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.