→ http://release.debian.org/proposed-updates/stable.html
6.7. Keeping a System Up to Date
The Debian distribution is dynamic and changes continually. Most of the changes are in the Testing and Unstable versions, but even Stable is updated from time to time, mostly for security-related fixes. Whatever version of Debian a system runs, it is generally a good idea to keep it up to date, so that you can get the benefit of recent evolutions and bug fixes.
While it is of course possible to periodically run a tool to check for available updates and run the upgrades, such a repetitive task is tedious, especially when it needs to be performed on several machines. Fortunately, like many repetitive tasks, it can be partly automated, and a set of tools have already been developed to that effect.
The first of these tools is apticron, in the package of the same name. Its main effect is to run a script daily (via cron). The script updates the list of available packages, and, if some installed packages are not in the latest available version, it sends an email with a list of these packages along with the changes that have been made in the new versions. Obviously, this package mostly targets users of Debian Stable, since the daily emails would be very long for the more mobile versions of Debian. When updates are available, apticron automatically downloads them. It does not install them — the administrator will still do it — but having the packages already downloaded and available locally (in APT's cache) makes the job faster.
Administrators in charge of several computers will no doubt appreciate being informed of pending upgrades, but the upgrades themselves are still as tedious as they used to be, which is where the /etc/cron.daily/apt script (in the apt package) comes in handy. This script is also run daily (and non-interactively) by cron. To control its behavior, use APT configuration variables (which are therefore stored in a file under /etc/apt/apt.conf.d/). The main three variables are:
APT::Periodic::Update-Package-Lists
This option allows you to specify the frequency (in days) at which the package lists are refreshed. apticron users can do without this variable, since apticron already does this task.
APT::Periodic::Download-Upgradeable-Packages
Again, this option indicates a frequency (in days), this time for the downloading of the actual packages. Again, apticron users won't need it.
APT::Periodic::AutocleanInterval
This last option covers a feature that apticron doesn't have. It controls how often obsolete packages (those not referenced by any distribution anymore) are removed from the APT cache. This keeps the APT cache at a reasonable size and means that you don't need to worry about that task.
Other options can allow you to control the cache cleaning behavior with more precision. They are not listed here, but they are described in the /etc/cron.daily/apt script.
These tools work very well for servers, but desktop users generally prefer a more interactive system. That is why the “Graphical desktop environment” task installs update-notifier and update-manager. The former displays an icon in the notification area of desktop environments when updates are available; clicking on this icon then runs update-manager, a simplified interface to perform updates. You can browse through available updates, read the description of the relevant packages and their changelog, and select whether to apply the update or not on a case-by-case basis. Note that these packages contain configuration data for /etc/cron.daily/apt so that it refreshes the lists of available packages and downloads the relevant ones. The update-notifier/update-manager combination is far from having as many features as aptitude and synaptic, since it only handles the upgrades of packages which are already installed; as a consequence, its minimalistic interface leaves little room for mistakes, and therefore little risk of breaking the system.
Figure 6.3. Upgrading with update-manager
6.8. Automatic Upgrades
Since Falcot Corp has many computers but only limited manpower, its administrators try to make upgrades as automatic as possible. The programs in charge of these processes must therefore run with no human intervention.
6.8.1. Configuring dpkg
As we have already mentioned (see sidebar GOING FURTHER Avoiding the configuration file questions), dpkg can be instructed not to ask for confirmation when replacing a configuration file (with the --force-confdef --force-confold options). Interactions can, however, have three other sources: some come from APT itself, some are handled by debconf, and some happen on the command line due to package configuration scripts.
6.8.2. Configuring APT
The case of APT is simple: the -y option (or --assume-yes) tells APT to consider the answer to all its questions to be “yes”.
6.8.3. Configuring debconf
The case of debconf deserves more details. This program was, from its inception, designed to control the relevance and volume of questions displayed to the user, as well as the way they are shown. That is why its configuration requests a minimal priority for questions; only questions above the minimal priority are displayed. debconf assumes the default answer (defined by the package maintainer) for questions which it decided to skip.
The other relevant configuration element is the interface used by the front-end. If you choose noninteractive out of the choices, all user interaction is disabled. If a package tries to display an informative note, it will be sent to the administrator by email.
To reconfigure debconf, use the dpkg-reconfigure tool from the debconf package; the relevant command is dpkg-reconfigure debconf. Note that the configured values can be temporarily overridden with environment variables when needed (for instance, DEBIAN_FRONTEND controls the interface, as documented in the debconf(7) manual page).
6.8.4. Handling Command Line Interactions
The last source of interactions, and the hardest to get rid of, is the configuration scripts run by dpkg. There is unfortunately no standard solution, and no answer is overwhelmingly better than another.
The common approach is to suppress the standard input by redirecting the empty content of /dev/null into it with command </dev/null, or to feed it with an endless stream of newlines. None of these methods are 100 % reliable, but they generally lead to the default answers being used, since most scripts consider a lack of reply as an acceptance of the default value.
6.8.5. The Miracle Combination
By combining the previous elements, it is possible to design a small but rather reliable script which can handle automatic upgrades.
Example 6.3. Non-interactive upgrade script
export DEBIAN_FRONTEND=noninteractive
yes '' | apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade
IN PRACTICE The Falcot Corp case
Falcot computers are a heterogeneous system, with machines having various functions. Administrators will therefore pick the most relevant solution for each computer.
In practice, the servers running Squeeze are configured with the “miracle combination” above, and are kept up to date automatically. Only the most critical servers (the firewalls, for instances) are set up with apticron, so that upgrades always happen under the supervision of an administrator.