Linux Terminal Server Project Administrator's Reference

One of the key technologies included in modern GNU/Linux operating systems is the Linux Terminal Server Project (LTSP) which allows you to boot thin clients from an LTSP server. For educational environments, LTSP lowers hardware costs by enabling the use of older or less powerful machines as thin clients, as well as reduced administration overhead by having only to install and maintain the software on the server. When a workstation fails, it can simply be replaced without data loss or re-installation of the operating system.

Thin client computing has been around for a long time in the UNIX world. Although the implementation has evolved quite a bit, the concept has remained the same:

Because the thin clients have a limited number of tasks to manage, the hardware for the thin client can be small and cheap. The thin clients themselves are basically maintenance free. They last longer because they have no storage with moving parts like hard disks. If they break no data is lost since nothing is stored on the client itself. Simply swap the client with another one and go back to work. If your thin client is stolen or put in the trash, no data ends up in the hands of unauthorized people.

The terminal server runs all applications and contains all the data. All the regular maintenance (software updates, administration) takes place on the terminal server. The number of thin clients that a terminal server can support is proportional to the power of the server. Because GNU/Linux makes efficient use of resources, you can support a surprising number of thin clients from a machine which might only be considered a powerful single user system running other operating systems. Please see for more details.

In a thin client computing environment, the stability of the server is important. It's important to make sure that your server has good power fallback facilities, like installing a UPS, and depending on how much availability is required, redundant power supplies may be called for. As well, users who have the resources may decide to invest in multiple disks for RAID support, and other options which may be needed in a High Availability environment. However, you certainly don't need them in all environments, and GNU/Linux's high quality means that in all but the most demanding environments, this won't be needed.

Security has become a key challenge for administrators and LTSP both recognizes and handles this quite well. Often schools lack the specialized IT staff or time to lock and clean up computers.

Operating systems with LTSP included, being Linux-based operating systems, enjoy the security advantages of its Unix-like and open source heritages. This translates into higher quality code and no spyware and viruses, like they plague other operating systems.

In addition, it has a strict, proactive security policy which means that many common problems, such as open ports or misconfigured software, never make it into the released product. Finally, LTSP based systems are true multi-user operating systems, making it easy to allow users to complete their tasks without having a level of access that could compromise the system.

With administrators and especially school IT departments deploying and administering an increasing number of computers, it is difficult to find time to manage individual machines. LTSP thin client technology, makes deployment and management simple and easy. A single server is all that is needed to set up, manage and administrate an entire network It is recognized that not every school's setup is the same, so LTSP (and the underlying operating system) has been made to easily customize your unique needs.

With the ongoing debate about climate change, questions are finally being asked and answered in the fields of IT, education and thin client technology in general. A recent study compared the energy and resource consumption of a regular PC and Thin Client setups. You can find that study here: http://it.umsicht.fraunhofer.de/TCecology/index_en.html

They found that thin clients use half the energy of traditional workstations, which not only helps on the cost savings (calculate that a 40 terminal thin client lab will save approximately $500-$800 per year), but is ecologically effective in avoiding electronic waste and high carbon emissions. Thin client production, assembly and logistics costs far less and requires less energy than traditional PC manufacturing. The recycling of old machinery also helps the environment, making LTSP a green solution to the environmental and power saving issues many IT managers face today.

With ever-increasing demands on school budgets, expensive technology is often last on the list. LTSP can help you offer what your students increasingly require from computer technology, without breaking the bank. GNU/Linux is and always will be free to acquire, use and modify, including the underlying LTSP structure that holds it all together.

Need to set up another machine? Or another 100? Just install them! With GNU/Linux you'll have no more expensive OS upgrades and licenses, and having specialized programs on only some computers will become a thing of the past. When you build your network on Open Source software, you are freed to seek support for your computers from whomever you wish.

GNU/Linux with LTSP can also help you save hardware costs, by allowing you to redeploy older machines as thin clients using LTSP technology. Whether you choose to set up many smaller labs with various LTSP servers or one giant setup with a load balanced LTSP setup (various servers working together to manage the users and applications logging on) the cost savings are always enormous.

LTSP support is available from the LTSP community. Many of the authors of the software included in LTSP, including the respective developers of the various LTSP GNU/Linux distribution implementations themselves, can be contacted directly via mailing lists and IRC channels.

There are many forms of support available, including mailing lists, Wiki websites, IRC channels, and bug trackers. There are also special support groups for using LTSP and GNU/Linux.

