[Date Prev][Date Next] [Chronological] [Thread] [Top]
So I finally upgraded from slurpd...

To: openldap-technical@openldap.org
Subject: So I finally upgraded from slurpd...
From: Kolbjørn Barmen <kolbjorn.barmen@uninett.no>
Date: Thu, 8 Jul 2010 19:04:11 +0200 (CEST)
User-agent: Alpine 2.01 (LNX 1266 2009-07-14)
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) $ ^Iroot@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
Follow-Ups:
- Re: So I finally upgraded from slurpd...
  - From: Quanah Gibson-Mount <quanah@zimbra.com>
Prev by Date: dynlist attributes and search filters
Next by Date: RE: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
Index(es):
- Chronological
- Thread