LTSP Server

From Gentoo Linux Wiki

[edit] Existing Server

http://www.linkstar.com/images/server_linux.jpg

This system is the one which actually serves all of the LTSP files necessary for the client machines to boot up. This could be an existing file- or dhcp-server. Very likely, you use this machine to authenticate your users, and will need to ensure that PAM is set up on the desktop correctly to do so. If you are doing this in your basement, you'll probably set this up to be your desktop system as well. Administrative issues that you encounter will likely occur here.

[edit] net-misc/dhcp

The easiest configuration is to set an existing dhcp server to hand out IP addresses to the thin clients along with appropriate paths to boot images, kernels and boot parameters.

Almost as easy is to set up a new dhcp server in a network that does not already have DHCP servers. A complete guide HOWTO setup DHCP explains the details of how to set up a DHCP server on your Gentoo box.

But if, for some reason, you don't have access to the main DHCP server on the network or your DHCP server is a dumb box like a cheap xDSL router box, you need to set up a new DHCP server that does some more or less ugly hacks to serve the thin clients. The text below explains some possible configurations to make the LTSP system work.

The ugliest solution is to set up two conflicting DHCP servers on the network with the default settings. This has some drawbacks - the thin clients most probably will be able to get the pxe/etherboot -image from the network since their first dhcp request is a bit special in a way that the client requires the server to send a bootrom image. But the second request (made by the booting kernel) has to choose between two competing servers.

Usually the dumb DHCP server is authoritative and "wins" most of the requests made by the clients. If it isn't, you can improve the bets of your #2 server by making it authoritative. The drawback here is that all non-thin clients will also receive their addresses from your #2 server if you don't limit the operation to specific MAC addresses. IMHO conflicting servers is definitely not a proper way to do this.

Luckily there are two more elegant solutions to this. First, you can bind your #2 DHCP server to port 1067. The bootrom images from rom-o-matic support alternative DHCP port 1067, but if you're using a stock PXE bootrom, you have to bind a #2 DHCP server also to port 67. Configuration for Etherboot is located in dhcpd.conf, PXE users should append the kernel options to their pxe config file.

Second, you can use the primary DHCP server to offer your clients their IP addresses, but use the #2 server to send out bootrom images and kernel configuration. The special trick is to use nfsroot kernel parameter. The drawback here is that if the primary DHCP server does not provide thin clients with a host name, you're not able to use the localdev support (I think). Still, AFAIK localdev support is not supported on Gentoo ATM. The third option is to use different subnets for different clients, but I haven't had time to test it yet.

More solutions are described here:

http://wiki.ltsp.org/twiki/bin/view/Ltsp/DHCP#Multiple_DHCP_servers_on_the_sam http://www.ltsp.org/contrib/parallel_dhcp.txt

You can create a bootrom using alternative DHCP port 1067 by selecting Configure -> [X] ALTERNATE_DHCP_PORTS_1067_1068 from the rom-o-matic web site.

Setting the server to use alternative ports can be done by setting

 DHCPD_OPTS="-p 1067"

Setting up two separate dhcp servers (ports 67 & 1067) on the same server machine is possible, but you have to create a custom init script for the second server.

Ok, now let's do some configuration. Here's a sample dhcpd.conf to start with:

 /etc/dhcp/dhcpd.conf
# Global defaults
not authoritative;				# only primary servers use authoritative
default-lease-time		28800;		# 8 hours
max-lease-time			86400;		# 1 day
use-host-decl-names		on;		# Push hostname to clients (on/off)
ddns-update-style		none;		# Dynamic DNS update style (off,interim,ad-hoc)
#range 10.0.0.100 10.0.0.150;			# Comment this if you have another DHCP server

# Network
option subnet-mask		255.255.255.0;	# Duh
option broadcast-address	10.0.0.255;	# Duh
option routers			10.0.0.1;	# The default gateway
option domain-name-servers	10.0.0.1;	# Our router / firewall manages DNS
option log-servers		10.0.0.11;	# The box that accepts remote logging
option nntp-server		10.0.0.11;	# The Novell box is our time server
next-server			10.0.0.11;	# Machine server tftp
#option ip-forwarding		off;		# ???

