#48371 lib389 should not enforce localhost.localdomain with weaker host checks
Closed: wontfix None Opened 5 years ago by firstyear.

The utility of the localhost.localdomain check is diminshed given that we can now setup instances with weaker host checks. Additionally, the hostname checks really only matter for GSSAPI instances.

A lot of our tools try to initialise lib389 and contact a ds instance but can't because of this enforcement. We should relax this, and let either:

  • setup-ds.pl worry about it
  • let the admin work it out.

Hi William,

there is one failure three times with your patch on RHEL-7.2-20151030.0 x86_64:

================================================= test session starts =================================================
platform linux2 -- Python 2.7.5 -- py-1.4.27 -- pytest-2.7.0 -- /usr/bin/python
rootdir: /root/lib389, inifile:
collected 8 items

lib389/tests/utils_test.py::test_formatInfData FAILED
lib389/tests/utils_test.py::test_formatInfData_withadmin FAILED
lib389/tests/utils_test.py::test_formatInfData_withconfigserver FAILED

====================================================== FAILURES =======================================================
_______ test_formatInfData ________

def test_formatInfData():
    ret = formatInfData({
        'hostname': 'localhost.localdomain',
        'user-id': 'dirsrv',
        'group-id': 'dirsrv',
        'ldap-port': 12345,
        'root-dn': 'cn=directory manager',
        'root-pw': 'password',
        'server-id': 'dirsrv',
      'suffix': 'o=base1',


args = {'CFGSUFFIX': 'o=NetscapeRoot', 'group-id': 'dirsrv', 'hostname': 'localhost.localdomain', 'ldap-port': 12345, ...}

def formatInfData(args):
    """Return the .inf data for a silence setup via setup-ds.pl.

        args = {
            # new instance values
            newhost, newuserid, newport, SER_ROOT_DN, newrootpw, newsuffix,

            # The following parameters require to register the new instance
            # in the admin server
            have_admin, cfgdshost, cfgdsport, cfgdsuser,cfgdspwd, admin_domain

            InstallLdifFile, AddOrgEntries, ConfigFile, SchemaFile,

            # Setup the o=NetscapeRoot namingContext

        @see https://access.redhat.com/site/documentation/en-US/
        FullMachineName= dir.example.com
        SuiteSpotUserID= nobody
        SuiteSpotGroup= nobody
        AdminDomain= example.com
        ConfigDirectoryAdminID= admin
        ConfigDirectoryAdminPwd= admin
        ConfigDirectoryLdapURL= ldap://dir.example.com:389/o=NetscapeRoot

        SlapdConfigForMC= Yes
        UseExistingMC= 0
        ServerPort= 389
        ServerIdentifier= dir
        Suffix= dc=example,dc=com
        RootDN= cn=Directory Manager
        RootDNPwd= password
        AddSampleEntries= No

        Port= 9830
        ServerAdminID= admin
        ServerAdminPwd= admin

    args = args.copy()

    content = ("[General]" "\n")
    content += ("FullMachineName= %s\n" % args[SER_HOST])
    content += ("SuiteSpotUserID= %s\n" % args[SER_USER_ID])
    content += ("nSuiteSpotGroup= %s\n" % args[SER_GROUP_ID])
  content += ("StrictHostCheck= %s\n" % args[SER_STRICT_HOSTNAME_CHECKING])

E KeyError: 'strict_hostname_checking'

lib389/utils.py:677: KeyError

Also, I couldn't run '''lib389/tests/krb5_create_test.py''', even without the patch. It just hangs in some kind of loop. But it may be only my problem with installation, because I run tests as root from the root HOME directory. An investigation is required, I'll try to resolve this.

Updated: the same "hang and loop" thing happens if run with sudo from regular user repo directory. It looks like, even if you run with py.test, it doesn't go to fixture, but run there:

-> for name in dir(holderobj):
-> obj = getattr(holderobj, name, None)
-> if not callable(obj):
-> continue
It runs through a lot of objects(may be the whole system) and finally(after 20 minutes) gives a PASS result(with your patch it PASSes too)

Fix for the utils test issue you are seeing. The krb issue seems unrelated, so either open a new ticket, or email me about it and we can work it out.

Replying to [comment:4 firstyear]:

Fix for the utils test issue you are seeing. The krb issue seems unrelated, so either open a new ticket, or email me about it and we can work it out.

Thank you, all tests have passed.

I mentioned the krb issue, because when it fails, I can't be sure how your patch affect this test case. When I saw that it passed, I had stopped worrying. :)

No issue mate, thanks heaps for the review. I appreciate your diligence.

commit b2600db5198daca7bb372ced1cf7b90aa62b69fa
To ssh://git.fedorahosted.org/git/389/lib389.git
a9fb88f..9624cd1 master -> master

Metadata Update from @firstyear:
- Issue assigned to firstyear
- Issue set to the milestone: CI test 1.0

4 years 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/1702

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 (was: Fixed)

a year ago

Login to comment on this ticket.