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.

• Launchpad Entry: ltsp-localapps

• Packages affected: ltsp-client

Summary

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.

Rationale

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.

Assumptions

• We want to be independent of whatever the authentication method is on the server. Setting up LDAP on thin clients is not something we want to do.
• We want to avoid using NFS to export home directories, due to security concerns.
• We want a simple method of calling remote applications on the client, with the ability to easily provide .desktop files for remote apps.

Design

• 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.

Implementation

• 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.

    • why not just fix sshfs to do this?
      • sshfs is built on openssh, and the OpenBSD people are staunchly opposed to modifying sftp to return any kind of information regarding how much space there is on the server filesystem

  • Is it possible to use another fuse file system? Research to do... http://fuse.sourceforge.net/wiki/index.php/FileSystems It may not have another fs for that, let's try to make sshfs work.

    • NFS is out, we need security, if you know of one, yes. We can use it. Suggestions?
  • Plumb the mount from LDM's rc.d capabilities.
• NSS:
  • Make sure libnss-extrausers is installed in the chroot, and /etc/nsswitch.conf is modified to accomodate it.
    • libnss-extrausers is in universe right now; only dependency is libc6
  • Using the rc.d abilities of ldm, execute a "getent passwd $USER", "getent group $USER", and "id $USER" (to get extra groups)
  • Take the output and put in /var/run/misc, where libnss-extrausers expects it to be.
  • configure libnss-extrausers within the chroot to read these files.
  • On user logout, delete the files.
• Launcher:

  • example available at http://swan.he.net/~sbalneav/bzr/xrexecd (not done yet)

  • Write an application that listens on an X property, LTSP_COMMAND
  • 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 ; $*

• Question : what to do with Cygwin users? It would be possible with a special flag.
  • We have the same problem for chroots that are missing some local apps...this needs to fail gracefully (and preferably run the app on the server instead)
  • We can set another XPROP to give feedback to the server, and a return value of (e.g.) LTSP_LOCALAPP_NOT_FOUND would tell the server to launch the app itself

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.

Migration

• promote libnss-extrausers to main

Test/Demo Plan

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

Issues

• gconf may not support multiple processes accessing it simultaneously.

• ConsoleKit may be used to trac multiple sessions

BoF agenda and discussion

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

---

CategorySpec CategoryEdubuntuSpec