LtspSshXdmcpLocaldev

Differences between revisions 9 and 10
Revision 9 as of 2007-05-11 07:29:53
Size: 3524
Editor: 195
Comment:
Revision 10 as of 2008-08-06 16:41:17
Size: 3524
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

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.

Summary

Currently, Local device connections are plumbed via an ssh command channel. This works fine, until we switch to using XDMCP, when it breaks. We need to come up with a common command channel that will work in both instances.

Rationale

XDMCP, while insecure, is much faster than tunelling X over SSH. For low powered thin clients, it may be desirable to switch to XDMCP as a communications method.

Use Cases

  • Ollie has just been asked to set up an Edubuntu lab in a developing nation by his boss. On arriving, he finds that all the machines are Pentium 90's with 64 megs of RAM. Running the standard LTSP encrypted setup isn't an option, as the clients just don't have enough power. They work fine as XDMCP, though.
  • Scott wants to do video on his thin client. He's got a gigabit network, but tunelling over SSH introduces too much latency. He's not worried about security on his local network.

Scope

  • ltsp-server

  • ltspfs

Design

  • Use an X property on the root window as the communications mechanism, as this will be available to either SSH or XDMCP communications methods.

Implementation

Thin Client

  • Well defined place for Xorg's .Xauthority file to be written (in /tmp, but not named /tmp/fileKJHDJ)

    • Bind mount /root/.Xauthority

  • Logging in, and staticdev detection handled with:

while /bin/true; do
     FSTAB=$(cat /etc/fstab)
     while [ ! $(xprop -root -f LTSP_FSTAB 8s -set LTSP_FSTAB "${FSTAB}" > /dev/null) ]; do
        sleep 2
     done
     xblock  # discussed later
done
  • This will wait until the X server is up, then set the X property LTSP_FSTAB on the root window.
  • This property will survive past an LDM or XDMCP login, but after a logout, an xreset is done. All clients are disconnected, and all properties are cleared.
  • We'll need a small program, called xblock.
    • Does a connect to the X server, sits in empty event loop.
    • Simply exits quietly on X disconnect.
  • add-fstab-entry now simply:

    • updates the /etc/fstab file
    • updates the LTSP_FSTAB xprop (if X isn't up yet, not a problem, fail quietly, and the above bit of code will handle this automatically).
  • eliminate the static-mounter daemon.

  • fix cdpinger to set the xprop.

Host Server

  • Need to create a daemon that is started from /etc/X11/Xsession.d

  • Looks at initial LTSP_FSTAB xprop, mounts anything not already there.
  • Listens for changes in the xproperty during the session.
  • Upon seeing a change, grabs the information needed, and calls an external program to handle the mount or unmount, as necessary.
  • on session exit, cleans up all mounts before exiting.

External mounter

  • References ltspfs-virtual-hal-devices

  • External program will iterate over hal set options, and insert a virtual HAL device.
  • HAL will then handle the plumbing.

Implementation Notes

  • With the exception of the tiny xblock, everything should be able to be handled by shell and python scripting.


CategorySpec

LtspSshXdmcpLocaldev (last edited 2008-08-06 16:41:17 by localhost)