[409] in athena10
Re: Automatic updates for Athena 10
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Aug 11 16:22:29 2008
From: Greg Hudson <ghudson@MIT.EDU>
To: Kenneth Arnold <kcarnold@mit.edu>
Cc: athena10@mit.edu
In-Reply-To: <4888D816.4030604@mit.edu>
Content-Type: text/plain
Date: Mon, 11 Aug 2008 16:21:41 -0400
Message-Id: <1218486101.12433.177.camel@error-messages.mit.edu>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
On Thu, 2008-07-24 at 15:29 -0400, Kenneth Arnold wrote:
> There is also the unattended-upgrades package; the wiki page isn't clear
> that they actually implemented something. I only know that it works for
> security updates; I haven't looked at what it does inside.
I've looked into this and, unfortunately, it appears to only be 95% of a
solution. By simply dropping a file into /etc/apt/apt.conf.d, we could:
* Add hardy-updates and all of the debathena-components to the allowed
origins for unattended upgrades.
* Turn on unattended upgrades.
* Turn on Install-Recommends to get aptitude-like behavior for
Recommends.
Unfortunately, although I haven't completely verified this, it looks
like unattended-upgrade always acts like "apt-get upgrade", in that it
will never install a new package.
Also, unattended-upgrades wouldn't give us any hooks to implement
desynchronization or running only when no user is logged in. I'd be
willing to sacrifice those niceties at least for the moment (see below),
but we really need a solution which does full upgrades.
I also looked into cron-apt. It's really a very thin wrapper around
apt. It's fairly configurable but since we don't fit into its default
use case, I don't see much value in using it. As with
unattended-upgrades, the target audience seems to be people who want to
do simple critical security updates automatically and let the admin user
take care of everything else.
So, I think I get to do it from scratch. My general integration plan
is:
1. Divert /etc/gdm/PostSession/Default (which does nothing by
default). This script runs as root after a logout session and gdm
blocks until it is complete. DISPLAY is set, but the X server might be
dead in some cases.
2. Create a cron.hourly job which checks if anyone is logged in and
runs an update, ideally blocking logins while it runs.
The actual update process is just "aptitude update && aptitude
full-upgrade" so most of the scripting will be the safety checks around
it, possibly an attempt to communicate to the console that an update is
happening, etc.. Also, /etc/sources.list.d/debathena.list will be
updated depending on cluster info.
On desynchronization: I am less concerned about this than I was for 9.4
updates. First, Athena 10 updates should typically come in small pieces
since we don't batch them up for months at a time. Second, the data
will be served by athena10.mit.edu, so the load on the AFS servers
should be lessened by the AFS cache on that machine. And third, the
network for clusters is much better than it used to be.
