ThinClientIntegration

Status

Introduction

Provide rich thin client functionality out of the box in Ubuntu

Rationale

Thin client is in demand from educational and many other classes of user. If we have rich thin client functionality out of the box in Ubuntu, we can expand the user base.

Scope and Use Cases

Our goal is to provide a reasonable "greatest common factor" approximation of functionality from LTSP. We are deliberately keeping the scope small in order to meet the BreezyBadger release schedule. Future improvements are covered in ThinClientRoadmap.

The initial implementation will incorporate the following use cases:

  • An educator wishes to set up a computer lab using 2-100 donated, low-end PCs and a single, high-end server. They install Ubuntu on the server, requesting a thin client configuration. All necessary software is installed and configured such that clients can be immediately netbooted on the attached LAN. Effort specifically to address this issue is on another wiki at http://www.slug.org.za/wiki/UbuntuDesktop

  • Public library kiosks for patrons to have access to the internet and email. Also they should have access to office applications such as OpenOffice.org.

  • Businesses that want to provide Linux desktops to their users on a low-cost reliable platform.
  • Multiple architectures are needed. For clients, x86 and PPC should be supported. Both client architectures should be supported on all Ubuntu servers. That is, x86, x86_64 and PPC servers should support both x86 and PPC clients.

The standard kernel, applications and hardware support infrastructure from Ubuntu will be used on both the clients and the server.

