Thin Client Roadmap

Status

• Created: 2005-04-23 by MattZimmerman
  

• Priority: LowPriority
  

• People: JimMcQuillanLead, ScottBalneavesSecond
  

• Contributors: MattZimmerman, FabioDiNitto, ChristianReis
  

• Interested: LamontJones
  

• Status: EditedSpecification, MattZimmermanQueue, DistroSpecification
  

• Branch:
  

• Malone Bug:
  

• Packages:
  

• Depends:
  

  • ThinClientSecurity

• UduSessions: 1, 4, 8, etc
  

Introduction

This topic maps out a roadmap for Thin Client support, and is applicable to many distros, but especially reflects the goals of providing a rich thin client experience under Ubuntu.

Rationale

The initial thin client support in Breezy will provide "basic" thin client functionality. Post Breezy we would aim for a richer environment for both thin and fat diskless clients.

Scope and Use Cases

• Provide a richer thin client experience for end users: extensive local device access, such as local storage devices, USB headphones for VOIP; seamless network audio; enhanced security, etc.
• Provide a full "diskless workstation", in which an almost full version of Ubuntu executes on the local diskless client.
• In essence, the ultimate goal is to provide the thin client user with the exact same capabilities that are available to a thick client.

• SUN said it best with their slogan: The Network IS the Computer

Implementation Plan

Not applicable, as this is just a Roadmap.

Data Preservation and Migration

For workstations or networks "upgrading" from an Ubuntu (or Debian)-based system to a thin client setup, it would be nice to offer a way to ensure that the new setup includes the packages that existed on the former system.

Packages Affected

User Interface Requirements

Outstanding Issues

Thin Client

• Secure booting and security issues: see ThinClientSecurity

• Networked resources:
  • Everything on the network should be considered a "NODE".
  • Thin clients, in their simplest form are a "Display Node".
  • Servers are 'Execution Nodes'.
  • Multiple nodes should be allowed, no matter what kind they are.
  • Some thin clients could also be execution nodes. At least for the user that is logged in on it.
  • If the client is capable of running an application, such as Firefox, the desktop environment needs to know that, so that when the user clicks on the Firefox menu entry, it gets launched in the right place.
  • If, when running Firefox, the user clicks on a PDF document, the PDF reader needs to run in the right place. That might be locally, on the client, or it might be on an execution server. It depends on whether the client is capable of running the PDF viewer. If it runs on an execution server, what if there are multiple servers?
  • What is needed is some kind of secure network transparent broker, that allows thin clients, diskless workstations, execution servers, print servers, etc, to register their capabilities, and allow programs to be executed anywhere necessary, based on server load, network link speed, and other factors. Perhaps a dbus based service with a network transparent HAL or something similar.
  • The goal is to allow a network administrator to easily expand the network as needs dictate, without having to do a lot of reconfiguration. If 15 new employees show up, one should simply be able to drop in 15 diskless workstations and another execution server, and they should automatically integrate themselves into the network environment, with minimal setup required.
• We need to continue to provide local apps support.
  • It's a shame to waste a 1Ghz cpu and 256mb of ram, just to run an Xserver. We need to navigate that issue, without losing sight of the fact that many users are still using a 486 with 32mb of ram as their client.
• ICA client for access to Citrix servers.
  • Available but not widely used on Linux, as it is non-free.
• Integration of LDAP into LTSP
  • Needed for local applications support, as the thin client needs to have some kind of concept of who the user is that's sitting at the client. Work is progressing on integrating LDAP into LTSP.
• Local devices for thin clients.
  • Use pmount for mounting and unmounting of local media devices.
  • Use hotplug for handling USB device hotplugging.
  • Network transparent HAL -- talk to Martin Pitt.
• Network audio

  • See AudioInfrastructure

• Clustering:
  • The network transparent services model described above provides a coarse-grained "cluster" that is sufficient for school and office based environments.
• Graphical tool to create/edit/delete entries in lts.conf file.

Fat Diskless Client

• A fat client is defined as a powerful computer with no disk that gets its filesystems from a network fileserver.
• Issues needing to be resolved:
  • Create a shared root filesystem amongst all clients. This filesystem, as above, should be mounted read-only. The shared root filesystem presents some challenges as when installed completely it is quite large; a potential solution would be to use the thin client filesystem as a initial step, and from there install a complete distribution. Deployment using a DVD as the installation media would be convenient, as all the packages required could be obtained directly from it. The thin client "remote X" part of the initscripts would need to be replaced by GDM.
  • Need to deal with things that can't be easily shared such as /var, config files and /home. Perhaps this could be handled with unionfs or bindmount.
  • Persist /var/lib/nfs - for correct lockd and statd operation, it needs to be persistent. XXX: Async works around this by providing a server-stored directory per-client that is overmounted on the client upon bootup, just before mounting a shared /home and /var/spool/mail.

  • We need a way to do "local" delivery of mail; this conflicts with the current MailRoadmap in that we seem to require a local MTA to handle delivery from apps that don't support remote delivery (anything that relies on /usr/lib/sendmail to send, for instance).

  • Possibly offer an out-of-the-box solution for SSHing into a chroot of the client image on the server; this allows a single point for read-write access to the image. Note that this requires overmounting /dev/pts inside the chroot, and possibly /home for extra convenience.

  • For network authentication, LDAP seems like the obvious choice. Should Active directory be supported? (Comment:Async uses NIS; it's not secure, but it does the job)

  • Swap could be implemented as described in the ThinClientIntegration specification.

  • For printing, configure the printing subsystem on the client to feed the print jobs to a full fledged print server.
  • Managing client-local devices presents some challenge: while it is not necessary to forward resources to the server, it is still necessary to offer /some/ client-specific configuration: potentially mount-points for local devices, printers, potentially other devices.

UDU BOF Agenda

UDU Pre-Work