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