We should allow nsDS5ReplicaBindDN to handle group DNs. This would allow one to have a group of replication users in the replicated tree, which simplifies certain use-cases.
FreeIPA uses GSSAPI for replication, so the replication users exist in the replicated tree. Each replica uses a separate replication user. The DNA plug-in is also used by IPA, which utilizes the replication bind DNs for authorization when receiving a range transfer request extended operation. Being able to use a group DN simplifies the configuration changes that need to be made when a new replica is added. Consider the following 3 master replication topology:
A <-> B <-> C
If a new master D is added that is only connected to master C, we would need to update nsDS5ReplicaBindDN on A, B, and C to allow DNA range transfers between D and all other masters with the current behavior. If a group of replication users from the replicated tree is used instead, we could simply add the new replication bind DN to the group and it would be replicated out to the rest of the topology.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1052754
Started to work on this ticket and I am not sure what is the best way to implement it. Right now the nsDS5ReplicaBindDN from the Replica config entry is stored in a hash table and in a replica session the bind dn is looked up to see if it is an allowed replica binddn. If we allow groups then we need always to read the entry, check its objectclass and then add the members (recursively ?) to the hash table. An other option would be to introduce a new config parameter eg nsDS5ReplicaBindGroup and only if it is present do the membership lookup and add the DNs to the same hash table.
Replying to [comment:7 lkrispen]:
If we allow groups then we need always to read the entry, check its objectclass and then add the members (recursively ?) to the hash table. An other option would be to introduce a new config parameter eg nsDS5ReplicaBindGroup and only if it is present do the membership lookup and add the DNs to the same hash table.
That seems like a good idea, as it won't affect those who are not using the new nsDS5ReplicaBindGroup.
We could avoid doing the membership lookup and hash table maintenance everytime by having the hash table be a cache of sorts. We would only reload the group if a configurable amount of time has passed.
I will use the new attr nsDS5ReplicaBindGroup to enable this feature, if it is to be used in a deployment the Replica opbject needs to be changed anyway: replace teh norm,al bind dn by a group, so it can also add this new attr and it is more clean and doesn't impact any deployments not using it.
The problem of tracking changes to the group is more complex. Ideally a change of the group should immediately trigger a rebuild of the binddns, but checking for a group change at every replication bind is too much overhead. Other alternatives are: - Do like the aci plugin register a postop plugin function for mods or deletes and check if the update is modifiying a group, if so change the signature of the list of replication bind dns - Accept a delay in updates, eg specify an interval after which a replication bind should check if the bindngroup has changed
There are already many plugins handling group changes: aci, referint, memberof,.. and now repliction plugin. Maybe this can be unified/simplified.
For the current ticket I will go for the interval option if there is no objection
attachment 0001-Ticket-47667-Allow-nsDS5ReplicaBindDN-to-be-a-group-.patch
Replying to [comment:9 lkrispen]:
I will use the new attr nsDS5ReplicaBindGroup to enable this feature, if it is to be used in a deployment the Replica opbject needs to be changed anyway: replace teh norm,al bind dn by a group, so it can also add this new attr and it is more clean and doesn't impact any deployments not using it. The problem of tracking changes to the group is more complex. Ideally a change of the group should immediately trigger a rebuild of the binddns, but checking for a group change at every replication bind is too much overhead. Other alternatives are: - Do like the aci plugin register a postop plugin function for mods or deletes and check if the update is modifiying a group, if so change the signature of the list of replication bind dns
The problem of tracking changes to the group is more complex. Ideally a change of the group should immediately trigger a rebuild of the binddns, but checking for a group change at every replication bind is too much overhead. Other alternatives are: - Do like the aci plugin register a postop plugin function for mods or deletes and check if the update is modifiying a group, if so change the signature of the list of replication bind dns
This is the way I would prefer.
Accept a delay in updates, eg specify an interval after which a replication bind should check if the bindngroup has changed
How would someone force a change to take effect immediately?
+1
Sorry I missed this, but I would prefer the other approach mentioned above.
How would someone force a change to take effect immediately? <<< With the interval based approach the list of binddns based on groups will only be rebuilt once the interval has passed. If one wants to enforce an immediate rebuild it would be possible to modify the replica object:
replace: nsDS5ReplicaBindGroup nsDS5ReplicaBindGroup: <current values>
this triggers a change in the replica and an immediate rebuild.
In my opinion this is a feature which will be used in very limited use cases, the groups will not be very dynamic, probaly only if another server with anew bindDN is added. I would like to avoid the overhead of having another pluging interfering with every mod and checking for relevant group changes.
Ok. I see you opened https://fedorahosted.org/389/ticket/47765 for the general group management problem.
ack.
$ git merge 47667 Updating 48cd960..6bfb761 Fast-forward ldap/servers/plugins/replication/repl5.h | 12 +++++++++++- ldap/servers/plugins/replication/repl5_replica.c | 136 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------- ldap/servers/plugins/replication/repl5_replica_config.c | 45 +++++++++++++++++++++++++++++++++++++++++---- ldap/servers/plugins/replication/repl5_updatedn_list.c | 119 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- ldap/servers/plugins/replication/repl_globals.c | 4 ++++ 5 files changed, 284 insertions(+), 32 deletions(-) $ git push origin master Counting objects: 21, done. Delta compression using up to 4 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (11/11), 4.36 KiB, done. Total 11 (delta 9), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 48cd960..6bfb761 master -> master
thanks for the update, Mark already had found this and it was forgotten, should be fixed
attachment 0001-fix-assertion-failure-introduced-with-fix-for-ticket.patch
$ git merge 47667b Updating 634250f..f06f76e Fast-forward ldap/servers/plugins/replication/repl5_updatedn_list.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) $ git push origin master Counting objects: 13, done. Delta compression using up to 4 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 690 bytes, done. Total 7 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 634250f..f06f76e master -> maste
Replying to [comment:11 lkrispen]:
How would someone force a change to take effect immediately? <<< With the interval based approach the list of binddns based on groups will only be rebuilt once the interval has passed. If one wants to enforce an immediate rebuild it would be possible to modify the replica object: replace: nsDS5ReplicaBindGroup nsDS5ReplicaBindGroup: <current values> this triggers a change in the replica and an immediate rebuild. In my opinion this is a feature which will be used in very limited use cases, the groups will not be very dynamic, probaly only if another server with anew bindDN is added. I would like to avoid the overhead of having another pluging interfering with every mod and checking for relevant group changes.
Very soprry to come late to this, I was not CCed in the bug, but one of the reason IPA reqwuested ther feature is to allow to create a New host, add it to the masters group and immediately replicate. If there is a delay in checking the groups it means we will get random failures ?
well you will not get random failures, the replication bind could fail until the interval is passed, it will be retried and finally succeed. you can set the interval to 0 or force a rebuild by a dummy mod like described above.
or you could request an enhancement to trigger the rebuild if the group is modified.
I hesitated to add this task to the replication plugin, but I' wonder if this couldn't be handled by the topology plugin. The Bind group could live in the shared config area and every update trigger a rebuild
there are two problems with the fix:
the parameter checkInterval doesn'T check for incorrect values ans should be single valued only.
the group replace after a checkup is incorrect, patch attachhed. At the moment group changes require restart to get effective
attachment 0001-use-correctly-group_replace-if-groups-are-checked-fo.patch
Metadata Update from @rmeggins: - Issue assigned to lkrispen - Issue set to the milestone: 1.3.3 - 4/14 (April)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1004
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.