Revision 1 as of 2007-10-29 15:35:09

Clear message

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.


Local applications has been a long standing feature that's been desired by both users and LTSP developers alike. We need a simple method to allow end users to run applications locally on the thin client, regardless of authentication mechanism on the server.

Release Note

A simple method of allowing administrators to specify applications that can be installed into the chroot, and executed using the computing resources of the local thin client workstation.


Many times, sites will have powerful thin clients, and will be wanting to take advantage of the computing resources available on the thin client. Or, alternatively, run programs in a thin client environment that don't work well having their resources forwarded over the network.

Use Cases

  • Tom wants to set up a call centre, and wants to run Skype on his thin clients, so that they can act as both a computer and a phone. He installs skype in the chroot, and enables localapps, and things work as expected.
  • Mary is an educator, who wants to make heavy use of multimedia in her classroom. She has powerful workstations, but not enough money to put in Gigabit networking. So, she installs Firefox, gnash, and totem in the chroot, and runs firefox as a localapp. Everything works speedily.
  • Jordan is a researcher who has a program that allows him to do parallel protein folding on multiple machines. He installs the application in the LTSP chroot, and sets it up to run as a localapp. His proteins are folded into origami.


  • We want to be independent of whatever the authentication method is on the server.


  • We need to mount the logged in users home directory safely.
  • We need a method to inform the local user of the Name Switch Services (/etc/passwd and /etc/group) up on the server for the logged in user.
  • We need some method of actually launching the application on the thin client.


  • Home directory:
    • We'll use sshfs. We already have a control socket available for the logged in user, so mounting the users home directory via this socket is easy.
    • sshfs doesn't implement the statfs call. Create a simple fuse filesystem based on fusexmp.c, which is mainly passthrough, but uses the ssh socket to execute the command stat -f $HOME --printf="%f %a %b %c %d\n" to obtain the information to plug into the statvfs call.
  • NSS:
    • Using the rc.d abilities of ldm, execute a "getent passwd $USER" and "getent group $USER"
    • Take the output and put in /var/run/misc, where nss-extrafiles expects it to be.
    • configure nss-exrafiles within the chroot to read these files.
    • On user logout, delete the files.
  • Launcher:
    • Write an application that listens on an X property.
    • When the X prop changes, read it. It should be a command line of a program.
    • Execute the command line as the user.
    • Already proof-of-concepted. Works.
    • Need a simple shell script called "localapp" or some such, which sets the xprop based on shift ; $*

UI Changes

Might want to ship some extra .desktop files with common applications localapped: firefox, etc.

Code Changes

Only additions, no modifications to existing code.


  • promote nss-extrafiles to main

Test/Demo Plan

Use case will be launching Firefox, which is the most requested local app.

BoF agenda and discussion

  • Get the LTSP drivers to approve this method, or suggest alternatives.