#48373 DNA plugins can create invalid shared config entry
Opened 3 years ago by tbordaz. Modified 4 months ago

At DS startup, DNA plugin creates a shared config entry (under 'dnaSharedCfgDN'). Like

dn: dnaHostname=<fqdn>+dnaPortNum=389,<dnaSharedCfgDN>
objectClass: dnaSharedConfig
objectClass: top
dnaHostname: <fqdn>
dnaPortNum: 389
dnaSecurePortNum: 636
dnaRemainingValues: 200000

The entry is created at the condition either normal and/or secure port are set.
It tests the secure port<>0, but also test 'nsslapd-security: off'.

If normal/secure port are disabled, it creates an entry like:

dn: dnaHostname=<fqdn>+dnaPortNum=0,<dnaSharedCfgDN>
objectClass: dnaSharedConfig
objectClass: top
dnaHostname: <fqdn>
dnaPortNum: 0
dnaSecurePortNum: 636
dnaRemainingValues: 200000

This remaining values of that server will never be updated so there is a risk that this server will always be targeted for range requests.


Per triage, push the target milestone to 1.3.6.

After setting up replica against IPA master I can now observe 4 entries in cn=posix-ids subtree: https://paste.fedoraproject.org/460223/06770147/

Please note that in the case of replica (replica1.ipa.test) none of the two entries are configured properly (one is missing dnaRemoteBindMethod and dnaRemoteConnProtocol attributes, one has dnaPortNum set to 0).

Is there some risk that the range allocation will not work correctly one replica1?

Replying to [comment:4 mbabinsk]:

After setting up replica against IPA master I can now observe 4 entries in cn=posix-ids subtree: https://paste.fedoraproject.org/460223/06770147/

Please note that in the case of replica (replica1.ipa.test) none of the two entries are configured properly (one is missing dnaRemoteBindMethod and dnaRemoteConnProtocol attributes, one has dnaPortNum set to 0).

Is there some risk that the range allocation will not work correctly one replica1?

You are right the result is that replica1 will not be able to connect to master1 to gather new range.
A possibility (unlikely) is that it is a transient result and eventually update to set SASL/GSSAPI on 'dnaHostname=replica1.ipa.test+dnaPortNum=389,xxx' will be received.

An other possibility is that dsinstall.py:update_dna_shared_config retrieved the 'dnaHostname= replica1.ipa.test' just at the time it existed the portNum=0 but before portNum:389 existed.
It could be verified looking in 'replica1' DS access log for the RESULT of

{{{
SRCH scope=one base="cn=posix-ids,cn=dna,cn=ipa,cn
=etc,dc=ipa,dc=test" "(dnaHostname=replica1.ipa.test)"

}}}

Metadata Update from @nhosoi:
- Issue assigned to tbordaz
- Issue set to the milestone: 1.3.6.0

2 years ago

Metadata Update from @mreynolds:
- Custom field component reset (from Server - DNA Plug-in)
- Issue close_status updated to: None
- Issue set to the milestone: 1.4 backlog (was: 1.3.6.0)

2 years ago

Metadata Update from @tbordaz:
- Issue set to the milestone: 1.3.7 backlog (was: 1.4 backlog)

2 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to None
- Issue set to the milestone: 1.4 backlog (was: 1.3.7 backlog)

4 months ago

Login to comment on this ticket.

Metadata