ThinClientHowto

Differences between revisions 28 and 32 (spanning 4 versions)
Revision 28 as of 2005-10-27 12:48:54
Size: 7929
Editor: 213
Comment: Add an overview of thin client technology (Major addition)
Revision 32 as of 2005-11-13 21:44:47
Size: 7155
Editor: s64-186-37-120
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
To the user, a thin client behaves like a regular desktop computer. To the administrator, a thin client has no storage of it's own, is easy to maintain, and can give the user a modern computing experience even with ancient hardware. To the user, a thin client behaves like a regular desktop computer. To the administrator, a thin client has no storage of its own, is easy to maintain, and can give the user a modern computing experience even with ancient hardware.
Line 22: Line 22:
Once the kernel has been collected via TFTP, the kernel is executed; the machine boots linux. A ramdisk collected with the linux kernel is mounted as a root file system. This carries the necessary drivers for the network card, mouse, keyboard sound etc. Once the network card driver is loaded, a second DHCP request tells the client it's ip address, netmask, gateway, DNS server, and root NFS (Network File System) mount point. Once the kernel has been collected via TFTP, the kernel is executed; the machine boots linux. A initramfs collected with the linux kernel is mounted as a root file system. This carries and autodetect the necessary drivers for the network card, mouse, keyboard sound etc. Once the network card driver is loaded, a second DHCP request tells the client it's ip address, netmask, gateway, DNS server, and root NFS (Network File System) mount point.
Line 24: Line 24:
The linux kernel performs a pivot_root, which mounts the root NFS share from the server onto the thin client read-only. The thin client now has a booted linux kernel, and a root file system, much like any Linux system. From now on, when we talk of the root file system on the client, we are actually talking about a root file system mounted read-only from the server. The root file system mounted by the thin client is not be the same root file system the server itself uses, but is specially prepared for thin clients, and is shared by all thin clients connected to the server. The client kernel calls the init program. The /etc/lts.conf file is parsed, and settings for that thin client made (eg mouse driver, graphics adapter, Xserver etc). X -query <Server IP> is called. This launches X-windows on the client and tells X-windows where to connect to. The linux kernel runs the ubuntu initramfs, which mounts the root NFS share from the server onto the thin client read-only. The thin client now has a booted linux kernel, and a root file system, much like any Linux system. From now on, when we talk of the root file system on the client, we are actually talking about a root file system mounted read-only from the server. The root file system mounted by the thin client is not the same root file system the server itself uses, but is specially prepared for thin clients, and is shared by all thin clients connected to the server (located in /opt/ltsp/<arch> on the server) . The initramfs calls the init program, the Xserver settings are autodetected and the ubuntu breezy ltsp login manager, called ldm is started.
Line 28: Line 28:
Confusion warning: The X windows which runs on the client machine is called the X server. The programs which run on the server (Such as Gnome, Mozilla, KDE) are called X clients... Just to get that out of the way! I will try to avoid using this confusing terminology and just refer to the X running on the client machine, or X programs running on the server.

For X-windows to connect to the server, the server must be running a service called XDMCP (X Display Management Control Protocol). When a client connects to the server, the XDMCP service will launch a program such as GDM (Gnome Display Manager), which makes a connection to the client machine. GDM provides a log-in window. When a user logs in, GDM in turn launches a program such as gnome-session or kdesktop, which in turn, launch all the programs you expect on a modern GNU/Linux desktop.

When GDM launches, it is actually making a connection from the server machine to port 6000 on the client machine. XDMCP communicates the ip address of the client machine through the $DISPLAY environment variable. In fact, all programs which the user launches through the client machine are making a connection to port 6000 on the client machine. All X-windows programs the user launches know where to connect to as they check the DISPLAY environment variable.
After logging in, ldm starts a ssh tunnel and executes a X session on the server which is displayed through the tunnel on the thin clients X server. Using ssh here has the big advantage that you dont need to have a Xserver configured on the client and no unsafe tcp X transport is initialized like it was done in older days of ltsp.
Line 90: Line 86:
=== Tips ===
If you have a separte DHCP that you do '''not''' want to install LTSP on you can just redirect the thin-client to boot off a different server.

In your DHCP server's dhcpd.conf:
{{{next-server 192.168.0.3;
}}} where 192.168.0.3 is the address of your LTSP server

Thin Client How-To

What is a Thin Client?

To the user, a thin client behaves like a regular desktop computer. To the administrator, a thin client has no storage of its own, is easy to maintain, and can give the user a modern computing experience even with ancient hardware.

How do thin clients work?

-- Basic answer --

Thin clients load a small operating system into memory then connect to the server. The programs run on the server but are displayed on a thin client's screen.

-- Advanced answer --

Boot phase (described from the point of view of the thin client machine): A thin client may either obtain a kernel from local storage, or load the kernel across the network. (Using these instructions, you will collect the linux kernel from the server using a bootable network card. This way, the thin client needs no more storage than the boot rom built into a bootable network card.)

- Boot sequence -

The PXE network card makes a DHCP request on the local network. The DHCP reply gives information to the card where to collect the linux kernel from. The kernel is collected over the network through the TFTP protocol.

Once the kernel has been collected via TFTP, the kernel is executed; the machine boots linux. A initramfs collected with the linux kernel is mounted as a root file system. This carries and autodetect the necessary drivers for the network card, mouse, keyboard sound etc. Once the network card driver is loaded, a second DHCP request tells the client it's ip address, netmask, gateway, DNS server, and root NFS (Network File System) mount point.

