freeipa

#9623 ipa-server-install error
Opened by felipetg. Modified

Open
Close Issue

Issue

I've got an error while trying to perform the test case Testcase basicIPA with HSM.

The command ipa-server-install -a $ADMIN_PASSWORD -p $DM_PASSWORD -r EXAMPLE.TEST -U --random-serial-numbers --token-name=ipa_token --token-library-path=/usr/lib64/pkcs11/libsofthsm2.so --token-password=$TOKEN_PASSWORD --skip-mem-check produces the log attached to this issue. The main error message is:

ERROR: Unable to access LDAP server: ldap://ipa.example.test:389

Steps to Reproduce

  1. Perform the configuration described in the test page (commands included in the attached log).
  2. Run ipa-server-install -a $ADMIN_PASSWORD -p $DM_PASSWORD -r EXAMPLE.TEST -U --random-serial-numbers --token-name=ipa_token --token-library-path=/usr/lib64/pkcs11/libsofthsm2.so --token-password=$TOKEN_PASSWORD --skip-mem-check

Actual behavior

Error during installation .

Expected behavior

Installation concludes with no errors.

Version/Release/Distribution

$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server

root@ipa:/home/felipe# rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server
freeipa-server-4.12.1-1.fc41.x86_64
freeipa-client-4.12.1-1.fc41.x86_64
package ipa-server is not installed
package ipa-client is not installed
389-ds-base-3.1.0-10.fc41.x86_64
package pki-ca is not installed
krb5-server-1.21.2-6.fc41.x86_64

Additional info:

I had to add --skip-mem-check due to a lack of more free RAM to assign to the VM. The VM's got 1G of RAM during config.

test_log.txt

CA-enabled installs need more than 1GB RAM, sorry.

Ok, I'll assign more RAM to the VM and try again.

Would be also good to look at the systemd journal -- perhaps it was memory pressure that caused 389-ds to be killed. But in general, CA variants need more memory, at least 2GB RAM.

A second installation attempt. I ran the commands suggested in here to reuse the previous system. I set the amount of RAM to 2G.

Still, I get an error. This is a chunk from journalctl: 

root@ipa:/home/felipe# journalctl -r
Jul 09 16:56:58 ipa.example.test systemd[1056]: Finished systemd-tmpfiles-clean.service - Cleanup of User's Temporary Files and Directories.
Jul 09 16:56:58 ipa.example.test systemd[1056]: Starting systemd-tmpfiles-clean.service - Cleanup of User's Temporary Files and Directories...
Jul 09 16:56:58 ipa.example.test systemd[1056]: Created slice background.slice - User Background Tasks Slice.
Jul 09 16:56:48 ipa.example.test chronyd[2143]: Selected source 193.149.0.217 (2.fedora.pool.ntp.org)
Jul 09 16:55:52 ipa.example.test audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=pcscd comm="systemd" exe>
Jul 09 16:55:52 ipa.example.test systemd[1]: pcscd.service: Deactivated successfully.
Jul 09 16:55:43 ipa.example.test chronyd[2143]: Selected source 162.159.200.1 (2.fedora.pool.ntp.org)
Jul 09 16:55:11 ipa.example.test ns-slapd[2653]: [09/Jul/2024:16:55:11.571584883 +0200] - ERR - ipa-topology-plugin - ipa_topo_util_get_replica_conf: cannot create re>
Jul 09 16:55:11 ipa.example.test ns-slapd[2653]: [09/Jul/2024:16:55:11.565139389 +0200] - ERR - ipa-topology-plugin - ipa_topo_util_get_replica_conf: server configura>
Jul 09 16:55:10 ipa.example.test audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=setroubleshootd comm="sy>
Jul 09 16:55:10 ipa.example.test systemd[1]: setroubleshootd.service: Deactivated successfully.
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=493 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=492 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=524 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=523 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=487 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=486 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=522 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=521 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=485 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=520 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=488 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=519 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=494 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=518 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=477 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=476 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=517 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=516 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=475 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=515 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=499 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=514 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=481 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=480 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=513 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=512 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=479 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=511 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=497 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=496 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=510 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=509 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=495 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=508 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=478 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=507 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=484 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=483 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=506 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=505 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=482 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=504 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=491 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=490 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=503 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=502 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=489 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=501 op=LOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=498 op=UNLOAD
Jul 09 16:55:10 ipa.example.test audit: BPF prog-id=500 op=LOAD
Jul 09 16:55:10 ipa.example.test audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.3-org.fedoraproj>
Jul 09 16:55:10 ipa.example.test systemd[1]: dbus-:1.3-org.fedoraproject.SetroubleshootPrivileged@2.service: Deactivated successfully.
Jul 09 16:55:00 ipa.example.test setroubleshoot[2263]: SELinux is preventing /usr/sbin/abrt-server from connectto access on the unix_stream_socket /run/systemd/io.sys>
                                                       *****  Plugin catchall_boolean (89.3 confidence) suggests   ******************
                                                       If you want to allow daemons to enable cluster mode
                                                       Then you must tell SELinux about this by enabling the 'daemons_enable_cluster_mode' boolean.
                                                       Do
                                                       setsebool -P daemons_enable_cluster_mode 1
                                                       *****  Plugin catchall (11.6 confidence) suggests   **************************
                                                       If you believe that abrt-server should be allowed connectto access on the io.systemd.NamespaceResource unix_str>
                                                       Then you should report this as a bug.
                                                       You can generate a local policy module to allow this access.
                                                       Do
                                                       allow this access for now by executing:
                                                       # ausearch -c 'abrt-server' --raw | audit2allow -M my-abrtserver
                                                       # semodule -X 300 -i my-abrtserver.pp