Implementation Plan

  1. Kernel and initrd

    • We will use stock Ubuntu kernels. The base initial ram disk can be provided by EarlyUserspace (initramfs), with extensions to provide for the read-only root filesystem environment. The initial design will use unionfs, though if this proves to be problematic, the existing LTSP technique of mounting tmpfs filesystems can be substituted. If the EarlyUserspace extensions are not ready in time for testing LTSP functionality, we can fall back to a traditional initrd based on the existing LTSP initrd build process.

  2. Services Configuration Tool. See also NFSRoot.

    • A single configuration tool should be created to provide a single place to configure all of the services needed on an LTSP server. It will be capable of non-interactively deploying the most common configurations: a dedicated server, either with one shared network interface (used for both serving clients and passing traffic upstream), or two network interfaces (one for serving clients, and a second for communicating with the existing network). It will interact with the following components:
    • DHCP - dhcp3-server is a dependency. The server package will contain a tool to create a configuration file appropriate for thin clients.
    • TFTP - tftpd-hpa is a dependency. The server package will contain a tool to allow kernels installed in the LTSP client root to be served by the host's tftp server. This tool will also handle pxelinux setup, and allow for etherboot images available in the LTSP client root.
    • NFS - nfs-kernel-server is a dependency. The server package will contain a tool to perform the necessary modifications to /etc/exports to serve the LTSP client root(s) from /opt/ltsp.
    • XDMCP - A display manger is a dependency (gdm for Ubuntu, kdm for Kubuntu). The server package will contain a configuration tool to enable XDMCP in the appropriate config file.
    • syslogd is already installed as part of the sysklogd package, in the base system. The server package will contain a tool to enable remote logging via the '-r' flag. This setting is currently part of the sysklogd init script, but should be moved to an /etc/default file.

    • According to the AudioInfrastructure BOF, Network sound isn't a priority, but based on their decision to go with polypaudio, we should get network transparent sound almost for free.

    • NBD (Network Block Device) - nbd-server is a dependency. The server package will contain a tool to create swapfiles for LTSP clients.

    • lts.conf file. A default one should be provided. It would be nice if a tool were provided to modify the lts.conf file, but this isn't a Breezy goal. See ThinClientRoadmap.

  3. Building and shipping the client root filesystem
    • The simplest option is to generate the filesystem once, as part of Ubuntu release process. This has the advantage as it is fast and simple to deploy, and will provide cross-architecture support. The downside is that either a large binary package will be required to contain the tree, or an alternative place to stash this in the Ubuntu archive will be required. Either option has negative consequences for mirrors. The filesystem could also be built on demand from packages already in the archive, using debootstrap and apt. This option is less resource-intensive, but is more complex, slower to execute and cannot support cross-architecture environments. In either case, we will need to create a tool to generate the filesystem, and will include it in the server package.
  4. We need to package various tools from the LTSP build environment (LBE) which are used in the client root:

    • getltscfg

      • Reads conf file
    • startsess
      • Starts the LTSP session scripts in the LTSP screen.d directory (/opt/ltsp/i386/etc/screen.d/)
    • ./screen.d/*
      • Session scripts. The current options are startx, shell, redesktop, and telnet

    • lp_server

      • Listens on port 910x for print streams and redirects them out to attached parallel,serial or USB printers.

    • ltspinfod

      • Daemon running on client that can be queried by the server. This is how the server can find out which sound daemon the client is using. Can also be used to shutdown or reboot the client.

    • pci_scan

      • This is how LTSP autodetects the nic, video chipset and audio chipset. Should this be replaced by HAL?

    • vidlist

      • Table of PCI Vendor/Device IDs that is used by pci_scan to determine which Xserver to use

    • niclist

      • Table of PCI Vendor/Device IDs used by pci_scan to determine which NIC kernel module to load
  5. Client swapping for low memory clients.
    • Set up necessary tools on the client for doing NBD swapping for low memory clients.
  6. Automated Xorg setup.
    • Combination of both "Classic" LTSP configuration and Ubuntu automagic configuration.

    • Documented in LTSPXorgConfiguration.

Data Preservation and Migration

N/A

Packages Affected

  • kernel
  • sysklogd
  • gdm
  • kdm
  • dhcp3-server
  • nfs-kernel-server
  • tftpd-hpa
  • nbd-server
  • ltsp-server (new package containing server-side infrastructure)
  • ltsp-client (new package containing client-side infrastructure, to be installed in the client root)

User Interface Requirements

Initial configuration will be non-interactive.

Outstanding Issues

  • We have a need to modify various configuration files belonging to other packages, and must decide on a method to deploy these changes without creating a fragile (and policy non-compliant) system.

  • We would also like to support "fat clients" (diskless workstations), but this requires additional design work and does not seem feasible for the BreezyBadger timeframe.

Design notes

These notes are points that were discussed, and provide documentation of the implementation plan, and a history of the several BOFs that were held to discuss the task of integrating LTSP into Breezy.

Bootstrapping the Client

  • Initrd design

    • Squeezing X into RAM isn't feasible at this point: we need to account for low-memory clients, so use NFS root. See NFSRoot and EarlyUserspace. Goal is to use the stock initramfs from Breezy.

      • The required pieces needed to diskless booting are:
        • Network interface detection using hotplug.
        • DHCP using dhclient3.
        • NFS read only root support.

    • If initramfs (EarlyUserspace) will not be ready in time, we can use custom mkinitrd scripts to add:

      • Network interface detection using LTSP's method
      • DHCP using dhclient3.
      • NFS root support.
      • Read-only root handling.
  • Boot process
    • Use existing LTSP scripts for:
      • X configuration (alternative or "Classic")
      • Creating syslog.conf based on lts.conf.
        • Need to make sure '-r' flag added in /etc/init.d/sysklogd. Should this be an option in /etc/default?
      • Sound server config from lts.conf
      • dump configuration info for ltspinfod
    • Use existing Ubuntu init scripts for:
      • Starting syslogd.
      • Configuring the network.
      • Hardware detection.
    • Create new Ubuntu init scripts for:
      • Enabling swap.
      • start_printer.
      • ltspinfod.
      • X configuration (standard Ubuntu autodetection method).
      • Configuring hostname.
      • Add startsess to inittab.
    • Don't worry about shutdown (most clients just power off anyway).

Running the Client

  • Client root design
    • Need a mechanism to make the filesystem read/write, shared between clients.
      • We'll try tmpfs + unionfs (we will experiment with this for the Breezy live CD anyway).
      • Can always use existing LTSP mechanism using ramdisk mounts.
      • Other crazy ideas: nbd + device-mapper.
    • Create a thinclient seed including:
      • Base.
      • Package of LTSP scripts (above).
      • x-window-system-core.
      • rdesktop.
      • openssh-client.
      • esound.
    • Include generic kernel in root filesystem:
      • Decouple from server kernel:
      • Can generate custom initrd if necessary:
      • Use kernel-package hook to generate etherboot image (mknbi-linux).
  • X configuration
    • We should add a setting to lts.conf to indicate that the Ubuntu X configuration infrastructure should be used
    • This setting can be disabled in order to use the standard LTSP configuration (build_x4_cfg)
    • Need to seed keymap settings from lts.conf into debconf
    • See LTSPXorgConfiguration for more details.

Setting up New Clients

  • Two methods discussed included dynamically creating the Client's root filesystem via a debootstrap process or packaging a pre-generated root filesystem as a (huge) .deb file.
  • For Breezy, it was decided that supplying a large .deb file was the simplest thing to do at this point, but the consequences for archive mirrors need to be considered
  • Allowing the LTSP admin to generate the root filesystem on-the-fly has the following issues:
    • Minus: Slow and complex to deploy.
    • Minus: Cross-architecture support is more problematic (e.g., need to cross-debootstrap).
    • Plus: No need for a binary blob (can just use existing packages, even ones on CD).
    • Plus: No need to stash it in the archive (packages are already there).
    • Plus: Able to update as security and bug-fix packages are released.

Server Infrastructure

  • Server configuration

    • Setup tools in ltspcfg (part of ltsp-utils pkg).

    • Would be nice to have an installation mode to set everything up (probably
      • post-Breezy)
      • Local apps - we will defer to post-Breezy.
  • What to do about swap?
    • Swap to NFS does not work, patch exists for 2.4, not going upstream.
    • enbd is interesting, supports remote access to devices, but activity upstream is minimal.
    • Consider GFS for root filesystem
    • Consider GNBD for swap? Not sure at this point.
    • nbd is our best bet for Breezy. It's already in the server's kernel, and has been around for a while.
    • Local swap would be useful, could use getltscfg to determine whether we are allowed to scribble on a disk if it's installed in the client.

Comments/Notes

Warning /!\ Edit conflict - other version:

Warning /!\ Edit conflict - your version:

Warning /!\ End of edit conflict

UbuntuDownUnder/BOFs/ThinClientIntegration (last edited 2008-08-06 16:15:33 by localhost)