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)
I can see from the documentation that my consumer is not authenticating to my provider, but I can't see what the error is. If any other info would help please let me know.
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.
ldapsearch -x -b dc=city,dc=ac,dc=uk uid=replicator version: 1 dn: uid=replicator,ou=users,dc=city,dc=ac,dc=uk objectClass: person objectClass: posixAccount objectClass: inetOrgPerson sn: replicator cn: replicator uid: replicator uidNumber: 22258 gidNumber: 22258 homeDirectory: /export/home/replicator userPassword: secret displayName: replicator mail: None labeledURI: None description: openLDAP replication id
Consumer ldap.conf:
database bdb suffix "dc=city,dc=ac,dc=uk" rootdn "cn=DSAmgr,dc=city,dc=ac,dc=uk" rootpw {CRYPT}******* directory /var/opt/csw/openldap-data index default pres,eq,sub index objectClass eq index cn index sn index uid access to attrs=userPassword by anonymous auth by * none
access to * by * read index entryUUID eq syncrepl rid=0 provider=ldap://oxford.unix1.city.ac.uk:389 bindmethod=simple binddn="cn=replicator,dc=city,dc=ac,dc=uk" credentials=secret searchbase="dc=city,dc=ac,dc=uk" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog updateref ldap://oxford.unix1.city.ac.uk database monitor
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
directory /var/opt/csw/openldap-data index default pres,eq,sub index objectClass eq index cn index sn index uid access to * by dn.base="cn=replicator,dc=city,dc=ac,dc=uk" read by * break
access to attrs=userPassword by anonymous auth by * none
access to * by * read
modulepath /usr/local/openldap-2.4.22 moduleload back_bdb.la moduleload accesslog.la moduleload syncprov.la database bdb suffix cn=accesslog directory /var/opt/csw/accesslog rootdn cn=accesslog index default eq index objectClass,reqEnd,reqResult,reqStart
overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE limits dn.exact="cn=replicator,dc=city,dc=ac,dc=uk" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # database bdb # suffix "dc=dc=city,dc=ac,dc=uk" # rootdn "cn=DSAmgr,dc=city,dc=ac,dc=uk" index entryCSN eq index entryUUID eq overlay syncprov syncprov-checkpoint 1000 60 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 99+00:00 00+00:01
# Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=city,dc=ac,dc=uk" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited database monitor
I increased the logging and found this upon starting up the provider:
=> bdb_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" (0x00000001) scope=1 => bdb_dn2idl("cn=accesslog") bdb_idl_fetch_key: %cn=accesslog <= bdb_dn2idl: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) bdb_search_candidates: failed (rc=-30988) bdb_search: no candidates
I realised that I hadn’t created a cn=accesslog.
I’ve done that now with an ldif file, results of an ldapsearch on that entry below, but still get the same error.
ldapsearch -x -b dc=city,dc=ac,dc=uk cn=accesslog version: 1 dn: cn=accesslog,dc=city,dc=ac,dc=uk objectClass: auditContainer cn: accesslog
Is there something more I need to do for the cn=accesslog to work?
From: Gocher, Mark [mailto:Mark.Gocher.1@city.ac.uk] Sent: 01 June 2010 09:51 To: openldap-technical@openldap.org Subject: Syncrepl - ldap_bind: Invalid credentials error
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)
I can see from the documentation that my consumer is not authenticating to my provider, but I can’t see what the error is. If any other info would help please let me know.
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.
ldapsearch -x -b dc=city,dc=ac,dc=uk uid=replicator version: 1 dn: uid=replicator,ou=users,dc=city,dc=ac,dc=uk objectClass: person objectClass: posixAccount objectClass: inetOrgPerson sn: replicator cn: replicator uid: replicator uidNumber: 22258 gidNumber: 22258 homeDirectory: /export/home/replicator userPassword: secret displayName: replicator mail: None labeledURI: None description: openLDAP replication id
Consumer ldap.conf:
database bdb suffix "dc=city,dc=ac,dc=uk" rootdn "cn=DSAmgr,dc=city,dc=ac,dc=uk" rootpw {CRYPT}******* directory /var/opt/csw/openldap-data index default pres,eq,sub index objectClass eq index cn index sn index uid access to attrs=userPassword by anonymous auth by * none
access to * by * read index entryUUID eq syncrepl rid=0 provider=ldap://oxford.unix1.city.ac.uk:389 bindmethod=simple binddn="cn=replicator,dc=city,dc=ac,dc=uk" credentials=secret searchbase="dc=city,dc=ac,dc=uk" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog updateref ldap://oxford.unix1.city.ac.uk database monitor
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
directory /var/opt/csw/openldap-data index default pres,eq,sub index objectClass eq index cn index sn index uid access to * by dn.base="cn=replicator,dc=city,dc=ac,dc=uk" read by * break
access to attrs=userPassword by anonymous auth by * none
access to * by * read
modulepath /usr/local/openldap-2.4.22 moduleload back_bdb.la moduleload accesslog.la moduleload syncprov.la database bdb suffix cn=accesslog directory /var/opt/csw/accesslog rootdn cn=accesslog index default eq index objectClass,reqEnd,reqResult,reqStart
overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE limits dn.exact="cn=replicator,dc=city,dc=ac,dc=uk" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # database bdb # suffix "dc=dc=city,dc=ac,dc=uk" # rootdn "cn=DSAmgr,dc=city,dc=ac,dc=uk" index entryCSN eq index entryUUID eq overlay syncprov syncprov-checkpoint 1000 60 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 99+00:00 00+00:01
# Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=city,dc=ac,dc=uk" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited database monitor
--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.
directory /var/opt/csw/openldap-data
index default pres,eq,sub
index objectClass eq
index cn
index sn
index uid
access to *
by dn.base="cn=replicator,dc=city,dc=ac,dc=uk" read
by * break
access to attrs=userPassword
by anonymous auth
by * none
access to *
by * read
modulepath /usr/local/openldap-2.4.22
moduleload back_bdb.la
moduleload accesslog.la
moduleload syncprov.la
database bdb
suffix cn=accesslog
directory /var/opt/csw/accesslog
rootdn cn=accesslog
index default eq
index objectClass,reqEnd,reqResult,reqStart
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
limits dn.exact="cn=replicator,dc=city,dc=ac,dc=uk" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
# database bdb
# suffix "dc=dc=city,dc=ac,dc=uk"
# rootdn "cn=DSAmgr,dc=city,dc=ac,dc=uk"
index entryCSN eq
index entryUUID eq
overlay syncprov
syncprov-checkpoint 1000 60
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
logpurge 99+00:00 00+00:01
# Let the replica DN have limitless searches
limits dn.exact="cn=replicator,dc=city,dc=ac,dc=uk" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
database monitor
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
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.
--On Wednesday, June 02, 2010 2:07 PM +0100 "Gocher, Mark" Mark.Gocher.1@city.ac.uk wrote:
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:
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 don't see any error here. What I see is that there are currently no contents in the accesslog database, or that there are no new changes to the accesslog DB since the last changes were made. But still, no evidence of any error other than configuration, or normal operating behavior.
Have you loaded the consumer with a slapcat of the master via slapadd?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Thanks again Quanah, you've been very helpful. By a very long way round I'd come to the same conclusion. My consumer only knows of the entries in the conf file.
Firstly I don't understand the slapcat part, and didn't see that in the documentation, I'll go and look it up. Secondly on the provider my main db is bdb and my accesslog db is hdb. On my provider I just have a bdb database in slapd.conf.
Have I put a conflict in here? Should they all be bdb or should I have a second accesslog hdb database configured on the consumer? I've re-read the documentation but it still isn't clear to me.
Your help is very much appreciated, Mark
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: 02 June 2010 16:29 To: Gocher, Mark; openldap-technical@openldap.org Subject: RE: Syncrepl - ldap_bind: Invalid credentials error
--On Wednesday, June 02, 2010 2:07 PM +0100 "Gocher, Mark" Mark.Gocher.1@city.ac.uk wrote:
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:
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 don't see any error here. What I see is that there are currently no contents in the accesslog database, or that there are no new changes to the accesslog DB since the last changes were made. But still, no evidence of any error other than configuration, or normal operating behavior.
Have you loaded the consumer with a slapcat of the master via slapadd?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Wednesday, June 02, 2010 4:53 PM +0100 "Gocher, Mark" Mark.Gocher.1@city.ac.uk wrote:
Thanks again Quanah, you've been very helpful. By a very long way round I'd come to the same conclusion. My consumer only knows of the entries in the conf file.
Firstly I don't understand the slapcat part, and didn't see that in the documentation, I'll go and look it up. Secondly on the provider my main db is bdb and my accesslog db is hdb. On my provider I just have a bdb database in slapd.conf.
slapcat is the supported mechanism for taking a backup of the LDAP database. slapadd is the supported way to import an LDIF file generated by slapcat into another LDAP server. Together, they form the bulk export/import capabilities of LDAP.
As for your databases, I would suggest using all the same type. back-hdb is the preferred database, back-bdb is being phased out. I would note that switching backend types will require slapcatting the main database on the master and then reloading it with slapadd after deleting the old back-bdb database.
As I said in the prior email, you can force the consumer to reload all data from the master using the -c option to slapd to reset its cookie. You may want to do that just to verify everything replicates as you need.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
OK, I've changed to hdb throughout and successfully backed up and restored my db before adding it to my consumer with the -c rid=000 option.
Still had a few issues with overlay syncprov but went back to your earlier post and restructured my slapd.conf file to match the pattern in the documentation.
Replication is now working, thanks very much for all your help, you saved me a huge amount of time.
Now to have a look at PAM.....................
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: 02 June 2010 20:22 To: Gocher, Mark; openldap-technical@openldap.org Subject: RE: Syncrepl - ldap_bind: Invalid credentials error
--On Wednesday, June 02, 2010 4:53 PM +0100 "Gocher, Mark" Mark.Gocher.1@city.ac.uk wrote:
Thanks again Quanah, you've been very helpful. By a very long way round I'd come to the same conclusion. My consumer only knows of the entries in the conf file.
Firstly I don't understand the slapcat part, and didn't see that in the documentation, I'll go and look it up. Secondly on the provider my main db is bdb and my accesslog db is hdb. On my provider I just have a bdb database in slapd.conf.
slapcat is the supported mechanism for taking a backup of the LDAP database. slapadd is the supported way to import an LDIF file generated by slapcat into another LDAP server. Together, they form the bulk export/import capabilities of LDAP.
As for your databases, I would suggest using all the same type. back-hdb is the preferred database, back-bdb is being phased out. I would note that switching backend types will require slapcatting the main database on the master and then reloading it with slapadd after deleting the old back-bdb database.
As I said in the prior email, you can force the consumer to reload all data from the master using the -c option to slapd to reset its cookie. You may want to do that just to verify everything replicates as you need.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
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.
--On Wednesday, June 02, 2010 3:25 PM +0100 "Gocher, Mark" Mark.Gocher.1@city.ac.uk wrote:
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?
Your first mistake is to keep thinking codes you see reported are errors. Since it hasn't yet replicated anything from the master, how would the entry exist?
My guess would be that it set a cookie while your configs were incorrect, so it has no "knowledge" that it needs to update to anything later. Again, I would advise you to load the replica from the master via a slapadd. If not, man slapd, and reset the replication cookie as noted in the man page with the -c flag.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Gocher, Mark -
Quanah Gibson-Mount