I have a 3-server (replicating) FreeIPA environment running on CentOS7. ipa --version shows: VERSION: 4.6.8, API_VERSION: 2.237 I have successfully "joined" two Ubuntu Server 20.04 LTS clients to the FreeIPA environment without issue. Let's call those Alpha and Beta. Alpha and Beta were installed using Ubuntu's freeipa packages; they show ipa --version: VERSION: 4.8.6, API_VERSION: 2.236
Alpha and Beta work as expected, even though their client version is newer than the servers.
I now have a 3rd Ubuntu Server 20.04 LTS VM ("Gamma") that I am trying to enroll/setup, and ipa-client-install returns success, but near the end of the install, 'getent' fails to pull info about the user account that was used during the install, and I can't login to this VM with an account from the FreeIPA database.
I looked through the install log and didn't see anything obvious, but I've also only installed freeipa on 5 other systems at this point, so I don't really know what to look for. :)
Key differences between Alpha/Beta and Gamma: Alpha/Beta are both VMs installed from a Ubuntu 20.04 LTS ISO; Gamma is an Ubuntu "cloud-image" VM (cloned from their image and then run through cloud-init for a hostname/etc)
Alpha/Beta are using static IP addresses with manual DNS configuration; Gamma is using DHCP, but has a reservation (the IP won't change). DHCP is issuing the IPs of the 3 FreeIPA server VMs as DNS servers, and the DNS search domain is correct.
Note that all 3 Ubuntu systems *are* still using Systemd-Resolve for DNS, which is then sending queries to the CentOS 7 Servers. Alpha and Beta are fine with this, so I don't think systemd-resolve is the problem.
Any help would be greatly appreciated, because I'm not sure what to look at next (and I also don't understand why what should be a nearly identical install is not working). Rather than attaching the entirety of ipaclient-install.log, here is a github gist link with it. I've sanitized the domain, hostname, enroll username, and kerberos realm, but everything else has not been touched. https://gist.github.com/ZPrimed/1040499a744286690745a7d93bcd3d10
On to, 18 helmi 2021, Braden McGrath via FreeIPA-users wrote:
I have a 3-server (replicating) FreeIPA environment running on CentOS7. ipa --version shows: VERSION: 4.6.8, API_VERSION: 2.237 I have successfully "joined" two Ubuntu Server 20.04 LTS clients to the FreeIPA environment without issue. Let's call those Alpha and Beta. Alpha and Beta were installed using Ubuntu's freeipa packages; they show ipa --version: VERSION: 4.8.6, API_VERSION: 2.236
Alpha and Beta work as expected, even though their client version is newer than the servers.
I now have a 3rd Ubuntu Server 20.04 LTS VM ("Gamma") that I am trying to enroll/setup, and ipa-client-install returns success, but near the end of the install, 'getent' fails to pull info about the user account that was used during the install, and I can't login to this VM with an account from the FreeIPA database.
I looked through the install log and didn't see anything obvious, but I've also only installed freeipa on 5 other systems at this point, so I don't really know what to look for. :)
Key differences between Alpha/Beta and Gamma: Alpha/Beta are both VMs installed from a Ubuntu 20.04 LTS ISO; Gamma is an Ubuntu "cloud-image" VM (cloned from their image and then run through cloud-init for a hostname/etc)
Alpha/Beta are using static IP addresses with manual DNS configuration; Gamma is using DHCP, but has a reservation (the IP won't change). DHCP is issuing the IPs of the 3 FreeIPA server VMs as DNS servers, and the DNS search domain is correct.
Note that all 3 Ubuntu systems *are* still using Systemd-Resolve for DNS, which is then sending queries to the CentOS 7 Servers. Alpha and Beta are fine with this, so I don't think systemd-resolve is the problem.
Any help would be greatly appreciated, because I'm not sure what to look at next (and I also don't understand why what should be a nearly identical install is not working). Rather than attaching the entirety of ipaclient-install.log, here is a github gist link with it. I've sanitized the domain, hostname, enroll username, and kerberos realm, but everything else has not been touched. https://gist.github.com/ZPrimed/1040499a744286690745a7d93bcd3d10
Check your /etc/nsswitch.conf, does it have 'sss' in 'passwd' and 'group' entries?
I think Debian/Ubuntu platform code does not modify /etc/nsswitch.conf and expects that 'sss' is present. If I'd do 'apt-get install sssd' on Ubuntu 20.04, then an install script from one of installed packages modifies /etc/nsswitch.conf to include 'sss', this can be seen here:
https://salsa.debian.org/sssd-team/sssd/-/blob/master/debian/libnss-sss.post...
Setting up libnss-sss:amd64 (2.2.3-3ubuntu0.3) ... First installation detected... Checking NSS setup... Adding an entry for automount.
I'd guess your cloud image is incomplete and may be it didn't really run the post install scripts for many packages, not just libnss-sss.
May be 'dpkg-reconfigure libnss-sss' would help?
Alexander, I truly appreciate your help once again. :-)
Check your /etc/nsswitch.conf, does it have 'sss' in 'passwd' and 'group' entries?
It does not... you're definitely onto something.
I think Debian/Ubuntu platform code does not modify /etc/nsswitch.conf and expects that 'sss' is present. If I'd do 'apt-get install sssd' on Ubuntu 20.04, then an install script from one of installed packages modifies /etc/nsswitch.conf to include 'sss', this can be seen here:
https://salsa.debian.org/sssd-team/sssd/-/blob/master/debian/libnss-sss.p...
Setting up libnss-sss:amd64 (2.2.3-3ubuntu0.3) ... First installation detected... Checking NSS setup... Adding an entry for automount.
I'd guess your cloud image is incomplete and may be it didn't really run the post install scripts for many packages, not just libnss-sss.
May be 'dpkg-reconfigure libnss-sss' would help?
'dpkg-reconfigure libnss-sss' doesn't seem to do anything, it isn't even adding 'sss' to nsswitch.conf.
I'm not sure how or why the cloud image would be incomplete. It has been booted and then restarted multiple times after the initial cloud-config ran. But now I'm going to do more research on what other differences there might be between a "cloud image" and a normal install...
To be clear, I did *not* install the freeipa-client package as part of the cloud-init. I manually ran 'sudo apt -y install freeipa-client' which is supposed to grab all other dependencies / etc. I saw it install a whole bunch of SSS-related libs and such.
On the other two VMs (Alpha & Beta), I used the same process and they worked correctly.
For the heck of it, I just did an ipa-client-install --uninstall, and wiped it all off of Gamma and started over. During the apt install, it throws some warnings during the setup of 'sssd-common', and I don't think I remember seeing this on the VMs installed from ISO. So now I need to track down why apparmor.d is doing a "Force-complain" and why (if?) this is different from the ISO-installed systems.
Setting up libpam-pwquality:amd64 (1.4.2-1build1) ... Setting up nss-plugin-pem:amd64 (1.0.5-1) ... Setting up sssd-common (2.2.3-3ubuntu0.3) ... Warning: found usr.sbin.sssd in /etc/apparmor.d/force-complain, forcing complain mode Warning from /etc/apparmor.d/usr.sbin.sssd (/etc/apparmor.d/usr.sbin.sssd line 59): Warning failed to create cache: usr.sbin.sssd sssd-autofs.service is a disabled or a static unit not running, not starting it. sssd-nss.service is a disabled or a static unit not running, not starting it. sssd-pam.service is a disabled or a static unit not running, not starting it. sssd-ssh.service is a disabled or a static unit not running, not starting it. sssd-sudo.service is a disabled or a static unit not running, not starting it. sssd.service is a disabled or a static unit not running, not starting it. A dependency job for sssd-autofs.socket failed. See 'journalctl -xe' for details. A dependency job for sssd-nss.socket failed. See 'journalctl -xe' for details. A dependency job for sssd-pam-priv.socket failed. See 'journalctl -xe' for details. A dependency job for sssd-pam.socket failed. See 'journalctl -xe' for details. A dependency job for sssd-ssh.socket failed. See 'journalctl -xe' for details. A dependency job for sssd-sudo.socket failed. See 'journalctl -xe' for details. Setting up sssd-proxy (2.2.3-3ubuntu0.3) ... Setting up rpm-common (4.14.2.1+dfsg1-1build2) ... Setting up python3-pil:amd64 (7.0.0-4ubuntu0.2) ... Setting up sssd-krb5-common (2.2.3-3ubuntu0.3) ... Setting up libcups2:amd64 (2.3.1-9ubuntu1.1) ... Setting up certmonger (0.79.9-2) ... certmonger.conf:3: Line references path below legacy directory /var/run/, updating /var/run/certmonger → /run/certmonger; please update the tmpfiles.d/ drop-in file accordingly. certmonger.service is a disabled or a static unit not running, not starting it. Setting up sssd-krb5 (2.2.3-3ubuntu0.3) ... Setting up python3-qrcode (6.1-2build1) ... update-alternatives: using /usr/bin/python3-qr to provide /usr/bin/qr (qr) in auto mode Setting up libpam-sss:amd64 (2.2.3-3ubuntu0.3) ... Setting up sssd-ldap (2.2.3-3ubuntu0.3) ... Setting up python3-ipalib (4.8.6-1ubuntu2) ... Setting up samba-libs:amd64 (2:4.11.6+dfsg-0ubuntu1.6) ... Setting up sssd-ad-common (2.2.3-3ubuntu0.3) ... sssd-pac.service is a disabled or a static unit not running, not starting it. A dependency job for sssd-pac.socket failed. See 'journalctl -xe' for details. Setting up libsmbclient:amd64 (2:4.11.6+dfsg-0ubuntu1.6) ... Setting up python3-ipaclient (4.8.6-1ubuntu2) ... Setting up sssd-ad (2.2.3-3ubuntu0.3) ... Setting up sssd-ipa (2.2.3-3ubuntu0.3) ... Setting up sssd (2.2.3-3ubuntu0.3) ... Setting up freeipa-client (4.8.6-1ubuntu2) ... Processing triggers for systemd (245.4-4ubuntu3.4) ... Processing triggers for man-db (2.9.1-1) ... Processing triggers for dbus (1.12.16-2ubuntu2.1) ... Processing triggers for libc-bin (2.31-0ubuntu9.2) ... [end]
On to, 18 helmi 2021, Braden McGrath via FreeIPA-users wrote:
Alexander, I truly appreciate your help once again. :-)
Check your /etc/nsswitch.conf, does it have 'sss' in 'passwd' and 'group' entries?
It does not... you're definitely onto something.
I think Debian/Ubuntu platform code does not modify /etc/nsswitch.conf and expects that 'sss' is present. If I'd do 'apt-get install sssd' on Ubuntu 20.04, then an install script from one of installed packages modifies /etc/nsswitch.conf to include 'sss', this can be seen here:
https://salsa.debian.org/sssd-team/sssd/-/blob/master/debian/libnss-sss.p...
Setting up libnss-sss:amd64 (2.2.3-3ubuntu0.3) ... First installation detected... Checking NSS setup... Adding an entry for automount.
I'd guess your cloud image is incomplete and may be it didn't really run the post install scripts for many packages, not just libnss-sss.
May be 'dpkg-reconfigure libnss-sss' would help?
'dpkg-reconfigure libnss-sss' doesn't seem to do anything, it isn't even adding 'sss' to nsswitch.conf.
Do you have it (libnss-sss) installed? If you do, maybe running
/var/lib/dpkg/info/libnss-sss:amd64.postinst configure
manually would help?
In any case, this is definitely something with particulars of the cloud image you are using and perhaps dependencies of the packages in Debian/Ubuntu.
FreeIPA upstream development team has no influence over distributions' packaging in Debian/Ubuntu. So if you see some issue there, please report a bug to your distribution as only distribution maintainers could fix that.
I'm not sure how or why the cloud image would be incomplete. It has been booted and then restarted multiple times after the initial cloud-config ran. But now I'm going to do more research on what other differences there might be between a "cloud image" and a normal install...
To be clear, I did *not* install the freeipa-client package as part of the cloud-init. I manually ran 'sudo apt -y install freeipa-client' which is supposed to grab all other dependencies / etc. I saw it install a whole bunch of SSS-related libs and such.
On the other two VMs (Alpha & Beta), I used the same process and they worked correctly.
For the heck of it, I just did an ipa-client-install --uninstall, and wiped it all off of Gamma and started over. During the apt install, it throws some warnings during the setup of 'sssd-common', and I don't think I remember seeing this on the VMs installed from ISO. So now I need to track down why apparmor.d is doing a "Force-complain" and why (if?) this is different from the ISO-installed systems.
Setting up libpam-pwquality:amd64 (1.4.2-1build1) ... Setting up nss-plugin-pem:amd64 (1.0.5-1) ... Setting up sssd-common (2.2.3-3ubuntu0.3) ... Warning: found usr.sbin.sssd in /etc/apparmor.d/force-complain, forcing complain mode Warning from /etc/apparmor.d/usr.sbin.sssd (/etc/apparmor.d/usr.sbin.sssd line 59): Warning failed to create cache: usr.sbin.sssd sssd-autofs.service is a disabled or a static unit not running, not starting it. sssd-nss.service is a disabled or a static unit not running, not starting it. sssd-pam.service is a disabled or a static unit not running, not starting it. sssd-ssh.service is a disabled or a static unit not running, not starting it. sssd-sudo.service is a disabled or a static unit not running, not starting it. sssd.service is a disabled or a static unit not running, not starting it. A dependency job for sssd-autofs.socket failed. See 'journalctl -xe' for details. A dependency job for sssd-nss.socket failed. See 'journalctl -xe' for details. A dependency job for sssd-pam-priv.socket failed. See 'journalctl -xe' for details. A dependency job for sssd-pam.socket failed. See 'journalctl -xe' for details. A dependency job for sssd-ssh.socket failed. See 'journalctl -xe' for details. A dependency job for sssd-sudo.socket failed. See 'journalctl -xe' for details. Setting up sssd-proxy (2.2.3-3ubuntu0.3) ... Setting up rpm-common (4.14.2.1+dfsg1-1build2) ... Setting up python3-pil:amd64 (7.0.0-4ubuntu0.2) ... Setting up sssd-krb5-common (2.2.3-3ubuntu0.3) ... Setting up libcups2:amd64 (2.3.1-9ubuntu1.1) ... Setting up certmonger (0.79.9-2) ... certmonger.conf:3: Line references path below legacy directory /var/run/, updating /var/run/certmonger → /run/certmonger; please update the tmpfiles.d/ drop-in file accordingly. certmonger.service is a disabled or a static unit not running, not starting it. Setting up sssd-krb5 (2.2.3-3ubuntu0.3) ... Setting up python3-qrcode (6.1-2build1) ... update-alternatives: using /usr/bin/python3-qr to provide /usr/bin/qr (qr) in auto mode Setting up libpam-sss:amd64 (2.2.3-3ubuntu0.3) ... Setting up sssd-ldap (2.2.3-3ubuntu0.3) ... Setting up python3-ipalib (4.8.6-1ubuntu2) ... Setting up samba-libs:amd64 (2:4.11.6+dfsg-0ubuntu1.6) ... Setting up sssd-ad-common (2.2.3-3ubuntu0.3) ... sssd-pac.service is a disabled or a static unit not running, not starting it. A dependency job for sssd-pac.socket failed. See 'journalctl -xe' for details. Setting up libsmbclient:amd64 (2:4.11.6+dfsg-0ubuntu1.6) ... Setting up python3-ipaclient (4.8.6-1ubuntu2) ... Setting up sssd-ad (2.2.3-3ubuntu0.3) ... Setting up sssd-ipa (2.2.3-3ubuntu0.3) ... Setting up sssd (2.2.3-3ubuntu0.3) ... Setting up freeipa-client (4.8.6-1ubuntu2) ... Processing triggers for systemd (245.4-4ubuntu3.4) ... Processing triggers for man-db (2.9.1-1) ... Processing triggers for dbus (1.12.16-2ubuntu2.1) ... Processing triggers for libc-bin (2.31-0ubuntu9.2) ... [end] _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@lists.fedorahoste... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On to, 18 helmi 2021, Braden McGrath via FreeIPA-users wrote:
Do you have it (libnss-sss) installed? If you do, maybe running
/var/lib/dpkg/info/libnss-sss\:amd64.postinst configuremanually would help?
It was installed (automatically) as a dependency of freeipa-client, so yes. Running the script as you describe *does* add "sss" to passwd, group, shadow, services, netgroup, and automount. But given the other error messages from "sssd-common" during installation, I suspect more things will be broken.
In any case, this is definitely something with particulars of the cloud image you are using and perhaps dependencies of the packages in Debian/Ubuntu.
FreeIPA upstream development team has no influence over distributions' packaging in Debian/Ubuntu. So if you see some issue there, please report a bug to your distribution as only distribution maintainers could fix that.
Fully understood, and I'm planning on taking this off of this list as it obviously isn't something wrong with FreeIPA itself. I appreciate the help getting to the bottom of it though.
I wanted to provide follow-up on this in case anybody else runs into it in the future. The error messages I was seeing during the install of "sssd-common" are apparently typical/expected and did *not* have anything to do with the problem here.
Alexander was crucial in saving me a lot of time digging around. :-) The wound was self-inflicted, but not purposefully, and I think there may be a bug in a Debian/Ubuntu package that was contributing to it.
As part of trying to get this working while also trying to document my steps, I believe I may have uninstalled the freeipa-client package, and then used `apt autoremove` to get rid of any unneeded dependencies (which includes the package libnss-sss, which is what actually modifies /etc/nsswitch.conf on Ubuntu).
When libnss-sss is installed initially, it makes changes to /etc/nsswitch.conf. When it is *removed*, it undoes those changes, which is actually not normal/expected behavior (typically, Debian/Ubuntu packages leave their config in-place unless you *purge* the package). If you subsequently re-install libnss-sss, it does *not* modify /etc/nsswitch.conf again, unless libnss-sss has first been purged.
So, through install and then remove (via "apt autoremove") and then subsequent reinstall of dependencies, I left libnss-sss in a state where it wasn't modifying /etc/nsswitch.conf to add the "sss" entries required for FreeIPA to actually integrate with everything. freeipa-client itself was working correctly.
I feel like this may be a bug with either the postinstall or postrm scripts for this particular library package, so I'm discussing that with Ubuntu. :)
Thank you again to Alexander for the help and to everyone involved in IPA/FreeIPA for all of their work on what I'm finding to be a pretty powerful system.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Braden McGrath