search

389ds / 389-ds-base

The enterprise-class Open Source LDAP server for Linux
https://www.port389.org/
Other
211 stars 91 forks source link

DNA plugins can create invalid shared config entry #1704

Open 389-ds-bot opened 4 years ago

389-ds-bot commented 4 years ago

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/48373

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.

389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2016-05-13 00:55:04

Per triage, push the target milestone to 1.3.6.

389-ds-bot commented 4 years ago

Comment from mbabinsk at 2016-10-24 17:01:49

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?

389-ds-bot commented 4 years ago

Comment from tbordaz (@tbordaz) at 2016-10-24 17:59:43

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)"
389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2017-02-11 22:58:24

Metadata Update from @nhosoi:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2017-05-08 22:19:39

Metadata Update from @mreynolds389:

389-ds-bot commented 4 years ago

Comment from tbordaz (@tbordaz) at 2017-07-13 16:26:11

Metadata Update from @tbordaz:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2019-08-23 21:16:57

Metadata Update from @mreynolds389:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2020-05-27 16:32:03

Metadata Update from @mreynolds389: