On ma, 15 helmi 2021, lejeczek via FreeIPA-users wrote:
On 04/01/2021 17:46, Alexander Bokovoy wrote:
On ma, 04 tammi 2021, lejeczek via FreeIPA-users wrote:
Hi guys.
I'm trying to setup a first master during which I get:
...
 [7/7]: configuring ipa-dnskeysyncd to start on boot
Done configuring DNS key synchronization service
(ipa-dnskeysyncd).
Restarting ipa-dnskeysyncd
Restarting named
Named service failed to start (CalledProcessError(Command
['/bin/systemctl', 'restart', 'named-pkcs11.service'] returned
non-zero exit status 1: 'Job for named-pkcs11.service failed
because a timeout was exceeded.\nSee "systemctl status
named-pkcs11.service" and "journalctl -xe" for details.\n'))
...
and that is the only error from the setup which seemingly
continues and completes successfully:
...
Using existing certificate '/etc/ipa/ca.crt'.
Client hostname: c8kubermaster1.private.openshift.c8
Realm: PRIVATE.OPENSHIFT.C8
DNS Domain: private.openshift.c8
IPA Server: c8kubermaster1.private.openshift.c8
BaseDN: dc=private,dc=openshift,dc=c8
Configured sudoers in /etc/authselect/user-nsswitch.conf
Configured /etc/sssd/sssd.conf
Systemwide CA database updated.
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Could not update DNS SSHFP records.
SSSD enabled
Configured /etc/openldap/ldap.conf
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring private.openshift.c8 as NIS domain.
Client configuration complete.
The ipa-client-install command was successful
DNS query for c8kubermaster1.private.openshift.c8. 1 failed: The
DNS operation timed out after 30.000322580337524 seconds
unable to resolve host name c8kubermaster1.private.openshift.c8.
to IP address, ipa-ca DNS record will be incomplete
==============================================================================
Setup complete
Next steps:
   1. You must make sure these network ports are open:
      TCP Ports:
       * 80, 443: HTTP/HTTPS
       * 389, 636: LDAP/LDAPS
       * 88, 464: kerberos
       * 53: bind
      UDP Ports:
       * 88, 464: kerberos
       * 53: bind
       * 123: ntp
   2. You can now obtain a kerberos ticket using the command:
'kinit admin'
     This ticket will allow you to use the IPA tools (e.g.,
ipa user-add)
     and the web user interface.
Be sure to back up the CA certificates stored in /root/cacert.p12
These files are required to create replicas. The password for
these
files is the Directory Manager password
The ipa-server-install command was successful
Yet, very first reboot and ipa.service fails to start, but before
that reboot if I
-> $ systemctl restart named-pkcs11.service
I takes rather long 10 or so secons and journal shows
...
LDAP configuration synchronization failed: socket is not connected
...
but socket is there: /var/run/slapd-PRIVATE-OPENSHIFT-C8.socket
More from named's journal:
...
esolver priming query complete
LDAP error: Can't contact LDAP server: ldap_sync_poll() failed
ldap_syncrepl will reconnect in 60 seconds
GSSAPI client step 1
GSSAPI client step 1
GSSAPI client step 1
GSSAPI client step 2
successfully reconnected to LDAP server
LDAP configuration for instance 'ipa' synchronized
GSSAPI client step 1
GSSAPI client step 1
GSSAPI client step 1
GSSAPI client step 2
LDAP data for instance 'ipa' are being synchronized, please ignore
message 'all zones loaded'
Is it named-pkcs11 looking for wrong bits or something not good
with dirsrv or .. maybe something else... would you anybody know?
It looks like 389-ds LDAP server start takes quite some time before
it
starts listening on the LDAPI socket, so first attempt to connect by
bind-dyndb-ldap driver fails.
Not sure it is a problem with the amount of resources available on
this
system (a VM? a container? How many CPUs available? Disk is slow?
etc).
Eventually bind-dyndb-ldap succeeds on re-try so it might only be a
too
fast parallel startup for some components and not the other.
If this happens later, when 389-ds already started, there might be
another issue -- if it is really slow to respond on LDAPI
connection,
may be LDAP server was already swapped out by something more memory
hungry? In general, it would be good to look at the overall picture
with
the workload you have on that system.
I think the culprit here is
ipa-server-4.9.0-1.module_el8.4.0+639+a88aab78.x86_64
ipa-server-4.8.7-13.module_el8.3.0+606+1e8766d7.x86_64 seems to be
free from that problem.
So guys - if you are on Centos Stream be aware - ipa-server-4.9.0
comes with centos-stream-repos-8-2.el8.noarch - before you add those
repos to your setups.
I do not see this problem at all, nor on CentOS 8 Stream with 4.9.0-1,
nor on RHEL 8.4 nightlies with extensive set of tests.
If you'd show exact instructions how you reached this state, it would be
easier to reproduce.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
