ipaclient_setup_nss fails on Ubuntu/Debian

[imp1sh]

I roll out FreeIPA as a client and during that I also use freeipa.ansible_freeipa.ipaclient_setup_nss.

Sadly the process is stuck as the changes seem to result in the OS is in interactive mode and requesting an input:

See my processes, when it's stuck:

root       47387   41700  0 13:27 pts/0    00:00:00       /bin/sh -c /usr/bin/python3 /root/.ansible/tmp/ansible-tmp-1693999621.2573123-3214333-199842260532899/AnsiballZ_ipaclient_setup_nss.py && sleep 0
root       47388   47387  0 13:27 pts/0    00:00:01         /usr/bin/python3 /root/.ansible/tmp/ansible-tmp-1693999621.2573123-3214333-199842260532899/AnsiballZ_ipaclient_setup_nss.py
root       48151   47388  0 13:27 pts/0    00:00:00           /usr/bin/perl -w /usr/share/debconf/frontend /sbin/pam-auth-update --package --enable mkhomedir
root       48157   48151  0 13:27 pts/0    00:00:00             /usr/bin/perl -w /sbin/pam-auth-update --package --enable mkhomedir
root       48159   48151  0 13:27 pts/0    00:00:00             whiptail --backtitle Package configuration --title PAM configuration --output-fd 11 --defaultno --yesno -- One or more of the files  /etc/pam.d/common-{auth,account,password,session} have been locally  modified.  Please indicate whether these local changes should be  overridden using the system-provided configuration.  If you decline this option, you will need to manage your system's authentication  configuration by hand.  Override local changes to /etc/pam.d/common-*? 14 77

I'm on 1.11.1 The problematic OSes is Ubuntu 20.04 and Debian 12 On CentOS 7 the problem does not occur.

[imp1sh]

Just in case anyone else suffers this problem. As a workaround just kill the whiptail process on the target system.

[rjeffman]

What do you mean by "I also use freeipa.ansible_freeipa.ipaclient_setup_nss."?

The roles internal modules are not meant to be used independently of the roles.

[imp1sh]

Well that was certainly a bad way to describe it. To be clear: I use the role ipaclient from the collection. One task of this role is called Install - Create IPA NSS database and that makes use of freeipa.ansible_freeipa.ipaclient_setup_nss.

[rjeffman]

That make things more clear. :-)

I don't remember testing under Debian 12, but Ubuntu 20.04 used to work.

The failure ocurs when we do a call to a FreeIPA function, so the same issue should also occur, on this node, if the installation was performed through the CLI.

Note that the question is about a file that is locally modified, so I'm not sure if some installed tool is monitoring the file or not.

As far as I can see (without rebuilding my Debian/Ubuntu environments) is that this is a change either in the distro packaging or package tools, or on the node configuration. Either way it does not seem we can do much on ansible-freeipa side.

[imp1sh]

Thank you. I will dig around some more and give feedback.

[jhawkwind]

This also happens to Ubuntu 22.04 LTS and Ubuntu 24.04 LTS. It seems that something is calling /sbin/pam-auth-update --package --enable mkhomedir and doesn't "force" so it waits for user interaction..... which there is no interactive session to interact with the whiptail prompt.

Normally if we add --force, it would just answer "yes" on that prompt whether to override localized PAM file changes; which would solve the hanging. However, this may make changes to PAM files that may exceed the scope of the IPA client that may lead to other things in a non-standard/OOB PAM setup breaking.

[jhawkwind]

Taking a hint from these two articles:

• Debian Package Configuration System
• Become User Flags

You can do this in your playbook to have the package manager suppress prompts by adding an environment variable to the sudo process so it passes the DEBIAN_FRONTEND=noninteractive environment variable that the package manager will use:

- name: Apply IPA Client configuration
  hosts: ipaclients
  become: true
  become_flags: "DEBIAN_FRONTEND=noninteractive"
  roles:
    - role: freeipa.ansible_freeipa.ipaclient
      state: present

This got me over the issue with Ubuntu systems, and probably other Debian boxes. If there are other non-Debian systems, it will likely just ignore that environment variable even if set. So it should be safe to set without any conditions.

The only danger is that if you have any local PAM configurations on the /etc/pam.d/common-* files that are custom that you want to keep, they are wiped/lost since the confirmation prompt is entirely skipped.

[jhawkwind]

As far as I can see (without rebuilding my Debian/Ubuntu environments) is that this is a change either in the distro packaging or package tools, or on the node configuration. Either way it does not seem we can do much on ansible-freeipa side.

Whatever is calling the IPA package installation in the freeipa.ansible_freeipa.ipaclient_setup_nss play should probably pass that flag when it detects a Debian box. Or maybe just set the environment variable before calling ipa-client-install in the modules?

Since when you do ipa-client-install on CLI, you are indeed "interactive", but I don't think the FreeIPA function has a check whether it is interactive or not, unless it also has something like a -q or -y flag to pass. I think the easier solution is simply to detect if it is a Debian OS, and if it is, set the environment variable before calling the FreeIPA function.

[rjeffman]

I'm somewhat drowning in work here, but I'll try to take a look at it in the coming week(s).

I kinda like the environment variable solution.