[379] in athena10
Re: Larvnet design discussion
daemon@ATHENA.MIT.EDU (Timothy G Abbott)
Tue Aug 5 15:47:27 2008
Date: Tue, 5 Aug 2008 15:47:12 -0400 (EDT)
From: Timothy G Abbott <tabbott@MIT.EDU>
To: ghudson@mit.edu
cc: athena10@mit.edu
In-Reply-To: <200808051752.m75HqNEH020805@outgoing.mit.edu>
Message-ID: <alpine.DEB.1.10.0808051517420.21810@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
I might consider trying an /etc/X11/Xsession.d script rather than using
PAM, if you just want a little script to run whenever someone logs in
graphically. It sounds like liblarv is trivial enough it could be done
with a script, rather than a C program, and might be easier to maintain.
A simple PAM module would probably also work, but it's probably best to
keep monitoring code out of PAM if possible, since code running in the PAM
context is automatically security-sensative.
Either way, I'd have the larvnet system check whether the machine was a
cluster machine before doing anything (to avoid annoying people with
strong privacy who use non-cluster workstations) and which thus can be
included in the default debathena-pam-config /etc/pam.d/gdm file.
-Tim Abbott
On Tue, 5 Aug 2008, ghudson@MIT.EDU wrote:
> I'm knocking down the larvnet item for the eventual cluster
> deployment. There are four parts:
>
> * Package liblarv (done pending checkin)
> * Package busyd (done pending checkin)
> * Integrate with gdm (not done)
> * Add to cluster metapackage (not done)
>
> liblarv is a very simple library; it knows how to touch or remove a
> flag file which means "this workstation is in use", and how to send
> off a UDP packet to larvnetd indicating the status. Since UDP packets
> can be lost, busyd acts as a backup mechanism; it listens to a port
> via inetd and, using liblarv, checks the flag file and responds with a
> status packet.
>
> In 9.4, liblarv is integrated directly into the xlogin code. In
> Athena 10, I was thinking the best option is to write a simple PAM
> module which gets installed into /etc/pam.d/gdm via a
> config-package-dev transformation. A few variations on the low-level
> implementation of this plan are:
>
> * Create debathena/libpam-larv with the PAM module and
> config/gdm-larv with the installation into /etc/pam.d/gdm.
> * Shoehorn both into debathena/libpam-dev.
> * Shoehorn both into config/gdm-larv.
>
> Opinions before I go ahead? Since this is a very site-specific PAM
> module I like the simplicity of a single package for gdm integration
> but I don't feel strongly about it.
>
