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

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.'