> Date: Fri, 27 Jul 2007 09:12:12 -0500
> From: Scott Balneaves <[EMAIL PROTECTED]>
> Subject: LDM2 update, thoughts about multiple login hosts.
> Scripted greeter now working.
> Indication of password failure, and password re-entry now working.
> Password expiry working.
> Autologin working.
> Support for LDM_DIRECTX working.
> New rc.d infrastructure working, with the replacement of the
> delayed_mounter with a few-line shell script.
Nice work, Scott.
> LDM_SERVER could be a space separated list of hosts. Something
> like
Yes.
> The greeter would present the list as a set of hosts,
> with the default, for lack of a better method, being
> the first one.
Yes.
> 1) For very simple cases, one could simply define this var
> in lts.conf
Well, ${SERVER} would be used in the simplest cases, when $LDM_SERVER
wouldn't even be set, right?
> 2) If we put something in the ldm screen script along the
> lines of:
> if [ -x /path/to/some/script/that/creates/host/list ]; then
> LDM_SERVER=$(/path/to/some/script/that/creates/host/list)
> fi
Yes.
> 3) I like vagrantc's suggestion that it should be based
> somehow on the hosts in the ssh_known_hosts file.
There could be a couple samples included:
/usr/share/doc/ldm/scripts-that-create-host-list
And ltsp-update-sshkeys should support $LDM_SERVER, so it adds the
host keys for all the servers listed.
Perhaps LDM could do a check to see if any of the hosts in LDM_SERVER
(or $SERVER, if $LDM_SERVER isn't set) are in the ssh_known_hosts
file, and if *no* servers in that file are available, it could print
a nice notice that says something like "Note: Currently no servers
appear to be available. Your administrator may need to run the
ltsp-update-sshkeys command." The way things have been, if you change
your server's IP address (which is a very common practice in real-life
scenarios, as you're getting things set up the first time, and
deciding on your server IP addresses) logins on TCs just totally break
until you 1) happen to read some documentation or 2) enable local
logins on the TC and read the LDM log.
> This seems fairly easy to implement, as it would only mean
> some minor mods to ldm and the greeter, and would allow
> administrators to implement fully automatic load balancing
> by whatever policy they desire based upon a shell script they
> provide.
Yes. Brilliant.
> Date: Fri, 27 Jul 2007 15:15:27 -0500
> From: "Jim Kronebusch" <[EMAIL PROTECTED]>
> Subject: Re: LDM2 update, thoughts about multiple login hosts.
> I would really like to see LDM_SERVER be able to accept fully qualified dns
> names. Then
> I could simply point LDM_SERVER=ltsp.mydomain.com and set up a round robin A
> record in
> DNS where ltsp.mydomain.com resolves to either a single IP or a group of
> IP's. Then DNS
> would actually be able to handle the load balancing without any need for
> configuration
> changes on the server if a LTSP server is added or removed from the pool.
As long as the ssh_known_hosts file is kept up-to-date, Scott's
proposal would support this with no trouble. But if you provide
a script that just does the nslookup and gets the list of round-robin
hosts from DNS, your script could then ping each server (or whatever
you want) be sure it's up before handing the list back to LDM.
Of course...I think it would make more sense for LDM itself to fail
gracefully if the chosen server turns out to be unavailable, so
perhaps this shouldn't need to be built into the
script/that/creates/host/list.
> Any updates on the status of local application support in LDM2, or isn't that
> related to
> LDM?
There are problems to solve here that aren't particularly LDM-related.
Basically, as I understand things, the primary problems are 1) TCs
knowing about the passwd/shadow/group databases, and 2) TCs securely
mounting user home directories.
Inspired by conversations with Gadi and Scott, I've started working on
what we're calling libpam-ssh and libnss-ssh. These will (someday,
when they're working...) effectively add a remote ssh-server's
passwd/shadow/group databases to the local system, so this should
provide a relatively simple solution (in contrast to LDAP) to problem
#1, above.
--matt
--
Open Source Software Engineering Consultant
http://majen.net/
--
edubuntu-devel mailing list
edubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/edubuntu-devel
