[6455] in Release_7.7_team
Re: Login chroots
daemon@ATHENA.MIT.EDU (William Cattey)
Fri Oct 9 12:55:06 2009
From: William Cattey <wdc@MIT.EDU>
To: release-team@mit.edu
In-Reply-To: <200910091634.n99GYSR9013990@outgoing.mit.edu>
Message-Id: <EF128187-BDAF-423A-A24B-9013B16F88F0@mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 9 Oct 2009 12:54:58 -0400
Cc: Greg Hudson <ghudson@mit.edu>
X-Spam-Flag: NO
X-Spam-Score: 0.00
From the standpoint of pragmatically meeting user needs, then yes we
should pursue getting rid of LVM chroots so as to make the user
experience faster and thereby better.
Still, it would be amazing if the performance problems could be
indentified and solved so that we could show the world a non-
disruptive way to take updates. Although traditional Athena systems
have idle time when logged out, pretty much everybody's home system
stays logged in all the time.
Maybe we should investigate a grant to solve the performance problem
and demonstrate proof of concept for a radical way EVERYONE should set
up their computers in the future.
-Bill
On Oct 9, 2009, at 12:34 PM, ghudson@MIT.EDU wrote:
> (Summarizing a zephyr conversation this morning.)
>
> LVM-based login chroots do four things:
>
> 1. Reduce the likelihood that a user's login activities will affect
> the reusability of the machine.
>
> 2. Allow a user's login activities to include becoming root and
> mucking around with the system (e.g. adding packages).
>
> 3. Allow the system's real root to take package updates without
> affecting the user login session.
>
> 4. Slow everything down, particularly the process of logging in.
>
> Login chroots have already been disabled on quickstations because of
> (4). jdreed wants to consider making login chroots opt-in on cluster
> machines (I'm not sure how one would do this, but ignore that for the
> moment).
>
> I observed that if we're willing to sacrifice (3) (and we clearly are,
> on quickstations), then it becomes substantially easier to implement
> login chroots using union mounts (trac #97). Anders noted the
> possibility of a user installing a package in the login chroot and
> then the updater runs in the real root; files modified in the login
> chroot would not see the changes in the real root, while files
> unmodified in the login chroot would. That could cause problems for
> the dpkg database files in particular.
>
> The 9.4 story for auto-updates is to run them while users are logged
> out, and disable logins while updates are running. If we aren't doing
> LVM-based login chroots, we should probably implement this instead,
> whether or not we do union-based login chroots. Right now
> auto-updates could do things like break a user's running Firefox; I
> see this occasionally on my stock Ubuntu machine.