The official IRC support channel is found on freenode.org at #ltsp

The official LTSP mailing list is found here:

https://lists.sourceforge.net/lists/listinfo/ltsp-discuss

In fact, some of the money that would have gone to purchasing software can instead be spent to hire local experts to help train you, and to help you support your network. LTSP can help you take more control over your network while also benefiting your local economy. With LTSP based systems, these choices are yours.

LTSP based distros come with translations for many languages and localization features that allow people from all over the world to enjoy their computing experience. Accessibility features strive to provide a pleasant, high-quality computing experience to disabled users.

The Free nature of GNU/Linux means that the applications a user is used to at their school or workplace is also available to them at home. Users can install their favorite GNU/Linux distribution at home, and have all the same functionality they are used to. In fact, many GNU/Linux distributions have Live CD's, which allow users to try, or even fully use the distribution at home, without even installing it on their home machine.

The LTSP server software allows administrators, IT managers and teachers to create a low cost computer lab so that users can have access to the opportunities that GNU/Linux and the Internet can provide.

Since setups can be adjusted to many situations, each thin client lab can be uniquely tailored to fit the business, agency or educational facility in question.

Networking works by breaking files and other data into little packets of information. These packets are transferred over a network. The difference between various types of networks is how they transfer packets.

There are two types of networking hardware: wired and wireless.

An important fact to remember is that a network will be only as fast as the slowest part. Making sure that your network setup matches your intended use case is an important consideration in an LTSP network.

The most common network infrastructure services include:

From here, all operations such as authenticating your username and password, launching applications, and viewing websites are actually handled on the LTSP server rather than the thin-client. The LTSP server transfers all graphical information to the thin-client over the network. This allows very low powered thin-clients to utilize the power of the server for all operations. It also allows for large client deployments with reduced overall resource utilization, as 50 thin-clients all running the popular OpenOffice suite under different sessions generally only require enough RAM for a single instance of OpenOffice (excluding per-user configuration which is minimal). The server shares memory between user sessions, so libraries for applications are only loaded once and referenced for each user session.

A person setting up a LTSP thin client environment for the first time, typically asks two questions:

Chances are, hardware that you already have is more than sufficient for terminals. One of the great advantages of an LTSP Server is that you can set up a high quality lab of terminals for your students to use, by leveraging the machines you already have. As for servers, usually, it's very easy to turn any high-end single user desktop machine into a terminal server capable of handling many thin clients. We'll present some guidelines that should help in making the most of your resources.

Server sizing in an LTSP network is more art than science. Ask any LTSP administrator how big a server you need to use, and you'll likely be told "It depends". How big a server you need does depend largely on what it is you're planning on doing with your thin client network. The server requirements needed for a network where the only use will be a little light web-browsing, with no Java or Flash, will be greatly different from a network where you want to do heavy graphics, interactive games, and Flash animation. Here are some common guidelines that should fit most "average" cases.

Depending on your network card, it may already contain a boot ROM, or you may be able to use an EPROM programmer to create your own. Check the hardware documentation for the network card in your thin client for details.

If your network card in the thin client doesn't have a boot ROM built in, and you don't have access to an EPROM burner, have no fear! Chances are, that old machine has a floppy drive, or CD-ROM in it. If so, then you can use local media to boot the thin client.

With the integration of LTSP into distributions, installation of LTSP is now usually as easy as adding the LTSP packages in your distro's package manager. Consult your distribution's documentation for details on how to install LTSP on your particular system.

However, as a general guideline, usually after you've installed your distributions' LTSP packages, and configured your network interfaces, and some kind of DHCP3 server, you'd run (as root):

sudo ltsp-build-client
            

If you are on a 64-bit system but your clients have another architecture use the --arch option e.g.

ltsp-build-client --arch i386

After that, you should be able to boot your first thin client.

In order to speed up LTSP, by default, we're using NBD (Network Block Devices) rather than NFS. To do this, we'd had to move the the lts.conf file out of the chroot and into the TFTP directory, in /var/lib/tftpboot/ltsp/<arch>, where <arch> is the architecture you are working on (usually i386, but could be something else, like amd64 for example). This means you can make changes to the file immediately, and simply reboot the terminal, without recompiling the image.

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_SESSION=/usr/bin/myloginscript
            

