[1350] in athena10
Re: the debathena-managed metapackage
daemon@ATHENA.MIT.EDU (Tim Abbott)
Fri Mar 6 22:48:30 2009
Date: Fri, 6 Mar 2009 22:42:31 -0500 (EST)
From: Tim Abbott <tabbott@MIT.EDU>
To: Jonathan Reed <jdreed@mit.edu>
cc: Evan Broder <broder@mit.edu>, Greg Price <price@mit.edu>,
debathena@mit.edu
In-Reply-To: <36BE5734-9AA0-43EB-A886-49F34386B35F@mit.edu>
Message-ID: <alpine.DEB.2.00.0903061953130.15811@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 6 Mar 2009, Jonathan Reed wrote:
>
> On Mar 6, 2009, at 5:52 PM, Evan Broder wrote:
>
> > > > To put a bit more flesh here, the package description lists
> > > >
> > > > 1. configuring the screensaver to allow logouts afer a certain time
> > > > period
> > > > 2. disabling user switching
> > > > 3. disabling console logins
> > > > 4. disabling sshd
> > > > 5. disabling the halt/reboot/suspend commands in gdm and at logout
> > > > 6. setting the root password
> >
> > It seems like there's some strong disagreement about #1, #3, and #4. The
> > traditional Debathena way to deal with this would be to make each of
> > them their own package so that people could install and uninstall them
> > at will, but I'm really not a fan of that in this case.
>
> I withdraw my previous comment about #1. All athena 9 machines offer the
> logout option, and per-user customization to disable it. Since a gconf key
> controls whether the logout option appears or not, perhaps we can do something
> clever like force the logout option on -cluster, and obey the user's gconf key
> (if set) on -workstation.
I don't think forcing the gconf key on -cluster users is useful; they can
always run a build of xscreensaver out of their home directory instead if
they want to avoid the logout button.
> Was there disagreement about #3? I missed it. I said I was on the
> fence, so don't take my comment as disagreement. As for #4, do we
> disable sshd or do we _prohibit_ enabling sshd? These are two different
> things. If we prevent it from being enabled (ie: if you enable it,
> it'll get disabled upon reboot), that's one thing. If we're just
> disabling it by default, that's another. Chroot issues aside, it sounds
> like we create /etc/sshd_not_to_be_run, and then users can nuke it if
> they want (which is fundamentally equivalent to setting SSHD=true in
> rc.conf on athena 9).
Yeah, deleting /etc/sshd_not_to_be_run is about as much work as editing
rc.conf, and has the advantage that it is consistent with how one manages
sshd on other Linux machines users might encounter at other times in their
life.
> I suspect details about #3 and #4 are confusing, so here it is functionality
> wise:
>
> - Both -workstation and -cluster install with SSHD disabled and console logins
> disabled. Users who want sshd on -workstation can remove
> /etc/sshd_not_to_be_run and it won't get put back. Users can also enable
> console logins by doing $foo, and have that setting not be clobbered on
> reboot/update.
Re-enabling console logins is actually somewhat annoying with the current
implementation (at present, we just divert away the 6 files defining
them).
-Tim Abbott
