[K12OSN] Re: Tossing around an idea...need some input

[Matt Oquist]

> Now....notice the "next server" line up above and the    
> 
> option root-path              "10.0.15.253:/opt/ltsp/i386";
> 
> These are in the global section....one question I had is....if I put these
> in the workstation declarations down below pointing to Server #2
> (10.0.14.253 ) would that override the globals?  Example:

Yes.

Also, I wonder if you could set up internal DNS and use hostnames
instead of IP addresses for the root-path and next-server.  Assuming
for our discussion that your two LTSP servers are 10.0.14.253 and
10.0.14.252, you would put this in your DNS zone file (after the SOA
and all that):

ltsp    A       10.0.14.252
ltsp    A       10.0.14.253

According to "DNS & Bind" (a book every administrator should have)
this will give you Round Robin Load Distribution (p. 273).

Your DHCP options would then be:
option root-path        "ltsp.daves.school:/opt/ltsp/i386";
option next-server      "ltsp.daves.school";

The DNS server will alternate between the IP addresses.  Since the
kernels on the two LTSP servers will be identical it probably doesn't
matter that a given client could get the kernel from one server and
root from the other.  And since (I assume) the client only mounts root
once, each client should get its IP address for 'ltsp.daves.school',
mount root, and be done with it.

A problem could arise if a given client would need to ask for the
LTSP server's hostname later on.  For example, if the client has an
application running and that application creates temporary files on
the server, and the client asks for "ltsp.daves.school" and gets the
other LTSP server's IP address, then the client may try to communicate
with the wrong server about the application running on the other
server, and it might matter.  Or something like that.

This is all assuming that those DHCP options can use hostnames instead
of IP addresses, and I don't know for sure about that.  I guess
I could test...

/me tests

It appears to work fine to use hostnames for those options in
dhcpd.conf.


> OR....another intriguing idea for failover is to have a script that pings
> the servers (Server 1 and Server 2) to see if they are "alive"....it would
> assume a dhcpd.conf pointing to Server 1.....but if Server 1 turns out to
> be "dead"....do something like this....
> 
> Ping Server 1....if alive continue using dhcpd.conf.....if dead then...
> 
> service dhcpd stop
> mv dhcpd.conf  dhcpd-serverone.conf
> mv dhcpd-servertwo.conf  dhcpd.conf
> service dhcpd start

Yep, this is also a good idea.
My preference would be to use a symlink for dhcpd.conf, pointing to
one of your two confs.  Then, in case of trouble:

$ service dhcpd stop
$ ln -sf dhcpd-servertwo.conf dhcpd.conf
$ service dhcpd start

> this is crude I know, but just trying to illustrate the idea....

Dude, that's how *nix works.  It is full of delightfully fun, crude
stuff just like that.  :)

/me has been reading the Unix Hater's Handbook.  It's not as good as
BIND & DNS, but it's still worth reading.

What I'm working on right now is a simple hot-spare setup...for
any Linux box, but with LTSP in mind.  This would enable a low-end box
with enough disk space to be a backup and pinch-hitting hot spare for
a beefy LTSP server.  The spare may not be able to run [m]any thin
clients, but it can certainly still do DHCP & DNS for a network with
lots of non-LTSP boxes depending on it.  (Yes, this will consist
almost entirely of 'rsync', but I want to have a text file listing
config files *not* to overwrite on the spare *until you need to use
it*.  And then I want a single command to move all the configs
appropriately and give the pinch-hitter the bat.)

Anywho, that's related to what you're working on so I thought I'd
mention it.  :)

--matt

-- 
--
Software Engineering Consultant

718 Fox Hollow Drive
Hudson, NH  03051  U.S.A.
+1 603-881-3808
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/k12osn/attachments/20050813/cd887ca0/attachment.sig>