Hello Let me start by introducing myself briefly: * I'm a sysadm at the Norwegian NREN (UNINETT) * As sysadm here, I end up doing a heck lot of things at once, and our LDAP servers are really just tiny (but important) pieces in our huge puzzle that is our network infrastructure. Point being, I dont have the capasity to "know it all", or RTFM (and comprehend) everything I'm involved with, things just tend to drop into my lap. * I'm not paricularly interested or fond of LDAP as such :) * I have also no particular interest in diving into LDAP and become some sort of LDAP-wizzard in the future
I just felt mentioning the above before anyone throw me an RTFM ;) Anyways... I have at last upgraded a system from using slurpd (debian etch, slapd 2.3.30) to using replsync, at least that was the intention. Let me start with the scenario: * one master LDAP-server with a web frontend (old modified GOsa) * 30ish slave LDAP-servers spread around on various institutions * on the master LDAP-server, each institution has its own branch, like dc=foo,dc=no ; dc=bar,dc=no etc. * each slave is supposed to replacicate only its own branch, for exmple server.foo.no only has dc=foo,dc=no replicated from the master * for each dc=foo,dc=no there is an admin user, eg. cn=admin,dc=foo,dc=no that has all rights granted to the according subtree dc=foo,dc=no That in all its simplity i the scenario. With slurpd I had in masters slapd.conf entries like this: replica host="server.foo.no" suffix="dc=foo,dc=no" binddn="cn=admin,dc=foo,dc=no" credentials="f00bAr123" bindmethod="simple" tls="critical" and on the slaves, (running 2.4.23, they were upgraded some time ago): updatedn "cn=admin,dc=foo,dc=no" updateref ldap://masterserver.uninett.no/ This worked fine, apart from occations of out-of-sync every now and then. Now, with upgraded master - I have yet to get any replication working. Which sync method is most likely the best for my scenario? On master I have added: =================== ... moduleload syncprov.la moduleload back_ldap.la ... # and under database, it looks like this: database bdb suffix "dc=no" directory "/var/lib/ldap" rootdn "cn=root,dc=no" rootpw {SMD5}XXXXXXXXXXXXXXXXXXXXXXXXXXX= index objectClass eq index uid,gidNumber,uidNumber,memberUid pres,eq index mail,gosaMailAlternateAddress pres,eq,sub index gosaUser,gosaObject pres,eq,sub index zoneName,relativeDomaiNname pres,eq lastmod on sizelimit 4000 overlay syncprov syncprov-checkpoint 1000 60 syncprov-sessionlog 100 # and some access lists access to dn.regex="dc=([^,]+),dc=no$" attrs=userPassword,sambaLMPassword,sambaNTPassword,goImapPassword by dn.regex="^cn=admin,dc=$1,dc=no$" write by anonymous auth by self write by * none access to dn.base="" by * read access to dn.regex="dc=([^,]+),dc=no$" by dn.regex="^cn=admin,dc=$1,dc=no$" write by * read =================== And on slave: =================== ... ... database bdb suffix "dc=foo,dc=no" directory "/var/lib/ldap" rootdn "cn=admin,dc=foo,dc=no" rootpw {SMD5}XXXXXXXXXXXXXXXXXXXXXXXXXXX= index objectclass,entryCSN,entryUUID eq index uid,gidNumber,uidNumber,memberUid pres,eq index mail,gosaMailAlternateAddress pres,eq,sub lastmod on sizelimit 4000 # updatedn "cn=admin,dc=foo,dc=no" # updateref ldap://masterserver.uninett.no/ syncrepl rid=123 provider=ldaps://masterserver.uninett.no:636/ type=refreshOnly interval=00:00:00:10 retry="60 +" searchbase="dc=foo,dc=no" scope=sub schemachecking=off bindmethod=simple binddn="cn=admin,dc=foo,dc=no" credentials="f00bAr123" access to attrs=userPassword,sambaLMPassword,sambaNTPassword,goImapPassword by anonymous auth by self write by * none access to dn.base="" by * read access to * by * read =================== I have (in good tradition) done a slapcat of the subtree dc=foo,dc=no on the master and copied over the ldif to the slave, and there used slapadd to create the entire database from scratch, so the content is identical. When I start slapd on the slave I get on the slave: =================== 18:37:50 server.foo.no slapd[7971]: @(#) $OpenLDAP: slapd 2.4.23 (Jul 5 2010 18:35:50) $ ^ir...@localhost:/home/kolla/openldap/openldap-2.4.23/debian/build/servers/slapd 18:37:50 server.foo.no slapd[7972]: slapd starting 18:37:50 server.foo.no slapd[7972]: syncrepl_message_to_entry: rid=123 mods check (objectClass: value #0 provided more than once) 18:37:50 server.foo.no slapd[7972]: do_syncrepl: rid=123 rc 20 retrying 18:38:50 server.foo.no slapd[7972]: syncrepl_message_to_entry: rid=123 mods check (objectClass: value #0 provided more than once) 18:38:50 server.foo.no slapd[7972]: do_syncrepl: rid=123 rc 20 retrying =================== And on the master: =================== 18:37:50 ratatosk slapd[9162]: conn=1069 fd=16 ACCEPT from IP=NNN.NN.NN.NN:43227 (IP=0.0.0.0:636) 18:37:50 ratatosk slapd[9162]: conn=1069 fd=16 TLS established tls_ssf=256 ssf=256 18:37:50 ratatosk slapd[9162]: conn=1069 op=0 BIND dn="cn=admin,dc=foo,dc=no" method=128 18:37:50 ratatosk slapd[9162]: conn=1069 op=0 BIND dn="cn=admin,dc=foo,dc=no" mech=SIMPLE ssf=0 18:37:50 ratatosk slapd[9162]: conn=1069 op=0 RESULT tag=97 err=0 text= 18:37:50 ratatosk slapd[9162]: conn=1069 op=1 SRCH base="dc=foo,dc=no" scope=2 deref=0 filter="(objectClass=*)" 18:37:50 ratatosk slapd[9162]: conn=1069 op=1 SRCH attr=* + 18:37:50 ratatosk slapd[9162]: conn=1069 op=2 UNBIND 18:37:50 ratatosk slapd[9162]: conn=1069 fd=16 closed 18:38:50 ratatosk slapd[9162]: conn=1070 fd=16 ACCEPT from IP=NNN.NN.NN.NN:43239 (IP=0.0.0.0:636) 18:38:50 ratatosk slapd[9162]: conn=1070 fd=16 TLS established tls_ssf=256 ssf=256 18:38:50 ratatosk slapd[9162]: conn=1070 op=0 BIND dn="cn=admin,dc=foo,dc=no" method=128 18:38:50 ratatosk slapd[9162]: conn=1070 op=0 BIND dn="cn=admin,dc=foo,dc=no" mech=SIMPLE ssf=0 18:38:50 ratatosk slapd[9162]: conn=1070 op=0 RESULT tag=97 err=0 text= 18:38:50 ratatosk slapd[9162]: conn=1070 op=1 SRCH base="dc=foo,dc=no" scope=2 deref=0 filter="(objectClass=*)" 18:38:50 ratatosk slapd[9162]: conn=1070 op=1 SRCH attr=* + 18:38:50 ratatosk slapd[9162]: conn=1070 op=2 UNBIND 18:38:50 ratatosk slapd[9162]: conn=1070 fd=16 closed =================== and so it goes, but no sync is done whatsoever. What am I doing wrong here? And what could cause this message to appear on the slave: "syncrepl_message_to_entry: rid=123 mods check (objectClass: valu e #0 provided more than once)" Any help is very welcome, especially examplified configs that I can use as "template" for my scenario. Thanks a bunch! :) -- Kolbjørn Barmen UNINETT Driftsenter