[450] in athena10
Re: Login chroot design for Athena 10
daemon@ATHENA.MIT.EDU (Kenneth Arnold)
Tue Aug 19 14:08:43 2008
Message-ID: <48AB0BFE.3050706@mit.edu>
Date: Tue, 19 Aug 2008 14:07:58 -0400
From: Kenneth Arnold <kcarnold@MIT.EDU>
MIME-Version: 1.0
To: ghudson@mit.edu
CC: athena10@mit.edu
In-Reply-To: <200808191726.m7JHQ3kp013052@outgoing-legacy.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
ghudson@MIT.EDU wrote:
> * We need to pick a size for the logical volumes--small enough that
> we don't overfill cluster machine disks and big enough that we
> don't run out of space for software packages. /tmp and /var/tmp
> will be coming from the host so that's not an issue. I'm not sure
> if snapshots
>
did you mean to finish a sentence there?
> * The cluster-software package wants to be installed in
> login-master, not on the host. (So it gets removed from
> debathena-cluster.)
>
> * login-master probably wants debathena-workstation installed, not
> debathena-cluster. (In particular, we don't want the login chroot
> to be trying to create its own interior login chroot!)
>
Neither of these should be a problem. A chroot is not a VM, so gdm will
only ever be running out of one place (the original /).
As far as updating... it seems like someone else was thinking about this
problem too: http://kerneltrap.org/Linux/LVM_Snapshot_Merging
Failing that (it may not make it in time), the only entirely safe bet is
locking new logins for the duration of an upgrade.
That may not be too bad: if updates run often, the size of a single
upgrade is probably small. Anyone know an aptitude trick to get it to do
the minimally consistent chunk of an upgrade at a time? (e.g., if the
mirror pulls in several separate uploads worth of updates, but they can
be applied independently)
-Ken
