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.
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.
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!).
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).
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.
Specifies a unique descriptive identifier for the device. This will be used as the final component of the mount point pathname (/var/ftp/rmedia/name), so don't use spaces or punctuation. Typically you would use a word such as floppy, cdrom, zip, cdrw, cdrom1 etc.
This is the local pathname of the block device corresponding to the removable media unit. I strongly advise using generic devfs pathnames (eg. /dev/cdroms/cdrom0) rather than driver-specific traditional pathnames (eg. /dev/hdc) to avoid confusion over IDE SCSI emulation.
If you don't know which physical devices will associate with which pathnames, set RUNLEVEL to 3 temporarily and enable rmedia using RAMDISK_SIZE = 2048 and RCFILE_nn = "rmedia" without specifying any RMEDIA_DEVnn options, then boot the machine and use the shell prompt to find out what devices the script has detected in /dev/discs, /dev/cdroms etc. Change RUNLEVEL back to 5 when finished.
This allows you to override the default mount options for the device. This is not normally necessary. The defaults are:
-fstype=auto,noexec,nosuid,nodev,sync,uid=nobody_uid,gid=nobody_gid
... where nobody_uid and nobody_gid are the numeric UID and GID of the nobody user and group respectively.
These options are healthily paranoid, preventing the user from potentially gaining superuser access via executables on the media. If you want to ease up on this, edit /etc/rc.d/rmedia and change the default rather than using option overrides for every device.
The sync option is a safety measure to minimise the effects of a forced media ejection while a filesystem is still mounted (eg. if ftpwatch glitches). The uid= and gid= options ensure that the media is writable by the anonymous FTP user, which runs as nobody (for additional paranoia).
fstype=auto allows mount to try a user-defined sequence of filesystem types (from /etc/filesystems) to automatically deduce the filesystem type. This is a nice feature of mount that is not supported by the Busybox mount applet, which is why the package provides a replacement /bin/mount. The mount command will also automatically figure out if the media is read-only, so there's no need to specify this explicitly via overrides.
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.
[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"
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.
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.
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.