# Boot
boot-unknown-clients		false;		# Prevent random machines
						# from accidently net booting
allow booting;					# Duh
allow bootp;					# Duh

# PXE & legacy options
option option-128		code 128 = string; # required for PXE boot
option option-129		code 129 = text;   # required for PXE boot
option option-128		e4:45:74:68:00:00; # magic value for PXE booting

# Describe workstations
shared-network LTSPCLIENTS {			# Because there is another DHCP server
  option domain-name	"ltsp.domain.tld";	# A fake domain-name for our thin-clients
  option root-path	"10.0.0.11:/opt/ltsp/i386"; # NFS root path for the kernel

  if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
    filename "/pxe/pxelinux.0";		        # PXE bootrom
  }
  else if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
    filename "/lts/vmlinuz-2.6.16.1-ltsp-2";	# Etherboot kernel
  }

  subnet 10.0.0.0 netmask 255.255.255.0 {
    # dynamic IP range for DHCP clients
    range 10.0.0.100 10.0.0.150;

    # this range is assigned to both BOOTP and DHCP clients
    range dynamic-bootp 10.0.0.100 10.0.0.150;

    group DESKTOP {
      host desktop {
        hardware ethernet	00:C0:4F:AD:5C:BC;
        fixed-address		10.0.0.12;
      }
    }
    group LIBRARY {
      # ws with support for alternative DHCP port 1067 (Etherboot)
      host ws100 {
        hardware ethernet	00:C0:4F:AD:5C:BC;
        fixed-address		10.0.0.100;
        option option-129	"DPORT=1067";
      }
      # support for DHCP port 1067 & slow 3Com ISA NIC
      host ws101 {
        hardware ethernet	00:60:08:5C:CB:BE;
        fixed-address		10.0.0.101;
        option option-129	"DPORT=1067 NIC=3c509 MOPTS=nolock,ro,wsize=2048,rsize=2048";
      }
      # another client with a slow ISA NIC
      host ws102 {
        hardware ethernet	00:C0:4F:AD:5D:55;
        fixed-address		10.0.0.102;
        option option-129	"NIC=ne IO=0x300";
      }
    }
    group LAB {
      # trick to use, when there are two conflicting DHCP servers
      # and the dumb one is authoritative
      host ws103 {
        hardware ethernet	00:C0:4F:AD:5D:55;
        fixed-address		10.0.0.103;
        option option-129	"nfsroot=10.0.0.11:/opt/ltsp/i386";

      }
    }
  }
}
# RESERVED FOR FUTURE USE - Describe OpenMOSIX Servers
#shared-network OPENMOSIXSERVERS {
#  option domain-name "cluster.domain.tld";	# domain-name for servers
#  option root-path   "10.0.0.13:/opt/om/???";	# NFS root path for the kernel
#  # Append /tftpboot if your tftpd isn't chrooted
#  filename         "/om/vmlinuz-???-om";
#  subnet 10.0.0.0 netmask 255.255.255.0 {
#    #range dynamic-bootp 10.0.0.13 10.0.0.15;
#    host srv13 {
#      hardware ethernet	00:C0:4F:AD:5C:BC;
#      fixed-address		10.0.0.13;
#    }
#  }
#}

[edit] Testing

Now you can test your configuration by starting the dhcp server. It's possible that it will fail to start, in which case I find that forgetting to put a ; at the end of each line is the most common problem.

 /etc/init.d/dhcp start
 rc-update add dhcp default

Boot up your LTSP client and you should get as far as

Loading 10.0.0.11:/lts/vmlinuz-2.6.16.1-ltsp-2 ...

[edit] net-dns/dnsmasq

You can also use dnsmasq instead of dhcp. Add these lines to the dnsmasq configuration file:

dhcp-boot=/pxe/pxelinux.0,ltsp,192.168.0.102
# root path
dhcp-option=17,192.168.0.102:/opt/ltsp-4.2/i386

