On Apr 21, 2010, at 5:53 PM, Sergiy Stepanenko wrote:
I simulated conditions close to what you described and in my case it was caused by database config not being defined in slapd.conf. Ldapwhoami returns proper response, ldap search on anything but cn=config returns proper response, cn=config search returns err 32 no such object and Apache is unable to connect at all. Sounds about right... Make sure that you do have database config defined either way (slapd.conf or slap.d via ldif) with proper access definition to it by either rootdn or access to.
Hope it is all you need to do.
Best regards
-- Sergiy Stepanenko Systems Administrator Information Technology Services University of Saskatchewan
phone: (306) 966-2762 email:sergiy.stepanenko@usask.ca
I ended up taking down the primary, doing a `slapcat -l backup.ldif` and bringing it back up. Then went to the slave, took down slapd then `rm -rf /var/lib/ldap/*; slapadd -l backup.ldif; chown -r openldap:openldap /var/lib/ldap/*` and then bringing slapd back up. Checked to make sure replication was working. And hurray, I can authenticate against the slave server now!
That was very strange, replication to go out of sync but keep updating the slave with no errors or warnings. I have backups from both servers and I cannot see any difference in their ldif's. Very confusing because everything is the same, the flavor and version of linux, the version of openldap, the config files (except for the syncrepl parts). I hope this doesn't happen again.
Without your ideas and support I would not have kept going to fixing this. Thank you!
-a