LTSP DNS round robin cluster

I have finally completed the LTSP DNS round robin cluster implementation using Vmware server 2. The contents of this post detail what I did to cluster a LTSP service over three Edubuntu servers.

The background information for this implmentation and the idea refinement came from reading the Edubuntu handbook, specifically the section on Multiple server setup. I began with one edubuntu server, whose primary purpose was to be a DNS server. The details of its construction are in a previous post, titled, DNS server. I then set up two more servers, both Edubuntu servers, one called "edubuntu" and the other called "bumble" (inspired by The Complete FreeBSD...). The DNS server (called dns-server) was set up to resolve the name to 3 A-records, one for each of these three servers.

I decided that the server called edubuntu would be the primary server within the cluster. So based on the ideas from the Edubuntu handbook, this server would then be the dhcp server, the tftp server and the nbd server to which thin clients would connect and use to boot the nbd image. After which the thin clients could use any one of the three servers as the ltsp server.

This meant that the following changes needed to be made to the Edubuntu server. Firstly, in the lts.conf file I needed to set the LDM_SERVER variable. The handbook suggests setting it using a script that randomly cycles through IPs or host names so that you have a different LTSP server each time a client connects. It occured to me that there is already a service that provides this, DNS. So mine is set to which resolves to 3 different A-records, one for each of the 3 servers in my cluster. Thus any one of them, relatively randomly, could be the LTSP server that the client connects to.

Secondly, because I wanted the files of the user to be available to them regardless of which LTSP cluster server they connected to, I followed the suggestion of the handbook and have one server, the one called edubuntu in my example, as the central file server. Thus the other LTSP servers authenticate against this server and mount the home directory of the user from that server. The handbook suggests a number of methods to achieve this, such as ldap, NIS and winbind. I happen to have used winbind before when creating an NT4 domain at one of the schools for central auth and mounting home directories, so this seemed like the best option considering I already knew how to do it (I know Barry thinks I'm nuts and that I must have been sacrificing chickens in the back yard to get it to work, but it seemed like a better idea than wasting time learning something new like ldap). The work done in getting the other LTSP servers (dns-server and bumble) to auth against the primary server (called edubuntu - probably confusing you I know) is captured on the e-yethu school wiki howto.

The final step was ensure that the clients could log in to the LTSP server that it had chosen from the DNS response. Edubuntu uses LDM (LTSP display manager) to handle the thin client logins and it runs on the thin clients themselves, creating an ssh session with the server when the user logs in.  Because LDM uses ssh to connect to the server, the final step involved ensuring that each of the servers have the same private key and that the client image has the associated public key for each of the servers. This was done by pushing out the private key of the primary server (called edubuntu) to the other two servers (called dns-server and bumble), and then copying the public key to the ssh_known_hosts of the nbd image that is tftp'ed by the clients. This ensured that the clients could log in to any of the ltsp servers.


Display comments as (Linear | Threaded)

    No comments

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.