Re: slurp, master & slave issues

[Jason Lixfeld <jason+lists.openldap@lixfeld.ca>]

On 28-Oct-04, at 2:52 AM, Pierangelo Masarati wrote:

> Jason Lixfeld wrote:
>
> > I've read chapter 13 of the manual and am trying to setup 
> > replication.  As per the examples, I went like so:
> >
> > On the master, I:
> >
> > ldapadd -f /tmp/Replicator.ldif
> >
> > == 8< == /tmp/Replicator.ldif == 8< ==
> >
> > dn:cn=Replicator,dc=example,dc=com
> > cn: Replicator
> > objectClass: organizationalRole
> > userPassword: {MD5}Chb+9Fr8crHiifMsNyQItw==
> >
> > == 8< == slapd.conf == 8< ==
> >
> > replogfile              /usr/local/etc/openldap/replog
> > replica-argsfile        /usr/local/etc/openldap/slurp.conf
> > replica-pidfile         /var/run/openldap/slurp.pid
> > replicationinterval     60
> >
> > replica uri=ldap://192.168.100.10:389
> >         binddn="cn=Replicator,dc=example,dc=com"
> >         bindmethod=simple credentials=*****
> >
> > ==
> >
> > Once the master configuration is done, I copy the database from the 
> > master to the slave.
> >
> > On the slave, I:
> >
> > == 8< == slapd.conf == 8< ==
> >
> > updatedn        cn=Replicator,dc=example,dc=com
> >
> > Once the slave configuration is done, I:
> >
> > Start slapd on the slave
> > Start slapd on the master
> > Start slurp on the master
> >
> > When I modify data on the master, I get this error in the slave logs:
> >
> > => access_allowed: backend default write access denied to 
> > "cn=Replicator,dc=example,dc=com"
> > <=- bdb_delete: no write access to parent
> > send_ldap_result: conn=0 op=1 p=3
> > send_ldap_result: err=50 matched="" text="no write access to parent"
> >
> > I managed to get this all working by changing the binddn on the 
> > master and the updatedn on the slave from Replicator to Manager (my 
> > rootdn) and it worked without issue so i can't figure out the 
> > difference between what I've done except for change Manager to 
> > Replicator.  Not to mention, I've read many notes suggesting that 
> > using the binddn of the root user is a bad idea so I'd like to get 
> > this working properly.
> >
> > Anyone see what I've missed?
>
> "cn=Replicator,dc=example,dc=com" must have appropriate access to 
> write data.  There are two options:
>
> 1) use "cn=Replicator,dc=example,dc=com" as rootdn of the slave (i.e. 
> a different name from that of the master)
> 2) add rules that allow "cn=Replicator,dc=example,dc=com" to write 
> anything, like

I thought about this, but I actually had no rules in place to begin 
with while testing.  Does the lack of rules mean an implicit deny to 
everything from anyone except the rootdn or does the lack of rules 
imply permit to everything from anyone?

> # first rule ever: in case identity doesn't match 
> "cn=Replicator,dc=example,dc=com",
> # control is passed to following rules, without giving any access 
> permissions.
> access to *
>    by dn.exact="cn=Replicator,dc=example,dc=com" write
>    by * none break
>
> # other access rules...
>
> Note that all of this is stated (maybe in slightly different terms) in 
> slapd.conf(5)
> (quote:)
>       updatedn <dn>
>              This option is only applicable in a slave  database
>              updated  using  slurpd(8).   It  specifies  the  DN
>              permitted to update (subject  to  access  controls)
>              the  replica  (typically,  this is the DN slurpd(8)
>              binds to update the replica).  Generally,  this  DN
>              should  not  be  the same as the rootdn used at the
>              master.
>
> note the points "subject to access control" and "not be the same as 
> the rootdn
> used at the master" (not the slave)...
>
> p.
>
>
>
>    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: 
> +390382476497