Re: Replication Problem

[Buchan Milne <bgmilne@staff.telkomsa.net>]

On Thursday 25 October 2007 21:51:12 Marcus Frischherz wrote:
> Hi,
>
> I think I searched the internet and the documentation carefully, and
> still have problems:
>
> Master and slave are both openSuSE 10.2, running openldap 2.3.27
> (unaltered SuSE version).
>
> I set up in the master:

If this was *exactly* what was in your slapd.conf, it is broken. White space 
is very important in slapd.conf, there should be leading white space before 
the first characters on your line starting with bindmethod (as it is part of 
the replica statement, which should be on one line, and lines may be 
continued by using leading white space on the next line to aid readability).

> replogfile /var/lib/ldap/slurpd/slurpd.replog
> replica host=frifri_vpn:389 binddn="uid=rmanager,ou=intern,o=rori"
> bindmethod=simple credentials=xxx
>
> and on the slave:
> [...beginning of access rules]
> access to *
>         by dn.exact="uid=rmanager,ou=intern,o=rori" write
>         by * break
>
> access to dn.base=""
>         by * read
>
> access to dn.base="cn=Subschema"
>         by * read
>
> access to attrs=userPassword,userPKCS12
>         by self write
>         by * auth
>
> access to attrs=shadowLastChange
>         by self write
>         by * read
>
> access to *
>         by * read
> [...]
> updatedn="uid=rmanager,ou=intern,o=rori" updateref rori_vpn:389

And here, the updatedn should be the first text on a new line (no leading 
white space), and the same thing for updateref. If you really have updatedn 
and updateref on the same line, this would explain your problem below.

> and populated the slave's database with slapadd
> and restarted slapd on master and slave, + slurpd on master.
>
> Everytime I make a change on the master I get in the rejection file the
> same error code:
> ERROR: Constraint violation: structuralObjectClass: no user modification
> allow
>  ed
> replica: frifri_vpn:389
> time: 1193340583.0
> dn: cn=test test,ou=people,o=rori
> changetype: add
> sn: test
> givenName: test
> mail: x@y
> mozillaCustom2: FriFri
> cn: test test
> objectClass: top
> objectClass: inetOrgPerson
> objectClass: abookPerson
> objectClass: mozillaOrgPerson
> structuralObjectClass: mozillaOrgPerson
> entryUUID: 6208a648-177c-102c-9f5a-29bdb5d43dbc
> creatorsName: cn=Manager,o=rori
> createTimestamp: 20071025192943Z
> entryCSN: 20071025192943Z#000000#00#000000
> modifiersName: cn=Manager,o=rori
> modifyTimestamp: 20071025192943Z
>
> I have found various references to "Constraint violation:
> structuralObjectClass: no user modification allowed" on the internet,
> e.g. pointing out that a restore of a slapcat produced ldif with ldapadd
> will result in this error message (and ran myself into that problem,
> until I found out I was supposed to use slapadd), and apparently various
> people had the same occuring with replication, but I didn't see a
> solution. It seems that either master's ldap should not produce the
> structuralObjectClass: mozillaOrgPerson line (and other organization
> ones neither), or slave's ldap should accept it.

The slave will only accept operational attributes from the updatedn. 
Additionally, it won't accept any changes from anything but the updatedn, if 
the updateref is set. So, it seems like slapd on the slave is not parsing 
either of your updatedn or updateref statements.

If you don't succeed in fixing the issue, please attach sanitised versions of 
your configuration files, so we can be sure we are looking at *exactly* what 
you have in slapd.conf.

I note that slurpd-based replication is deprecated in 2.3, and slurpd has been 
removed from 2.4.

Regards,
Buchan