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: