Hi Scott, Scott Balneaves a écrit : > 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. > You're doing an amazing job! > 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 > Thanks for your interest.
I think that what you suggest is good. It will be easy to expand. In Mille-xterm, the variable XDM_SERVER, if not defined, is fetch from the loadbalancer server. If the variable is defined, than the server defined is actually used. At some point, it's hard to know what is overriding what. Let's take care of that. I agree that it could have two mechanism for loadbalancing. One that is built-in and simple, and another more complex, complete and scalable. For simple loadbalancing, maybe I would let the LDM_SERVER as is and create a new variable for matter, for example : LDM_SERVERS_LIST. I understand that for simple loadbalancing, servers state won't be used and only a randomize on the list will be done. That's good and scalable. But at least, a server that is down should be automaticaly removed from the list. Yesterday, I tried to figure out what was the impact of loadbalancing architecture. For example, if the clients pools every server in a while to get their state and compute the best server, then it's not scalable. Here are some scenarios I'm looking for : http://pastebin.ca/635973 Another difference is that previously with XDMCP, the server was chosen before the login, in the startx script. It could be better to chose it at login time. LDM enables that because it's local to the terminal. Is that what you though about? Have a nice day, Francis Giraldeau -- Francis Giraldeau, Ing jr. Analyste Infrastructure Directeur Qualité Téléphone : (819) 780-8955 poste 1111 Sans frais : 1-800-996-8955 Télécopieur : (819) 780-8871 Revolution Linux Inc. 2100 King ouest - bureau 260 Sherbrooke (Québec) J1J 2E8 CANADA http://www.revolutionlinux.com Toutes les opinions et les prises de position exprimees dans ce courriel sont celles de son auteur et ne representent pas necessairement celles de Revolution Linux Any views and opinions expressed in this email are solely those of the author and do not necessarily represent those of Revolution Linux ------------------------------------------------------------------------- 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
