Hello,
I have a question regarding the LDAP search mechanism. I have 2 Master Server and 1 Slave Server. All Servers are in Sync. The second Master is a standby Master which is active if the first one goes down. Now I want to test a failover szenario and shut down the first Master. The second one is active now and the Slave is now in Sync with the second one.
After rebooting the first Master I started LDAP and no error occured. LDAP is up and running. I tested the Server with some ldapsearches and everything works fine except the search with filters. If I do a search for example "uid=abc*" LDAP hangs and does not respond. Searching for exact DNs are working fine. What happended here?
Hopefully anybody can help me. Thanks a lot.
Best regards, Andi
On Tue, 28 Jul 2009, Andi Gorhan wrote:
some ldapsearches and everything works fine except the search with filters. If I do a search for example "uid=abc*" LDAP hangs and does not respond. Searching for exact DNs are working fine. What happended here?
Sounds like your indexes are corrupted. Just for ease of procedure, I'd recommend a slapcat/slapadd (although I'm sure you could poke around, just run slapindex for the affected files, etc). If you have old slapcat output around, you might want to keep it handy just in case the loss was bigger than just indexes...
Thanks for your reply Aaron. Seems to be a log problem. The log level was very high (16800) and that slows down the ldapsearch process. Anyway thanks for the answer.
Am 28.07.2009 um 17:44 schrieb Aaron Richton:
On Tue, 28 Jul 2009, Andi Gorhan wrote:
some ldapsearches and everything works fine except the search with filters. If I do a search for example "uid=abc*" LDAP hangs and does not respond. Searching for exact DNs are working fine. What happended here?
Sounds like your indexes are corrupted. Just for ease of procedure, I'd recommend a slapcat/slapadd (although I'm sure you could poke around, just run slapindex for the affected files, etc). If you have old slapcat output around, you might want to keep it handy just in case the loss was bigger than just indexes...
Andreas Gorhan wrote:
Thanks for your reply Aaron. Seems to be a log problem. The log level was very high (16800) and that slows down the ldapsearch process. Anyway thanks for the answer.
This loglevel is nonsense. The mere notion of "high" makes no sense in OpenLDAP's logging configuration. The loglevel is a mask that tells what susbsystems are logging. 16800 means 0x41a0 which means:
sync (0x4000) stats (0x100) acl (0x80) filter (0x20)
While stats definitely makes sense, and sync may make some sense when tracking synchronization issues that can only be tracked "live", acl and filter do not make any sense in a production environment. Acl only makes sense in extreme cases while debugging acl design. Similar considerations apply to filter.
p.
openldap-software@openldap.org
-
Aaron Richton -
Andi Gorhan -
Andreas Gorhan
-
Pierangelo Masarati