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: https://features.launchpad.net/distros/ubuntu/+spec/ltsp-local-apps
Packages affected: ltsp-client, ltsp-server, ltsp-localapps
This spec is obsolete, see the new version at https://wiki.ubuntu.com/ltsp-localapps
Local applications allow applications chosen by the administrator to be run locally on the thin client, as opposed to running on the server.
With the move to LTSP 5, installing applications to run locally on the client now becomes a much easier task. People with more powerful thin clients may wish to move some cpu intensive tasks off of the server, and on to the workstation. A very common choice is to run Firefox locally, as well as the flash plugin, so that server CPU time isn't used for viewing flash intensive websites.
- Belinda has a grade two class, which uses a flash based education application. The've got a lab of converted Pentium III's with 128 megs of memory, so they'd like to run Firefox locally on the thin clients so that they can have all 40 lab machines using the flash program at the same time.
- Roger's really big into protein folding. His masters thesis is coming up, and he's received permission to use the university's open lab for folding@home use over the Christmas holidays. He chroot's into /opt/ltsp/i386, and installs the folding client. He's now got himself a low-rent supercomputer, with 80 lab machines folding his protiens int various oragami-like shapes.
Launching applications locally on the thin client, as opposed to the server.
Design and Implementation
- Must have LDAP authentication/libnss support. (edubuntu-auth-client spec).
- Export the /home directory on the server R/W (with root_squash)
- Configure pam_mount to handle usermount of home on thin client on login.
- Need some way of triggering an app from the server to the client.
- ssh connection. (We have to run sshd on the client)
- Need to set the display variable back to :0, and DON'T start ssh to client with -X
- Need some way of differentiating between running the app on the server, versus running it on the client.
- Separate .desktop files placed in /usr/share/ltsp/localapps.
set XDG_CONFIG_DIRS appropriately. (See LaserJock & sbalneav)
- Create a lower-level system that checks a lookup table in /etc for how/where to run an executable when it is called (ala sudoers-style)
- We need a file that maps workstation name/ip/mac to which localapps it supports. (or graceful failing?)
- We need something in the login that then sets the XDG_CONFIG_DIRS appropriately, depending on the workstation id.
- Make sure the sound works locally.
- a package called ltsp-localapps will be created, containing a script called ltsp-local-app-installer that chroots into the thin client environment, mounts proc,installs the app there, unmounts proc and exits te chroot and afterwards copies the .desktop file for the app from /usr/share/applications to /usr/share/ltsp/localapps and changes the Exec= line there.
- Gconfd remains an obstacle if applications are compiled with Gnome support. Gnome desktop preferences are referenced by a local domain socket.
- We need to investigate the TCP sockets option for gconf.
- Sebastian Bacher will investigate this for us.
- XDG_CONFIG_DIRS: should be a merge variable, not simple replacement.
- The rw export of /home is questionably secure (even with no_root_squash, which is essential) and we will investigate kerberos for feisty+1.
- Upstream will provide a solution to decide whether or not a localapp will run on a workstation based upon workstation performance.
- Add a section to thin-client-configurator to allow administrators the ability to easily and graphically add applications to the chroot environment.