Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1029640
Description of problem: In larger, more complex IPA environments where Replica's are not all interconnected, we are missing some dirsrv dna plugin configurations to allow a directory server to lookup ranges on other servers once exhausted. Per bug#971111 under comment 7: https://bugzilla.redhat.com/show_bug.cgi?id=971111#c7 We need IPA servers to support the following: objectClass: dnaPluginConfig dnaRemoteBindDN dnaRemoteBindCred objectClass: dnaSharedConfig dnaRemoteBindMethod (SIMPLE, SSL, SASL/DIGEST-MD5, or SASL/GSSAPI) dnaRemoteConnProtocol: (LDAP, TLS, or SSL) The 389 Devs can provide more details there. If we do not have this, we can see problems adding users/groups once the uid/gid range is exhausted. This allows an IPA server to get a UID/GID from a server with an available range. Bug #971111 covers the DS side of the fix needed to support this configuration. Version-Release number of selected component (if applicable): 389-ds-base-1.3.1.6-8.el7.x86_64 How reproducible: seen often (but not always) in automated testing. Steps to Reproduce: 1. setup IPA env m1-m2-m3 2. add user on m3 Actual results: ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. Expected results: user successfully added to ipa Additional info:
Moving to next month iteration.
As noted in https://bugzilla.redhat.com/show_bug.cgi?id=1029640#c5, we will do automation in IPA later, when DS support it: https://fedorahosted.org/389/ticket/47667
Moving back to NEEDS_TRIAGE.
Releasing old tickets.
Should be easy when #3416 is fixed.
Instead of #3416, we could use cn=replication managers,cn=sysaccounts,cn=etc,SUFFIX that was added in FreeIPA 4.2.
cn=replication managers,cn=sysaccounts,cn=etc,SUFFIX
Topology plugin was postponed, this functionality should be postponed also as it depends on the group managed by the Topology functionality.
See #4302 for details.
this requires a fix in the DNA plugin to manage the binddngroups: https://fedorahosted.org/389/ticket/48258
I have a fix for this and the only needed addition to fix this ticket is to add remoteBindMethod and protocol to the shared config entries, eg:
dn: dnaHostname=vm-179.abc.idm.lab.eng.brq.redhat.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com dnaRemainingValues: 50000 objectClass: dnaSharedConfig objectClass: top dnaHostname: vm-179.abc.idm.lab.eng.brq.redhat.com dnaPortNum: 389 dnaSecurePortNum: 636 dnaRemoteBindMethod: SASL/GSSAPI dnaRemoteConnProtocol: LDAP
Replying to [comment:14 lkrispen]:
this requires a fix in the DNA plugin to manage the binddngroups: https://fedorahosted.org/389/ticket/48258 I have a fix for this and the only needed addition to fix this ticket is to add remoteBindMethod and protocol to the shared config entries, eg: {{{ dn: dnaHostname=vm-179.abc.idm.lab.eng.brq.redhat.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com dnaRemainingValues: 50000 objectClass: dnaSharedConfig objectClass: top dnaHostname: vm-179.abc.idm.lab.eng.brq.redhat.com dnaPortNum: 389 dnaSecurePortNum: 636 dnaRemoteBindMethod: SASL/GSSAPI dnaRemoteConnProtocol: LDAP }}}
{{{ dn: dnaHostname=vm-179.abc.idm.lab.eng.brq.redhat.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com dnaRemainingValues: 50000 objectClass: dnaSharedConfig objectClass: top dnaHostname: vm-179.abc.idm.lab.eng.brq.redhat.com dnaPortNum: 389 dnaSecurePortNum: 636 dnaRemoteBindMethod: SASL/GSSAPI dnaRemoteConnProtocol: LDAP }}}
There is something that I am missing here. According to http://directory.fedoraproject.org/docs/389ds/design/dna-plugin.html, the server that needs to extent its range of allocation is using the (binddn/groupdn, credential) defined in the replica agreement to connect to the server with large remaining values. Why not using the bindmethod,protocol defined as well in the replica agreement ?
I updated the install scripts, so that it adds bindmethod/protocol in the shared config entry of the host when this entry is created. With those attributes in the shared config entry, a replica is able to request an extended range to an other replica. This even if the requesting replica has no replica_agreement to the requested replica
Now DNA plugin, recreates at startup the shared config entry of the host. This shared config entry is based on the shared config base entry (e.g. cn=posix-ids,cn=dna,cn=ipa,cn=etc,SUFFIX) so this is where the bindmethod/protocol should be set. A constraint is that all shared config hosts will share the same bindmethod/protocol
The second point of my previous update is incomplete. At startup the entry is recreated. Since https://fedorahosted.org/389/ticket/47779, the recreation works fine especially regarding the attributes previously set in the shared entry.
Now there is a corner case when the shared config entry contains an exhausted range (https://fedorahosted.org/389/ticket/48362). In that case, the entry is recreated with basic settings and some attributes may be missing (especially method/protocol).
The workarounds (see 48362) are likely not applicable for IPA, that needs to create an instance with exhausted range.
attachment 0001-DNA-shared-config-entry-need-to-define-method-protoc.patch
The attached patch is successful after updating 389-ds with https://fedorahosted.org/389/ticket/48362.
The attached patch has been tested in a full install scenario and needs to be tested with upgrade
attachment 0001-DNA-using-service.patch
attached patch is tested on full install and upgrade. It also differs from the previous moving the upgrade-dna script in to the service.py file
blocked by https://fedorahosted.org/389/ticket/48362 Also related to https://fedorahosted.org/freeipa/ticket/5510 (aka https://fedorahosted.org/389/ticket/48373)
Not a blocker for 4.3 release.
master:
ipa-4-3:
Metadata Update from @mkosek: - Issue assigned to tbordaz - Issue set to the milestone: FreeIPA 4.3.1
Login to comment on this ticket.