Creating And Configuring Filesystem Options (203.3)

Candidates should be able to configure automount filesystems using AutoFS. This objective includes configuring automount for network and device filesystems. Also included is creating filesystems for devices such as CD-ROMs.

Resources: Don99; Nielsen98; Truemper00.

Key Knowledge Areas

  • autofs configuration files

  • UDF and ISO9660 tools and utilities

  • awareness of CD-ROM filesystems (UDF, ISO9660, HFS)

  • awareness of CD-ROM filesystem extensions (Joliet, Rock Ridge, El Torito)

  • basic feature knowledge of encrypted filesystems

Terms and Utilities

  • /etc/auto.master

  • /etc/auto.[dir]

  • mkisofs

  • dd

  • mke2fs

Autofs and automounter

Automounting is the process in which mounting (and unmounting) of filesystems is done automatically by a daemon. If the filesystem is not mounted and a user tries to access it, it will be automatically (re)mounted. This is useful in networked environments (especially when not all machines are always on-line) and for removable devices, such as floppies and CD-ROMs.

The linux implementation of automounting, autofs, consists of a kernel component and a daemon called automount. Autofs uses automount to mount local and remote filesystems (over NFS) when needed and unmount them when they are not being used (after a timeout). Your /etc/init.d/autofs script first looks at /etc/auto.master:

	# sample /etc/auto.master file
	/var/autofs/floppy /etc/auto.floppy --timeout=2
	/var/autofs/cdrom /etc/auto.cdrom --timeout=6
			

The file contains lines with three whitspace separated fields. The first field lists the directory in which the mounts will be done. The second field lists the filename in which we have placed configuration data for the devices to be mounted, the supplemental files. The last field specifies options. In our example we specified a timeout. After the timeout period lapses, the automount daemon will unmount the devices specified in the supplemental file.

The configuration data in the supplemental files may consist of multiple lines and span multiple devices. The filenames and path to the supplemental files may be choosen freely. Each line in a supplemental file contains three fields:

	# sample /etc/auto.floppy file
	floppy -user,fstype=auto :/dev/fd0
			

The first value is the pseudo directory. If the device is mounted, a directory of that name will appear and you can change into it to explore the mounted filesystem. The second value contains the mount options. The third value is the device (such as /dev/fd0, the floppy drive) which the pseudo directory is connected to.

The configuration files are reread when the automounter is reloaded

/etc/init.d/autofs reload

Please note that autofs does NOT reload nor restart if the mounted directory ( eg: /home ) is busy. Every entry in auto.master starts it's own daemon.

The pseudo directory is contained in the directory which is defined in /etc/auto.master. When users try to access this pseudo directory, they will be rerouted to the device you specified. For example, if you specify a supplemental file to mount /dev/fd0 on /var/autofs/floppy/floppy, the command ls /var/autofs/floppy/floppy will list the contents of the floppy. But if you do the command ls /var/autofs/floppy, you don't see anything even though the directory /var/autofs/floppy/floppy should exist. That is because /var/autofs/floppy/floppy does not exist yet. Only when you directly try to access that directory the automounter will mount it.

Each device should have its own supplementary file. So, for example, configuration data for the floppy drive and that of the cdrom drive should not be combined into the same supplementary file. Each definition in the /etc/auto.master file results in spawning its own automount daemon. If you have several devices running under control of the same automount daemon - which is legit - but one of the devices fails, the daemon may hang or be suspended and other devices it controls might not be mounted properly either. Hence it is good practice to have every device under control ofits own automount daemon and so there should be just one device per supplementary file per entry in the /etc/auto.master file.

CD-ROM filesystem

Creating an image for a CD-ROM

The usual utilities for creating filesystems on hard-disk partitions write an empty filesystem onto them, which is then mounted and filled with files by the users as they need it. A writable CD is only writable once so if we wrote an empty filesystem to it, it would get formatted and remain completely empty forever. This is also true for re-writable media as you cannot change arbitrary sectors yet; you must erase the whole disk. The tool to create the filesystem is called mkisofs. A sample usage looks like this:

					$ mkisofs -r -o cd_image private_collection/
				

