Portuguese Brazilian Translation

Spanish Translation

LTSP Version 4.0

Ok, it's been a long time. Too long. But, LTSP-4 is finally available. The document below describes some of the new features, how to install it, how to configure it and, how to get the source code.

This is one of those things that we could probably spend another 2 years on, and still not feel that it has everything we'd like. But, at some point, we figured we just needed to release it and get as many people as possible using it.

Thank you,
Jim McQuillan - jam@Ltsp.org

New Features
Installation
Configuration
Local Applications
Source Code
LTSP Build Environment (LBE)

Check the LTSP-4 Errata page for the latest news

• Changes to RUNLEVEL

  The RUNLEVEL setting in lts.conf is no longer used. It has been replaced with the SCREEN_xx settings described below in Screen scripts.

• ltspcfg

  We drastically changed the way LTSP is installed. That is, we separated the "installing" of the LTSP tree from the "configuring" of the services on the server.

  This will make it easier to install LTSP on any version of any distro. The actual installion is simply a matter of unpacking the tree in the right place. Either from a tarball, an RPM, a DEB package or whatever.

  The "configurating" can either be done manually, or by using a new tool called ltspcfg.

  This new utility has the logic built in to figure out how to enable the various servers, such as DHCP, TFTP, NFS and XDMCP on the server. And, if it can't figure out how to enable the service, it will tell you, so that you can enable it manually.

  Gone are the days of seeing the message "Sorry This distro is not supported by LTSP"

  The getltscfg is not finished yet, but is very close.

