[452] in athena10
Re: Login chroot design for Athena 10
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Aug 19 14:28:26 2008
From: Greg Hudson <ghudson@MIT.EDU>
To: Kenneth Arnold <kcarnold@mit.edu>
Cc: athena10@mit.edu
In-Reply-To: <48AB0BFE.3050706@mit.edu>
Content-Type: text/plain; charset=utf-8
Date: Tue, 19 Aug 2008 14:27:41 -0400
Message-Id: <1219170461.12433.289.camel@error-messages.mit.edu>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
On Tue, 2008-08-19 at 14:07 -0400, Kenneth Arnold wrote:
> 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?
Uh, yes. What I meant to say is I'm not sure what the "size" of a
snapshot LVM is. I guess it's the amount of space allocated for
copy-on-write storage? So if we're snapshotting a 300GB root volume
into a 10GB LVM, that should work as long as we don't modify more than
10GB of files in the snapshot.
> As far as updating... it seems like someone else was thinking about
> this problem too: http://kerneltrap.org/Linux/LVM_Snapshot_Merging
Interesting, but we can't really make use of that right now. (And I'm
not certain how we could make use of it.)
> 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.
So, the advantage brought by login chroots is that updates don't block
the login process as often. But we still have to worry about that case
in our scripts.
I think the current breakdown is:
+ Updates don't block logins as often.
+ Users can install software during logins without guilt.
+ Might be able to punt on verification task, saving effort
- Unusual approach -> higher maintenance costs
- Potential lossiness with dbus or other daemon-to-desktop interaction
