Am Samstag, den 27.08.2005, 05:57 -0400 schrieb Coach Basti:
> Good Day,
> 
> Everytime I boot a client, it is not assured which server it will
> connect to. Is there a way for me to force a client to connect and
> boot to a specific server from a collection of servers?
> 
> My network: 4 clients, 2 servers

There are several methods available to determine which client connects
to which server. They apply to different steps in the startup process.

****Method A: Client selection via DHCP.

This means you have two DHCP servers, both "not authoritative". You
simply list the clients to boot off server A in that dhcpd.conf of
server A (and vice versa).

Pro: Completely different bootup situations; you could upgrade
the /opt/ltsp tree on server A and the "B"-clients would not notice

Con: You need two /opt/ltsp trees. Clients can not easily switch between
both servers (only the admin can do that with changes in DHCP config)

****Method B: One bootup server, settings in lts.conf

You have only one server supplying /opt/ltsp, the DHCP service and the
TFTP service. Where the X login screen comes from can be set via
lts.conf, with the XDM_SERVER keyword (see
http://wiki.ltsp.org/twiki/bin/view/Ltsp/LtsConf#XDM_SERVER
for details)

Pro: Only one /opt/ltsp tree to keep updated, easy changing that param

Con: Clients can not choose themselves.

****Method B2: Only one bootup server, but with X-chooser

I don't know if this can be done without changing LTSP scripts (at least
the "x" screen script, probably found
in /opt/ltsp/i386/etc/screen.d/ !?)
The Xserver (the software running on the terminal machine and serving
screen and input devices to the software on the server - uhhmmmm :-)
can be started up like (what LTSP does)
X -query 1.2.3.4
which means it politely asks the server 1.2.3.4 wether that one is ready
to give a login screen to the terminal. But there are other options as
well, like
X -indirect
which, iirc, means to make a broadcast query and take the X server with
the smallest load (or shortest reply time?)
About this, you better read the X manual page, which should describe
this in length. To try what this looks like in real life, you could
install the "Xnest" software package (if it is not already installed),
and enter
Xnest -query 1.2.3.4 :2 (and the like, :2 means using virtual screen 2)
in a xterm to see a X login in a box, quite what it would look like on
the terminals (I love Xnest ;-)

> I want all clients to be able to choose from either server A or server B.
> Is it possible? And is this possible to implement using etherboot?

Validate the different X options. KDM or GDM might implement a feature
to not only offer local login but change to another login manager - I'm
not to sure, but I saw something alike that a while back. Others
probably will know better?

Basically, you could implement this using etherboot as well, using some
weird home-brew etherboot menu (which can be done not to complicatedly),
but I'd recommend using etherboot for the regular boot and doing the
"choosing" lateron.

If you need the high-availability (for example, if both servers tend to
be down during different times of day or so), you could implement too
completely same dhcp setups, not authoritatively, with fixed addresses
for all your clients. Then any client booting up will take any server
available and boot off that server (you need two complete NFS trees then
as well). You could offer them the X chooser anyway....

Regards,
Anselm




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_____________________________________________________________________
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