Jul 09 16:54:59 ipa.example.test setroubleshoot[2263]: SELinux is preventing /usr/sbin/abrt-server from connectto access on the unix_stream_socket /run/systemd/io.sys>
Jul 09 16:54:59 ipa.example.test setroubleshoot[2263]: SELinux is preventing /usr/sbin/abrt-server from connectto access on the unix_stream_socket /run/systemd/io.sys>
                                                       *****  Plugin catchall_boolean (89.3 confidence) suggests   ******************
                                                       If you want to allow daemons to enable cluster mode
                                                       Then you must tell SELinux about this by enabling the 'daemons_enable_cluster_mode' boolean.
                                                       Do
                                                       setsebool -P daemons_enable_cluster_mode 1
                                                       *****  Plugin catchall (11.6 confidence) suggests   **************************
                                                       If you believe that abrt-server should be allowed connectto access on the io.systemd.NamespaceResource unix_str>
                                                       Then you should report this as a bug.
                                                       You can generate a local policy module to allow this access.
                                                       Do
                                                       allow this access for now by executing:
                                                       # ausearch -c 'abrt-server' --raw | audit2allow -M my-abrtserver
                                                       # semodule -X 300 -i my-abrtserver.pp
Jul 09 16:54:59 ipa.example.test setroubleshoot[2263]: SELinux is preventing /usr/sbin/abrt-server from connectto access on the unix_stream_socket /run/systemd/io.sys>
Jul 09 16:54:59 ipa.example.test setroubleshoot[2263]: SELinux is preventing /usr/sbin/abrt-server from connectto access on the unix_stream_socket /run/systemd/io.sys>
                                                       *****  Plugin catchall_boolean (89.3 confidence) suggests   ******************
                                                       If you want to allow daemons to enable cluster mode
                                                       Then you must tell SELinux about this by enabling the 'daemons_enable_cluster_mode' boolean.
                                                       Do
                                                       setsebool -P daemons_enable_cluster_mode 1
                                                       *****  Plugin catchall (11.6 confidence) suggests   **************************
                                                       If you believe that abrt-server should be allowed connectto access on the io.systemd.NamespaceResource unix_str>
                                                       Then you should report this as a bug.
                                                       You can generate a local policy module to allow this access.
                                                       Do
                                                       allow this access for now by executing:
                                                       # ausearch -c 'abrt-server' --raw | audit2allow -M my-abrtserver
                                                       # semodule -X 300 -i my-abrtserver.pp
Jul 09 16:54:59 ipa.example.test setroubleshoot[2263]: SELinux is preventing /usr/sbin/abrt-server from connectto access on the unix_stream_socket /run/systemd/io.sys>
Jul 09 16:54:59 ipa.example.test setroubleshoot[2263]: SELinux is preventing /usr/sbin/abrt-server from connectto access on the unix_stream_socket /run/systemd/io.sys>
                                                       *****  Plugin catchall_boolean (89.3 confidence) suggests   ******************
                                                       If you want to allow daemons to enable cluster mode
                                                       Then you must tell SELinux about this by enabling the 'daemons_enable_cluster_mode' boolean.
                                                       Do
                                                       setsebool -P daemons_enable_cluster_mode 1
                                                       *****  Plugin catchall (11.6 confidence) suggests   **************************
                                                       If you believe that abrt-server should be allowed connectto access on the io.systemd.NamespaceResource unix_str>
                                                       Then you should report this as a bug.
                                                       You can generate a local policy module to allow this access.
                                                       Do
                                                       allow this access for now by executing:
                                                       # ausearch -c 'abrt-server' --raw | audit2allow -M my-abrtserver
                                                       # semodule -X 300 -i my-abrtserver.pp
