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

Replication Problem


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:
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 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
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 permissions I set
according to advices on the list and slapd.access man page. What am I

kind regards,