knuthaugen

Howto: Configuring LTSP and playing audio on clients

Author: knut (a) knuthaugen dot no, copyright 2004.
Legalese: Please read the copyright and the disclaimer wich apply to this document

Abstract

This document describes how to do general setup of diskless clients for LTSP and configuring sound to work on the clients (actually without sound working on the server).

Setup

The document is based on the following setup and you'll have to deduce any changes regarding your own network. Those are the breaks.

Misc


Installing up LTSP

First order of the day is to set up the LTSP server itself. As of version 4, the only way of installing it is to pipe a wget command into a root shell. Yes, that's ridiculously correct. Why people choose this policy only an involved mind can understand, but there you have it. If you want to be paranoid, and you should be paranoid if you're a sysadmin, you can run this installer as a normal user and chmod the directory afterwards. You will probably get some errors for some files, but those are fixable. You can of course compile it from source. Use the source, Luke.

You need at least the packages ltsp_core, ltsp_x_core. Ltsp_x_addtl_fonts and ltsp_rdesktop can be nice, so can ltsp_debug_tools. In any case you need the rpm for the ltspcfg tool and the kernels. At TTOW there wasn't a package for LTSP-4 kernels but the version 3 package works fine. The kernel file name is actually "4" in that package, and it seems pretty updated. The ltspcfg package is independent of the release. If you used the LTSP-4 installer, the easiest way is to download and install the tgz file for the kernel since it depends on the ltsp_core rpm from LTSP-3. The ltspcfg does not depend on anything. All these files are available from ltsp.org.

Configuring LTSP

Run ltspcfg to do the major configurations. It has a terminal gui which allows you to do most of the work needed without editing. You will have to edit some files afterwards, but you won't have to write a bunch of files. Follow the instructions in the ltspcfg program and turn mostly everything on.

Runlevels

A lot of services have to be running in the runlevel you'll be using for all this to work. These services are:

LTSP config file – lts.conf

# Copyright (c) 2002 by James A. McQuillan (McQuillan Systems, LLC)
#
# This software is licensed under the Gnu General Public License.
# The full text of which can be found at http://www.LTSP.org/license.txt
# Config file for the Linux Terminal Server Project (www.ltsp.org)

[Default]
    SERVER             = 80.232.36.179
	XDM_SERVER	       = 80.232.36.179
    XSERVER            = auto
	X_MOUSE_PROTOCOL   = "PS/2"
	X_MOUSE_DEVICE     = "/dev/psaux"
	X_MOUSE_RESOLUTION = 400
	X_MOUSE_BUTTONS    = 3
	USE_XFS            = N
	LOCAL_APPS         = N
	SCREEN_01          = startx
	SCREEN_02          = shell
	XkbLayout	       = no
	XkbModel	       = pc105

[thin01]
	SOUND		    = Y
	SOUND_DAEMON    = nasd
	VOLUME          = 70
	MIC_VOLUME      = 70
	CD_VOLUME       = 70
	XF86CONFIG_FILE = XF86Config-tynn

The Default section applies to all clients and should be tailored to your server configuration. The LTSP documentation should be sufficient for this. If that fails, google is your friend.

The sound* and *_volume configuration variables must, according to LTSP doc, be repeated for all clients using sound. Cumbersome, but necessary. SOUND_DAEMON=nasdis the key here.

DHCP setup

Here is a snippet of the dhcpd.conf file needed for booting clients via PXE.

option domain-name "foo.no";
option ntp-servers ntp.foo.no;
default-lease-time 604800;
max-lease-time 2419200;

allow booting;
allow bootp;

shared-network foo {
    subnet 10.0.1.128 netmask 255.255.255.192 {
	option routers 10.0.1.129;

	option domain-name-servers 10.0.1.131, 10.0.1.2, 195.1.156.91;

	option static-routes 213.203.57.201 10.0.1.131, 213.203.57.202 10.0.1.132;
   }

    subnet 10.0.1.192 netmask 255.255.255.224 {
	option routers 10.0.1.193;
	option domain-name-servers 10.0.1.2;
	range dynamic-bootp 10.0.1.196 10.0.1.221;
	filename "pxelinux.0";
	default-lease-time 3600;
	max-lease-time 14400;
   }
}

