This page is specific to Ubuntu versions 10.04, 10.10, 11.04, 11.10
If you find this information applicable to additional versions/releases, please edit this page and modify this header to reflect that. Please also include any necessary modifications for this information to apply to the additional versions.
LTSP 5.2 comes with support for fat clients. Similarly to thin clients, fat clients use the server as a network disk for /home and for the root file system, and authenticate with ldm/ssh. But in contrast with thin clients, fat clients use their own RAM and CPU power to run the applications. Of course this also means that their hardware requirements are the same as for running Ubuntu on normal workstations.
Similarities & Differences between Fat (thick) and Thin
- Home directory is mounted on login (with sshfs, optionally with NFS), while thin client is directly on the server.
The NBD root on the thin client version simply has to get the client to SSH/LDM logon screen and provide an X-Window server, whereas the fat client has a larger NBD root filesystem containing a complete OS with all the desired additional programs (i.e. LibreOffice).
- Since processes are running on the client rather than the server, as an admin, you can't interact with them (kill, etc) from a central location.
- Since processes are running locally, there is less maintenance required to kill 'stale' processes that accumulate on a thin client LTSP setup.
- Internet connectivity needs to be provided directly to the client, i.e. the client needs to be directed to an Internet gateway via DHCP. In a standard LTSP thin client setup, the client apps runs on the server, so all network traffic originates and routes through the server.
- In the same thread as 3.) out-of-control processes will not bring down the entire server, just the abusing client.
ltsp-build-client fat-client parameters
A chroot for fat clients needs to be specially prepared, either by providing some command line parameters to 'ltsp-build-client' or by creating an ltsp-build-client.conf file. The command line parameters are mentioned in this paragraph, while the rest of the document refers to the ltsp-build-client.conf method.
--arch: The thin client chroot architecture you'll be installing. This is the CPU architecture of the fat clients that will be used. Must be a supported architecture of the --fat-client-desktop distribution. For Ubuntu they currently are i386, amd64, hppa, powerpc.
--chroot NAME: Replace NAME with what you want the chroot's name to be (for example, --chroot fat-i386 will produce /opt/ltsp/fat-i386 and associated nbd image name).
--fat-client: Creates and installs a FAT chroot that uses the same desktop environment that is installed on the server.
--fat-client-desktop: Creates and installs a FAT chroot with the specified desktop environment. Options are ubuntu-desktop, edubuntu-desktop among others. The option kubuntu-desktop is not tested.
--late-packages: Specify additional packages to install in the chroot (other than the ones you would normally get in a live session).
In the following paragraphs the method that uses an ltsp-build-client.conf file is described. Any parameters would be put in that file, so that in the end you'll just need to run sudo ltsp-build-client with no parameters at all.
Install ltsp-server-standalone (or ltsp-server, if you have an external DHCP server):
sudo apt-get install ltsp-server-standalone
Lucid warning: if ldm-server installation hangs, switch to another terminal, and run:
sudo service openbsd-inetd restart
Run the following command to create the ltsp-build-client configuration file
sudo gedit /etc/ltsp/ltsp-build-client.conf
and paste the following contents into it, while adjusting them to your needs:
# The chroot architecture. ARCH=i386 # ubuntu-desktop and edubuntu-desktop are tested. # If you test with [k|x]ubuntu-desktop, edit this page and mention if it worked OK. # kubuntu lucid (10.10) working okay. FAT_CLIENT_DESKTOPS="ubuntu-desktop" # Space separated list of programs to install. # The java plugin installation contained in ubuntu-restricted-extras # needs some special care, so let's use it as an example. LATE_PACKAGES=" ubuntu-restricted-extras gimp nfs-client " # This is needed to answer "yes" to the Java EULA. # We'll create that file in the next step. DEBCONF_SEEDS="/etc/ltsp/debconf.seeds" # This uses the server apt cache to speed up downloading. # This locks the servers dpkg, so you can't use apt on # the server while building the chroot. MOUNT_PACKAGE_DIR="/var/cache/apt/archives/"
When chroot is created and populated, should take the localization from the server environment, but seems is not the case. So only "en" language package are installed, and locale (so also keyboard) is not correctly set. So if you are, for instance, Greek, you should add to the above file (or pass through command line) something like:
and in the list of packages (i.e. under "nfs-client" of the previous example) something like that:
language-pack-el language-pack-gnome-el language-pack-kde-el language-support-el openoffice.org-l10n-el openoffice.org-help-el openoffice.org-hyphenation
For instance, in Kubuntu 11.10 for Italian language I put:
LOCALE="it_IT.UTF-8" kde-l10n-it language-pack-kde-it-base language-pack-kde-it firefox-locale-it language-pack-it language-pack-it-base myspell-it language-support-writing-it libreoffice-help-it firefox-locale-it
Run the following command
sudo gedit /etc/ltsp/debconf.seeds
to create a new file that will contain the debconf seeds, which are needed for the unattented Java and msttcorefonts installation. Paste the following lines into that file:
# Do you agree with the DLJ license terms? sun-java6-bin shared/accepted-sun-dlj-v1-1 boolean true sun-java6-jre shared/accepted-sun-dlj-v1-1 boolean true # In order to install this package, you must accept the license terms, the # "TrueType core fonts for the Web EULA ". Not accepting will cancel the # installation. Do you accept the EULA license terms? ttf-mscorefonts-installer msttcorefonts/accepted-mscorefonts-eula boolean true
Of course adding those keys manually means that you have read and accepted the Java and msttcorefonts EULA.
Reenabling NBD compression
Up until Ubuntu 9.10, the NBD image at /opt/ltsp/images/i386.img was compressed with squashfs so that it needed less bandwidth over the network, thus making the clients faster. From 10.04 and on, compression has been disabled because of some unidentified problems. In 11.04 it was discovered that the problems were caused by nbd-proxy and not by NBD compression, so nbd-proxy was disabled instead. So you can safely reenable NBD compression by removing the following line from /etc/ltsp/ltsp-update-image.conf:
NO_COMP="-noF -noD -noI -no-exports"
Then, run sudo ltsp-update-image to compress your NBD image. This should make NBD disk access for your clients about 2.5 times faster.
Extra steps for Oneiric
The fat client plugin blacklists some packages that don't make sense to have in a fat client chroot. Unfortunately in Oneiric xdiagnose depends on one of those packages, apport, so the fat client plugin needs to be manually edited for ltsp-build-client to complete successfully.
Run the following command
sudo gedit /usr/share/ltsp/plugins/ltsp-build-client/Ubuntu/030-fat-client
and remove the word "apport" from line 43. Save, exit, and continue with the steps below.
After the steps above, open a terminal, and just enter the command:
You might want to enable "unlimited scrollback" in your terminal preferences, so that you have all the logs in case of failure. If everything goes well, when it finishes you'll be able to boot your fat clients. If you want some clients to be booted as thin clients instead, you can put LTSP_FATCLIENT=false in lts.conf for those clients.
Further chroot customizations
To install additional programs after the initial chroot generation, the upstream "ltsp-chroot" script might help you. Unfortunately it's not available for older Ubuntu versions, so you may download it from launchpad or ltsp-chroot for Ubuntu 10.04. Save it in /usr/sbin, run "chmod +x /usr/sbin/ltsp-chroot", and then "ltsp-chroot --help" to see its usage. For example, this will get you a command prompt inside the chroot, while mounting /proc and the package cache:
sudo ltsp-chroot -c -p
While inside the chroot, you may run apt-get update/dist-upgrade/install etc. Of course every time you modify your chroot you also need to run ltsp-update-image (and possibly ltsp-update-kernels) afterwards.
Relevant lts.conf parameters
You can use the fat chroot also to run thin clients, not only fat ones. This way you can have a mix of powerful and not powerful clients, that they will become "fat" or "thin" based upon their RAM (consider fat chroot a "superset" of a thin one, so thin boot uses only a small but common part of it). The parameter that affects the RAM threshold is:
that defaults to 300 (MB). So if you want your client boot as FAT ones only if they have more than 800MB edit lts.conf and put:
Another interesting feature is have a server's directory available to all the fat clients (through sshfs). For instance, to have the fat clients mount as their own /srv the /srv of the server add this parameter:
If you want to mount multiple dirs use coma as separator without spaces (i.e. /srv,/mydir). Also mountpoint in the chroot has to be empty, otherwise server dir will not be mounted (i.e. if in chroot you have /srv/subdir). Alternative method is use NFS mount and FSTAB_1 (to FSTAB_9) parameter.
KDE 4.x special notes
KDE works well as thin client, but as Fat client special considerations have to be done. The plasma desktop does a lot of I/O that is specially intensive through LAN. In addition, under ~/.kde a symlink is created to /var/tmp/kdecache-$USER, a dir populated with about 100MB of cached data at the first login. This directory is intended to survive reboots and make Plasma run faster. In fat that dir is wrote in client /var/tmp that is in RAM, reducing RAM available and being lost at every reboot.
Without special cares, due probably to some process crashing and re-running because of the difficult with symlinks and sshfs, the network traffic from LDM login to Plasma loaded is of about... 700MB! If you have many clients the process becomes so slow that login is practically impossible. With the described tips is reduced to 140MB at first login, and 96MB for subsequent logins.
Also when you change fat client and has a different sound hardware, Phonon prompts the user with questions about if discard old audio device configs, and if do it permanently or not, and this is annoying and confuses the user.
To solve the above issues, in the hope that in the future KDE developers will be able to help on this regards, I've found this way to reduce the problem: First you have to create this file in chroot:
with this content:
rm "$HOME/.kde/share/config/phonondevicesrc" KDEVARTMP=$HOME/.cache export KDEVARTMP
and of course rebuild the NBD image.
Then you have to export the home directory through NFS and use the "async" parameter, that is more risky for data integrity of open files if server crashes, but increases a lot I/O performances:
and you mount it in the client with this line in lts.conf (the parameter NFS_HOME is obsolete):
FSTAB_1="server:/home /home nfs defaults,nfsvers=3,nolock 0 0"
Remove the user's kde configuration removing it's .kde directory, or just pick up the symlink there and delete it, remove the dir /var/tmp/kdecache-username if present in the server.
Some applications, like pulseaudio, googleearth, google chrome etc, try to create locks/symlinks from within the sshfs mounted user home directory to other places like /proc or /tmp. For those apps to work, SSH_FOLLOW_SYMLINKS=False is required in lts.conf.
Unfortunately, even with SSH_FOLLOW_SYMLINKS=False, some applications that require file locks (e.g. evolution) fail to run properly. A new lts.conf variable was introduced to overcome this, NFS_HOME. In order to use it,
- Install nfs-common in the chroot,
- Install nfs-kernel-server on your server,
Add /home *(rw,sync,no_subtree_check) to your /etc/exports on your server,
Run sudo exportfs -ra for the previous change to take effect,
And finally, add NFS_HOME=/home on your lts.conf.
If you're using a 2-NIC setup, where your fat clients are connected to one NIC of your server and your server connects to the internet through another NIC, then you'll need to follow the howto at ThinClientHowtoNAT to get internet access working on your clients.
Changing existing LTSP thin server to fat client mode
If you follow the above steps and get to the ltsp-build-client step, you may get an error about the client chroot existing, like so:
NOTE: Root directory /opt/ltsp/amd64 already exists, this will lead to problems, please remove it before trying again. Exiting.
This is just what it seems like, simply delete the old chroot (think first! If you have a highly customized chroot you will lose that stuff!)
UbuntuLTSP - Community Ubuntu LTSP Documentation.