Custom silverblue image with freeipa-client SSSD cannot work

Ask Fedora
,
1

I build a custom silverblue image with freeipa-client installed to be ready to be enrolled on first boot. The host is correctly enrolled in my FreeIPA instance after realm join but locally, SSSD does not work and refuse to start.

Containerfile

ARG FEDORA_VERSION=42
FROM quay.io/fedora-ostree-desktops/silverblue:$FEDORA_VERSION

RUN dnf install -y freeipa-client
COPY tmpfile.conf /usr/lib/tmpfiles.d/ipa.conf # Workaround https://bugzilla.redhat.com/show_bug.cgi?id=2332433 

RUN bootc container lint

tmpfile.conf

d /var/lib/certmonger 0755 root root
d /var/lib/certmonger/cas
d /var/lib/certmonger/local
d /var/lib/certmonger/requests
d /var/lib/ipa-client 0755 root root
d /var/lib/ipa-client/pki
d /var/lib/ipa-client/sysrestore

After first boot, I can run a realm join, the host seems correctly enrolled in FreeIPA but SSSD is unable to start :

...
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config.d/04-ipa.conf
Configuring fr.otera.lan as NIS domain.
Configured /etc/krb5.conf for IPA realm FR.OTERA.LAN
Client configuration complete.
The ipa-client-install command was successful
This program will set up IPA client.
Version 4.12.5


Using default chrony configuration.
 * /usr/bin/systemctl enable sssd.service
 * /usr/bin/systemctl restart sssd.service
Job for sssd.service failed because the control process exited with error code.
See "systemctl status sssd.service" and "journa

� sssd.service - System Security Services Daemon
     Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             \u2514\u250010-timeout-abort.conf, 50-keep-warm.conf
     Active: failed (Result: exit-code) since Thu 2025-11-27 16:08:35 CET; 1min 21s ago
 Invocation: 381dd2f3e3fa4617b4f8b474c81674ea
    Process: 15949 ExecStartPre=/bin/chown -f -R -H root:sssd /etc/sssd (code=exited, status=0/SUCCESS)
    Process: 15951 ExecStartPre=/bin/chmod -f -R g+r /etc/sssd (code=exited, status=0/SUCCESS)
    Process: 15953 ExecStartPre=/bin/chmod -f g+x /etc/sssd (code=exited, status=0/SUCCESS)
    Process: 15955 ExecStartPre=/bin/chmod -f g+x /etc/sssd/conf.d (code=exited, status=0/SUCCESS)
    Process: 15957 ExecStartPre=/bin/chmod -f g+x /etc/sssd/pki (code=exited, status=0/SUCCESS)
    Process: 15959 ExecStartPre=/bin/sh -c /bin/chown -f -h sssd:sssd /var/lib/sss/db/*.ldb (code=exited, status=0/SUCCESS)
    Process: 15961 ExecStartPre=/bin/chown -f -R -h sssd:sssd /var/lib/sss/gpo_cache (code=exited, status=0/SUCCESS)
    Process: 15963 ExecStartPre=/bin/sh -c /bin/chown -f -h sssd:sssd /var/log/sssd/*.log* (code=exited, status=0/SUCCESS)
    Process: 15965 ExecStart=/usr/bin/sssd -i ${DEBUG_LOGGER} (code=exited, status=1/FAILURE)
   Main PID: 15965 (code=exited, status=1/FAILURE)
   Mem peak: 8.4M
        CPU: 148ms

nov. 27 16:08:28 tools3.fr.otera.lan systemd[1]: Starting sssd.service - System Security Services Daemon...
nov. 27 16:08:29 tools3.fr.otera.lan sssd[15965]: Starting up
nov. 27 16:08:29 tools3.fr.otera.lan sssd_be[15966]: Starting up
nov. 27 16:08:29 tools3.fr.otera.lan sssd_be[15968]: Starting up
nov. 27 16:08:31 tools3.fr.otera.lan sssd_be[15970]: Starting up
nov. 27 16:08:35 tools3.fr.otera.lan sssd_be[15972]: Starting up
nov. 27 16:08:35 tools3.fr.otera.lan sssd[15965]: Exiting the SSSD. Could not restart critical service [fr.otera.lan].
nov. 27 16:08:35 tools3.fr.otera.lan systemd[1]: sssd.service: Main process exited, code=exited, status=1/FAILURE
nov. 27 16:08:35 tools3.fr.otera.lan systemd[1]: sssd.service: Failed with result 'exit-code'.
nov. 27 16:08:35 tools3.fr.otera.lan systemd[1]: Failed to start sssd.service - System Security Services Daemon.

Layering via rpm-ostree on native silverblue works. I don’t understand the difference… The /etc/sssd/sssd.conf is same…

2

I am not familiar with this particular package and would not be able to help here.

In the bug report you mentioned in your Containerfile, there is a statement from the package maintainer that bootable container environments are not currently supported. However, with proper knowledge of this particular package and RPM in general, I suppose a workaround could be implemented.

As a side note, as I mentioned in your previous post, when building a derived bootable container image, the two LABEL instructions in your Containerfile are not necessary and can be safely omitted for readability and simplicity.

4

With silverblue 43 instead of 42 as base image, SSSD seems to behave better. But authentication still fails for obscure reason

Nov 28 14:16:43 qemu-standardpcq35ich92009-notspecified.fr.otera.lan systemd[1]: Starting sssd-kcm.service - SSSD Kerberos Cache Manager...
Nov 28 14:16:43 qemu-standardpcq35ich92009-notspecified.fr.otera.lan systemd[1]: Started sssd-kcm.service - SSSD Kerberos Cache Manager.
Nov 28 14:16:43 qemu-standardpcq35ich92009-notspecified.fr.otera.lan audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd-kcm comm="systemd" exe="/us>
Nov 28 14:16:44 qemu-standardpcq35ich92009-notspecified.fr.otera.lan sssd_kcm[3951]: Starting up
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan gdm-password][3816]: pam_sss(gdm-password:auth): authentication success; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=william.oprandi
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan audit[3816]: AUDIT1100 pid=3816 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication gr>
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan gdm-password][3816]: gkr-pam: unable to locate daemon control file
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan gdm-password][3816]: gkr-pam: stashed password to try later in open session
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan gdm-password][3816]: Gdm: GdmSessionWorker: state AUTHENTICATED
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan gdm-password][3816]: Gdm: GdmSessionWorker: trying to get updated username
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan gdm-password][3816]: Gdm: GdmSessionWorker: username is 'william.oprandi'
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan gdm-password][3816]: Gdm: GdmSessionWorker: old-username='william.oprandi' new-username='william.oprandi'
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan gdm-password][3816]: Gdm: GdmSessionWorker: attempting to change state to AUTHORIZED
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan gdm-password][3816]: Gdm: GdmSessionWorker: determining if authenticated user (password required:0) is authorized to session
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" >
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan audit: BPF prog-id=103 op=UNLOAD
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan audit[3816]: AUDIT1101 pid=3816 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting granto>
Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan gdm-password][3816]: pam_sss(gdm-password:account): Access denied for user william.oprandi: 4 (Erreur syst�me)

I will open a bugzilla ticket

5

I removed the LABEL

6

I created upstream issue here : 2417703 – Cannot login with IPA account when freeipa-client is bundled in bootc image

A workaround is to add selinux_provider = none in the domain section of sssd.conf