The option -r sets the permissions of all files on the CD to be public readable and enables Rock Ridge extensions. You probably want to use this option unless you really know what you're doing (hint: without -r the mount point gets the permissions of private_collection!).

mkisofs will try to map all filenames to the 8.3 format used by DOS to ensure the highest possible compatibility. In case of naming conflicts (different files have the same 8.3 name), numbers are used in the filenames and information about the chosen filename is printed via STDERR (usually the screen). Don't panic: Under Linux you will never see these odd 8.3 filenames because Linux makes use of the Rock Ridge extensions which contain the original file information (permissions, filename, etc.). Use the option -J (MS Joliet extensions) or use mkhybrid if you want to generate a more Windows-friendly CD-ROM. You can also use mkhybrid to create HFS CD-ROMS Read the man-page for details on the various options. Another extention is El Torito, which is used to create bootable CD-ROM filesystems.

Besides the ISO9660 filesystem as created by mkisofs there is the UDF (Universal Disk Format) filesystem. The Optical Storage Technology Association standardized the UDF filesystem to form a common filesystem for all (read-only and re-writable) optical media. It was intended to replace the ISO9660 filesystem.

Tools to create and maintain a UDF filesystem are:

mkudffs

Creates a new UDF filesystem. Can be used on hard disks as well as on CD-R(W).

udffsck

Used to check the integrity and correct errors on UDF filesystems.

wrudf

This command is used for maintaining UDF filesystems. It provides an interactive shell with operations on existing UDF filesystems: cp, rm, mkdir, rmdir, ls,.... etc.

cdrwtool

The cdrwtool provides facilities to manage CD-RW drives. This includes formating new disks, setting the read and write speeds, etc.

These tools are part of the UDFtools package.

Reasons why the output of mkisofs is not directly sent to the writer device:

  • mkisofs knows nothing about driving CD-writers;

  • You may want to test the image before burning it;

  • On slow machines it would not be reliable.

One could also think of creating an extra partition and writing the image to that partition instead to a file. This is possible, but has a few drawbacks. If you write to the wrong partition due to a typo, you could lose your complete Linux system. Furthermore, it is a waste of disk space because the CD-image is temporary data that can be deleted after writing the CD. However, using raw partitions saves you the time of deleting 650MB-sized files.

Test the CD-image

Linux has the ability to mount files as if they were disk partitions. This feature is useful to check that the directory layout and file-access permissions of the CD image matches your wishes. Although media is very cheap today, the writing process is still time consuming, and you may at least want to save some time by doing a quick test.

To mount the file cd_image created above on the directory /cdrom, give the command

	$ mount -t iso9660 -o ro,loop=/dev/loop0 cd_image /cdrom
				

Now you can inspect the files under /cdrom - they appear exactly as they were on a real CD. To unmount the CD-image, just say umount /cdrom.

Write the CD-image to a CD

The command cdrecord is used to write images to a SCSI CD-burner. Non-SCSI writers require compatibility drivers, which make them appear as if they were real SCSI devices.

CD-writers want to be fed a constant stream of data. So, the process of writing the image to the CD must not be interrupted or the CD may be corrupted. It is easy to unintentionally interrupt the data stream, for example by deleting a very large file. Say you delete an old 650 Mb CD-image - the kernel must update information on 650,000 blocks of the hard disk (assuming you have a block size of 1 Kb for your filesystem). That takes some time and will slow down disk activity long enough for the data stream to pause for a few seconds. However, reading mail, browsing the web, or even compiling a kernel generally will not affect the writing process on modern machines.

Please note that no writer can re-position its laser and continue at the original spot on the CD when it gets disturbed. Therefore any strong vibrations or other mechanical shocks will probably destroy the CD you are writing.

