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

Re: slurpd replication, "entryCSN: no user modification allowed"

| I am trying to set up a slave to my openldap server using slurpd.  In
| slurpd debug, modifications are greeting with:
| Error: ldap_modify_s failed modifying "entryCSN: no user modification
| allowed":

This usually means the dn you are using to replicate is not the dn
listed in the updatedn entry in the slapd.conf on the slave, or the
updatedn entry is not present in the slapd.conf (since only the updatedn
~ should be allowed to change operational attributes).

Just to be certain that this is not related to binddn / updatedn, I tried running slurpd in one shot mode, with and without the entryCSN line. splurpd then reported 'modifiersName: user user modification allowed. The same thing happened with modifyTimestamp. When I hashed out all three of these changes, the actual modification worked fine.

I'm currently replicating the database by grepping entryCSN, modifiersName and modifyTimestamp out of the replog, and running slurpd in one shot mode every minute. I'm thinking there has to be a better way than that.

The edited replog entry:

replica: ldap://ldap2.mydomain.com:389
time: 1086270130
dn: uid=myuser,ou=radius,dc=mydomain,dc=com
changetype: modify
replace: rategroupid
rategroupid: newvalue
#replace: entryCSN				<=entryCSN hashed out
#entryCSN: 2004060313:42:10Z#0x0001#0#0000
#replace: modifiersName				<=hashed out
#modifiersName: uid=root,dc=mydomain,dc=com	
#replace: modifyTimestamp			<=hashed out
#modifyTimestamp: 20040603134210Z

returns this from slurpd -o:

Processing in one-shot mode: 1 total replication records in file, 1 replication records to process. begin replication thread for ldap:0 end replication thread for ldap:0 slurpd: terminated.

So, the credentials are just fine, it's the fact that the master is trying to update unmodifiable attributes on the slave.

This doesn't really make sense - can anyone shed some light?