ThinClientLocalDevices

Differences between revisions 21 and 22
⇤ ← Revision 21 as of 2005-11-05 21:38:30 →
Size: 7505
Editor: 209
Comment:
← Revision 22 as of 2006-01-01 05:22:10 → ⇥
Size: 7525
Editor: S0106000000cc07fc
Comment: cat spec
Deletions are marked like this. Additions are marked like this.
Line 110: Line 110:
----
CategorySpec

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:

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

The approach is to use dbus over the existing LTSP ssh X11 tunnel, attach the Thin Client's system dbus to the servers session dbus and do all the messaging through this implementation.

Mounting and actual data transport will be done through an additionally established ssh tunnel, ltspfs/ltspfsd will attach to this tunnel. Since ltspfs handles automated unmounting of unused devices after a period of time. Ltspfs also makes sure that the integrity of the written data over the network is given.

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

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

CategorySpec

ThinClientLocalDevices (last edited 2008-08-06 16:22:55 by localhost)