Section headings begin with an identifier in the form [Default] which is used for all computers as mentioned above, and [MAC address] for individual workstations, 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 best way to check for the MAC address of the machine is by starting it up, checking its IP number and doing a arp -an on the server, this should then tell you which IP number has which MAC address.

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:

VARIABLE = value
            

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.

The LIKE keyword allows you to define a general set of parameters under a unique identifier, and then assign individual workstations that set of parameters using the LIKE keyword. An example will illustrate it's use.

Let's assume you have 3 kinds of thin clients on your network. One set, which are used in the lab, have older video cards, and must use 16 bit colour at 1024x768 resolution. Another set need to have their video ram set to 8 megs, and a third set which auto-detect everything correctly. We don't need to specify anything for the third set, but having some symbolic names for the first two would help us to maintain the lts.conf file.

Here's an example lts.conf that illustrates how this would be done:

[Lab]
    X_COLOR_DEPTH = 16
    X_MODE_0 = 1024x768

[Lowram]
    X_VIDEO_RAM = 8096

[00:40:32:71:77:A1]
    LIKE = Lab

[00:70:84:BB:27:52]
    LIKE = Lowram
            

As you can see, using the LIKE keyword can make your lts.conf more readable, by allowing you to group related parameters together into a single symbolic name.

To accommodate this, Xorg now understands partial xorg.conf files. Meaning you only add the sections that you need to force. Otherwise, it discovers everything. That's why you might see minimalist xorg.conf files in your LTSP chroot.

