[Date Prev][Date Next]
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
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:
#replace: entryCSN <=entryCSN hashed out
#replace: modifiersName <=hashed out
#replace: modifyTimestamp <=hashed out
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
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?