Re: [Ltsp-developer] pam_sshauth update - status update, ready for hacking?

[Scott B. <sba...@le...>]

On Mon, Apr 04, 2011 at 04:56:56PM -0700, Vagrant Cascadian wrote:
> On Mon, Apr 04, 2011 at 09:36:44AM -0500, Scott Balneaves wrote:
> > On Wed, Mar 30, 2011 at 08:55:01AM -0500, Scott Balneaves wrote:
> > > On Tue, Mar 22, 2011 at 09:52:37AM -0500, Scott Balneaves wrote:
> > > 
> > > By way of an update, I've progressed reasonably well along getting things to
> > > work.
> 
> very exciting!
> 
>  
> > I didn't get a chance to update this before I went away to my son's Basketball
> > tourney on the weekend, but I'm happy to report that I actually got a
> > successful login, and desktop start using pam_sshauth on the weekend.  In
> > keeping with using retro XDM, and for nostalgia purposes, I started TWM
> > remotely. :)
> 
> go scotty "retro nostalgia" balneaves!

Yeah, I'm all about the oldschool.  WORD TO YOUR MOTHER, YO!

> > I simply had to create a custom script for the x-window-manager binary, and xdm
> > picked it up automatically.
> > 
> > At this point, tonight I'll spend some time cleaning things up, and trying to
> > get manual pages written, and blow away my chroot and "do it properly".
> > Specifically:
> > 
> > 1) Use "pam-auth-update" to manipulate the actual pam configs, as opposed to 
> >    diddling with the pam configs using vi.  My understanding is that this is
> >    shipped as part of the pam packages, and so *should* be a good bet that
> >    it'll be available on all Linuxes.
> 
> it uses debconf, so my guess is it's debian and derivatives only...

Crap.  So, one supposes other distros will need to perform sed -i magic.  Oh,
well.

> > 2) Use update-alternatives to set the x-window-manager link.
> 
> this should happen automatically with most window managers and/or desktop 
> environments when installing the package.

Right.

> > I know dynamic host selection at login time is something we need, so I'll also
> > code up a "gethost=" parameter for the pam_sshauth module.  It'll point to an
> > executable, of which I'll expect to read one line containing a newline
> > terminated host ip or name that will be used as the basis to select a host to
> > log in on.
> > 
> > Finally, I know we have the ability, within LDM, of selecting from a menu which
> > host to log in on.  Most greeters don't have this ability, however, my
> > understanding is that we can code up greeters for LightDM using HTML, as it
> > used webkit to render the greeter page.  I'm imagining we can somehow populate,
> > and then return the host from that page.  In that case, simply pre-setting the
> > PAM_SSHAUTH_HOST environment variable should have the intended result, so I
> > think we can handle that use-case.
> > 
> > Once I get all this done in the next day or so, I'd wonder if any interested
> > LTSP hackers would have time to get together for an evening online, and see if
> > we can somehow bolt this into the ltsp-build-client command?
> 
> so, you're thinking of an ltsp-build-client hook to use this as an alternate 
> method for fatclients?

Well, as an alternative (for now) for both fat and thin.  Here was the plan we
(very, very vaguely) hashed out at the hackfest.

Us maintaining our own DM is kind of difficult: it's a lot of C code, and
besides, pre-existing DM's will do theming and look-and-feel stuff way better
than we'll ever be able to: K people would like their thin clients to present a
KDM login, Gnomes will want GDM, etc etc.  For us to write, maintain, etc.
greeters for all these environments is a chore.

The point of the pam module was to get the ssh auth and tunnel that we use,
but take advantage of the DM's, so that we could, in theory, fit nicely into
any environment.

Now, we've got some "special" things in LDM, like the guest login, etc, that we
don't want to use.  For that, we could look at LightDM, which supposedly allows
you to create your greeter interfaces using just HTML.  We could craft an LTSP
"page" that allows for the login, plus adds in the forms and menus we want for
things like host selection, guest buttons, etc.  Then we're just maintaining a
"web page", rather than an entire DM.

Plus, by using the PAM stack, we should be able to support things like smart
cards, fingerprint login, etc., since all of these things have PAM modules, so
it's "just" a case of chaining the right modules together and tying that to the
ssh login, and we're golden.

Of course, right now, we have multiple places where we can execute scripts:

1) Before X starts (can still do this with RC scripts)
2) After X starts, but before login (I'm guessing we can set up an Xsession.d
   script to do these)
3) After login, but before desktop launch (This can be handled with a callout
   in our x-desktop-manager script)
4) Post desktop scripts.

And, of course, others I may have forgotton about.

Since this is a fairly fundamental change, and since we're now within "striking
distance" of making it happen, I think it might be useful to have a discussion
on how we'd like to handle this.  There's two ways that I can see:

1) Decide that, on a going-forward basis, we'll support both "old" LDM, and
   PAM logins, and so maintain both in the same tree, or:
2) Decide that ditching LDM's the way to go, fork the branch, and start coming
   up with an "LDM-less" version of LTSP, and working towards supporting all
   DM's, with the "official" DM being something like LightDM, with our extra
   bits built in.

I'm happy to go either way, but my suspicion is, given our limited developer
base, and the clear advantages of going with a PAM stack enabled
implementation, #2 probably makes more sense.  We could call that "LTSP6", and
hack on it until we get it to the same level as LTSP5, and then cut over
cleanly.  But, as usual, I speak only for myself :)

Cheers,
Scott

-- 
Scott L. Balneaves | Nothing sickens me more than the closed door of a library.
Systems Department |     -- Barbara Tuchman
Legal Aid Manitoba |