A Flexible Approach to Thin Client Removable Media Management

Paul Whittaker (Paul.Whittaker@iname.com)
Director, Cloud Network Technologies Pty Ltd, Australia
Last update: 28 January 2002

Index

Overview

This package presents three methods for remote access to removable media devices in a thin client environment - one for conventional random-access devices, one for sequential-access devices, and one for CD writers. Collectively, they allow access to almost any removable media device supported by Linux.

The techniques documented here have been transplanted from an alternative i386 open-source thin client project that I am currently developing using embedded methodologies (with design objectives that differ significantly from those of LTSP). As I have borrowed a couple of utility programs from the LTSP project, I thought it only fair to offer up these techniques in return. The intent is to provide a flexible and portable means of removable media access, at the expense of end-user seamlessness - if this does not suit you then you may wish to consider existing alternatives documented elsewhere (NBD and mtools (floppyd)).

These methods have been tested on and are known to work with 1.44 Mb floppy disk drive, ATAPI and USB Zip 100 and Zip 250 drives, CDROM, CD-RW, DVD-ROM, DVD-RAM, Orb drive and SCSI QIC-150 tape. The author has every expectation that they will work with a far greater range of devices.

Requirements

The removable media package requires LTSP 3.0. I'm not going to write one for 2.x, so don't ask.

You will probably want a user-friendly FTP GUI on your server. gftp is as good as any, and comes with many Linux distributions.

If you wish to use tape or CD writer devices, you will need to have Local Apps installed and enabled. This is not necessary for other types of devices. For CD writers, you will need cdrtools-1.10 on your server, and unless you are a masochist you will also want a GUI front-end such as xcdroast-0.98a9 also. These packages are provided with RedHat 7.2 and other recent distributions.

Please Mr McQuillan ...

Unfortunately the LTSP 3.0.1 kernel package doesn't include some kernel modules that are needed to use certain removable media devices: drivers/ide/ide-floppy.o (CONFIG_BLK_DEV_IDEFLOPPY) and drivers/usb/storage/usb-storage.o (CONFIG_USB_STORAGE) for ATAPI and USB Zip drives respectively, and fs/udf/udf.o (CONFIG_UDF_FS and CONFIG_UDF_RW) for DVD-ROM/RAM.

I haven't included these modules here because it's too much hassle to obtain, patch and recompile the LTSP kernel source. Let's just ask Jim nicely if he can include them in the next LTSP kernel release, OK?

Enabling the tar applet in Busybox would also be helpful for allowing WU-FTPD to perform on-the-fly tar commands.

And while we're at it the kernel module loader, although present in the kernel, doesn't seem to work. A working kmod would make my life a lot easier. Note that even if you get the kernel module loader working, you will need to add ide-floppy to the /dev/discs line in /etc/modules.devfs to allow autodetection of ATAPI Zip drives (I should report this to the Devfs maintainer at some point!).

Installation

Extract the package into a temporary directory and run install.sh. The script must be run on a Linux box, although it may be run against a remote filesystem mounted via NFS or SMBFS/CIFS if your LTSP server is not Linux-based.

To enable access to random-access devices, you will need to make several changes to lts.conf (see configuration section).

To enable access to sequential-access devices you must add appropriate MODULE_nn entries to lts.conf for your tape controller and device. You may also need to create .rhosts files to allow less restrictive rsh access from your server, depending on your requirements (see Tapes section).

If you intend to use the remote CD burning capability, you will need to ensure that /home/rscsi/.rhosts and /etc/default/rscsi are appropriately set, and possibly perform some additional server-side configuration (see the CD Burners section).

Random-Access Devices (Disks)

Random-access devices are supported using an automount daemon (with sufficient components to do local device mounts only) "glued" to a WU-FTP daemon. Clients read and (if possible) write files to the removable media devices via anonymous FTP. The device is selected by chdir to an appropriately named directory, which then triggers an automount of that device onto the directory. Within two seconds of the user closing the FTP session, a "forced expire" signal is sent to automount in order to unmount the media and permit manual media ejection.

Unlike mtools (floppyd), this method supports filesystems other than DOS FAT. Unlike NBD, it doesn't have a 32-bit limitation preventing >2 Gb filesystem access. But most importantly it doesn't require that you run Linux - or even *nix - on your server. All you need is an FTP client, and halfway-decent GUI drag-n-drop FTP clients are available for almost all platforms these days. If worst comes to worst, you can always use command-line FTP or a web browser.

