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

• Packages affected:

  • dbus
  • udev
  • gnome-volume-manager
  • ltspfs/ltspfsd

Summary

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

Existing solutions should be taken into account:

• samba. PXES (http://pxes.sf.net) and Thinstation (http://thinstation.sf.net) export local devices with samba and they are mounted on the server. Only does file-level operations. Not optimal security-wise.

• nbd/enbd. Allows raw data access, enbd even implements some ioctls for CD burners etc. Complicated setup, bunch of scripting. Not optimized for thin clients. Enbd has SSL encryption of transferred data and other features. Enbd is not in vanilla kernel and there seem to be no plans to include it in the near future.

• usbip (http://usbip.sf.net). Very low level, only handles USB devices. Probably in beta state. Never tried.

• LTSPFS: (http://wiki.ltsp.org/twiki/bin/view/Ltsp/LtspFS) New method. Small, lightweight, atomic, will include automounter.

Other links:

• LTSP hack: http://wiki.ltsp.org/twiki/bin/view/Ltsp/LocalMedia

• Rich thread on the topic (WRT nx) starter, discussing HAL and d-bus deplyment etc.: http://mail.kde.org/pipermail/freenx-knx/2005-January/000608.html

Rationale

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 deeply integrated with the existing blockdevice handling infrastructure is needed. It should integrate on a level below the desktop and should be exposed to the users desktop session. The device must be accessible from the users desktop.

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

Schema overview

attachment:thin-client-local-dev.png

• udev
  • Handles plug events.
  • makes it possible to use scripts to achieve what we want in udev.d at the lowest device level.
  • Could sends device notifications to the Ubuntu server via dbus + (some network backend for dbus)
• hal
  • Handles polling of drives, and notification of media events (i.e. cdrom media ejected, floppy inserted)
• dbus
  • Should/could be the general message passing system.
  • We'd need to write some kind of network communication plugin for dbus to handle network notifications.
• ltspfs
  • ltspfs would need to listen for dbus messages for listening for media insert and remove messages.
• pmount
  • pmount would need to respect the LTSP_CLIENT environment variable.

Currently we are discussing two different approaches and try to decide which one is feasable to use for dapper. One approach is to use dbus over the network, attach the Thin Clients system dbus to the servers session dbus and do all the messaging through this, the other approach would be to just call ltspfs-mount on the server via ssh to mount the remote device over the network without involving messaging at all:

Two parts of the proposed solution

• 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, two 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
  • ltspfs designed for this scenario: copes better with unexpected media removal, etc.

Implementation

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

Code

possible udev.d mount script example to outline the non-dbus approach:

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

Data preservation and migration

Outstanding issues

• is ltspfs able to handle IOCTLs on the device? AFAIK it is neede in order to make e.g. CD burners work. The ltsp-discuss mailing list does not mention enbd which makes such things, albeit in a rather complex ways, possible. They suggest that IOCTLs have been superseeded by writes to sysfs but do not mention any implementation within ltspfs [VáclavŠmilauer]

  • No, ltspfs is a simple network filesystem, and not a low-level device access method like enbd. The ltspfs filesystem is the same sort of thing as NFS or Samba, neither of which handle IOCTL's either. The LTSP project tried enbd, but it has several difficulties, such as a crashed client can cause problems for the server, and the simple fact that it's not included by default on any of the big distros, which requires users to recompile their kernel. [ScottBalneaves]

• We need to sort out who's going to handle the actual mounting/unmounting of the media. If it's to be done in ltspfs (mount on use of ltspfs filesystem, unmount media on idle), then ltspfs somehow needs to receive information about the removable media's geometry (vfat,iso9660,ro,rw,other -o's). This can happen a couple of ways:
  • Something cool with dbus
  • Something more pedestrian like getting passed the info at mount time.
• If HAL/dbus handle the polling of media and mount/unmount, then that needs sorting out as well.
• To me, nbd/enbd seems a nice solution but:
  • nbd doesn't supports ioctl nor encryption and isn't sync (ie removing the usb stick right after unmounting it can let the just copied file broken!)

  • [OliverGrawert] nbd will be used for swapping (see the ThinclientMemory) its not feasable for the purposes as we were discussing them here in montreal.

  • enbd is supposed to be nice but last time I checked it wasn't playing well with recent kernels (>=2.6.10)

  • [OliverGrawert] enbd is not being included upstream thats not an option for us.

• I also tried mounting the /media of the thin client via samba (in a gdm presession script) and automounting each media locally with a simple udev script, works fine but nautilus refused to copy new files, (incorrectly) saying "not enough space", cp did it well. Probably a problem with my setup...

• [OliverGrawert] we neither use gdm in ubuntu ltsp not do we see the need to introduce an additional filesystem.

• whatever the solution is, privacy might be a problem, as well as discoverability: if ten users have their usbstick plugged in, each of them should only see it's own on the desktop (and ideally be unable to access to the other's even if he knows where it is mounted) [AurelienNaldi]

• [OliverGrawert] thats the reason we discuss encrypted transports

BoF agenda and discussion