Jul 09 16:54:59 ipa.example.test setroubleshoot[2263]: SELinux is preventing /usr/sbin/abrt-server from connectto access on the unix_stream_socket /run/systemd/io.sys>
Jul 09 16:54:58 ipa.example.test abrt-server[3048]: Deleting problem directory '/var/spool/abrt/Python3-2024-07-09-16:54:58-3046'
Jul 09 16:54:58 ipa.example.test abrt-server[3048]: 'post-create' on '/var/spool/abrt/Python3-2024-07-09-16:54:58-3046' exited with 1
Jul 09 16:54:58 ipa.example.test abrt-server[3048]: Package 'dogtag-pki-server' isn't signed with proper key
Jul 09 16:54:58 ipa.example.test audit: PROCTITLE proctitle=616272742D736572766572002D73
Jul 09 16:54:58 ipa.example.test audit[3048]: SYSCALL arch=c000003e syscall=42 success=no exit=-13 a0=6 a1=7ffd67a7e230 a2=33 a3=55f182b67040 items=0 ppid=852 pid=304>
Jul 09 16:54:58 ipa.example.test audit[3048]: AVC avc:  denied  { connectto } for  pid=3048 comm="abrt-server" path="/run/systemd/io.systemd.NamespaceResource" sconte>
Jul 09 16:54:58 ipa.example.test audit: PROCTITLE proctitle=616272742D736572766572002D73

And the installation log is attached down below.

test_log.txt

So the CA can't connect to the ldap server for some reason. Let's check to see if it is running. You should get something like:

$ ldapsearch -LLL -x -H ldap://ipa.example.test -b "" -s base namingContexts
dn:
namingContexts: dc=example,dc=test
namingContexts: cn=changelog
namingContexts: o=ipaca

I wonder if this is a problem due to double networking in cloud environments (if this is such a VM). 

2024-07-09T14:54:30Z DEBUG Check if ipa.example.test is a primary hostname for localhost
2024-07-09T14:54:30Z DEBUG Primary hostname for localhost: ipa.example.test
2024-07-09T14:54:30Z DEBUG Search DNS for ipa.example.test
2024-07-09T14:54:30Z DEBUG Check if ipa.example.test is not a CNAME
2024-07-09T14:54:30Z DEBUG Check reverse address of 185.103.150.13
2024-07-09T14:54:30Z DEBUG Found reverse name: ipa.example.test
2024-07-09T14:54:30Z DEBUG will use host_name: ipa.example.test

If ipa.example.test is 185.103.. according to /etc/hosts or DNS, we might try to connect to it through the external interface and that will stumble upon an external firewall. All the previous LDAP operations in the installer are going through LDAPI (UNIX domain socket access).

So the CA can't connect to the ldap server for some reason. Let's check to see if it is running. You should get something like:

$ ldapsearch -LLL -x -H ldap://ipa.example.test -b "" -s base namingContexts
dn:
namingContexts: dc=example,dc=test
namingContexts: cn=changelog
namingContexts: o=ipaca

I can't connect to the ldap server, though I can ping it:

felipe@ipa:~$ ldapsearch -LLL -x -H ldap://ipa.example.test -b "" -s base namingContexts
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

I wonder if this is a problem due to double networking in cloud environments (if this is such a VM).
```

2024-07-09T14:54:30Z DEBUG Check if ipa.example.test is a primary hostname for localhost
2024-07-09T14:54:30Z DEBUG Primary hostname for localhost: ipa.example.test
2024-07-09T14:54:30Z DEBUG Search DNS for ipa.example.test
2024-07-09T14:54:30Z DEBUG Check if ipa.example.test is not a CNAME
2024-07-09T14:54:30Z DEBUG Check reverse address of 185.103.150.13
2024-07-09T14:54:30Z DEBUG Found reverse name: ipa.example.test
2024-07-09T14:54:30Z DEBUG will use host_name: ipa.example.test
`` Ifipa.example.testis185.103..according to/etc/hosts` or DNS, we might try to connect to it through the external interface and that will stumble upon an external firewall. All the previous LDAP operations in the installer are going through LDAPI (UNIX domain socket access).

It's setup as a VM using Virt-manager. The network is set in bridge mode and attached to the virtual virbr0 network interface which redirects the traffic to the real wireless NIC.

So can you collect a network trace to see if we get wrong DNS response or a problem is completely within the VM?

Any update on this?
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.