The FTP protocol supports all of the basic filesystem operations, not just GET and PUT. You can create and remove directories, change modes and umasks, delete files. GUIs may not have nice buttons for all of these functions, but generally they are still accessable by some means. For bulk transfers, if MGET and MPUT aren't good enough, you can always use wget and WU-FTPD's ability to "tarballise" on the fly.

However, the mechanism for automatic unmounting of filesystems is crude (inadequate for use with web browsers, for example, because you have no control over when the browser closes the FTP session). You also have the problem of the "unbrowseability" of the rmedia directory, because of the way auto-indirect filesystem mounts work - subdirectories won't appear until you try to access them by name, which is very unintuitive when using GUI file selection dialogs. No doubt the autofs gurus will deal with this problem eventually.

There is also no support for audio CD or DVD playback, although this should be possible through use of Local Apps.

Despite all precautions anonymous FTP remains something of a security hazard. There is certainly scope to tighten up access control (eg. using TCP wrappers, or allowing access only from a trusted proxy) if you wish, but even so FTP daemons are vulnerable to attack and exploitation.

Configuration

In lts.conf, you will need to set RAMDISK_SIZE to at least 2048 for all workstations with removable media devices, as the default of 1024 is too small to contain the anonymous FTP hierarchy. You will also need to set "rmedia" to run from one of the available RCFILE_nn slots. You must then add appropriate device entries. Three new configuration options have been added:

You must specify at least RMEDIA_DEVnn_NAME and RMEDIA_DEVnn_PATH for any given nn, or else that device enumeration will be ignored.

The rmedia script will automatically detect all floppy disk and IDE devices, and will set up IDE SCSI emulation where needed. DO NOT add MODULE_nn lines for any IDE modules to lts.conf! For any other types of random-access devices, however, you will need to preload the appropriate modules using MODULE_nn slots, or else automount will be unable to detect them.

Example lts.conf Entry

[ws01]
RAMDISK_SIZE = 2048
RCFILE_01 = "rmedia"
MODULE_01 = "usb-uhci"
MODULE_02 = "usb-storage"
RMEDIA_DEV01_NAME = "floppy"
RMEDIA_DEV01_PATH = "/dev/floppy/0"
RMEDIA_DEV02_NAME = "cdrom"
RMEDIA_DEV02_NAME = "/dev/cdroms/cdrom0"
RMEDIA_DEV02_OPTIONS = "-fstype=iso9660,ro,block=2048"
RMEDIA_DEV03_NAME = "zip"
RMEDIA_DEV03_PATH = "/dev/discs/disc0/part4"

Using Anonymous FTP

To access a device, simply connect to your thin client using anonymous FTP, CWD to the directory representing the device you wish to use, and transfer or manipulate files using standard FTP commands.

Note that due to the nature of automount, available devices will not show up in the DIR listing for the rmedia directory - you must take a "leap of faith" and attempt to access directories using foreknowledge of what their names will be. This causes some inconvenience when using a GUI - you must enter the directory name by hand (all decent FTP GUIs will allow this somehow) rather than drill down via mouse click using the file selection dialog.

Sequential Access Devices (Tapes)

Remote access to tape devices is a no-brainer. This rmt capability is built into every *nix known to man. On any *nix, you can access remote tape devices using the dump and restore utilities by prepending a hostname and colon to the device name. On linux, tar and cpio support this syntax also (although this may not be immediately obvious from the documentation). The equivalent busybox applets do not, however.

Unfortunately rmt is fairly insecure. It relies upon rsh as a transport, so you must first set up the required host trusts by creating appropriate /etc/hosts.equiv or ~/.rhosts files on your thin client. The default hosts.equiv file created by LTSP 3.0 with Local Apps will allow rsh access by all users in the NIS passwd map, but it will not permit root access.

Don't go enabling root rsh access unless you absolutely have to - under Linux, you can avoid this by using an extended user@hostname:/remote/pathname syntax to run the rmt command on the thin client as a user other than the user invoking the command. You will have to create .rhosts files to allow this, or edit /opt/ltsp/i386/etc/rc.local such that it creates a more permissive /etc/rc.local - see the hosts.equiv(5) manpage. You will also need to add the "promiscuous" option to the auth line in /opt/ltsp/i386/etc/pam.d/rsh if you intend to use "+" wildcards.

