#9170 [Tracker] NIghtly test failure (@389ds/389-ds-base-nightly) in server installation
Closed: fixed by frenaud. Opened by frenaud.

The nightly tests with the nightly build of 389-ds are failing during IPA server installation, in the discovery phase of ipa-client-install. See for instance PR #1764 with the folllowing test: automember (Report, logs):

...
Configuring client side components
Using existing certificate '/etc/ipa/ca.crt'.
Skip master.ipa.test: not an IPA server
Failed to verify that master.ipa.test is an IPA Server.
This may mean that the remote server is not up or is not reachable due to network or firewall settings.
Please make sure the following ports are opened in the firewall settings:
     TCP: 80, 88, 389
     UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working properly after enrollment:
     TCP: 464
     UDP: 464, 123 (if NTP enabled)
The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information
This program will set up IPA client.
Version 4.10.0.dev
Configuration of client side components failed!
The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information

The code is doing the equivalent of the following LDAP command to check if the server is an IPA server:

LDAPTLS_CACERT=/etc/ipa/ca.crt ldapsearch -x -ZZ -b dc=ipa,dc=test -s base  "(info=IPA*)"

and the command doesn't find any entry. Note that without the -s base option, the entry is properly returned:

# LDAPTLS_CACERT=/etc/ipa/ca.crt ldapsearch -x -ZZ -b dc=ipa,dc=test  "(info=IPA*)"
# extended LDIF
#
# LDAPv3
# base <dc=ipa,dc=test> with scope subtree
# filter: (info=IPA*)
# requesting: ALL
#
# ipa.test
dn: dc=ipa,dc=test
objectClass: top
objectClass: domain
objectClass: pilotObject
objectClass: domainRelatedObject
objectClass: nisDomainObject
dc: ipa
info: IPA V2.0
associatedDomain: ipa.test
nisDomain: ipa.test
# search result
search: 3
result: 0 Success
# numResponses: 2
# numEntries: 1

Companion issue logged against 389ds: https://github.com/389ds/389-ds-base/issues/5332

This is the same issue as seen in Fedora: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e9c10b569e

Issue fixed by 389-ds, see for instance a successful instance in PR #1797 with the test automember: Details

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

Metadata