Problem with replicas (was: reprocessing rejected replica entries)

["Angel L. Mateo" <amateo@um.es>]

El lun, 23-01-2006 a las 14:47 -0500, matthew sporleder escribió:
> Slurpd will consume the file as it goes through it.
> If you end up with a .rej after processing the .rej, then your run
> didn't work and you'll have to investigate further.
> 
	So I have still the synchronization problem, although the entry in the
master server and in the slave on seems identical. isn't it?

	Let's come to analyze one of the problems, the first one:

ERROR: Constraint violation: entryCSN: no user modification allowed
replica: slave.telemat.um.es:389
time: 1125910938.0
dn: uid=<anuid>,<user base dn>
changetype: modify
replace: userPassword
userPassword:: <apassword>

	If I look for that entry in the master server I get:

dn: uid=<anuid>,<user base dn>
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: CourierMailAccount
cn: <His name>
uid: <anuid>
uidNumber: 100253
gidNumber: 1001
homeDirectory: <his home>
loginShell: /bin/bash
mail: <anuid>@<mydomain>
mailbox: <hishome>/Maildir/
gecos: <His name>
host: correo
description: <his name>
userPassword:: <apassword>
shadowLastChange: 13057

	and in the slave:

dn: uid=<anuid>,<user base dn>
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: CourierMailAccount
cn: <His name>
uid: <anuid>
uidNumber: 100253
gidNumber: 1001
homeDirectory: <his home>
loginShell: /bin/bash
mail: <anuid>@<mydomain>
mailbox: <hishome>/Maildir/
gecos: <His name>
host: correo
description: <his name>
userPassword:: <apassword>
shadowLastChange: 13057

	So they are the same. Maybe the problem are with internal attributes,
where there are differences. The master's entry:

structuralObjectClass: account
entryUUID: 5089f66c-8f28-1029-86db-b04328147150
creatorsName: cn=admin,<base dn>
createTimestamp: 20050722181523Z
entryCSN: 20051001171631Z#000001#00#000000
modifiersName: cn=admin,<base dn>
modifyTimestamp: 20051001171631Z
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

	and the slave's one:

structuralObjectClass: account
entryUUID: 5089f66c-8f28-1029-86db-b04328147150
creatorsName: cn=admin,<base dn>
createTimestamp: 20050722181523Z
entryCSN: 20050905090218Z#000001#00#000000
modifiersName: cn=admin,<base dn>
modifyTimestamp: 20050905090218Z
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

	So it seems that the problem is that the user I have to replicate
between servers is not allowed to write some attributes. But I have this
ACLs:

access to attr=description
        by dn.exact="<dn of replica user>" write
        by dn.exact="<other dn>" write
        by dn.exact="<other dn>" read
        by dn.exact="<other dn>" read
        by dn.exact="<other dn>" read
        by self write
        by * none
access to attr=userPassword
        by dn.exact="<dn of replica user>" write
        by dn.exact="<other dn>" write
        by dn.exact="<other dn>" read
        by self write
        by anonymous auth
        by * none
access to attr=sambaLMPassword
        by dn.exact="<dn of replica user>" write
        by dn.exact="<other dn>" write
        by self write
        by anonymous auth
        by * none
access to attr=sambaNTPassword
        by dn.exact="<dn of replica user>" write
        by dn.exact="<other dn>" write
        by self write
        by anonymous auth
        by * none
access to *
        by dn.exact="<dn of replica user>" write
        by dn.exact="<other dn>" write
        by dn.exact="<other dn>" read
        by dn.exact="<other dn>" read
        by dn.exact="<other dn>" read
        by dn.exact="<other dn>" read
        by self write
        by * read

	so I think the user has all the permissions needed to be able to update
any attribute.

	Any help with this problem?

	Thanks in advance


-- 
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información     _o)
y las Comunicaciones Aplicadas (ATICA)    / \\
http://www.um.es/atica                  _(___V
Tfo: 968367590
Fax: 968398337