replies are inline.
On 05/06/2015 02:22 PM, thierry bordaz wrote:
Sorry I didn't know you can MOD_DEL a particular value (I'm LDAP noob I
know). Will fix this.
On 05/06/2015 01:54 PM, Martin Babinsky wrote:
The attached patch tries to fix
After discussion with Thierry we concluded that while this issue is
more complex than it seems, the transition from REPLACE to DEL/ADD
operations when updating nsDS5ReplicaId should suffice for this ticket.
Few comments, you are using MOD_DEL 'replicaID' with None value. So this
is going to delete all previous values and it should be equivalent to a
I was thinking you wanted to retrieve the id_value and call MOD_DEL
'replicaID' <current_value>. So that if by the time you fetched the
replicaId, an other replica updated the replicaId, the MOD_DEL/MOD_ADD
would fail and you need a new iteration.
AFAIK ReplicaId is single-valued (looking at the schema right now) so
this shouldn't be problem.
If replicaId was multi-valued and you want to make it single valued, you
may want to do create a more complex MOD (e.g. (ldap.MOD_DELETE,
'nsDS5ReplicaId', str(value1), (ldap.MOD_DELETE, 'nsDS5ReplicaId',
I studied the code in the master branch and IIUC (and please correct me
if I got this wrong) nsDS5ReplicaId attribute in
'cn=replication,cn=etc,$SUFFIX' represents replicaID of the _next_
replica that will be installed.
If it is updating successfully do you want to return 'retval' or
If several replicas try to update the replicaId of the master and the
current replicaId is 1000.
Replica1 successfully updates the replicaId and gets 1001 as the new value.
Replica2 successfully updates the replicaId and gets 1002.
The final value on master will be 1002, but replica1 will assum it is
1001. Is it a problem ?
So if a replica is installed, it sets the current value of
nsDS5ReplicaId as its replica ID (the function returns 'retval') and
then increments it in 'cn=replication,cn=etc,$SUFFIX' entry ('retval +
1' is written to master) so that the next installed replica fetches this
So the case you described should be the expected behavior. To change it
would require different patch IMHO.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code