host tynn.foo.no {
	hardware ethernet 00:40:63:C0:C2:0C;
	fixed-address thin.foo.no;
	filename "/lts/2.4.24-ltsp-4/pxelinux.0";
	option root-path "10.0.1.179:/usr/ltsp/i386";
}

The policy chosen here is to have an entry for each mac address and have each thin client in DNS. Your mileage on this may vary and its up to you to decide. The filename and root-path can be set to apply for all hosts quite easily. See man dhcpd.conf for details.

The filename parameter is relative to the root for the tftp daemon, which for debian is /var/tftp and the path in the dhcpd.conf file should be adjusted accordingly. Check you tftp install. And here comes the smart part. We want our thin clients to boot completely without disk and mount the root file system via NFS. This is done via the option root-path "10.0.1.179:/usr/ltsp/i386"; where of course the ip address is the address of the LTSP server.

The /etc/exports file on the LTSP server looks like this (LTSP is installed i /usr/ltsp).:


/usr/ltsp                 10.0.1.128/255.255.255.192(ro,no_root_squash,sync)
/var/opt/ltsp/swapfiles   10.0.1.128/255.255.255.192(rw,no_root_squash,async)

With the nfs processes up and running on the LTSP server, this should be working like a charm. Check the console messages when booting the client for info if this doesn't work.

Pxe setup

The PXE file that we are referring to in the dhcpd.conf entry (/lts/2.4.24-ltsp-4/pxelinux.0) is in /var/tftp/lts/2.4.24-ltsp-4/pxelinux.0 and is a special file provided by LTSP in it's kernel package. This is the actual file that is used for loading the config and starting the boot process.

The config file could use some tweaking, though, and it is found in the pxelinux.cfg directory. You can actually specify a unique file for each mac address, or range of macs, if you're so lucky as to have NICs in the same series. PXE checks for a config file by converting the mac address to hexadecimal values (removing the :) and trying to read that filename, starting with the full mac and stripping of characters down to one. Default is the last file it tries if no of the others are found. It represents the default config. Unless you have very special needs it should suffice. The following file refers to the actual kernel files in the directory lts/2.4.24-ltsp-4 and this is seldom a problem. If the client can't find the kernel, this is the file you should be editing.

prompt=0
label linux
	kernel bzImage-2.4.24-ltsp-4
	append init=/linuxrc rw root=/dev/ram0 initrd=initrd-2.4.24-ltsp-4.gz

Nasd setup

At present I won't be writing the full details on the sound setup. See http://www.ncpl.lib.in.us/~rjune/lbe/LTSP-arts-howto.html for info on how to do that. The KDE stuff may vary a bit, but the setup is pretty much correct.

If you get choppy sound when resizing windows, try to increase the settings in the nasd.conf. This file is found in $LTSP_HOME/i386/etc/nas/nasd.conf and it's the ouput section taht should bed edited. experiment with minfrags, maxfrags and fragsize settings to see if it improves. Remember, we're sending audio over the network here, so bandwidth is an issue.

XDM setup

Our XDM/KDM/whatever has to be configured for allowing remote logins and also give out a welcome sign to our diskless clients. Yes, this means that we will be logging in remotely on the server via X and that in turn means our passwords will be transmitted in clear text over the local network. If this is unacceptable to you, then standard LTSP is not for you.

Anyhow, the magic words are done in (for KDM) the kdmrc file, xdmrc for XDM and gdmrc for GDM. Every distro on the planet place these files in different location and I'm not gonna bother writing it down here, cause it's bound to be wrong. Use locate. These files have the same syntax and the magic is in a section called XDMCP, which is the technology for remote logins to X. Something like this:


[Xdmcp]
# Whether KDM should listen to XDMCP requests. Default is true.
Enable=true

Restart your XDM/KDM/Whatever and test it. E.g the command Xnest -query <ltsp-server> :1 should give you the XDM/KDM/Whatever login screen. If you only get a grey flickering screen the XDM/KDM/Whatever isn't allowing remote X logins, or your firewall may be in the way or something. Bring out the big guns with tcpdump, ethereal or your favorite network traffic analyser and see what's going on.

Files

References

Copyright © Knut Haugen 2004-07-26, last updated 2004-08-09, valid xhtml 1.0 strict