Ubuntu apt Upgrade – Running Commands Before and After Upgrade

aptUbuntu

On an Ubuntu 16.04.3 LTS server I run some process monitors, but I also run apt manually as well as unattended-upgrades for security updates.

This sometimes causes the monitors to report and act on programs that were stopped by apt during apt upgrade.

Is there a way to run a command when unattended-upgrades/apt starts the upgrades (to stop the monitors) and again when unattended-upgrades/apt finishes (to restart the monitors)?

I found APT::Update::Pre-Invoke and APT::Update::Post-Invoke hooks but the apt update step is not the problem, and apt itself does not seem to have any pre/post upgrade hooks.

Best Answer

There are three hooks you can use for this:

DPkg::Pre-Invoke is run once, before all the package manipulation sequences in one apt invocation;
DPkg::Pre-Install-Pkgs is also run once, before the package manipulation sequences, after the Pre-Invoke hook, and with a list of all the packages which will be installed;
DPkg::Post-Invoke is run once, after the package manipulation sequences.

The documentation isn’t all that clear (do read man apt.conf though), but reading the source code supports the above. Specifying hooks also confirms this (for example, this is how apt-listbugs works).

Solution

Create a new Group: groupadd -r updaters The -r option reserves a system group, i.e. 0 - 100.
Add Users to Above Group: useradd -G updaters john, useradd -G updaters sally. You can also use the user alias section to acheive this. See Sudoer File Examples for a fully functioning User Alias Section. In my opinion, doing it the way I've done adds security, as the group actually exists in the system.
Create your command list for updaters: Note: Apt-get uses argument passing. See Problem Section Cmnd_Alias UPDATE_CMDS = /usr/bin/aptitude, /usr/bin/dpkg, /usr/bin/apt-get up*, /usr/bin/apt-get install
- Note that dpkg is needed for apt-get. See AskUbuntu: Adding apt-get to sudoers file.
- Note that apt-get update and apt-get upgrade are both needed. Using a glob pattern achieves both.
- Note that aptitude may be used to replace apt-get if the dpkg behavior noted above is undesired. If you don't want users in the updaters group to install off the internet with a mouse click...

Now we must add our updates into our sudoers file. Issue: visudo,and:

The default sudoers file from Ubuntu (with adds from above):

# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults    env_reset

# Uncomment to allow members of group sudo to not need a password
# %sudo ALL=NOPASSWD: ALL

# Host alias specification

# User alias specification

# Cmnd alias specification
Cmnd_Alias UPDATE_CMDS = /usr/bin/aptitude, /usr/bin/dpkg, /usr/bin/apt-get up*, /usr/bin/apt-get install

# User privilege specification
root    ALL=(ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Members of the upgraders group may perform certain upgrade commands.
# If No Password is desired, comment the line below, and see the next option.
%upgraders ALL=UPDATE_CMDS

# Members of the upgraders group may perform certain upgrade commands, 
# WITHOUT A PASSWORD DANGEROUS (uncomment if desired):
#%upgraders ALL=NOPASSWD:UPDATE_CMDS

If you decide to add unattended-upgrade, read the Debian Documentation on it. and use which unattended-upgrade to determine the path to add it to UPDATE_CMDS. See Problem Section.

Update

After even more research, I ran across a Blogpost: Everything you need to know about conffiles: configuration files managed by dpkg. The problem is not in apt variants, the problem is in the underlying dpkg implementation. Quoting:

Avoiding the conffile prompt

Every time that dpkg must install a new conffile that you have modified (and a removed file is only a particular case of a modified file in dpkg’s eyes), it will stop the upgrade and wait your answer. This can be particularly annoying for major upgrades. That’s why you can give predefined answers to dpkg with the help of multiple --force-conf* options:

--force-confold: do not modify the current configuration file, the new version is installed with a .dpkg-dist suffix. With this option alone, even configuration files that you have not modified are left untouched. You need to combine it with --force-confdef to let dpkg overwrite configuration files that you have not modified.

--force-confnew: always install the new version of the configuration file, the current version is kept in a file with the .dpkg-old suffix.

--force-confdef: ask dpkg to decide alone when it can and prompt otherwise. This is the default behavior of dpkg and this option is mainly useful in combination with --force-confold.

--force-confmiss: ask dpkg to install the configuration file if it’s currently missing (for example because you have removed the file by mistake).

Knowing this, as the blog points out, we can create /etc/apt/apt.conf.d/local, and add (example):

Dpkg::Options {
   "--force-confdef";
   "--force-confold";
}

This should then bypass the Z option all together.

Problem

Unattended Upgrades are usually a bad idea, because the OS may install items that were unexpected, for example new kernels, or updated drivers that will break a functioning driver, added to the idea that you're giving the option to a user. The other issue here is that since apt-get uses argument passing to decide which option to perform, one must pass each desired option in the Command Alias created. By adding each argument separately, we remove the ability to use the dist-upgrade argument. Like you, I assumed one could not pass an argument in the sudoers file, and while researching I too, learned something new.

References

nixCraft - Howto: Linux Add User To Group
Aptitude - Ubuntu Documentation
Ubuntu Forums - Thread: HowTO: Sudoers Configuration
Ubuntu Documentation - Installing Software
AskUbuntu - What is the difference between apt-get update and upgrade?

Where to find logs/information about unattended-upgrades (apt)

Unattended upgrade has its own log-file in /var/log/unattended-upgrades/unattended-upgrades.log

It is policed by anacoron.

# These lines replace cron's entries
1   5   cron.daily  run-parts --report /etc/cron.daily
7   10  cron.weekly run-parts --report /etc/cron.weekly
@monthly    15  cron.monthly    run-parts --report /etc/cron.monthly

Best Answer

Related Solutions

Is granting unattended-upgrade command to non-sudo users safe

Solution

Update

Avoiding the conffile prompt

Problem

References

Where to find logs/information about unattended-upgrades (apt)

Related Question