Ubuntu Wiki

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/thinclient-local-devices

• Created: Date(2005-10-07T12:40:00Z) by JaneWeideman

• Contributors: OliverGrawert, VáclavŠmilauer, ScottBalneaves

• Packages affected:

  • ltspfs/ltspfsd
  • ltsp-server
  • ltsp-client

Summary

Thin Client Local Devices how to provide userfriendly access to local devices on the thin clients.

Rationale

Ubuntu's LTSP currently doesnt support local block devices on the Thin Clients. If you plug in a usb stick, usb storage capable camera, CD rom or floppy on the Thin Client, you dont have access to the device at all. A implementation to handle this was developed in LTSP-4.2, this spec is about including that functionality into Ubuntu LTSP.

Use cases

Scott uses a LTSP Thin Client and wants to copy files from a CD rom he burned at home, he puts in the CD into the drive of his Thin Client and it shows up on his desktop as it uses to do at home on his ubuntu desktop install.

Jane has taken a bunch of photos with her usb storage capable digital camera for usage in the art class she has. Janes school runs a edubuntu LTSP server in the classroom. She plugs in her camera and gets a popup that offers her to import the pictures into her photo album.

Willy brought his documents he wrote at home on a floppy to his office where ubuntu LTSP runs and where he works on a Thin Client. Willy wants to insert the floppy into the local floppy drive, mount it and copy the files on his desktop to edit them in openoffice.

Scope

• Block devices that interact in the normal manner with dbus, udev, etc.
• We won't handle special-function or character devices for Dapper.

Design

The currently existing udev/kernel structure already solves the raw automounting of the device on the thin client, ltsp.org designed a program called lbus that forwards a notification about new appearing devices on the client to the users session on the server.

The actual datatransfer is done by a fuse based implementation, a daemon called ltspfsd runs on the client, a client program called ltspfs executed in the session of the user on the server does the mounting over the network.

In case a notification from lbus running on the client is recieved by the lbus process listening in the users session on the server, ltspfs mounts the device into a subdir of /media/$USER which is owned by the user in 0700 mode.

Implementation

• hal and udev will run on the client to fulfill the architectural requirements.
• dbus will be enhanced to support X transport over the ssh tunnel, it will hook into the already running channel.
  • a system bus on the client connects to the session bus on the server, notifications will be sent through this connection to trigger gnome-volume-manager to mount via ltspfs.
• gnome-volume-manager will be enhanced to respect the LTSP_CLIENT variable; if set it will not run pmount but arrange (either itself or via a script) to send a dbus message to the system dbus on the client asking the client to make the filesystem mounted on the server. The client then does ssh server [a bit like under Implementation / Code in wiki page]
• Each user will have their own 0750 root.usergrp subdirectory of /media on the server to get a private namespace and to make device labels work properly.

  • LTSP currently mount's into the users home Directory, under a Drives folder. Might this be better on a multi-user system? It would hide the fact that someone HAS a USB device mounted on the machine. -- ScottBalneaves

  • This requires modifying gnome-vfs to respect this user directory (it must check the LTSP_CLIENT variable for that)
  • A ltsp-user option is to be added to the users and groups manager in gnome, so you can easily check a checkbox to have the required dir created.

Code

The gnome-volume-manager triggered script of point 5 in the schema will be a simple python based dbus script running the commands dbus-connect and dbus-send to emit the message to the clients dbus.

Command executed by mount initiation script on the client (point 7 in the schema):

• ssh ${user}@${server} "ltspfs ${LTSP_CLIENT}:/media/${devicelabel} /media/${user}/${devicelabel}"

Outstanding issues

We cannot use the ltspfs builtin TCP transport because it has no encryption. (FUSE encryption is for encrypted filesystems, not encrypted ltspfs traffic.), ScottBalneaves will implement handling of stdin/out in ltspfs/ltspfsd to being able to tunnel through ssh connections.

Currenly, we've had a comment or two on the LTSP mailing list that codepages aren't supported under LTSPFS. We'll need to implement that in keeping with Ubuntu's i18n nature. -- ScottBalneaves

How would the X11 dbus transport work? Sending info via atoms? -- ScottBalneaves

Inspecting the required changes to gnome-vfs.

Inspecting the changes to the user and group manager.

BoF agenda and discussion

There were two approaches during the BoF discussions we discussed, they split up in two parts:

• 1 How to notify insertion, transfer metadata, eject instructions, etc. 2 How to transfer/mount actual filesystem data

For metadata, two solutions:

• 1 Simple scheme involving ssh on insertion, using ssh-agent to permit reverse connections if applicable
  • Pro: not much code: new udev script and glue, new script on server to run mount command, new arrangements to make new device appear in right nautilus session or right user's desktop view.
  • Con: metadata on server is not correct; error handling may be suboptimal; not clear yet how to make nautilus right.
    • (since ssh transports environment variables through its connection this data could either made available through variables or directly to ltspfs-mount as options this program would need to respect)
  2 Dbus
  • Con: needs more code: dbus X transport (should be easy); gvm to run ltspfs-mount on system device events instead of normal pmount etc.
  • Pro: completely correct and `normal' visibility of client's devices just as if it would be if the user were running a session on the local workstation

Both schemes need ldm changed to store username and password on client (in tmpfs mounted /tmp) for future ssh connections

For filesystem data, Three solutions:

• 1 sftp/sshfs
  • Requires reverse-connection from server back to client (and ssh-agent)
  • Simple
  • sftp is not ideal as remote filesystem protocol
  2 ltspfs
  • Some modifications to ltspfs required to make it talk over stdin/stdout rather than wanting to do its own network and own authentication (straightforward we are told)

  • Stability status of ltspfs not currently known. Update 06/17/2006: ltspfs is in current version of LTSP (4.2), and deployed. Reports coming back are positive, and the code's proven quite stable. Apart from i18n, things are looking good. -- ScottBalneaves

  • ltspfs designed for this scenario: copes better with unexpected media removal, etc.
  3 Avahi

  • Not sure where this is at the moment, but we should investigate and see if it's a possible fit. -- ScottBalneaves

CategorySpec