#47667 Allow nsDS5ReplicaBindDN to be a group DN
Closed: Fixed None Opened 6 years ago by nkinder.

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.


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

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

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?

There are already many plugins handling group changes: aci, referint, memberof,.. and now repliction plugin. Maybe this can be unified/simplified.

+1

For the current ticket I will go for the interval option if there is no objection

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

In DEBUG mode, the fix may trigger an ASSERT. {{{ (gdb) where #0 0x0000003bee035935 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x0000003bee0370e8 in __GI_abort () at abort.c:91 #2 0x0000003c53010eba in PR_Assert (s=0x7fab8b8a7d5a "list && vs", file=0x7fab8b8a7d00 "../workspaces/389-master-branch/ds/ldap/servers/plugins/replication/repl5_updatedn_list.c", ln=262) at ../../../nspr/pr/src/io/prlog.c:554 #3 0x00007fab8b8716a7 in replica_updatedn_list_add_ext (list=0x7fab40003890, vs=0x0, group_update=1) at ../workspaces/389-master-branch/ds/ldap/servers/plugins/replication/repl5_updatedn_list.c:262 #4 0x00007fab8b87120f in replica_groupdn_list_new (vs=0x0) at ../workspaces/389-master-branch/ds/ldap/servers/plugins/replication/repl5_updatedn_list.c:130 #5 0x00007fab8b85a8d3 in _replica_init_from_config (r=0x7fab40003ce0, e=0x7fab40000f40, errortext=0x7fab737f9600 "") at ../workspaces/389-master-branch/ds/ldap/servers/plugins/replication/repl5_replica.c:1930 #6 0x00007fab8b857335 in replica_new_from_entry (e=0x7fab40000f40, errortext=0x7fab737f9600 "", is_add_operation=1) at ../workspaces/389-master-branch/ds/ldap/servers/plugins/replication/repl5_replica.c:224 #7 0x00007fab8b85fa38 in replica_config_add (pb=0x7fab737fdae0, e=0x7fab40000f40, entryAfter=0x0, returncode=0x7fab737f9574, errorbuf=0x7fab737f9600 "", arg=0x0) at ../workspaces/389-master-branch/ds/ldap/servers/plugins/replication/repl5_replica_config.c:246 #8 0x00007fab91088894 in dse_call_callback (pdse=0x22cf390, pb=0x7fab737fdae0, operation=16, flags=1, entryBefore=0x7fab40000f40, entryAfter=0x0, returncode=0x7fab737f9574, returntext=0x7fab737f9600 "") at ../workspaces/389-master-branch/ds/ldap/servers/slapd/dse.c:2645 #9 0x00007fab91087b9d in dse_add (pb=0x7fab737fdae0) at ../workspaces/389-master-branch/ds/ldap/servers/slapd/dse.c:2356 #10 0x00007fab9106a85e in op_shared_add (pb=0x7fab737fdae0) at ../workspaces/389-master-branch/ds/ldap/servers/slapd/add.c:735 #11 0x00007fab91069784 in do_add (pb=0x7fab737fdae0) at ../workspaces/389-master-branch/ds/ldap/servers/slapd/add.c:258 #12 0x0000000000415d1c in connection_dispatch_operation (conn=0x7fab88193410, op=0x272b880, pb=0x7fab737fdae0) at ../workspaces/389-master-branch/ds/ldap/servers/slapd/connection.c:645 #13 0x0000000000417d4d in connection_threadmain () at ../workspaces/389-master-branch/ds/ldap/servers/slapd/connection.c:2534 #14 0x0000003c53028b46 in _pt_root (arg=0x2702780) at ../../../nspr/pr/src/pthreads/ptthread.c:204 #15 0x0000003bee407d14 in start_thread (arg=0x7fab737fe700) at pthread_create.c:309 #16 0x0000003bee0f168d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 }}} I believe if a replica does not contain nsDS5ReplicaBindDnGroup, replica_updatedn_list_add_ext may be called with a null valueset. It is fine in non debug mode as the loop will exit immediately but in debug mode it asserts

thanks for the update, Mark already had found this and it was forgotten, should be fixed

$ 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

Metadata Update from @rmeggins:
- Issue assigned to lkrispen
- Issue set to the milestone: 1.3.3 - 4/14 (April)

3 years ago

Login to comment on this ticket.

Metadata