diff --git a/en_US.ISO8859-1/books/handbook/disks/chapter.xml b/en_US.ISO8859-1/books/handbook/disks/chapter.xml index b0abcb8507..fcbe022a47 100644 --- a/en_US.ISO8859-1/books/handbook/disks/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/disks/chapter.xml @@ -1,3888 +1,3813 @@ Storage Synopsis This chapter covers the use of disks in &os;. This includes memory-backed disks, network-attached disks, standard SCSI/IDE storage devices, and devices using the USB interface. After reading this chapter, you will know: The terminology &os; uses to describe the organization of data on a physical disk. How to add additional hard disks to a &os; system. How to configure &os; to use USB storage devices. How to set up virtual file systems, such as memory disks. How to use quotas to limit disk space usage. How to encrypt disks to secure them against attackers. How to create and burn CDs and DVDs on &os;. How to use the backup programs available under &os;. What file system snapshots are and how to use them efficiently. Before reading this chapter, you should: Know how to configure and install a new &os; kernel. Device Names The following is a list of physical storage devices supported in &os; and their associated device names. Physical Disk Naming Conventions Drive type Drive device name IDE hard drives ad or ada IDE CD-ROM drives acd or cd SATA hard drives ad or ada SATA CD-ROM drives acd or cd SCSI hard drives and USB Mass storage devices da SCSI CD-ROM drives cd Assorted non-standard CD-ROM drives mcd for Mitsumi CD-ROM and scd for Sony CD-ROM devices Floppy drives fd SCSI tape drives sa IDE tape drives ast Flash drives fla for &diskonchip; Flash device RAID drives aacd for &adaptec; AdvancedRAID, mlxd and mlyd for &mylex;, amrd for AMI &megaraid;, idad for Compaq Smart RAID, twed for &tm.3ware; RAID.
Adding Disks David O'Brien Originally contributed by disks adding This section describes how to add a new SATA disk to a machine that currently only has a single drive. First, turn off the computer and install the drive in the computer following the instructions of the computer, controller, and drive manufacturers. Reboot the system and become root. Inspect /var/run/dmesg.boot to ensure the new disk was found. In this example, the newly added SATA drive will appear as ada1. partitions gpart For this example, a single large partition will be created on the new disk. The GPT partitioning scheme will be used in preference to the older and less versatile MBR scheme. If the disk to be added is not blank, old partition information can be removed with gpart delete. See &man.gpart.8; for details. The partition scheme is created, and then a single partition is added: &prompt.root; gpart create -s GPT ada1 &prompt.root; gpart add -t freebsd-ufs ada1 Depending on use, several smaller partitions may be desired. See &man.gpart.8; for options to create partitions smaller than a whole disk. A file system is created on the new blank disk: &prompt.root; newfs -U /dev/ada1p1 An empty directory is created as a mountpoint, a location for mounting the new disk in the original disk's file system: &prompt.root; mkdir /newdisk Finally, an entry is added to /etc/fstab so the new disk will be mounted automatically at startup: /dev/ada1p1 /newdisk ufs rw 2 2 The new disk can be mounted manually, without restarting the system: &prompt.root; mount /newdisk USB Storage Devices Marc Fonvieille Contributed by USB disks Many external storage solutions, such as hard drives, USB thumbdrives, and CD/DVD burners, use the Universal Serial Bus (USB). &os; provides support for these devices. Configuration The USB mass storage devices driver, &man.umass.4;, is built into the GENERIC kernel and provides support for USB storage devices. For a custom kernel, be sure that the following lines are present in the kernel configuration file: device scbus device da device pass device uhci device ohci device ehci device usb device umass Since the &man.umass.4; driver uses the SCSI subsystem to access the USB storage devices, any USB device will be seen as a SCSI device by the system. Depending on the USB chipset on the motherboard, device uhci or device ohci is used to provide USB 1.X support. Support for USB 2.0 controllers is provided by device ehci. If the USB device is a CD or DVD burner, &man.cd.4;, must be added to the kernel via the line: device cd Since the burner is seen as a SCSI drive, the driver &man.atapicam.4; should not be used in the kernel configuration. Testing the Configuration To test the USB configuration, plug in the USB device. In the system message buffer, &man.dmesg.8;, the drive should appear as something like: umass0: USB Solid state disk, rev 1.10/1.00, addr 2 GEOM: create disk da0 dp=0xc2d74850 da0 at umass-sim0 bus 0 target 0 lun 0 da0: <Generic Traveling Disk 1.11> Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 126MB (258048 512 byte sectors: 64H 32S/T 126C) The brand, device node (da0), and other details will differ according to the device. Since the USB device is seen as a SCSI one, camcontrol can be used to list the USB storage devices attached to the system: &prompt.root; camcontrol devlist <Generic Traveling Disk 1.11> at scbus0 target 0 lun 0 (da0,pass0) If the drive comes with a file system, it can be mounted. Refer to for instructions on how to format and create partitions on the USB drive. Allowing untrusted users to mount arbitrary media, by enabling vfs.usermount as described below, should not be considered safe from a security point of view. Most file systems in &os; were not built to safeguard against malicious devices. To make the device mountable as a normal user, one solution is to make all users of the device a member of the operator group using &man.pw.8;. Next, ensure that the operator group is able to read and write the device by adding these lines to /etc/devfs.rules: [localrules=5] add path 'da*' mode 0660 group operator If SCSI disks are installed in the system, change the second line as follows: add path 'da[3-9]*' mode 0660 group operator This will exclude the first three SCSI disks (da0 to da2)from belonging to the operator group. Next, enable the &man.devfs.rules.5; ruleset in /etc/rc.conf: devfs_system_ruleset="localrules" Next, instruct the running kernel to allow regular users to mount file systems. The easiest way is to add the following line to /etc/sysctl.conf: vfs.usermount=1 Since this only takes effect after the next reboot use &man.sysctl.8; to set this variable now. The final step is to create a directory where the file system is to be mounted. This directory needs to be owned by the user that is to mount the file system. One way to do that is for root to create a subdirectory owned by that user as /mnt/username. In the following example, replace username with the login name of the user and usergroup with the user's primary group: &prompt.root; mkdir /mnt/username &prompt.root; chown username:usergroup /mnt/username Suppose a USB thumbdrive is plugged in, and a device /dev/da0s1 appears. If the device is preformatted with a FAT file system, it can be mounted using: &prompt.user; mount -t msdosfs -o -m=644,-M=755 /dev/da0s1 /mnt/username Before the device can be unplugged, it must be unmounted first. After device removal, the system message buffer will show messages similar to the following: umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry GEOM: destroy disk da0 dp=0xc2d74850 umass0: detached Further Reading Beside the Adding Disks and Mounting and Unmounting File Systems sections, reading various manual pages may also be useful: &man.umass.4;, &man.camcontrol.8;, and &man.usbconfig.8; under &os;  8.X or &man.usbdevs.8; under earlier versions of &os;. Creating and Using CD Media Mike Meyer Contributed by CD-ROMs creating Introduction CD media provide a number of features that differentiate them from conventional disks. Initially, they were not writable by the user. They are designed so that they can be read continuously without delays to move the head between tracks. They are also much easier to transport between systems. CD media do have tracks, but this refers to a section of data to be read continuously and not a physical property of the disk. For example, to produce a CD on &os;, prepare the data files that are going to make up the tracks on the CD, then write the tracks to the CD. ISO 9660 file systems ISO 9660 The ISO 9660 file system was designed to deal with these differences. To overcome the original file system limits, it provides an extension mechanism that allows properly written CDs to exceed those limits while still working with systems that do not support those extensions. sysutils/cdrtools The sysutils/cdrtools port includes &man.mkisofs.8;, a program that can be used to produce a data file containing an ISO 9660 file system. It has options that support various extensions, and is described below. CD burner ATAPI Which tool to use to burn the CD depends on whether the CD burner is ATAPI or something else. ATAPI CD burners use burncd which is part of the base system. SCSI and USB CD burners should use cdrecord from the sysutils/cdrtools port. It is also possible to use cdrecord and other tools for SCSI drives on ATAPI hardware with the ATAPI/CAM module. For CD burning software with a graphical user interface, consider X-CD-Roast or K3b. These tools are available as packages or from the sysutils/xcdroast and sysutils/k3b ports. X-CD-Roast and K3b require the ATAPI/CAM module with ATAPI hardware. <application>mkisofs</application> The sysutils/cdrtools port also installs &man.mkisofs.8;, which produces an ISO 9660 file system that is an image of a directory tree in the &unix; file system name space. The simplest usage is: &prompt.root; mkisofs -o imagefile.iso /path/to/tree file systems ISO 9660 This command creates an imagefile.iso containing an ISO 9660 file system that is a copy of the tree at /path/to/tree. In the process, it maps the file names to names that fit the limitations of the standard ISO 9660 file system, and will exclude files that have names uncharacteristic of ISO file systems. file systems HFS file systems Joliet A number of options are available to overcome these restrictions. In particular, enables the Rock Ridge extensions common to &unix; systems, enables Joliet extensions used by Microsoft systems, and can be used to create HFS file systems used by &macos;. For CDs that are going to be used only on &os; systems, can be used to disable all filename restrictions. When used with , it produces a file system image that is identical to the specified &os; tree, though it may violate the ISO 9660 standard in a number of ways. CD-ROMs creating bootable The last option of general use is . This is used to specify the location of the boot image for use in producing an El Torito bootable CD. This option takes an argument which is the path to a boot image from the top of the tree being written to the CD. By default, &man.mkisofs.8; creates an ISO image in floppy disk emulation mode, and thus expects the boot image to be exactly 1200, 1440 or 2880 KB in size. Some boot loaders, like the one used by the &os; distribution disks, do not use emulation mode. In this case, should be used. So, if /tmp/myboot holds a bootable &os; system with the boot image in /tmp/myboot/boot/cdboot, this command would produce the image of an ISO 9660 file system as /tmp/bootable.iso: &prompt.root; mkisofs -R -no-emul-boot -b boot/cdboot -o /tmp/bootable.iso /tmp/myboot If md is configured in the kernel, the file system can be mounted as a memory disk with: &prompt.root; mdconfig -a -t vnode -f /tmp/bootable.iso -u 0 &prompt.root; mount -t cd9660 /dev/md0 /mnt One can then verify that /mnt and /tmp/myboot are identical. There are many other options available for &man.mkisofs.8; to fine-tune its behavior. Refer to &man.mkisofs.8; for details. <application>burncd</application> CD-ROMs burning For an ATAPI CD burner, burncd can be used to burn an ISO image onto a CD. burncd is part of the base system, installed as /usr/sbin/burncd. Usage is very simple, as it has few options: &prompt.root; burncd -f cddevice data imagefile.iso fixate This command will burn a copy of imagefile.iso on cddevice. The default device is /dev/acd0. See &man.burncd.8; for options to set the write speed, eject the CD after burning, and write audio data. <application>cdrecord</application> For systems without an ATAPI CD burner, cdrecord can be used to burn CDs. cdrecord is not part of the base system and must be installed from either the sysutils/cdrtools package or port. Changes to the base system can cause binary versions of this program to fail, possibly resulting in a coaster. It is recommended to either upgrade the port when the system is upgraded, or for users tracking -STABLE, to upgrade the port when a new version becomes available. While cdrecord has many options, basic usage is simple. Burning an ISO 9660 image is done with: &prompt.root; cdrecord dev=device imagefile.iso The tricky part of using cdrecord is finding the to use. To find the proper setting, use which might produce results like this: CD-ROMs burning &prompt.root; cdrecord -scanbus Cdrecord-Clone 2.01 (i386-unknown-freebsd7.0) Copyright (C) 1995-2004 Jörg Schilling Using libscg version 'schily-0.1' scsibus0: 0,0,0 0) 'SEAGATE ' 'ST39236LW ' '0004' Disk 0,1,0 1) 'SEAGATE ' 'ST39173W ' '5958' Disk 0,2,0 2) * 0,3,0 3) 'iomega ' 'jaz 1GB ' 'J.86' Removable Disk 0,4,0 4) 'NEC ' 'CD-ROM DRIVE:466' '1.26' Removable CD-ROM 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * scsibus1: 1,0,0 100) * 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) 'YAMAHA ' 'CRW4260 ' '1.0q' Removable CD-ROM 1,6,0 106) 'ARTEC ' 'AM12S ' '1.06' Scanner 1,7,0 107) * This lists the appropriate value for the devices on the list. Locate the CD burner, and use the three numbers separated by commas as the value for . In this case, the CRW device is 1,5,0, so the appropriate input is . Refer to &man.cdrecord.1; for easier ways to specify this value and for information on writing audio tracks and controlling the write speed. Duplicating Audio CDs To duplicate an audio CD, extract the audio data from the CD to a series of files, then write these files to a blank CD. The process is slightly different for ATAPI and SCSI drives. SCSI Drives Use cdda2wav to extract the audio: &prompt.user; cdda2wav -vall -D2,0 -B -Owav Use cdrecord to write the .wav files: &prompt.user; cdrecord -v dev=2,0 -dao -useinfo *.wav Make sure that 2,0 is set appropriately, as described in . ATAPI Drives With the help of the ATAPI/CAM module, cdda2wav can also be used on ATAPI drives. This tool is usually a better choice for most of users, as it supports jitter correction and endianness, than the method proposed below. The ATAPI CD driver makes each track available as /dev/acddtnn, where d is the drive number, and nn is the track number written with two decimal digits, prefixed with zero as needed. So the first track on the first disk is /dev/acd0t01, the second is /dev/acd0t02, the third is /dev/acd0t03, and so on. Make sure the appropriate files exist in /dev. If the entries are missing, force the system to retaste the media: &prompt.root; dd if=/dev/acd0 of=/dev/null count=1 Extract each track using &man.dd.1;, making sure to specify a block size when extracting the files: &prompt.root; dd if=/dev/acd0t01 of=track1.cdr bs=2352 &prompt.root; dd if=/dev/acd0t02 of=track2.cdr bs=2352 ... Burn the extracted files to disk using burncd. Specify that these are audio files, and that burncd should fixate the disk when finished: &prompt.root; burncd -f /dev/acd0 audio track1.cdr track2.cdr ... fixate Duplicating Data CDs It is possible to copy a data CD to an image file that is functionally equivalent to the image file created with &man.mkisofs.8;, and then use it to duplicate any data CD. The example given here assumes that the CD-ROM device is acd0. Substitute the correct CD-ROM device. &prompt.root; dd if=/dev/acd0 of=file.iso bs=2048 Now that there is an image, it can be burned to CD as described above. Using Data CDs It is possible to mount and read the data on a standard data CD. By default, &man.mount.8; assumes that a file system is of type ufs. Running this command: &prompt.root; mount /dev/cd0 /mnt will generate an error about Incorrect super block, and will fail to mount the CD. The CD does not use the UFS file system, so attempts to mount it as such will fail. Instead, tell &man.mount.8; that the file system is of type ISO9660 by specifying to &man.mount.8;. For example, to mount the CD-ROM device, /dev/cd0, under /mnt, use: &prompt.root; mount -t cd9660 /dev/cd0 /mnt Replace /dev/cd0 with the device name for the CD device. Also, executes &man.mount.cd9660.8;, meaning the above command is equivalent to: &prompt.root; mount_cd9660 /dev/cd0 /mnt While data CD-ROMs from any vendor can be mounted this way, disks with certain ISO 9660 extensions might behave oddly. For example, Joliet disks store all filenames in two-byte Unicode characters. The &os; kernel does not speak Unicode, but the &os; CD9660 driver is able to convert Unicode characters on the fly. If some non-English characters show up as question marks, specify the local charset with . For more information, refer to &man.mount.cd9660.8;. In order to do this character conversion with the help of , the kernel requires the cd9660_iconv.ko module to be loaded. This can be done either by adding this line to loader.conf: cd9660_iconv_load="YES" and then rebooting the machine, or by directly loading the module with &man.kldload.8;. Occasionally, Device not configured will be displayed when trying to mount a CD-ROM. This usually means that the CD-ROM drive thinks that there is no disk in the tray, or that the drive is not visible on the bus. It can take a couple of seconds for a CD-ROM drive to realize that a media is present, so be patient. Sometimes, a SCSI CD-ROM may be missed because it did not have enough time to answer the bus reset. To resolve this, add the following option to the kernel configuration and rebuild the kernel. options SCSI_DELAY=15000 This tells the SCSI bus to pause 15 seconds during boot, to give the CD-ROM drive every possible chance to answer the bus reset. Burning Raw Data CDs It is possible to burn a file directly to CD, without creating an ISO 9660 file system. Some people do this for backup purposes. This command runs more quickly than burning a standard CD: &prompt.root; burncd -f /dev/acd1 -s 12 data archive.tar.gz fixate In order to retrieve the data burned to such a CD, the data must be read from the raw device node: &prompt.root; tar xzvf /dev/acd1 This type of disk can not be mounted as a normal CD-ROM and the data cannot be read under any operating system except &os;. In order to mount the CD, or to share the data with another operating system, &man.mkisofs.8; must be used as described above. Using the ATAPI/CAM Driver Marc Fonvieille Contributed by CD burner ATAPI/CAM driver This driver allows ATAPI devices, such as CD/DVD drives, to be accessed through the SCSI subsystem, and so allows the use of applications like sysutils/cdrdao or &man.cdrecord.1;. To use this driver, add the following line to /boot/loader.conf: atapicam_load="YES" then, reboot the system. Users who prefer to statically compile &man.atapicam.4; support into the kernel, should add this line to the kernel configuration file: device atapicam Ensure the following lines are still in the kernel configuration file: device ata device scbus device cd device pass Then rebuild, install the new kernel, and reboot the machine. During the boot process, the burner should show up, like so: acd0: CD-RW <MATSHITA CD-RW/DVD-ROM UJDA740> at ata1-master PIO4 cd0 at ata1 bus 0 target 0 lun 0 cd0: <MATSHITA CDRW/DVD UJDA740 1.00> Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed The drive can now be accessed via the /dev/cd0 device name. For example, to mount a CD-ROM on /mnt, type the following: &prompt.root; mount -t cd9660 /dev/cd0 /mnt As root, run the following command to get the SCSI address of the burner: &prompt.root; camcontrol devlist <MATSHITA CDRW/DVD UJDA740 1.00> at scbus1 target 0 lun 0 (pass0,cd0) In this example, 1,0,0 is the SCSI address to use with &man.cdrecord.1; and other SCSI applications. For more information about ATAPI/CAM and SCSI system, refer to &man.atapicam.4; and &man.cam.4;. Creating and Using DVD Media Marc Fonvieille Contributed by Andy Polyakov With inputs from DVD burning Introduction Compared to the CD, the DVD is the next generation of optical media storage technology. The DVD can hold more data than any CD and is the standard for video publishing. Five physical recordable formats can be defined for a recordable DVD: DVD-R: This was the first DVD recordable format available. The DVD-R standard is defined by the DVD Forum. This format is write once. DVD-RW: This is the rewritable version of the DVD-R standard. A DVD-RW can be rewritten about 1000 times. DVD-RAM: This is a rewritable format which can be seen as a removable hard drive. However, this media is not compatible with most DVD-ROM drives and DVD-Video players as only a few DVD writers support the DVD-RAM format. Refer to for more information on DVD-RAM use. DVD+RW: This is a rewritable format defined by the DVD+RW Alliance. A DVD+RW can be rewritten about 1000 times. DVD+R: This format is the write once variation of the DVD+RW format. A single layer recordable DVD can hold up to 4,700,000,000 bytes which is actually 4.38 GB or 4485 MB as 1 kilobyte is 1024 bytes. A distinction must be made between the physical media and the application. For example, a DVD-Video is a specific file layout that can be written on any recordable DVD physical media such as DVD-R, DVD+R, or DVD-RW. Before choosing the type of media, ensure that both the burner and the DVD-Video player are compatible with the media under consideration. Configuration To perform DVD recording, use &man.growisofs.1;. This command is part of the sysutils/dvd+rw-tools utilities which support all DVD media types. These tools use the SCSI subsystem to access the devices, therefore ATAPI/CAM support must be loaded or statically compiled into the kernel. This support is not needed if the burner uses the USB interface. Refer to for more details on USB device configuration. DMA access must also be enabled for ATAPI devices, by adding the following line to /boot/loader.conf: hw.ata.atapi_dma="1" Before attempting to use dvd+rw-tools, consult the Hardware Compatibility Notes. For a graphical user interface, consider using sysutils/k3b which provides a user friendly interface to &man.growisofs.1; and many other burning tools. Burning Data DVDs Since &man.growisofs.1; is a front-end to mkisofs, it will invoke &man.mkisofs.8; to create the file system layout and perform the write on the DVD. This means that an image of the data does not need to be created before the burning process. To burn to a DVD+R or a DVD-R the data in /path/to/data, use the following command: &prompt.root; growisofs -dvd-compat -Z /dev/cd0 -J -R /path/to/data In this example, is passed to &man.mkisofs.8; to create an ISO 9660 file system with Joliet and Rock Ridge extensions. Refer to &man.mkisofs.8; for more details. For the initial session recording, is used for both single and multiple sessions. Replace /dev/cd0, with the name of the DVD device. Using indicates that the disk will be closed and that the recording will be unappendable. This should also provide better media compatibility with DVD-ROM drives. To burn a pre-mastered image, such as imagefile.iso, use: &prompt.root; growisofs -dvd-compat -Z /dev/cd0=imagefile.iso The write speed should be detected and automatically set according to the media and the drive being used. To force the write speed, use . Refer to &man.growisofs.1; for example usage. In order to support working files larger than 4.38GB, an UDF/ISO-9660 hybrid file system must be created by passing to &man.mkisofs.8; and all related programs, such as &man.growisofs.1;. This is required only when creating an ISO image file or when writing files directly to a disk. Since a disk created this way must be mounted as an UDF file system with &man.mount.udf.8;, it will be usable only on an UDF aware operating system. Otherwise it will look as if it contains corrupted files. To create this type of ISO file: &prompt.user; mkisofs -R -J -udf -iso-level 3 -o imagefile.iso /path/to/data To burn files directly to a disk: &prompt.root; growisofs -dvd-compat -udf -iso-level 3 -Z /dev/cd0 -J -R /path/to/data When an ISO image already contains large files, no additional options are required for &man.growisofs.1; to burn that image on a disk. Be sure to use an up-to-date version of sysutils/cdrtools, which contains &man.mkisofs.8;, as an older version may not contain large files support. If the latest version does not work, install sysutils/cdrtools-devel and read its &man.mkisofs.8;. Burning a DVD-Video DVD DVD-Video A DVD-Video is a specific file layout based on the ISO 9660 and micro-UDF (M-UDF) specifications. Since DVD-Video presents a specific data structure hierarchy, a particular program such as multimedia/dvdauthor is needed to author the DVD. If an image of the DVD-Video file system already exists, it can be burned in the same way as any other image. If dvdauthor was used to make the DVD and the result is in /path/to/video, the following command should be used to burn the DVD-Video: &prompt.root; growisofs -Z /dev/cd0 -dvd-video /path/to/video is passed to &man.mkisofs.8; to instruct it to create a DVD-Video file system layout. This option implies the &man.growisofs.1; option. Using a DVD+RW DVD DVD+RW Unlike CD-RW, a virgin DVD+RW needs to be formatted before first use. It is recommended to let &man.growisofs.1; take care of this automatically whenever appropriate. However, it is possible to use dvd+rw-format to format the DVD+RW: &prompt.root; dvd+rw-format /dev/cd0 Only perform this operation once and keep in mind that only virgin DVD+RW medias need to be formatted. Once formatted, the DVD+RW can be burned as usual. To burn a totally new file system and not just append some data onto a DVD+RW, the media does not need to be blanked first. Instead, write over the previous recording like this: &prompt.root; growisofs -Z /dev/cd0 -J -R /path/to/newdata The DVD+RW format supports appending data to a previous recording. This operation consists of merging a new session to the existing one as it is not considered to be multi-session writing. &man.growisofs.1; will grow the ISO 9660 file system present on the media. For example, to append data to a DVD+RW, use the following: &prompt.root; growisofs -M /dev/cd0 -J -R /path/to/nextdata The same &man.mkisofs.8; options used to burn the initial session should be used during next writes. Use for better media compatibility with DVD-ROM drives. When using DVD+RW, this option will not prevent the addition of data. To blank the media, use: &prompt.root; growisofs -Z /dev/cd0=/dev/zero Using a DVD-RW DVD DVD-RW A DVD-RW accepts two disc formats: incremental sequential and restricted overwrite. By default, DVD-RW discs are in sequential format. A virgin DVD-RW can be directly written without being formatted. However, a non-virgin DVD-RW in sequential format needs to be blanked before writing a new initial session. To blank a DVD-RW in sequential mode: &prompt.root; dvd+rw-format -blank=full /dev/cd0 A full blanking using will take about one hour on a 1x media. A fast blanking can be performed using , if the DVD-RW will be recorded in Disk-At-Once (DAO) mode. To burn the DVD-RW in DAO mode, use the command: &prompt.root; growisofs -use-the-force-luke=dao -Z /dev/cd0=imagefile.iso Since &man.growisofs.1; automatically attempts to detect fast blanked media and engage DAO write, should not be required. One should instead use restricted overwrite mode with any DVD-RW as this format is more flexible than the default of incremental sequential. To write data on a sequential DVD-RW, use the same instructions as for the other DVD formats: &prompt.root; growisofs -Z /dev/cd0 -J -R /path/to/data To append some data to a previous recording, use with &man.growisofs.1;. However, if data is appended on a DVD-RW in incremental sequential mode, a new session will be created on the disc and the result will be a multi-session disc. A DVD-RW in restricted overwrite format does not need to be blanked before a new initial session. Instead, overwrite the disc with . It is also possible to grow an existing ISO 9660 file system written on the disc with . The result will be a one-session DVD. To put a DVD-RW in restricted overwrite format, the following command must be used: &prompt.root; dvd+rw-format /dev/cd0 To change back to sequential format, use: &prompt.root; dvd+rw-format -blank=full /dev/cd0 Multi-Session Few DVD-ROM drives support multi-session DVDs and most of the time only read the first session. DVD+R, DVD-R and DVD-RW in sequential format can accept multiple sessions. The notion of multiple sessions does not exist for the DVD+RW and the DVD-RW restricted overwrite formats. Using the following command after an initial non-closed session on a DVD+R, DVD-R, or DVD-RW in sequential format, will add a new session to the disc: &prompt.root; growisofs -M /dev/cd0 -J -R /path/to/nextdata Using this command with a DVD+RW or a DVD-RW in restricted overwrite mode will append data while merging the new session to the existing one. The result will be a single-session disc. Use this method to add data after an initial write on these types of media. Since some space on the media is used between each session to mark the end and start of sessions, one should add sessions with a large amount of data to optimize media space. The number of sessions is limited to 154 for a DVD+R, about 2000 for a DVD-R, and 127 for a DVD+R Double Layer. For More Information To obtain more information about a DVD, use dvd+rw-mediainfo /dev/cd0 while the disc in the specified drive. More information about dvd+rw-tools can be found in &man.growisofs.1;, on the dvd+rw-tools web site, and in the cdwrite mailing list archives. When creating a problem report related to the use of dvd+rw-tools, always include the output of dvd+rw-mediainfo. Using a DVD-RAM DVD DVD-RAM Configuration DVD-RAM writers can use either a SCSI or ATAPI interface. For ATAPI devices, DMA access has to be enabled by adding the following line to /boot/loader.conf: hw.ata.atapi_dma="1" Preparing the Media A DVD-RAM can be seen as a removable hard drive. Like any other hard drive, the DVD-RAM must be formatted before it can be used. In this example, the whole disk space will be formatted with a standard UFS2 file system: &prompt.root; dd if=/dev/zero of=/dev/acd0 bs=2k count=1 &prompt.root; bsdlabel -Bw acd0 &prompt.root; newfs /dev/acd0 The DVD device, acd0, must be changed according to the configuration. Using the Media Once the DVD-RAM has been formatted, it can be mounted as a normal hard drive: &prompt.root; mount /dev/acd0 /mnt Once mounted, the DVD-RAM will be both readable and writeable. Creating and Using Floppy Disks This section explains how to format a 3.5 inch floppy disk in &os;. Steps to Format a Floppy A floppy disk needs to be low-level formatted before it can be used. This is usually done by the vendor, but formatting is a good way to check media integrity. To low-level format the floppy disk on &os;, use &man.fdformat.1;. When using this utility, make note of any error messages, as these can help determine if the disk is good or bad. To format the floppy, insert a new 3.5 inch floppy disk into the first floppy drive and issue: &prompt.root; /usr/sbin/fdformat -f 1440 /dev/fd0 After low-level formatting the disk, create a disk label as it is needed by the system to determine the size of the disk and its geometry. The supported geometry values are listed in /etc/disktab. To write the disk label, use &man.bsdlabel.8;: &prompt.root; /sbin/bsdlabel -B -w /dev/fd0 fd1440 The floppy is now ready to be high-level formatted with a file system. The floppy's file system can be either UFS or FAT, where FAT is generally a better choice for floppies. To format the floppy with FAT, issue: &prompt.root; /sbin/newfs_msdos /dev/fd0 The disk is now ready for use. To use the floppy, mount it with &man.mount.msdosfs.8;. One can also install and use emulators/mtools from the Ports Collection. Creating and Using Data Tapes tape media Tape technology has continued to evolve but is less likely to be used in a modern system. Modern backup systems tend to use off site combined with local removable disk drive technologies. Still, &os; will support any tape drive that uses SCSI, such as LTO and older devices such as DAT. There is limited support for SATA and USB tape drives. Serial Access with &man.sa.4; tape drives &os; uses the &man.sa.4; driver, providing /dev/sa0, /dev/nsa0, and /dev/esa0. In normal use, only /dev/sa0 is needed. /dev/nsa0 is the same physical drive as /dev/sa0 but does not rewind the tape after writing a file. This allows writing more than one file to a tape. Using /dev/esa0 ejects the tape after the device is closed, if applicable. Controlling the Tape Drive with &man.mt.1; tape media mt &man.mt.1; is the &os; utility for controlling other operations of the tape drive, such as seeking through files on a tape or writing tape control marks to the tape. For example, the first three files on a tape can be preserved by skipping past them before writing a new file: &prompt.root; mt -f /dev/nsa0 fsf 3 Using &man.tar.1; to Read and Write Tape Backups An example of writing a single file to tape using &man.tar.1;: &prompt.root; tar cvf /dev/sa0 file Recovering files from a &man.tar.1; archive on tape into the current directory: &prompt.root; tar xvf /dev/sa0 Using &man.dump.8; and &man.restore.8; to Create and Restore Backups A simple backup of /usr with &man.dump.8;: &prompt.root; dump -0aL -b64 -f /dev/nsa0 /usr Interactively restoring files from a &man.dump.8; file on tape into the current directory: &prompt.root; restore -i -f /dev/nsa0 Other Tape Software Higher-level programs are available to simplify tape backup. The most popular are Amanda and Bacula. These programs aim to make backups easier and more convenient, or to automate complex backups of multiple machines. The Ports Collection contains both these and other tape utility applications. Backup Basics Implementing a backup plan is essential in order to have the ability to recover from disk failure, accidental file deletion, random file corruption, or complete machine destruction, including destruction of on-site backups. The backup type and schedule will vary, depending upon the importance of the data, the granularity needed for file restores, and the amount of acceptable downtime. Some possible backup techniques include: Archives of the whole system, backed up onto permanent, off-site media. This provides protection against all of the problems listed above, but is slow and inconvenient to restore from, especially for non-privileged users. File system snapshots, which are useful for restoring deleted files or previous versions of files. Copies of whole file systems or disks which are sychronized with another system on the network using a scheduled net/rsync. Hardware or software RAID, which minimizes or avoids downtime when a disk fails. Typically, a mix of backup techniques is used. For example, one could create a schedule to automate a weekly, full system backup that is stored off-site and to supplement this backup with hourly ZFS snapshots. In addition, one could make a manual backup of individual directories or files before making file edits or deletions. This section describes some of the utilities which can be used to create and manage backups on a &os; system. File System Backups backup software dump / restore dump restore The traditional &unix; programs for backing up a file system are &man.dump.8;, which creates the backup, and &man.restore.8;, which restores the backup. These utilities work at the disk block level, below the abstractions of the files, links, and directories that are created by file systems. Unlike other backup software, dump backs up an entire file system and is unable to backup only part of a file system or a directory tree that spans multiple file systems. Instead of writing files and directories, dump writes the raw data blocks that comprise files and directories. If dump is used on the root directory, it will not back up /home, /usr or many other directories since these are typically mount points for other file systems or symbolic links into those file systems. When used to restore data, restore stores temporary files in /tmp/ by default. When using a recovery disk with a small /tmp, set TMPDIR to a directory with more free space in order for the restore to succeed. When using dump, be aware that some quirks remain from its early days in Version 6 of AT&T &unix;,circa 1975. The default parameters assume a backup to a 9-track tape, rather than - to another media or the high-density tapes available today. + to another type of media or to the high-density tapes available today. These defaults must be overridden on the command line. .rhosts It is possible to backup a file system across the network to a another system or to a tape drive attached to another computer. While the &man.rdump.8; and &man.rrestore.8; utilities can be used for this purpose, they are not considered to be secure. Instead, one can use dump and restore in a more secure fashion over an SSH connection. This example creates a full, compressed backup of the /usr file system and sends the backup file to the specified host over a SSH connection. Using <command>dump</command> over <application>ssh</application> &prompt.root; /sbin/dump -0uan -f - /usr | gzip -2 | ssh -c blowfish \ targetuser@targetmachine.example.com dd of=/mybigfiles/dump-usr-l0.gz This example sets RSH in order to write the the backup to a tape drive on a remote system over a SSH connection: Using <command>dump</command> over <application>ssh</application> with <envar>RSH</envar> Set &prompt.root; env RSH=/usr/bin/ssh /sbin/dump -0uan -f targetuser@targetmachine.example.com:/dev/sa0 /usr Directory Backups backup software tar Several built-in utilities are available for backing up and restoring specified files and directories as needed. A good choice for making a backup of all of the files in a directory is &man.tar.1;. This utility dates back to Version 6 of AT&T &unix; and by default assumes a recursive backup to a local tape device. Switches can be used to instead specify the name of a backup file. tar This example creates a compressed backup of the current directory and saves it to /tmp/mybackup.tgz. When creating a backup file, make sure that the backup is not saved to the same directory that is being backed up. Backing Up the Current Directory With <command>tar</command> &prompt.root; tar czvf /tmp/mybackup.tgz . To restore the entire backup, cd into the directory to restore into and specify the name of the backup. Note that this will overwrite any newer versions of files in the restore directory. When in doubt, restore to a temporary directory or specify the name of the file within the backup to restore. Restoring Up the Current Directory With <command>tar</command> &prompt.root; tar xzvf /tmp/mybackup.tgz There are dozens of available switches which are described in &man.tar.1;. This utility also supports the use of exclude patterns to specify which files should not be included when backing up the specified directory or restoring files from a backup. backup software cpio To create a backup using a specified list of files and directories, &man.cpio.1; is a good choice. Unlike tar, cpio does not know how to walk the directory tree and it must be provided the list of files to backup. For example, a list of files can be created using ls or find. This example creates a recursive listing of the current directory which is then piped to cpio in order to create an output backup file named /tmp/mybackup.cpio. Using<command>ls</command> and <command>cpio</command> to Make a Recursive Backup of the Current Directory &prompt.root; ls -R | cpio -ovF /tmp/mybackup.cpio backup software pax pax POSIX IEEE A backup utility which tries to bridge the features provided by tar and cpio is &man.pax.1;. Over the years, the various versions of tar and cpio became slightly incompatible. &posix; created pax which attempts to read and write many of the various cpio and tar formats, plus new formats of its own. The pax equivalent to the previous examples would be: Backing Up the Current Directory With <command>pax</command> &prompt.root; pax -wf /tmp/mybackup.pax . - <application>Amanda</application> + Third-Party Backup Utilities backup software - Amanda - - - Amanda - - Amanda (Advanced Maryland - Network Disk Archiver) is a client/server backup system, - rather than a single program. An - Amanda server will backup to a - single tape drive any number of computers that have - Amanda clients and a network - connection to the Amanda server. A - common problem at sites with a number of large disks is that - the length of time required to backup to data directly to tape - exceeds the amount of time available for the task. - Amanda solves this problem by using - a holding disk to backup several file systems - at the same time. Amanda creates - archive sets: a group of tapes used over a - period of time to create full backups of all the file systems - listed in Amanda's configuration - file. The archive set also contains nightly - incremental, or differential, backups of all the file systems. - Restoring a damaged file system requires the most recent full - backup and the incremental backups. - - The configuration file provides fine grained control of - backups and the network traffic that - Amanda generates. - Amanda will use any of the above - backup programs to write the data to tape. - Amanda is not installed by - but is available as either a port or package. + The &os; Ports Collection provides many third-party + utilities which can be used to schedule the creation of + backups. Many of these applications are client/server based + and can be used to automate the backups of a single system or + all of the computers in a network. + + Popular utilities include + Amanda, + Bacula, + rsync, and + duplicity. + - Emergency Restore Procedure - - - Before the Disaster + Emergency Recovery - There are four steps which should be performed in - preparation for any disaster that may occur. + In addition to regular backups, it is recommended to + perform the following steps as part of an emergency + preparedness plan. bsdlabel - First, print the bsdlabel of each disk using a command - such as bsdlabel da0 | lpr. Also print a - copy of /etc/fstab and all boot - messages. + Create a print copy of the output of the following + commands: + + + + gpart show + + + + more /etc/fstab + + + + dmesg + + livefs CD - Second, burn a livefs CD. This CD - contains support for booting into a &os; - livefs rescue mode, allowing the user to - perform many tasks like running &man.dump.8;, - &man.restore.8;, &man.fdisk.8;, &man.bsdlabel.8;, - &man.newfs.8;, &man.mount.8;, and more. The livefs CD image - for &os;/&arch.i386; &rel2.current;-RELEASE is - available from ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/&arch.i386;/ISO-IMAGES/&rel2.current;/&os;-&rel2.current;-RELEASE-&arch.i386;-livefs.iso. + Store this printout and a copy of the installation media + in a secure location. Should an emergency restore be + needed, boot into the installation media and select + Live CD to access a rescue shell. This + rescue mode can be used to view the current state of the + system, and if needed, to reformat disks and restore data + from backups. - Livefs CD images are not available for - &os; &rel.current;-RELEASE and later. In addition to - the CD-ROM installation images, flash drive installation - images may be used to recover a system. The - memstick image for - &os;/&arch.i386; &rel.current;-RELEASE is available - from ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/&arch.i386;/&arch.i386;/ISO-IMAGES/&rel.current;/&os;-&rel.current;-RELEASE-&arch.i386;-memstick.img. + The installation media + for &os;/&arch.i386; &rel2.current;-RELEASE does not + include a rescue shell. For this version, instead + download and burn a Livefs CD image from ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/&arch.i386;/ISO-IMAGES/&rel2.current;/&os;-&rel2.current;-RELEASE-&arch.i386;-livefs.iso. - Third, create backup tapes regularly. Any changes that - made after the last backup may be irretrievably lost. - Write-protect the backup media. - - Fourth, test the livefs CD and the + Next, test the rescue shell and the backups. Make notes of the procedure. Store these notes - with the CD, the printouts, and the backups. These notes + with the media, the printouts, and the backups. These notes may prevent the inadvertent destruction of the backups while under the stress of performing an emergency recovery. - For an added measure of security, store an extra - livefs CD and the latest backup at a - remote location, where a remote location is - not the basement of the same building. - A remote location should be physically separated from the + For an added measure of security, store the latest backup at a + remote location which is + physically separated from the computers and disk drives by a significant distance. - - - - After the Disaster - - First, determine if the hardware survived. Thanks - to regular, off-site backups, there is no need to worry - about the software. - - If the hardware has been damaged, the parts should be - replaced before attempting to use the computer. - - If the hardware is okay, insert the - livefs CD and boot the computer. The - original install menu will be displayed on the screen. - Select the correct country, then choose - Fixit -- Repair mode with CD-ROM/DVD/floppy or - start a shell. then select - CD-ROM/DVD -- Use the live file system - CD-ROM/DVD. - restore and the other needed programs - are located in /mnt2/rescue. - - Recover each file system separately. - - - mount - - root partition - - bsdlabel - - - newfs - - - Try to mount the root partition - of the first disk using mount /dev/da0a - /mnt. If the bsdlabel was damaged, use - bsdlabel to re-partition and label the - disk to match the label that was printed and saved. Use - newfs to re-create the file systems. - Re-mount the root partition of the disk read-write using - mount -u -o rw /mnt. Use the backups - to recover the data for this file system. Unmount the file - system with umount /mnt. Repeat for each - file system that was damaged. - - Once the system is running, backup the data onto new - media as whatever caused the crash or data loss may strike - again. Another hour spent now may save further distress - later. - Network, Memory, and File-Backed File Systems Marc Fonvieille Reorganized and enhanced by virtual disks disks virtual In addition to physical disks such as floppies, CDs, and hard drives, &os; also supports virtual disks. NFS Coda disks memory These include network file systems such as the Network File System and Coda, memory-based file systems, and file-backed file systems. According to the &os; version, the tools used for the creation and use of file-backed and memory-based file systems differ. Use &man.devfs.5; to allocate device nodes transparently for the user. File-Backed File System disks file-backed &man.mdconfig.8; is used to configure and enable memory disks, &man.md.4;, under &os;. To use &man.mdconfig.8;, &man.md.4; must be first loaded. When using a custom kernel configuration file, ensure it includes this line: device md &man.mdconfig.8; supports several types of memory backed virtual disks: memory disks allocated with &man.malloc.9; and memory disks using a file or swap space as backing. One possible use is the mounting of CD images. To mount an existing file system image: Using <command>mdconfig</command> to Mount an Existing File System Image &prompt.root; mdconfig -a -t vnode -f diskimage -u 0 &prompt.root; mount /dev/md0 /mnt To create a new file system image with &man.mdconfig.8;: Creating a New File-Backed Disk with <command>mdconfig</command> &prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; mdconfig -a -t vnode -f newimage -u 0 &prompt.root; bsdlabel -w md0 auto &prompt.root; newfs md0a /dev/md0a: 5.0MB (10224 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.25MB, 80 blks, 192 inodes. super-block backups (for fsck -b #) at: 160, 2720, 5280, 7840 &prompt.root; mount /dev/md0a /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0a 4710 4 4330 0% /mnt If unit number is not specified with , &man.mdconfig.8; uses the &man.md.4; automatic allocation to select an unused device. The name of the allocated unit will be output to stdout, such as md4. Refer to &man.mdconfig.8; for more details about. While &man.mdconfig.8; is useful, it takes several command lines to create a file-backed file system. &os; also comes with &man.mdmfs.8; which automatically configures a &man.md.4; disk using &man.mdconfig.8;, puts a UFS file system on it using &man.newfs.8;, and mounts it using &man.mount.8;. For example, to create and mount the same file system image as above, type the following: Configure and Mount a File-Backed Disk with <command>mdmfs</command> &prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; mdmfs -F newimage -s 5m md0 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0 4718 4 4338 0% /mnt When is used without a unit number, &man.mdmfs.8; uses the &man.md.4; auto-unit feature to automatically select an unused device. For more details about &man.mdmfs.8;, refer to its manual page. Memory-Based File System disks memory file system For a memory-based file system, swap backing should normally be used. This does not mean that the memory disk will be swapped out to disk by default, but rather that the memory disk will be allocated from a memory pool which can be swapped out to disk if needed. It is also possible to create memory-based disks which are &man.malloc.9; backed, but using large malloc backed memory disks can result in a system panic if the kernel runs out of memory. Creating a New Memory-Based Disk with <command>mdconfig</command> &prompt.root; mdconfig -a -t swap -s 5m -u 1 &prompt.root; newfs -U md1 /dev/md1: 5.0MB (10240 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.27MB, 81 blks, 192 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 2752, 5344, 7936 &prompt.root; mount /dev/md1 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md1 4718 4 4338 0% /mnt Creating a New Memory-Based Disk with <command>mdmfs</command> &prompt.root; mdmfs -s 5m md2 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md2 4846 2 4458 0% /mnt Detaching a Memory Disk from the System disks detaching a memory disk When a memory-based or file-based file system is no longer in use, its resources should be released back to the system. First, unmount the file system, then use &man.mdconfig.8; to detach the disk from the system and release the resources. For example, to detach and free all resources used by /dev/md4: &prompt.root; mdconfig -d -u 4 It is possible to list information about configured &man.md.4; devices by running mdconfig -l. File System Snapshots Tom Rhodes Contributed by file systems snapshots &os; offers a feature in conjunction with Soft Updates: file system snapshots. UFS snapshots allow a user to create images of specified file systems, and treat them as a file. Snapshot files must be created in the file system that the action is performed on, and a user may create no more than 20 snapshots per file system. Active snapshots are recorded in the superblock so they are persistent across unmount and remount operations along with system reboots. When a snapshot is no longer required, it can be removed using &man.rm.1;. While snapshots may be removed in any order, all the used space may not be acquired because another snapshot will possibly claim some of the released blocks. The un-alterable file flag is set by &man.mksnap.ffs.8; after initial creation of a snapshot file. &man.unlink.1; makes an exception for snapshot files since it allows them to be removed. Snapshots are created using &man.mount.8;. To place a snapshot of /var in the file /var/snapshot/snap, use the following command: &prompt.root; mount -u -o snapshot /var/snapshot/snap /var Alternatively, use &man.mksnap.ffs.8; to create the snapshot: &prompt.root; mksnap_ffs /var /var/snapshot/snap One can find snapshot files on a file system, such as /var, using &man.find.1;: &prompt.root; find /var -flags snapshot Once a snapshot has been created, it has several uses: Some administrators will use a snapshot file for backup purposes, because the snapshot can be transferred to CDs or tape. The file system integrity checker, &man.fsck.8;, may be run on the snapshot. Assuming that the file system was clean when it was mounted, this should always provide a clean and unchanging result. Running &man.dump.8; on the snapshot will produce a dump file that is consistent with the file system and the timestamp of the snapshot. &man.dump.8; can also take a snapshot, create a dump image, and then remove the snapshot in one command by using . The snapshot can be mounted as a frozen image of the file system. To &man.mount.8; the snapshot /var/snapshot/snap run: &prompt.root; mdconfig -a -t vnode -f /var/snapshot/snap -u 4 &prompt.root; mount -r /dev/md4 /mnt The frozen /var is now available through /mnt. Everything will initially be in the same state it was during the snapshot creation time. The only exception is that any earlier snapshots will appear as zero length files. To unmount the snapshot, use: &prompt.root; umount /mnt &prompt.root; mdconfig -d -u 4 For more information about and file system snapshots, including technical papers, visit Marshall Kirk McKusick's website at http://www.mckusick.com/. File System Quotas accounting disk space disk quotas Quotas are an optional feature of the operating system that can be used to limit the amount of disk space or the number of files a user or members of a group may allocate on a per-file system basis. This is used most often on timesharing systems where it is desirable to limit the amount of resources any one user or group of users may allocate. This prevents one user or group of users from consuming all of the available disk space. Configuring the System to Enable Disk Quotas Before using disk quotas, quota support must be added to the kernel by adding the following line to the kernel configuration file: options QUOTA Before &os; 9.2, the GENERIC kernel usually did not include this option. sysctl kern.features.ufs_quota can be used to test whether the current kernel supports quotas. If the option is not present, a custom kernel must be compiled. Refer to for more information on kernel configuration. Next, enable disk quotas in /etc/rc.conf: quota_enable="YES" disk quotas checking For finer control over quota startup, an additional configuration variable is available. Normally on bootup, the quota integrity of each file system is checked by &man.quotacheck.8;. This program insures that the data in the quota database properly reflects the data on the file system. This is a time consuming process that will significantly affect the time the system takes to boot. To skip this step, add this variable to /etc/rc.conf: check_quotas="NO" Finally, edit /etc/fstab to enable disk quotas on a per-file system basis. This is when user or group quotas can be enabled on the file systems. To enable per-user quotas on a file system, add to the options field in the /etc/fstab entry for the file system to enable quotas on. For example: /dev/da1s2g /home ufs rw,userquota 1 2 To enable group quotas, instead use . To enable both user and group quotas, change the entry as follows: /dev/da1s2g /home ufs rw,userquota,groupquota 1 2 By default, the quota files are stored in the root directory of the file system as quota.user and quota.group. Refer to &man.fstab.5; for more information. Even though an alternate location for the quota files can be specified, this is not recommended because the various quota utilities do not seem to handle this properly. Once the configuration is complete, reboot the system with the new kernel. /etc/rc will automatically run the appropriate commands to create the initial quota files for all of the quotas enabled in /etc/fstab. There is no need to manually create any zero length quota files. In the normal course of operations, there should be no need to manually run &man.quotacheck.8;, &man.quotaon.8;, or &man.quotaoff.8;. However, one should read their manual pages to be familiar with their operation. Setting Quota Limits disk quotas limits Once the system has been configured to enable quotas, verify they really are enabled by running: &prompt.root; quota -v There should be a one line summary of disk usage and current quota limits for each file system that quotas are enabled on. The system is now ready to be assigned quota limits with &man.edquota.8;. Several options are available to enforce limits on the amount of disk space a user or group may allocate, and how many files they may create. Allocations can be limited based on disk space (block quotas), number of files (inode quotas), or a combination of both. Each limits is further broken down into two categories: hard and soft limits. hard limit A hard limit may not be exceeded. Once a user reaches a hard limit, no further allocations can be made on that file system by that user. For example, if the user has a hard limit of 500 kbytes on a file system and is currently using 490 kbytes, the user can only allocate an additional 10 kbytes. Attempting to allocate an additional 11 kbytes will fail. soft limit Soft limits can be exceeded for a limited amount of time, known as the grace period, which is one week by default. If a user stays over their limit longer than the grace period, the soft limit turns into a hard limit and no further allocations are allowed. When the user drops back below the soft limit, the grace period is reset. The following is an example output from &man.edquota.8;. When &man.edquota.8; is invoked, the editor specified by EDITOR is opened in order to edit the quota limits. The default editor is set to vi. &prompt.root; edquota -u test Quotas for user test: /usr: kbytes in use: 65, limits (soft = 50, hard = 75) inodes in use: 7, limits (soft = 50, hard = 60) /usr/var: kbytes in use: 0, limits (soft = 50, hard = 75) inodes in use: 0, limits (soft = 50, hard = 60) There are normally two lines for each file system that has quotas enabled. One line represents the block limits and the other represents the inode limits. Change the value to modify the quota limit. For example, to raise this user's block limit from a soft limit of 50 and a hard limit of 75 to a soft limit of 500 and a hard limit of 600, change: /usr: kbytes in use: 65, limits (soft = 50, hard = 75) to: /usr: kbytes in use: 65, limits (soft = 500, hard = 600) The new quota limits take affect upon exiting the editor. Sometimes it is desirable to set quota limits on a range of UIDs. This can be done by passing to &man.edquota.8;. First, assign the desired quota limit to a user, then run edquota -p protouser startuid-enduid. For example, if test has the desired quota limits, the following command will duplicate those quota limits for UIDs 10,000 through 19,999: &prompt.root; edquota -p test 10000-19999 For more information, refer to &man.edquota.8;. Checking Quota Limits and Disk Usage disk quotas checking Either &man.quota.1; or &man.repquota.8; can be used to check quota limits and disk usage. To check individual user or group quotas and disk usage, use &man.quota.1;. A user may only examine their own quota and the quota of a group they are a member of. Only the superuser may view all user and group quotas. To get a summary of all quotas and disk usage for file systems with quotas enabled, use &man.repquota.8;. The following is sample output from quota -v for a user that has quota limits on two file systems. Disk quotas for user test (uid 1002): Filesystem usage quota limit grace files quota limit grace /usr 65* 50 75 5days 7 50 60 /usr/var 0 50 75 0 50 60 grace period In this example, the user is currently 15 kbytes over the soft limit of 50 kbytes on /usr and has 5 days of grace period left. The asterisk * indicates that the user is currently over the quota limit. Normally, file systems that the user is not using any disk space on will not show in the output of &man.quota.1;, even if the user has a quota limit assigned for that file system. Use to display those file systems, such as /usr/var in the above example. Quotas over NFS NFS Quotas are enforced by the quota subsystem on the NFS server. The &man.rpc.rquotad.8; daemon makes quota information available to &man.quota.1; on NFS clients, allowing users on those machines to see their quota statistics. Enable rpc.rquotad in /etc/inetd.conf like so: rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad Now restart inetd: &prompt.root; service inetd restart Encrypting Disk Partitions Lucky Green Contributed by
shamrock@cypherpunks.to
disks encrypting &os; offers excellent online protections against unauthorized data access. File permissions and Mandatory Access Control (MAC) help prevent unauthorized users from accessing data while the operating system is active and the computer is powered up. However, the permissions enforced by the operating system are irrelevant if an attacker has physical access to a computer and can move the computer's hard drive to another system to copy and analyze the data. Regardless of how an attacker may have come into possession of a hard drive or powered-down computer, both the GEOM Based Disk Encryption (gbde) and geli cryptographic subsystems in &os; are able to protect the data on the computer's file systems against even highly-motivated attackers with significant resources. Unlike cumbersome encryption methods that encrypt only individual files, gbde and geli transparently encrypt entire file systems. No cleartext ever touches the hard drive's platter. Disk Encryption with <application>gbde</application> Configuring gbde requires superuser privileges. &prompt.user; su - Password: If using a custom kernel configuration file, ensure it contains this line: options GEOM_BDE If the kernel already contains this support, use kldload to load &man.gbde.4;: &prompt.root; kldload geom_bde Preparing the Encrypted Hard Drive The following example demonstrates adding a new hard drive to a system that will hold a single encrypted partition. This partition will be mounted as /private. gbde can also be used to encrypt /home and /var/mail, but this requires more complex instructions which exceed the scope of this introduction. Add the New Hard Drive Install the new drive to the system as explained in . For the purposes of this example, a new hard drive partition has been added as /dev/ad4s1c and /dev/ad0s1* represents the existing standard &os; partitions. &prompt.root; ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 Create a Directory to Hold <command>gbde</command> Lock Files &prompt.root; mkdir /etc/gbde The gbde lock file contains information that gbde requires to access encrypted partitions. Without access to the lock file, gbde will not be able to decrypt the data contained in the encrypted partition without significant manual intervention which is not supported by the software. Each encrypted partition uses a separate lock file. Initialize the <command>gbde</command> Partition A gbde partition must be initialized before it can be used. This initialization needs to be performed only once: &prompt.root; gbde init /dev/ad4s1c -i -L /etc/gbde/ad4s1c.lock &man.gbde.8; will open the default editor, in order to set various configuration options in a template. For use with UFS1 or UFS2, set the sector_size to 2048: # $FreeBSD: src/sbin/gbde/template.txt,v 1.1.36.1 2009/08/03 08:13:06 kensmith Exp $ # # Sector size is the smallest unit of data which can be read or written. # Making it too small decreases performance and decreases available space. # Making it too large may prevent filesystems from working. 512 is the # minimum and always safe. For UFS, use the fragment size # sector_size = 2048 [...] &man.gbde.8; will ask the user twice to type the passphrase used to secure the data. The passphrase must be the same both times. The ability of gbde to protect data depends entirely on the quality of the passphrase. For tips on how to select a secure passphrase that is easy to remember, see the Diceware Passphrase website. gbde initcreates a lock file for the gbde partition. In this example, it is stored as /etc/gbde/ad4s1c.lock. gbde lock files must end in .lock in order to be correctly detected by the /etc/rc.d/gbde start up script. gbde lock files must be backed up together with the contents of any encrypted partitions. While deleting a lock file alone cannot prevent a determined attacker from decrypting a gbde partition, without the lock file, the legitimate owner will be unable to access the data on the encrypted partition without a significant amount of work that is totally unsupported by &man.gbde.8;. Attach the Encrypted Partition to the Kernel &prompt.root; gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock This command will prompt to input the passphrase that was selected during the initialization of the encrypted partition. The new encrypted device will appear in /dev as /dev/device_name.bde: &prompt.root; ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 /dev/ad4s1c.bde Create a File System on the Encrypted Device Once the encrypted device has been attached to the kernel, a file system can be created on the device using &man.newfs.8;. This example creates a UFS2 file system with soft updates enabled. &prompt.root; newfs -U /dev/ad4s1c.bde &man.newfs.8; must be performed on an attached gbde partition which is identified by a *.bde extension to the device name. Mount the Encrypted Partition Create a mount point for the encrypted file system: &prompt.root; mkdir /private Mount the encrypted file system: &prompt.root; mount /dev/ad4s1c.bde /private Verify That the Encrypted File System is Available The encrypted file system should now be visible to &man.df.1; and be available for use. &prompt.user; df -H Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 1037M 72M 883M 8% / /devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 8.1G 55K 7.5G 0% /home /dev/ad0s1e 1037M 1.1M 953M 0% /tmp /dev/ad0s1d 6.1G 1.9G 3.7G 35% /usr /dev/ad4s1c.bde 150G 4.1K 138G 0% /private Mounting Existing Encrypted File Systems After each boot, any encrypted file systems must be re-attached to the kernel, checked for errors, and mounted, before the file systems can be used. The required commands must be executed as root. Attach the <command>gbde</command> Partition to the Kernel &prompt.root; gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock This command will prompt for the passphrase that was selected during initialization of the encrypted gbde partition. Check the File System for Errors Since encrypted file systems cannot yet be listed in /etc/fstab for automatic mounting, the file systems must be checked for errors by running &man.fsck.8; manually before mounting: &prompt.root; fsck -p -t ffs /dev/ad4s1c.bde Mount the Encrypted File System &prompt.root; mount /dev/ad4s1c.bde /private The encrypted file system is now available for use. Automatically Mounting Encrypted Partitions It is possible to create a script to automatically attach, check, and mount an encrypted partition, but for security reasons the script should not contain the &man.gbde.8; password. Instead, it is recommended that such scripts be run manually while providing the password via the console or &man.ssh.1;. As an alternative, an rc.d script is provided. Arguments for this script can be passed via &man.rc.conf.5;: gbde_autoattach_all="YES" gbde_devices="ad4s1c" gbde_lockdir="/etc/gbde" This requires that the gbde passphrase be entered at boot time. After typing the correct passphrase, the gbde encrypted partition will be mounted automatically. This can be useful when using gbde on laptops. Cryptographic Protections Employed by <command>gbde</command> &man.gbde.8; encrypts the sector payload using 128-bit AES in CBC mode. Each sector on the disk is encrypted with a different AES key. For more information on the cryptographic design, including how the sector keys are derived from the user-supplied passphrase, refer to &man.gbde.4;. Compatibility Issues &man.sysinstall.8; is incompatible with gbde-encrypted devices. All *.bde devices must be detached from the kernel before starting &man.sysinstall.8; or it will crash during its initial probing for devices. To detach the encrypted device used in the example, use the following command: &prompt.root; gbde detach /dev/ad4s1c Disk Encryption with <command>geli</command> Daniel Gerzo Contributed by An alternative cryptographic GEOM class is available through &man.geli.8;. geli differs from gbde; offers different features, and uses a different scheme for doing cryptographic work. &man.geli.8; provides the following features: Utilizes the &man.crypto.9; framework and, when cryptographic hardware is available, geli uses it automatically. Supports multiple cryptographic algorithms such as AES, Blowfish, and 3DES. Allows the root partition to be encrypted. The passphrase used to access the encrypted root partition will be requested during system boot. Allows the use of two independent keys such as a key and a company key. geli is fast as it performs simple sector-to-sector encryption. Allows backup and restore of master keys. If a user destroys their keys, it is still possible to get access to the data by restoring keys from the backup. Allows a disk to attach with a random, one-time key which is useful for swap partitions and temporary file systems. More geli features can be found in &man.geli.8;. This section describes how to enable support for geli in the &os; kernel and explains how to create and use a geli encryption provider. Superuser privileges are required since modifications to the kernel are necessary. Adding <command>geli</command> Support to the Kernel For a custom kernel, ensure the kernel configuration file contains these lines: options GEOM_ELI device crypto Alternatively, the geli module can be loaded at boot time by adding the following line to /boot/loader.conf: geom_eli_load="YES" &man.geli.8; should now be supported by the kernel. Generating the Master Key The following example describes how to generate a key file which will be used as part of the master key for the encrypted provider mounted under /private. The key file will provide some random data used to encrypt the master key. The master key will also be protected by a passphrase. The provider's sector size will be 4kB. The example will describe how to attach to the geli provider, create a file system on it, mount it, work with it, and finally, how to detach it. It is recommended to use a bigger sector size, such as 4kB, for better performance. The master key will be protected with a passphrase and the data source for the key file will be /dev/random. The sector size of the provider /dev/da2.eli will be 4kB. &prompt.root; dd if=/dev/random of=/root/da2.key bs=64 count=1 &prompt.root; geli init -s 4096 -K /root/da2.key /dev/da2 Enter new passphrase: Reenter new passphrase: It is not mandatory to use both a passphrase and a key file as either method of securing the master key can be used in isolation. If the key file is given as -, standard input will be used. This example shows how more than one key file can be used: &prompt.root; cat keyfile1 keyfile2 keyfile3 | geli init -K - /dev/da2 Attaching the Provider with the Generated Key &prompt.root; geli attach -k /root/da2.key /dev/da2 Enter passphrase: The new plaintext device will be named /dev/da2.eli. &prompt.root; ls /dev/da2* /dev/da2 /dev/da2.eli Creating the New File System &prompt.root; dd if=/dev/random of=/dev/da2.eli bs=1m &prompt.root; newfs /dev/da2.eli &prompt.root; mount /dev/da2.eli /private The encrypted file system should now be visible to &man.df.1; and be available for use: &prompt.root; df -H Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 248M 89M 139M 38% / /devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 7.7G 2.3G 4.9G 32% /usr /dev/ad0s1d 989M 1.5M 909M 0% /tmp /dev/ad0s1e 3.9G 1.3G 2.3G 35% /var /dev/da2.eli 150G 4.1K 138G 0% /private Unmounting and Detaching the Provider Once the work on the encrypted partition is done, and the /private partition is no longer needed, it is prudent to consider unmounting and detaching the geli encrypted partition from the kernel: &prompt.root; umount /private &prompt.root; geli detach da2.eli More information about the use of &man.geli.8; can be found in its manual page. Using the <filename>geli</filename> <filename>rc.d</filename> Script geli comes with a rc.d script which can be used to simplify the usage of geli. An example of configuring geli through &man.rc.conf.5; follows: geli_devices="da2" geli_da2_flags="-p -k /root/da2.key" This configures /dev/da2 as a geli provider of which the master key file is located in /root/da2.key. geli will not use a passphrase when attaching to the provider if was given during the geli init phase. The system will detach the geli provider from the kernel before the system shuts down. More information about configuring rc.d is provided in the rc.d section of the Handbook. Encrypting Swap Space Christian Brüffer Written by swap encrypting Like the encryption of disk partitions, encryption of swap space is used to protect sensitive information. Consider an application that deals with passwords. As long as these passwords stay in physical memory, these passwords will not be written to disk and be cleared after a reboot. If &os; starts swapping out memory pages to free space for other applications, the passwords may be written to the disk platters unencrypted. Encrypting swap space can be a solution for this scenario. The &man.gbde.8; or &man.geli.8; encryption systems may be used for swap encryption. Both systems use the encswap rc.d script. For the remainder of this section, ad0s1b will be the swap partition. Swap partitions are not encrypted by default and should be cleared of any sensitive data before continuing. To overwrite the current swap parition with random garbage, execute the following command: &prompt.root; dd if=/dev/random of=/dev/ad0s1b bs=1m Swap Encryption with &man.gbde.8; The .bde suffix should be added to the device in the respective /etc/fstab swap line: # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b.bde none swap sw 0 0 Swap Encryption with &man.geli.8; The procedure for instead using &man.geli.8; for swap encryption is similar to that of using &man.gbde.8;. The .eli suffix should be added to the device in the respective /etc/fstab swap line: # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b.eli none swap sw 0 0 &man.geli.8; uses the AES algorithm with a key length of 128 bit by default. These defaults can be altered by using geli_swap_flags in /etc/rc.conf. The following line tells the encswap rc.d script to create &man.geli.8; swap partitions using the Blowfish algorithm with a key length of 128 bits and a sectorsize of 4 kilobytes, and sets detach on last close: geli_swap_flags="-e blowfish -l 128 -s 4096 -d" Refer to the description of onetime in &man.geli.8; for a list of possible options. Encrypted Swap Verification Once the system has rebooted, proper operation of the encrypted swap can be verified using swapinfo. If &man.gbde.8; is being used: &prompt.user; swapinfo Device 1K-blocks Used Avail Capacity /dev/ad0s1b.bde 542720 0 542720 0% If &man.geli.8; is being used: &prompt.user; swapinfo Device 1K-blocks Used Avail Capacity /dev/ad0s1b.eli 542720 0 542720 0% Highly Available Storage (HAST) Daniel Gerzo Contributed by Freddie Cash With inputs from Pawel Jakub Dawidek Michael W. Lucas Viktor Petersson HAST high availability Synopsis High availability is one of the main requirements in serious business applications and highly-available storage is a key component in such environments. Highly Available STorage, or HASTHighly Available STorage, was developed by &a.pjd.email; as a framework which allows transparent storage of the same data across several physically separated machines connected by a TCP/IP network. HAST can be understood as a network-based RAID1 (mirror), and is similar to the DRBD® storage system known from the GNU/&linux; platform. In combination with other high-availability features of &os; like CARP, HAST makes it possible to build a highly-available storage cluster that is resistant to hardware failures. After reading this section, you will know: What HAST is, how it works and which features it provides. How to set up and use HAST on &os;. How to integrate CARP and &man.devd.8; to build a robust storage system. Before reading this section, you should: Understand &unix; and &os; basics. Know how to configure network interfaces and other core &os; subsystems. Have a good understanding of &os; networking. The HAST project was sponsored by The &os; Foundation with support from OMCnet Internet Service GmbH and TransIP BV. HAST Features The main features of the HAST system are: Can be used to mask I/O errors on local hard drives. File system agnostic as it works with any file system supported by &os;. Efficient and quick resynchronization, synchronizing only blocks that were modified during the downtime of a node. Can be used in an already deployed environment to add additional redundancy. Together with CARP, Heartbeat, or other tools, it can be used to build a robust and durable storage system. HAST Operation As HAST provides a synchronous block-level replication of any storage media to several machines, it requires at least two physical machines: the primary, also known as the master node, and the secondary or slave node. These two machines together are referred to as a cluster. HAST is currently limited to two cluster nodes in total. Since HAST works in a primary-secondary configuration, it allows only one of the cluster nodes to be active at any given time. The primary node, also called active, is the one which will handle all the I/O requests to HAST-managed devices. The secondary node is automatically synchronized from the primary node. The physical components of the HAST system are: local disk on primary node, and disk on remote, secondary node. HAST operates synchronously on a block level, making it transparent to file systems and applications. HAST provides regular GEOM providers in /dev/hast/ for use by other tools or applications, thus there is no difference between using HAST-provided devices and raw disks or partitions. Each write, delete, or flush operation is sent to the local disk and to the remote disk over TCP/IP. Each read operation is served from the local disk, unless the local disk is not up-to-date or an I/O error occurs. In such case, the read operation is sent to the secondary node. Synchronization and Replication Modes HAST tries to provide fast failure recovery. For this reason, it is very important to reduce synchronization time after a node's outage. To provide fast synchronization, HAST manages an on-disk bitmap of dirty extents and only synchronizes those during a regular synchronization, with an exception of the initial sync. There are many ways to handle synchronization. HAST implements several replication modes to handle different synchronization methods: memsync: report write operation as completed when the local write operation is finished and when the remote node acknowledges data arrival, but before actually storing the data. The data on the remote node will be stored directly after sending the acknowledgement. This mode is intended to reduce latency, but still provides very good reliability. fullsync: report write operation as completed when local write completes and when remote write completes. This is the safest and the slowest replication mode. This mode is the default. async: report write operation as completed when local write completes. This is the fastest and the most dangerous replication mode. It should be used when replicating to a distant node where latency is too high for other modes. HAST Configuration HAST requires GEOM_GATE support which is not present in the default GENERIC kernel. However, the geom_gate.ko loadable module is available in the default &os; installation. Alternatively, to build GEOM_GATE support into the kernel statically, add this line to the custom kernel configuration file: options GEOM_GATE The HAST framework consists of several parts from the operating system's point of view: the &man.hastd.8; daemon responsible for data synchronization, the &man.hastctl.8; userland management utility, and the &man.hast.conf.5; configuration file. The following example describes how to configure two nodes in master-slave / primary-secondary operation using HAST to replicate the data between the two. The nodes will be called hasta with an IP address of 172.16.0.1 and hastb with an IP of address 172.16.0.2. Both nodes will have a dedicated hard drive /dev/ad6 of the same size for HAST operation. The HAST pool, sometimes also referred to as a resource or the GEOM provider in /dev/hast/, will be called test. Configuration of HAST is done using /etc/hast.conf. This file should be the same on both nodes. The simplest configuration possible is: resource test { on hasta { local /dev/ad6 remote 172.16.0.2 } on hastb { local /dev/ad6 remote 172.16.0.1 } } For more advanced configuration, refer to &man.hast.conf.5;. It is also possible to use host names in the remote statements. In such a case, make sure that these hosts are resolvable and are defined in /etc/hosts or in the local DNS. Now that the configuration exists on both nodes, the HAST pool can be created. Run these commands on both nodes to place the initial metadata onto the local disk and to start &man.hastd.8;: &prompt.root; hastctl create test &prompt.root; service hastd onestart It is not possible to use GEOM providers with an existing file system or to convert an existing storage to a HAST-managed pool. This procedure needs to store some metadata on the provider and there will not be enough required space available on an existing provider. A HAST node's primary or secondary role is selected by an administrator, or software like Heartbeat, using &man.hastctl.8;. On the primary node, hasta, issue this command: &prompt.root; hastctl role primary test Similarly, run this command on the secondary node, hastb: &prompt.root; hastctl role secondary test When the nodes are unable to communicate with each other, and both are configured as primary nodes, the condition is called split-brain. To troubleshoot this situation, follow the steps described in . Verify the result by running &man.hastctl.8; on each node: &prompt.root; hastctl status test The important text is the status line, which should say complete on each of the nodes. If it says degraded, something went wrong. At this point, the synchronization between the nodes has already started. The synchronization completes when hastctl status reports 0 bytes of dirty extents. The next step is to create a file system on the /dev/hast/test GEOM provider and mount it. This must be done on the primary node, as /dev/hast/test appears only on the primary node. Creating the file system can take a few minutes, depending on the size of the hard drive: &prompt.root; newfs -U /dev/hast/test &prompt.root; mkdir /hast/test &prompt.root; mount /dev/hast/test /hast/test Once the HAST framework is configured properly, the final step is to make sure that HAST is started automatically during system boot. Add this line to /etc/rc.conf: hastd_enable="YES" Failover Configuration The goal of this example is to build a robust storage system which is resistant to the failure of any given node. The scenario is that a primary node of the cluster fails. If this happens, the secondary node is there to take over seamlessly, check and mount the file system, and continue to work without missing a single bit of data. To accomplish this task, another &os; feature, CARP, provides for automatic failover on the IP layer. CARP (Common Address Redundancy Protocol) allows multiple hosts on the same network segment to share an IP address. Set up CARP on both nodes of the cluster according to the documentation available in . After setup, each node will have its own carp0 interface with a shared IP address of 172.16.0.254. The primary HAST node of the cluster must be the master CARP node. The HAST pool created in the previous section is now ready to be exported to the other hosts on the network. This can be accomplished by exporting it through NFS or Samba, using the shared IP address 172.16.0.254. The only problem which remains unresolved is an automatic failover should the primary node fail. In the event of CARP interfaces going up or down, the &os; operating system generates a &man.devd.8; event, making it possible to watch for state changes on the CARP interfaces. A state change on the CARP interface is an indication that one of the nodes failed or came back online. These state change events make it possible to run a script which will automatically handle the HAST failover. To be able to catch state changes on the CARP interfaces, add this configuration to /etc/devd.conf on each node: notify 30 { match "system" "IFNET"; match "subsystem" "carp0"; match "type" "LINK_UP"; action "/usr/local/sbin/carp-hast-switch master"; }; notify 30 { match "system" "IFNET"; match "subsystem" "carp0"; match "type" "LINK_DOWN"; action "/usr/local/sbin/carp-hast-switch slave"; }; Restart &man.devd.8; on both nodes to put the new configuration into effect: &prompt.root; service devd restart When the carp0 interface state changes by going up or down , the system generates a notification, allowing the &man.devd.8; subsystem to run an arbitrary script, in this case /usr/local/sbin/carp-hast-switch. This script handles the automatic failover. For further clarification about the above &man.devd.8; configuration, refer to &man.devd.conf.5;. An example of such a script could be: #!/bin/sh # Original script by Freddie Cash <fjwcash@gmail.com> # Modified by Michael W. Lucas <mwlucas@BlackHelicopters.org> # and Viktor Petersson <vpetersson@wireload.net> # The names of the HAST resources, as listed in /etc/hast.conf resources="test" # delay in mounting HAST resource after becoming master # make your best guess delay=3 # logging log="local0.debug" name="carp-hast" # end of user configurable stuff case "$1" in master) logger -p $log -t $name "Switching to primary provider for ${resources}." sleep ${delay} # Wait for any "hastd secondary" processes to stop for disk in ${resources}; do while $( pgrep -lf "hastd: ${disk} \(secondary\)" > /dev/null 2>&1 ); do sleep 1 done # Switch role for each disk hastctl role primary ${disk} if [ $? -ne 0 ]; then logger -p $log -t $name "Unable to change role to primary for resource ${disk}." exit 1 fi done # Wait for the /dev/hast/* devices to appear for disk in ${resources}; do for I in $( jot 60 ); do [ -c "/dev/hast/${disk}" ] && break sleep 0.5 done if [ ! -c "/dev/hast/${disk}" ]; then logger -p $log -t $name "GEOM provider /dev/hast/${disk} did not appear." exit 1 fi done logger -p $log -t $name "Role for HAST resources ${resources} switched to primary." logger -p $log -t $name "Mounting disks." for disk in ${resources}; do mkdir -p /hast/${disk} fsck -p -y -t ufs /dev/hast/${disk} mount /dev/hast/${disk} /hast/${disk} done ;; slave) logger -p $log -t $name "Switching to secondary provider for ${resources}." # Switch roles for the HAST resources for disk in ${resources}; do if ! mount | grep -q "^/dev/hast/${disk} on " then else umount -f /hast/${disk} fi sleep $delay hastctl role secondary ${disk} 2>&1 if [ $? -ne 0 ]; then logger -p $log -t $name "Unable to switch role to secondary for resource ${disk}." exit 1 fi logger -p $log -t $name "Role switched to secondary for resource ${disk}." done ;; esac In a nutshell, the script takes these actions when a node becomes master / primary: Promotes the HAST pools to primary on a given node. Checks the file system under the HAST pool. Mounts the pools at an appropriate place. When a node becomes backup / secondary: Unmounts the HAST pools. Degrades the HAST pools to secondary. Keep in mind that this is just an example script which serves as a proof of concept. It does not handle all the possible scenarios and can be extended or altered in any way, for example, to start/stop required services. For this example, a standard UFS file system was used. To reduce the time needed for recovery, a journal-enabled UFS or ZFS file system can be used instead. More detailed information with additional examples can be found in the HAST Wiki page. Troubleshooting General Troubleshooting Tips HAST should generally work without issues. However, as with any other software product, there may be times when it does not work as supposed. The sources of the problems may be different, but the rule of thumb is to ensure that the time is synchronized between all nodes of the cluster. When troubleshooting HAST problems, the debugging level of &man.hastd.8; should be increased by starting &man.hastd.8; with -d. This argument may be specified multiple times to further increase the debugging level. A lot of useful information may be obtained this way. Consider also using -F, which starts &man.hastd.8; in the foreground. Recovering from the Split-brain Condition Split-brain is when the nodes of the cluster are unable to communicate with each other, and both are configured as primary. This is a dangerous condition because it allows both nodes to make incompatible changes to the data. This problem must be corrected manually by the system administrator. The administrator must decide which node has more important changes (or merge them manually) and let HAST perform full synchronization of the node which has the broken data. To do this, issue these commands on the node which needs to be resynchronized: &prompt.root; hastctl role init <resource> &prompt.root; hastctl create <resource> &prompt.root; hastctl role secondary <resource>