The screen-session.d/ directory (located in the chroot's /usr/share/ltsp directory) is a structure of shell scripts all of which are sourced in order (similar to Xsession.d/ or rc.d/ that you may be familiar with). These scripts are executed upon the beginning of each session but before the Xserver (if the session runs an Xserver) is launched. You can make whatever script you want that may need to run at that point. For LTSP, one thing we use it for is to set up how the Xserver will be launched. This entails not just generating a xorg.conf file as needed, but also configuring the parameters that the Xserver should be launched with. The nice thing about a collection of sourced scripts is that it gives flexibility to the distribution or to the administrator to add additional scripts that may be required for that distribution or for a particular network environment that will not modify existing files (and therefore require more maintenance to care for updates in the upstream code).

Each script is named with a prefix letter, then an order number, then a name. The prefix letter determines when the scripts of that prefix are executed and the order number determines in what order.

PREFIXES: Prefixes that may be used include:

S - Is a script that runs at the beginning of a session (screen script) K - Is a script that runs at the end of a session (screen script) XS - Is a script that is only run at the beginning of screen scripts that run an Xserver

All of the scripts that generate a xorg.conf or modify the Xserver arguments are XS* scripts.

These scripts are mostly organized by the particular lts.conf parameter or function that they affect. For example, XS85-xvideoram adds the ability to specify the X_VIDEO_RAM parameter in lts.conf and force the amount of video ram used by the driver.

If you are going to create your own script, I recommend looking at other scripts to understand the structure. Since many hacks may impact the same xorg.conf sections, each section has a function of hacks assigned to it, and in your script, you would create a function and add it to the list of functions for that section. For example, if you add something to the Monitor section (that cannot already be added through existing functions) you would create a function in your script and add it to the monitor_hacks function list. Again, easier to read the code and look at examples to understand how to write a new script.

Also, please note that one of the lts.conf parameters you can specify is: CONFIGURE_X_COMMAND This should be set to a path to a script. So, if you have the old configure-x.sh and like it better, simply copy it into the chroot, to say, /opt/ltsp/<arch>/usr/share/ltsp/configure-x.sh and then in lts.conf, specify:

CONFIGURE_X_COMMAND =
                    "/usr/share/ltsp/configure-x.sh"

and you will be back to where you were.

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 LTSP, and has a lot of useful features:

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:

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 section.

This new version of LDM supports auto login of accounts, if specified in the lts.conf file. Simply create a config section 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:

In this version of LTSP, there's a simple load-balancing solution implemented that allows administrators to have multiple LTSP 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 for details.

LDM has a very good system for handling user-supplied rc.d scripts. This allows people looking to add site-specific customizations to their LTSP setups an easy way to integrate this functionality into LTSP.

These rc.d scripts can be placed in $CHROOT/usr/share/ldm/rc.d/. They are executed in the usual rc.d type method, so you must make sure that any script you write will not make a call to exit.

The files start with the letter I, S, K, or X, and have two digits after them, allowing you to place them in order of execution. The letters stand for:

Your scripts can make use of the following environment variables in the S, X, and K scripts:

You can use these variables to create scripts that customize behaviors at login time. For instance, lets say you were running the GNOME desktop environment, and wanted to force your users to have blank-only mode for their screen savers, to save network bandwidth.

Since the script is actually running on the thin client itself, you want this script to set this up on the server, where the Gnome session is running. That's where you can make use of the LDM_SOCKET and LDM_SERVER environment variables to run an ssh command on the server, using the control socket that LDM has set up. Here's an example script. You could install this into $CHROOT/usr/share/ldm/rc.d/X01-set-blankonly:

#
# sourced with .
#
# Script to automatically switch gnome screensaver to blank
# only mode
#
ssh -S ${LDM_SOCKET} ${LDM_SERVER} "/usr/bin/gconftool-2 --set --type string /apps/gnome-screensaver/mode blank-only"
            

Using this mechanism, it's easy to customize your LTSP setup to your needs.

A multiple server setup is useful for larger thin client networks. Instead of using one big server, it makes it possible to use smaller servers, and dispatch users on them. You can adjust computing resources as the demand grows simply by adding a new server. To make sure that every server behaves the same from the users point of view, new services and configurations that are required will be discussed. In addition, some configurations specific to thin clients will be presented.

The network topology is the same as a standalone server setup, except that there are more than one server on the thin client LAN.

You will need to select one server to behave as the primary server. This server will be used to run additional services, hold users files, and network boot thin clients.

Secondary servers will be used only to run desktop sessions. They are simpler, and will be configured to use the central services from the primary server.

A user should be able to start a session with the same login and password, no matter which server it connects to. For this purpose, a central authentication mechanism must be used. There are many possibilities offered. Here are the major technologies:

For detailed instructions, see their respective manuals.

Shared home directories are easy to setup using an NFS server on eithe the primary LTSP server, or even better, a standalone NFS server. Other more modern, faster (and consequently more expensive) options include a SAN, and maybe even moving to a fibre-channel raid SAN. Consult your distribution's documentation for details and suggestions for setting up an NFS server.

For printers to be accessible on each server, the cups server must be configured to share printers. Refer to the CUPS manual for your distribution for detailed setup instructions.

Note that an LTSP thin client acting as a print server resembles a JetDirect print server.

For security reasons, a thin client won't connect to an untrusted server. You must add the keys of secondary servers inside the client root on the primary server. To do this, first export the key file of the secondary server using LTSP's tools. As root, run:

ltsp-update-sshkeys --export ssh_known_hosts.myhostname
            

Then, copy the file ssh_known_hosts.myhostnam to the primary server, in the directory /etc/ltsp/ and run ltsp-update-sshkeys on the primary server. Then, thin clients will trust the freshly added server, and will be able to connect to it.

If a secondary server changes it's IP address, then this procedure must be repeated.

The purpose of IP Masquerading is to allow machines with private, non-routable IP addresses on your network to access the Internet through the machine doing the masquerading. Traffic from your private network destined for the Internet must be manipulated for replies to be routable back to the machine that made the request. To do this, the kernel must modify the source IP address of each packet so that replies will be routed back to it, rather than to the private IP address that made the request, which is impossible over the Internet. Linux usesi Connection Tracking (conntrack) to keep track of which connections belong to which machines and reroute each return packet accordingly. Traffic leaving your private network is thus "masqueraded" as having originated from your gateway machine. This process is referred to in Microsoft documentation as Internet Connection Sharing.

IP Forwarding with IP Tables

LDM is a login manager for thin clients. Users can select a server from the available ones in the host selection dialogue box.

The displayed server list is defined by the LDM_SERVER parameter. This parameter accepts a list of server IP address or host names, separated by space. If you use host names, then your DNS resolution must work on the thin client. If defined in the lts.conf file, the list order will be static, and the first server in the list will be selected by default.

You can also compute a new order for the server list, by creating the script /opt/ltsp/<arch>/usr/lib/ltsp/get_hosts . The parameter LDM_SERVER overrides the script. In consequence, this parameter must not be defined if the get_hosts is going to be used. The get_hosts script writes on the standard output each server IP address or host names, in the chosen order.

You can change this behaviour by using a script to rearrange the list. The simplest way to do it is by randomizing the list. First, define a custom variable in the file lts.conf , for example MY_SERVER_LIST, that will contain the list of servers, the same way as LDM_SERVER Then, put the following script in /opt/ltsp/<arch>/usr/lib/ltsp/get_hosts

#!/bin/bash
# Randomize the server list contained in MY_SERVER_LIST parameter
TMP_LIST=""
SHUFFLED_LIST=""

for i in $MY_SERVER_LIST; do
    rank=$RANDOM
    let "rank %= 100"
    TMP_LIST="$TMP_LIST\n${rank}_$i"
done

TMP_LIST=$(echo -e $TMP_LIST | sort)
for i in $TMP_LIST; do
    SHUFFLED_LIST="$SHUFFLED_LIST $(echo $i | cut -d_ -f2)"
done
echo $SHUFFLED_LIST
            

More advanced load balancing algorithms can be written. For example, load balancing can be done by querying ldminfod for the server rating. By querying ldminfod, you can get the current rating state of the server. This rating goes from 0 to 100, higher is better. Here is an example of such a query:

nc localhost 9571 | grep rating | cut -d: -f2

Just like on a full fledged workstation, it helps to have swap defined for your thin client. "Swap" is an area of disk space set aside to allow you to transfer information out of ram, and temporarily store it on a hard drive until it's needed again. It makes the workstation look like it has more memory than it actually does. For instance, if your workstation has 64 Megabytes of ram and you configure 64 Megabytes of swap, it's theoretically possible to load a 128 Megabyte program.

We say, "theoretically", because in practice, you want to avoid swapping as much as possible. A hard drive is several orders of magnitude slower than ram, and, of course, on a thin client, you don't even have a hard drive! You have to first push the data through the network to the server's hard drive, thus making your swapping even slower. In practice, it's best to make sure you have enough ram in your thin client to handle all your average memory needs.

However, sometimes that's not possible. Sometimes, you're re-using old hardware, or you've simply got a program that isn't normally used, but does consume a lot of ram on the thin client when it does. Fortunately, LTSP supports swapping over the network via NBD, or Network Block Devices. We include a small shell script called nbdswapd, which is started via inetd. It handles creating the swap file, and setting up the swapping, and removing the swap file when it's no longer needed, after the terminal shuts down.

By default, swap files are 32 Megabytes in size. This was chosen to give your workstation a little extra ram, but not use up too much disk space. If you get some random odd behaviour, such as Firefox crashing when viewing web pages with a lot of large pictures, you may want to try increasing the size of the swap files. You can do so by creating a file in the directory /etc/ltsp on the LTSP server, called nbdswapd.conf. In it, you can set the SIZE variable to the number of Megabytes you wish the file to be sized to. For instance, to create 128 Megabyte files, you'll want: SIZE=128 in the nbdswapd.conf file.

Please note that this is a global setting for all swap files. If your server has 40 thin clients, each using 128 Megs of memory, you'll need 128 * 40 = 5120, or a little over 5 Gigabytes of space in your /tmp directory, where the swap files are stored.

DHCP stands for Dynamic Host Configuration Protocol and is the very first thing your thin client uses to obtain an IP address from the network, in order to allow it to start booting. In LTSP, the dhcpd file is located in /etc/ltsp. Any changes you want to make to booting behaviour should be made there.

By default, LTSP ships a dhcpd.conf that serves thin clients in a dynamic range (i.e. it will hand out ip addresses to anyone who asks for them) from 192.168.0.20 to 192.168.0.250. The default dhcpd.conf file looks like:

#
# Default LTSP dhcpd.conf config file.
#

authoritative;

subnet 192.168.0.0 netmask 255.255.255.0 {
    range 192.168.0.20 192.168.0.250;
    option domain-name "example.com";
    option domain-name-servers 192.168.0.1;
    option broadcast-address 192.168.0.255;
    option routers 192.168.0.1;
#    next-server 192.168.0.1;
#    get-lease-hostnames true;
    option subnet-mask 255.255.255.0;
    option root-path "/opt/ltsp/i386";
    if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
        filename "/ltsp/i386/pxelinux.0";
    } else {
        filename "/ltsp/i386/nbi.img";
    }
}
            

