#48373 DNA plugins can create invalid shared config entry
Closed: wontfix 2 months ago by spichugi. Opened 4 years ago by tbordaz.

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

3 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)

3 years ago

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

3 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)

a year ago

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

6 months ago

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/1704

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

2 months ago

Login to comment on this ticket.

Metadata