powered by Jive Software

Ldap user and filtering down

Ok, as most fo you know, because of my incesent questions, I have my server, with the hook-up to the pre-existing database. When ever I do user logins it takes forever, and usually causes the client to disconnect without returning results to the roster . On looking at the debug, error, stderror and stdout, I have come to the reason for this. WIldfire is getting a complete listing of users attempting to gather users from the LDAP database I guess to populate or update the pqsl database. Ok, I can see it wanting to update entries, but I have over 23K users in this database, hence you see my issue. Althoguh at presnt this is on a test platform, it is a rather nice medium end machine, and it is still taking forever for the updates to happen, sometimes 25 minutes. I must find a way to limit what is being searched updated and cached or I will absolutely not be able to use Wildfire as my IM solution. Ldap is eDirectory, and the IM service (the ability to login in I mean) is controlled through attributes placed on accounts. I have tried all ideas, scripts, thoughts that I can find in the forum here, but cannot find a hook, or switch to limit the searches to the attribute “accessIM”. search filters are not working, or I am not setting them up correctly. alternateDN isn’'t working because when I point it to the group drectory, it will not allow login. THose of you that have helped no the issues I have been having with this, but If I cannot find a solution that will not only limit searches to IM users only, and cannot find a way to strictly allow only users the have the attribute to loing in, then I will have to go back to Jabberd, or ejabberd, as they can do this (my s8 install does it for me now). Any ideas are helpful, but the ideas already laid out in the forums were tried by me yesterday and today without success.


Hey Jeff,

The Wildfire 2.6.0 beta includes many optimizations and today we just checked in another one JM-607. There are 2 more very important optimizations pending to be implemented that may be finished early next week.

Once we have all these optimizations I would like to get in contact with you so we can test them together and possibly find more things to optimize. Anyway, with the current implemented optimizations and the 2 new ones things should look really different.

Feel free to contact me by IM so we can test the nightly build versions.


– Gato

For your information one of the other two issues being worked on is:




Fellas. GREAT! I know I may sound like a pain and all. I like what I see in WIldfire, getting others NOT to go to MS COMM SRV is becoming more and more difficult. Any testing you need done I will do it. I have and endless supply of boxes, and also want to be selfish here, I really want to get my issue resolved. Thank you so much. Will contact you tomorrow some time.



We are determined to get LDAP working much, much better then it is now. This will not only be of benefit to you but also to anyone that uses LDAP. Don’'t feel selfish, the great thing about finding issues and fixing them in Wildfire is that it will benefit everyone in the end. Thank you for taking the time out to post here and help us test and troubleshoot!