This dhcpd.conf should handle most situations.

By default, LTSP will detect an unused network interface and configure it to be 192.168.0.254. LTSP's recommended single server installation is to use a separate network interface for the thin clients. If, however, you're not using two network interfaces, or you already have an interface in the 192.168.0 range, then you might have to configure the thin client interface differently, which means you may have to adjust the dhcpd.conf accordingly.

If the network interface that you're going to connect the thin clients to has, say, a TCP/IP address of 10.0.20.254, you'll want to replace every occurrence of 192.168.0 with 10.0.20 in the dhcpd.conf file.

Always remember, you'll need to re-start the dhcp server if you make any changes. You can do this by issuing the command:

sudo invoke-rc.d dhcp3-server restart

(at the command prompt.)

If you customize user's desktop, then custom desktop profiles should be copied to every server. Gnome desktop profiles created with Sabayon are located in /etc/desktop-profiles

By choosing a single user and right clicking on that users name, you will open up the context menu. From here you can choose "Lockdown", which will allow you to set options to restrict a particular user. Clicking this menu item will invoke the "Pessulus" program, which is the Gnome lockdown editor. Ticking and unticking options in Pessulus will enable and disable certain functions for that particular user. There is a padlock next to each option in Pessulus. Ticking this will make the option unchangeable by the user. This is called a mandatory setting. For further help with Pessulus, please refer to the Pessulus documentation.