(change 192.168.0.102 to the ip address of your ltsp server)

On the ltsp server I did also create this symlink, else PXE couldn't find the configuration file "default":

ln -sf /tftpboot/pxelinux.cfg /tftpboot/pxe

[edit] sys-apps/xinetd

Many sources use xinetd as a superserver to start tftpd. I guess this improves security, when properly set up, but it's not mandatory. It might also save some memory, if you're already running xinetd for other reasons, because xinetd only starts up services upon valid requests. Create /etc/xinetd.d/tftp with the contents below.

service tftp
{
        disable = no
        socket_type = dgram
        protocol = udp
        wait = yes
        user = root
        server = /usr/sbin/in.tftpd
        server_args = -s /tftpboot
}

If you want additional security, set xinetd to run tftpd as user 'nobody'. I haven't tested this, but it should work.

[edit] net-ftp/tftp-hpa

tftpd or in.tftpd comes in at least 4 flavors. LTSP Wiki recommends atftp and tftp-hpa. The previous author of this section had some problems with tftp-hpa, but I think those have been fixed now. We'll stick with tftp-hpa for now.

 emerge tftp-hpa
 rc-update add in.tftpd default   # if you don't plan on using xinet.d
 /etc/init.d/in.tftpd start   # if you don't plan on using xinet.d

# /etc/conf.d/in.tftpd

# Path to server files from
INTFTPD_PATH="/tftpboot"

# For more options, see tftpd(8)
INTFTPD_OPTS="-u nobody -s ${INTFTPD_PATH}"

Alternative location for /tftpboot is /var/lib/tftpboot. For some reason the maintainer of ltsp ebuild / ltsp folks have selected the current IMO "non-standard" location. You can change it if you wish.

