I have a lab full of workstations running Ubuntu 8.04 (Hardy Heron). My predecessors made a hackish bit of cron script to update, upgrade, and clean daily. I like the fact that it requires zero attention, but want to stick as close to distro-supported methods as possible, so future admins can find and understand it easily. Specifically, it seems that there is infrastructure in Ubuntu to do this more cleanly, so I'd rather use that instead. What does this entail?
This question was inspired by this one, which has a decent but scattered answer. What's the bottom line, based on the documentation?
This answer is based on reading the following files:
which are part of packages (including
unattended-upgrades
andupdate-notifier-common
) included in the standard Ubuntu installation. There are other tools available from the distribution that could achieve the same ends, such asapticron
andcron-apt
.In the file
/etc/apt/apt.conf.d/10periodic
, add a lineThis configures Apt's periodic scripts to run an unattended upgrade every day. For a longer interval, increase the
1
to a larger number. A0
for this variable would mean 'disabled'.In tandem with this, the
autoclean
line should be enabled by replacing a0
there:By default, Ubuntu 8.04 only configures automatic unattended upgrades from the
hardy-security
archive. This will cover you against security vulnerabilities, but not for general bug-fix releases. For that, you need to enable thehardy-updates
archive in/etc/apt/apt.conf.d/50unattended-upgrades
:Ubuntu's spec for this feature appears on a wiki page. Note that Debian systems seem to have the same exact infrastructure, apparently from this feature migrating upstream.
While it is more than possible to automatically upgrade a Debian or Ubuntu system using either the solution that Novelocrat suggested or using something like apticron or cronapt, I have to question how sensible this is. This was mentioned on the question you linked to, but you need to decide if you object to the downtime that may happen when services automatically restart when they get upgraded. Often, the more packages that are getting upgraded, the longer your service might be down for. This is due to packages incorrectly stopping the service before it gets installed and then starting it again then it has installed. Many packages to the right thing of just restarting when the package has installed. This can be a particular problem for example, MySQL, where the Debian package will run a table check when it starts up, and if you have a large database, this can cause your tables to lock until it has finished. Automatic upgrades also don't give you the chance to check the package for problems.
What we do is use Puppet to install 99% of packages when we ask them to. I run apticron on all the servers, and every morning, run a script that reads those mails, removes blacklisted upgrades, like MySQL, Tomcat and PostgreSQL, and updates the manifest file with the package name and the version. When this manifest gets pushed out, it upgrades those packages. We then have to do the blacklisted ones by hand when we can afford downtime.
No need to do anything complex. Just go to System > Administration > Synaptic Package Manager > Settings > Repositories > Updates and select Install security updates without notifications.
That's it