If you must, you can allow root rsh access by creating an appropriate .rhosts file in /opt/ltsp/i386 (not /opt/ltsp/i386/root despite what it says in the passwd file). A file containing simply the word "server" should suffice.

In addition to rmt, the removable media package includes the mt utility, to allow you to perform essential low-level tape operations such as tape positioning (forward, rewind etc) and erase operations. The mt command does not support rmt, and must be run locally on your thin client via rsh or rlogin rather than on your server. The dd utility, also useful with tapes, is already available under LTSP 3.0 as a busybox applet.

CD Burners

Unfortunately the autofs/FTP method doesn't cater to CD-R and CD-RW units. However, there is a little-known feature of cdrecord called rscsi which allows cdrecord to issue SCSI commands to a remote device via rsh. This isn't very efficient, because all data read or written must be transmitted over the network between client and server, but you can burn at up to 4x or so on a 10 Mbit/s network or 12x on a 100 Mbit/s network. It isn't very safe either, but becomes quite reliable if used in conjunction with units supporting one of the so-called "Burnproof" technologies.

This capability has been provided in my removable media package for LTSP 3.0, but due to the reliance of rscsi on rsh it will not work unless you have Local Apps installed and enabled. It is possible to set up xinetd and rsh in a reasonably secure fashion without enabling full-blown Local Apps, but I won't go into that here.

To use the rscsi capability, you will need cdrtools-1.10 or later or equivalent derived packages, and a cdrecord/mkisofs GUI front end that allows you to enter the REMOTE:user@host:b,t,u syntax device names - many only allow you to enter (b,t,u) SCSI address tuples. I recommend X-CD-Roast 0.98a9, for which I will provide additional instructions below.

If the install script has not already done so, you will need to create a /home/rscsi and change its ownership to nobody. In /home/rscsi you will need to create a .rhosts file to allow remote access by whichever hosts and users you wish to allow access to. Note that since the user is not rsh'ing from an account with the same name (rscsi), you must include an allowed user specification as well as an allowed hosts specification. Note also that PAM will not honour "+" wildcards unless you add the promiscuous qualifier after pam_rhosts_auth.so in /opt/ltsp/i386/etc/pam.d/rsh.

You might want to take a look at /opt/ltsp/i386/etc/default/rscsi and further restrict the access to (IDE-)SCSI devices if your thin client has SCSI devices other than CD writers that you don't want remote users to have low-level SCSI access to.

Since your LTSP thin client will not allow root to rsh in to start rscsi (unless you tweaked PAM to allow this), you will need to set up cdrecord setuid root on your server so that you can run it unprivileged. X-CD-Roast will tell you if this has not been done, and will point you to a HowTo file for non-root access - follow these instructions. Note that the group mentioned must literally be named "cdwrite", this is hardcoded!

If you are using a RedHat release on your server, you should know that RedHat have mangled the X-CD-Roast and CD-R Tools packages rather horribly. To enable the non-root access described in the X-CD-Roast docs, you will first need to mv /usr/sbin/xcdroast /usr/bin/xcdroast to clobber the KDE wrapper. xcdrwrap is located rather obscurely in /usr/lib/xcdroast-0.98/bin.

Now try running cdrecord -scanbus dev=REMOTE:rscsi@hostname:, where hostname is the name of the thin client hosting the CD burner. If all goes well cdrecord will list all of the (IDE)-SCSI devices on the thin client that you have permitted rscsi to access, including (bus, target, unit) tuples for each device.

You should now run xcdroast as root in order to set up system-wide defaults. Don't worry about the devices it does or does not detect, just set up options as best you can and then save them. Running as root, you will have an additional Users tab available on which you can set up access to the application by unprivileged users. Make sure that you allow your users to specify their own reader and writer devices.

You should now be able to start X-CD-Roast and burn CDs as an unprivileged user. Since X-CD-Roast only scans the local host (ie. the server) for CD writers by default, you will need to use the -f argument to explicitly specify that the device is remote, ie. xcdroast -f 'REMOTE:rscsi@hostname:b,t,u' where b, t and u are the bus, target and unit numbers of the device as shown in the output of your cdrecord -scanbus command previously. You can specify additional devices by using a semicolon as a delimiter, eg. xcdroast -f 'REMOTE:rscsi@tc1:0,0,0;REMOTE:rscsi@tc1:0,1,0'. However, bear in mind that copies from a remote reader device to a co-hosted remote writer device are NOT local to that remote host - data is read from client to server and then written from server to client.