• Screen scripts

  With previous versions of LTSP, the type of session to appear on the workstation was dictated by the 'RUNLEVEL' parameter in the lts.conf file. A runlevel of 5 would invoke a GUI interface. A runlevel of 4 would invoke a Telnet session, and runlevel 3 was for diagnostics mode. (Bash shell prompt).

  Now, the type of session can be selected for each virtually tty. That is, you could have 6 telnet sessions on vt1 - vt6. Or, you could have a couple telnet sessions and a GUI session. Or, with future add-ons, you could have things like local Rdesktop sessions (yes, that's plural) or SSH sessions or local X Window desktops. All of this is controlled by new parameters in the lts.conf file.

  Here's an example:

         SCREEN_01  = telnet 192.168.254.254
         SCREEN_02  = startx 

  One great thing about the screen scripts is that it is easy to create new screen scripts without hacking any of the core ltsp code. They just drop into the /opt/ltsp/i386/etc/screen.d directory and are then available to the lts.conf file.

  Here is a list of the currently available screen scripts:

  • startx

    This will launch X on the screen (Equivalent to RUNLEVEL = 5 on ltsp-3)

  • telnet

    Runs a character based telnet session back to the server. (Equivalent to RUNLEVEL = 4 on ltsp-3)

  • shell

    Runs a shell on the terminal. This is intended for DIAGNOSTICS mode only. (Equivalent of RUNLEVEL = 3 on ltsp-3).

  • rdesktop

    This will launch X with rdesktop as the only application. The idea is that you'd run rdesktop in full screen mode, connecting directly to a windows server, without having to log into Linux first.

  More screen scripts can be written to do almost anything on the workstation. Take a look at the existing scripts in /opt/ltsp/i386/etc/screen.d for examples of how to write a script.

• getltscfg has been rewritten

  getltscfg is the program that reads the lts.conf file. It has been rewritten using bison and flex. This makes the parsing faster, and gives us greater flexibility in the syntax. We now have a 'LIKE' keyword that will allow sections to inherit the settings from other sections.

  Here is an example where you have several HP Vectras and several Dell Dimension PCs that you are using:

  
         [Vectra]
             X_MOUSE_DEVICE   = /dev/ttyS0
             X_MOUSE_PROTOCOL = Microsoft
      
         [Dimension]
             X_MOUSE_DEVICE   = /dev/psaux
             X_MOUSE_PROTOCOL = IMPS/2
         
         [ws001] LIKE = Vectra 
      
         [ws002] LIKE = Vectra 
      
         [ws003] LIKE = Vectra 
      
         [ws004] LIKE = Dimension 
      
         [ws005]
             LIKE               = Dimension
             PRINTER_0_DEVICE   = /dev/ttyS1
             PRINTER_0_TYPE     = S
      
         [ws006] LIKE = Dimension 

  Notice that ws005 inherits from Dimension, but also includes a local printer.

• ltspinfod

  This is a daemon that runs on the workstation. A process on the server can query the daemon and ask it for information about the workstation. This is handy for things like SOUND. The profile script on the server can query the workstation to see if sound is enabled, and which sound daemon is being used.

• Local Apps

  Local apps has been greatly enhanced. We now use ssh to launch the apps on the workstation. ssh is absolutely more secure than rsh, but the main reason we chose ssh is because it was just plain easier to use. See Local Applications Info
  below for more information

• Source code

  Source code is now available for all of LTSP.

• LBE - The LTSP Build Environment

  A complete build environment, allowing easier building of local applications.

The installation procedure for LTSP has been greatly simplified. If you've ever installed Ximian Desktop 2, you'll feel right at home with the new installer for LTSP-4.

Step 1:

First of all, you'll need to be the Super-user. Then, a simple wget command will retrieve the ltsp installer, and start the installation process.

   su -
   wget -q -O - http://www.ltsp.org/ltsp_installer | sh

Step 2:

Once the installer has finished, you will need to configure various services on your server. We've created a new utility called 'ltspcfg', described below, to help you with the configuration process.

In the future, we do plan to offer RPM and DEB packages.

Step 3:

There isn't yet a specific kernel for LTSP-4. The kernels for LTSP-3 will work just fine with LTSP-4. You can use the RPM version of the kernel package, but you'll need to force the install, because it depends on the ltsp_core package from LTSP-3. A simpler way is probably to just install the ltsp_kernel TGZ package.

ltsp_kernel-3.0.15-i386.tgz

With LTSP-4, we've separated the installation from the configuration. We now provide a configuration tool called ltspcfg.

You can download either a RPM or a tarball package containing the ltspcfg tool.

ltspcfg will help you to configure the services needed for running LTSP workstations.

Installation notes for ltspcfg:

• RPM installation:

  rpm -ivh ltspcfg-0.5-0.noarch.rpm

• tarball installation:

  tar xvzf ltspcfg-0.5.tgz
  ./install.sh

In some cases, it is a waste to have a big powerful CPU and lots of RAM sitting on the desktop, and only using to run the Linux kernel and the X Server. So, with LTSP, you have the option to run some applications locally.

We launch the application using SSH.

To make ssh very secure, you'd have to store the workstations private key on some sort of local storage device, such as a floppy, flash disk or harddisk. We haven't gone that far with it yet. The private key is stored on the server and accessed via NFS. WE KNOW that this is a security problem. Our first goal with ssh was to make it possible to launch the applications on the workstation. We're working on making it as secure as possible.

A public/private key pair is shared among all workstations, and it needs to be created with ssh-keygen and stored in /opt/ltsp/i386/etc/ssh. Also, the public key needs to be stored in the /etc/ssh/ssh_known_hosts file. Actually, the same key needs to exist in that file several times. Once for each workstation, with the name of the workstation preceeding each record. Once that is setup, if you want to avoid having the user needing to enter their password each time they try to launch a local app, you'll need to put the users public key in their own authorized_keys file.

To generate the private/public key pair for the workstations, run the following commands:

    ssh-keygen  -q  -t rsa1  -f /opt/ltsp/i386/etc/ssh/ssh_host_key      -C ''  -N ''
    ssh-keygen  -q  -t rsa   -f /opt/ltsp/i386/etc/ssh/ssh_host_rsa_key  -C ''  -N ''
    ssh-keygen  -q  -t dsa   -f /opt/ltsp/i386/etc/ssh/ssh_host_dsa_key  -C ''  -N ''

You will then take the contents of the /opt/ltsp/i386/etc/ssh/ssh_host_rsa_key.pub and add a line in /etc/ssh/ssh_known_hosts for each workstation. Make sure you put the workstation name in front of each record.

Below is an example of how the /etc/ssh/ssh_known_hosts file should look:

    ws001  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...
    ws002  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...
    ws003  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...
    ws004  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...
    ws005  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...

Once ssh is setup, and NIS is configured on the server, the following settings need to be added to the lts.conf file:

    LOCAL_APPS       = Y
    NIS_DOMAIN       = ltsp

Once those settings are added, and the workstation is restarted, the user can launch programs on the workstation. Of course the application and all its libraries must be accessable to the workstation via NFS.

Here is a simple example of running a program on the thin client:

    ssh  ws001  uptime

I've been successful at getting Mozilla Firebird 0.7 to run as a local app. I didn't create an official package. This was more of a test, just to see if I could do it. And, it works !!! It requires copying a whole bunch of libraries into the /opt/ltsp/i386/usr/lib directory, and copying the Mozilla Firebird directory to /opt/ltsp/i386/usr/local/MozillaFirebird-0.7. Once that was done, launching Firebird on the thin client was done like this:

    ssh ws001 env DISPLAY=:0.0 /usr/local/MozillaFirebird-0.7/MozillaFirebird

One of the main reasons for creating LTSP-4 with the Build environment is so that we can build local applications. We definately plan on offering an official package including all Mozilla and all of the libraries needed.

LTSP-4 is build entirely from source code. That doesn't mean that you MUST build it. We have binary packages available as well. It's just that you CAN build it, and customize it all you want.

To get started with the source code, take a look at the information below on accessing the source via CVS.

Probably the largest single feature of LTSP-4.0 is the fact that it is entirely built from source code. In previous versions of LTSP, we took binaries from other distros (Mostly Redhat 7.0).

While going through the process of organizing the source code for all of the pieces of LTSP, we found that it was nearly impossible to account for all of the versions of development tools on all the platforms where people would want to build LTSP. For instance, to build Glibc-2.2, you need gcc-3.2 or newer to do it, and many existing Linux distributions don't yet include it. So, we came up with something that we call the LTSP Build Environment (LBE).

The LBE contains all of the compilers, linkers and any other utilities that are used for building LTSP. In fact, it is the exact same tools and versions that we use to build the official LTSP releases.

There has been an awful lot of work done on the LBE since LTSP-3 The whole build process has been redone, and the method of retrieving the source tarballs has changed.

New with LTSP-4 is the cross-compiler setup. We found that we needed to build a cross-compiler, to force the tools in the LBE to use the correct libraries and include files. We were going nuts trying to figure out why the LBE would build on some distros and not others. Then we figured out that each distro had different versions of header files, and this caused some things to break. So, we have a cross compiler now. Even though we are on an x86 system, and generating x86 code. One bright spot is that this gets us closer to a build environment where we can generate code for non-x86 clients. But, that's a future thing. We're not ready to tackle all of that yet. By having a cross-compiler, this also should eliminate the need for having specific versions of gcc and binutils on your system.

There is a fairly small core tree that is used to get the build process started. The source tarballs for each of the individual components of the LBE and LTSP are no longer stored inside of the core package. They are retrieved automatically, using wget, at the beginning of the build process.

Furthermore, the components that are common between the LBE and LTSP share the same tarball, rather than including a copy of the source twice. An example would be bash, the shell used for both the LBE and LTSP-4.0.

A very powerful build tool has been written for the LBE and LTSP. This tool reads a list of packages to be built, and then for each package, it reads the package.def file for instructions in how to actually do the build.

Building LTSP-4.0 from source:

1. Downloading from CVS

   The documentation for grabbing the LBE with CVS has been moved to a separate page. Click here for that document.

2. Building

   ./build_all

   This process will build the cross-compilers, the LBE, LTSP, the initrd and the LTSP kernel.

   Be prepared to wait a while. On a 2.5ghz P4, it takes about 3 hours.