[451] in athena10
Re: Login chroot design for Athena 10
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Tue Aug 19 14:09:44 2008
Cc: athena10@mit.edu
Message-Id: <9F0A95A7-FC4D-43AB-96A8-EB3F296655E4@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <1219168210.12433.274.camel@error-messages.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Tue, 19 Aug 2008 14:08:58 -0400
On Aug 19, 2008, at 1:50 PM, Greg Hudson wrote:
> Since we can't do snapshots of snapshots, it makes some sense to
> return
> to Ken's design of snapshotting the root volume and chrooting into the
> snapshot. But the architectural benefits for the update aren't as cut
> and dried:
>
> * Snapshot the root for the login chroot
> * Start an update of the real root
> * User logins in and logs out
> * Update is still going. Do we:
> - Snapshot it anyway, mid-update?
> - Reuse the snapshot for the next login, instead of deleting it as
> we normally would?
> - Block logins until the update completes?
Blocking logins until the update completes probably makes the most
sense, and users are already used to seeing "This machine is in the
middle of an update, go away".
However, now that this is less trivial than initially thought, I want
to make sure we're doing it for the right reasons. I realize I was
the one who raised the idea of "what if people install a bunch of crap
locally" in the first place. While the chroot/LVM method simplifies
cleanup and updates, it does introduce a whole new approach. To play
devil's advocate: at this point, is it not simply easier to return to
some sort of reactivate-esque approach, or a workstation cleanup/
verifier that runs on boot?
Additionally, if cluster machines are going to be doing all sorts of
magic with chroots and LVM, it's going to make them even more
different from other debathena machines and slightly harder to
support. If we go that route, I'd like to see user-accessible
commands (ie: not simply embedded in rc scripts) to return the system
to a pristine state, or re-snapshot the volume on demand, etc.
Alternatively, we could just say that debathena-cluster is really
really really only for cluster machines, and if you want to install it
on a "private" workstation, you're totally on your own.
-Jon