The linux kernel runs the ubuntu initramfs, which mounts the root NFS share from the server onto the thin client read-only. The thin client now has a booted linux kernel, and a root file system, much like any Linux system. From now on, when we talk of the root file system on the client, we are actually talking about a root file system mounted read-only from the server. The root file system mounted by the thin client is not the same root file system the server itself uses, but is specially prepared for thin clients, and is shared by all thin clients connected to the server (located in /opt/ltsp/<arch> on the server) . The initramfs calls the init program, the Xserver settings are autodetected and the ubuntu breezy ltsp login manager, called ldm is started.

- X nuts and bolts -

After logging in, ldm starts a ssh tunnel and executes a X session on the server which is displayed through the tunnel on the thin clients X server. Using ssh here has the big advantage that you dont need to have a Xserver configured on the client and no unsafe tcp X transport is initialized like it was done in older days of ltsp.

Requirements

You will need:

  • An Ubuntu 5.10 system to be the server
  • At least one PXE-bootable system to be a client
  • A bunch of disk space
  • A fast network connection, or a local Breezy mirror, or some patience
  • A DHCP server which is capable of supporting PXE clients, or a separate network segment where you can run a dedicated DHCP server
  • Command-line familiarity
  • A sense of adventure
  • A burning desire to send feedback to [mailto:ubuntu-devel@lists.ubuntu.com ubuntu-devel]

Getting Started

NOTE: If you plan to use the server as gateway/nat/firewall machine, it is strongly suggested to configure all the network interfaces before proceeding with the following steps.

  1. Set up the DHCP server
    • If you have an existing DHCP server which can support PXE clients:
      • Configure it to pass a boot filename of /ltsp/pxelinux.0 and a root path of /opt/ltsp/i386

      • For ISC DHCPD, use the following options:

        filename "/ltsp/pxelinux.0";
        option root-path "/opt/ltsp/i386";
      • Install ltsp-server on the server: {{{sudo apt-get install ltsp-server

}}}

  • If you want to run a dedicated DHCP server on the thin client server:
    1. Install ltsp-server-standalone on the server: {{{sudo apt-get install ltsp-server-standalone

}}}

  1. If necessary, customize /etc/ltsp/dhcpd.conf (by default it's configured for a server at 192.168.0.1 serving PXE clients)

  2. If you are running a firewall on the server, you'll need to open TFTP and NFS (and DHCP if you're running the standalone server). Also, make sure portmap isn't limited to the loopback interface in /etc/default/portmap (comment out the line with "-i 127.0.0.1") if it exists, could be a leftover from Hoary. You also may want to edit `/etc/hosts.allow' and limit access for portmap, rpc.mountd, rpc.statd, and in.tftpd to the local network: {{{portmap: 192.168.0.0/24

rpc.mountd: 192.168.0.0/24 rpc.statd: 192.168.0.0/24 in.tftpd: 192.168.0.0/24}}}

  1. Restart the nfs subsystem: {{{sudo invoke-rc.d nfs-kernel-server restart

sudo invoke-rc.d nfs-common restart sudo invoke-rc.d portmap restart}}}

  1. Build the thin client runtime environment: {{{sudo ltsp-build-client

}}}

  • This script is hardcoded to use a particular Ubuntu mirror, so you may wish to edit it if you have a nearby mirror or CD (sudo ltsp-build-client --mirror file:///cdrom), remember to copy sources.list from the server into the chroot)

  • If you changed your aptitude dependency-settings not to select recommended packages automatically, not all required packages will be downloaded and installed by this script. Then no login with sdm is possible for example because some parts of the x-server are missing
  1. {{{apt-get install openssh-server

sudo ltsp-update-sshkeys}}} Check /opt/ltsp/i386/etc/ssh/ssh_known_hosts and ensure that your host key is associated with your host's IP address. Depending on your /etc/hosts configuration, this may not always be correct automatically (yet). If it looks like this:

servername ssh-rsa AAAAB3NzaC1yc2EAAAABI...

then add the IP address like this:

servername,192.168.0.1 ssh-rsa AAAAB3NzaC1yc2EAAAABI...

AND file a bug in [http://bugzilla.ubuntu.com/ Bugzilla]. THIS SHOULD NOT HAPPEN.

  1. {{{sudo invoke-rc.d dhcp3-server start

}}}

  1. Optionally, create /opt/ltsp/i386/etc/lts.conf. If you don't create one, reasonable defaults and auto-detected values will be used.

  2. PXE boot the client and see what happens. If all goes well, you should see a graphical login dialog.
  3. If your client doesn't have PXE on the network card, you can generate a custom boot CD or floppy at [http://www.rom-o-matic.net/ ROM-o-matic.net]. Burn the iso or floppy image and boot from that.

  4. Log in, with any user authorized to login remotely via ssh, and see what happens. If all goes well, you should get a working desktop session on the server.
  5. Send mail to [mailto:ubuntu-devel@lists.ubuntu.com ubuntu-devel] with your findings

Tips

If you have a separte DHCP that you do not want to install LTSP on you can just redirect the thin-client to boot off a different server.

In your DHCP server's dhcpd.conf: {{{next-server 192.168.0.3; }}} where 192.168.0.3 is the address of your LTSP server

Extras

  1. ["ThinClientHowtoNAT"]

ThinClientHowto (last edited 2008-08-06 16:14:39 by localhost)