Creating And Configuring Filesystem Options (203.3)
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.
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 automount
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:
/etc/auto.master /etc/init.d/autofs
1 2 3 | |
The file contains lines with three whitespace 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:
1 2 | |
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
1 | |
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.
Automount with systemd¶
To initiate automount with systemd a unit file should be created in
/etc/systemd/system. The unit file should be named after the mount
point. In this example the file is named: mnt.mount because the mount
point is /mnt.
1 2 3 4 5 6 7 8 9 10 11 12 | |
After creating the unit file it should be activated with the command:
1 | |
Verify the activated mount point:
1 2 | |
To activate the auto mounting on startup use the command:
1 | |
Initiate a reboot and verify if the partition is mounted. More information about mounting with systemd can be found in the man page of systemd.mount(5).
Autofs with systemd¶
To enable autofs with systemd a unit file with the extension
.automount should be created in /etc/systemd/system. The information
in that file is being controlled and supervised by systemd. The
Automount units should be named after the directions they control. In
this example the name of the automount unit configuration file is:
mnt.automount.
1 2 3 4 5 6 7 8 9 | |
Activate the autofs automount unit.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | |
Once it has been started the mount output shows the mount point enabled with autofs.
1 2 | |
The command lsblk shows that that disk is not mounted.
1 2 3 4 5 6 7 8 | |
Let's do a file listing of the /mnt directory.
1 2 | |
Then execute the command lsblk again to verify if partition sdb1 is
mounted on /mnt.
1 2 3 4 5 6 7 8 | |
The mount command shows the same.
1 2 3 | |
Autofs combined with systemd is now working. See the manpage of systemd.automount(5) for more configuration options.
CD-ROM filesystem¶
Creating an image for a CD-ROM¶
The usual utilities for creating filesystems on hard-disk CD-ROM
filesystem ISO9660 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
1 | |
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 8.3 filename format 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 Rock Ridge 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 HFS 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
cdrwtoolprovides 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 loop mount 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
1 | |
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 cdrecord SCSI 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 busSCSI LUN ID
BUS cdrecord -scanbus and use these to write the CD:
1 2 3 4 5 6 7 8 | |
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 blank 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:
1 2 3 4 5 6 7 8 9 10 | |
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
1 | |
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
1 | |
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 symmetric encryption algorithms to encrypt your filesystem
with, namely: Twofish, Advanced Encryption Standard (AES) also known as
Rijndael, Data Encryption Standard (DES) and others. Twofish was also an
AES candidate like Rijndael. Due performance reasons Rijndael was
selected as the new AES standard. Twofish supports 128 bit block size
and keys up to 256 bits. DES is the predecessor of the AES standard and
is now considered as insecure because of the small key size. With
current computing power it is possible to brute force 56 bits (+8 parity
bits) DES keys in a relatively short time frame. AES uses a block size
of 128 bits and a key size of 128, 192 or 256 bits. For many years 128
bits key size was sufficient but with the introduction of quantum
computers the U.S. National Security Agency issued guidance for data
classification up to Top Secret with 256 bits keys. Intel introduced in
2010 the Advanced Encryption Standard New Instructions (AES-NI) set.
This new instruction set performs the encryption and decryption
completely in hardware which helps to lower the risk of side-channel
attacks and greatly improve AES performance. To check if your CPU
supports the AES-NI instruction set use the command:
grep aes /proc/cpuinfo. You can check AES-NI kernel support with the
command: sort -u /proc/crypto | grep module and load the driver with
the command: modprobe aesni-intel as root.
Device Mapper¶
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 hard
disk. 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.
Device Mapper crypt (dm-crypt)¶
Device mapper crypt provides a generic way for transparent encryption of block devices by using the kernel API and can be used in combination with RAID or LVM volumes. When the user creates a new block device he can specify several options: symmetric cipher, encryption mode, key and iv generation mode. Dm-crypt does not store any information in a header like LUKS does. After encrypting the disk it will be indistinguishable from a disk with random data. This means that the existence of of encrypted files deniable in the sense that it can not be proven that encrypted data exists. The user should keep track of the options that are used in the dm-crypt setup otherwise it could lead to data loss since no metadata is available. Only one encryption key can be used to encrypt and decrypt block devices and no master key can be used. Once the password of a encrypted block device is lost there is no possibility to recover the data. Dm-crypt should only be used by advanced users. Regular users should use LUKS for disk encryption.
Linux Unified Key Setup (LUKS)¶
LUKS is a standard utility on all generic linux distributions. It provides disk encryption for different type of volumes (plain dm-crypt volumes, LUKS volumes, etc.). It offers compatibility amongst distributions and provides secure management of user passwords. It also provides storage of cryptography options including the master key in the partition header enabling seamlessly transport or data migration. LUKS also provides up to 8 different keys per LUKS partition to enable key escrow (usage of keys per meaning). By creating encrypted partitions on different Linux distributions the default settings may vary but the settings are sufficient enough to protect the data on the volume(s). LUKS is the preferred method for data protection by regular users.
Example with dm-crypt¶
This is an example to set up an encrypted filesystem. All relevant modules should be loaded at boot time:
1 2 3 4 | |
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:
1 2 | |
Make a filesystem:
1 | |
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:
1 2 | |
Example with LUKS¶
This is an example to create an 512 MiB encrypted LUKS container in a linux environment.
1 | |
Format the sparse file with LUKS and provide a passphrase:
1 2 3 4 5 6 7 8 9 | |
Open the container, provide a name and enter the passphrase:
1 2 | |
Create a filesystem on the unencrypted container:
1 2 3 4 5 6 7 8 9 10 11 | |
Mount the encrypted container for usage:
1 | |
Encrypted container as filesystem:
1 2 3 4 5 6 7 8 9 10 11 | |
Content of /mnt as any ext4 filesystem:
1 2 | |
Unmount the encrypted container after usage:
1 | |
Close the encrypted container:
1 | |