[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: are unattended updates a good idea?

On Sat, Jan 31, 2015 at 09:58:39AM +0100, Ml Ml wrote:
> Is anyone else facing the same problem? What are your experiences
> doing (blind) automatic security updates.

I've done automatic updates for Debian under cfengine control for nine
years and Ubuntu for perhaps one and a half. I started with a small
number of systems and gradually expanded it out until it includes most
servers. I can't think of any incidents where this has caused serious
problems, but I still update a handful of systems exclusively by hand.

The major problems, limitations and warnings I'm aware of are:

- In /etc/apt/sources.list it's very important to specify the release by
  name: you should use e.g. 'wheezy' instead of 'stable'. Otherwise you
  risk breaking your systems when jessie is released.

- It's important to have an easy way to turn off automatic updates on a
  particular system so that you can do maintenance work, and it's
  important to have an easy way to turn off automatic updates globally
  if you need to.

- It's probably a good idea to have some way of delaying updates to your
  critical production systems until you've checked them out on your test
  and less-critical production systems.

- My scripts do not reboot the system or restart any services that APT
  doesn't. This means I have to restart services or systems manually for
  library and kernel updates. I have Nagios check for systems that
  require a reboot and I restart them during a maintenance window.

- In the past, certain upgrade failures have broken the kernel or
  bootloader badly enough to leave systems unbootable without manual
  attention. If memory serves, this was most common on squeeze or lenny
  but hasn't happened frequently on wheezy. It's important to review the
  transcript of the upgrade session before you reboot.

- Starting last spring, certain unattended upgrades (possibly things
  that trigger man-db's maintainerscripts?) began to fail if /bin/sh is
  dash, but not if it's bash. My hunch is that this might be related to
  not having a controlling TTY attached when apt-get is run by cfagent.

  I don't have enough information at this point to be confident it's not
  related to the way I'm invoking it or to file a useful bug report
  against anything. I haven't worked on it recently, but I have notes
  saying it might be related to bug #439763.

I use the following, but there are likely better ways to do it nowadays:

- Before doing anything else:
  /usr/bin/apt-get update -qq --trivial-only

- To install all available updates, security and otherwise:
  /bin/sh -c 'DEBIAN_FRONTEND=noninteractive DEBCONF_REDIR= /usr/bin/apt-get -o="DPkg::Options=--force-confdef,confold" upgrade -qq -y' ifelapsed=65

- To install a particular package (%s to be replaced with the name):
  /bin/sh -c 'DEBIAN_FRONTEND=noninteractive /usr/bin/apt-get -o="DPkg::Options::=--force-confdef,confold" install -qq -y %s'

- To remove a packages (%s to be replaced with the name):
  /bin/sh -c 'DEBIAN_FRONTEND=noninteractive /usr/bin/apt-get remove -qq -y %s'

On Sat, Jan 31, 2015 at 12:53:32PM +0100, Michael Zoet wrote:
> You can do updates with Puppet (or every other configuration
> management tool you like) but using it for updating the whole system
> is not the way I would go. You would need to create a complete list
> of installed packages on the server and keep this up2date in Puppet.

This is more or less the approach I take for updating MacOS X with
softwareupdate(8), as it has fewer packages and a worse history of
updates breaking things than Debian and Ubuntu.

William Aoki     KD7YAF    waoki@umnh.utah.edu    5-1924

Reply to: