[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slurp, master & slave issues

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< ==

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://
        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)
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

note the points "subject to access control" and "not be the same as the rootdn
used at the master" (not the slave)...


SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497