Further research in the archives reveals that this is not an error, it just means that it was looking for the index of a value that doesn't exist in the DB.
http://www.openldap.org/lists/openldap-technical/201005/msg00011.html
I can see that the servers are talking to each other. I can see db files in the consumer's accesslog directory, but an ldap search on the consumer fails with:
ldap_search: No such object
Further logging reveals it can't find the main suffix laid out in slapd.conf dc=city,dc=ac,dc=uk
=> bdb_dn2id("dc=city,dc=ac,dc=uk") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988)
I thought this would be automatically added from the conf file and also contained in the data replicated from the consumer. Can someone point out my (probably obvious) mistake?
Thanks very much, Mark
-----Original Message----- From: Gocher, Mark Sent: 02 June 2010 14:08 To: openldap-technical@openldap.org Subject: RE: Syncrepl - ldap_bind: Invalid credentials error
Thanks very much for your response. I found that I had created replicator as a uid on one server and a cn on the other. I then changed my dn password to SSHA and the consumer can now talk to the provider.
I found, however, that no content was being provided to the consumer. I'm not sure if the error was already there or was caused by something I just "fixed", but when I start my provider db I get this error:
daemon: select: listen=7 active_threads=0 tvp=zero daemon: select: listen=8 active_threads=0 tvp=zero => hdb_search bdb_dn2entry("cn=accesslog") => access_allowed: search access to "cn=accesslog" "entry" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) search_candidates: base="cn=accesslog" (0x00000002) scope=1 => hdb_dn2idl("cn=accesslog") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates OR => bdb_list_candidates 0xa1 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [b49d1940] <= bdb_index_read: failed (-30988) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_filter_candidates LE => bdb_inequality_candidates (reqStart) => key_read bdb_idl_fetch_key: <= bdb_index_read: failed (-30988) <= bdb_inequality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 <= bdb_list_candidates: id=0 first=0 last=0 <= bdb_filter_candidates: id=0 first=0 last=0 <= bdb_list_candidates: id=0 first=0 last=0 <= bdb_filter_candidates: id=0 first=0 last=0 bdb_search_candidates: id=0 first=0 last=0 hdb_search: no candidates send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text=""
I have re-indexed and performed a db_recovery and can see no errors in the logs. I can perform ldapsearches on my db successfully. I'm at a bit of a loss as to what the cause or repair of the index read failure might be. Any help would be very gratefully received.
Reindex and db_recovery output snippet: ./slapindex -f /usr/local/openldap-2.4.22/servers/slapd/slapd.conf -v -d 1 slapindex init: initiated tool. slap_sasl_init: initialized! bdb_back_initialize: initialize BDB backend bdb_back_initialize: Berkeley DB 4.7.25: (May 15, 2008) hdb_back_initialize: initialize HDB backend hdb_back_initialize: Berkeley DB 4.7.25: (May 15, 2008) ==> translucent_initialize bdb_db_init: Initializing BDB database
dnPrettyNormal: <dc=city,dc=ac,dc=uk>
<<< dnPrettyNormal: <dc=city,dc=ac,dc=uk>, <dc=city,dc=ac,dc=uk>
dnPrettyNormal: <cn=DSAmgr,dc=city,dc=ac,dc=uk>
<<< dnPrettyNormal: <cn=DSAmgr,dc=city,dc=ac,dc=uk>, <cn=dsamgr,dc=city,dc=ac,dc=uk>
dnNormalize: <cn=replicator,dc=city,dc=ac,dc=uk>
<<< dnNormalize: <cn=replicator,dc=city,dc=ac,dc=uk>
dnNormalize: <cn=replicator,dc=city,dc=ac,dc=uk>
<<< dnNormalize: <cn=replicator,dc=city,dc=ac,dc=uk> hdb_db_init: Initializing HDB database ����� back-bdb/back-hdb monitor: "olmBDBAttributes" previously defined "1.3.6.1.4.1.4203.666.1.55.0.1.1" ����� back-bdb/back-hdb monitor: "olmBDBObjectClasses" previously defined "1.3.6.1.4.1.4203.666.3.16.0.1.1"
dnPrettyNormal: <cn=accesslog>
<<< dnPrettyNormal: <cn=accesslog>, <cn=accesslog>
dnPrettyNormal: <cn=accesslog>
<<< dnPrettyNormal: <cn=accesslog>, <cn=accesslog>
dnNormalize: <cn=replicator,dc=city,dc=ac,dc=uk>
<<< dnNormalize: <cn=replicator,dc=city,dc=ac,dc=uk>
dnPrettyNormal: <cn=accesslog>
<<< dnPrettyNormal: <cn=accesslog>, <cn=accesslog>
dnPrettyNormal: <cn=Monitor>
<<< dnPrettyNormal: <cn=Monitor>, <cn=monitor>
dnNormalize: <cn=Subschema>
<<< dnNormalize: <cn=subschema> matching_rule_use_init ----snipped to end of output----- <= key_change 0 => key_change(ADD,c) <= key_change 0 <= index_entry_add( 12, "cn=DSAmgr,dc=city,dc=ac,dc=uk" ) success slapindex shutdown: initiated ====> bdb_cache_release_all slapindex destroy: freeing system resources. -bash-3.00# /usr/local/BerkeleyDB.4.7/bin/db_recover -vFinding last valid log LSN: file: 1 offset 28
Regards, Mark
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: 01 June 2010 17:20 To: Gocher, Mark; openldap-technical@openldap.org Subject: Re: Syncrepl - ldap_bind: Invalid credentials error
--On Tuesday, June 01, 2010 9:51 AM +0100 "Gocher, Mark" Mark.Gocher.1@city.ac.uk wrote:
I'm receiving the following error on my consumer, using logging -d stats + args + trace + sync 2> /var/log/ldap
@(#) $OpenLDAP: slapd 2.4.22 (May 21 2010 12:10:42) $
@cambridge:/usr/local/openldap-2.4.22/servers/slapd
slapd starting
slap_client_connect: URI=ldap://oxford.unix1.city.ac.uk:389 DN="cn=replicator,dc=city,dc=ac,dc=uk" ldap_sasl_bind_s failed (49)
Error 49 says that an invalid password was provided (or that the DN isn't right).
I have created the uid for replicator and repeated this search with the 'access to attrs=userPassword' line commented out on the provider to ensure that the userPassword for replicator is clear text 'secret'. I can also perform this search from the consumer successfully.
Your provider conf file is a mess. It has a mix of global and database specific directives peppered through it. You load modules after using them, etc. I would spend some time cleaning up your provider's configuration (and possible the replica one too, I didn't look at it closely).
Provider ldap.conf:
database bdb
suffix "dc=city,dc=ac,dc=uk"
rootdn "cn=DSAmgr,dc=city,dc=ac,dc=uk"
rootpw {CRYPT}aZmvWMwFgg.vk
Crypt is non portable. You should use SSHA or similar.