Using salt-ssh for Ubuntu/Debian patching (dialog frontend is not usable)

Server Fault asked:

I’m looking into replacing a Linux based home-grown patch management solution with salt-ssh.

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?

My answer:


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.


View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.