[443] in athena10
Re: Automatic updates for Athena 10
daemon@ATHENA.MIT.EDU (Kenneth Arnold)
Mon Aug 18 14:04:56 2008
Message-ID: <48A9B98F.90804@mit.edu>
Date: Mon, 18 Aug 2008 14:03:59 -0400
From: Kenneth Arnold <kcarnold@MIT.EDU>
MIME-Version: 1.0
To: ghudson@mit.edu
CC: athena10@mit.edu
In-Reply-To: <200808170723.m7H7N7Fm028968@outgoing.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Running off LVM snapshots could solve all these problems easily. You
don't have to avoid updating the master disk while a user is running in
a snapshot; the next login will simply take the updates. No verification
is needed since the user can't easily change the master image. And
logins don't have to be blocked either, if the update process takes a
snapshot (that the login then knows to use) right before running the
updates. There's an obvious little race condition on which snapshot to
use, but that should be solvable by a lock.
-Ken
ghudson@MIT.EDU wrote:
> Here's the current status of the auto update:
>
> * It's implemented and, as far as I know, working. It's hard to know
> how well an auto-update is working until there are updates for it to
> take, so I've installed it on my office machine and will see how it
> goes.
>
> * It's using Anders's suggestion for ensuring that debathena-cluster
> (or debathena-workstation or whatever metapackage you have
> installed) doesn't get deinstalled. If it's invoked via cron and
> someone is logged into gdm, it downloads updates in the background
> so that logins aren't blocked for as long when the update actually
> happens.
>
> * A separate package, debathena-reactivate, owns the logout hook. The
> plan is that reactivate will also clean up user processes from the
> previous login and run a "fast verify" (config file cleanup,
> basically) between logins. It might also do a slow verify (full
> package check) every ten logins or so; not sure about that idea.
>
> * User feedback is not there yet. Logins are blocked during updates
> but there's no visual indication that an update (or in the future,
> slow verify) is happening. To do user feedback, I need to write a
> program which displays a message in a window at the top of the
> display, retrying periodically if the display dies, until it is
> killed. This is a little tricky because Xlib assumes that the
> program will abort if the display dies. That can be worked around
> by using a pair of processes. This is more work than I really want
> to do, so I'm not sure where it will fit into the time I have left.
>
