On Thursday 25 September 2008 11:36:41 Maurizio Lo Bosco wrote:
I think that some access rules are missing for the user, something like contextCSN in the user dn.
The only requirement is that the DN that is used as the binddn in the syncrepl statement on the consumer must have read access to all the attributes that are required to be replicated to the consumer, plus the entryCSN/entryUUID on all the entries that must be replicated, plus the contextCSN on the basedn. Additionally, the DN must have a sufficiently large "quota" (time/size limits) to retrieve the entire contents that matches the filter used in the consumer configuration.
I have a single master server replicating with syncrepl a consumer openldap. The same version 2.3.30-5 of openldap is used on every server on the same OS debian etch.
The user for the syncrepl has full read access to every entry in the provider
You haven't provided enough of your configuration to prove this. Since this is the most likely cause of your problems, you should either ensure this yourself, or provide enough information for people on this list to point out the mistakes ...
so I think thera are no problems for the replication, in fact if I modify the attribute with a different user the replace is correctly replicated.
With the same ACLs. Somehow I doubt this.
The problem is with the user making the replace of the attribute.
As far as I know about replication, this is impossible.
Since the Radius User must only write a single attribute I have just inserted the rule for the single attribute
access to attrs=RASPassword [...] by dn="cn=Radius User,ou=SysAccount,o=engineering,c=it" write
This way I can change the attribute using
ldapmodify -x -f cambia_raspwd.ldif -D "cn=Radius User,ou=SysAccount,o=engineering,c=it" -W
but the replace is not propagated to the consumer.
If I insert a _read_ access for the Radius User
What is the Radius User used for ? Maybe it is also the syncrepl consumer's DN ? Who knows, you don't provide enough information.
to the tree containing the entries whose RASPassword is going to be changed
access to dn.subtree="ou=Persone,o=Engineering,c=IT" [...] by dn="cn=Radius User,ou=SysAccount,o=engineering,c=it" read
the change on the attribute is correctly replicated to the consumer!
I don't know why but without the read access granted to the Radius User the replace modify is not propagated to the consumers. What am I missing?
You haven't provided the context for this access control entry. You may have added it before the rule allowing your consumer's DN read access to all attributes (we can't tell since you don't provide the rest of your access controls), so since you don't have a clause for your consumer's DN (I assume it is not the rootdn, and also not "cn=Radius User", but since you don't provide your consumer configuration I can't do anything but make assumptions) in the access rule above, this could be the reason why your consumer does not have read access to the affected entries/attributes.
Now, if you don't want real help, keep posting cryptic descriptions with incomplete configuration. I'm not prepared to guess your configuration any further.
Regards, Buchan