 |
|
 |
| Theory of operation |
|
Multiple server setup |
By default, most thin clients will automatically configure themselves
correctly, and just work when they're plugged in. However, sometimes you
may wish to customize their behavior. You would do this by editing the
lts.conf file.
When LTSP was designed, one of the issues that needed to be dealt with was varying hardware configurations for the thin client. Certainly, whatever combination of processor, network card and video card available today would not be available in 3 months, when you want to add more thin clients to the network.
So, LTSP.org devised a way of specifying the configuration of
each thin client. The configuration file is called
lts.conf and it lives in the
/opt/ltsp/i386/etc
directory.
The format of the lts.conf allows for 'default' settings and individual thin client settings. If all of your thin clients are identical, you could specify all of the configuration settings in the '[Default]' section.
Section headings begin with an identifier in square brackets. the identifier can be one of:
a mac address for a workstation, in the form of XX:XX:XX:XX:XX:XX, where X is the digits 0-9, or A-F. You can usually read the mac address for a network card from a sticker on the card itself, or use some kind of network tool to discover it. The ifconfig can tell you the mac address of your network cards.
an IP address. You'll need to statically assign host IP addresses
for this to work, as by default, Edubuntu ships with a
dhcpd.conf that hands out dynamic addresses.
This means there's no guarantee which host will get what IP
address.
a hostname. Same issue as an IP address, but additionally, you
must have either defined the hostname in DNS, or in /etc/hosts.
The special section heading [Default]. This section can set defaults that apply to all terminals.
After the section heading, you can then define variables. Variables are ether boolean values, requiring a True/False or Y/N answer. Note that you can either use True or False, Yes or No, or Y or N. Whichever you prefer. Other variables may simply be strings, supplied after the = sign. The general format of an assignment looks like:
BOOLEAN_VARIABLE = True
STRING_VARIABLE = Information
Comments can be inserted into the file for your documentation purposes. Comments start with a # character, and everything after the # for the rest of the line is considered a comment.
In order to speed up LTSP, by default, we're using NBD (Network Block
Devices) rather than NFS. The /opt/ltsp/i386
still exists, but now, it's compressed into a squashfs image, so it's much
smaller than simply exporting via NFS. This means that the client uses less
network bandwidth than before. However, it would mean that every time you
change the lts.conf file, you'd have to re-create this
image using the command ltsp-update-image. This takes a while
to do. So, in order to avoid this, we've moved the lts.conf file
to the TFTP directory, in /var/lib/tftpboot/ltsp/i386.
This means you can make changes to the file immediately, and simply reboot the terminal, without
recompiling the image.
Using NBD instead of NFS has several advantages:
Using a squashfs image we can now merge that together in a unionfs to get writeable access which is a lot faster during bootup.
A squashed root filesystem uses less network bandwidth.
Many users and administrators have asked us to eliminate NFS, for reasons of site policy. Since the squashed image is now served out by nbd-server, which is an entirely userspace program, and is started as the user nobody, this should help to eliminate concerns over NFS shares.
However, some people still want to use NFS. Fortunately, it's easy to switch back to NFS, if it's so desired:
On the server, use the chroot command to maintain the LTSP chroot:
sudo chroot /opt/ltsp/i386
Now edit /etc/default/ltsp-client-setup
and change the value of the root_write_method variable to use bind mounts
instead of unionfs, it should look like this afterwards:
root_write_method="bind_mounts"
Next, create the file /etc/initramfs-tools/conf.d/ltsp
and add the following line (set the value of the BOOT variable to nfs):
BOOT=nfs
Regenerate the initramfs:
update-initramfs -u
Hit CTRL-D to exit the chroot now. Make sure LTSP uses the new initramfs to boot:
sudo ltsp-update-kernels
Here is an example of the lts.conf file:
################
# Global defaults for all clients
# if you refer to the local server, just use the
# "server" keyword as value
# see lts_parameters.txt for valid values
################
[default]
X_COLOR_DEPTH=16
LOCALDEV=True
SOUND=True
NBD_SWAP=True
SYSLOG_HOST=server
XKBLAYOUT=de
################
#[MAC ADDRESS]: Per thin client settings
################
[00:11:25:84:CE:BA]
XSERVER = vesa
X_MOUSE_DEVICE=/dev/ttyS0
X_MOUSE_PROTOCOL=intellimouse
###############
# A Thin Client Print server
# (switch off X by pointing tty7 to shell,
# to save ressources)
###############
[00:11:25:93:CF:00]
PRINTER_0_DEVICE=/dev/usblp0
SCREEN_07=shell
###############
# A workstation that executes a specific
# command after login
###############
[00:11:25:93:CF:02]
LDM_REMOTECMD=/usr/bin/myloginscript
The LTSP Display Manager, or ldm is the display manager specifically written by the LTSP project to handle logins to a GNU/Linux server. It is the default display manager for LTSP thin clients running under Edubuntu, and has a lot of useful features:
It is written in C, for speed and efficiency on low end clients.
It supports logging in via either a greeter (a graphical login application) or autologin.
It can be configured to encrypt X Windows traffic, for increased security, or leave it unencrypted, for better performance on slower clients.
It contains a simple load-balancing system, to allow the system administrator to allow load balancing across several servers.
We'll go over the lts.conf entries you'll need to
control these features below.
To help understand the following sections, a bit of an explanation of how ldm does it's work is needed. Most thin client display managers tend to run up on the server. The ldm display manager is unique in that it runs on the thin client itself. This allows the thin client to have a lot of choice as to how it will set up the connection. A typical login session goes as follows:
ldm launches and starts up the X Windows display on the thin client.
ldm starts up the greeter, which is a graphical program which presents the user with a nice login display and allows them to select their session, language, and host they'd like to log into.
ldm collects the information from the greeter, and starts an ssh session with the server. This ssh connection is used to create an ssh master socket, which is used by all subsequent operations.
Now, the users selected session is started via the master socket. Depending on whether or not an encrypted connection has been requested, via the LDM_DIRECTX parameter, the session is either connected back to the local display via the ssh tunnel, or via a regular TCP/IP connection.
During the session, any memory sticks, or other local devices that are plugged in, communicate their status to the server via the ssh control socket.
When the user exits the session, the ssh connection is closed down, the X server is stopped, and ldm restarts itself, so everything starts with a clean slate.
By default, LTSP5 encrypts the X session between the server. This makes your session more secure, but at the cost of increased processing power required on the thin client and on the server. If processing power is a concern to you, it's very easy to specify that the connection for either an individual workstation, or the default setting should use an unencrypted connection. To do so, simply specify:
LDM_DIRECTX=True
in your lts.conf file in the appropriate stanza.
This new version of LDM supports auto login of accounts, if
specified in the lts.conf file. Simply
create a config stanza for each of the terminals you want to log
in automatically (you can use either MAC address, IP address, or
hostname) and specify the variable LDM_USERNAME
and LDM_PASSWORD. Note that you must have created
these accounts on the server, with the passwords specified. An example
will serve to illustrate how to use this:
[00:E0:81:27:D6:AE]
LDM_USERNAME=station1
LDM_PASSWORD=sekrit1
[00:30:48:73:FC:A3]
LDM_USERNAME=station2
LDM_PASSWORD=sekrit2
In this version of LTSP, there's a simple load-balancing solution implemented that allows administrators to have multiple Edubuntu servers on the network, and allow the thin client to pick which one of the servers it would like to log into.
The host selection system is simple and flexible enough to allow administrators to implement their own policy on how they want the load balancing to happen: either on a random, load-based, or round robin system. See the section called “Multiple server setup” for details.
There are several variables that one can define in the lts.conf file which control how the thin client interacts with the server. These are:
This is the server that is used for the XDM_SERVER, TELNET_HOST, XFS_SERVER and SYSLOG_HOST, if any of those are not specified explicitly. If you have one machine that is acting as the server for everything, then you can just specify the address here and omit the other server parameters. If this value is not set, it will be auto detected.
If you want to send logging messages to a machine other than the default server, then you can specify the machine here. If this parameter is NOT specified, then it will use the 'SERVER' parameter described above.
Set this to Y if you want to turn on NBD swap. The default is Y.
The NBD swap server can exist on any server on the network that is capable of handling it. You can specify the IP address of that server. The default is whatever the value of SERVER set to.
The port on which NBD swapping will occur. This is set to 9572 by default.
If you have a hard drive installed in the thin client, with a valid swap partition on it, this parameter will allow the thin client to swap to the local hard drive. The default is N.
Used to build the resolv.conf file. Not needed by default.
Used to build the resolv.conf file.
This parameter enables sound for the thin client. The default is Y.
This parameter enables local devices support, like CD's and USB sticks. Users plugging them in should see them on the desktop, after they've been added to the fuse group on the server. You can do this by going to: → → selecting the user, clicking on "Properties", the going into the "User Privileges" tab, and making sure the "Allow use of FUSE filesystems..." box is checked. The default is: Y.
Screen scripts are how LTSP determines what type of login will run on what virtual screen. Most GNU/Linux machines have 12 virtual consoles, which you can access by pressing Control-Alt-F1, through Control-Alt-F12. There is a text based getty that is started on screen 1, but you normally can't log into it, as there are no local users on the thin client.
However, for debugging purposes, you may want to set up root to log in on the thin client. You may need to do this if you're debugging problems with local devices, for example. Fortunately, it's easy to do: on the server, just chroot into the LTSP chroot, and set the password with passwd.
sudo chroot /opt/ltsp/i386
passwd
By default, if there's nothing else mentioned in lts.conf,
an LDM session will be started on screen 7.
Parameters relating to screen scripts
Up to 12 screen scripts can be specified for a thin client. This will give you up to 12 sessions on the thin client, each accessible by pressing the Ctrl-Alt-F1 through Ctrl-Alt-F12 keys.
SCREEN_07 = ldm
SCREEN_02 = shell
Currently, possible values include:
ldm: This is the default display manager. It collects a username and password, and then establishes a secure, encrypted tunnel to the server via ssh. This should be good for most environments. Edubuntu deployments with lower-powered clients or servers may find that the extra overhead involved in encrypting the X traffic might slow their sessions, and may wish to enable the LDM_DIRECTX parameter described in the section called “The LDM display manager”
sdm: Similar in functionality to ldm, but a little less graphically intensive.
startx: Older X connection requiring the use of XDMCP to connect to the server. Some legacy installations may want to use it, however, the intruduction of the LDM_DIRECTX parameter has eliminated much of the need to run it. Enabling this will require you to turn on XDMCP for the gdm login manager. As an administrative user, go to → → and in the "Remote" tab, change the drop down to "Same as local". Additionally, you may wish to click on the "Configure XDMCP" button on the lower corner, and increase the "Maximum remote sessions" to something a little higher than the number of thin clients you have. Please note that doing this means local devices will not work for you, as they rely on the ssh tunnel that ldm provides.
telnet: Text screen telnet into whatever host TELNET_HOST is set to. See below for an explanation.
shell: spawns a shell on the thin client. Useful for testing.
rdesktop: spawns an rdesktop session to a remote windows server. Note that you must have the rdeskop package installed in the chroot.
Look in the /opt/ltsp/i386/usr/lib/ltsp/screen.d
directory for more scripts, or write your own, and put them there.
If the thin client is setup to have a character based interface, then the value of this parameter will be used as the host to telnet into. If this value is NOT set, then it will use the value of SERVER above.
For the most part, LTSP does a very good job of detecting what hardware's on your thin client. However, it's possible that you may want to manually specify a kernel module to load after boot. Alternatively, you may have a script you've written that you've put in the chroot, and want to make sure gets run at startup. LTSP provides some hooks to allow you to do this.
Up to 10 kernel modules can be loaded by using these configuration entries. The entire command line that you would use when running insmod can be specified here. For example:
MODULE_01 = uart401.o
MODULE_02 = "sb.o io=0x220 irq=5 dma=1"
MODULE_03 = opl3.o
If the value of this parameter is an absolute pathname, then insmod will be used to load the module. Otherwise, modprobe will be used.
In normal circumstances, you shouldn't need to specify anything here, as most hardware will be auto-detected.
Additional RC scripts can be executed by the
ltsp-client-setup script. Just put the script in the
/opt/ltsp/i386/etc/init.d directory, and
specify the name of the script in one of these entries.
Setting up X windows on the thin client's normally a pretty easy operation. The thin client uses X.org's own auto configuration mode to let X determine what it thinks is installed in the box. The thin client just runs the command Xorg -configure, and then uses that output, slightly modified, for the X config file.
However, sometimes, this doesn't always work. Either due to strange/buggy
hardware, or buggy drivers in X.org, or because X detects default settings that
you don't want. For instance, it may detect that your monitor is capable of doing
1280x1024, but you'd prefer it to come up in 1024x768 resolution. Fortunately,
you can tweak individual X settings, or, alternatively, simply provide your own
xorg.conf to use.
X.org configuration
If you want to create your own complete X.org config file, you
can do so and place it in the
/opt/ltsp/i386/etc/X11 directory. Then, whatever you
decide to call it needs to be entered as a value for this
configuration variable. For example:
X_CONF = /etc/X11/my-custom-xorg.conf
Note that for the thin client, you reference it from /etc/X11.
Some programs allocate a large amount of ram in the X.org server running on your thin client. Programs like Firefox and Evince can use up so much ram, that they eventually exhaust all your physical ram, and NBD swap, causing your thin client to crash. If you find your clients being booted back to a login prompt, or freezing up when viewing certain PDF's or web pages, this may be the problem.
The X_RAMPERC variable stands for X RAM PERCent, and is a number between 0 and 100 that specifies how much of the free space on your thin client X.org is allowed to consume. You'll generally want to set it at something lower than 100 percent, if you're having problems. Experimentation has shown a value between 80 and 90 will usually keep the terminal alive. What will then happen is the program consuming the memory will die, as opposed to the thin client itself. If you're having unexplained terminal problems, specifying:
X_RAMPERC = 80
in your lts.conf file may improve things.
If you're using the older startx screen script, and need to specify a different server, then you can specify the server here. If this parameter is NOT specified, then it will use the 'SERVER' parameter described above.
You can use this parameter to override which X server the thin client will run. For PCI and AGP video cards, this parameter should not be required. The thin client should normally be able to auto-detect the card.
If, for some reason you do need to manually set it, here are the valid values:
ark
ati
atimisc
chips
cirrus_alpine
cirrus
cirrus_laguna
cyrix
dummy
fbdev
fglrx
glint
i128
i740
i810
imstt
mga
neomagic
newport
nsc
nv
r128
radeon
rendition
riva128
s3
s3virge
savage
siliconmotion
sis
sisusb
tdfx
tga
trident
tseng
v4l
vesa
vga
via
vmware
voodoo
This is the device node that the mouse is connected to. If it is a serial mouse, this would be a serial port, such as /dev/ttyS0 or /dev/ttyS1. This is not needed for PS/2 or USB mice, as they are auto-detected.
Should be auto-detected. However, valid entries include:
sunkbd
lkkbd
vsxxxaa
spaceorb
spaceball
magellan
warrior
stinger
mousesystems
sunmouse
microsoft
mshack
mouseman
intellimouse
mmwheel
iforce
h3600ts
stowawaykbd
ps2serkbd
twiddler
twiddlerjoy
Normally unset, may need to be set to Y for certain 2 button mice.
This is the number of bits to use for the color depth. Possible values are 8, 16, 24 and 32. 8 bits will give 256 colors, 16 will give 65536 colors, 24 will give 16 million colors and 32 bits will give 4.2 billion colors! Not all X servers support all of these values. The default value for this is 24.
You have a choice of running the X Font Server (XFS) or reading the fonts through the file system. XFS has been pretty much superceeded by the RENDER extention of X.org, but for special cases, you can specify it. The 2 values for this option are Y and N. The default value is N. If you do want to use a font server, then you can use the XFS_SERVER entry to specify which host will act as the font server.
If you are using an X Font Server to serve fonts, then you can use this entry to specify the IP address of the host that is acting as the font server. If this is not specified, it will use the default server, which is specified with the SERVER entry described above.
This sets the X.org HorizSync configuration parameter. This should be auto-detected for your monitor, however, if you want to force a lower resolution, use this parameter to do so.
This sets the X.org VertRefresh configuration parameter. This should be auto-detected for your monitor. If you need to force a lower resolution, use this parameter to do so.
This sets the X.org VideoRam configuration parameter. This should be auto-detected for your monitor. If you need to force a different video ram setting, use this parameter to do so.
This allows you to specify
Option settings in the xorg.conf file, to
add options to the video driver. A common use for this will be to test
turning off accelleration in your driver, if you're having trouble. An example usage
would be:
X_OPTION_01 = "\"NoAccel\""
X_OPTION_02 = "\"AnotherOption\" \"True\""
. You probably won't need these except in special circumstances.
These sets the X.org ModeLine configuration. For example, if your thin client comes up in a higher resolution than what you want, say, 1280x1024, specifying:
X_MODE_0 = 1024x786
should get your desired resolution on startup.
Sometimes, it's convenient to hang a printer off of a thin client in a lab, so that the computer lab has access to local printing resources. Fortunately, LTSP can accomodate printing on the workstation.
LTSP can connect up to 3 printers per workstation to the network via a small daemon called JetPipe. Both parallel and USB printers are supported. JetPipe makes the printer look like a standard HP Jet Direct printer interface. You can then create any cups printer on your server, and point it at the printer via a Jet Direct connection.
In your dhcpd.conf file that controls your
thin client IP assignments, you'll want to assign a static IP
for the terminal with the printers, to guarentee that it gets
the same IP address every time it boots. Otherwise, your printing
won't work if the terminal leases a different IP address.
Printing related parameters
The device name of the printer. Names such as /dev/lp0, or /dev/usblp0 are allowed.
The TCP/IP Port number to use. By default, it will use ' 9100', for PRINTER_0_DEVICE, '9101' for PRINTER_1_DEVICE, and '9102' for PRINTER_2_DEVICE.
All of the keyboard support files are copied into the /opt/ltsp/i386 hierarchy, so configuring international keyboard support is simply a matter of configuring X.org. There are several configuration parameters for this.
The values for the above parameters are from the X.org documentation. Whatever is valid for X.org is valid for these parameters.
We would like to add documentation to show what values are needed for each type of international keyboard. If you work with this and can configure your international keyboards, feedback to Edubuntu would be greatly appreciated.
Allows you to specify a valid console keymap for TELNET_HOST sessions. Default is en.
Consult the X.org documentation for valid settings.
Consult the X.org documentation for valid settings.
Consult the X.org documentation for valid settings.
Consult the X.org documentation for valid settings.
Consult the X.org documentation for valid settings.
| |
|
|
| Theory of operation |
|
Multiple server setup |