Server Fault asked:
I’m looking into replacing a Linux based home-grown patch management solution with
The current system uses a shell script to iterate through a list of hosts and copies a script named apt-update to the remote. After copying the script, the process then runs the script on the remote (over ssh). The apt-update script basically contains
apt-get udpate; apt-get upgrade. When a conflict arises with a configuration file (such as Grub) or
dpkg-reconfigure runs something like
pam-auth-update, interaction is required to select how to proceed. If I run this process over
salt-ssh, there doesn’t seem to be an opportunity to interact with the update process. In fact,
salt-ssh stdout contains this:
stderr: debconf: unable to initialize frontend: Dialog debconf: (TERM is not set, so the dialog frontend is not usable.) debconf: falling back to frontend: Readline debconf: unable to initialize frontend: Readline debconf: (This frontend requires a controlling tty.) debconf: falling back to frontend: Teletype dpkg-preconfigure: unable to re-open stdin:
I’ve not used Saltstack before. Is there a way to handle this type of situation when interaction is required?
You can set the environment variable
DEBIAN_FRONTEND=noninteractive in order to cause all such questions to be suppressed. However, how packages get configured in this scenario may vary, so you should test thoroughly.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.