Edit the udev rules to enable the disabled (there is a good reason for this, like all users having access the the hard drive contents) udev line related to hard drives in /opt/ltsp/<arch>/etc/udev/rules.d/<some-letter-and-number>-ltspfd.rule

ACTION=="add", SUBSYSTEM=="block", ENV{ID_TYPE}=="disk", ATTRS{removable}!="1", RUN+="ltspfs_entry add %k"
            

In the lts.conf file add LOCALDEV=True

Rebuild the image with ltsp-update-image and reboot thin client.

Using NBD instead of NFS has several advantages:

However, some people still want to use NFS. Fortunately, it's easy to switch back to NFS, if it's so desired:

First, I am going to start with a couple assumptions:

Create a new image to ensure your configuration is congruent with my successfully tested configuration.

sudo ltsp-build-client --copy-sourceslist --arch i386
            

(note the --arch i386 command is required for my system because it's running an amd64 kernel. It may not be required for individuals running a 32-bit kernel)

Download the pertinent VIA unichrome driver for your chipset from this web site: http://linux.via.com.tw/support/downloadFiles.action Be sure to select the proper OS as well. The installation script is set up specifically for the directory structure of each OS, and will error out if the wrong OS release is installed. Next we need to move the downloaded file to the image directory

cp /home/<username/Desktop/chrome9.83-242-sl10.1.tar.gz /opt/ltsp/i386
            

After that, we need to chroot to the same image directory.

sudo chroot /opt/ltsp/i386/
            

Unpack the driver in the root directory

tar -zxvf chrome9.83-242-sl10.1.tar.gz
            

After unpacking, enter the directory:

cd chrome9.83-242-sl10.1/
            

Run the file contained inside to start the driver installation

./vinstall ..................done! Original X config file
was saved as /etc/X11/xorg.conf.viabak
            

(The following error: "VIAERROR:The /etc/X11/xorg.conf is missing!" Can be ignored. We will be replacing the xorg.conf anyway, and the drivers are still installed properly.)

Next we need to put a proper xorg.conf in to the proper directory.

gedit /etc/X11/xorg.conf
            

Now paste the following in to the empty file:

Section "Module"
    Load "extmod"
    Load "dbe"
    Load "dri"
    Load "glx"
    Load "freetype"
    Load "type1"
EndSection

Section "Files"
    RgbPath "/usr/X11R6/lib/X11/rgb"
    FontPath "/usr/X11R6/lib/X11/fonts/misc/"
    FontPath "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
    FontPath "/usr/X11R6/lib/X11/fonts/75dpi/"
    FontPath "/usr/X11R6/lib/X11/fonts/Type1"
    FontPath "/usr/X11R6/lib/X11/fonts/TTF"
EndSection

Section "ServerFlags"
    Option "Dont Zoom"
    Option "AllowMouseOpenFail" "Yes"
    Option "BlankTime" "20"
    Option "StandbyTime" "0"
    Option "SuspendTime" "0"
    Option "OffTime" "0"
    Option "Xinerama" "on"
EndSection

Section "InputDevice"
    Identifier "Keyboard1"
    Driver "Keyboard"
    Driver "keyboard"
    Option "AutoRepeat" "500 30"
    Option "XkbRules" "xfree86"
    Option "XkbModel" "pc105"
    Option "XkbLayout" "en_US,en_US"
    Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll" EndSection
EndSection

Section "InputDevice"
    Identifier "USBMouse"
    Driver "mouse"
    Option "Protocol" "IMPS/2"
    Option "Device" "/dev/input/mice"
    Option "ZAxisMapping" "4 5"
    Option "Buttons" "5"
EndSection

Section "InputDevice"
    Identifier "Mouse1"
    Driver "mouse"
    Option "Protocol" "Auto"
    Option "Device" "/dev/psaux"
    Option "ZAxisMapping" "4 5"
    Option "Buttons" "5"
EndSection

Section "Monitor"
    Identifier "Monitor0"
    HorizSync 31.5-48.5
    VertRefresh 60
    Option "DPMS"
EndSection

Section "Device"
    Identifier "CN700"
    Driver "via"
    VideoRam 16384
    Screen 0
    Option "NoDDCValue" "1"
    Option "Simultaneous"
    Option "DPMS" "on"
    BusID "PCI:1:0:0"
EndSection

Section "Screen"
    Identifier "Screen0DVI"
    Device "CN700DVI"
    Monitor "Monitor0DVI"
    DefaultDepth 24
    Subsection "Display"
        Depth 8
        Modes "1280x1024"
        ViewPort 0 0
    EndSubsection
    Subsection "Display"
        Depth 16
        Modes "1280x1024"
        ViewPort 0 0
    EndSubsection
    Subsection "Display"
        Depth 24
        Modes "1280x1024"
        ViewPort 0 0
    EndSubsection
EndSection

Section "Monitor"
    Identifier "Monitor0"
    HorizSync 31.5-48.5
    VertRefresh 60
    Option "DPMS"
EndSection

Section "Device"
    Identifier "CN700DVI"
    Driver "via"
    VideoRam 16384
    Screen 1
    Option "NoDDCValue" "1"
    Option "Simultaneous"
    Option "DPMS" "on"
    BusID "PCI:1:0:0"
EndSection

Section "Screen"
    Identifier "Screen0"
    Device "CN700"
    Monitor "Monitor0"
    DefaultDepth 24
    Subsection "Display"
        Depth 8
        Modes "1280x1024"
        ViewPort 0 0
    EndSubsection
    Subsection "Display"
        Depth 16
        Modes "1280x1024"
        ViewPort 0 0
    EndSubsection
    Subsection "Display"
        Depth 24
        Modes "1280x1024"
        ViewPort 0 0
    EndSubsection
EndSection

Section "ServerLayout"
    Identifier "Simple Layout"
    Screen "Screen0" 0 0
    Screen 1 "Screen0DVI" LeftOf "Screen0"
    InputDevice "Mouse1" "CorePointer"
    InputDevice "Keyboard1" "CoreKeyboard"
    InputDevice "USBMouse" "AlwaysCore"
EndSection
            

IMPORTANT NOTE IN THE ABOVE SECTION PASTED INTO THE XORG.CONF, NOTICE THAT THERE ARE RESOLUTIONS SPECIFIED PER MONITOR. PLEASE ENSURE THAT YOU HAVE THE PROPER RESOLUTIONS FOR YOU YOUR MONITOR ENTERED ON THOSE AREAS. Be sure to save the file as xorg.conf and exit out of your chroot'd image. <CTRL+D or "exit"> next we need to put in an addendum in the lts.conf

gedit /var/lib/tfpboot/ltsp/i386/lts.conf
            

Feel free to comment out anything that you need to in the lts.conf. I will include my full lts.conf as an example:

[DEFAULT]
    #X_COLOR_DEPTH = "16"
    #X_MODE_0 = "1680x1050"
    #X_VERTREFRESH = "43-61"
    #X_HORZSYNC = "28-85"
    #X_OPTION_01 = "\"ForcePanel\" \"True\""
    #X_OPTION_01 = "\"NoPanel\" \"true\""
    #SCREEN_02 = shell
    #SCREEN_07 = ldm
    X_CONF = /etc/X11/xorg.conf
            

Feel free to copy-paste this in it's entirety if you want, but you will only need the last line. After you add the X_CONF line, save & exit. Now we need to make the changes that we have made take effect in the image

# sudo ltsp-update-image --arch i386
            

(again, the --arch i386 will not be required for most, but I am putting it in just in case a user has a x64 installation on their server.) That should do it! Boot up the client and you should be good to go.