#4026 [RFE] Add DNA Plugin config for dnaRemote support
Closed: Fixed None Opened 8 years ago by mkosek.

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.

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.

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
}}}

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.

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

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:

  • 6851e56 configure DNA plugin shared config entries to allow connection with GSSAPI

ipa-4-3:

  • 4531eae configure DNA plugin shared config entries to allow connection with GSSAPI

Metadata Update from @mkosek:
- Issue assigned to tbordaz
- Issue set to the milestone: FreeIPA 4.3.1

4 years ago

Login to comment on this ticket.

Metadata