Just giving people a status update on where ldm2 is at.

So, over the last couple of days, here's what's working:

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.

So, I sat down last night for a few minutes to think about
the whole Scalability/Multiple login hosts thing that Francis
has brought up.

Here's whats coming to mind.

We've got an environment variable, called LDM_SERVER, which
can override the SERVER environment variable.  The most
perverse case is a situation where we want the user to be
able to select which host they want, through a drop down
menu on the greeter.  However, I'd suspect in most instances,
an administrator would like to simply institute some kind
of load-balancing/round robin, etc.

Here's what I propose:

LDM_SERVER could be a space separated list of hosts.  Something
like

LDM_SERVER="192.168.0.254 192.168.0.253 192.168.0.252"

Or, names, if the administrator sets things up in the
chroot for /etc/hosts and/or resolve.conf.

The greeter would present the list as a set of hosts,
with the default, for lack of a better method, being
the first one.

This has the following advantages:

1) For very simple cases, one could simply define this var
in lts.conf
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

Then policy can be instituted as to what hosts get reported.
Things like mille-xterm's agent can be put in here, with no
need to modify the greeter or ldm.
3) I like vagrantc's suggestion that it should be based
somehow on the hosts in the ssh_known_hosts file.

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.

Thoughts?

Cheers,
Scott

-- 
Scott L. Balneaves | "Eternity is a very long time,
Systems Department |  especially towards the end."
Legal Aid Manitoba |    -- Woody Allen

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net

Reply via email to