Flag -s tells tftpd to run chrooted. The '-u nobody' flag is there to improve security. When using '-u' you also need to change file permissions: (Don't forget this important step!!! You may need to repeat this in the future as you add / modify files.)

 mkdir /tftpboot
 chown nobody:nobody -R /tftpboot

Added Note: I've added this command to the /etc/init.d/in.tftpd under the start() method I've included chown -R nobody:nobody -R /tftpboot so each time you start the service, it resets all the permissions. my $.02

I'd be interested in any comments about the other tftp daemons that DO work with xinetd AND chroot to a specified directory or how the example above could be more complete. That is to say, if you have something to contribute. You can ask a question... but I'm not the expert here.

[edit] Firewall Rule

1. Save your current firewall rules iptables-save > /etc/iptables.bak
2. Open /etc/iptables.bak in your favorite text editor
3. Add the following rule(s) in appropriate order (according to your existing rules).

 -A INPUT -p udp -m state --state NEW -m udp --dport 69 -j ACCEPT

4. Restore all rules to be part of your current configuration iptables-restore /etc/iptables.bak

[edit] Testing

You can test the server is running tftpd:

 netstat -apn|grep ":69 "

Netstat should say something like

udp      0    0 0.0.0.0:69           0.0.0.0:*                    12125/in.tftpd

Boot up your LTSP client and you should get as far as

Loading 10.0.0.11:/lts//vmlinuz-2.4.26-ltsp-2 .TFTP error 1 (File not found)
Unable to load file
<sleep>
<abort>

[edit] net-misc/ltsp

Want to build your own LTSP environment? Index:LTSP

LTSP only comes in one official pre-packaged flavor. You might be able to find someone else's build on the net, but I'm lame, thus we're using the standard ebuild here. The configuration here is EXTREMELY complex, such that most mere mortals can't manage it so be sure to pay close attention.

• Install LTSP
• upgrade to latest packages with ltspadmin
• basic configuration with ltspcfg

 emerge ltsp
 ltspadmin
 ltspcfg
 # [enter]
 # [c]
 # [8]
 # [enter]
 # [10]
 # [enter]
 # [11]
 # [enter]
 # [q]
 mkdir /tmp/{mnt,var}
 cd /opt/
 ln -s ltsp-${VER} ltsp
 cd /tftpboot/
 mv pxelinux.cfg/ pxe/
 ln -s pxe/pxelinux.cfg pxelinux.cfg

NOTE: Since the configuration tool isn't specifically for Gentoo I'd say don't bother with any of the other settings. Instead, do them by hand.

NOTE2: I got an error:

Checking xdmcp.........Unable to open /etc/X11/default-display-manager: No such file or directory

when running ltspcfg. Running touch /etc/X11/default-display-manager prior to running ltspcfg fixed the issue.

NOTE3: Another "error" you may see is "Checking xdm ........ found: none". This can be corrected by editing /usr/sbin/ltspcfg, add the missing directories/files for your display managers. i.e. add '"/usr/kde/3.5/bin/kdm",' to 'my @kdm_locs' and '"/usr/kde/3.5/share/config/kdm/kdmrc",' to 'my @kdmrc_locs'

[edit] Setting the Display (Desktop) Server

Be sure to change the server IP address to match your situation.

[Default]
       SERVER             = 10.0.0.12
       # using defaults for the rest
[WS250]
       XF86CONFIG_FILE = XF86Config.ltn
       # this machine has an ltn monitor which needs special configuration

[edit] Testing

Boot up your LTSP client and you should get as far as

Kernel Panic: Tried to kill init!
No root path

NOTE: If you have installed nfs-utils and are still getting this message, it may be due to another DHCP server on your network. Please read the the section about configuring the DHCP server for more info.

[edit] net-fs/nfs-utils

If you've been playing by numeber here, the last error you got was probably something about a kernel panic: attempted to kill init. That's because none of the filesystems are yet available to be mounted. Installing and configuring nfs will fix that. You will also need portmap. Be sure to have NFS support compiled in your kernel or at least have it installed as modules. You will find the NFS Support for the kernel in "File systems > Network File Systems > NFS server support".

NOTE: Since NFS and SYSKLOGD are inherently vulnerable to attack, it is important that you have some established level of trust betwixt yourself and your users! In example: a malicious user could fill the hard drive on the server by misusing the NFS swapfile mount or generating innumerable bogus errors to make the logfile on the server get big.

 echo "net-fs/nfs-utils tcpd" >> /etc/portage/package.use
 emerge nfs-utils
 mkdir -p /var/opt/ltsp/swapfiles
 vim /etc/exports

# NFS file systems being exported.  See exports(5).
/opt/ltsp-4.2/i386		10.0.0.0/255.255.255.0(ro,no_root_squash,async)
/var/opt/ltsp/swapfiles		10.0.0.0/255.255.255.0(rw,no_root_squash,async)

[edit] Firewall Rule

Because of the way the many different components of NFS work, it's a little tricky to set up a firewall for it. Please follow the firewall portion of this guide: HOWTO Share Directories via NFS

[edit] Testing

 /etc/init.d/portmap start
 rc-update add portmap default
 /etc/init.d/nfs start
 rc-update add nfs default

Boot up your LTSP client and you should notice two things: An error about the system logger not accepting connections scrolls by on bootup:

 system logger couldn't connect

And the fact that X loads to a blank grey screen with an X in the center... and not much else is happening for you

[edit] Logger

You need a logger which allows remote logging so that the clients can write logs to the main server. There are two loggers which are very easy to set up for this.

If your current logger is different, you'll have to unmerge it:

 LOGGER=`emerge -p logger | cut -d']' -f2 | cut -d'[' -f1`
 /etc/init.d/${LOGGER} stop
 emerge --unmerge ${LOGGER}

[edit] app-admin/sysklogd

 emerge sysklogd logrotate
 vim /etc/conf.d/sysklogd
 rc-update add sysklogd default
 /etc/init.d/sysklogd start

 SYSLOGD="-m 0 -r"
 KLOGD="-c 3 -2"

[edit] app-admin/syslog-ng

 emerge syslog-ng logrotate
 vim /etc/syslog-ng/syslog-ng.conf
 rc-update add syslog-ng default
 /etc/init.d/syslog-ng start

I don't know how well the default gentoo conf for syslog-ng handles remote logging; I recommend this one:

http://www.campin.net/syslog-ng.conf

You'll still need to make a slight modification to these lines:

udp(port(514));
tcp(port(5140) keep-alive(yes));

[edit] Firewall Rule / Services

 iptables-save > /root/iptables.bak
 vim /etc/services
 vim /root/iptables.bak
 iptables-restore /root/iptables.bak

 syslog          5140/tcp

 -A INPUT -p udp -m state --state NEW -m udp --dport syslog -j ACCEPT
 -A INPUT -p tcp -m state --state NEW -m tcp --dport syslog -j ACCEPT

[edit] Testing

/etc/init.d/sysklogd start
rc-update add sysklogd default

Boot up your LTSP client and you should notice the fact that X loads to a blank grey screen with an X in the center... and not much else is happening for you... on the client side

But notice what is happening on the server!

1. grep -r ws241 /var/log/

/var/log/user.log:Feb 14 16:28:45 test rpc.mountd: authenticated mount request from ws241.ltsp.vuhs.org:657 for /opt/ltsp-4.1/i386 (/opt/ltsp-4.1/i386) /var/log/syslog.0:Feb 14 16:28:45 test rpc.mountd: authenticated mount request from ws241.ltsp.vuhs.org:657 for /opt/ltsp-4.1/i386 (/opt/ltsp-4.1/i386) /var/log/syslog.0:Feb 14 16:28:47 ws241.ltsp.vuhs.org syslogd started: BusyBox v0.60.4 (2004.07.12-19:22+0000) /var/log/syslog.0:Feb 14 16:28:51 ws241.ltsp.vuhs.org init: Entering runlevel: 5 /var/log/syslog.0:Feb 14 16:43:06 test gdm[7936]: gdm_slave_xioerror_handler: Fatal X error - Restarting ws241.ltsp.vuhs.org:0 /var/log/syslog.0:Feb 14 17:19:47 test gdm[9646]: Ping to ws241.ltsp.vuhs.org:0 failed, whacking display!

NOTE: `grep -r` is probably the most usefull command in all of *nix-dom. I urge you to remember that when you're trouble shooting - from error logs to source code, grep is your friend!

[edit] TIP: Webmin LTSP

Haven't messed with this much yet:

cd
emerge webmin
wget http://freshmeat.net/redir/webmin-ltsp/11431/url_tgz/ltsp-webmin-0.5.99.tar.gz
tar xzpf ltsp-webmin-0.5.99.tar.gz -C /usr/libexec/webmin/
# tar xpf ltsp-webmin-0.5.99.wbm -C /usr/libexec/webmin/ # if you get the wbm instead
cp /usr/libexec/webmin/ltsp/config-redhat-linux /usr/libexec/webmin/ltsp/config-gentoo-linux
vim /etc/webmin/webmin.acl # add ltsp to root's list
vim /usr/libexec/webmin/ltsp/ltsp-webmin/ltsp-lib.pl # uncomment lines 32-45
# I'd suggest just using http://rom-o-matic.net
# wget http://heanet.dl.sourceforge.net/sourceforge/etherboot/etherboot-5.4.0.tar.bz2
# tar xjpf etherboot-5.4.0.tar.bz2 ./
/etc/init.d/webmin start
rc-update add webmin default

Order of operations seems important, edit the webmin.acl before starting webmin for the first time

firefox https://localhost:10000/ # log in
firefox https://localhost:10000/ltsp/ # configure ltsp

[edit] Order of Operations

I recommend separating the server from the desktop. One reason for this is that your desktop houses the most problematic part of this equation - users. If you happen to host the school webservices on your server, you wouldn't want to have to disrupt it because of a problem with a zombie user process or mounting operation that necessitated a reboot.

[edit] See Also

http://www.k12ltsp.org/server.html

http://vuhs-club.livejournal.com/