You need to find the SCSI-BUS, -ID and -LUN number with cdrecord -scanbus and use these to write the CD:

	shell> SCSI_BUS=0 #
	shell> SCSI_ID=6 # taken from cdrecord -scanbus
	shell> SCSI_LUN=0 #
	shell> cdrecord -v speed=2 dev=$SCSI_BUS,$SCSI_ID,$SCSI_LUN \
	-data cd_image

	# same as above, but shorter:
	shell> cdrecord -v speed=2 dev=0,6,0 -data cd_image
				

For better readability, the coordinates of the writer are stored in three environment variables whose names actually make sense: SCSI_BUS, SCSI_ID, SCSI_LUN.

If you use cdrecord to overwrite a CD-RW, you must add the option blank=... to erase the old content. Please read the man page to learn more about the various methods of clearing the CD-RW.

If the machine is fast enough, you can feed the output of mkisofs directly into cdrecord:

	shell> IMG_SIZE=`mkisofs -R -q -print-size private_collection/ 2>&1
	\
	| sed -e "s/.* = //"`

	shell> echo $IMG_SIZE

	shell> [ "0$IMG_SIZE" -ne 0 ] && mkisofs -r
	private_collection/ \
	| cdrecord speed=2 dev=0,6,0 tsize=${IMG_SIZE}s -data -

	# don't forget the s --^ ^-- read data from STDIN
				

The first command is an empty run to determine the size of the image (you need the mkisofs from the cdrecord distribution for this to work). You need to specify all parameters you will use on the final run (e.g. -J or -hfs). If your writer does not need to know the size of the image to be written, you can leave this dry run out. The printed size must be passed as a tsize-parameter to cdrecord (it is stored in the environment variable IMG_SIZE). The second command is a sequence of mkisofs and cdrecord, coupled via a pipe.

Making a copy of a data CD

It is possible to make a 1:1 copy of a data CD. But you should be aware of the fact that any errors while reading the original (due to dust or scratches) will result in a defective copy. Please note that both methods will fail on audio CDs!

First case: you have a CD-writer and a separate CD-ROM drive. By issuing the command

	cdrecord -v dev=0,6,0 speed=2 -isosize /dev/scd0
				

you read the data stream from the CD-ROM drive attached as /dev/scd0 and write it directly to the CD-writer.

Second case: you don't have a separate CD-ROM drive. In this case you have to use the CD-writer to read out the CD-ROM first:

	dd if=/dev/scd0 of=cdimage
				

This command reads the content of the CD-ROM from the device /dev/scd0 and writes it into the file cdimage. The content of this file is equivalent to what mkisofs produces, so you can proceed as described earlier in this document (which is to take the file cdimage as input for cdrecord).

Encrypted file systems

Linux has native filesystem encryption support. You can choose from a number of encryption algorithms: Twofish, AES, DES and others. For our example we choose AES.

As of linux 2.6 it is possible to use the devicemapper, a generic linux framework to map one block device to another. Devicemapper is used for software RAID and LVM. It is used as the filter between the filesystem on a virtual blockdevice and the encrypted data to be written to a harddisk. This enables the filesystem to present itself decrypted while everything read and written will be encrypted on disk. A virtual block device is created in /dev/mapper, which can be used as any other block device. All data to and from it goes to an encryption or decryption filter before being mapped to another blockdevice.

This is an example to set up an encrypted filesystem. All relevant modules should be loaded at boot time:

	# echo aes >> /etc/modules
	# echo dm_mod >> /etc/modules
	# echo dm_crypt >> /etc/modules
	# modprobe -a aes dm_mod dm_crypt
			

Create the device mapperblock device and use (for example) hda3 for it. Choose your password using: cryptsetup -y create crypt /dev/hda3 Map the device:

	# echo "crypt /dev/hda3 none none" >> /etc/crypttab
	# echo "/dev/mapper/crypt /crypt reiserfs defaults 0 1" >> /etc/fstab
			

Make a filesystem:

	# mkfs.reiserfs /dev/mapper/crypt
			

Now mount your encrypted filesystem. You will be prompted for the password you chose with cryptsetup. You will be asked to provide it at every boot:

	# mkdir /crypt
	# mount /crypt
			

Copyright Snow B.V. The Netherlands