[Date Prev][Date Next]
Re: slurpd replication, "entryCSN: no user modification allowed"
rootdn and updatedn really really really need to be different. We've
had this discussion about 18 months ago (maybe more). I believe it is
even spelled out in the admin guide.
So, I believe the slave is getting confused and not knowing if you are
trying to do an replication-update or if the rootdn has just connected
to it to do a force update (via ldapmodify say) and is therefore
assuming the rootdn and rejecting the update. I expect you will solve
your problem if you change the updatedn to be different from the rootdn.
Ah, ok - I'll try it out. According to the administrator's guide at
http://www.openldap.org/doc/admin22/replication.html, rootdn can be
used. Maybe it needs updating.
'Note that the DN given by the binddn= directive must exist in the slave
slapd's database _(or be the rootdn specified in the slapd config file)_
in order for the bind operation to succeed...It is generally recommended
that this DN be different than the rootdn of the master database.'