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
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)
Metadata Update from @tbordaz: - Issue set to the milestone: 1.3.7 backlog (was: 1.4 backlog)
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to None - Issue set to the milestone: 1.4 backlog (was: 1.3.7 backlog)
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4.5 (was: 1.4 backlog)
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.
subscribe
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)
Login to comment on this ticket.