I go in using Exodus on windows or Spark on Linux. I can do a search the first time, but after that, the service hangs. Say that is cannot be contacted. However looking to the logs, I see the the search service has kicked off an entire LDAP listing search again, probably to update records, however I cannot search for a user name while it is doing that. Any suggestions on how to make this run cleaner from Cache?
Jeff
Message was edited by: jeff_garner
OK! First thanks to everyone on the forums that have helped me over the last several days to get me to this. Whoever wrote the documents for LDAP that are included in this build (and probably all the others) HUGE thanks! RTFM!
Here is my working config snippet working against eDirectory (LDAP). The search filter will only search out one particular attribute on the user’'s account and then only return those names that have that attribute, it also will not allow anyone without that attribute to login the server. Went from 23K+ entries to the 3300 that are allowed to login the server! Security is a wonderful thing.
Hey Jeff,
Searches can be so finely grained that it isn’‘t worth caching their results. A better solution would be to implement paging in searches, XMPP does have an experimental provision for this that we plan on implementing in the long term. In the short term we have decided to limit the count of results that can be returned for a particular search, this will be configurable by a jive property but larger searches start to outwhere their usefullness just being able to sort through the information, you’'d need a search for your search
I’'ve created two issues to track the progress of both these improvements:
JM-616
JM-617
Cheers,
Alex
Hi Guys,
Another somewhat related issue is JM-508 which will allow you limit search results via a search filter when using LDAP.
Regards,
Ryan
I can appreciate the need to limit searches, esp. with the size of my LDAP base. However in this instance, this filter is needed not only to allow for a specific search, but to enforce security for login on the server. Understanding that xmmp based servers are for individuals to sign up and start chatting, I have to limit my login criteria to only specified users within my LDAP, thus providing an approved list of people that can login, and leaving the other entries in LDAP as not allowed to login. For my production box, soon to rolled out I might add, I will have to use my filter to enforce the login security. Seeing that I could be in the minority of Wildfire administrators, I do see the benenfits at limiting searches for users, but still allowing for searches against the entire database. I just can’'t deploy it in my production environment.
Jeff
The way authentication uses and limits the search mechanism and the way user searches are performed are handled completly differently. This was implicit in the improvements and I should’'ve made that more clear, so, you have nothing to fear.
Cheers,
Alex
Ok. I can see that. I will say however that the way that Wildfire uses the filter that I posted not only limits the login capability, but also limits the user’'s search base down to those only allowed to login. In my deployment, this will be a suffcient means at getting me to my goal. If the limitations that you have built in helps this along, that would be great as currently although working, the initial search with my tag is 45 seconds or so to login and initial searches for individual names. Not a large amount of time, but to make it quicker will be great.
Currently, I have prepared another Linux based machine in the office that I have installed Wildfire 2.5.1 on, with the same setup as my test machine minus the search tag. Tomorrow, I will be backing the search tab off of the test box, allowing again an entire search of the LDAP. I couldn’‘t accomplish everythig today, although both boxes are capable of server xmpp traffic properly at this time. Tomorrrow, I will complete the tasks that Gato asked for me to check 2.5.1 vs. 2.6.0 latest nightly build (which should be tonight’'s). I will attempt to give you ample feed-back on Sunday as to how everything went as per his instructions. Hopefully this can help you refine anything needed (if needed as I am quite happy right now.)
Jeff
Message was edited by: jeff_garner
Message was edited by: jeff_garner