diff --git a/documentation/content/en/books/handbook/bibliography/_index.adoc b/documentation/content/en/books/handbook/bibliography/_index.adoc index 04159bcd49..650a0010d0 100644 --- a/documentation/content/en/books/handbook/bibliography/_index.adoc +++ b/documentation/content/en/books/handbook/bibliography/_index.adoc @@ -1,94 +1,94 @@ --- title: Appendix B. Bibliography part: Part V. Appendices prev: books/handbook/mirrors next: books/handbook/eresources description: FreeBSD Handbook Bibliography tags: ["appendix", "bibliography", "handbook", "books", "guides", "security", "periodicals", "journals", "magazines"] showBookMenu: true weight: 42 params: path: "/books/handbook/bibliography/" --- [appendix] [[bibliography]] = Bibliography :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumoffset: B :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/bibliography/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] While manual pages provide a definitive reference for individual pieces of the FreeBSD operating system, they seldom illustrate how to put the pieces together to make the whole operating system run smoothly. For this, there is no substitute for a good book or users' manual on UNIX(R) system administration. [[bibliography-freebsd]] == FreeBSD Bibliography * *Absolute FreeBSD: The Complete Guide To FreeBSD*, Third Edition, published by link:https://nostarch.com/absfreebsd3[No Starch Press], 2018. ISBN: 978-1593278922 * *FreeBSD Mastery: Storage Essentials*, published by link:https://www.tiltedwindmillpress.com/product/freebsd-mastery-storage-essentials/[Tilted Windmill Press], 2014. ISBN: 978-1642350098 * *FreeBSD Mastery: Specialty Filesystems*, published by link:https://www.tiltedwindmillpress.com/product/fmspf/[Tilted Windmill Press], 2015. ISBN: 978-1642350111 * *FreeBSD Mastery: ZFS*, published by link:https://www.tiltedwindmillpress.com/product/fmzfs/[Tilted Windmill Press], 2015. ISBN: 978-1642350005 * *FreeBSD Mastery: Advanced ZFS*, published by link:https://www.tiltedwindmillpress.com/product/fmaz/[Tilted Windmill Press], 2016. ISBN: 978-0692688687 * *FreeBSD Mastery: Jails*, published by link:https://www.tiltedwindmillpress.com/product/fmjail/[Tilted Windmill Press], 2019. ISBN: 978-1642350241 * *FreeBSD Device Drivers: A Guide for the Intrepid*, published by link:https://nostarch.com/bsddrivers.htm[No Starch Press], 2012. ISBN: 978-1593272043 * *The Design And Implementation Of The Freebsd Operating System*, Second Edition, published by link:https://www.pearson.com/store/p/design-and-implementation-of-the-freebsd-operating-system-the/P200000000463/9780321968975[Pearson Education, Inc.], 2014. ISBN: 978-0321968975 * *UNIX and Linux System Administration Handbook*, Fifth Edition, published by link:https://www.pearson.com/en-us/subject-catalog/p/unix-and-linux-system-administration-handbook/P200000000513/9780137460359[Pearson Education, Inc.], 2017. ISBN: 978-0134277554 * *Designing BSD Rootkits*, published by link:https://nostarch.com/rootkits.htm[No Starch Press], 2007. ISBN: 978-1593271428 * *FreeBSD Jails using VNETs*, published in link:https://rderik.gumroad.com/l/uwOLZ[gumroad] [[bibliography-security]] == Security Reference * *The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall*, Third Edition, published by link:https://nostarch.com/pf3[No Starch Press], 2014. ISBN: 978-1593275891 * *SSH Mastery: OpenSSH, PuTTY, Tunnels, and Keys*, Second Edition, 2018. ISBN: 978-1642350029 [[bibliography-history]] == UNIX(R) History * Lion, John _Lion's Commentary on UNIX, 6th Ed. With Source Code_. ITP Media Group, 1996. ISBN 1573980137 * Raymond, Eric S. _The New Hacker's Dictionary, 3rd edition_. MIT Press, 1996. ISBN 0-262-68092-0. Also known as the http://www.catb.org/~esr/jargon/html/index.html[Jargon File] * Salus, Peter H. _A quarter century of UNIX_. Addison-Wesley Publishing Company, Inc., 1994. ISBN 0-201-54777-5 * Simon Garfinkel, Daniel Weise, Steven Strassmann. _The UNIX-HATERS Handbook_. IDG Books Worldwide, Inc., 1994. ISBN 1-56884-203-1. Out of print, but available http://www.simson.net/ref/ugh.pdf[online]. * Don Libes, Sandy Ressler _Life with UNIX_ - special edition. Prentice-Hall, Inc., 1989. ISBN 0-13-536657-7 * _The BSD family tree_. https://cgit.freebsd.org/src/tree/share/misc/bsd-family-tree[https://cgit.freebsd.org/src/tree/share/misc/bsd-family-tree] or link:file://localhost/usr/share/misc/bsd-family-tree[/usr/share/misc/bsd-family-tree] on a FreeBSD machine. * _Networked Computer Science Technical Reports Library_. -* _Old BSD releases from the Computer Systems Research group (CSRG)_. http://www.mckusick.com/csrg/[http://www.mckusick.com/csrg/]: The 4CD set covers all BSD versions from 1BSD to 4.4BSD and 4.4BSD-Lite2 (but not 2.11BSD, unfortunately). The last disk also holds the final sources plus the SCCS files. +* _Old BSD releases from the Computer Systems Research group (CSRG)_. https://www.mckusick.com/csrg/[https://www.mckusick.com/csrg/]: The 4CD set covers all BSD versions from 1BSD to 4.4BSD and 4.4BSD-Lite2 (but not 2.11BSD, unfortunately). The last disk also holds the final sources plus the SCCS files. * Kernighan, Brian _Unix: A History and a Memoir_. Kindle Direct Publishing, 2020. ISBN 978-169597855-3 [[bibliography-journals]] == Periodicals, Journals, and Magazines * https://www.admin-magazin.de/[Admin Magazin] (in German), published by Medialinx AG. ISSN: 2190-1066 * https://www.bsdnow.tv/[BSD Now - Video Podcast], published by Jupiter Broadcasting LLC * https://freebsdfoundation.org/our-work/journal/[FreeBSD Journal], published by S&W Publishing, sponsored by The FreeBSD Foundation. ISBN: 978-0-615-88479-0 diff --git a/documentation/content/en/books/handbook/bsdinstall/_index.adoc b/documentation/content/en/books/handbook/bsdinstall/_index.adoc index de90517cde..577c0114e0 100644 --- a/documentation/content/en/books/handbook/bsdinstall/_index.adoc +++ b/documentation/content/en/books/handbook/bsdinstall/_index.adoc @@ -1,1293 +1,1293 @@ --- title: Chapter 2. Installing FreeBSD part: Part I. Getting Started prev: books/handbook/introduction next: books/handbook/basics description: Guide about how to install FreeBSD, the minimum hardware requirements and supported architectures, how to create the installation media, etc tags: ["bsdinstall", "installing FreeBSD", "requirements", "tutorial", "guide"] showBookMenu: true weight: 4 params: path: "/books/handbook/bsdinstall/" --- [[bsdinstall]] = Installing FreeBSD :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumoffset: 2 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/bsdinstall/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[bsdinstall-synopsis]] == Synopsis FreeBSD supports different architectures including amd64, ARM(R), RISC-V(R), and PowerPC(R). Depending on the architecture and platform, different images can be link:https://www.freebsd.org/where/[downloaded] to install or directly run FreeBSD. The image types are: * Virtual Machine disk images, such as `qcow2`, `vmdk`, `vhd`, and raw device images. These are not installation images, but images that have FreeBSD preinstalled and ready for post-installation tasks. Virtual machine images are also commonly used in cloud environments. * SD card images, for embedded systems such as Raspberry Pi. These files must be uncompressed and written as a raw image to an SD card, from which the board will boot. * Installation images to boot from an ISO or USB device to install FreeBSD on a drive for the usual desktop, laptop, or server system. The rest of this chapter describes the third case, explaining how to install FreeBSD using the text-based installation program named bsdinstall. There may be minor differences between the installer and what is shown here, so use this chapter as a general guide rather than as a set of literal instructions. Read this chapter to learn: * How to obtain FreeBSD images and create FreeBSD installation media. * How to start bsdinstall. * The questions bsdinstall will ask, what they mean, and how to answer them. * How to troubleshoot a failed installation. * How to access a live version of FreeBSD before committing to an installation. [[bsdinstall-hardware]] == Minimum Hardware Requirements The hardware requirements to install FreeBSD vary by architecture and version. Hardware architectures and devices supported by a FreeBSD release are listed on the link:https://www.FreeBSD.org/releases/[FreeBSD Release Information] page. The link:https://www.FreeBSD.org/where/[FreeBSD download page] also has recommendations for choosing the correct image for different architectures. [[bsdinstall-pre]] == Pre-Installation Tasks Once it has been determined that the system meets the minimum hardware requirements for installing FreeBSD, the installation file should be downloaded and the installation media prepared. [TIP] ==== Consider using crossref:virtualization[virtualization,virtualization] when wanting to use FreeBSD on a system that already has another operating system installed. ==== Before moving on to the installation, check that the system is ready by verifying the items in this checklist: [.procedure] ==== . *Back Up Important Data* + Before installing any operating system, *always* backup all important data first. Do not store the backup on the system being installed. Instead, save the data to a removable disk such as a USB drive, another system on the network, or an online backup service. Test the backup before starting the installation to make sure it contains all of the needed files. Once the installer formats the system's disk, all data stored on that disk will be lost. . *Decide Where to Install FreeBSD* + If FreeBSD will be the only operating system installed, this step can be skipped. But if FreeBSD will share the disk with another operating system, decide which disk or partition will be used for FreeBSD. + In the i386 and amd64 architectures, disks can be divided into multiple partitions using one of two partitioning schemes. A traditional _Master Boot Record_ (MBR) holds a partition table defining up to four _primary partitions_. For historical reasons, FreeBSD calls these primary partition _slices_. One of these primary partitions can be made into an _extended partition_ containing multiple _logical partitions_. The _GUID Partition Table_ (GPT) is a newer and simpler method of partitioning a disk. Common GPT implementations allow up to 128 partitions per disk, eliminating the need for logical partitions. + The FreeBSD boot loader requires either a primary or GPT partition. If all of the primary or GPT partitions are already in use, one must be freed for FreeBSD. To create a partition without deleting existing data, use a partition resizing tool to shrink an existing partition and create a new partition using the freed space. + An alternative to modifying the system's existing disk partitions is to use crossref:virtualization[virtualization,virtualization], which allows multiple operating systems to run at the same time without having to alter partitions. + A variety of free and commercial partition resizing tools are listed at link:https://en.wikipedia.org/wiki/List_of_disk_partitioning_software[List of disk partitioning software wikipedia entry]. link:https://gparted.org/livecd.php[GParted Live] is a free live CD which includes the GParted partition editor. + [WARNING] ====== When used properly, disk shrinking utilities can safely create space for creating a new partition. Since the possibility of selecting the wrong partition exists, always backup any important data and verify the integrity of the backup before modifying disk partitions. ====== + Disk partitions containing different operating systems make it possible to install multiple operating systems on one computer. . *Collect Network Information* + Some FreeBSD installation methods require a network connection in order to download the installation files. After any installation, the installer will offer to setup the system's network interfaces. + If the network has a DHCP server, it can be used to provide automatic network configuration. If DHCP is not available, the following network information for the system must be obtained from the local network administrator or Internet service provider: + [[bsdinstall-collect-network-information]] Required Network Information .. IP address .. Subnet mask .. IP address of default gateway .. Domain name of the network .. IP addresses of the network's DNS servers . *Check for FreeBSD Errata* + Although the FreeBSD Project strives to ensure that each release of FreeBSD is as stable as possible, bugs occasionally creep into the process. On very rare occasions those bugs affect the installation process. As these problems are discovered and fixed, they are noted in the FreeBSD Errata page of each version. Check the errata before installing to make sure that there are no problems that might affect the installation. + Information and errata for all the releases can be found on the link:https://www.FreeBSD.org/releases/[FreeBSD Release Information] page. ==== [[bsdinstall-installation-media]] === Prepare the Installation Media The FreeBSD installer is not an application that can be run from within another operating system. Instead, download a FreeBSD installation file, burn it to the media associated with its file type and size (CD, DVD, or USB), and boot the system to install from the inserted media. FreeBSD installation files are available at the link:https://www.FreeBSD.org/where/[FreeBSD download page]. Each installation file's name includes the release version of FreeBSD, the architecture, and the type of file. Installation files are available in several formats, compressed with man:xz[1] or uncompressed. The formats vary depending on computer architecture and media type. Installation file types: * `*-bootonly.iso*`: This is the smallest installation file as it only contains the installer. A working Internet connection is required during installation as the installer will download the files it needs to complete the FreeBSD installation. This file should be burned to optical media. * `*-disc1.iso*`: This file contains all of the files needed to install FreeBSD, its source, and the Ports Collection. This file should be burned to optical media. * `*-dvd1.iso*`: This file contains all of the files needed to install FreeBSD, its source, and the Ports Collection. It also contains a set of popular binary packages for installing a window manager and some applications so that a complete system can be installed from media without requiring a connection to the Internet. This file should be burned to optical media. * `*-memstick.img*`: This file contains all of the files needed to install FreeBSD, its source, and the Ports Collection. Write this file to a USB stick as shown in crossref:bsdinstall[bsdinstall-usb, Writing an Image File to USB]. * `*-mini-memstick.img*`: Like `*-bootonly.iso*`, does not include installation files, but downloads them as needed. A working internet connection is required during installation. It should be written to a USB stick as shown in crossref:bsdinstall[bsdinstall-usb, Writing an Image File to USB]. After downloading the image file, download at least one _checksum_ file from the same directory. There are two _checksum_ files available, named after the release number and the architecture name. For example: `CHECKSUM.SHA256-FreeBSD-{rel-latest}-RELEASE-amd64` and `CHECKSUM.SHA512-FreeBSD-{rel-latest}-RELEASE-amd64`. After downloading one of the files (or both), calculate the _checksum_ for the image file and compare it with the one shown in the _checksum_ file. Note that comparing the calculated _checksum_ against the correct file is needed, as they correspond to two different algorithms: SHA256 and SHA512. FreeBSD provides man:sha256[1] and man:sha512[1] that can be used for calculating the _checksum_. Other operating systems have similar programs. Verifying the _checksum_ in FreeBSD can be done automatically using man:sha256sum[1] (and man:sha512sum[1]) by executing: [source,shell,subs=attributes] .... % sha256sum -c CHECKSUM.SHA256-FreeBSD-{rel-latest}-RELEASE-amd64 --ignore-missing FreeBSD-{rel-latest}-RELEASE-amd64-dvd1.iso: OK .... The checksums must match exactly. If the checksums do not match, the image file is corrupt and must be downloaded again. [[bsdinstall-usb]] ==== Writing an Image File to USB The `\*memstick.img` file is an _image_ of the complete contents of a memory stick. It _cannot_ be copied to the target device as a file. Several applications are available for writing the `*.img` to a USB stick. This section describes two of these utilities. [IMPORTANT] ==== Before proceeding, back up any important data on the USB stick. This procedure will erase the existing data on the stick. ==== [[bsdinstall-usb-dd]] [.procedure] ==== *Procedure. Using `dd` to write the image* + [WARNING] ====== This example uses `/dev/da0` as the target device where the image will be written. Be *very careful* that the correct device is used as this command will destroy the existing data on the specified target device. ====== . The command-line utility is available on BSD, Linux(R), and Mac OS(R) systems. To burn the image using `dd`, insert the USB stick and determine its device name. Then, specify the name of the downloaded installation file and the device name for the USB stick. This example burns the amd64 installation image to the first USB device on an existing FreeBSD system. + [source,shell,subs=attributes] .... # dd if=FreeBSD-{rel-latest}-RELEASE-amd64-memstick.img of=/dev/da0 bs=1M conv=sync .... + If this command fails, verify that the USB stick is not mounted and that the device name is for the disk, not a partition. + Some operating systems might require this command to be run with man:sudo[8]. The man:dd[1] syntax varies slightly across different platforms; for example, Mac OS(R) requires a lower-case `bs=1m`. Systems like Linux(R) might buffer writes. To force all writes to complete, use man:sync[8]. ==== [.procedure] ==== *Procedure. Using Windows(R) to Write the Image* + [WARNING] ====== Be sure to give the correct drive letter as the existing data on the specified drive will be overwritten and destroyed. ====== . *Obtaining Image Writer for Windows(R)* + Image Writer for Windows(R) is a free application that can correctly write an image file to a memory stick. Download it from https://sourceforge.net/projects/win32diskimager/[win32diskimager home page] and extract it into a folder. . *Writing the Image with Image Writer* + Double-click the Win32DiskImager icon to start the program. Verify that the drive letter shown under `Device` is the drive with the memory stick. Click the folder icon and select the image to be written to the memory stick. Click btn:[Save] to accept the image file name. Verify that everything is correct, and that no folders on the memory stick are open in other windows. When everything is ready, click btn:[Write] to write the image file to the memory stick. ==== [[bsdinstall-start]] == Starting the Installation [IMPORTANT] ==== By default, the installation will not make any changes to the disk(s) before the following message: [.programlisting] .... Your changes will now be written to disk. If you have chosen to overwrite existing data, it will be PERMANENTLY ERASED. Are you sure you want to commit your changes? .... The install can be exited at any time prior to this warning. If there is a concern that something is incorrectly configured, just turn the computer off before this point and no changes will be made to the system's disks. ==== This section describes how to boot the system from the installation media which was prepared using the instructions in crossref:bsdinstall[bsdinstall-installation-media, Prepare the Installation Media]. When using a bootable USB stick, plug in the USB stick before turning on the computer. When booting from CD or DVD, turn on the computer and insert the media at the first opportunity. How to configure the system to boot from the inserted media depends upon the architecture. [[bsdinstall-view-probe]] === FreeBSD Boot Loader Menu Once the system boots from the installation media, a menu similar to the following will be displayed: [[bsdinstall-newboot-loader-menu]] .FreeBSD Boot Loader Menu image::bsdinstall-newboot-loader-menu.png[FreeBSD boot loader menu] By default, the menu will wait ten seconds for user input before booting into the FreeBSD installer or, if FreeBSD is already installed, before booting into FreeBSD. To pause the boot timer in order to review the selections, press kbd:[Space]. To select an option, press its highlighted number, character, or key. The following options are available. * `Boot Multi User`: This will continue the FreeBSD boot process. If the boot timer has been paused, press kbd:[1], upper- or lower-case kbd:[B], or kbd:[Enter]. * `Boot Single User`: This mode can be used to fix an existing FreeBSD installation as described in crossref:boot[boot-singleuser,“Single-User Mode”]. Press kbd:[2] or the upper- or lower-case kbd:[S] to enter this mode. * `Escape to loader prompt`: This will boot the system into a repair prompt that contains a limited number of low-level commands. This prompt is described in crossref:boot[boot-loader,“Stage Three”]. Press kbd:[3] or kbd:[Esc] to boot into this prompt. * `Reboot`: Reboots the system. * `Cons`: Allow to continue the installation by `video`, `serial`, `Dual (serial primary)` or `Dual (Video primary)` * `Kernel`: Loads a different kernel. * `Boot Options`: Opens the menu shown in, and described under, crossref:bsdinstall[bsdinstall-boot-options-menu,FreeBSD Boot Options Menu]. [[bsdinstall-boot-options-menu]] .FreeBSD Boot Options Menu image::bsdinstall-boot-options-menu.png[Menu showing the different boot options supported] The boot options menu is divided into two sections. The first section can be used to either return to the main boot menu or to reset any toggled options back to their defaults. The next section is used to toggle the available options to `On` or `Off` by pressing the option's highlighted number or character. The system will always boot using the settings for these options until they are modified. Several options can be toggled using this menu: * `ACPI`: If the system hangs during boot, try toggling this option to `Off`. This option is only present when ACPI support is available but not required. * `Safe Mode`: If the system still hangs during boot even with `ACPI Support` set to `Off`, try setting this option to `On`. * `Single User`: Toggle this option to `On` to fix an existing FreeBSD installation as described in crossref:boot[boot-singleuser,“Single-User Mode”]. Once the problem is fixed, set it back to `Off`. * `Verbose`: Toggle this option to `On` to see more detailed messages during the boot process. This can be useful when troubleshooting a piece of hardware. After making the needed selections, press kbd:[1] or kbd:[Backspace] to return to the main boot menu, then press kbd:[Enter] to continue booting into FreeBSD. A series of boot messages will appear as FreeBSD carries out its hardware device probes and loads the installation program. Once the boot is complete, the welcome menu shown in crossref:bsdinstall[bsdinstall-choose-mode,Welcome Menu] will be displayed. [[bsdinstall-choose-mode]] .Welcome Menu image::bsdinstall-choose-mode.png[FreeBSD installation welcome menu] Press kbd:[Enter] to select the default of btn:[Install] to enter the installer. The rest of this chapter describes how to use this installer. Otherwise, use the right or left arrows or the colorized letter to select the desired menu item. The btn:[Shell] can be used to access a FreeBSD shell in order to use command line utilities to prepare the disks before installation. The btn:[Live CD] option can be used to try out FreeBSD before installing it. The live version is described in crossref:bsdinstall[using-live-cd, Using the Live CD]. [TIP] ==== To review the boot messages, including the hardware device probe, press the upper- or lower-case kbd:[S] and then kbd:[Enter] to access a shell. At the shell prompt, type `more /var/run/dmesg.boot` and use the space bar to scroll through the messages. When finished, type `exit` to return to the welcome menu. ==== [[using-bsdinstall]] == Using bsdinstall This section shows the order of the bsdinstall menus and the type of information that will be asked before the system is installed. Use the arrow keys to highlight a menu option, then kbd:[Space] to select or deselect that menu item. When finished, press kbd:[Enter] to save the selection and move onto the next screen. [[bsdinstall-keymap]] === Selecting the Keymap Menu Before starting the process, bsdinstall will load the keymap files as shown in crossref:bsdinstall[bsdinstall-keymap-loading,Keymap Loading]. [[bsdinstall-keymap-loading]] .Keymap Loading image::bsdinstall-keymap-loading.png[Keymap loading] After the keymaps have been loaded, bsdinstall displays the menu shown in crossref:bsdinstall[bsdinstall-keymap-10,Keymap Selection Menu]. Use the up and down arrows to select the keymap that most closely represents the mapping of the keyboard attached to the system. Press kbd:[Enter] to save the selection. [[bsdinstall-keymap-10]] .Keymap Selection Menu image::bsdinstall-keymap-10.png[Keymap selection menu showing all supported keyboards] [NOTE] ==== Pressing kbd:[Esc] will exit this menu and use the default keymap. If the choice of keymap is not clear, [.guimenuitem]#United States of America ISO-8859-1# is also a safe option. ==== In addition, when selecting a different keymap, the user can try the keymap and ensure it is correct before proceeding, as shown in crossref:bsdinstall[bsdinstall-keymap-testing,Keymap Testing Menu]. [[bsdinstall-keymap-testing]] .Keymap Testing Menu image::bsdinstall-keymap-testing.png[Keymap testing menu] [[bsdinstall-hostname]] === Setting the Hostname The next bsdinstall menu is used to set the hostname for the newly installed system. [[bsdinstall-config-hostname]] .Setting the Hostname image::bsdinstall-config-hostname.png[Setting the hostname] Type in a hostname that is unique for the network. It should be a fully-qualified hostname, such as `machine3.example.com`. [[bsdinstall-installation-type]] === Selecting Installation Type In the next menu bsdinstall will ask whether to install the base system using traditional distribution sets or the new package-based method. [[bsdinstall-choose-type]] .Selecting Installation Type image::bsdinstall-distributions-sets-pkgbase.png[Choice between "Distribution Sets" and "Packages (Tech Preview)"] Starting with FreeBSD 15.0, the installer offers two distinct approaches for laying down and later updating the base system. Both options install the same kernel and userland but differ fundamentally in how they are delivered and maintained over time. * `Distribution Sets` - The classic installation method used since the early days of the project. The base system is unpacked from a collection of compressed tarballs. Updates are performed exclusively with the man:freebsd-update[8] utility. This method is fully supported, stable, and remains the default for most installation media in the 15.x series. * `Packages (Tech Preview)` - Installs the base system as a set of individual packages from the `FreeBSD-base` repository. Once installed, the entire operating system—both the base and any third-party software—can be upgraded with a single `pkg upgrade` command. This method, known as `pkgbase`, unifies system management under the man:pkg[8] framework. [TIP] ==== The `Packages (Tech Preview)` option is offered for testing and early adoption. While it is expected to become the default in FreeBSD 16.0, users who prefer a conservative, time-tested update solution should select `Distribution Sets` for production environments during the 15.x lifecycle. ==== [[bsdinstall-components]] === Selecting Components to Install Next, bsdinstall will prompt to select optional components to install. [[bsdinstall-config-components]] .Selecting Components to Install image::bsdinstall-config-components.png[Different components that can be installed. Example: base-dbg, lib32, ports, etc.] Deciding which components to install will depend largely on the intended use of the system and the amount of disk space available. The FreeBSD kernel and userland, collectively known as the _base system_, are always installed. Depending on the architecture, some of these components may not appear: * `base-dbg` - Base tools like cat and ls, among many others, with debug symbols activated. * `kernel-dbg` - Kernel and modules with debug symbols activated. * `lib32-dbg` - Compatibility libraries for running 32-bit applications on a 64-bit version of FreeBSD with debug symbols activated. * `lib32` - Compatibility libraries for running 32-bit applications on a 64-bit version of FreeBSD. * `ports` - The FreeBSD Ports Collection is a collection of files which automates the downloading, compiling and installation of third-party software packages. crossref:ports[ports,Installing Applications: Packages and Ports] discusses how to use the Ports Collection. + [WARNING] ==== The installation program does not check for adequate disk space. Select this option only if sufficient hard disk space is available. The FreeBSD Ports Collection takes up about {ports-size} of disk space. ==== * `src` - The complete FreeBSD source code for both the kernel and the userland. Although not required for the majority of applications, it may be required to build device drivers, kernel modules, or some applications from the Ports Collection. It is also used for developing FreeBSD itself. The full source tree requires 1 GB of disk space and recompiling the entire FreeBSD system requires an additional 5 GB of space. * `tests` - FreeBSD Test Suite. [[bsdinstall-netinstall]] === Installing from the Network The menu shown in crossref:bsdinstall[bsdinstall-netinstall-notify,Installing from the Network] only appears when installing from a `-bootonly.iso` or `-mini-memstick.img`, as this installation media does not hold copies of the installation files. Since the installation files must be retrieved over a network connection, this menu indicates that the network interface must be configured first. If this menu is shown in any step of the process, remember to follow the instructions in crossref:bsdinstall[bsdinstall-config-network-dev, Configuring Network Interfaces]. [[bsdinstall-netinstall-notify]] .Installing from the Network image::bsdinstall-netinstall-files.png[Indicates that certain components have not been found and will be downloaded using the network.] [[bsdinstall-partitioning]] == Allocating Disk Space The next menu is used to determine the method for allocating disk space. [[bsdinstall-zfs-partmenu]] .Partitioning Choices image::bsdinstall-zfs-partmenu.png[Shows the different partition options. Example: Manual, Shell, etc.] bsdinstall gives the user four methods for allocating disk space: * `Auto (ZFS)` partitioning creates a root-on-ZFS system with optional GELI encryption support for _boot environments_. * `Auto (UFS)` partitioning automatically sets up the disk partitions using the `UFS` file system. * `Manual` partitioning allows advanced users to create customized partitions from menu options. * `Shell` opens a shell prompt where advanced users can create customized partitions using command-line utilities like man:gpart[8], man:fdisk[8], and man:bsdlabel[8]. This section describes what to consider when laying out the disk partitions. It then demonstrates how to use the different partitioning methods. [[configtuning-initial]] === Designing the Partition Layout The default partition layout for file systems includes one file system for the entire system. When using `UFS` it may be worth considering the use of multiple file systems with sufficient disk space or multiple disks available. When laying out file systems, remember that hard drives transfer data faster from the outer tracks to the inner. Thus, smaller and heavier-accessed file systems should be closer to the outside of the drive, while larger partitions like `/usr` should be placed toward the inner parts of the disk. It is a good idea to create partitions in an order similar to: `/`, swap, `/var`, and `/usr`. The size of the `/var` partition reflects the intended machine's usage. This partition is used to hold mailboxes, log files, and printer spools. Mailboxes and log files can grow to unexpected sizes depending on the number of users and how long log files are kept. On average, most users rarely need more than about a gigabyte of free disk space in `/var`. [NOTE] ==== Sometimes, a lot of disk space is required in `/var/tmp`. When new software is installed, the packaging tools extract a temporary copy of the packages under `/var/tmp`. Large software packages, like Firefox or LibreOffice may be tricky to install if there is not enough disk space under `/var/tmp`. ==== The `/usr` partition holds many of the files which support the system, including the FreeBSD Ports Collection and system source code. At least 2 gigabytes of space is recommended for this partition. Also, note that home directories for users are placed in `/usr/home` by default, but can be placed on another partition. By default, `/home` is a symbolic link to `/usr/home`. When selecting partition sizes, keep the space requirements in mind. Running out of space in one partition while barely using another can be a hassle. As a rule of thumb, the swap partition should be about double the size of physical memory (RAM). Systems with minimal RAM (less for larger-memory configurations) may perform better with more swap. Configuring too little swap can lead to inefficiencies in the VM page scanning code and might create issues later if more memory is added. On larger systems with multiple SCSI disks or multiple IDE disks operating on different controllers, it is recommended that swap be configured on each drive, up to four drives. The swap partitions should be approximately the same size. The kernel can handle arbitrary sizes, but internal data structures scale to 4 times the largest swap partition. Keeping the swap partitions near the same size will allow the kernel to optimally stripe swap space across disks. Large swap sizes may elicit a kernel warning message about the total configured swap. The limit is raised by increasing the amount of memory allowed for keeping track of swap allocations, as instructed by the warning message. It might be easier to recover from a runaway program before being forced to reboot. By properly partitioning a system, fragmentation introduced in the smaller write-heavy partitions will not bleed over into the mostly read partitions. Keeping the write-loaded partitions closer to the disk's edge will increase I/O performance in the partitions where it occurs the most. While I/O performance in the larger partitions may be needed, shifting them more toward the edge of the disk will not lead to a significant performance improvement over moving `/var` to the edge. [[bsdinstall-part-guided]] === Guided Partitioning Using UFS When this method is selected, a menu will display the available disk(s). If multiple disks are connected, choose the one where FreeBSD is to be installed. [[bsdinstall-part-guided-disk]] .Selecting from Multiple Disks image::bsdinstall-part-guided-disk.png[Shows the list of disks on which FreeBSD can be installed] Once the disk is selected, the next menu prompts to install to either the entire disk or to create a partition using free space. If btn:[Entire Disk] is chosen, a general partition layout filling the whole disk is automatically created. Selecting btn:[Partition] creates a partition layout from the unused space on the disk. [[bsdinstall-part-entire-part]] .Selecting Entire Disk or Partition image::bsdinstall-part-entire-part.png[Menu asking the user if he wants to use all the available space on the disk or wants to make a partition] The next menu shows a list with the available partition scheme types. GPT is usually the most appropriate choice for amd64 computers. Older computers that are not compatible with GPT should use MBR. The other partition schemes are generally used for uncommon or older computers. More information is available in crossref:bsdinstall[partition-schemes,Partitioning Schemes]. [[bsdinstall-ufs-scheme]] .Select Partition Scheme image::bsdinstall-part-manual-partscheme.png[Menu showing the user the different the different types of partition that exist and requesting one of them] After the partition layout has been created, review it to ensure it meets the needs of the installation. Selecting btn:[Revert] will reset the partitions to their original values. Pressing btn:[Auto] will recreate the automatic FreeBSD partitions. Partitions can also be manually created, modified, or deleted. When the partitioning is correct, select btn:[Finish] to continue with the installation. [[bsdinstall-part-review]] .Review Created Partitions image::bsdinstall-part-review.png[Menu showing created partitions] Once the disks are configured, the next menu provides the last chance to make changes before the selected drives are formatted. If changes need to be made, select btn:[Back] to return to the main partitioning menu. btn:[Revert & Exit] exits the installer without making any changes to the drive. Otherwise, select btn:[Commit] to start the installation process. [[bsdinstall-ufs-final-confirmation]] .Final Confirmation image::bsdinstall-final-confirmation.png[Menu indicating to the user that all changes will be written to disk and informing that if he decides to continue the existing data will be permanently deleted.] To continue with the installation process, go to crossref:bsdinstall[bsdinstall-fetching-distribution, Fetching Distribution Files]. [[bsdinstall-part-manual]] === Manual Partitioning Selecting this method opens the partition editor: [[bsdinstall-part-manual-create]] .Manually Create Partitions image::bsdinstall-part-manual-create.png[Menu showing the Partition Editor.] Highlight the installation drive (`ada0` in this example) and select btn:[Create] to display a menu of available partition schemes: [[bsdinstall-part-manual-partscheme]] .Manually Create Partitions image::bsdinstall-part-manual-partscheme.png[Menu showing the different kind of partition schemes] GPT is usually the most appropriate choice for amd64 computers. Older computers that are not compatible with GPT should use MBR. The other partition schemes are generally used for uncommon or older computers. [[partition-schemes]] .Partitioning Schemes [cols="25h,~", frame="none", options="header"] |=== <| Abbreviation <| Description |APM |Apple Partition Map, used by PowerPC(R). |BSD |BSD label without an MBR, sometimes called _dangerously dedicated mode_ as non-BSD disk utilities may not recognize it. |GPT |link:https://en.wikipedia.org/wiki/GUID_Partition_Table[GUID Partition Table]. |MBR |link:https://en.wikipedia.org/wiki/Master_boot_record[Master Boot Record]. |=== After the partitioning scheme has been selected and created, select btn:[Create] again to create the partitions. The kbd:[Tab] key is used to give focus to the fields (after cycling through btn:[], btn:[], and btn:[]). [[bsdinstall-part-manual-addpart]] .Manually Create Partitions image::bsdinstall-part-manual-addpart.png[Menu requesting type, size, mountpoint and label for the new partition.] A standard FreeBSD GPT installation uses at least three partitions, including either UFS or ZFS: * `freebsd-boot` or `efi` - Holds the FreeBSD boot code. * `freebsd-ufs` - A FreeBSD UFS file system. * `freebsd-zfs` - A FreeBSD ZFS file system. More information about ZFS is available in crossref:zfs[zfs,The Z File System (ZFS)]. * `freebsd-swap` - FreeBSD swap space. Refer to man:gpart[8] for descriptions of the available GPT partition types. Multiple file system partitions can be created. Some people prefer a traditional layout with separate partitions for `/`, `/var`, `/tmp`, and `/usr`. [TIP] ==== Note that `/tmp` can be added later as a memory-based file system (man:tmpfs[5]) on systems with sufficient memory. ==== See crossref:bsdinstall[bsdinstall-part-manual-splitfs,Creating Traditional Split File System Partitions] for an example. The `Size` may be entered with common abbreviations: _K_ for kilobytes, _M_ for megabytes, or _G_ for gigabytes. [TIP] ==== Proper sector alignment provides the best performance, and making partition sizes even multiples of 4K bytes helps to ensure alignment on drives with either 512-byte or 4K-byte sectors. Generally, using partition sizes that are even multiples of 1M or 1G is the easiest way to make sure every partition starts at an even multiple of 4K. There is one exception: a _freebsd-boot_ partition for BIOS booting should be no larger than 512K due to legacy boot code limitations. This limitation does not apply to UEFI booting. ==== A `Mountpoint` is needed if the partition will contain a file system. If only a single UFS partition will be created, the mountpoint should be `/`. The `Label` is a name by which the partition will be known. Drive names or numbers can change if the drive is connected to a different controller or port, but the partition label does not change. Referring to labels instead of drive names and partition numbers in files like `/etc/fstab` makes the system more tolerant to hardware changes. GPT labels appear in `/dev/gpt/` when a disk is attached. Other partitioning schemes have different label capabilities and their labels appear in different directories in `/dev/`. [TIP] ==== Use a unique label on every partition to avoid conflicts from identical labels. A few letters from the computer's name, use, or location can be added to the label. For instance, use `labroot` or `rootfslab` for the UFS root partition on the computer named `lab`. ==== [[bsdinstall-part-manual-splitfs]] .Creating Traditional Split File System Partitions [example] ==== For a traditional partition layout where the `/`, `/var`, `/tmp`, and `/usr` directories are separate file systems on their own partitions, create a GPT partitioning scheme, then create the partitions as shown. Partition sizes shown are typical for a 20G target disk. If more space is available on the target disk, larger swap or `/var` partitions may be useful. Labels shown here are prefixed with `ex` for "example", but readers should use other unique label values as described above. By default, FreeBSD's `gptboot` expects the first UFS partition to be the `/` partition. [.informaltable] [cols="1,1,1,1", frame="none", options="header"] |=== | Partition Type | Size | Mountpoint | Label |`freebsd-boot` |`512K` | | |`freebsd-ufs` |`2G` |`/` |`exrootfs` |`freebsd-swap` |`4G` | |`exswap` |`freebsd-ufs` |`2G` |`/var` |`exvarfs` |`freebsd-ufs` |`1G` |`/tmp` |`extmpfs` |`freebsd-ufs` |accept the default (remainder of the disk) |`/usr` |`exusrfs` |=== ==== After the custom partitions have been created, select btn:[Finish] to continue with the installation and go to crossref:bsdinstall[bsdinstall-fetching-distribution, Fetching Distribution Files]. [[bsdinstall-part-zfs]] === Guided Partitioning Using Root-on-ZFS This partitioning mode only works with whole disks and will erase the contents of the entire disk. The main ZFS configuration menu offers a number of options to control the creation of the pool. [[bsdinstall-zfs-menu]] .ZFS Partitioning Menu image::bsdinstall-zfs-menu.png[Menu showing the different options to configure the ZFS pool] Here is a summary of the options in this menu: * `Install` - Proceed with the installation with the selected options. * `Pool Type/Disks` - Configure the `Pool Type` and the disk(s) that will constitute the pool. The automatic ZFS installer currently only supports the creation of a single top level vdev, except in stripe mode. To create more complex pools, use the instructions in crossref:bsdinstall[bsdinstall-part-shell, Shell Mode Partitioning] to create the pool. * `Rescan Devices` - Repopulate the list of available disks. * `Disk Info` - This menu can be used to inspect each disk, including its partition table and various other information such as the device model number and serial number, if available. * `Pool Name` - Establish the name of the pool. The default name is _zroot_. * `Force 4K Sectors?` - Force the use of 4K sectors. By default, the installer will automatically create partitions aligned to 4K boundaries and force ZFS to use 4K sectors. This is safe even with 512 byte sector disks, and has the added benefit of ensuring that pools created on 512 byte disks will be able to have 4K sector disks added in the future, either as additional storage space or as replacements for failed disks. Press the kbd:[Enter] key to chose to activate it or not. * `Encrypt Disks?` - Encrypting the disks allows the user to encrypt the disks using GELI. More information about disk encryption is available in crossref:disks[disks-encrypting-geli,“Disk Encryption with geli”]. Press the kbd:[Enter] key to choose whether to activate it or not. * `Partition Scheme` - Choose the partition scheme. GPT is the recommended option in most cases. Press the kbd:[Enter] key to chose between the different options. * `Swap Size` - Establish the amount of swap space. * `Mirror Swap?` - Whether to mirror the swap between the disks. Be aware that enabling mirror swap will break crash dumps. Press the kbd:[Enter] key to activate it or not. * `Encrypt Swap?` - Whether to encrypt the swap. This will encrypt the swap with a temporary key each time the system boots, and discards it on reboot. Press the kbd:[Enter] key to choose to activate it or not. More information about swap encryption in crossref:disks[swap-encrypting,“Encrypting Swap”]. * `ZFS Pool Options` - Specifies additional pool properties to apply when the ZFS root pool is created. More information about the options can be found in man:zpool-create[8] and man:zpoolprops[7]. Select kbd:[T] to configure the `Pool Type` and the disk(s) that will constitute the pool. [[bsdinstall-zfs-vdev_type]] .ZFS Pool Type image::bsdinstall-zfs-vdev_type.png[Menu requesting the Virtual Device type. Ex: stripe, mirror, raidz1] Here is a summary of the `Pool Type` that can be selected in this menu: * `stripe` - Striping provides maximum storage of all connected devices, but no redundancy. If just one disk fails the data on the pool is lost irrevocably. * `mirror` - Mirroring stores a complete copy of all data on every disk. Mirroring provides good read performance because data is read from all disks in parallel. Write performance is slower as the data must be written to all disks in the pool. Allows all but one disk to fail. This option requires at least two disks. * `raid10` - Striped mirrors. Provides the best performance, but the least storage. This option needs at least an even number of disks and a minimum of four disks. * `raidz1` - Single Redundant RAID. Allow one disk to fail concurrently. This option needs at least three disks. * `raidz2` - Double Redundant RAID. Allows two disks to fail concurrently. This option needs at least four disks. * `raidz3` - Triple Redundant RAID. Allows three disks to fail concurrently. This option needs at least five disks. Once a `Pool Type` has been selected, a list of available disks is displayed, and the user is prompted to select one or more disks to make up the pool. The configuration is then validated to ensure that enough disks are selected. If validation fails, select btn:[] to return to the list of disks or btn:[] to change the `Pool Type`. [[bsdinstall-zfs-disk_select]] .Disk Selection image::bsdinstall-zfs-disk_select.png[Menu requesting how many disks will be added to the pool] [[bsdinstall-zfs-vdev_invalid]] .Invalid Selection image::bsdinstall-zfs-vdev_invalid.png[Menu indicating that not enough disks have been selected] If one or more disks are missing from the list, or if disks were attached after the installer was started, select btn:[- Rescan Devices] to repopulate the list of available disks. [[bsdinstall-zfs-rescan-devices]] .Rescan Devices image::bsdinstall-zfs-rescan-devices.png[Device rescan] To avoid accidentally erasing the wrong disk, the btn:[- Disk Info] menu can be used to inspect each disk, including its partition table and various other information such as the device model number and serial number, if available. [[bsdinstall-zfs-disk_info]] .Analyzing a Disk image::bsdinstall-zfs-disk_info.png[Menu showing the information of the partitions.] Select kbd:[N] to configure the `Pool Name`. Enter the desired name, then select btn:[] to establish it or btn:[] to return to the main menu and leave the default name. [[bsdinstall-zfs-pool-name]] .Pool Name image::bsdinstall-zfs-pool-name.png[Menu requesting the name of the pool.] Select kbd:[S] to set the amount of swap. Enter the desired amount of swap, then select btn:[] to establish it or btn:[] to return to the main menu and let the default amount. [[bsdinstall-zfs-swap-amount]] .Swap Amount image::bsdinstall-zfs-swap-amount.png[Menu requesting the amount of swap memory] Once all options have been set to the desired values, select the btn:[>>> Install] option at the top of the menu. The installer then offers a last chance to cancel before the contents of the selected drives are destroyed to create the ZFS pool. [[bsdinstall-zfs-warning]] .Last Chance image::bsdinstall-zfs-warning.png[Menu indicating to the user that the data will be lost] If GELI disk encryption was enabled, the installer will prompt twice for the passphrase to be used to encrypt the disks. Initialization of the encryption then begins. [[bsdinstall-zfs-geli_password]] .Disk Encryption Password image::bsdinstall-zfs-geli_password.png[Menu requesting the password to encrypt the devices.] [[bsdinstall-zfs-init-encription]] .Initializing Encryption image::bsdinstall-zfs-init-encription.png[Menu showing that the encryption is initializing.] The installation then proceeds normally. To continue with the installation, go to crossref:bsdinstall[bsdinstall-fetching-distribution, Fetching Distribution Files]. [[bsdinstall-part-shell]] === Shell Mode Partitioning When creating advanced installations, the bsdinstall partitioning menus may not provide the level of flexibility required. Advanced users can select the btn:[Shell] option from the partitioning menu in order to manually partition the drives, create the file system(s), populate `/tmp/bsdinstall_etc/fstab`, and mount the file systems under `/mnt`. Once this is done, type `exit` to return to bsdinstall and continue the installation. [[bsdinstall-fetching-distribution]] == Fetching Distribution Files Installation time will vary depending on the distributions chosen, installation media, and speed of the computer. A series of messages will indicate the progress. First, the installer formats the selected disk(s) and initializes the partitions. Next, in the case of a `bootonly media` or `mini memstick`, it downloads the selected components: [[bsdinstall-distfile-fetching]] .Fetching Distribution Files image::bsdinstall-distfile-fetching.png[Menu showing the download of the different components.] Next, the integrity of the distribution files is verified to ensure they have not been corrupted during download or misread from the installation media: [[bsdinstall-distfile-verify]] .Verifying Distribution Files image::bsdinstall-distfile-verifying.png[Menu showing the verification of the different components.] Finally, the verified distribution files are extracted to the disk: [[bsdinstall-distfile-extract]] .Extracting Distribution Files image::bsdinstall-distfile-extracting.png[Menu showing the extraction of the different components.] Once all requested distribution files have been extracted, bsdinstall displays the first post-installation configuration screen. The available post-configuration options are described in the next section. [[bsdinstall-post]] == Network Interfaces, Accounts, Time Zone, Services and Hardening [[bsdinstall-post-root]] === Setting the `root` Password First, the `root` password must be set. While entering the password, the characters being typed are not displayed on the screen. The password must be entered twice to prevent typing errors. [[bsdinstall-post-set-root-passwd]] .Setting the `root` Password image::bsdinstall-post-root-passwd.png[Menu showing requesting the password for the root user.] [[bsdinstall-config-network-dev]] === Configuring Network Interfaces Next, a list of the network interfaces found on the computer is shown. Select the interface to configure. [[bsdinstall-configure-net-interface]] .Choose a Network Interface image::bsdinstall-configure-network-interface.png[Menu showing the different network interfaces to configure.] If an Ethernet interface is selected, the installer will skip ahead to the menu shown in crossref:bsdinstall[bsdinstall-configure-net-ipv4,Choose IPv4 Networking]. If a wireless network interface is chosen, the system will instead scan for wireless access points: [[bsdinstall-wireless-scan]] .Scanning for Wireless Access Points image::bsdinstall-configure-wireless-scan.png[Menu showing wireless network scanning.] Wireless networks are identified by a Service Set Identifier (SSID); a short, unique name given to each network. SSIDs found during the scan are listed, followed by a description of the encryption types available for that network. If the desired SSID does not appear in the list, select btn:[Rescan] to scan again. If the desired network still does not appear, check for problems with antenna connections or try moving the computer closer to the access point. Rescan after each change is made. [[bsdinstall-wireless-accesspoints]] .Choosing a Wireless Network image::bsdinstall-configure-wireless-accesspoints.png[Menu showing the different wireless networks to connect to.] Next, enter the encryption information for connecting to the selected wireless network. WPA2 encryption is strongly recommended over older encryption types such as WEP, which offer little security. If the network uses WPA2, input the password, also known as the Pre-Shared Key (PSK). For security reasons, the characters typed into the input box are displayed as asterisks. [[bsdinstall-wireless-wpa2]] .WPA2 Setup image::bsdinstall-configure-wireless-wpa2setup.png[Menu requesting the wireless network password.] Next, choose whether or not an IPv4 address should be configured on the Ethernet or wireless interface: [[bsdinstall-configure-net-ipv4]] .Choose IPv4 Networking image::bsdinstall-configure-network-interface-ipv4.png[Menu indicating if IPv4 wants to be configured for the selected interface.] There are two methods of IPv4 configuration. DHCP will automatically configure the network interface correctly and should be used if the network provides a DHCP server. Otherwise, the addressing information needs to be input manually as a static configuration. [NOTE] ==== Do not enter random network information as it will not work. If a DHCP server is not available, obtain the information listed in crossref:bsdinstall[bsdinstall-collect-network-information, Required Network Information] from the network administrator or Internet service provider. ==== If a DHCP server is available, select btn:[Yes] in the next menu to automatically configure the network interface. The installer will appear to pause for a minute or so as it finds the DHCP server and obtains the addressing information for the system. [[bsdinstall-net-ipv4-dhcp]] .Choose IPv4 DHCP Configuration image::bsdinstall-configure-network-interface-ipv4-dhcp.png[Menu indicating if DHCP wants to be configured for the selected interface.] If a DHCP server is not available, select btn:[No] and input the following addressing information in this menu: [[bsdinstall-net-ipv4-static]] .IPv4 Static Configuration image::bsdinstall-configure-network-interface-ipv4-static.png[Menu requesting data to configure IPv4 network.] * `IP Address` - The IPv4 address assigned to this computer. The address must be unique and not already in use by another device on the local network. * `Subnet Mask` - The subnet mask for the network. * `Default Router` - The IP address of the network's default gateway. The next screen will ask if the interface should be configured for IPv6. If IPv6 is available and desired, choose btn:[Yes] to select it. [[bsdinstall-net-ipv6]] .Choose IPv6 Networking image::bsdinstall-configure-network-interface-ipv6.png[Menu indicating if IPv6 wants to be configured for the selected interface.] IPv6 also has two methods of configuration. StateLess Address AutoConfiguration (SLAAC) will automatically request the correct configuration information from a local router. -Refer to http://tools.ietf.org/html/rfc4862[rfc4862] for more information. +Refer to https://tools.ietf.org/html/rfc4862[rfc4862] for more information. Static configuration requires manual entry of network information. If an IPv6 router is available, select btn:[Yes] in the next menu to automatically configure the network interface. The installer will appear to pause for a minute or so as it finds the router and obtains the addressing information for the system. [[bsdinstall-net-ipv6-slaac]] .Choose IPv6 SLAAC Configuration image::bsdinstall-configure-network-interface-slaac.png[Menu indicating if SLAAC wants to be configured for the selected interface.] If an IPv6 router is not available, select btn:[No] and input the following addressing information in this menu: [[bsdinstall-net-ipv6-static]] .IPv6 Static Configuration image::bsdinstall-configure-network-interface-ipv6-static.png[Menu requesting data to configure IPv6 network.] * `IPv6 Address` - The IPv6 address assigned to this computer. The address must be unique and not already in use by another device on the local network. * `Default Router` - The IPv6 address of the network's default gateway. The last network configuration menu is used to configure the Domain Name System (DNS) resolver, which converts hostnames to and from network addresses. If DHCP or SLAAC was used to autoconfigure the network interface, the `Resolver Configuration` values may already be filled in. Otherwise, enter the local network's domain name in the `Search` field. `DNS #1` and `DNS #2` are the IPv4 and/or IPv6 addresses of the DNS servers. At least one DNS server is required. [[bsdinstall-net-dns-config]] .DNS Configuration image::bsdinstall-configure-network-ipv4-dns.png[Menu requesting data to configure DNS for the network.] Once the interface is configured, select a mirror site that is located in the same region of the world as the computer on which FreeBSD is being installed. Files can be retrieved more quickly when the mirror is close to the target computer, reducing installation time. [TIP] ==== -Selecting `http://download.freebsd.org Main Site (GeoDNS, HTTP)` or `ftp://download.freebsd.org Main Site (GeoDNS, FTP)` will automatically route to the nearest mirror. +Selecting `https://download.freebsd.org Main Site (GeoDNS, HTTPS)` or `ftp://download.freebsd.org Main Site (GeoDNS, FTP)` will automatically route to the nearest mirror. ==== [[bsdinstall-netinstall-mirror]] .Choosing a Mirror image::bsdinstall-netinstall-mirrorselect.png[Menu requesting a network mirror.] [[bsdinstall-timezone]] === Setting the Time Zone The next series of menus are used to determine the correct local time by selecting the geographic region, country, and time zone. Setting the time zone allows the system to automatically correct for regional time changes, such as daylight savings time, and perform other time zone related functions properly. The example shown here is for a machine located in the mainland time zone of Spain, Europe. The selections will vary according to the geographical location. [[bsdinstall-timezone-region]] .Select a Region image::bsdinstall-timezone-region.png[Menu requesting the timezone region.] The appropriate region is selected using the arrow keys and then pressing kbd:[Enter]. [[bsdinstall-timezone-country]] .Select a Country image::bsdinstall-timezone-country.png[Menu requesting the timezone country.] Select the appropriate country using the arrow keys and press kbd:[Enter]. [[bsdinstall-timezone-zone]] .Select a Time Zone image::bsdinstall-timezone-zone.png[Menu requesting the timezone zone.] The appropriate time zone is selected using the arrow keys and pressing kbd:[Enter]. [[bsdinstall-timezone-confirmation]] .Confirm Time Zone image::bsdinstall-timezone-confirm.png[Menu requesting confirmation of the selected timezone.] Confirm the abbreviation for the time zone is correct. [[bsdinstall-timezone-date]] .Select Date image::bsdinstall-timezone-date.png[Menu requesting the system date.] The appropriate date is selected using the arrow keys and then pressing btn:[Set Date]. Otherwise, the date selection can be skipped by pressing btn:[Skip]. [[bsdinstall-timezone-time]] .Select Time image::bsdinstall-timezone-time.png[Menu requesting the system time.] The appropriate time is selected using the arrow keys and then pressing btn:[Set Time]. Otherwise, the time selection can be skipped by pressing btn:[Skip]. [[bsdinstall-sysconf]] === Enabling Services The next menu is used to configure which system services will be started whenever the system boots. All of these services are optional. Only start the services that are needed for the system to function. [[bsdinstall-config-serv]] .Selecting Additional Services to Enable image::bsdinstall-config-services.png[Menu showing the different services available.] Here is a summary of the services that can be enabled in this menu: * `sshd` - The Secure Shell (SSH) daemon is used to remotely access a system over an encrypted connection. Only enable this service if the system should be available for remote logins. * `ntpd` - The Network Time Protocol (NTP) daemon for automatic clock synchronization. Enable this service when wanting to synchronise the system clock with a remote time server or pool. * `ntpd_sync_on_start` - Enabled, man:ntpd[8] is invoked with the `-g` flag during system startup, performing an immediate, one-time clock synchronization at boot time. * `local_unbound` - Enable the DNS local unbound. It is necessary to keep in mind that this is a configuration only meant for use as a local caching forwarding resolver. If the objective is to set up a resolver for the entire network, install package:dns/unbound[]. * `powerd` - System power control utility for power control and energy saving. * `moused` - Enable this service if the mouse will be used from the command-line system console. * `dumpdev` - Crash dumps are useful when debugging issues with the system, so users are encouraged to enable them. [[bsdinstall-hardening]] === Enabling Hardening Security Options The next menu is used to configure which security options will be enabled. All of these options are optional. But their use is encouraged. [[bsdinstall-hardening-options]] .Selecting Hardening Security Options image::bsdinstall-hardening.png[Menu shoring the different hardening security options.] Here is a summary of the options that can be enabled in this menu: * `hide_uids` - Hide processes running as other users (UID). This prevents unprivileged users from seeing running processes from other users. * `hide_gids` - Hide processes running as other groups (GID). This prevents unprivileged users from seeing running processes from other groups. * `hide_jail` - Hide processes running in jails. This prevents unprivileged users from seeing processes running inside jails. * `read_msgbuf` - Disable reading kernel message buffer for unprivileged users. Prevent unprivileged users from using man:dmesg[8] to view messages from the kernel's log buffer. * `proc_debug` - Disable process debugging facilities for unprivileged users. Disables a variety of unprivileged inter-process debugging services, including some procfs functionality, `ptrace()`, and `ktrace()`. Please note that this will also prevent debugging tools such as man:lldb[1], man:truss[1] and man:procstat[1], as well as some built-in debugging facilities in certain scripting languages like PHP. * `random_pid` - Randomize the PID of processes. * `clear_tmp` - Clean `/tmp` when the system starts up. * `disable_syslogd` - Disable opening the syslogd network socket. By default, FreeBSD runs syslogd in a secure way with `-s`. This prevents the daemon from listening for incoming UDP requests on port 514. With this option enabled, syslogd will instead run with `-ss`, which prevents syslogd from opening any port. For more information, see man:syslogd[8]. * `secure_console` - Make the command prompt request the `root` password when entering single-user mode. * `disable_ddtrace` - DTrace can run in a mode that affects the running kernel. Destructive actions may not be used unless explicitly enabled. Use `-w` to enable this option when using DTrace. For more information, see man:dtrace[1]. [[bsdinstall-addusers]] === Add Users The next menu prompts to create at least one user account. It is recommended to log into the system using a user account rather than as `root`. When logged in as `root`, there are essentially no limits or protection on what can be done. Logging in as a normal user is safer and more secure. Select btn:[Yes] to add new users. [[bsdinstall-add-user1]] .Add User Accounts image::bsdinstall-adduser1.png[Menu requesting if a user want to be added to the system.] Follow the prompts and input the requested information for the user account. The example shown in crossref:bsdinstall[bsdinstall-add-user2,Enter User Information] creates the `asample` user account. [[bsdinstall-add-user2]] .Enter User Information image::bsdinstall-adduser2.png[Menu requesting different information for the new user.] Here is a summary of the information to input: * `Username` - The name the user will enter to log in. A common convention is to use the first letter of the first name combined with the last name, as long as each username is unique for the system. The username is case sensitive and should not contain any spaces. * `Full name` - The user's full name. This can contain spaces and is used as a description for the user account. * `Uid` - User ID. This is typically left blank so the system automatically assigns a value. * `Login group` - The user's group. This is typically left blank to accept the default. * `Invite _user_ into other groups?` - Additional groups to which the user will be added as a member. If the user needs administrative access, type `wheel` here. * `Login class` - Typically left blank for the default. * `Shell` - Type in one of the listed values to set the interactive shell for the user. Refer to crossref:basics[shells,Shells] for more information about shells. * `Home directory` - The user's home directory. The default is usually correct. * `Home directory permissions` - Permissions on the user's home directory. The default is usually correct. * `Use password-based authentication?` - Typically `yes` so that the user is prompted to input their password at login. * `Use an empty password?` - Typically `no` as empty or blank passwords are insecure. * `Use a random password?` - Typically `no` so that the user can set their own password in the next prompt. * `Enter password` - The password for this user. Typed-in characters will not be shown on the screen. * `Enter password again` - The password must be typed again for verification. * `Lock out the account after creation?` - Typically `no` so that the user can log in. After entering all the details, a summary is shown for review. If a mistake was made, enter `no` to correct it. Once everything is correct, enter `yes` to create the new user. [[bsdinstall-add-user3]] .Exit User and Group Management image::bsdinstall-adduser3.png[Menu showing the information of the new user and requesting if everything is correct.] If there are more users to add, answer the `Add another user?` question with `yes`. Enter `no` to finish adding users and continue the installation. For more information on adding users and user management, see crossref:basics[users-synopsis,Users and Basic Account Management]. [[bsdinstall-final-conf]] === Final Configuration After everything has been installed and configured, a final chance is provided to modify settings. [[bsdinstall-final-config]] .Final Configuration image::bsdinstall-finalconfiguration.png[Menu showing different options to perform before finishing the installation. Ex: Add user, Time Zone, etc.] Use this menu to make any changes or to do any additional configuration before completing the installation. * `Add User` - Described in crossref:bsdinstall[bsdinstall-addusers, Add Users]. * `Root Password` - Described in crossref:bsdinstall[bsdinstall-post-root, Setting the `root` Password]. * `Hostname` - Described in crossref:bsdinstall[bsdinstall-hostname, Setting the Hostname]. * `Network` - Described in crossref:bsdinstall[bsdinstall-config-network-dev, Configuring Network Interfaces]. * `Services` - Described in crossref:bsdinstall[bsdinstall-sysconf, Enabling Services]. * `System Hardening` - Described in crossref:bsdinstall[bsdinstall-hardening, Enabling Hardening Security Options]. * `Time Zone` - Described in crossref:bsdinstall[bsdinstall-timezone, Setting the Time Zone]. * `Firmware` - Download and install required firmware for system components such as Wi-Fi or graphics cards. * `Handbook` - Download and install the FreeBSD Handbook. Once configuration is complete, select btn:[Exit]. [[bsdinstall-final-modification-shell]] .Manual Configuration image::bsdinstall-final-modification-shell.png[Menu showing that the installation has finished. And asking if a shell to make manual changes should open.] bsdinstall will prompt for any additional configuration that needs to be done before rebooting into the new system. Select btn:[Yes] to exit to a shell within the new system or btn:[No] to proceed to the last step of the installation. [[bsdinstall-final-main]] .Complete the Installation image::bsdinstall-mainexit.png[Menu showing that the installation has finished and asking whether to reboot the system or access the Live CD.] If further configuration or special setup is needed, select btn:[Live CD] to boot the install media into Live CD mode. If the installation is complete, select btn:[Reboot] to reboot the computer and start the new FreeBSD system. Do not forget to remove the FreeBSD install media or the computer might boot from it again. As FreeBSD boots, informational messages are displayed. After the system finishes booting, a login prompt is displayed. At the `login:` prompt, enter the username added during the installation. Avoid logging in as `root`. Refer to crossref:basics[users-superuser,The Superuser Account] for instructions on how to become the superuser when administrative access is needed. The messages that appear during boot can be reviewed by pressing kbd:[Scroll-Lock] to turn on the scroll-back buffer. The kbd:[PgUp], kbd:[PgDn], and arrow keys can be used to scroll back through the messages. When finished, press kbd:[Scroll-Lock] again to unlock the display and return to the console. To review these messages once the system has been up for some time, type `less /var/run/dmesg.boot` from a command prompt. Press kbd:[q] to return to the command line after viewing. If sshd was enabled in crossref:bsdinstall[bsdinstall-config-serv,Selecting Additional Services to Enable], the first boot might be a bit slower as the system generates SSH host keys. Subsequent boots will be faster. The fingerprints of the keys are then displayed as in the following example: [source,shell] .... Generating public/private rsa1 key pair. Your identification has been saved in /etc/ssh/ssh_host_key. Your public key has been saved in /etc/ssh/ssh_host_key.pub. The key fingerprint is: 10:a0:f5:af:93:ae:a3:1a:b2:bb:3c:35:d9:5a:b3:f3 root@machine3.example.com The key's randomart image is: +--[RSA1 1024]----+ | o.. | | o . . | | . o | | o | | o S | | + + o | |o . + * | |o+ ..+ . | |==o..o+E | +-----------------+ Generating public/private dsa key pair. Your identification has been saved in /etc/ssh/ssh_host_dsa_key. Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: 7e:1c:ce:dc:8a:3a:18:13:5b:34:b5:cf:d9:d1:47:b2 root@machine3.example.com The key's randomart image is: +--[ DSA 1024]----+ | .. . .| | o . . + | | . .. . E .| | . . o o . . | | + S = . | | + . = o | | + . * . | | . . o . | | .o. . | +-----------------+ Starting sshd. .... Refer to crossref:security[openssh,"OpenSSH"] for more information about fingerprints and SSH. FreeBSD does not install a graphical environment by default. Refer to crossref:x11[x11,The X Window System] for more information about installing and configuring a graphical window manager. Proper shutdown of a FreeBSD computer helps protect data and hardware from damage. _Do not turn off the power before the system has been properly shut down!_ If the user is a member of the `wheel` group, become the superuser by typing `su` at the command line and entering the `root` password. Then, type `shutdown -p now` and the system will shut down cleanly, and, if the hardware supports it, turn itself off. [[bsdinstall-install-trouble]] == Troubleshooting This section covers basic installation troubleshooting, such as common problems people have reported. Check the Hardware Notes listed on the link:https://www.FreeBSD.org/releases/[FreeBSD Release Information] page for the version of FreeBSD to make sure the hardware is supported. [NOTE] ==== Some installation problems can be avoided or alleviated by updating the firmware on various hardware components, most notably the motherboard. Motherboard firmware is usually referred to as the BIOS. Most motherboard and computer manufacturers have a website for upgrades and upgrade information. Manufacturers generally advise against upgrading the motherboard BIOS unless there is a good reason for doing so, like a critical update. The upgrade process _can_ go wrong, leaving the BIOS incomplete and the computer inoperative. ==== If the system hangs while probing hardware during boot or behaves strangely during the installation process, ACPI may be the culprit. FreeBSD makes extensive use of the system ACPI service on the i386 and amd64 platforms to aid in system configuration if it is detected during boot. Unfortunately, some bugs still exist in both the ACPI driver and within system motherboards and BIOS firmware. ACPI can be disabled by setting the `hint.acpi.0.disabled` hint in the third stage boot loader: [source,shell] .... set hint.acpi.0.disabled="1" .... This is reset each time the system is booted, so it is necessary to add `hint.acpi.0.disabled="1"` to the file `/boot/loader.conf`. More information about the boot loader can be found in crossref:boot[boot-synopsis,“Synopsis”]. [[using-live-cd]] == Using the Live CD The welcome menu of bsdinstall, shown in crossref:bsdinstall[bsdinstall-choose-mode,Welcome Menu], provides a btn:[Live CD] option. This is useful for those who are still wondering whether FreeBSD is the right operating system for them and want to test some of the features before installing. The following points should be noted before using the btn:[Live CD]: * To gain access to the system, authentication is required. The username is `root` and the password is blank. * As the system runs directly from the installation media, performance will be significantly slower than that of a system installed on a hard disk. * This option only provides a command prompt and not a graphical interface. diff --git a/documentation/content/en/books/handbook/desktop/_index.adoc b/documentation/content/en/books/handbook/desktop/_index.adoc index 4820ae5b4d..9e12c540a6 100644 --- a/documentation/content/en/books/handbook/desktop/_index.adoc +++ b/documentation/content/en/books/handbook/desktop/_index.adoc @@ -1,1149 +1,1149 @@ --- title: Chapter 8. Desktop Environments part: Part II. Common Tasks prev: books/handbook/partii next: books/handbook/multimedia description: This chapter demonstrates how to install numerous desktop environments, including web browsers, productivity software, document viewers, and financial software tags: ["desktop", "KDE", "Plasma", "GNOME", "XFCE", "MATE", "Cinnamon", "LXQT", "browsers", "Firefox", "Chromium", "Iridium", "Falkon", "Konqueror", "Epiphany", "qutebrowser", "Dillo", "Links", "w3m", "Development tools", "Visual Studio Code", "Qt Creator", "Kdevelop", "Eclipse IDE", "Vim", "Neovim", "GNU Emacs", "Productivity", "LibreOffice", "Calligra", "AbiWord", "Viewers", "Okular", "Evince", "ePDFView", "Xpdf", "Finance", "KMyMoney", "GnuCash"] showBookMenu: true weight: 11 params: path: "/books/handbook/desktop/" --- [[desktop]] = Desktop Environments :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumoffset: 8 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/desktop/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[desktop-synopsis]] == Synopsis While FreeBSD is popular as a server for its performance and stability, it is also well suited for day-to-day use as a desktop. With over {numports} applications available in the FreeBSD ports tree, it is straightforward to build a customized desktop that can run a wide variety of desktop applications. This chapter demonstrates how to install popular desktop environments as well as desktop applications such as web browsers, productivity software, document viewers, and financial software. Prerequisites: * Readers of this chapter should already understand how to install either the crossref:x11[x11,X Window System] or crossref:wayland[wayland,Wayland] on FreeBSD. * Readers are instructed throughout this chapter to install official packages. Refer to the section on crossref:ports[ports-using,using the ports collection] to build customized packages from ports. [[desktop-environments]] == Desktop Environments This section describes how to install and configure some popular desktop environments on a FreeBSD system. A desktop environment can range from a simple window manager to a complete suite of desktop applications. .Supported desktop environments [options="header", cols="1,1,1"] |=== | Name | License | Package | Plasma | GPL 2.0 or later | package:x11/kde[] | GNOME | GPL 2.0 or later | package:x11/gnome[] | XFCE | GPL, LGPL, BSD | package:x11-wm/xfce4[] | MATE | GPL 2.0, LGPL 2.0 | package:x11/mate[] | Cinnamon | GPL 2.0 or later | package:x11/cinnamon[] | LXQT | GPL, LGPL | package:x11-wm/lxqt[] |=== [[kde-environment]] === Plasma Plasma is an easy-to-use desktop environment made by the KDE community. This desktop provides a suite of applications with a consistent look and feel, a standardized menu and toolbars, keybindings, color-schemes, internationalization, and a centralized, dialog-driven desktop configuration. More information on Plasma can be found at the link:https://kde.org/plasma-desktop[Plasma homepage]. For FreeBSD-specific information, consult the link:https://freebsd.kde.org/[FreeBSD homepage at KDE]. [[kde-meta-install]] ==== Install Plasma meta package To install the Plasma desktop with a basic set of KDE Applications, execute: [source,shell] .... # pkg install kde .... Additional KDE Applications are tagged with the `kde-applications` category. Search for them by executing the following command: [source,shell] .... % pkg search -S origin kde-applications .... [[kde-minimal-install]] ==== Minimal Plasma installation To install a minimal Plasma desktop, execute: [source,shell] .... # pkg install plasma6-plasma .... [TIP] ==== This installation is *really* minimal. The Konsole terminal emulator must be installed separately executing: [source,shell] .... # pkg install konsole .... ==== [[kde-configuration]] ==== Configure Plasma Plasma uses man:dbus-daemon[1] for a message bus and hardware abstraction. This application is automatically installed as a dependency of Plasma. Enable the D-Bus service in man:rc.conf[5] to start at system boot: [source,shell] .... # sysrc dbus_enable="YES" .... [[kde-start]] ==== Start Plasma The preferred way to start Plasma is automatically via the package:x11/sddm[] display manager. To install package:x11/sddm[], execute: [source,shell] .... # pkg install sddm .... Enable the SDDM service in man:rc.conf[5] to start at system boot: [source,shell] .... # sysrc sddm_enable="YES" .... A keyboard language, in this case Spanish, can be set in SDDM with the following command: [source,shell] .... # sysrc sddm_lang="es_ES" .... Alternatively, start Plasma in an Xorg session is by manually invoking man:startx[1]. For this to work, the following line is needed in ~/.xinitrc: [source,shell] .... % echo "exec dbus-launch --exit-with-x11 ck-launch-session startplasma-x11" > ~/.xinitrc .... Experimentally, start Plasma manually in a Wayland session by executing the following command: [source,shell] .... % exec dbus-launch ck-launch-session startplasma-wayland .... [[gnome-environment]] === GNOME GNOME is a user-friendly desktop environment. It includes a panel for starting applications and displaying status, a desktop, a set of tools and applications, and a set of conventions that make it easy for applications to cooperate and be consistent with each other. [[gnome-meta-install]] ==== Install GNOME meta package To install the GNOME meta package with GNOME Desktop and Applications, execute: [source,shell] .... # pkg install gnome .... [[gnome-minimal-install]] ==== Minimal GNOME installation To install the GNOME-lite meta package with a GNOME desktop slimmed down for only the basics, execute: [source,shell] .... # pkg install gnome-lite .... [[gnome-configuration]] ==== Configure GNOME GNOME requires `/proc` to be mounted. Add this line to `/etc/fstab` to mount this file system automatically during system startup: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# proc /proc procfs rw 0 0 .... GNOME uses man:dbus-daemon[1] for a message bus and hardware abstraction. This application is automatically installed as a dependency of GNOME. Enable D-BUS service in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc dbus_enable="YES" .... [[gnome-start]] ==== Start GNOME GNOME Display Manager is the preferred display manager for GNOME. GDM is installed as part of the GNOME package. Enable GDM in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc gdm_enable="YES" .... A second method to start GNOME is by manually invoking man:startx[1]. For this to work, the following line is needed in `~/.xinitrc`: [source,shell] .... % echo "exec gnome-session" > ~/.xinitrc .... [[xfce-environment]] === XFCE XFCE is a desktop environment based on the GTK+, lightweight and provides a simple, efficient, easy-to-use desktop. It is fully configurable, has a main panel with menus, applets, and application launchers, provides a file manager and sound manager, and is themeable. Since it is fast, light, and efficient, it is ideal for older or slower machines with memory limitations. [[xfce-install]] ==== Install XFCE To install the XFCE meta package, execute: [source,shell] .... # pkg install xfce .... [[xfce-configuration]] ==== Configure XFCE XFCE uses man:dbus-daemon[1] for a message bus and hardware abstraction. This application is automatically installed as a dependency of XFCE. Enable D-BUS in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc dbus_enable="YES" .... [[xfce-start]] ==== Start XFCE package:x11/lightdm[] is a display manager that supports different display technologies and is a good choice as it is very lightweight, requires little memory usage, and has fast performance. To install it, execute: [source,shell] .... # pkg install lightdm lightdm-gtk-greeter .... Enable lightdm in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc lightdm_enable="YES" .... A second method to start XFCE is by manually invoking man:startx[1]. For this to work, the following line is needed in `~/.xinitrc`: [source,shell] .... % echo '. /usr/local/etc/xdg/xfce4/xinitrc' > ~/.xinitrc .... [[mate-environment]] === MATE The MATE Desktop Environment is the continuation of GNOME 2. It provides an intuitive and attractive desktop environment using traditional metaphors. [[mate-meta-install]] ==== Install MATE meta package To install the MATE meta package that includes the MATE Desktop with some extra applications such as text editor, archiver manager, etc., execute: [source,shell] .... # pkg install mate .... [[mate-minimal-install]] ==== Minimal MATE installation To install the MATE lite meta package with MATE desktop slimmed down for only the basics, execute: [source,shell] .... # pkg install mate-base .... [[mate-configuration]] ==== Configure MATE MATE requires `/proc` to be mounted. Add this line to `/etc/fstab` to mount this file system automatically during system startup: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# proc /proc procfs rw 0 0 .... MATE uses man:dbus-daemon[1] for a message bus and hardware abstraction. This application is automatically installed as a dependency of MATE. Enable D-BUS in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc dbus_enable="YES" .... [[mate-start]] ==== Start MATE package:x11/lightdm[] is a display manager that supports different display technologies and is a good choice as it is very lightweight, requires little memory usage, and has fast performance. To install it, execute: [source,shell] .... # pkg install lightdm lightdm-gtk-greeter .... Enable lightdm in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc lightdm_enable="YES" .... A second method to start MATE is by manually invoking man:startx[1]. For this to work, the following line is needed in `~/.xinitrc`: [source,shell] .... % echo "exec dbus-launch --exit-with-x11 ck-launch-session mate-session" > ~/.xinitrc .... [[cinnamon-environment]] === Cinnamon Cinnamon is a UNIX(R) desktop which provides advanced innovative features and a traditional user experience. The desktop layout is similar to Gnome 2. The underlying technology is forked from Gnome Shell. The emphasis is put on making users feel at home and providing them with an easy to use and comfortable desktop experience. [[cinnamon-install]] ==== Install Cinnamon To install the Cinnamon package, execute: [source,shell] .... # pkg install cinnamon .... [[cinnamon-configuration]] ==== Configure Cinnamon Cinnamon requires `/proc` to be mounted. Add this line to `/etc/fstab` to mount this file system automatically during system startup: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# proc /proc procfs rw 0 0 .... Cinnamon uses man:dbus-daemon[1] for a message bus and hardware abstraction. This application is automatically installed as a dependency of Cinnamon. Enable D-BUS in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc dbus_enable="YES" .... [[cinnamon-start]] ==== Start Cinnamon package:x11/lightdm[] is a display manager that supports different display technologies and is a good choice as it is very lightweight, requires little memory usage, and has fast performance. To install it execute: [source,shell] .... # pkg install lightdm lightdm-gtk-greeter .... Enable lightdm in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc lightdm_enable="YES" .... A second method to start Cinnamon is by manually invoking man:startx[1]. For this to work, the following line is needed in `~/.xinitrc`: [source,shell] .... % echo "exec dbus-launch --exit-with-x11 ck-launch-session cinnamon-session" > ~/.xinitrc .... [[lxqt-environment]] === LXQT LXQt is an advanced, easy-to-use, and fast desktop environment based on Qt technologies. It has been tailored for users who value simplicity, speed, and an intuitive interface. Unlike most desktop environments, LXQt also works fine with less powerful machines. [[lxqt-install]] ==== Install LXQT To install the LXQT meta package, execute: [source,shell] .... # pkg install lxqt .... [[lxqt-configuration]] ==== Configure LXQT LXQT requires `/proc` to be mounted. Add this line to `/etc/fstab` to mount this file system automatically during system startup: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# proc /proc procfs rw 0 0 .... LXQT uses man:dbus-daemon[1] for a message bus and hardware abstraction. This application is automatically installed as a dependency of LXQT. Enable D-BUS in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc dbus_enable="YES" .... [[lxqt-start]] ==== Start LXQT The preferred LXQT display manager is package:x11/sddm[]. To install package:x11/sddm[], execute: [source,shell] .... # pkg install sddm .... Enable SDDM service in `/etc/rc.conf` to start at system boot: [source,shell] .... # sysrc sddm_enable="YES" .... The keyboard language can be set in SDDM by running the following command (for example, for Spanish): [source,shell] .... # sysrc sddm_lang="es_ES" .... A second method to start LXQT is by manually invoking man:startx[1]. For this to work, the following line is needed in `~/.xinitrc`: [source,shell] .... % echo "exec dbus-launch --exit-with-x11 ck-launch-session startlxqt" > ~/.xinitrc .... [[desktop-browsers]] == Browsers This section describes how to install and configure some popular web browsers on a FreeBSD system, from full web browsers with high resource consumption to command line web browsers with reduced resource usage. .Supported browsers [options="header", cols="1,1,1,1"] |=== | Name | License | Package | Resources Needed | Firefox | MPL 2.0 | package:www/firefox[] | Heavy | Chromium | BSD-3 and others | package:www/chromium[] | Heavy | Iridium browser | BSD-3 and others | package:www/iridium-browser[] | Heavy | Falkon | MPL 2.0 | package:www/falkon-qtonly[] | Heavy | Konqueror | GPL 2.0 or later | package:x11-fm/konqueror[] | Medium | Gnome Web (Epiphany) | GPL 3.0 or later | package:www/epiphany[] | Medium | qutebrowser | GPL 3.0 or later | package:www/qutebrowser[] | Medium | Dillo | GPL 3.0 or later | package:www/dillo2[] | Light | Links | GPL 2.0 or later | package:www/links[] | Light | w3m | MIT | package:www/w3m[] | Light |=== [[firefox]] === Firefox Firefox is an open source browser that features a standards-compliant HTML display engine, tabbed browsing, popup blocking, extensions, improved security, and more. Firefox is based on the Mozilla codebase. To install the package of the latest release version of Firefox, execute: [source,shell] .... # pkg install firefox .... To instead install Firefox Extended Support Release (ESR) version, execute: [source,shell] .... # pkg install firefox-esr .... [[chromium]] === Chromium Chromium is an open source browser project that aims to build a safer, faster, and more stable web browsing experience. Chromium features tabbed browsing, popup blocking, extensions, and much more. Chromium is the open source project upon which the Google Chrome web browser is based. To install Chromium, execute: [source,shell] .... # pkg install chromium .... [NOTE] ==== The executable for Chromium is [.filename]#/usr/local/bin/chrome#, not [.filename]#/usr/local/bin/chromium#. Available search engines in Chromium are region-locked. Refer to the section on crossref:l10n[using-localization, Using Localization] to configure an appropriate locale. ==== [[iridium]] === Iridium browser Iridium is a free, open, and libre browser modification of the Chromium code base, with privacy being enhanced in several key areas. Automatic transmission of partial queries, keywords, metrics to central services is inhibited and only occurs with consent. To install Iridium, execute: [source,shell] .... # pkg install iridium-browser .... [[falkon]] === Falkon Falkon is a new-ish and very fast QtWebEngine browser. It aims to be a lightweight web browser available on all major platforms. Falkon has all standard functions someone can expect from a web browser. It includes bookmarks, history (both also in sidebar) and tabs. Beyond that, AdBlock plugin can block ads, Click2Flash can block Flash content and SSL Manager can edit the local CA Certificates database. To install Falkon, execute: [source,shell] .... # pkg install falkon .... [[konqueror]] === Konqueror Konqueror is more than a web browser as it is also a file manager and a multimedia viewer. It supports WebKit, a rendering engine used by many modern browsers including Chromium, as well as its own KHTML engine. To install Konqueror, execute: [source,shell] .... # pkg install konqueror .... [[gnome-web-epiphany]] === Gnome Web (Epiphany) Gnome Web (Epiphany) is a web browser designed to be as lightweight and fast as possible, at the expense of many of the features found in other browsers. To install Gnome Web (Epiphany), execute: [source,shell] .... # pkg install epiphany .... [[qutebrowser]] === qutebrowser Qutebrowser is a keyboard-focused browser with a minimal GUI. It is based on Python and PyQt5 and free software, licensed under the GPL. To install qutebrowser, execute: [source,shell] .... # pkg install qutebrowser .... [[dillo]] === Dillo Dillo aims to be a multiplatform alternative browser that is small, stable, developer-friendly, usable, fast, and extensible. This new, experimental version of Dillo is based upon FLTK toolkit, rather than GTK1, and has been substantially rewritten. To install Dillo, execute: [source,shell] .... # pkg install dillo .... [[links]] === Links A lynx-like web browser with text and graphics modes with many features like displaying tables, menus, etc. To install Links, execute: [source,shell] .... # pkg install links .... [[w3m]] === w3m w3m is a pager/text-based web browser. It is a similar application to Lynx, but it has several features Lynx does not have like rendering tables and rendering frames. To install w3m, execute: [source,shell] .... # pkg install w3m .... [[desktop-development]] == Development tools This section describes how to install and configure some popular development tools on a FreeBSD system. .Supported development tools [options="header", cols="1,1,1,1"] |=== | Name | License | Package | Resources Needed | Visual Studio Code | MIT | package:editors/vscode[] | Heavy | Qt Creator | QtGPL | package:devel/qtcreator[] | Heavy | Kdevelop | GPL 2.0 or later and LGPL 2.0 or later | package:devel/kdevelop[] | Heavy | Eclipse IDE | EPL | package:java/eclipse[] | Heavy | Vim | VIM | package:editors/vim[] | Light | Neovim | Apache 2.0 | package:editors/neovim[] | Light | GNU Emacs | GPL 3.0 or later | package:editors/emacs[] | Light |=== [[vs-code]] === Visual Studio Code Visual Studio Code is a type of tool that combines the simplicity of a code editor with what developers need for their core edit-build-debug cycle. It provides comprehensive editing and debugging support, an extensibility model, and lightweight integration with existing tools. To install Visual Studio Code, execute: [source,shell] .... # pkg install vscode .... [[qt-creator]] === Qt Creator Qt Creator is a cross-platform IDE (integrated development environment) tailored to the needs of Qt developers. Functionalities included with Qt Creator are: * code editor with C++, QML and ECMAscript support; * rapid code navigation tools; * static code checking and style hints when typing; * context sensitive help; * visual debugger; * integrated GUI layout and forms designer. To install Qt Creator, execute: [source,shell] .... # pkg install qtcreator .... [[kdevelop]] === kdevelop Open source, feature-full, plugin extensible IDE for C/C++ and other programming languages. It is based on KDevPlatform and the KDE and Qt libraries, and it has been under development since 1998. To install kdevelop, execute: [source,shell] .... # pkg install kdevelop .... [[eclipse]] === Eclipse IDE The Eclipse Platform is an open extensible IDE for anything and yet nothing in particular. The Eclipse Platform provides building blocks and a foundation for constructing and running integrated software-development tools. The Eclipse Platform allows tool builders to independently develop tools that integrate with other people's tools. To install Eclipse IDE, execute: [source,shell] .... # pkg install eclipse .... [[vim]] === Vim Vim is a highly configurable text editor built to enable efficient text editing. It is an improved version of the vi editor distributed with most UNIX systems. Vim is often called a "programmer's editor," and so useful for programming that many consider it an entire IDE. It is not just for programmers, though. Vim is perfect for all kinds of text editing, from composing email to editing configuration files. To install Vim, execute: [source,shell] .... # pkg install vim .... [[neovim]] === Neovim Neovim is an aggressive refactor of package:editors/vim[]. It represents a complete overhaul of the codebase with many sanity improvements, including sensible defaults, a built-in terminal emulator, asynchronous plugin architecture, and powerful APIs designed for speed and extensibility. It retains full compatibility with almost all Vim plugins and scripts. To install Neovim, execute: [source,shell] .... # pkg install neovim .... [[gnu-emacs]] === GNU Emacs GNU Emacs is an extensible, customizable, free/libre text editor. At its core is an interpreter for Emacs Lisp, a dialect of the Lisp programming language with extensions to support text editing. To install GNU Emacs, execute: [source,shell] .... # pkg install emacs .... [[desktop-productivity]] == Desktop office productivity When it comes to productivity, users often look for an office suite or an easy-to-use word processor. While some desktop environments like crossref:desktop[kde-environment, KDE Plasma] provide an office suite, there is no default productivity package. Several office suites and graphical word processors are available for FreeBSD, regardless of the installed desktop environments. This section demonstrates how to install the following popular productivity software and indicates if the application is resource-heavy, takes time to compile from ports, or has any major dependencies. .Supported Desktop office productivity suites [options="header", cols="1,1,1,1"] |=== | Name | License | Package | Resources Needed | LibreOffice | MPL 2.0 | package:editors/libreoffice[] | Heavy | Calligra Suite | LGPL and GPL | package:editors/calligra[] | Medium | AbiWord | GPL 2.0 or later | package:editors/abiword[] | Medium |=== [[libreoffice]] === LibreOffice -LibreOffice is a free software office suite developed by http://www.documentfoundation.org/[The Document Foundation]. +LibreOffice is a free software office suite developed by https://www.documentfoundation.org/[The Document Foundation]. It is compatible with other major office suites and available on a variety of platforms. It is a rebranded fork of Apache OpenOffice and includes applications found in a complete office productivity suite: a word processor, spreadsheet, presentation manager, drawing program, database management program, and a tool for creating and editing mathematical formulæ. It is available in a number of different languages and internationalization has been extended to interfaces, spell checkers, and dictionaries. -More information about LibreOffice can be found at http://www.libreoffice.org/[libreoffice.org]. +More information about LibreOffice can be found at https://www.libreoffice.org/[libreoffice.org]. To install LibreOffice, execute: [source,shell] .... # pkg install libreoffice .... The LibreOffice package comes by default only in English. To have a localized version of LibreOffice it is necessary to install a language pack. For example, for the version localized in Spanish, it is necessary to install the package package:editors/libreoffice-es[] with the command: [source,shell] .... # pkg install es-libreoffice .... [[calligra]] === Calligra The KDE Plasma desktop environment includes an office suite which can be installed separately from KDE Plasma. Calligra includes standard components that can be found in other office suites. Words is the word processor, Sheets is the spreadsheet program, Stage manages slide presentations, and Karbon is used to draw graphical documents. To install Calligra, execute: [source,shell] .... # pkg install calligra .... [[abiword]] === AbiWord AbiWord is a free word processing program similar in look and feel to Microsoft(R) Word. It is fast, contains many features, and is user-friendly. AbiWord can import or export many file formats, including some proprietary ones like Microsoft(R) [.filename]#.rtf#. To install AbiWord, execute: [source,shell] .... # pkg install abiword .... [[desktop-viewers]] == Document Viewers Some new document formats have gained popularity since the advent of UNIX(R) and the viewers they require may not be available in the base system. This section demonstrates how to install the following document viewers: .Supported Document Viewers [options="header", cols="1,1,1,1"] |=== | Name | License | Package | Resources Needed | Okular | GPL 2.0 | package:graphics/okular[] | Heavy | Evince | GPL 2.0 | package:graphics/evince[] | Medium | ePDFView | GPL 2.0 | package:graphics/epdfview[] | Medium | Xpdf | GPL 2.0 | package:graphics/xpdf[] | light | Zathura | Zlib | package:graphics/zathura[] | light |=== [[okular]] === Okular Okular is a universal document viewer, part of the KDE Plasma project. Okular combines excellent functionality with the versatility of supporting different kinds of documents, like PDF, Postscript, DjVu, CHM, XPS, ePub and others. To install Okular, execute: [source,shell] .... # pkg install okular .... [[evince]] === Evince Evince is a document viewer for multiple document formats including PDF and Postscript. Part of the GNOME project. The goal of evince is to replace document viewers such as ggv and gpdf with a single, simple application. To install Evince, execute: [source,shell] .... # pkg install evince .... [[epdfview]] === ePDFView ePDFView is a lightweight PDF document viewer that only uses the Gtk+ and Poppler libraries. The aim of ePDFView is to make a simple PDF document viewer, similar to Evince but without using the GNOME libraries. To install ePDFView, execute: [source,shell] .... # pkg install epdfview .... [[xpdf]] === Xpdf For users that prefer a small FreeBSD PDF viewer, Xpdf provides a light-weight and efficient viewer which requires few resources. It uses the standard X fonts and does not require any additional toolkit. To install Xpdf, execute: [source,shell] .... # pkg install xpdf .... [[zathura]] === Zathura Zathura is a highly customizable and functional document viewer. It provides a minimalistic and space saving interface as well as an easy usage that mainly focuses on keyboard interaction. To install zathura, with PDF support, execute: [source,shell] .... # pkg install zathura zathura-pdf-mupdf .... Additionally, one can install package:graphics/zathura-pdf-poppler[] for alternative PDF support, package:graphics/zathura-ps[] for PostScript support, package:graphics/zathura-djvu[] for DjVu support, and package:graphics/zathura-cb[] for comic book support. [[desktop-finance]] == Finance For managing personal finances on a FreeBSD desktop, some powerful and easy-to-use applications can be installed. Some are compatible with widespread file formats, such as the formats used by Quicken and Excel. This section covers these programs: .Supported Finance programs [options="header", cols="1,1,1,1"] |=== | Name | License | Package | Resources Needed | KMyMoney | GPL 2.0 | package:finance/kmymoney[] | Heavy | GnuCash | GPL 2.0 and GPL 3.0 | package:finance/gnucash[] | Heavy |=== [[kmymoney]] === KMyMoney KMyMoney is a personal finance application created by the KDE community. KMyMoney aims to provide the important features found in commercial personal finance manager applications. It also highlights ease-of-use and proper double-entry accounting among its features. KMyMoney imports from standard Quicken QIF files, tracks investments, handles multiple currencies, and provides a wealth of reports. To install KMyMoney, execute: [source,shell] .... # pkg install kmymoney .... [[gnucash]] === GnuCash GnuCash is part of the GNOME effort to provide user-friendly, yet powerful, applications to end-users. GnuCash can be used to keep track of income and expenses, bank accounts, and stocks. It features an intuitive interface while remaining professional. GnuCash provides a smart register, a hierarchical system of accounts, and many keyboard accelerators and auto-completion methods. It can split a single transaction into several more detailed pieces. GnuCash can import and merge Quicken QIF files. It also handles most international date and currency formats. To install GnuCash, execute: [source,shell] .... # pkg install gnucash .... diff --git a/documentation/content/en/books/handbook/disks/_index.adoc b/documentation/content/en/books/handbook/disks/_index.adoc index fd9471f071..43f32549e1 100644 --- a/documentation/content/en/books/handbook/disks/_index.adoc +++ b/documentation/content/en/books/handbook/disks/_index.adoc @@ -1,2491 +1,2491 @@ --- title: Chapter 21. Storage part: Part III. System Administration prev: books/handbook/audit next: books/handbook/geom description: This chapter covers the use of disks and storage media in FreeBSD. This includes SCSI and IDE disks, CD and DVD media, memory-backed disks, and USB storage devices. tags: ["storage", "disks", "gpart", "mount", "quotas", "encrypt", "GPT", "cdrecord", "quotas", "swap", "HAST", "CD", "DVD", "resizing", "growing"] showBookMenu: true weight: 24 params: path: "/books/handbook/disks/" --- [[disks]] = Storage :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumoffset: 21 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/disks/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[disks-synopsis]] == Synopsis This chapter covers the use of disks and storage media in FreeBSD. This includes SCSI and IDE disks, CD and DVD media, memory-backed disks, and USB storage devices. Read this chapter to learn: * How to add additional hard disks to a FreeBSD system. * How to grow the size of a disk's partition on FreeBSD. * How to configure FreeBSD to use USB storage devices. * How to use CD and DVD media on a FreeBSD system. * How to use the backup programs available under FreeBSD. * How to set up memory disks. * What file system snapshots are and how to use them efficiently. * How to use quotas to limit disk space usage. * How to encrypt disks and swap to secure them against attackers. * How to configure a highly available storage network. Before reading this chapter: * Know how to crossref:kernelconfig[kernelconfig,configure and install a new FreeBSD kernel]. [[disks-adding]] == Adding Disks 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 [.filename]#/var/run/dmesg.boot# to ensure the new disk was found. In this example, the newly added SATA drive will appear as [.filename]#ada1#. For this example, a single large partition will be created on the new disk. The https://en.wikipedia.org/wiki/GUID_Partition_Table[GPT] partitioning scheme will be used in preference to the older and less versatile MBR scheme. [NOTE] ==== 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. To improve performance on newer disks with larger hardware block sizes, the partition is aligned to one megabyte boundaries: [source,shell] .... # gpart create -s GPT ada1 # gpart add -t freebsd-ufs -a 1M ada1 .... Depending on use, several smaller partitions may be desired. See man:gpart[8] for options to create partitions smaller than a whole disk. The disk partition information can be viewed with `gpart show`: [source,shell] .... % gpart show ada1 => 34 1465146988 ada1 GPT (699G) 34 2014 - free - (1.0M) 2048 1465143296 1 freebsd-ufs (699G) 1465145344 1678 - free - (839K) .... A file system is created in the new partition on the new disk: [source,shell] .... # 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: [source,shell] .... # mkdir /newdisk .... Finally, an entry is added to [.filename]#/etc/fstab# so the new disk will be mounted automatically at startup: [.programlisting] .... /dev/ada1p1 /newdisk ufs rw 2 2 .... The new disk can be mounted manually, without restarting the system: [source,shell] .... # mount /newdisk .... [[disks-growing]] == Resizing and Growing Disks A disk's capacity can increase without any changes to the data already present. This happens commonly with virtual machines, when the virtual disk turns out to be too small and is enlarged. Sometimes a disk image is written to a USB memory stick, but does not use the full capacity. Here we describe how to resize or _grow_ disk contents to take advantage of increased capacity. Determine the device name of the disk to be resized by inspecting [.filename]#/var/run/dmesg.boot#. In this example, there is only one SATA disk in the system, so the drive will appear as [.filename]#ada0#. List the partitions on the disk to see the current configuration: [source,shell] .... # gpart show ada0 => 34 83886013 ada0 GPT (48G) [CORRUPT] 34 128 1 freebsd-boot (64k) 162 79691648 2 freebsd-ufs (38G) 79691810 4194236 3 freebsd-swap (2G) 83886046 1 - free - (512B) .... [NOTE] ==== If the disk was formatted with the https://en.wikipedia.org/wiki/GUID_Partition_Table[GPT] partitioning scheme, it may show as "corrupted" because the GPT backup partition table is no longer at the end of the drive. Fix the backup partition table with `gpart`: [source,shell] .... # gpart recover ada0 ada0 recovered .... ==== Now the additional space on the disk is available for use by a new partition, or an existing partition can be expanded: [source,shell] .... # gpart show ada0 => 34 102399933 ada0 GPT (48G) 34 128 1 freebsd-boot (64k) 162 79691648 2 freebsd-ufs (38G) 79691810 4194236 3 freebsd-swap (2G) 83886046 18513921 - free - (8.8G) .... Partitions can only be resized into contiguous free space. Here, the last partition on the disk is the swap partition, but the second partition is the one that needs to be resized. Swap partitions only contain temporary data, so it can safely be unmounted, deleted, and then recreate the third partition after resizing the second partition. Disable the swap partition: [source,shell] .... # swapoff /dev/ada0p3 .... Delete the third partition, specified by the `-i` flag, from the disk _ada0_. [source,shell] .... # gpart delete -i 3 ada0 ada0p3 deleted # gpart show ada0 => 34 102399933 ada0 GPT (48G) 34 128 1 freebsd-boot (64k) 162 79691648 2 freebsd-ufs (38G) 79691810 22708157 - free - (10G) .... [WARNING] ==== There is risk of data loss when modifying the partition table of a mounted file system. It is best to perform the following steps on an unmounted file system while running from a live CD-ROM or USB device. However, if absolutely necessary, a mounted file system can be resized after disabling GEOM safety features: [source,shell] .... # sysctl kern.geom.debugflags=16 .... ==== Resize the partition, leaving room to recreate a swap partition of the desired size. The partition to resize is specified with `-i`, and the new desired size with `-s`. Optionally, alignment of the partition is controlled with `-a`. This only modifies the size of the partition. The file system in the partition will be expanded in a separate step. [source,shell] .... # gpart resize -i 2 -s 47G -a 4k ada0 ada0p2 resized # gpart show ada0 => 34 102399933 ada0 GPT (48G) 34 128 1 freebsd-boot (64k) 162 98566144 2 freebsd-ufs (47G) 98566306 3833661 - free - (1.8G) .... Recreate the swap partition and activate it. If no size is specified with `-s`, all remaining space is used: [source,shell] .... # gpart add -t freebsd-swap -a 4k ada0 ada0p3 added # gpart show ada0 => 34 102399933 ada0 GPT (48G) 34 128 1 freebsd-boot (64k) 162 98566144 2 freebsd-ufs (47G) 98566306 3833661 3 freebsd-swap (1.8G) # swapon /dev/ada0p3 .... Grow the UFS file system to use the new capacity of the resized partition: [source,shell] .... # growfs /dev/ada0p2 Device is mounted read-write; resizing will result in temporary write suspension for /. It's strongly recommended to make a backup before growing the file system. OK to grow file system on /dev/ada0p2, mounted on /, from 38GB to 47GB? [Yes/No] Yes super-block backups (for fsck -b #) at: 80781312, 82063552, 83345792, 84628032, 85910272, 87192512, 88474752, 89756992, 91039232, 92321472, 93603712, 94885952, 96168192, 97450432 .... If the file system is ZFS, the resize is triggered by running the `online` subcommand with `-e`: [source,shell] .... # zpool online -e zroot /dev/ada0p2 .... Both the partition and the file system on it have now been resized to use the newly-available disk space. [[usb-disks]] == USB Storage Devices Many external storage solutions, such as hard drives, USB thumbdrives, and CD and DVD burners, use the Universal Serial Bus (USB). FreeBSD provides support for USB 1.x, 2.0, and 3.0 devices. [NOTE] ==== USB 3.0 support is not compatible with some hardware, including Haswell (Lynx point) chipsets. If FreeBSD boots with a `failed with error 19` message, disable xHCI/USB3 in the system BIOS. ==== Support for USB storage devices is built into the [.filename]#GENERIC# kernel. For a custom kernel, be sure that the following lines are present in the kernel configuration file: [.programlisting] .... device scbus # SCSI bus (required for ATA/SCSI) device da # Direct Access (disks) device pass # Passthrough device (direct ATA/SCSI access) device uhci # provides USB 1.x support device ohci # provides USB 1.x support device ehci # provides USB 2.0 support device xhci # provides USB 3.0 support device usb # USB Bus (required) device umass # Disks/Mass storage - Requires scbus and da device cd # needed for CD and DVD burners .... FreeBSD uses the man:umass[4] driver which uses the SCSI subsystem to access USB storage devices. Since any USB device will be seen as a SCSI device by the system, if the USB device is a CD or DVD burner, do _not_ include `device atapicam` in a custom kernel configuration file. The rest of this section demonstrates how to verify that a USB storage device is recognized by FreeBSD and how to configure the device so that it can be used. === Device Configuration To test the USB configuration, plug in the USB device. Use `dmesg` to confirm that the drive appears in the system message buffer. It should look something like this: [source,shell] .... umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:4:0:-1: Attached to scbus4 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Fixed Direct Access SCSI-4 device da0: Serial Number WD-WXE508CAN263 da0: 40.000MB/s transfers da0: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C) da0: quirks=0x2 .... The brand, device node ([.filename]#da0#), speed, and size 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: [source,shell] .... # camcontrol devlist at scbus4 target 0 lun 0 (pass3,da0) .... Alternately, `usbconfig` can be used to list the device. Refer to man:usbconfig[8] for more information about this command. [source,shell] .... # usbconfig ugen0.3: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) .... If the device has not been formatted, refer to crossref:disks[disks-adding, Adding Disks] for instructions on how to format and create partitions on the USB drive. If the drive comes with a file system, it can be mounted by `root` using the instructions in crossref:basics[mount-unmount,“Mounting and Unmounting File Systems”]. [WARNING] ==== 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 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 `operator` is able to read and write the device by adding these lines to [.filename]#/etc/devfs.rules#: [.programlisting] .... [localrules=5] add path 'da*' mode 0660 group operator .... [NOTE] ==== If internal SCSI disks are also installed in the system, change the second line as follows: [.programlisting] .... add path 'da[3-9]*' mode 0660 group operator .... This will exclude the first three SCSI disks ([.filename]#da0# to [.filename]#da2#) from belonging to the `operator` group. Replace _3_ with the number of internal SCSI disks. Refer to man:devfs.rules[5] for more information about this file. ==== Next, enable the ruleset in [.filename]#/etc/rc.conf#: [.programlisting] .... devfs_system_ruleset="localrules" .... Then, instruct the system to allow regular users to mount file systems by adding the following line to [.filename]#/etc/sysctl.conf#: [.programlisting] .... vfs.usermount=1 .... Since this only takes effect after the next reboot, use `sysctl` to set this variable now: [source,shell] .... # sysctl vfs.usermount=1 vfs.usermount: 0 -> 1 .... 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 [.filename]#/mnt/username#. In the following example, replace _username_ with the login name of the user and _usergroup_ with the user's primary group: [source,shell] .... # mkdir /mnt/username # chown username:usergroup /mnt/username .... Suppose a USB thumbdrive is plugged in, and a device [.filename]#/dev/da0s1# appears. If the device is formatted with a FAT file system, the user can mount it using: [source,shell] .... % mount -t msdosfs -o -m=644,-M=755 /dev/da0s1 /mnt/username .... Before the device can be unplugged, it _must_ be unmounted first: [source,shell] .... % umount /mnt/username .... After device removal, the system message buffer will show messages similar to the following: [source,shell] .... umass0: at uhub3, port 2, addr 3 (disconnected) da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: s/n WD-WXE508CAN263 detached (da0:umass-sim0:0:0:0): Periph destroyed .... === Automounting Removable Media USB devices can be automatically mounted by uncommenting this line in [.filename]#/etc/auto_master#: [source,shell] .... /media -media -nosuid .... Then add these lines to [.filename]#/etc/devd.conf#: [source,shell] .... notify 100 { match "system" "GEOM"; match "subsystem" "DEV"; action "/usr/sbin/automount -c"; }; .... Reload the configuration if man:autofs[5] and man:devd[8] are already running: [source,shell] .... # service automount restart # service devd restart .... man:autofs[5] can be set to start at boot by adding this line to [.filename]#/etc/rc.conf#: [.programlisting] .... autofs_enable="YES" .... man:autofs[5] requires man:devd[8] to be enabled, as it is by default. Start the services immediately with: [source,shell] .... # service automount start # service automountd start # service autounmountd start # service devd start .... Each file system that can be automatically mounted appears as a directory in [.filename]#/media/#. The directory is named after the file system label. If the label is missing, the directory is named after the device node. The file system is transparently mounted on the first access, and unmounted after a period of inactivity. Automounted drives can also be unmounted manually: [source,shell] .... # automount -fu .... This mechanism is typically used for memory cards and USB memory sticks. It can be used with any block device, including optical drives or iSCSILUNs. [[creating-cds]] == Creating and Using CD Media Compact Disc (CD) media provide a number of features that differentiate them from conventional disks. They are designed so that they can be read continuously without delays to move the head between tracks. While CD media do have tracks, these refer to a section of data to be read continuously, and not a physical property of the disk. The ISO 9660 file system was designed to deal with these differences. The FreeBSD Ports Collection provides several utilities for burning and duplicating audio and data CDs. This chapter demonstrates the use of several command line utilities. For CD burning software with a graphical utility, consider installing the package:sysutils/xcdroast[] or package:sysutils/k3b[] packages or ports. [[atapicam]] === Supported Devices The [.filename]#GENERIC# kernel provides support for SCSI, USB, and ATAPICD readers and burners. If a custom kernel is used, the options that need to be present in the kernel configuration file vary by the type of device. For a SCSI burner, make sure these options are present: [.programlisting] .... device scbus # SCSI bus (required for ATA/SCSI) device da # Direct Access (disks) device pass # Passthrough device (direct ATA/SCSI access) device cd # needed for CD and DVD burners .... For a USB burner, make sure these options are present: [.programlisting] .... device scbus # SCSI bus (required for ATA/SCSI) device da # Direct Access (disks) device pass # Passthrough device (direct ATA/SCSI access) device cd # needed for CD and DVD burners device uhci # provides USB 1.x support device ohci # provides USB 1.x support device ehci # provides USB 2.0 support device xhci # provides USB 3.0 support device usb # USB Bus (required) device umass # Disks/Mass storage - Requires scbus and da .... For an ATAPI burner, make sure these options are present: [.programlisting] .... device ata # Legacy ATA/SATA controllers device scbus # SCSI bus (required for ATA/SCSI) device pass # Passthrough device (direct ATA/SCSI access) device cd # needed for CD and DVD burners .... [NOTE] ==== On FreeBSD versions prior to 10.x, this line is also needed in the kernel configuration file if the burner is an ATAPI device: [.programlisting] .... device atapicam .... Alternately, this driver can be loaded at boot time by adding the following line to [.filename]#/boot/loader.conf#: [.programlisting] .... atapicam_load="YES" .... This will require a reboot of the system as this driver can only be loaded at boot time. ==== To verify that FreeBSD recognizes the device, run `dmesg` and look for an entry for the device. On systems prior to 10.x, the device name in the first line of the output will be [.filename]#acd0# instead of [.filename]#cd0#. [source,shell] .... % dmesg | grep cd cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: Serial Number M3OD3S34152 cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed .... [[cdrecord]] === Burning a CD In FreeBSD, `cdrecord` can be used to burn CDs. This command is installed with the package:sysutils/cdrtools[] package or port. While `cdrecord` has many options, basic usage is simple. Specify the name of the ISO file to burn and, if the system has multiple burner devices, specify the name of the device to use: [source,shell] .... # cdrecord dev=device imagefile.iso .... To determine the device name of the burner, use `-scanbus` which might produce results like this: [source,shell] .... # cdrecord -scanbus ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd10.0) Copyright (C) 1995-2010 Jörg Schilling Using libscg version 'schily-0.9' 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) * .... Locate the entry for the CD burner and use the three numbers separated by commas as the value for `dev`. In this case, the Yamaha burner device is `1,5,0`, so the appropriate input to specify that device is `dev=1,5,0`. Refer to the manual page for `cdrecord` for other ways to specify this value and for information on writing audio tracks and controlling the write speed. Alternately, run the following command to get the device address of the burner: [source,shell] .... # camcontrol devlist at scbus1 target 0 lun 0 (cd0,pass0) .... Use the numeric values for `scbus`, `target`, and `lun`. For this example, `1,0,0` is the device name to use. [[mkisofs]] === Writing Data to an ISO File System In order to produce a data CD, the data files that are going to make up the tracks on the CD must be prepared before they can be burned to the CD. In FreeBSD, package:sysutils/cdrtools[] installs `mkisofs`, which can be used to produce an ISO 9660 file system that is an image of a directory tree within a UNIX(R) file system. The simplest usage is to specify the name of the ISO file to create and the path to the files to place into the ISO 9660 file system: [source,shell] .... # mkisofs -o imagefile.iso /path/to/tree .... This command maps the file names in the specified path to names that fit the limitations of the standard ISO 9660 file system, and will exclude files that do not meet the standard for ISO file systems. A number of options are available to overcome the restrictions imposed by the standard. In particular, `-R` enables the Rock Ridge extensions common to UNIX(R) systems and `-J` enables Joliet extensions used by Microsoft(R) systems. For CDs that are going to be used only on FreeBSD systems, `-U` can be used to disable all filename restrictions. When used with `-R`, it produces a file system image that is identical to the specified FreeBSD tree, even if it violates the ISO 9660 standard. The last option of general use is `-b`. This is used to specify the location of a 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, `mkisofs` 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 FreeBSD distribution media, do not use emulation mode. In this case, `-no-emul-boot` should be used. So, if [.filename]#/tmp/myboot# holds a bootable FreeBSD system with the boot image in [.filename]#/tmp/myboot/boot/cdboot#, this command would produce [.filename]#/tmp/bootable.iso#: [source,shell] .... # mkisofs -R -no-emul-boot -b boot/cdboot -o /tmp/bootable.iso /tmp/myboot .... The resulting ISO image can be mounted as a memory disk with: [source,shell] .... # mdconfig -a -t vnode -f /tmp/bootable.iso -u 0 # mount -t cd9660 /dev/md0 /mnt .... One can then verify that [.filename]#/mnt# and [.filename]#/tmp/myboot# are identical. There are many other options available for `mkisofs` to fine-tune its behavior. Refer to man:mkisofs[8] for details. [NOTE] ==== It is possible to copy a data CD to an image file that is functionally equivalent to the image file created with `mkisofs`. To do so, use [.filename]#dd# with the device name as the input file and the name of the ISO to create as the output file: [source,shell] .... # dd if=/dev/cd0 of=file.iso bs=2048 .... The resulting image file can be burned to CD as described in crossref:disks[cdrecord, Burning a CD]. ==== [[mounting-cd]] === Using Data CDs Once an ISO has been burned to a CD, it can be mounted by specifying the file system type, the name of the device containing the CD, and an existing mount point: [source,shell] .... # mount -t cd9660 /dev/cd0 /mnt .... Since `mount` assumes that a file system is of type `ufs`, an `Incorrect super block` error will occur if `-t cd9660` is not included when mounting a data CD. While any data CD 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. If some non-English characters show up as question marks, specify the local charset with `-C`. For more information, refer to man:mount_cd9660[8]. [NOTE] ==== In order to do this character conversion with the help of `-C`, the kernel requires the [.filename]#cd9660_iconv.ko# module to be loaded. This can be done either by adding this line to [.filename]#loader.conf#: [.programlisting] .... cd9660_iconv_load="YES" .... and then rebooting the machine, or by directly loading the module with `kldload`. ==== Occasionally, `Device not configured` will be displayed when trying to mount a data CD. This usually means that the CD drive has not detected a disk in the tray, or that the drive is not visible on the bus. It can take a couple of seconds for a CD drive to detect media, so be patient. Sometimes, a SCSICD drive may be missed because it did not have enough time to answer the bus reset. To resolve this, a custom kernel can be created which increases the default SCSI delay. Add the following option to the custom kernel configuration file and rebuild the kernel using the instructions in crossref:kernelconfig[kernelconfig-building,“Building and Installing a Custom Kernel”]: [.programlisting] .... options SCSI_DELAY=15000 .... This tells the SCSI bus to pause 15 seconds during boot, to give the CD drive every possible chance to answer the bus reset. [NOTE] ==== It is possible to burn a file directly to CD, without creating an ISO 9660 file system. This is known as burning a raw data CD and some people do this for backup purposes. This type of disk can not be mounted as a normal data CD. In order to retrieve the data burned to such a CD, the data must be read from the raw device node. For example, this command will extract a compressed tar file located on the second CD device into the current working directory: [source,shell] .... # tar xzvf /dev/cd1 .... In order to mount a data CD, the data must be written using `mkisofs`. ==== [[duplicating-audiocds]] === 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. crossref:disks[using-cdrecord, Duplicating an Audio CD] describes how to duplicate and burn an audio CD. If the FreeBSD version is less than 10.0 and the device is ATAPI, the `atapicam` module must be first loaded using the instructions in crossref:disks[atapicam, Supported Devices]. [[using-cdrecord]] [.procedure] .Procedure: Duplicating an Audio CD . The package:sysutils/cdrtools[] package or port installs `cdda2wav`. This command can be used to extract all of the audio tracks, with each track written to a separate WAV file in the current working directory: + [source,shell] .... % cdda2wav -vall -B -Owav .... + A device name does not need to be specified if there is only one CD device on the system. Refer to the `cdda2wav` manual page for instructions on how to specify a device and to learn more about the other options available for this command. . Use `cdrecord` to write the [.filename]#.wav# files: + [source,shell] .... % cdrecord -v dev=2,0 -dao -useinfo *.wav .... + Make sure that _2,0_ is set appropriately, as described in crossref:disks[cdrecord, Burning a CD]. [[creating-dvds]] == Creating and Using DVD Media 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 http://www.dvdforum.org/forum.shtml[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 crossref:disks[creating-dvd-ram, Using a DVD-RAM] for more information on DVD-RAM use. * DVD+RW: This is a rewritable format defined by the https://en.wikipedia.org/wiki/DVD%2BRW_Alliance[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. [NOTE] ==== 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 package:sysutils/dvd+rw-tools[] utilities which support all DVD media types. These tools use the SCSI subsystem to access the devices, therefore crossref:disks[atapicam,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 crossref:disks[usb-disks, USB Storage Devices] for more details on USB device configuration. DMA access must also be enabled for ATAPI devices, by adding the following line to [.filename]#/boot/loader.conf#: [.programlisting] .... hw.ata.atapi_dma="1" .... Before attempting to use dvd+rw-tools, consult the http://fy.chalmers.se/~appro/linux/DVD+RW/hcn.html[Hardware Compatibility Notes]. [NOTE] ==== For a graphical user interface, consider using package: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 crossref:disks[mkisofs,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 [.filename]#/path/to/data#, use the following command: [source,shell] .... # growisofs -dvd-compat -Z /dev/cd0 -J -R /path/to/data .... In this example, `-J -R` 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, `-Z` is used for both single and multiple sessions. Replace _/dev/cd0_, with the name of the DVD device. Using `-dvd-compat` 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: [source,shell] .... # 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 `-speed=`. Refer to man:growisofs[1] for example usage. [NOTE] ==== In order to support working files larger than 4.38GB, an UDF/ISO-9660 hybrid file system must be created by passing `-udf -iso-level 3` 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: [source,shell] .... % mkisofs -R -J -udf -iso-level 3 -o imagefile.iso /path/to/data .... To burn files directly to a disk: [source,shell] .... # 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 package: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 package:sysutils/cdrtools-devel[] and read its man:mkisofs[8]. ==== === Burning a 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 package: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 [.filename]#/path/to/video#, the following command should be used to burn the DVD-Video: [source,shell] .... # growisofs -Z /dev/cd0 -dvd-video /path/to/video .... `-dvd-video` is passed to man:mkisofs[8] to instruct it to create a DVD-Video file system layout. This option implies the `-dvd-compat` man:growisofs[1] option. === Using a 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: [source,shell] .... # 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: [source,shell] .... # 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: [source,shell] .... # 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. [NOTE] ==== Use `-dvd-compat` 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: [source,shell] .... # growisofs -Z /dev/cd0=/dev/zero .... === Using a 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: [source,shell] .... # dvd+rw-format -blank=full /dev/cd0 .... [NOTE] ==== A full blanking using `-blank=full` will take about one hour on a 1x media. A fast blanking can be performed using `-blank`, if the DVD-RW will be recorded in Disk-At-Once (DAO) mode. To burn the DVD-RW in DAO mode, use the command: [source,shell] .... # 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, `-use-the-force-luke=dao` 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: [source,shell] .... # growisofs -Z /dev/cd0 -J -R /path/to/data .... To append some data to a previous recording, use `-M` 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 `-Z`. It is also possible to grow an existing ISO 9660 file system written on the disc with `-M`. The result will be a one-session DVD. To put a DVD-RW in restricted overwrite format, the following command must be used: [source,shell] .... # dvd+rw-format /dev/cd0 .... To change back to sequential format, use: [source,shell] .... # 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: [source,shell] .... # 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. [NOTE] ==== 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 http://fy.chalmers.se/~appro/linux/DVD+RW/[dvd+rw-tools web site], and in the http://lists.debian.org/cdwrite/[cdwrite mailing list] archives. [NOTE] ==== When creating a problem report related to the use of dvd+rw-tools, always include the output of `dvd+rw-mediainfo`. ==== [[creating-dvd-ram]] === Using a DVD-RAM 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 [.filename]#/boot/loader.conf#: [.programlisting] .... hw.ata.atapi_dma="1" .... 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: [source,shell] .... # dd if=/dev/zero of=/dev/acd0 bs=2k count=1 # bsdlabel -Bw acd0 # newfs /dev/acd0 .... The DVD device, [.filename]#acd0#, must be changed according to the configuration. Once the DVD-RAM has been formatted, it can be mounted as a normal hard drive: [source,shell] .... # mount /dev/acd0 /mnt .... Once mounted, the DVD-RAM will be both readable and writeable. [[floppies]] == Creating and Using Floppy Disks This section explains how to format a 3.5 inch floppy disk in FreeBSD. [.procedure] ==== *Procedure: 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 FreeBSD, use man:fdformat[8]. 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: + [source,shell] .... # /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 [.filename]#/etc/disktab#. + To write the disk label, use man:bsdlabel[8]: + [source,shell] .... # /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: + [source,shell] .... # /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 package:emulators/mtools[] from the Ports Collection. [[backup-basics]] == 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 synchronized with another system on the network using a scheduled package: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 FreeBSD system. === File System Backups The traditional UNIX(R) 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. [NOTE] ==== If `dump` is used on the root directory, it will not back up [.filename]#/home#, [.filename]#/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 [.filename]#/tmp/# by default. When using a recovery disk with a small [.filename]#/tmp#, set `TMPDIR` to a directory with more free space 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(R),circa 1975. The default parameters assume a backup to a 9-track tape, rather than to another type of media or to the high-density tapes available today. These defaults must be overridden on the command line. It is possible to backup a file system across the network to another system or 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` more securely over an SSH connection. This example creates a full, compressed backup of [.filename]#/usr# and sends the backup file to the specified host over an SSH connection. .Using `dump` over ssh [example] ==== [source,shell] .... # /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 backup to a tape drive on a remote system over an SSH connection: .Using `dump` over ssh with `RSH` Set [example] ==== [source,shell] .... # env RSH=/usr/bin/ssh /sbin/dump -0uan -f targetuser@targetmachine.example.com:/dev/sa0 /usr .... ==== [TIP] ==== Systems using the crossref:zfs[,Z file system (ZFS)] can make use of man:zfs[8] for creating snapshots, as well as crossref:zfs[zfs-zfs-send,sending and receiving] them to/from remote systems. ==== === Directory Backups 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(R) 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. This example creates a compressed backup of the current directory and saves it to [.filename]#/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 `tar` [example] ==== [source,shell] .... # 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 `tar` [example] ==== [source,shell] .... # 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. 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 [.filename]#/tmp/mybackup.cpio#. .Using `ls` and `cpio` to Make a Recursive Backup of the Current Directory [example] ==== [source,shell] .... # ls -R | cpio -ovF /tmp/mybackup.cpio .... ==== 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(R) 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 `pax` [example] ==== [source,shell] .... # pax -wf /tmp/mybackup.pax . .... ==== [[backups-tapebackups]] === Using Data Tapes for Backups While tape technology has continued to evolve, modern backup systems tend to combine off-site backups with local removable media. FreeBSD supports any tape drive that uses SCSI, such as LTO or DAT. There is limited support for SATA and USB tape drives. For SCSI tape devices, FreeBSD uses the man:sa[4] driver and the [.filename]#/dev/sa0#, [.filename]#/dev/nsa0#, and [.filename]#/dev/esa0# devices. The physical device name is [.filename]#/dev/sa0#. When [.filename]#/dev/nsa0# is used, the backup application will not rewind the tape after writing a file, which allows writing more than one file to a tape. Using [.filename]#/dev/esa0# ejects the tape after the device is closed. In FreeBSD, `mt` is used to control 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: [source,shell] .... # mt -f /dev/nsa0 fsf 3 .... This utility supports many operations. Refer to man:mt[1] for details. To write a single file to tape using `tar`, specify the name of the tape device and the file to backup: [source,shell] .... # tar cvf /dev/sa0 file .... To recover files from a `tar` archive on tape into the current directory: [source,shell] .... # tar xvf /dev/sa0 .... To backup a UFS file system, use `dump`. This examples backs up [.filename]#/usr# without rewinding the tape when finished: [source,shell] .... # dump -0aL -b64 -f /dev/nsa0 /usr .... To interactively restore files from a `dump` file on tape into the current directory: [source,shell] .... # restore -i -f /dev/nsa0 .... [[backups-programs-amanda]] === Third-Party Backup Utilities The FreeBSD Ports Collection provides many third-party utilities which can be used to schedule the creation of backups, simplify tape backup, and make backups easier and more convenient. 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 (package:misc/amanda-server[] and package:misc/amanda-client[]), * Bacula (package:sysutils/bacula13-server[] and package:sysutils/bacula13-client[]), * Bareos (package:sysutils/bareos-server[] and package:sysutils/bareos-client[]), * package:net/rsync[], * package:sysutils/duply[], and * package:sysutils/duplicity[]. === Emergency Recovery In addition to regular backups, it is recommended to perform the following steps as part of an emergency preparedness plan. Create a print copy of the output of the following commands: * `gpart show` * `more /etc/fstab` * `pkg prime-list` * `dmesg` 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. Next, test the rescue shell and the backups. Make notes of the procedure. Store 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 the latest backup at a remote location which is physically separated from the computers and disk drives by a significant distance. [[disks-virtual]] == Memory Disks In addition to physical disks, FreeBSD also supports the creation and use of memory disks. One possible use for a memory disk is to access the contents of an ISO file system without the overhead of first burning it to a CD or DVD, then mounting the CD/DVD media. In FreeBSD, the man:md[4] driver is used to provide support for memory disks. The [.filename]#GENERIC# kernel includes this driver. When using a custom kernel configuration file, ensure it includes this line: [.programlisting] .... device md .... [[disks-mdconfig]] === Attaching and Detaching Existing Images To mount an existing file system image, use `mdconfig` to specify the name of the ISO file and a free unit number. Then, refer to that unit number to mount it on an existing mount point. Once mounted, the files in the ISO will appear in the mount point. This example attaches _diskimage.iso_ to the memory device [.filename]#/dev/md0# then mounts that memory device on [.filename]#/mnt#: [source,shell] .... # mdconfig -f diskimage.iso -u 0 # mount -t cd9660 /dev/md0 /mnt .... Notice that `-t cd9660` was used to mount an ISO format. If a unit number is not specified with `-u`, `mdconfig` will automatically allocate an unused memory device and output the name of the allocated unit, such as [.filename]#md4#. Refer to man:mdconfig[8] for more details about this command and its options. When a memory disk is no longer in use, its resources should be released back to the system. First, unmount the file system, then use `mdconfig` to detach the disk from the system and release its resources. To continue this example: [source,shell] .... # umount /mnt # mdconfig -d -u 0 .... To determine if any memory disks are still attached to the system, type `mdconfig -l`. [[disks-md-freebsd5]] === Creating a File- or Memory-Backed Memory Disk FreeBSD also supports memory disks where the storage to use is allocated from either a hard disk or an area of memory. The first method is commonly referred to as a file-backed file system and the second method as a memory-backed file system. Both types can be created using `mdconfig`. To create a new memory-backed file system, specify a type of `swap` and the size of the memory disk to create. Then, format the memory disk with a file system and mount as usual. This example creates a 5M memory disk on unit `1`. That memory disk is then formatted with the UFS file system before it is mounted: [source,shell] .... # mdconfig -a -t swap -s 5m -u 1 # 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 # mount /dev/md1 /mnt # df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md1 4718 4 4338 0% /mnt .... To create a new file-backed memory disk, first allocate an area of disk to use. This example creates an empty 5MB file named [.filename]#newimage#: [source,shell] .... # dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out .... Next, attach that file to a memory disk, label the memory disk and format it with the UFS file system, mount the memory disk, and verify the size of the file-backed disk: [source,shell] .... # mdconfig -f newimage -u 0 # bsdlabel -w md0 auto # newfs -U 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 # mount /dev/md0a /mnt # df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0a 4710 4 4330 0% /mnt .... It takes several commands to create a file- or memory-backed file system using `mdconfig`. FreeBSD also comes with `mdmfs` which automatically configures a memory disk, formats it with the UFS file system, and mounts it. For example, after creating _newimage_ with `dd`, this one command is equivalent to running the `bsdlabel`, `newfs`, and `mount` commands shown above: [source,shell] .... # mdmfs -F newimage -s 5m md0 /mnt .... To instead create a new memory-based memory disk with `mdmfs`, use this one command: [source,shell] .... # mdmfs -s 5m md1 /mnt .... If the unit number is not specified, `mdmfs` will automatically select an unused memory device. For more details about `mdmfs`, refer to man:mdmfs[8]. [[snapshots]] == File System Snapshots FreeBSD 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. When using the crossref:zfs[,Z file system (ZFS)], refer to crossref:zfs[zfs-zfs-snapshot,"Managing Snapshots"] on how to use snapshots. 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 `snapshot` 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 [.filename]#/var# in the file [.filename]#/var/snapshot/snap#, use the following command: [source,shell] .... # mount -u -o snapshot /var/snapshot/snap /var .... Alternatively, use man:mksnap_ffs[8] to create the snapshot: [source,shell] .... # mksnap_ffs /var /var/snapshot/snap .... One can find snapshot files on a file system, such as [.filename]#/var#, using man:find[1]: [source,shell] .... # 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 `-L`. * The snapshot can be mounted as a frozen image of the file system. To man:mount[8] the snapshot [.filename]#/var/snapshot/snap# run: + [source,shell] .... # mdconfig -a -t vnode -o readonly -f /var/snapshot/snap -u 4 # mount -r /dev/md4 /mnt .... The frozen [.filename]#/var# is now available through [.filename]#/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: [source,shell] .... # umount /mnt # mdconfig -d -u 4 .... -For more information about `softupdates` and file system snapshots, including technical papers, visit Marshall Kirk McKusick's website at http://www.mckusick.com/[http://www.mckusick.com/]. +For more information about `softupdates` and file system snapshots, including technical papers, visit Marshall Kirk McKusick's website at https://www.mckusick.com/[https://www.mckusick.com/]. [[quotas]] == Disk Quotas Disk quotas 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 prevents one user or group of users from consuming all of the available disk space. This section describes how to configure disk quotas for the UFS file system. To configure quotas on the ZFS file system, refer to crossref:zfs[zfs-zfs-quota,"Dataset, User, and Group Quotas"] === Enabling Disk Quotas To determine if the FreeBSD kernel provides support for disk quotas: [source,shell] .... % sysctl kern.features.ufs_quota kern.features.ufs_quota: 1 .... In this example, the `1` indicates quota support. If the value is instead `0`, add the following line to a custom kernel configuration file and rebuild the kernel using the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]: [.programlisting] .... options QUOTA .... Next, enable disk quotas in [.filename]#/etc/rc.conf#: [.programlisting] .... quota_enable="YES" .... 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 [.filename]#/etc/rc.conf#: [.programlisting] .... check_quotas="NO" .... Finally, edit [.filename]#/etc/fstab# to enable disk quotas on a per-file system basis. To enable per-user quotas on a file system, add `userquota` to the options field in the [.filename]#/etc/fstab# entry for the file system to enable quotas on. For example: [.programlisting] .... /dev/da1s2g /home ufs rw,userquota 1 2 .... To enable group quotas, use `groupquota` instead. To enable both user and group quotas, separate the options with a comma: [.programlisting] .... /dev/da1s2g /home ufs rw,userquota,groupquota 1 2 .... By default, quota files are stored in the root directory of the file system as [.filename]#quota.user# and [.filename]#quota.group#. Refer to man:fstab[5] for more information. Specifying an alternate location for the quota files is not recommended. Once the configuration is complete, reboot the system and [.filename]#/etc/rc# will automatically run the appropriate commands to create the initial quota files for all of the quotas enabled in [.filename]#/etc/fstab#. 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 these manual pages to be familiar with their operation. === Setting Quota Limits To verify that quotas are enabled, run: [source,shell] .... # 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 `edquota`. 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 limit is further broken down into two categories: hard and soft limits. 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 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. In the following example, the quota for the `test` account is being edited. When `edquota` is invoked, the editor specified by `EDITOR` is opened in order to edit the quota limits. The default editor is set to vi. [source,shell] .... # 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 the block limit on [.filename]#/usr# to a soft limit of `500` and a hard limit of `600`, change the values in that line as follows: [.programlisting] .... /usr: kbytes in use: 65, limits (soft = 500, hard = 600) .... The new quota limits take effect upon exiting the editor. Sometimes it is desirable to set quota limits on a range of users. This can be done by first assigning the desired quota limit to a user. Then, use `-p` to duplicate that quota to a specified range of user IDs (UIDs). The following command will duplicate those quota limits for UIDs `10,000` through `19,999`: [source,shell] .... # edquota -p test 10000-19999 .... For more information, refer to man:edquota[8]. === Checking 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]. Normally, file systems that the user is not using any disk space on will not show in the output of `quota`, even if the user has a quota limit assigned for that file system. Use `-v` to display those file systems. The following is sample output from `quota -v` for a user that has quota limits on two file systems. [.programlisting] .... 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 .... In this example, the user is currently 15 kbytes over the soft limit of 50 kbytes on [.filename]#/usr# and has 5 days of grace period left. The asterisk `*` indicates that the user is currently over the quota limit. === Quotas over NFS Quotas are enforced by the quota subsystem on the NFS server. The man:rpc.rquotad[8] daemon makes quota information available to `quota` on NFS clients, allowing users on those machines to see their quota statistics. On the NFS server, enable `rpc.rquotad` by removing the `+#+` from this line in [.filename]*/etc/inetd.conf*: [.programlisting] .... rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad .... Then, restart `inetd`: [source,shell] .... # service inetd restart .... [[disks-encrypting]] == Encrypting Disk Partitions FreeBSD offers excellent online protections against unauthorized data access. File permissions and crossref:mac[mac,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, the GEOM-based cryptographic subsystems built into FreeBSD are able to protect the data on the computer's file systems against even highly-motivated attackers with significant resources. Unlike encryption methods that encrypt individual files, the built-in `gbde` and `geli` utilities can be used to transparently encrypt entire file systems. No cleartext ever touches the hard drive's platter. This chapter demonstrates how to create an encrypted file system on FreeBSD. It first demonstrates the process using `gbde` and then demonstrates the same example using `geli`. [WARNING] ==== GBDE disk-encryption is deprecated, and removed in FreeBSD 15.0. ==== === Disk Encryption with gbde The objective of the man:gbde[4] facility is to provide a formidable challenge for an attacker to gain access to the contents of a _cold_ storage device. However, if the computer is compromised while up and running and the storage device is actively attached, or the attacker has access to a valid passphrase, it offers no protection to the contents of the storage device. Thus, it is important to provide physical security while the system is running and to protect the passphrase used by the encryption mechanism. This facility provides several barriers to protect the data stored in each disk sector. It encrypts the contents of a disk sector 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]. FreeBSD provides a kernel module for gbde which can be loaded with this command: [source,shell] .... # kldload geom_bde .... If using a custom kernel configuration file, ensure it contains this line: `options GEOM_BDE` The following example demonstrates adding a new hard drive to a system that will hold a single encrypted partition that will be mounted as [.filename]#/private#. [.procedure] .Procedure: Encrypting a Partition with gbde . Add the New Hard Drive + Install the new drive to the system as explained in crossref:disks[disks-adding, Adding Disks]. For the purposes of this example, a new hard drive partition has been added as [.filename]#/dev/ad4s1c# and [.filename]#/dev/ad0s1*# represents the existing standard FreeBSD partitions. + [source,shell] .... # 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 `gbde` Lock Files + [source,shell] .... # 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 `gbde` Partition + A gbde partition must be initialized before it can be used. This initialization needs to be performed only once. This command will open the default editor, in order to set various configuration options in a template. For use with the UFS file system, set the sector_size to 2048: + [source,shell] .... # gbde init /dev/ad4s1c -i -L /etc/gbde/ad4s1c.lock # # 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 [...] .... + Once the edit is saved, the user will be asked 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 http://world.std.com/\~reinhold/diceware.html[http://world.std.com/~reinhold/diceware.htm]. + This initialization creates a lock file for the gbde partition. In this example, it is stored as [.filename]#/etc/gbde/ad4s1c.lock#. Lock files must end in ".lock" in order to be correctly detected by the [.filename]#/etc/rc.d/gbde# start up script. + [CAUTION] ==== Lock files _must_ be backed up together with the contents of any encrypted partitions. Without the lock file, the legitimate owner will be unable to access the data on the encrypted partition. ==== . Attach the Encrypted Partition to the Kernel + [source,shell] .... # 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 [.filename]#/dev# as [.filename]#/dev/device_name.bde#: + [source,shell] .... # 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. This example creates a UFS file system with soft updates enabled. Be sure to specify the partition which has a [.filename]#*.bde# extension: + [source,shell] .... # newfs -U /dev/ad4s1c.bde .... . Mount the Encrypted Partition + Create a mount point and mount the encrypted file system: + [source,shell] .... # mkdir /private # mount /dev/ad4s1c.bde /private .... . Verify That the Encrypted File System is Available + The encrypted file system should now be visible and available for use: + [source,shell] .... % 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 .... After each boot, any encrypted file systems must be manually re-attached to the kernel, checked for errors, and mounted, before the file systems can be used. To configure these steps, add the following lines to [.filename]#/etc/rc.conf#: [.programlisting] .... gbde_autoattach_all="YES" gbde_devices="ad4s1c" gbde_lockdir="/etc/gbde" .... This requires that the passphrase be entered at the console at boot time. After typing the correct passphrase, the encrypted partition will be mounted automatically. Additional gbde boot options are available and listed in man:rc.conf[5]. [[disks-encrypting-geli]] === Disk Encryption with `geli` An alternative cryptographic GEOM class is available using `geli`. This control utility adds some features and uses a different scheme for doing cryptographic work. It provides the following features: * Utilizes the man:crypto[9] framework and automatically uses cryptographic hardware when it is available. * Supports multiple cryptographic algorithms such as AES-XTS, AES-CBC, and Camellia-CBC. * 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. * It 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 features and usage examples can be found in man:geli[8]. 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 [.filename]#/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 describes how to attach to the `geli` provider, create a file system on it, mount it, work with it, and finally, how to detach it. [.procedure] .Procedure: Encrypting a Partition with `geli` . Load `geli` Support + Support for `geli` is available as a loadable kernel module. To configure the system to automatically load the module at boot time, add the following line to [.filename]#/boot/loader.conf#: + [.programlisting] .... geom_eli_load="YES" .... + To load the kernel module now: + [source,shell] .... # kldload geom_eli .... + For a custom kernel, ensure the kernel configuration file contains these lines: + [.programlisting] .... options GEOM_ELI device crypto .... . Generate the Master Key + The following commands generate a master key that all data will be encrypted with. This key can never be changed. Rather than using it directly, it is encrypted with one or more user keys. The user keys are made up of an optional combination of random bytes from a file, [.filename]#/root/da2.key#, and/or a passphrase. In this case, the data source for the key file is [.filename]#/dev/random#. This command also configures the sector size of the provider ([.filename]#/dev/da2.eli#) as 4kB, for better performance: + [source,shell] .... # dd if=/dev/random of=/root/da2.key bs=64 count=1 # geli init -K /root/da2.key -s 4096 /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. For example, this command generates three key files: + [source,shell] .... # cat keyfile1 keyfile2 keyfile3 | geli init -K - /dev/da2 .... . Attach the Provider with the Generated Key + To attach the provider, specify the key file, the name of the disk, and the passphrase: + [source,shell] .... # geli attach -k /root/da2.key /dev/da2 Enter passphrase: .... + This creates a new device with an [.filename]#.eli# extension: + [source,shell] .... # ls /dev/da2* /dev/da2 /dev/da2.eli .... . Create the New File System + Next, format the device with the UFS file system and mount it on an existing mount point: + [source,shell] .... # dd if=/dev/random of=/dev/da2.eli bs=1m # newfs /dev/da2.eli # mount /dev/da2.eli /private .... + The encrypted file system should now be available for use: + [source,shell] .... # 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 .... Once the work on the encrypted partition is done, and the [.filename]#/private# partition is no longer needed, it is prudent to put the device into cold storage by unmounting and detaching the `geli` encrypted partition from the kernel: [source,shell] .... # umount /private # geli detach da2.eli .... An [.filename]#rc.d# script is provided to simplify the mounting of `geli`-encrypted devices at boot time. For this example, add these lines to [.filename]#/etc/rc.conf#: [.programlisting] .... geli_devices="da2" geli_da2_flags="-k /root/da2.key" .... This configures [.filename]#/dev/da2# as a `geli` provider with a master key of [.filename]#/root/da2.key#. The system will automatically detach the provider from the kernel before the system shuts down. During the startup process, the script will prompt for the passphrase before attaching the provider. Other kernel messages might be shown before and after the password prompt. If the boot process seems to stall, look carefully for the password prompt among the other messages. Once the correct passphrase is entered, the provider is attached. The file system is then mounted, typically by an entry in [.filename]#/etc/fstab#. Refer to crossref:basics[mount-unmount,“Mounting and Unmounting File Systems”] for instructions on how to configure a file system to mount at boot time. [[swap-encrypting]] == Encrypting Swap 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, they are not written to disk and will be cleared after a reboot. However, if FreeBSD starts swapping out memory pages to free space, the passwords may be written to the disk unencrypted. Encrypting swap space can be a solution for this scenario. This section demonstrates how to configure an encrypted swap partition using man:gbde[8] or man:geli[8] encryption. It assumes that [.filename]#/dev/ada0s1b# is the swap partition. === Configuring Encrypted Swap Swap partitions are not encrypted by default and should be cleared of any sensitive data before continuing. To overwrite the current swap partition with random garbage, execute the following command: [source,shell] .... # dd if=/dev/random of=/dev/ada0s1b bs=1m .... To encrypt the swap partition using man:gbde[8], add the `.bde` suffix to the swap line in [.filename]#/etc/fstab#: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# /dev/ada0s1b.bde none swap sw 0 0 .... To instead encrypt the swap partition using man:geli[8], initialize the device with a onetime key: [source,shell] .... # geom eli onetime -d /dev/ada0s1b .... Afterwards, add a line for the device with the `.eli` suffix to [.filename]#/etc/fstab#: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# /dev/ada0s1b.eli none swap sw 0 0 .... By default, man:geli[8] uses the AES algorithm with a key length of 128 bits. Normally the default settings will suffice. If desired, these defaults can be altered in the options field in [.filename]#/etc/fstab#. The possible flags are: aalgo:: Data integrity verification algorithm used to ensure that the encrypted data has not been tampered with. See man:geli[8] for a list of supported algorithms. ealgo:: Encryption algorithm used to protect the data. See man:geli[8] for a list of supported algorithms. keylen:: The length of the key used for the encryption algorithm. See man:geli[8] for the key lengths that are supported by each encryption algorithm. sectorsize:: The size of the blocks data is broken into before it is encrypted. Larger sector sizes increase performance at the cost of higher storage overhead. The recommended size is 4096 bytes. This example configures an encrypted swap partition using the AES-XTS algorithm with a key length of 128 bits and a sectorsize of 4 kilobytes: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# /dev/ada0s1b.eli none swap sw,ealgo=AES-XTS,keylen=128,sectorsize=4096 0 0 .... === 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: [source,shell] .... % swapinfo Device 1K-blocks Used Avail Capacity /dev/ada0s1b.bde 542720 0 542720 0 .... If man:geli[8] is being used: [source,shell] .... % swapinfo Device 1K-blocks Used Avail Capacity /dev/ada0s1b.eli 542720 0 542720 0 .... [[disks-hast]] == Highly Available Storage (HAST) High availability is one of the main requirements in serious business applications and highly-available storage is a key component in such environments. In FreeBSD, the Highly Available STorage (HAST) framework 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(R) storage system used in the GNU/Linux(R) platform. In combination with other high-availability features of FreeBSD like CARP, HAST makes it possible to build a highly-available storage cluster that is resistant to hardware failures. The following are the main features of HAST: * Can be used to mask I/O errors on local hard drives. * File system agnostic as it works with any file system supported by FreeBSD. * Efficient and quick resynchronization as only the blocks that were modified during the downtime of a node are synchronized. * 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. Read this chapter to learn: * What HAST is, how it works, and which features it provides. * How to set up and use HAST on FreeBSD. * How to integrate CARP and man:devd[8] to build a robust storage system. Before reading this section: * Understand UNIX(R) and FreeBSD basics (crossref:basics[basics,FreeBSD Basics]). * Know how to configure network interfaces and other core FreeBSD subsystems (crossref:config[config-tuning,Configuration and Tuning]). * Have a good understanding of FreeBSD networking (crossref:partiv[network-communication,"Network Communication"]). -The HAST project was sponsored by The FreeBSD Foundation with support from http://www.omc.net/[http://www.omc.net/] and http://www.transip.nl/[http://www.transip.nl/]. +The HAST project was sponsored by The FreeBSD Foundation with support from https://www.omc.net/[https://www.omc.net/] and https://www.transip.nl/[https://www.transip.nl/]. === HAST Operation HAST provides synchronous block-level replication between two physical machines: the _primary_ node and the _secondary_ node. These two machines together are referred to as a cluster. 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 the local disk on primary node, and the disk on the remote, secondary node. HAST operates synchronously on a block level, making it transparent to file systems and applications. HAST provides regular GEOM providers in [.filename]#/dev/hast/# for use by other tools or applications. There is no difference between using HAST-provided devices and raw disks or partitions. Each write, delete, or flush operation is sent to both 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 cases, the read operation is sent to the secondary node. HAST tries to provide fast failure recovery. For this reason, it is 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_: This mode reports a 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 good reliability. This mode is the default. * _fullsync_: This mode reports a write operation as completed when both the local write and the remote write complete. This is the safest and the slowest replication mode. * _async_: This mode reports a write operation as completed when the local write completes. This is the fastest and the most dangerous replication mode. It should only be used when replicating to a distant node where latency is too high for other modes. === HAST Configuration The HAST framework consists of several components: * The man:hastd[8] daemon which provides data synchronization. When this daemon is started, it will automatically load `geom_gate.ko`. * The userland management utility, man:hastctl[8]. * The man:hast.conf[5] configuration file. This file must exist before starting hastd. Users who prefer to statically build `GEOM_GATE` support into the kernel should add this line to the custom kernel configuration file, then rebuild the kernel using the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]: [.programlisting] .... options GEOM_GATE .... The following example describes how to configure two nodes in 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 address of `172.16.0.2`. Both nodes will have a dedicated hard drive [.filename]#/dev/ad6# of the same size for HAST operation. The HAST pool, sometimes referred to as a resource or the GEOM provider in [.filename]#/dev/hast/#, will be called `test`. Configuration of HAST is done using [.filename]#/etc/hast.conf#. This file should be identical on both nodes. The simplest configuration is: [.programlisting] .... 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]. [TIP] ==== It is also possible to use host names in the `remote` statements if the hosts are resolvable and defined either in [.filename]#/etc/hosts# or in the local DNS. ==== Once 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]: [source,shell] .... # hastctl create test # service hastd onestart .... [NOTE] ==== 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: [source,shell] .... # hastctl role primary test .... Run this command on the secondary node, `hastb`: [source,shell] .... # hastctl role secondary test .... Verify the result by running `hastctl` on each node: [source,shell] .... # hastctl status test .... Check the `status` line in the output. If it says `degraded`, something is wrong with the configuration file. It should say `complete` on each node, meaning that the synchronization between the nodes has started. The synchronization completes when `hastctl status` reports 0 bytes of `dirty` extents. The next step is to create a file system on the GEOM provider and mount it. This must be done on the `primary` node. Creating the file system can take a few minutes, depending on the size of the hard drive. This example creates a UFS file system on [.filename]#/dev/hast/test#: [source,shell] .... # newfs -U /dev/hast/test # mkdir /hast/test # 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 [.filename]#/etc/rc.conf#: [.programlisting] .... 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. If the primary node fails, 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, the Common Address Redundancy Protocol (CARP) is used to provide for automatic failover at the IP layer. CARP 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 crossref:advanced-networking[carp,“Common Address Redundancy Protocol (CARP)”]. In this example, each node will have its own management IP address and a shared IP address of _172.16.0.254_. The primary HAST node of the cluster must be the primary 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 FreeBSD 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 catch state changes on the CARP interfaces, add this configuration to [.filename]#/etc/devd.conf# on each node, while replacing `` with the virtual host id and `` with the associated interface name: [.programlisting] .... notify 30 { match "system" "CARP"; match "subsystem" "@"; match "type" "MASTER"; action "/usr/local/sbin/carp-hast-switch primary"; }; notify 30 { match "system" "CARP"; match "subsystem" "@"; match "type" "BACKUP"; action "/usr/local/sbin/carp-hast-switch secondary"; }; .... Restart man:devd[8] on both nodes to put the new configuration into effect: [source,shell] .... # service devd restart .... When the specified interface state changes by going up or down , the system generates a notification, allowing the man:devd[8] subsystem to run the specified automatic failover script, [.filename]#/usr/local/sbin/carp-hast-switch#. For further clarification about this configuration, refer to man:devd.conf[5]. Here is an example of an automated failover script: [.programlisting] .... #!/bin/sh # Original script by Freddie Cash # Modified by Michael W. Lucas # and Viktor Petersson # The names of the HAST resources, as listed in /etc/hast.conf resources="test" # delay in mounting HAST resource after becoming primary # make your best guess delay=3 # logging log="local0.debug" name="carp-hast" # end of user configurable stuff case "$1" in primary) 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 ;; secondary) 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 primary: * Promotes the HAST pool to primary on the other node. * Checks the file system under the HAST pool. * Mounts the pool. When a node becomes secondary: * Unmounts the HAST pool. * Degrades the HAST pool to secondary. [CAUTION] ==== 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 or stop required services. ==== [TIP] ==== 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. ==== Instead of using the highly available storage locally, it can also be shared to other computers on a network via crossref:network-servers[network-nfs,NFS], crossref:network-servers[network-iscsi,iSCSI], man:sshfs[1], or programs in ports (i.e. package:net/samba419[]). -More detailed information with additional examples can be found at http://wiki.FreeBSD.org/HAST[http://wiki.FreeBSD.org/HAST]. +More detailed information with additional examples can be found at https://wiki.FreeBSD.org/HAST[https://wiki.FreeBSD.org/HAST]. === Troubleshooting 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 the nodes of the cluster. When troubleshooting HAST, the debugging level of man:hastd[8] should be increased by starting `hastd` with `-d`. This argument may be specified multiple times to further increase the debugging level. Consider also using `-F`, which starts `hastd` in the foreground. [[disks-hast-sb]] ==== Recovering from the Split-brain Condition _Split-brain_ occurs 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 either decide which node has more important changes, or perform the merge manually. Then, 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: [source,shell] .... # hastctl role init test # hastctl create test # hastctl role secondary test .... diff --git a/documentation/content/en/books/handbook/dtrace/_index.adoc b/documentation/content/en/books/handbook/dtrace/_index.adoc index 32a2b14d8c..9090bf55a9 100644 --- a/documentation/content/en/books/handbook/dtrace/_index.adoc +++ b/documentation/content/en/books/handbook/dtrace/_index.adoc @@ -1,286 +1,286 @@ --- title: Chapter 28. DTrace part: Part III. System Administration prev: books/handbook/cutting-edge next: books/handbook/usb-device-mode description: This chapter explains how to use DTrace in FreeBSD tags: ["DTrace", "features", "guide", "tutorial", "kldload"] showBookMenu: true weight: 31 params: path: "/books/handbook/dtrace/" --- [[dtrace]] = DTrace :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumoffset: 28 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/dtrace/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[dtrace-synopsis]] == Synopsis DTrace, also known as Dynamic Tracing, was developed by Sun(TM) as a tool for locating performance bottlenecks in production and pre-production systems. In addition to diagnosing performance problems, DTrace can be used to help investigate and debug unexpected behavior in both the FreeBSD kernel and in userland programs. DTrace is a remarkable profiling tool, with an impressive array of features for diagnosing system issues. It may also be used to run pre-written scripts to take advantage of its capabilities. Users can author their own utilities using the DTrace D Language, allowing them to customize their profiling based on specific needs. The FreeBSD implementation provides full support for kernel DTrace and experimental support for userland DTrace. Userland DTrace allows users to perform function boundary tracing for userland programs using the `pid` provider, and to insert static probes into userland programs for later tracing. Some ports, such as package:databases/postgresql12-server[] and package:lang/php74[] have a DTrace option to enable static probes. The official guide to DTrace is maintained by the illumos project at https://illumos.org/books/dtrace/bookinfo.html[illumos Dynamic Tracing Guide]. Read this chapter to learn: * What DTrace is and what features it provides. * Differences between the Solaris(TM) DTrace implementation and the one provided by FreeBSD. * How to enable and use DTrace on FreeBSD. Before reading this chapter: * Understand UNIX(R) and FreeBSD basics (crossref:basics[basics,FreeBSD Basics]). * Have some familiarity with security and how it pertains to FreeBSD (crossref:security[security,Security]). [[dtrace-implementation]] == Implementation Differences While the DTrace in FreeBSD is similar to that found in Solaris(TM), differences do exist. The primary difference is that in FreeBSD, DTrace is implemented as a set of kernel modules and DTrace can not be used until the modules are loaded. To load all of the necessary modules: [source,shell] .... # kldload dtraceall .... Beginning with FreeBSD 10.0-RELEASE, the modules are automatically loaded when man:dtrace[1] is run. FreeBSD uses the `DDB_CTF` kernel option to enable support for loading man:ctf[5] data from kernel modules and the kernel itself. `CTF` is the Solaris(TM) Compact C Type Format which encapsulates a reduced form of debugging information similar to `DWARF` and the venerable stabs. `CTF` data is added to binaries by the man:ctfconvert[1] and man:ctfmerge[1] build tools. The `ctfconvert` utility parses `DWARF` `ELF` debug sections created by the compiler and `ctfmerge` merges `CTF` `ELF` sections from objects into either executables or shared libraries. Some different providers exist for FreeBSD than for Solaris(TM). Most notable is the `dtmalloc` provider, which allows tracing man:malloc[9] by type in the FreeBSD kernel. Some of the providers found in Solaris(TM), such as `cpc`, are not present in FreeBSD. These may appear in future versions of FreeBSD. Moreover, some of the providers available in both operating systems are not compatible, in the sense that their probes have different argument types. Thus, `D` scripts written on Solaris(TM) may or may not work unmodified on FreeBSD, and vice versa. Due to security differences, only `root` may use DTrace on FreeBSD. Solaris(TM) has a few low level security checks which do not yet exist in FreeBSD. As such, the [.filename]#/dev/dtrace/dtrace# is strictly limited to `root`. DTrace falls under the Common Development and Distribution License (`CDDL`) license. -To view this license on FreeBSD, see [.filename]#/usr/src/cddl/contrib/opensolaris/OPENSOLARIS.LICENSE# or view it online at http://opensource.org/licenses/CDDL-1.0[http://opensource.org/licenses/CDDL-1.0]. +To view this license on FreeBSD, see [.filename]#/usr/src/cddl/contrib/opensolaris/OPENSOLARIS.LICENSE# or view it online at https://opensource.org/licenses/CDDL-1.0[https://opensource.org/licenses/CDDL-1.0]. While a FreeBSD kernel with DTrace support is `BSD` licensed, the `CDDL` is used when the modules are distributed in binary form or the binaries are loaded. [[dtrace-enable]] == Enabling DTrace Support In FreeBSD 9.2 and 10.0, DTrace support is built into the [.filename]#GENERIC# kernel. Users of earlier versions of FreeBSD or who prefer to statically compile in DTrace support should add the following lines to a custom kernel configuration file and recompile the kernel using the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]: [.programlisting] .... options KDTRACE_HOOKS options DDB_CTF makeoptions DEBUG=-g makeoptions WITH_CTF=1 .... Users of the AMD64 architecture should also add this line: [.programlisting] .... options KDTRACE_FRAME .... This option provides support for man:dtrace_fbt[4]. While DTrace will work without this option, there will be limited support for function boundary tracing. Once the FreeBSD system has rebooted into the new kernel, or the DTrace kernel modules have been loaded using `kldload dtraceall`, install the current DTrace Toolkit (package:sysutils/dtrace-toolkit[]), a collection of ready-made scripts for collecting system information. There are scripts to check open files, memory, CPU usage, and a lot more. FreeBSD includes some scripts in the base system as well; see [.filename]#/usr/share/dtrace#. [NOTE] ==== The scripts found in [.filename]#/usr/share/dtrace# have been specifically ported to FreeBSD. Not all of the scripts found in the DTrace Toolkit will work as-is on FreeBSD and some scripts may require some effort in order for them to work on FreeBSD. ==== The DTrace Toolkit includes many scripts in the special language of DTrace. This language is called the D language and it is very similar to C++. An in depth discussion of the language is beyond the scope of this document. Refer to the FreeBSD man:d[7] manual page for an overview of the D language on FreeBSD. The D language is also covered extensively in the https://www.illumos.org/books/dtrace/bookinfo.html[illumos Dynamic Tracing Guide]. [[dtrace-out-of-kernel]] == Enabling DTrace in Out-of-Kernel Modules To add DTrace support to an out-of-kernel module, which is useful for development and debugging, include the following line in the module's Makefile: [.programlisting] .... CFLAGS+= -DKDTRACE_HOOKS .... This flag enables DTrace hooks during compilation, allowing for advanced debugging and monitoring of the module. Ensure to recompile the module after this modification to activate DTrace functionality. [[dtrace-using]] == Using DTrace DTrace scripts consist of a list of one or more _probes_, or instrumentation points, where each probe is associated with an action. Whenever the condition for a probe is met, the associated action is executed. For example, an action may occur when a file is opened, a process is started, or a line of code is executed. The action might be to log some information or to modify context variables. The reading and writing of context variables allows probes to share information and to cooperatively analyze the correlation of different events. To view all probes, the administrator can execute the following command: [source,shell] .... # dtrace -l | more .... Each probe has an `ID`, a `PROVIDER` (e.g., `dtrace` or `fbt`), a `MODULE`, and a `FUNCTION NAME`. Refer to man:dtrace[1] for more information about this command. The examples in this section provide an overview of how to use two of the fully supported scripts from the DTrace Toolkit: the [.filename]#hotkernel# and [.filename]#procsystime# scripts. The [.filename]#hotkernel# script is designed to identify which function is using the most kernel time. It will produce output similar to the following: [source,shell] .... # cd /usr/local/share/dtrace-toolkit # ./hotkernel Sampling... Hit Ctrl-C to end. .... As instructed, use the kbd:[Ctrl+C] key combination to stop the process. Upon termination, the script will display a list of kernel functions and timing information, sorting the output in increasing order of time: [source,shell] .... kernel`_thread_lock_flags 2 0.0% 0xc1097063 2 0.0% kernel`sched_userret 2 0.0% kernel`kern_select 2 0.0% kernel`generic_copyin 3 0.0% kernel`_mtx_assert 3 0.0% kernel`vm_fault 3 0.0% kernel`sopoll_generic 3 0.0% kernel`fixup_filename 4 0.0% kernel`_isitmyx 4 0.0% kernel`find_instance 4 0.0% kernel`_mtx_unlock_flags 5 0.0% kernel`syscall 5 0.0% kernel`DELAY 5 0.0% 0xc108a253 6 0.0% kernel`witness_lock 7 0.0% kernel`read_aux_data_no_wait 7 0.0% kernel`Xint0x80_syscall 7 0.0% kernel`witness_checkorder 7 0.0% kernel`sse2_pagezero 8 0.0% kernel`strncmp 9 0.0% kernel`spinlock_exit 10 0.0% kernel`_mtx_lock_flags 11 0.0% kernel`witness_unlock 15 0.0% kernel`sched_idletd 137 0.3% 0xc10981a5 42139 99.3% .... This script will also work with kernel modules. To use this feature, run the script with `-m`: [source,shell] .... # ./hotkernel -m Sampling... Hit Ctrl-C to end. ^C MODULE COUNT PCNT 0xc107882e 1 0.0% 0xc10e6aa4 1 0.0% 0xc1076983 1 0.0% 0xc109708a 1 0.0% 0xc1075a5d 1 0.0% 0xc1077325 1 0.0% 0xc108a245 1 0.0% 0xc107730d 1 0.0% 0xc1097063 2 0.0% 0xc108a253 73 0.0% kernel 874 0.4% 0xc10981a5 213781 99.6% .... The [.filename]#procsystime# script captures and prints the system call time usage for a given process `ID` (`PID`) or process name. In the following example, a new instance of [.filename]#/bin/csh# was spawned. Then, [.filename]#procsystime# was executed and remained waiting while a few commands were typed on the other incarnation of `csh`. These are the results of this test: [source,shell] .... # ./procsystime -n csh Tracing... Hit Ctrl-C to end... ^C Elapsed Times for processes csh, SYSCALL TIME (ns) getpid 6131 sigreturn 8121 close 19127 fcntl 19959 dup 26955 setpgid 28070 stat 31899 setitimer 40938 wait4 62717 sigaction 67372 sigprocmask 119091 gettimeofday 183710 write 263242 execve 492547 ioctl 770073 vfork 3258923 sigsuspend 6985124 read 3988049784 .... As shown, the man:read[2] system call used the most time in nanoseconds while the man:getpid[2] system call used the least amount of time. diff --git a/documentation/content/en/books/handbook/firewalls/_index.adoc b/documentation/content/en/books/handbook/firewalls/_index.adoc index 3a59a59e26..e95478c447 100644 --- a/documentation/content/en/books/handbook/firewalls/_index.adoc +++ b/documentation/content/en/books/handbook/firewalls/_index.adoc @@ -1,2691 +1,2691 @@ --- title: Chapter 34. Firewalls part: IV. Network Communication prev: books/handbook/network-servers next: books/handbook/advanced-networking description: "FreeBSD has three firewalls built into the base system: PF, IPFW, and IPFILTER. This chapter covers how to define packet filtering rules, the differences between the firewalls built into FreeBSD and how to use them" tags: ["firewall", "pf", "ipfw", "ipfilter", "blocklistd", "filtering"] showBookMenu: true weight: 38 params: path: "/books/handbook/firewalls/" --- [[firewalls]] = Firewalls :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumoffset: 34 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/firewalls/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[firewalls-intro]] == Synopsis Firewalls make it possible to filter the incoming and outgoing traffic that flows through a system. A firewall can use one or more sets of "rules" to inspect network packets as they come in or go out of network connections and either allows the traffic through or blocks it. The rules of a firewall can inspect one or more characteristics of the packets such as the protocol type, source or destination host address, and source or destination port. Firewalls can enhance the security of a host or a network. They can be used to do one or more of the following: * Protect and insulate the applications, services, and machines of an internal network from unwanted traffic from the public Internet. * Limit or disable access from hosts of the internal network to services of the public Internet. * Support network address translation (NAT), which allows an internal network to use private IP addresses and share a single connection to the public Internet using either a single IP address or a shared pool of automatically assigned public addresses. FreeBSD has three firewalls built into the base system: PF, IPFW, and IPFILTER, also known as IPF. FreeBSD also provides two traffic shapers for controlling bandwidth usage: man:altq[4] and man:dummynet[4]. ALTQ has traditionally been closely tied with PF and dummynet with IPFW. Each firewall uses rules to control the access of packets to and from a FreeBSD system, although they go about it in different ways and each has a different rule syntax. FreeBSD provides multiple firewalls in order to meet the different requirements and preferences for a wide variety of users. Each user should evaluate which firewall best meets their needs. Read this chapter to learn: * How to define packet filtering rules. * The differences between the firewalls built into FreeBSD. * How to use and configure the PF firewall. * How to use and configure the IPFW firewall. * How to use and configure the IPFILTER firewall. Before reading this chapter: * Understand basic FreeBSD and Internet concepts. [NOTE] ==== Since all firewalls are based on inspecting the values of selected packet control fields, the creator of the firewall ruleset must have an understanding of how TCP/IP works, what the different values in the packet control fields are, and how these values are used in a normal session conversation. -For a good introduction, refer to http://www.ipprimer.com[Daryl's TCP/IP Primer]. +For a good introduction, refer to https://www.ipprimer.com[Daryl's TCP/IP Primer]. ==== [[firewalls-concepts]] == Firewall Concepts A ruleset contains a group of rules which pass or block packets based on the values contained in the packet. The bi-directional exchange of packets between hosts comprises a session conversation. The firewall ruleset processes both the packets arriving from the public Internet, as well as the packets produced by the system as a response to them. Each TCP/IP service is predefined by its protocol and listening port. Packets destined for a specific service originate from the source address using an unprivileged port and target the specific service port on the destination address. All the above parameters can be used as selection criteria to create rules which will pass or block services. To lookup unknown port numbers, refer to [.filename]#/etc/services#. Alternatively, visit https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers[https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers] and do a port number lookup to find the purpose of a particular port number. -Check out this link for http://web.archive.org/web/20150803024617/http://www.sans.org/security-resources/idfaq/oddports.php[port numbers used by Trojans]. +Check out this link for https://web.archive.org/web/20150803024617/http://www.sans.org/security-resources/idfaq/oddports.php[port numbers used by Trojans]. FTP has two modes: active mode and passive mode. The difference is in how the data channel is acquired. Passive mode is more secure as the data channel is acquired by the ordinal ftp session requester. For a good explanation of FTP and the different modes, see http://www.slacksite.com/other/ftp.html[http://www.slacksite.com/other/ftp.html]. A firewall ruleset can be either "exclusive" or "inclusive". An exclusive firewall allows all traffic through except for the traffic matching the ruleset. An inclusive firewall does the reverse as it only allows traffic matching the rules through and blocks everything else. An inclusive firewall offers better control of the outgoing traffic, making it a better choice for systems that offer services to the public Internet. It also controls the type of traffic originating from the public Internet that can gain access to a private network. All traffic that does not match the rules is blocked and logged. Inclusive firewalls are generally safer than exclusive firewalls because they significantly reduce the risk of allowing unwanted traffic. [NOTE] ==== Unless noted otherwise, all configuration and example rulesets in this chapter create inclusive firewall rulesets. ==== Security can be tightened further using a "stateful firewall". This type of firewall keeps track of open connections and only allows traffic which either matches an existing connection or opens a new, allowed connection. Stateful filtering treats traffic as a bi-directional exchange of packets comprising a session. When state is specified on a matching rule the firewall dynamically generates internal rules for each anticipated packet being exchanged during the session. It has sufficient matching capabilities to determine if a packet is valid for a session. Any packets that do not properly fit the session template are automatically rejected. When the session completes, it is removed from the dynamic state table. Stateful filtering allows one to focus on blocking/passing new sessions. If the new session is passed, all its subsequent packets are allowed automatically and any impostor packets are automatically rejected. If a new session is blocked, none of its subsequent packets are allowed. Stateful filtering provides advanced matching abilities capable of defending against the flood of different attack methods employed by attackers. NAT stands for _Network Address Translation_. NAT function enables the private LAN behind the firewall to share a single ISP-assigned IP address, even if that address is dynamically assigned. NAT allows each computer in the LAN to have Internet access, without having to pay the ISP for multiple Internet accounts or IP addresses. NAT will automatically translate the private LAN IP address for each system on the LAN to the single public IP address as packets exit the firewall bound for the public Internet. It also performs the reverse translation for returning packets. According to RFC 1918, the following IP address ranges are reserved for private networks which will never be routed directly to the public Internet, and therefore are available for use with NAT: * `10.0.0.0/8`. * `172.16.0.0/12`. * `192.168.0.0/16`. [WARNING] ==== When working with the firewall rules, be _very careful_. Some configurations _can lock the administrator out_ of the server. To be on the safe side, consider performing the initial firewall configuration from the local console rather than doing it remotely over ssh. ==== [[firewalls-pf]] == PF Since FreeBSD 5.3, a ported version of OpenBSD's PF firewall has been included as an integrated part of the base system. PF is a complete, full-featured firewall that has optional support for ALTQ (Alternate Queuing), which provides Quality of Service (QoS). -The OpenBSD Project maintains the definitive reference for PF in the http://www.openbsd.org/faq/pf/[PF FAQ]. -Peter Hansteen maintains a thorough PF tutorial at http://home.nuug.no/\~peter/pf/[http://home.nuug.no/~peter/pf/]. +The OpenBSD Project maintains the definitive reference for PF in the https://www.openbsd.org/faq/pf/[PF FAQ]. +Peter Hansteen maintains a thorough PF tutorial at https://home.nuug.no/\~peter/pf/[https://home.nuug.no/~peter/pf/]. [WARNING] ==== -When reading the http://www.openbsd.org/faq/pf/[PF FAQ], keep in mind that FreeBSD's version of PF has diverged substantially from the upstream OpenBSD version over the years. +When reading the https://www.openbsd.org/faq/pf/[PF FAQ], keep in mind that FreeBSD's version of PF has diverged substantially from the upstream OpenBSD version over the years. Not all features work the same way on FreeBSD as they do in OpenBSD and vice versa. ==== The {freebsd-pf} is a good place to ask questions about configuring and running the PF firewall. Check the mailing list archives before asking a question as it may have already been answered. This section of the Handbook focuses on PF as it pertains to FreeBSD. It demonstrates how to enable PF and ALTQ. It also provides several examples for creating rulesets on a FreeBSD system. === Enabling PF To use PF, its kernel module must be first loaded. This section describes the entries that can be added to [.filename]#/etc/rc.conf# to enable PF. Start by adding `pf_enable=yes` to [.filename]#/etc/rc.conf#: [source,shell] .... # sysrc pf_enable=yes .... Additional options, described in man:pfctl[8], can be passed to PF when it is started. Add or change this entry in [.filename]#/etc/rc.conf# and specify any required flags between the two quotes (`""`): [.programlisting] .... pf_flags="" # additional flags for pfctl startup .... PF will not start if it cannot find its ruleset configuration file. By default, FreeBSD does not ship with a ruleset and there is no [.filename]#/etc/pf.conf#. Example rulesets can be found in [.filename]#/usr/share/examples/pf/#. If a custom ruleset has been saved somewhere else, add a line to [.filename]#/etc/rc.conf# which specifies the full path to the file: [.programlisting] .... pf_rules="/path/to/pf.conf" .... Logging support for PF is provided by man:pflog[4]. To enable logging support, add `pflog_enable=yes` to [.filename]#/etc/rc.conf#: [source,shell] .... # sysrc pflog_enable=yes .... The following lines can also be added to change the default location of the log file or to specify any additional flags to pass to man:pflog[4] when it is started: [.programlisting] .... pflog_logfile="/var/log/pflog" # where pflogd should store the logfile pflog_flags="" # additional flags for pflogd startup .... Finally, if there is a LAN behind the firewall and packets need to be forwarded for the computers on the LAN, or NAT is required, enable the following option: [.programlisting] .... gateway_enable="YES" # Enable as LAN gateway .... After saving the needed edits, PF can be started with logging support by typing: [source,shell] .... # service pf start # service pflog start .... By default, PF reads its configuration rules from [.filename]#/etc/pf.conf# and modifies, drops, or passes packets according to the rules or definitions specified in this file. The FreeBSD installation includes several sample files located in [.filename]#/usr/share/examples/pf/#. -Refer to the http://www.openbsd.org/faq/pf/[PF FAQ] for complete coverage of PF rulesets. +Refer to the https://www.openbsd.org/faq/pf/[PF FAQ] for complete coverage of PF rulesets. To control PF, use `pfctl`. crossref:firewalls[pfctl,Useful `pfctl` Options] summarizes some useful options to this command. Refer to man:pfctl[8] for a description of all available options: [[pfctl]] .Useful `pfctl` Options [cols="1,1", frame="none", options="header"] |=== | Command | Purpose |`pfctl -e` |Enable PF. |`pfctl -d` |Disable PF. |`pfctl -F all -f /etc/pf.conf` |Flush all NAT, filter, state, and table rules and reload [.filename]#/etc/pf.conf#. |`pfctl -s [ rules \| nat \| states ]` |Report on the filter rules, NAT rules, or state table. |`pfctl -vnf /etc/pf.conf` |Check [.filename]#/etc/pf.conf# for errors, but do not load ruleset. |=== [TIP] ==== package:security/sudo[] is useful for running commands like `pfctl` that require elevated privileges. It can be installed from the Ports Collection. ==== To keep an eye on the traffic that passes through the PF firewall, consider installing the package:sysutils/pftop[] package or port. Once installed, pftop can be run to view a running snapshot of traffic in a format which is similar to man:top[1]. [[pf-tutorial]] === PF Rulesets This section demonstrates how to create a customized ruleset. It starts with the simplest of rulesets and builds upon its concepts using several examples to demonstrate real-world usage of PF's many features. The simplest possible ruleset is for a single machine that does not run any services and which needs access to one network, which may be the Internet. To create this minimal ruleset, edit [.filename]#/etc/pf.conf# so it looks like this: [.programlisting] .... block in all pass out all keep state .... The first rule denies all incoming traffic by default. The second rule allows connections created by this system to pass out, while retaining state information on those connections. This state information allows return traffic for those connections to pass back and should only be used on machines that can be trusted. The ruleset can be loaded with: [source,shell] .... # pfctl -e ; pfctl -f /etc/pf.conf .... In addition to keeping state, PF provides _lists_ and _macros_ which can be defined for use when creating rules. Macros can include lists and need to be defined before use. As an example, insert these lines at the very top of the ruleset: [.programlisting] .... tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }" udp_services = "{ domain }" .... PF understands port names as well as port numbers, as long as the names are listed in [.filename]#/etc/services#. This example creates two macros. The first is a list of seven TCP port names and the second is one UDP port name. Once defined, macros can be used in rules. In this example, all traffic is blocked except for the connections initiated by this system for the seven specified TCP services and the one specified UDP service: [.programlisting] .... tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }" udp_services = "{ domain }" block all pass out proto tcp to any port $tcp_services keep state pass proto udp to any port $udp_services keep state .... Even though UDP is considered to be a stateless protocol, PF is able to track some state information. For example, when a UDP request is passed which asks a name server about a domain name, PF will watch for the response to pass it back. Whenever an edit is made to a ruleset, the new rules must be loaded so they can be used: [source,shell] .... # pfctl -f /etc/pf.conf .... If there are no syntax errors, `pfctl` will not output any messages during the rule load. Rules can also be tested before attempting to load them: [source,shell] .... # pfctl -nf /etc/pf.conf .... Including `-n` causes the rules to be interpreted only, but not loaded. This provides an opportunity to correct any errors. At all times, the last valid ruleset loaded will be enforced until either PF is disabled or a new ruleset is loaded. [TIP] ==== Adding `-v` to a `pfctl` ruleset verify or load will display the fully parsed rules exactly the way they will be loaded. This is extremely useful when debugging rules. ==== [[pftut-gateway]] ==== A Simple Gateway with NAT This section demonstrates how to configure a FreeBSD system running PF to act as a gateway for at least one other machine. The gateway needs at least two network interfaces, each connected to a separate network. In this example, [.filename]#xl0# is connected to the Internet and [.filename]#xl1# is connected to the internal network. First, enable the gateway to let the machine forward the network traffic it receives on one interface to another interface. This sysctl setting will forward IPv4 packets: [source,shell] .... # sysctl net.inet.ip.forwarding=1 .... To forward IPv6 traffic, use: [source,shell] .... # sysctl net.inet6.ip6.forwarding=1 .... To enable these settings at system boot, use man:sysrc[8] to add them to [.filename]#/etc/rc.conf#: [source,shell] .... # sysrc gateway_enable=yes # sysrc ipv6_gateway_enable=yes .... Verify with `ifconfig` that both of the interfaces are up and running. Next, create the PF rules to allow the gateway to pass traffic. While the following rule allows stateful traffic from hosts of the internal network to pass to the gateway, the `to` keyword does not guarantee passage all the way from source to destination: [.programlisting] .... pass in on xl1 from xl1:network to xl0:network port $ports keep state .... That rule only lets the traffic pass in to the gateway on the internal interface. To let the packets go further, a matching rule is needed: [.programlisting] .... pass out on xl0 from xl1:network to xl0:network port $ports keep state .... While these two rules will work, rules this specific are rarely needed. For a busy network admin, a readable ruleset is a safer ruleset. The remainder of this section demonstrates how to keep the rules as simple as possible for readability. For example, those two rules could be replaced with one rule: [.programlisting] .... pass from xl1:network to any port $ports keep state .... The `interface:network` notation can be replaced with a macro to make the ruleset even more readable. For example, a `$localnet` macro could be defined as the network directly attached to the internal interface (`$xl1:network`). Alternatively, the definition of `$localnet` could be changed to an _IP address/netmask_ notation to denote a network, such as `192.168.100.1/24` for a subnet of private addresses. If required, `$localnet` could even be defined as a list of networks. Whatever the specific needs, a sensible `$localnet` definition could be used in a typical pass rule as follows: [.programlisting] .... pass from $localnet to any port $ports keep state .... The following sample ruleset allows all traffic initiated by machines on the internal network. It first defines two macros to represent the external and internal 3COM interfaces of the gateway. [NOTE] ==== For dialup users, the external interface will use [.filename]#tun0#. For an ADSL connection, specifically those using PPP over Ethernet (PPPoE), the correct external interface is [.filename]#tun0#, not the physical Ethernet interface. ==== [.programlisting] .... ext_if = "xl0" # macro for external interface - use tun0 for PPPoE int_if = "xl1" # macro for internal interface localnet = $int_if:network # ext_if IP address could be dynamic, hence ($ext_if) nat on $ext_if from $localnet to any -> ($ext_if) block all pass from { lo0, $localnet } to any keep state .... This ruleset introduces the `nat` rule which is used to handle the network address translation from the non-routable addresses inside the internal network to the IP address assigned to the external interface. The parentheses surrounding the last part of the nat rule `($ext_if)` is included when the IP address of the external interface is dynamically assigned. It ensures that network traffic runs without serious interruptions even if the external IP address changes. Note that this ruleset probably allows more traffic to pass out of the network than is needed. One reasonable setup could create this macro: [.programlisting] .... client_out = "{ ftp-data, ftp, ssh, domain, pop3, auth, nntp, http, \ https, cvspserver, 2628, 5999, 8000, 8080 }" .... to use in the main pass rule: [.programlisting] .... pass inet proto tcp from $localnet to any port $client_out \ flags S/SA keep state .... A few other pass rules may be needed. This one enables SSH on the external interface: [.programlisting] .... pass in inet proto tcp to $ext_if port ssh .... This macro definition and rule allows DNS and NTP for internal clients: [.programlisting] .... udp_services = "{ domain, ntp }" pass quick inet proto { tcp, udp } to any port $udp_services keep state .... Note the `quick` keyword in this rule. Since the ruleset consists of several rules, it is important to understand the relationships between the rules in a ruleset. Rules are evaluated from top to bottom, in the sequence they are written. For each packet or connection evaluated by PF, _the last matching rule_ in the ruleset is the one which is applied. However, when a packet matches a rule which contains the `quick` keyword, the rule processing stops and the packet is treated according to that rule. This is very useful when an exception to the general rules is needed. [[pftut-ftp]] ==== Creating an FTP Proxy Configuring working FTP rules can be problematic due to the nature of the FTP protocol. FTP pre-dates firewalls by several decades and is insecure in its design. The most common points against using FTP include: * Passwords are transferred in the clear. * The protocol demands the use of at least two TCP connections (control and data) on separate ports. * When a session is established, data is communicated using randomly selected ports. All of these points present security challenges, even before considering any potential security weaknesses in client or server software. More secure alternatives for file transfer exist, such as man:sftp[1] or man:scp[1], which both feature authentication and data transfer over encrypted connections. For those situations when FTP is required, PF provides redirection of FTP traffic to a small proxy program called man:ftp-proxy[8], which is included in the base system of FreeBSD. The role of the proxy is to dynamically insert and delete rules in the ruleset, using a set of anchors, to correctly handle FTP traffic. To enable the FTP proxy, add this line to [.filename]#/etc/rc.conf#: [.programlisting] .... ftpproxy_enable="YES" .... Then start the proxy by running: [source,bash] .... # service ftp-proxy start .... For a basic configuration, three elements need to be added to [.filename]#/etc/pf.conf#. First, the anchors which the proxy will use to insert the rules it generates for the FTP sessions: [.programlisting] .... nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*" .... Second, a pass rule is needed to allow FTP traffic in to the proxy. Third, redirection and NAT rules need to be defined before the filtering rules. Insert this `rdr` rule immediately after the `nat` rule: [.programlisting] .... rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021 .... Finally, allow the redirected traffic to pass: [.programlisting] .... pass out proto tcp from $proxy to any port ftp .... where `$proxy` expands to the address the proxy daemon is bound to. Save [.filename]#/etc/pf.conf#, load the new rules, and verify from a client that FTP connections are working: [source,shell] .... # pfctl -f /etc/pf.conf .... This example covers a basic setup where the clients in the local network need to contact FTP servers elsewhere. This basic configuration should work well with most combinations of FTP clients and servers. As shown in man:ftp-proxy[8], the proxy's behavior can be changed in various ways by adding options to the `ftpproxy_flags=` line. Some clients or servers may have specific quirks that must be compensated for in the configuration, or there may be a need to integrate the proxy in specific ways such as assigning FTP traffic to a specific queue. For ways to run an FTP server protected by PF and man:ftp-proxy[8], configure a separate `ftp-proxy` in reverse mode, using `-R`, on a separate port with its own redirecting pass rule. [[pftut-icmp]] ==== Managing ICMP Many of the tools used for debugging or troubleshooting a TCP/IP network rely on the Internet Control Message Protocol (ICMP), which was designed specifically with debugging in mind. The ICMP protocol sends and receives _control messages_ between hosts and gateways, mainly to provide feedback to a sender about any unusual or difficult conditions enroute to the target host. Routers use ICMP to negotiate packet sizes and other transmission parameters in a process often referred to as _path MTU discovery_. From a firewall perspective, some ICMP control messages are vulnerable to known attack vectors. Also, letting all diagnostic traffic pass unconditionally makes debugging easier, but it also makes it easier for others to extract information about the network. For these reasons, the following rule may not be optimal: [.programlisting] .... pass inet proto icmp from any to any .... One solution is to let all ICMP traffic from the local network through while stopping all probes from outside the network: [.programlisting] .... pass inet proto icmp from $localnet to any keep state pass inet proto icmp from any to $ext_if keep state .... Additional options are available which demonstrate some of PF's flexibility. For example, rather than allowing all ICMP messages, one can specify the messages used by man:ping[8] and man:traceroute[8]. Start by defining a macro for that type of message: [.programlisting] .... icmp_types = "echoreq" .... and a rule which uses the macro: [.programlisting] .... pass inet proto icmp all icmp-type $icmp_types keep state .... If other types of ICMP packets are needed, expand `icmp_types` to a list of those packet types. Type `more /usr/src/sbin/pfctl/pfctl_parser.c` to see the list of ICMP message types supported by PF. -Refer to http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml[http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml] for an explanation of each message type. +Refer to https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml[https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml] for an explanation of each message type. Since Unix `traceroute` uses UDP by default, another rule is needed to allow Unix `traceroute`: [.programlisting] .... # allow out the default range for traceroute(8): pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state .... Since `TRACERT.EXE` on Microsoft Windows systems uses ICMP echo request messages, only the first rule is needed to allow network traces from those systems. Unix `traceroute` can be instructed to use other protocols as well, and will use ICMP echo request messages if `-I` is used. Check the man:traceroute[8] man page for details. [[pftut-pathmtudisc]] ===== Path MTU Discovery Internet protocols are designed to be device independent, and one consequence of device independence is that the optimal packet size for a given connection cannot always be predicted reliably. The main constraint on packet size is the _Maximum Transmission Unit_ (MTU) which sets the upper limit on the packet size for an interface. Type `ifconfig` to view the MTUs for a system's network interfaces. TCP/IP uses a process known as path MTU discovery to determine the right packet size for a connection. This process sends packets of varying sizes with the "Do not fragment" flag set, expecting an ICMP return packet of "type 3, code 4" when the upper limit has been reached. Type 3 means "destination unreachable", and code 4 is short for "fragmentation needed, but the do-not-fragment flag is set". To allow path MTU discovery in order to support connections to other MTUs, add the `destination unreachable` type to the `icmp_types` macro: [.programlisting] .... icmp_types = "{ echoreq, unreach }" .... Since the pass rule already uses that macro, it does not need to be modified to support the new ICMP type: [.programlisting] .... pass inet proto icmp all icmp-type $icmp_types keep state .... PF allows filtering on all variations of ICMP types and codes. The list of possible types and codes are documented in man:icmp[4] and man:icmp6[4]. [[pftut-tables]] ==== Using Tables Some types of data are relevant to filtering and redirection at a given time, but their definition is too long to be included in the ruleset file. PF supports the use of tables, which are defined lists that can be manipulated without needing to reload the entire ruleset, and which can provide fast lookups. Table names are always enclosed within `< >`, like this: [.programlisting] .... table { 192.168.2.0/24, !192.168.2.5 } .... In this example, the `192.168.2.0/24` network is part of the table, except for the address `192.168.2.5`, which is excluded using the `!` operator. It is also possible to load tables from files where each item is on a separate line, as seen in this example [.filename]#/etc/clients#: [.programlisting] .... 192.168.2.0/24 !192.168.2.5 .... To refer to the file, define the table like this: [.programlisting] .... table persist file "/etc/clients" .... Once the table is defined, it can be referenced by a rule: [.programlisting] .... pass inet proto tcp from to any port $client_out flags S/SA keep state .... A table's contents can be manipulated live, using `pfctl`. This example adds another network to the table: [source,shell] .... # pfctl -t clients -T add 192.168.1.0/16 .... Note that any changes made this way will take affect now, making them ideal for testing, but will not survive a power failure or reboot. To make the changes permanent, modify the definition of the table in the ruleset or edit the file that the table refers to. One can maintain the on-disk copy of the table using a man:cron[8] job which dumps the table's contents to disk at regular intervals, using a command such as `pfctl -t clients -T show >/etc/clients`. Alternatively, [.filename]#/etc/clients# can be updated with the in-memory table contents: [source,shell] .... # pfctl -t clients -T replace -f /etc/clients .... [[pftut-overload]] ==== Using Overload Tables to Protect SSH Those who run SSH on an external interface have probably seen something like this in the authentication logs: [.programlisting] .... Sep 26 03:12:34 skapet sshd[25771]: Failed password for root from 200.72.41.31 port 40992 ssh2 Sep 26 03:12:34 skapet sshd[5279]: Failed password for root from 200.72.41.31 port 40992 ssh2 Sep 26 03:12:35 skapet sshd[5279]: Received disconnect from 200.72.41.31: 11: Bye Bye Sep 26 03:12:44 skapet sshd[29635]: Invalid user admin from 200.72.41.31 Sep 26 03:12:44 skapet sshd[24703]: input_userauth_request: invalid user admin Sep 26 03:12:44 skapet sshd[24703]: Failed password for invalid user admin from 200.72.41.31 port 41484 ssh2 .... This is indicative of a brute force attack where somebody or some program is trying to discover the user name and password which will let them into the system. If external SSH access is needed for legitimate users, changing the default port used by SSH can offer some protection. However, PF provides a more elegant solution. Pass rules can contain limits on what connecting hosts can do and violators can be banished to a table of addresses which are denied some or all access. It is even possible to drop all existing connections from machines which overreach the limits. To configure this, create this table in the tables section of the ruleset: [.programlisting] .... table persist .... Then, somewhere early in the ruleset, add rules to block brute access while allowing legitimate access: [.programlisting] .... block quick from pass inet proto tcp from any to $localnet port $tcp_services \ flags S/SA keep state \ (max-src-conn 100, max-src-conn-rate 15/5, \ overload flush global) .... The part in parentheses defines the limits and the numbers should be changed to meet local requirements. It can be read as follows: `max-src-conn` is the number of simultaneous connections allowed from one host. `max-src-conn-rate` is the rate of new connections allowed from any single host (_15_) per number of seconds (_5_). `overload ` means that any host which exceeds these limits gets its address added to the `bruteforce` table. The ruleset blocks all traffic from addresses in the `bruteforce` table. Finally, `flush global` says that when a host reaches the limit, that all (`global`) of that host's connections will be terminated (`flush`). [NOTE] ==== -These rules will _not_ block slow bruteforcers, as described in http://home.nuug.no/\~peter/hailmary2013/[http://home.nuug.no/~peter/hailmary2013/]. +These rules will _not_ block slow bruteforcers, as described in https://home.nuug.no/\~peter/hailmary2013/[https://home.nuug.no/~peter/hailmary2013/]. ==== This example ruleset is intended mainly as an illustration. For example, if a generous number of connections in general are wanted, but the desire is to be more restrictive when it comes to ssh, supplement the rule above with something like the one below, early on in the rule set: [.programlisting] .... pass quick proto { tcp, udp } from any to any port ssh \ flags S/SA keep state \ (max-src-conn 15, max-src-conn-rate 5/3, \ overload flush global) .... [NOTE] ==== *It May Not be Necessary to Block All Overloaders:* + It is worth noting that the overload mechanism is a general technique which does not apply exclusively to SSH, and it is not always optimal to entirely block all traffic from offenders. For example, an overload rule could be used to protect a mail service or a web service, and the overload table could be used in a rule to assign offenders to a queue with a minimal bandwidth allocation or to redirect to a specific web page. ==== Over time, tables will be filled by overload rules and their size will grow incrementally, taking up more memory. Sometimes an IP address that is blocked is a dynamically assigned one, which has since been assigned to a host who has a legitimate reason to communicate with hosts in the local network. For situations like these, pfctl provides the ability to expire table entries. For example, this command will remove `` table entries which have not been referenced for `86400` seconds: [source,shell] .... # pfctl -t bruteforce -T expire 86400 .... Similar functionality is provided by package:security/expiretable[], which removes table entries which have not been accessed for a specified period of time. Once installed, expiretable can be run to remove `` table entries older than a specified age. This example removes all entries older than 24 hours: [.programlisting] .... /usr/local/sbin/expiretable -v -d -t 24h bruteforce .... [[pftut-spamd]] ==== Protecting Against SPAM Not to be confused with the spamd daemon which comes bundled with spamassassin, package:mail/spamd[] can be configured with PF to provide an outer defense against SPAM. This spamd hooks into the PF configuration using a set of redirections. Spammers tend to send a large number of messages, and SPAM is mainly sent from a few spammer friendly networks and a large number of hijacked machines, both of which are reported to _blocklists_ fairly quickly. When an SMTP connection from an address in a blocklist is received, spamd presents its banner and immediately switches to a mode where it answers SMTP traffic one byte at a time. This technique, which is intended to waste as much time as possible on the spammer's end, is called _tarpitting_. The specific implementation which uses one byte SMTP replies is often referred to as _stuttering_. This example demonstrates the basic procedure for setting up spamd with automatically updated blocklists. Refer to the man pages which are installed with package:mail/spamd[] for more information. [.procedure] **** .Procedure: Configuring spamd . Install the package:mail/spamd[] package or port. To use spamd's greylisting features, man:fdescfs[5] must be mounted at [.filename]#/dev/fd#. Add the following line to [.filename]#/etc/fstab#: + [.programlisting] .... fdescfs /dev/fd fdescfs rw 0 0 .... + Then, mount the filesystem: + [.programlisting] .... # mount fdescfs .... . Next, edit the PF ruleset to include: + [.programlisting] .... table persist table persist rdr pass on $ext_if inet proto tcp from to \ { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 rdr pass on $ext_if inet proto tcp from ! to \ { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 .... + The two tables `` and `` are essential. SMTP traffic from an address listed in `` but not in `` is redirected to the spamd daemon listening at port 8025. . The next step is to configure spamd in [.filename]#/usr/local/etc/spamd.conf# and to add some [.filename]#rc.conf# parameters. + The installation of package:mail/spamd[] includes a sample configuration file ([.filename]#/usr/local/etc/spamd.conf.sample#) and a man page for [.filename]#spamd.conf#. Refer to these for additional configuration options beyond those shown in this example. + One of the first lines in the configuration file that does not begin with a `+#+` comment sign contains the block which defines the `all` list, which specifies the lists to use: + [.programlisting] .... all:\ :traplist:allowlist: .... + This entry adds the desired blocklists, separated by colons (`:`). To use an allowlist to subtract addresses from a blocklist, add the name of the allowlist _immediately_ after the name of that blocklist. For example: `:blocklist:allowlist:`. + This is followed by the specified blocklist's definition: + [.programlisting] .... traplist:\ :black:\ :msg="SPAM. Your address %A has sent spam within the last 24 hours":\ :method=http:\ :file=www.openbsd.org/spamd/traplist.gz .... + where the first line is the name of the blocklist and the second line specifies the list type. The `msg` field contains the message to display to blocklisted senders during the SMTP dialogue. The `method` field specifies how spamd-setup fetches the list data; supported methods are `http`, `ftp`, from a `file` in a mounted file system, and via `exec` of an external program. Finally, the `file` field specifies the name of the file spamd expects to receive. + The definition of the specified allowlist is similar, but omits the `msg` field since a message is not needed: + [.programlisting] .... allowlist:\ :white:\ :method=file:\ :file=/var/mail/allowlist.txt .... + [TIP] ==== *Choose Data Sources with Care:* + Using all the blocklists in the sample [.filename]#spamd.conf# will block large blocks of the Internet. Administrators need to edit the file to create an optimal configuration which uses applicable data sources and, when necessary, uses custom lists. ==== + Next, add this entry to [.filename]#/etc/rc.conf#. Additional flags are described in the man page specified by the comment: + [.programlisting] .... spamd_flags="-v" # use "" and see spamd-setup(8) for flags .... + When finished, reload the ruleset, start spamd by typing `service obspamd start`, and complete the configuration using `spamd-setup`. Finally, create a man:cron[8] job which calls `spamd-setup` to update the tables at reasonable intervals. **** On a typical gateway in front of a mail server, hosts will soon start getting trapped within a few seconds to several minutes. PF also supports _greylisting_, which temporarily rejects messages from unknown hosts with _45n_ codes. Messages from greylisted hosts which try again within a reasonable time are let through. Traffic from senders which are set up to behave within the limits set by RFC 1123 and RFC 2821 are immediately let through. More information about greylisting as a technique can be found at the http://www.greylisting.org/[greylisting.org] web site. The most amazing thing about greylisting, apart from its simplicity, is that it still works. Spammers and malware writers have been very slow to adapt to bypass this technique. The basic procedure for configuring greylisting is as follows: [.procedure] .Procedure: Configuring Greylisting . Make sure that man:fdescfs[5] is mounted as described in Step 1 of the previous Procedure. . To run spamd in greylisting mode, add this line to [.filename]#/etc/rc.conf#: + [.programlisting] .... spamd_grey="YES" # use spamd greylisting if YES .... + Refer to the spamd man page for descriptions of additional related parameters. . To complete the greylisting setup: + [.programlisting] .... # service obspamd restart # service obspamlogd start .... Behind the scenes, the spamdb database tool and the spamlogd whitelist updater perform essential functions for the greylisting feature. spamdb is the administrator's main interface to managing the block, grey, and allow lists via the contents of the [.filename]#/var/db/spamdb# database. [[pftut-hygiene]] ==== Network Hygiene This section describes how `block-policy`, `scrub`, and `antispoof` can be used to make the ruleset behave sanely. The `block-policy` is an option which can be set in the `options` part of the ruleset, which precedes the redirection and filtering rules. This option determines which feedback, if any, PF sends to hosts that are blocked by a rule. The option has two possible values: `drop` drops blocked packets with no feedback, and `return` returns a status code such as `Connection refused`. If not set, the default policy is `drop`. To change the `block-policy`, specify the desired value: [.programlisting] .... set block-policy return .... In PF, `scrub` is a keyword which enables network packet normalization. This process reassembles fragmented packets and drops TCP packets that have invalid flag combinations. Enabling `scrub` provides a measure of protection against certain kinds of attacks based on incorrect handling of packet fragments. A number of options are available, but the simplest form is suitable for most configurations: [.programlisting] .... scrub in all .... Some services, such as NFS, require specific fragment handling options. Refer to https://home.nuug.no/\~peter/pf/en/scrub.html[https://home.nuug.no/~peter/pf/en/scrub.html] for more information. This example reassembles fragments, clears the "do not fragment" bit, and sets the maximum segment size to 1440 bytes: [.programlisting] .... scrub in all fragment reassemble no-df max-mss 1440 .... The `antispoof` mechanism protects against activity from spoofed or forged IP addresses, mainly by blocking packets appearing on interfaces and in directions which are logically not possible. These rules weed out spoofed traffic coming in from the rest of the world as well as any spoofed packets which originate in the local network: [.programlisting] .... antispoof for $ext_if antispoof for $int_if .... [[pftut-unrouteables]] ==== Handling Non-Routable Addresses Even with a properly configured gateway to handle network address translation, one may have to compensate for other people's misconfigurations. A common misconfiguration is to let traffic with non-routable addresses out to the Internet. Since traffic from non-routeable addresses can play a part in several DoS attack techniques, consider explicitly blocking traffic from non-routeable addresses from entering the network through the external interface. In this example, a macro containing non-routable addresses is defined, then used in blocking rules. Traffic to and from these addresses is quietly dropped on the gateway's external interface. [.programlisting] .... martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \ 10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, \ 0.0.0.0/8, 240.0.0.0/4 }" block drop in quick on $ext_if from $martians to any block drop out quick on $ext_if from any to $martians .... === Enabling ALTQ On FreeBSD, ALTQ can be used with PF to provide Quality of Service (QOS). Once ALTQ is enabled, queues can be defined in the ruleset which determine the processing priority of outbound packets. Before enabling ALTQ, refer to man:altq[4] to determine if the drivers for the network cards installed on the system support it. ALTQ is not available as a loadable kernel module. If the system's interfaces support ALTQ, create a custom kernel using the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]. The following kernel options are available. The first is needed to enable ALTQ. At least one of the other options is necessary to specify the queueing scheduler algorithm: [.programlisting] .... options ALTQ options ALTQ_CBQ # Class Based Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) .... The following scheduler algorithms are available: CBQ:: Class Based Queuing (CBQ) is used to divide a connection's bandwidth into different classes or queues to prioritize traffic based on filter rules. RED:: Random Early Detection (RED) is used to avoid network congestion by measuring the length of the queue and comparing it to the minimum and maximum thresholds for the queue. When the queue is over the maximum, all new packets are randomly dropped. RIO:: In Random Early Detection In and Out (RIO) mode, RED maintains multiple average queue lengths and multiple threshold values, one for each QOS level. HFSC:: -Hierarchical Fair Service Curve Packet Scheduler (HFSC) is described in http://www-2.cs.cmu.edu/\~hzhang/HFSC/main.html[http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html]. +Hierarchical Fair Service Curve Packet Scheduler (HFSC) is described in https://www-2.cs.cmu.edu/\~hzhang/HFSC/main.html[https://www-2.cs.cmu.edu/~hzhang/HFSC/main.html]. PRIQ:: Priority Queuing (PRIQ) always passes traffic that is in a higher queue first. More information about the scheduling algorithms and example rulesets are available at the https://web.archive.org/web/20151109213426/http://www.openbsd.org/faq/pf/queueing.html[OpenBSD's web archive]. [[firewalls-ipfw]] == IPFW IPFW is a stateful firewall written for FreeBSD which supports both IPv4 and IPv6. It is comprised of several components: the kernel firewall filter rule processor and its integrated packet accounting facility, the logging facility, NAT, the man:dummynet[4] traffic shaper, a forward facility, a bridge facility, and an ipstealth facility. FreeBSD provides a sample ruleset in [.filename]#/etc/rc.firewall# which defines several firewall types for common scenarios to assist novice users in generating an appropriate ruleset. IPFW provides a powerful syntax which advanced users can use to craft customized rulesets that meet the security requirements of a given environment. This section describes how to enable IPFW, provides an overview of its rule syntax, and demonstrates several rulesets for common configuration scenarios. [[firewalls-ipfw-enable]] === Enabling IPFW IPFW is included in the basic FreeBSD install as a kernel loadable module, meaning that a custom kernel is not needed in order to enable IPFW. For those users who wish to statically compile IPFW support into a custom kernel, see crossref:firewalls[firewalls-ipfw-kernelconfig, IPFW Kernel Options]. To configure the system to enable IPFW at boot time, add `firewall_enable="YES"` to [.filename]#/etc/rc.conf#: [source,shell] .... # sysrc firewall_enable="YES" .... To use one of the default firewall types provided by FreeBSD, add another line which specifies the type: [source,shell] .... # sysrc firewall_type="open" .... The available types are: * `open`: passes all traffic. * `client`: protects only this machine. * `simple`: protects the whole network. * `closed`: entirely disables IP traffic except for the loopback interface. * `workstation`: protects only this machine using stateful rules. * `UNKNOWN`: disables the loading of firewall rules. * [.filename]#filename#: full path of the file containing the firewall ruleset. If `firewall_type` is set to either `client` or `simple`, modify the default rules found in [.filename]#/etc/rc.firewall# to fit the configuration of the system. Note that the `filename` type is used to load a custom ruleset. An alternate way to load a custom ruleset is to set the `firewall_script` variable to the absolute path of an _executable script_ that includes IPFW commands. The examples used in this section assume that the `firewall_script` is set to [.filename]#/etc/ipfw.rules#: [source,shell] .... # sysrc firewall_script="/etc/ipfw.rules" .... To enable logging through man:syslogd[8], include this line: [source,shell] .... # sysrc firewall_logging="YES" .... [WARNING] ==== Only firewall rules with the `log` option will be logged. The default rules do not include this option and it must be manually added. Therefore it is advisable that the default ruleset is edited for logging. In addition, log rotation may be desired if the logs are stored in a separate file. ==== There is no [.filename]#/etc/rc.conf# variable to set logging limits. To limit the number of times a rule is logged per connection attempt, specify the number using this line in [.filename]#/etc/sysctl.conf#: [source,shell] .... # echo "net.inet.ip.fw.verbose_limit=5" >> /etc/sysctl.conf .... To enable logging through a dedicated interface named `ipfw0`, add this line to [.filename]#/etc/rc.conf# instead: [source,shell] .... # sysrc firewall_logif="YES" .... Then use tcpdump to see what is being logged: [source,shell] .... # tcpdump -t -n -i ipfw0 .... [TIP] ==== There is no overhead due to logging unless tcpdump is attached. ==== After saving the needed edits, start the firewall. To enable logging limits now, also set the `sysctl` value specified above: [source,shell] .... # service ipfw start # sysctl net.inet.ip.fw.verbose_limit=5 .... [[firewalls-ipfw-rules]] === IPFW Rule Syntax When a packet enters the IPFW firewall, it is compared against the first rule in the ruleset and progresses one rule at a time, moving from top to bottom in sequence. When the packet matches the selection parameters of a rule, the rule's action is executed and the search of the ruleset terminates for that packet. This is referred to as "first match wins". If the packet does not match any of the rules, it gets caught by the mandatory IPFW default rule number 65535, which denies all packets and silently discards them. However, if the packet matches a rule that contains the `count`, `skipto`, or `tee` keywords, the search continues. Refer to man:ipfw[8] for details on how these keywords affect rule processing. When creating an IPFW rule, keywords must be written in the following order. Some keywords are mandatory while other keywords are optional. The words shown in uppercase represent a variable and the words shown in lowercase must precede the variable that follows it. The `+#+` symbol is used to mark the start of a comment and may appear at the end of a rule or on its own line. Blank lines are ignored. `_CMD RULE_NUMBER set SET_NUMBER ACTION log LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT OPTIONS_` This section provides an overview of these keywords and their options. It is not an exhaustive list of every possible option. Refer to man:ipfw[8] for a complete description of the rule syntax that can be used when creating IPFW rules. CMD:: Every rule must start with `ipfw add`. RULE_NUMBER:: Each rule is associated with a number from `1` to `65534`. The number is used to indicate the order of rule processing. Multiple rules can have the same number, in which case they are applied according to the order in which they have been added. SET_NUMBER:: Each rule is associated with a set number from `0` to `31`. Sets can be individually disabled or enabled, making it possible to quickly add or delete a set of rules. If a SET_NUMBER is not specified, the rule will be added to set `0`. ACTION:: A rule can be associated with one of the following actions. The specified action will be executed when the packet matches the selection criterion of the rule. + `allow | accept | pass | permit`: these keywords are equivalent and allow packets that match the rule. + `check-state`: checks the packet against the dynamic state table. If a match is found, execute the action associated with the rule which generated this dynamic rule, otherwise move to the next rule. A `check-state` rule does not have selection criterion. If no `check-state` rule is present in the ruleset, the dynamic rules table is checked at the first `keep-state` or `limit` rule. + `count`: updates counters for all packets that match the rule. The search continues with the next rule. + `deny | drop`: either word silently discards packets that match this rule. + Additional actions are available. Refer to man:ipfw[8] for details. LOG_AMOUNT:: When a packet matches a rule with the `log` keyword, a message will be logged to man:syslogd[8] with a facility name of `SECURITY`. Logging only occurs if the number of packets logged for that particular rule does not exceed a specified LOG_AMOUNT. If no LOG_AMOUNT is specified, the limit is taken from the value of `net.inet.ip.fw.verbose_limit`. A value of zero removes the logging limit. Once the limit is reached, logging can be re-enabled by clearing the logging counter or the packet counter for that rule, using `ipfw resetlog`. + [NOTE] ==== Logging is done after all other packet matching conditions have been met, and before performing the final action on the packet. The administrator decides which rules to enable logging on. ==== PROTO:: This optional value can be used to specify any protocol name or number found in [.filename]#/etc/protocols#. SRC:: The `from` keyword must be followed by the source address or a keyword that represents the source address. An address can be represented by `any`, `me` (any address configured on an interface on this system), `me6`, (any IPv6 address configured on an interface on this system), or `table` followed by the number of a lookup table which contains a list of addresses. When specifying an IP address, it can be optionally followed by its CIDR mask or subnet mask. For example, `1.2.3.4/25` or `1.2.3.4:255.255.255.128`. SRC_PORT:: An optional source port can be specified using the port number or name from [.filename]#/etc/services#. DST:: The `to` keyword must be followed by the destination address or a keyword that represents the destination address. The same keywords and addresses described in the SRC section can be used to describe the destination. DST_PORT:: An optional destination port can be specified using the port number or name from [.filename]#/etc/services#. OPTIONS:: Several keywords can follow the source and destination. As the name suggests, OPTIONS are optional. Commonly used options include `in` or `out`, which specify the direction of packet flow, `icmptypes` followed by the type of ICMP message, and `keep-state`. + When a `keep-state` rule is matched, the firewall will create a dynamic rule which matches bidirectional traffic between the source and destination addresses and ports using the same protocol. + The dynamic rules facility is vulnerable to resource depletion from a SYN-flood attack which would open a huge number of dynamic rules. To counter this type of attack with IPFW, use `limit`. This option limits the number of simultaneous sessions by checking the open dynamic rules, counting the number of times this rule and IP address combination occurred. If this count is greater than the value specified by `limit`, the packet is discarded. + Dozens of OPTIONS are available. Refer to man:ipfw[8] for a description of each available option. === Example Ruleset This section demonstrates how to create an example stateful firewall ruleset script named [.filename]#/etc/ipfw.rules#. In this example, all connection rules use `in` or `out` to clarify the direction. They also use `via` _interface-name_ to specify the interface the packet is traveling over. [NOTE] ==== When first creating or testing a firewall ruleset, consider temporarily setting this tunable: [.programlisting] .... net.inet.ip.fw.default_to_accept="1" .... This sets the default policy of man:ipfw[8] to be more permissive than the default `deny ip from any to any`, making it slightly more difficult to get locked out of the system right after a reboot. ==== The firewall script begins by indicating that it is a POSIX(R) shell script and flushes any existing rules. It then creates the `cmd` variable so that `ipfw add` does not have to be typed at the beginning of every rule. It also defines the `pif` variable which represents the name of the interface that is attached to the Internet. [.programlisting] .... #!/bin/sh # Flush out the list before we begin. ipfw -q -f flush # Set rules command prefix cmd="ipfw -q add" pif="dc0" # interface name of NIC attached to Internet .... The first two rules allow all traffic on the trusted internal interface and on the loopback interface: [.programlisting] .... # Change xl0 to LAN NIC interface name $cmd 00005 allow all from any to any via xl0 # No restrictions on Loopback Interface $cmd 00010 allow all from any to any via lo0 .... The next rule allows the packet through if it matches an existing entry in the dynamic rules table: [.programlisting] .... $cmd 00101 check-state .... The next set of rules defines which stateful connections internal systems can create to hosts on the Internet: [.programlisting] .... # Allow access to public DNS # Replace x.x.x.x with the IP address of a public DNS server # and repeat for each DNS server in /etc/resolv.conf $cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state $cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state # Allow access to ISP's DHCP server for cable/DSL configurations. # Use the first rule and check log for IP address. # Then, uncomment the second rule, input the IP address, and delete the first rule $cmd 00120 allow log udp from any to any 67 out via $pif keep-state #$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state # Allow outbound HTTP and HTTPS connections $cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state $cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state # Allow outbound email connections $cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state $cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state # Allow outbound ping $cmd 00250 allow icmp from any to any out via $pif keep-state # Allow outbound NTP $cmd 00260 allow udp from any to any 123 out via $pif keep-state # Allow outbound SSH $cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state # deny and log all other outbound connections $cmd 00299 deny log all from any to any out via $pif .... The next set of rules controls connections from Internet hosts to the internal network. It starts by denying packets typically associated with attacks and then explicitly allows specific types of connections. All the authorized services that originate from the Internet use `limit` to prevent flooding. [.programlisting] .... # Deny all inbound traffic from non-routable reserved address spaces $cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP $cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP $cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP $cmd 00303 deny all from 127.0.0.0/8 to any in via $pif #loopback $cmd 00304 deny all from 0.0.0.0/8 to any in via $pif #loopback $cmd 00305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto-config $cmd 00306 deny all from 192.0.2.0/24 to any in via $pif #reserved for docs $cmd 00307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster interconnect $cmd 00308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast # Deny public pings $cmd 00310 deny icmp from any to any in via $pif # Deny ident $cmd 00315 deny tcp from any to any 113 in via $pif # Deny all Netbios services. $cmd 00320 deny tcp from any to any 137 in via $pif $cmd 00321 deny tcp from any to any 138 in via $pif $cmd 00322 deny tcp from any to any 139 in via $pif $cmd 00323 deny tcp from any to any 81 in via $pif # Deny fragments $cmd 00330 deny all from any to any frag in via $pif # Deny ACK packets that did not match the dynamic rule table $cmd 00332 deny tcp from any to any established in via $pif # Allow traffic from ISP's DHCP server. # Replace x.x.x.x with the same IP address used in rule 00120. #$cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state # Allow HTTP connections to internal web server $cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Allow inbound SSH connections $cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Reject and log all other incoming connections $cmd 00499 deny log all from any to any in via $pif .... The last rule logs all packets that do not match any of the rules in the ruleset: [.programlisting] .... # Everything else is denied and logged $cmd 00999 deny log all from any to any .... [[in-kernel-nat]] === In-kernel NAT FreeBSD's IPFW firewall has two implementations of NAT: the userland implementation man:natd[8], and the more recent in-kernel NAT implementation. Both work in conjunction with IPFW to provide network address translation. This can be used to provide an Internet Connection Sharing solution so that several internal computers can connect to the Internet using a single public IP address. To do this, the FreeBSD machine connected to the Internet must act as a gateway. This system must have two NICs, where one is connected to the Internet and the other is connected to the internal LAN. Each machine connected to the LAN should be assigned an IP address in the private network space, as defined by https://www.ietf.org/rfc/rfc1918.txt[RFC 1918]. Some additional configuration is needed in order to enable the in-kernel NAT facility of IPFW. To enable in-kernel NAT support at boot time, the following must be set in [.filename]#/etc/rc.conf#: [.programlisting] .... gateway_enable="YES" firewall_enable="YES" firewall_nat_enable="YES" .... [NOTE] ==== When `firewall_nat_enable` is set but `firewall_enable` is not, it will have no effect and do nothing. This is because the in-kernel NAT implementation is only compatible with IPFW. ==== When the ruleset contains stateful rules, the positioning of the NAT rule is critical and the `skipto` action is used. The `skipto` action requires a rule number so that it knows which rule to jump to. The example below builds upon the firewall ruleset shown in the previous section. It adds some additional entries and modifies some existing rules in order to configure the firewall for in-kernel NAT. It starts by adding some additional variables which represent the rule number to skip to, the `keep-state` option, and a list of TCP ports which will be used to reduce the number of rules. [.programlisting] .... #!/bin/sh ipfw -q -f flush cmd="ipfw -q add" skip="skipto 1000" pif=dc0 ks="keep-state" good_tcpo="22,25,37,53,80,443,110" .... With in-kernel NAT it is necessary to disable TCP segmentation offloading (TSO) due to the architecture of man:libalias[3], a library implemented as a kernel module to provide the in-kernel NAT facility of IPFW. TSO can be disabled on a per network interface basis using man:ifconfig[8] or on a system wide basis using man:sysctl[8]. To disable TSO system wide, the following must be set it [.filename]#/etc/sysctl.conf#: [.programlisting] .... net.inet.tcp.tso="0" .... A NAT instance will also be configured. It is possible to have multiple NAT instances each with their own configuration. For this example only one NAT instance is needed, NAT instance number 1. The configuration can take a few options such as: `if` which indicates the public interface, `same_ports` which takes care that aliased ports and local port numbers are mapped the same, `unreg_only` will result in only unregistered (private) address spaces to be processed by the NAT instance, and `reset` which will help to keep a functioning NAT instance even when the public IP address of the IPFW machine changes. For all possible options that can be passed to a single NAT instance configuration consult man:ipfw[8]. When configuring a stateful NATing firewall, it is necessary to allow translated packets to be reinjected in the firewall for further processing. This can be achieved by disabling `one_pass` behavior at the start of the firewall script. [.programlisting] .... ipfw disable one_pass ipfw -q nat 1 config if $pif same_ports unreg_only reset .... The inbound NAT rule is inserted _after_ the two rules which allow all traffic on the trusted and loopback interfaces and after the reassemble rule but _before_ the `check-state` rule. It is important that the rule number selected for this NAT rule, in this example `100`, is higher than the first three rules and lower than the `check-state` rule. Furthermore, because of the behavior of in-kernel NAT it is advised to place a reassemble rule just before the first NAT rule and after the rules that allow traffic on trusted interface. Normally, IP fragmentation should not happen, but when dealing with IPSEC/ESP/GRE tunneling traffic it might and the reassembling of fragments is necessary before handing the complete packet over to the in-kernel NAT facility. [NOTE] ==== The reassemble rule was not needed with userland man:natd[8] because the internal workings of the IPFW `divert` action already takes care of reassembling packets before delivery to the socket as also stated in man:ipfw[8]. The NAT instance and rule number used in this example does not match with the default NAT instance and rule number created by [.filename]#rc.firewall#. [.filename]#rc.firewall# is a script that sets up the default firewall rules present in FreeBSD. ==== [.programlisting] .... $cmd 005 allow all from any to any via xl0 # exclude LAN traffic $cmd 010 allow all from any to any via lo0 # exclude loopback traffic $cmd 099 reass all from any to any in # reassemble inbound packets $cmd 100 nat 1 ip from any to any in via $pif # NAT any inbound packets # Allow the packet through if it has an existing entry in the dynamic rules table $cmd 101 check-state .... The outbound rules are modified to replace the `allow` action with the `$skip` variable, indicating that rule processing will continue at rule `1000`. The seven `tcp` rules have been replaced by rule `125` as the `$good_tcpo` variable contains the seven allowed outbound ports. [NOTE] ==== Remember that IPFW's performance is largely determined by the number of rules present in the ruleset. ==== [.programlisting] .... # Authorized outbound packets $cmd 120 $skip udp from any to x.x.x.x 53 out via $pif $ks $cmd 121 $skip udp from any to x.x.x.x 67 out via $pif $ks $cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks $cmd 130 $skip icmp from any to any out via $pif $ks .... The inbound rules remain the same, except for the very last rule which removes the `via $pif` in order to catch both inbound and outbound rules. The NAT rule must follow this last outbound rule, must have a higher number than that last rule, and the rule number must be referenced by the `skipto` action. In this ruleset, rule number `1000` handles passing all packets to our configured instance for NAT processing. The next rule allows any packet which has undergone NAT processing to pass. [.programlisting] .... $cmd 999 deny log all from any to any $cmd 1000 nat 1 ip from any to any out via $pif # skipto location for outbound stateful rules $cmd 1001 allow ip from any to any .... In this example, rules `100`, `101`, `125`, `1000`, and `1001` control the address translation of the outbound and inbound packets so that the entries in the dynamic state table always register the private LANIP address. Consider an internal web browser which initializes a new outbound HTTP session over port 80. When the first outbound packet enters the firewall, it does not match rule `100` because it is headed out rather than in. It passes rule `101` because this is the first packet and it has not been posted to the dynamic state table yet. The packet finally matches rule `125` as it is outbound on an allowed port and has a source IP address from the internal LAN. On matching this rule, two actions take place. First, the `keep-state` action adds an entry to the dynamic state table and the specified action, `skipto rule 1000`, is executed. Next, the packet undergoes NAT and is sent out to the Internet. This packet makes its way to the destination web server, where a response packet is generated and sent back. This new packet enters the top of the ruleset. It matches rule `100` and has its destination IP address mapped back to the original internal address. It then is processed by the `check-state` rule, is found in the table as an existing session, and is released to the LAN. On the inbound side, the ruleset has to deny bad packets and allow only authorized services. A packet which matches an inbound rule is posted to the dynamic state table and the packet is released to the LAN. The packet generated as a response is recognized by the `check-state` rule as belonging to an existing session. It is then sent to rule `1000` to undergo NAT before being released to the outbound interface. [NOTE] ==== Transitioning from userland man:natd[8] to in-kernel NAT might appear seamless at first but there is small catch. When using the GENERIC kernel, IPFW will load the [.filename]#libalias.ko# kernel module, when `firewall_nat_enable` is enabled in [.filename]#/etc/rc.conf#. The [.filename]#libalias.ko# kernel module only provides basic NAT functionality, whereas the userland implementation man:natd[8] has all NAT functionality available in its userland library without any extra configuration. All functionality refers to the following kernel modules that can additionally be loaded when needed besides the standard [.filename]#libalias.ko# kernel module: [.filename]#alias_ftp.ko#, [.filename]#alias_bbt.ko#, [.filename]#skinny.ko#, [.filename]#irc.ko#, [.filename]#alias_pptp.ko# and [.filename]#alias_smedia.ko# using the `kld_list` directive in [.filename]#/etc/rc.conf#. If a custom kernel is used, the full functionality of the userland library can be compiled in, in the kernel, using the `options LIBALIAS`. ==== ==== Port Redirection The drawback with NAT in general is that the LAN clients are not accessible from the Internet. Clients on the LAN can make outgoing connections to the world but cannot receive incoming ones. This presents a problem if trying to run Internet services on one of the LAN client machines. A simple way around this is to redirect selected Internet ports on the NAT providing machine to a LAN client. For example, an IRC server runs on client `A` and a web server runs on client `B`. For this to work properly, connections received on ports 6667 (IRC) and 80 (HTTP) must be redirected to the respective machines. With in-kernel NAT all configuration is done in the NAT instance configuration. For a full list of options that an in-kernel NAT instance can use, consult man:ipfw[8]. The IPFW syntax follows the syntax of natd. The syntax for `redirect_port` is as follows: [.programlisting] .... redirect_port proto targetIP:targetPORT[-targetPORT] [aliasIP:]aliasPORT[-aliasPORT] [remoteIP[:remotePORT[-remotePORT]]] .... To configure the above example setup, the arguments should be: [.programlisting] .... redirect_port tcp 192.168.0.2:6667 6667 redirect_port tcp 192.168.0.3:80 80 .... After adding these arguments to the configuration of NAT instance 1 in the above ruleset, the TCP ports will be port forwarded to the LAN client machines running the IRC and HTTP services. [.programlisting] .... ipfw -q nat 1 config if $pif same_ports unreg_only reset \ redirect_port tcp 192.168.0.2:6667 6667 \ redirect_port tcp 192.168.0.3:80 80 .... Port ranges over individual ports can be indicated with `redirect_port`. For example, _tcp 192.168.0.2:2000-3000 2000-3000_ would redirect all connections received on ports 2000 to 3000 to ports 2000 to 3000 on client `A`. ==== Address Redirection Address redirection is useful if more than one IP address is available. Each LAN client can be assigned its own external IP address by man:ipfw[8], which will then rewrite outgoing packets from the LAN clients with the proper external IP address and redirects all traffic incoming on that particular IP address back to the specific LAN client. This is also known as static NAT. For example, if IP addresses `128.1.1.1`, `128.1.1.2`, and `128.1.1.3` are available, `128.1.1.1` can be used as the man:ipfw[8] machine's external IP address, while `128.1.1.2` and `128.1.1.3` are forwarded back to LAN clients `A` and `B`. The `redirect_addr` syntax is as below, where `localIP` is the internal IP address of the LAN client, and `publicIP` the external IP address corresponding to the LAN client. [.programlisting] .... redirect_addr localIP publicIP .... In the example, the arguments would read: [.programlisting] .... redirect_addr 192.168.0.2 128.1.1.2 redirect_addr 192.168.0.3 128.1.1.3 .... Like `redirect_port`, these arguments are placed in a NAT instance configuration. With address redirection, there is no need for port redirection, as all data received on a particular IP address is redirected. The external IP addresses on the man:ipfw[8] machine must be active and aliased to the external interface. Refer to man:rc.conf[5] for details. ==== Userspace NAT Let us start with a statement: the userspace NAT implementation: man:natd[8], has more overhead than in-kernel NAT. For man:natd[8] to translate packets, the packets have to be copied from the kernel to userspace and back which brings in extra overhead that is not present with in-kernel NAT. To enable the userspace NAT daemon man:natd[8] at boot time, the following is a minimum configuration in [.filename]#/etc/rc.conf#. Where `natd_interface` is set to the name of the NIC attached to the Internet. The man:rc[8] script of man:natd[8] will automatically check if a dynamic IP address is used and configure itself to handle that. [.programlisting] .... gateway_enable="YES" natd_enable="YES" natd_interface="rl0" .... In general, the above ruleset as explained for in-kernel NAT can also be used together with man:natd[8]. The exceptions are the configuration of the in-kernel NAT instance `(ipfw -q nat 1 config ...)` which is not needed together with reassemble rule 99 because its functionality is included in the `divert` action. Rule number 100 and 1000 will have to change slightly as shown below. [.programlisting] .... $cmd 100 divert natd ip from any to any in via $pif $cmd 1000 divert natd ip from any to any out via $pif .... To configure port or address redirection, a similar syntax as with in-kernel NAT is used. Although, now, instead of specifying the configuration in our ruleset script like with in-kernel NAT, configuration of man:natd[8] is best done in a configuration file. To do this, an extra flag must be passed via [.filename]#/etc/rc.conf# which specifies the path of the configuration file. [.programlisting] .... natd_flags="-f /etc/natd.conf" .... [NOTE] ==== The specified file must contain a list of configuration options, one per line. For more information about the configuration file and possible variables, consult man:natd[8]. Below are two example entries, one per line: [.programlisting] .... redirect_port tcp 192.168.0.2:6667 6667 redirect_addr 192.168.0.3 128.1.1.3 .... ==== [[firewalls-ipfw-cmd]] === The IPFW Command `ipfw` can be used to make manual, single rule additions or deletions to the active firewall while it is running. The problem with using this method is that all the changes are lost when the system reboots. It is recommended to instead write all the rules in a file and to use that file to load the rules at boot time and to replace the currently running firewall rules whenever that file changes. `ipfw` is a useful way to display the running firewall rules to the console screen. The IPFW accounting facility dynamically creates a counter for each rule that counts each packet that matches the rule. During the process of testing a rule, listing the rule with its counter is one way to determine if the rule is functioning as expected. To list all the running rules in sequence: [source,shell] .... # ipfw list .... To list all the running rules with a time stamp of when the last time the rule was matched: [source,shell] .... # ipfw -t list .... The next example lists accounting information and the packet count for matched rules along with the rules themselves. The first column is the rule number, followed by the number of matched packets and bytes, followed by the rule itself. [source,shell] .... # ipfw -a list .... To list dynamic rules in addition to static rules: [source,shell] .... # ipfw -d list .... To also show the expired dynamic rules: [source,shell] .... # ipfw -d -e list .... To zero the counters: [source,shell] .... # ipfw zero .... To zero the counters for just the rule with number _NUM_: [source,shell] .... # ipfw zero NUM .... ==== Logging Firewall Messages Even with the logging facility enabled, IPFW will not generate any rule logging on its own. The firewall administrator decides which rules in the ruleset will be logged, and adds the `log` keyword to those rules. Normally only deny rules are logged. It is customary to duplicate the "ipfw default deny everything" rule with the `log` keyword included as the last rule in the ruleset. This way, it is possible to see all the packets that did not match any of the rules in the ruleset. Logging is a two edged sword. If one is not careful, an over abundance of log data or a DoS attack can fill the disk with log files. Log messages are not only written to syslogd, but also are displayed on the root console screen and soon become annoying. The `IPFIREWALL_VERBOSE_LIMIT=5` kernel option limits the number of consecutive messages sent to man:syslogd[8], concerning the packet matching of a given rule. When this option is enabled in the kernel, the number of consecutive messages concerning a particular rule is capped at the number specified. There is nothing to be gained from 200 identical log messages. With this option set to five, five consecutive messages concerning a particular rule would be logged to syslogd and the remainder identical consecutive messages would be counted and posted to syslogd with a phrase like the following: [.programlisting] .... last message repeated 45 times .... All logged packets messages are written by default to [.filename]#/var/log/security#, which is defined in [.filename]#/etc/syslog.conf#. [[firewalls-ipfw-rules-script]] ==== Building a Rule Script Most experienced IPFW users create a file containing the rules and code them in a manner compatible with running them as a script. The major benefit of doing this is the firewall rules can be refreshed in mass without the need of rebooting the system to activate them. This method is convenient in testing new rules as the procedure can be executed as many times as needed. Being a script, symbolic substitution can be used for frequently used values to be substituted into multiple rules. This example script is compatible with the syntax used by the man:sh[1], man:csh[1], and man:tcsh[1] shells. Symbolic substitution fields are prefixed with a dollar sign ($). Symbolic fields do not have the $ prefix. The value to populate the symbolic field must be enclosed in double quotes (""). Start the rules file like this: [.programlisting] .... ############### start of example ipfw rules script ############# # ipfw -q -f flush # Delete all rules # Set defaults oif="tun0" # out interface odns="192.0.2.11" # ISP's DNS server IP address cmd="ipfw -q add " # build rule prefix ks="keep-state" # just too lazy to key this each time $cmd 00500 check-state $cmd 00502 deny all from any to any frag $cmd 00501 deny tcp from any to any established $cmd 00600 allow tcp from any to any 80 out via $oif setup $ks $cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks $cmd 00611 allow udp from any to $odns 53 out via $oif $ks ################### End of example ipfw rules script ############ .... The rules are not important as the focus of this example is how the symbolic substitution fields are populated. If the above example was in [.filename]#/etc/ipfw.rules#, the rules could be reloaded by the following command: [source,shell] .... # sh /etc/ipfw.rules .... [.filename]#/etc/ipfw.rules# can be located anywhere and the file can have any name. The same thing could be accomplished by running these commands by hand: [source,shell] .... # ipfw -q -f flush # ipfw -q add check-state # ipfw -q add deny all from any to any frag # ipfw -q add deny tcp from any to any established # ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state # ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state # ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state .... [[firewalls-ipfw-kernelconfig]] === IPFW Kernel Options In order to statically compile IPFW support into a custom kernel, refer to the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]. The following options are available for the custom kernel configuration file: [.programlisting] .... options IPFIREWALL # enables IPFW options IPFIREWALL_VERBOSE # enables logging for rules with log keyword to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=5 # limits number of logged packets per-entry options IPFIREWALL_DEFAULT_TO_ACCEPT # sets default policy to pass what is not explicitly denied options IPFIREWALL_NAT # enables basic in-kernel NAT support options LIBALIAS # enables full in-kernel NAT support options IPFIREWALL_NAT64 # enables in-kernel NAT64 support options IPFIREWALL_NPTV6 # enables in-kernel IPv6 NPT support options IPFIREWALL_PMOD # enables protocols modification module support options IPDIVERT # enables NAT through natd(8) .... [NOTE] ==== IPFW can be loaded as a kernel module: options above are built by default as modules or can be set at runtime using tunables. ==== [[firewalls-ipf]] == IPFILTER (IPF) IPFILTER, also known as IPF, is a cross-platform, open source firewall which has been ported to several operating systems, including FreeBSD, NetBSD, OpenBSD, and Solaris(TM). IPFILTER is a kernel-side firewall and NAT mechanism that can be controlled and monitored by userland programs. Firewall rules can be set or deleted using ipf, NAT rules can be set or deleted using ipnat, run-time statistics for the kernel parts of IPFILTER can be printed using ipfstat, and ipmon can be used to log IPFILTER actions to the system log files. IPF was originally written using a rule processing logic of "the last matching rule wins" and only used stateless rules. Since then, IPF has been enhanced to include the `quick` and `keep state` options. -The IPF FAQ is at http://www.phildev.net/ipf/index.html[http://www.phildev.net/ipf/index.html]. -A searchable archive of the IPFilter mailing list is available at http://marc.info/?l=ipfilter[http://marc.info/?l=ipfilter]. +The IPF FAQ is at https://www.phildev.net/ipf/index.html[https://www.phildev.net/ipf/index.html]. +A searchable archive of the IPFilter mailing list is available at https://marc.info/?l=ipfilter[https://marc.info/?l=ipfilter]. This section of the Handbook focuses on IPF as it pertains to FreeBSD. It provides examples of rules that contain the `quick` and `keep state` options. === Enabling IPF IPF is included in the basic FreeBSD install as a kernel loadable module, meaning that a custom kernel is not needed in order to enable IPF. For users who prefer to statically compile IPF support into a custom kernel, refer to the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]. The following kernel options are available: [.programlisting] .... options IPFILTER options IPFILTER_LOG options IPFILTER_LOOKUP options IPFILTER_DEFAULT_BLOCK .... where `options IPFILTER` enables support for IPFILTER, `options IPFILTER_LOG` enables IPF logging using the [.filename]#ipl# packet logging pseudo-device for every rule that has the `log` keyword, `IPFILTER_LOOKUP` enables IP pools in order to speed up IP lookups, and `options IPFILTER_DEFAULT_BLOCK` changes the default behavior so that any packet not matching a firewall `pass` rule gets blocked. To configure the system to enable IPF at boot time, add the following entries to [.filename]#/etc/rc.conf#. These entries will also enable logging and `default pass all`. To change the default policy to `block all` without compiling a custom kernel, remember to add a `block all` rule at the end of the ruleset. [.programlisting] .... ipfilter_enable="YES" # Start ipf firewall ipfilter_rules="/etc/ipf.rules" # loads rules definition text file ipv6_ipfilter_rules="/etc/ipf6.rules" # loads rules definition text file for IPv6 ipmon_enable="YES" # Start IP monitor log ipmon_flags="-Ds" # D = start as daemon # s = log to syslog # v = log tcp window, ack, seq # n = map IP & port to names .... If NAT functionality is needed, also add these lines: [.programlisting] .... gateway_enable="YES" # Enable as LAN gateway ipnat_enable="YES" # Start ipnat function ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat .... Then, to start IPF now: [.programlisting] .... # service ipfilter start .... To load the firewall rules, specify the name of the ruleset file using `ipf`. The following command can be used to replace the currently running firewall rules: [source,shell] .... # ipf -Fa -f /etc/ipf.rules .... where `-Fa` flushes all the internal rules tables and `-f` specifies the file containing the rules to load. This provides the ability to make changes to a custom ruleset and update the running firewall with a fresh copy of the rules without having to reboot the system. This method is convenient for testing new rules as the procedure can be executed as many times as needed. Refer to man:ipf[8] for details on the other flags available with this command. === IPF Rule Syntax This section describes the IPF rule syntax used to create stateful rules. When creating rules, keep in mind that unless the `quick` keyword appears in a rule, every rule is read in order, with the _last matching rule_ being the one that is applied. This means that even if the first rule to match a packet is a `pass`, if there is a later matching rule that is a `block`, the packet will be dropped. Sample rulesets can be found in [.filename]#/usr/share/examples/ipfilter#. When creating rules, a `+#+` character is used to mark the start of a comment and may appear at the end of a rule, to explain that rule's function, or on its own line. Any blank lines are ignored. The keywords which are used in rules must be written in a specific order, from left to right. Some keywords are mandatory while others are optional. Some keywords have sub-options which may be keywords themselves and also include more sub-options. The keyword order is as follows, where the words shown in uppercase represent a variable and the words shown in lowercase must precede the variable that follows it: `_ACTION DIRECTION OPTIONS proto PROTO_TYPE from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT TCP_FLAG|ICMP_TYPE keep state STATE_` This section describes each of these keywords and their options. It is not an exhaustive list of every possible option. Refer to man:ipf[5] for a complete description of the rule syntax that can be used when creating IPF rules and examples for using each keyword. ACTION:: The action keyword indicates what to do with the packet if it matches that rule. Every rule _must_ have an action. The following actions are recognized: + `block`: drops the packet. + `pass`: allows the packet. + `log`: generates a log record. + `count`: counts the number of packets and bytes which can provide an indication of how often a rule is used. + `auth`: queues the packet for further processing by another program. + `call`: provides access to functions built into IPF that allow more complex actions. + `decapsulate`: removes any headers in order to process the contents of the packet. DIRECTION:: Next, each rule must explicitly state the direction of traffic using one of these keywords: + `in`: the rule is applied against an inbound packet. + `out`: the rule is applied against an outbound packet. + `all`: the rule applies to either direction. + If the system has multiple interfaces, the interface can be specified along with the direction. An example would be `in on fxp0`. OPTIONS:: Options are optional. However, if multiple options are specified, they must be used in the order shown here. + `log`: when performing the specified ACTION, the contents of the packet's headers will be written to the man:ipl[4] packet log pseudo-device. + `quick`: if a packet matches this rule, the ACTION specified by the rule occurs and no further processing of any following rules will occur for this packet. + `on`: must be followed by the interface name as displayed by man:ifconfig[8]. The rule will only match if the packet is going through the specified interface in the specified direction. + When using the `log` keyword, the following qualifiers may be used in this order: + `body`: indicates that the first 128 bytes of the packet contents will be logged after the headers. + `first`: if the `log` keyword is being used in conjunction with a `keep state` option, this option is recommended so that only the triggering packet is logged and not every packet which matches the stateful connection. + Additional options are available to specify error return messages. Refer to man:ipf[5] for more details. PROTO_TYPE:: The protocol type is optional. However, it is mandatory if the rule needs to specify a SRC_PORT or a DST_PORT as it defines the type of protocol. When specifying the type of protocol, use the `proto` keyword followed by either a protocol number or name from [.filename]#/etc/protocols#. Example protocol names include `tcp`, `udp`, or `icmp`. If PROTO_TYPE is specified but no SRC_PORT or DST_PORT is specified, all port numbers for that protocol will match that rule. SRC_ADDR:: The `from` keyword is mandatory and is followed by a keyword which represents the source of the packet. The source can be a hostname, an IP address followed by the CIDR mask, an address pool, or the keyword `all`. Refer to man:ipf[5] for examples. + There is no way to match ranges of IP addresses which do not express themselves easily using the dotted numeric form / mask-length notation. The package:net-mgmt/ipcalc[] package or port may be used to ease the calculation of the CIDR mask. -Additional information is available at the utility's web page: http://jodies.de/ipcalc[http://jodies.de/ipcalc]. +Additional information is available at the utility's web page: https://jodies.de/ipcalc[https://jodies.de/ipcalc]. SRC_PORT:: The port number of the source is optional. However, if it is used, it requires PROTO_TYPE to be first defined in the rule. The port number must also be preceded by the `proto` keyword. + A number of different comparison operators are supported: `=` (equal to), `!=` (not equal to), `<` (less than), `>` (greater than), `<=` (less than or equal to), and `>=` (greater than or equal to). + To specify port ranges, place the two port numbers between `<>` (less than and greater than ), `><` (greater than and less than ), or `:` (greater than or equal to and less than or equal to). DST_ADDR:: The `to` keyword is mandatory and is followed by a keyword which represents the destination of the packet. Similar to SRC_ADDR, it can be a hostname, an IP address followed by the CIDR mask, an address pool, or the keyword `all`. DST_PORT:: Similar to SRC_PORT, the port number of the destination is optional. However, if it is used, it requires PROTO_TYPE to be first defined in the rule. The port number must also be preceded by the `proto` keyword. TCP_FLAG|ICMP_TYPE:: If `tcp` is specified as the PROTO_TYPE, flags can be specified as letters, where each letter represents one of the possible TCP flags used to determine the state of a connection. Possible values are: `S` (SYN), `A` (ACK), `P` (PSH), `F` (FIN), `U` (URG), `R` (RST), `C` (CWN), and `E` (ECN). + If `icmp` is specified as the PROTO_TYPE, the ICMP type to match can be specified. Refer to man:ipf[5] for the allowable types. STATE:: If a `pass` rule contains `keep state`, IPF will add an entry to its dynamic state table and allow subsequent packets that match the connection. IPF can track state for TCP, UDP, and ICMP sessions. Any packet that IPF can be certain is part of an active session, even if it is a different protocol, will be allowed. + In IPF, packets destined to go out through the interface connected to the public Internet are first checked against the dynamic state table. If the packet matches the next expected packet comprising an active session conversation, it exits the firewall and the state of the session conversation flow is updated in the dynamic state table. Packets that do not belong to an already active session are checked against the outbound ruleset. Packets coming in from the interface connected to the public Internet are first checked against the dynamic state table. If the packet matches the next expected packet comprising an active session, it exits the firewall and the state of the session conversation flow is updated in the dynamic state table. Packets that do not belong to an already active session are checked against the inbound ruleset. + Several keywords can be added after `keep state`. If used, these keywords set various options that control stateful filtering, such as setting connection limits or connection age. Refer to man:ipf[5] for the list of available options and their descriptions. === Example Ruleset This section demonstrates how to create an example ruleset which only allows services matching `pass` rules and blocks all others. FreeBSD uses the loopback interface ([.filename]#lo0#) and the IP address `127.0.0.1` for internal communication. The firewall ruleset must contain rules to allow free movement of these internally used packets: [.programlisting] .... # no restrictions on loopback interface pass in quick on lo0 all pass out quick on lo0 all .... The public interface connected to the Internet is used to authorize and control access of all outbound and inbound connections. If one or more interfaces are cabled to private networks, those internal interfaces may require rules to allow packets originating from the LAN to flow between the internal networks or to the interface attached to the Internet. The ruleset should be organized into three major sections: any trusted internal interfaces, outbound connections through the public interface, and inbound connections through the public interface. These two rules allow all traffic to pass through a trusted LAN interface named [.filename]#xl0#: [.programlisting] .... # no restrictions on inside LAN interface for private network pass out quick on xl0 all pass in quick on xl0 all .... The rules for the public interface's outbound and inbound sections should have the most frequently matched rules placed before less commonly matched rules, with the last rule in the section blocking and logging all packets for that interface and direction. This set of rules defines the outbound section of the public interface named [.filename]#dc0#. These rules keep state and identify the specific services that internal systems are authorized for public Internet access. All the rules use `quick` and specify the appropriate port numbers and, where applicable, destination addresses. [.programlisting] .... # interface facing Internet (outbound) # Matches session start requests originating from or behind the # firewall, destined for the Internet. # Allow outbound access to public DNS servers. # Replace x.x.x.x with address listed in /etc/resolv.conf. # Repeat for each DNS server. pass out quick on dc0 proto tcp from any to x.x.x.x port = 53 flags S keep state pass out quick on dc0 proto udp from any to x.x.x.x port = 53 keep state # Allow access to ISP's specified DHCP server for cable or DSL networks. # Use the first rule, then check log for the IP address of DHCP server. # Then, uncomment the second rule, replace z.z.z.z with the IP address, # and comment out the first rule pass out log quick on dc0 proto udp from any to any port = 67 keep state #pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state # Allow HTTP and HTTPS pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state # Allow email pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state # Allow NTP pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state # Allow FTP pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state # Allow SSH pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state # Allow ping pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state # Block and log everything else block out log first quick on dc0 all .... This example of the rules in the inbound section of the public interface blocks all undesirable packets first. This reduces the number of packets that are logged by the last rule. [.programlisting] .... # interface facing Internet (inbound) # Block all inbound traffic from non-routable or reserved address spaces block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918 private IP block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918 private IP block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918 private IP block in quick on dc0 from 127.0.0.0/8 to any #loopback block in quick on dc0 from 0.0.0.0/8 to any #loopback block in quick on dc0 from 169.254.0.0/16 to any #DHCP auto-config block in quick on dc0 from 192.0.2.0/24 to any #reserved for docs block in quick on dc0 from 204.152.64.0/23 to any #Sun cluster interconnect block in quick on dc0 from 224.0.0.0/3 to any #Class D & E multicast # Block fragments and too short tcp packets block in quick on dc0 all with frags block in quick on dc0 proto tcp all with short # block source routed packets block in quick on dc0 all with opt lsrr block in quick on dc0 all with opt ssrr # Block OS fingerprint attempts and log first occurrence block in log first quick on dc0 proto tcp from any to any flags FUP # Block anything with special options block in quick on dc0 all with ipopts # Block public pings and ident block in quick on dc0 proto icmp all icmp-type 8 block in quick on dc0 proto tcp from any to any port = 113 # Block incoming Netbios services block in log first quick on dc0 proto tcp/udp from any to any port = 137 block in log first quick on dc0 proto tcp/udp from any to any port = 138 block in log first quick on dc0 proto tcp/udp from any to any port = 139 block in log first quick on dc0 proto tcp/udp from any to any port = 81 .... Any time there are logged messages on a rule with the `log first` option, run `ipfstat -hio` to evaluate how many times the rule has been matched. A large number of matches may indicate that the system is under attack. The rest of the rules in the inbound section define which connections are allowed to be initiated from the Internet. The last rule denies all connections which were not explicitly allowed by previous rules in this section. [.programlisting] .... # Allow traffic in from ISP's DHCP server. Replace z.z.z.z with # the same IP address used in the outbound section. pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state # Allow public connections to specified internal web server pass in quick on dc0 proto tcp from any to x.x.x.x port = 80 flags S keep state # Block and log only first occurrence of all remaining traffic. block in log first quick on dc0 all .... === Configuring NAT To enable NAT, add these statements to [.filename]#/etc/rc.conf# and specify the name of the file containing the NAT rules: [.programlisting] .... gateway_enable="YES" ipnat_enable="YES" ipnat_rules="/etc/ipnat.rules" .... NAT rules are flexible and can accomplish many different things to fit the needs of both commercial and home users. The rule syntax presented here has been simplified to demonstrate common usage. For a complete rule syntax description, refer to man:ipnat[5]. The basic syntax for a NAT rule is as follows, where `map` starts the rule and _IF_ should be replaced with the name of the external interface: [.programlisting] .... map IF LAN_IP_RANGE -> PUBLIC_ADDRESS .... The _LAN_IP_RANGE_ is the range of IP addresses used by internal clients. Usually, it is a private address range such as `192.168.1.0/24`. The _PUBLIC_ADDRESS_ can either be the static external IP address or the keyword `0/32` which represents the IP address assigned to _IF_. In IPF, when a packet arrives at the firewall from the LAN with a public destination, it first passes through the outbound rules of the firewall ruleset. Then, the packet is passed to the NAT ruleset which is read from the top down, where the first matching rule wins. IPF tests each NAT rule against the packet's interface name and source IP address. When a packet's interface name matches a NAT rule, the packet's source IP address in the private LAN is checked to see if it falls within the IP address range specified in _LAN_IP_RANGE_. On a match, the packet has its source IP address rewritten with the public IP address specified by _PUBLIC_ADDRESS_. IPF posts an entry in its internal NAT table so that when the packet returns from the Internet, it can be mapped back to its original private IP address before being passed to the firewall rules for further processing. For networks that have large numbers of internal systems or multiple subnets, the process of funneling every private IP address into a single public IP address becomes a resource problem. Two methods are available to relieve this issue. The first method is to assign a range of ports to use as source ports. By adding the `portmap` keyword, NAT can be directed to only use source ports in the specified range: [.programlisting] .... map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000 .... Alternately, use the `auto` keyword which tells NAT to determine the ports that are available for use: [.programlisting] .... map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto .... The second method is to use a pool of public addresses. This is useful when there are too many LAN addresses to fit into a single public address and a block of public IP addresses is available. These public addresses can be used as a pool from which NAT selects an IP address as a packet's address is mapped on its way out. The range of public IP addresses can be specified using a netmask or CIDR notation. These two rules are equivalent: [.programlisting] .... map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0 map dc0 192.168.1.0/24 -> 204.134.75.0/24 .... A common practice is to have a publicly accessible web server or mail server segregated to an internal network segment. The traffic from these servers still has to undergo NAT, but port redirection is needed to direct inbound traffic to the correct server. For example, to map a web server using the internal address `10.0.10.25` to its public IP address of `20.20.20.5`, use this rule: [.programlisting] .... rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 .... If it is the only web server, this rule would also work as it redirects all external HTTP requests to `10.0.10.25`: [.programlisting] .... rdr dc0 0.0.0.0/0 port 80 -> 10.0.10.25 port 80 .... IPF has a built in FTP proxy which can be used with NAT. It monitors all outbound traffic for active or passive FTP connection requests and dynamically creates temporary filter rules containing the port number used by the FTP data channel. This eliminates the need to open large ranges of high order ports for FTP connections. In this example, the first rule calls the proxy for outbound FTP traffic from the internal LAN. The second rule passes the FTP traffic from the firewall to the Internet, and the third rule handles all non-FTP traffic from the internal LAN: [.programlisting] .... map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp map dc0 10.0.10.0/29 -> 0/32 .... The FTP `map` rules go before the NAT rule so that when a packet matches an FTP rule, the FTP proxy creates temporary filter rules to let the FTP session packets pass and undergo NAT. All LAN packets that are not FTP will not match the FTP rules but will undergo NAT if they match the third rule. Without the FTP proxy, the following firewall rules would instead be needed. Note that without the proxy, all ports above `1024` need to be allowed: [.programlisting] .... # Allow out LAN PC client FTP to public Internet # Active and passive modes pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state # Allow out passive mode data channel high order port numbers pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep state # Active mode let data channel in from FTP server pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state .... Whenever the file containing the NAT rules is edited, run `ipnat` with `-CF` to delete the current NAT rules and flush the contents of the dynamic translation table. Include `-f` and specify the name of the NAT ruleset to load: [source,shell] .... # ipnat -CF -f /etc/ipnat.rules .... To display the NAT statistics: [source,shell] .... # ipnat -s .... To list the NAT table's current mappings: [source,shell] .... # ipnat -l .... To turn verbose mode on and display information relating to rule processing and active rules and table entries: [source,shell] .... # ipnat -v .... === Viewing IPF Statistics IPF includes man:ipfstat[8] which can be used to retrieve and display statistics which are gathered as packets match rules as they go through the firewall. Statistics are accumulated since the firewall was last started or since the last time they were reset to zero using `ipf -Z`. The default `ipfstat` output looks like this: [source,shell] .... input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0 output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0 input packets logged: blocked 99286 passed 0 output packets logged: blocked 0 passed 0 packets logged: input 0 output 0 log failures: input 3898 output 0 fragment state(in): kept 0 lost 0 fragment state(out): kept 0 lost 0 packet state(in): kept 169364 lost 0 packet state(out): kept 431395 lost 0 ICMP replies: 0 TCP RSTs sent: 0 Result cache hits(in): 1215208 (out): 1098963 IN Pullups succeeded: 2 failed: 0 OUT Pullups succeeded: 0 failed: 0 Fastroute successes: 0 failures: 0 TCP cksum fails(in): 0 (out): 0 Packet log flags set: (0) .... Several options are available. When supplied with either `-i` for inbound or `-o` for outbound, the command will retrieve and display the appropriate list of filter rules currently installed and in use by the kernel. To also see the rule numbers, include `-n`. For example, `ipfstat -on` displays the outbound rules table with rule numbers: [source,shell] .... @1 pass out on xl0 from any to any @2 block out on dc0 from any to any @3 pass out quick on dc0 proto tcp/udp from any to any keep state .... Include `-h` to prefix each rule with a count of how many times the rule was matched. For example, `ipfstat -oh` displays the outbound internal rules table, prefixing each rule with its usage count: [source,shell] .... 2451423 pass out on xl0 from any to any 354727 block out on dc0 from any to any 430918 pass out quick on dc0 proto tcp/udp from any to any keep state .... To display the state table in a format similar to man:top[1], use `ipfstat -t`. When the firewall is under attack, this option provides the ability to identify and see the attacking packets. The optional sub-flags give the ability to select the destination or source IP, port, or protocol to be monitored in real time. Refer to man:ipfstat[8] for details. === IPF Logging IPF provides `ipmon`, which can be used to write the firewall's logging information in a human readable format. It requires that `options IPFILTER_LOG` be first added to a custom kernel using the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]. This command is typically run in daemon mode in order to provide a continuous system log file so that logging of past events may be reviewed. Since FreeBSD has a built in man:syslogd[8] facility to automatically rotate system logs, the default [.filename]#rc.conf# `ipmon_flags` statement uses `-Ds`: [.programlisting] .... ipmon_flags="-Ds" # D = start as daemon # s = log to syslog # v = log tcp window, ack, seq # n = map IP & port to names .... Logging provides the ability to review, after the fact, information such as which packets were dropped, what addresses they came from, and where they were going. This information is useful in tracking down attackers. Once the logging facility is enabled in [.filename]#rc.conf# and started with `service ipmon start`, IPF will only log the rules which contain the `log` keyword. The firewall administrator decides which rules in the ruleset should be logged and normally only deny rules are logged. It is customary to include the `log` keyword in the last rule in the ruleset. This makes it possible to see all the packets that did not match any of the rules in the ruleset. By default, `ipmon -Ds` mode uses `local0` as the logging facility. The following logging levels can be used to further segregate the logged data: [source,shell] .... LOG_INFO - packets logged using the "log" keyword as the action rather than pass or block. LOG_NOTICE - packets logged which are also passed LOG_WARNING - packets logged which are also blocked LOG_ERR - packets which have been logged and which can be considered short due to an incomplete header .... In order to setup IPF to log all data to [.filename]#/var/log/ipfilter.log#, first create the empty file: [source,shell] .... # touch /var/log/ipfilter.log .... Then, to write all logged messages to the specified file, add the following statement to [.filename]#/etc/syslog.conf#: [.programlisting] .... local0.* /var/log/ipfilter.log .... To activate the changes and instruct man:syslogd[8] to read the modified [.filename]#/etc/syslog.conf#, run `service syslogd reload`. Do not forget to edit [.filename]#/etc/newsyslog.conf# to rotate the new log file. Messages generated by `ipmon` consist of data fields separated by white space. Fields common to all messages are: . The date of packet receipt. . The time of packet receipt. This is in the form HH:MM:SS.F, for hours, minutes, seconds, and fractions of a second. . The name of the interface that processed the packet. . The group and rule number of the rule in the format `@0:17`. . The action: `p` for passed, `b` for blocked, `S` for a short packet, `n` did not match any rules, and `L` for a log rule. . The addresses written as three fields: the source address and port separated by a comma, the -> symbol, and the destination address and port. For example: `209.53.17.22,80 -> 198.73.220.17,1722`. . `PR` followed by the protocol name or number: for example, `PR tcp`. . `len` followed by the header length and total length of the packet: for example, `len 20 40`. If the packet is a TCP packet, there will be an additional field starting with a hyphen followed by letters corresponding to any flags that were set. Refer to man:ipf[5] for a list of letters and their flags. If the packet is an ICMP packet, there will be two fields at the end: the first always being "icmp" and the next being the ICMP message and sub-message type, separated by a slash. For example: `icmp 3/3` for a port unreachable message. [[firewalls-blocklistd]] == Blocklistd Blocklistd is a daemon listening to sockets awaiting to receive notifications from other daemons about connection attempts that failed or were successful. It is most widely used in blocking too many connection attempts on open ports. A prime example is SSH running on the internet getting a lot of requests from bots or scripts trying to guess passwords and gain access. Using blocklistd, the daemon can notify the firewall to create a filter rule to block excessive connection attempts from a single source after a number of tries. Blocklistd was first developed on NetBSD and appeared there in version 7, it was originally called blacklistd. FreeBSD 11 imported blocklistd from NetBSD. This chapter describes how to set up blocklistd, configure it, and provides examples on how to use it. Readers should be familiar with basic firewall concepts like rules. For details, refer to the firewall chapter. PF is used in the examples, but other firewalls available on FreeBSD should be able to work with blocklistd, too. === Enabling Blocklistd The main configuration for blocklistd is stored in man:blocklistd.conf[5]. Various command line options are also available to change blocklistd's run-time behavior. Persistent configuration across reboots should be stored in [.filename]#/etc/blocklistd.conf#. To enable the daemon during system boot, add a `blocklistd_enable` line to [.filename]#/etc/rc.conf# like this: [source,shell] .... # sysrc blocklistd_enable=yes .... To start the service manually, run this command: [source,shell] .... # service blocklistd start .... === Creating a Blocklistd Ruleset Rules for blocklistd are configured in man:blocklistd.conf[5] with one entry per line. Each rule contains a tuple separated by spaces or tabs. Rules either belong to a `local` or a `remote`, which applies to the machine where blocklistd is running or an outside source, respectively. ==== Local Rules An example blocklistd.conf entry for a local rule looks like this: [.programlisting] .... [local] ssh stream * * * 3 24h .... All rules that follow the `[local]` section are treated as local rules (which is the default), applying to the local machine. When a `[remote]` section is encountered, all rules that follow it are handled as remote machine rules. Seven fields separated by either tabs or spaces define a rule. The first four fields identify the traffic that should be blocklisted. The three fields that follow define blocklistd's behavior. Wildcards are denoted as asterisks (`*`), matching anything in this field. The first field defines the location. In local rules, these are the network ports. The syntax for the location field is as follows: [.programlisting] .... [address|interface][/mask][:port] .... Addresses can be specified as IPv4 in numeric format or IPv6 in square brackets. An interface name like `_em0_` can also be used. The socket type is defined by the second field. TCP sockets are of type `stream`, whereas UDP is denoted as `dgram`. The example above uses TCP, since SSH is using that protocol. A protocol can be used in the third field of a blocklistd rule. The following protocols can be used: `tcp`, `udp`, `tcp6`, `udp6`, or numeric. A wildcard, like in the example, is typically used to match all protocols unless there is a reason to distinguish traffic by a certain protocol. In the fourth field, the effective user or owner of the daemon process that is reporting the event is defined. The username or UID can be used here, as well as a wildcard (see example rule above). The packet filter rule name is declared by the fifth field, which starts the behavior part of the rule. By default, blocklistd puts all blocks under a pf anchor called `blocklistd` in [.filename]#pf.conf# like this: [.programlisting] .... anchor "blocklistd/*" in on $ext_if block in pass out .... For separate blocklists, an anchor name can be used in this field. In other cases, the wildcard will suffice. When a name starts with a hyphen (`-`) it means that an anchor with the default rule name prepended should be used. A modified example from the above using the hyphen would look like this: [.programlisting] .... ssh stream * * -ssh 3 24h .... With such a rule, any new blocklist rules are added to an anchor called `blocklistd-ssh`. To block whole subnets for a single rule violation, a `/` in the rule name can be used. This causes the remaining portion of the name to be interpreted as the mask to be applied to the address specified in the rule. For example, this rule would block every address adjoining `/24`. [.programlisting] .... 22 stream tcp * */24 3 24h .... [NOTE] ==== It is important to specify the proper protocol here. IPv4 and IPv6 treat /24 differently, that is the reason why `*` cannot be used in the third field for this rule. ==== This rule defines that if any one host in that network is misbehaving, everything else on that network will be blocked, too. The sixth field, called `nfail`, sets the number of login failures required to blocklist the remote IP in question. When a wildcard is used at this position, it means that blocks will never happen. In the example rule above, a limit of three is defined meaning that after three attempts to log into SSH on one connection, the IP is blocked. The last field in a blocklistd rule definition specifies how long a host is blocklisted. The default unit is seconds, but suffixes like `m`, `h`, and `d` can also be specified for minutes, hours, and days, respectively. The example rule in its entirety means that after three times authenticating to SSH will result in a new PF block rule for that host. Rule matches are performed by first checking local rules one after another, from most specific to least specific. When a match occurs, the `remote` rules are applied and the `name`, `nfail`, and `duration` fields are changed by the `remote` rule that matched. ==== Remote Rules Remote rules are used to specify how blocklistd changes its behavior depending on the remote host currently being evaluated. Each field in a remote rule is the same as in a local rule. The only difference is in the way blocklistd is using them. To explain it, this example rule is used: [.programlisting] .... [remote] 203.0.113.128/25 * * * =/25 = 48h .... The address field can be an IP address (either v4 or v6), a port or both. This allows setting special rules for a specific remote address range like in this example. The fields for socket type, protocol and owner are identically interpreted as in the local rule. The name fields is different though: the equal sign (`=`) in a remote rule tells blocklistd to use the value from the matching local rule. It means that the firewall rule entry is taken and the `/25` prefix (a netmask of `255.255.255.128`) is added. When a connection from that address range is blocklisted, the entire subnet is affected. A PF anchor name can also be used here, in which case blocklistd will add rules for this address block to the anchor of that name. The default table is used when a wildcard is specified. A custom number of failures in the `nfail` column can be defined for an address. This is useful for exceptions to a specific rule, to maybe allow someone a less strict application of rules or a bit more leniency in login tries. Blocking is disabled when an asterisk is used in this sixth field. Remote rules allow a stricter enforcement of limits on attempts to log in compared to attempts coming from a local network like an office. === Blocklistd Client Configuration There are a few software packages in FreeBSD that can utilize blocklistd's functionality. The two most prominent ones are package:ftp/freebsd-ftpd[] and man:sshd[8] to block excessive connection attempts. To activate blocklistd in the SSH daemon, add the following line to [.filename]#/etc/ssh/sshd_config#: [.programlisting] .... UseBlocklist yes .... Restart sshd afterwards to make these changes take effect. Blocklisting for package:ftp/freebsd-ftpd[] is enabled using `-B`, either in [.filename]#/etc/inetd.conf# or as a flag in [.filename]#/etc/rc.conf# like this: [.programlisting] .... ftpd_flags="-B" .... That is all that is needed to make these programs talk to blocklistd. === Blocklistd Management Blocklistd provides the user with a management utility called man:blocklistctl[8]. It displays blocked addresses and networks that are blocklisted by the rules defined in man:blocklistd.conf[5]. To see the list of currently blocked hosts, use `dump` combined with `-b` like this. [source,shell] .... # blocklistctl dump -b rulename address/ma:port id nfail last access blocklistd 213.0.123.128/25:22 OK 6/3 2019/06/08 14:30:19 .... This example shows that there were 6 out of three permitted attempts on port 22 coming from the address range `213.0.123.128/25`. There are more attempts listed than are allowed because SSH allows a client to try multiple logins on a single TCP connection. A connection that is currently going on is not stopped by blocklistd. The last connection attempt is listed in the `last access` column of the output. To see the remaining time that this host will be on the blocklist, add `-r` to the previous command. [source,shell] .... # blocklistctl dump -br rulename address/ma:port id nfail remaining time blocklistd 213.0.123.128/25:22 OK 6/3 36s .... In this example, there are 36s seconds left until this host will not be blocked any more. === Removing Hosts from the Block List Sometimes it is necessary to remove a host from the block list before the remaining time expires. Unfortunately, there is no functionality in blocklistd to do that. However, it is possible to remove the address from the PF table using pfctl. For each blocked port, there is a child anchor inside the blocklistd anchor defined in [.filename]#/etc/pf.conf#. For example, if there is a child anchor for blocking port 22 it is called `blocklistd/22`. There is a table inside that child anchor that contains the blocked addresses. This table is called port followed by the port number. In this example, it would be called `port22`. With that information at hand, it is now possible to use man:pfctl[8] to display all addresses listed like this: [source,shell] .... # pfctl -a blocklistd/22 -t port22 -T show ... 213.0.123.128/25 ... .... After identifying the address to be unblocked from the list, the following command removes it from the list: [source,shell] .... # pfctl -a blocklistd/22 -t port22 -T delete 213.0.123.128/25 .... The address is now removed from PF, but will still show up in the blocklistctl list, since it does not know about any changes made in PF. The entry in blocklistd's database will eventually expire and be removed from its output. The entry will be added again if the host is matching one of the block rules in blocklistd again. diff --git a/documentation/content/en/books/handbook/glossary.adoc b/documentation/content/en/books/handbook/glossary.adoc index e30db9d7f8..a283f82f6d 100644 --- a/documentation/content/en/books/handbook/glossary.adoc +++ b/documentation/content/en/books/handbook/glossary.adoc @@ -1,1097 +1,1097 @@ --- title: FreeBSD Glossary prev: books/handbook/pgpkeys next: books/handbook/colophon description: FreeBSD Handbook Glossary showBookMenu: true weight: 45 params: path: "/books/handbook/glossary/" --- [glossary] [[freebsd-glossary]] = FreeBSD Glossary :doctype: book :toc: macro :toclevels: 1 :icons: font :!sectnums: :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/glossary/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] This glossary contains terms and acronyms used within the FreeBSD community and documentation. [discrete] == A ACL:: See crossref:glossary[acl-glossary,Access Control List]. ACPI:: See crossref:glossary[acpi-glossary,Advanced Configuration and Power Interface]. AMD:: See crossref:glossary[amd-glossary,Automatic Mount Daemon]. AML:: See crossref:glossary[aml-glossary,ACPI Machine Language]. API:: See crossref:glossary[api-glossary,Application Programming Interface]. APIC:: See crossref:glossary[apic-glossary,Advanced Programmable Interrupt Controller]. APM:: See crossref:glossary[apm-glossary,Advanced Power Management]. APOP:: See crossref:glossary[apop-glossary,Authenticated Post Office Protocol]. ASL:: See crossref:glossary[asl-glossary,ACPI Source Language]. ATA:: See crossref:glossary[ata-glossary,Advanced Technology Attachment]. ATM:: See crossref:glossary[atm-glossary,Asynchronous Transfer Mode]. [[aml-glossary]] ACPI Machine Language:: Pseudocode, interpreted by a virtual machine within an ACPI-compliant operating system, providing a layer between the underlying hardware and the documented interface presented to the OS. [[asl-glossary]] ACPI Source Language:: The programming language AML is written in. [[acl-glossary]] Access Control List:: A list of permissions attached to an object, usually either a file or a network device. [[acpi-glossary]] Advanced Configuration and Power Interface:: A specification which provides an abstraction of the interface the hardware presents to the operating system, so that the operating system should need to know nothing about the underlying hardware to make the most of it. ACPI evolves and supersedes the functionality provided previously by APM, PNPBIOS and other technologies, and provides facilities for controlling power consumption, machine suspension, device enabling and disabling, etc. [[api-glossary]] Application Programming Interface:: A set of procedures, protocols and tools that specify the canonical interaction of one or more program parts; how, when and why they do work together, and what data they share or operate on. [[apm-glossary]] Advanced Power Management:: An API enabling the operating system to work in conjunction with the BIOS in order to achieve power management. APM has been superseded by the much more generic and powerful ACPI specification for most applications. [[apic-glossary]] Advanced Programmable Interrupt Controller:: {empty} [[ata-glossary]] Advanced Technology Attachment:: {empty} [[atm-glossary]] Asynchronous Transfer Mode:: {empty} [[apop-glossary]] Authenticated Post Office Protocol:: {empty} [[amd-glossary]] Automatic Mount Daemon:: A daemon that automatically mounts a filesystem when a file or directory within that filesystem is accessed. [discrete] == B BAR:: See crossref:glossary[bar-glossary,Base Address Register]. BIND:: See crossref:glossary[bind-glossary,Berkeley Internet Name Domain]. BIOS:: See crossref:glossary[bios-glossary,Basic Input/Output System]. BSD:: See crossref:glossary[bsd-glossary,Berkeley Software Distribution]. [[bar-glossary]] Base Address Register:: The registers that determine which address range a PCI device will respond to. [[bios-glossary]] Basic Input/Output System:: The definition of BIOS depends a bit on the context. Some people refer to it as the ROM chip with a basic set of routines to provide an interface between software and hardware. Others refer to it as the set of routines contained in the chip that help in bootstrapping the system. Some might also refer to it as the screen used to configure the bootstrapping process. The BIOS is PC-specific but other systems have something similar. [[bind-glossary]] Berkeley Internet Name Domain:: An implementation of the DNS protocols. [[bsd-glossary]] Berkeley Software Distribution:: -This is the name that the Computer Systems Research Group (CSRG) at link:http://www.berkeley.edu[The University of California at Berkeley] gave to their improvements and modifications to AT&T's 32V UNIX(R). +This is the name that the Computer Systems Research Group (CSRG) at link:https://www.berkeley.edu[The University of California at Berkeley] gave to their improvements and modifications to AT&T's 32V UNIX(R). FreeBSD is a descendant of the CSRG work. [[bikeshed-glossary]] Bikeshed Building:: A phenomenon whereby many people will give an opinion on an uncomplicated topic, whilst a complex topic receives little or no discussion. See the extref:{faq}[FAQ, bikeshed-painting] for the origin of the term. [discrete] == C CD:: See crossref:glossary[cd-glossary,Carrier Detect]. CHAP:: See crossref:glossary[chap-glossary,Challenge Handshake Authentication Protocol]. CLIP:: See crossref:glossary[clip-glossary,Classical IP over ATM]. COFF:: See crossref:glossary[coff-glossary,Common Object File Format]. CPU:: See crossref:glossary[cpu-glossary,Central Processing Unit]. CTS:: See crossref:glossary[cts-glossary,Clear To Send]. [[cd-glossary]] Carrier Detect:: An RS232C signal indicating that a carrier has been detected. [[cpu-glossary]] Central Processing Unit:: Also known as the processor. This is the brain of the computer where all calculations take place. There are a number of different architectures with different instruction sets. Among the more well-known are the Intel-x86 and derivatives, Arm, and PowerPC. [[chap-glossary]] Challenge Handshake Authentication Protocol:: A method of authenticating a user, based on a secret shared between client and server. [[clip-glossary]] Classical IP over ATM:: {empty} [[cts-glossary]] Clear To Send:: An RS232C signal giving the remote system permission to send data. + See crossref:glossary[rts-glossary,Also Request To Send]. [[coff-glossary]] Common Object File Format:: {empty} [discrete] == D DAC:: See crossref:glossary[dac-glossary,Discretionary Access Control]. DDB:: See crossref:glossary[ddb-glossary,Debugger]. DES:: See crossref:glossary[des-glossary,Data Encryption Standard]. DHCP:: See crossref:glossary[dhcp-glossary,Dynamic Host Configuration Protocol]. DNS:: See crossref:glossary[dns-glossary,Domain Name System]. DRM:: See crossref:glossary[drm-glossary,Direct Rendering Manager]. DSDT:: See crossref:glossary[dsdt-glossary,Differentiated System Description Table]. DSR:: See crossref:glossary[dsr-glossary,Data Set Ready]. DTR:: See crossref:glossary[dtr-glossary,Data Terminal Ready]. DVMRP:: See crossref:glossary[dvmrp-glossary,Distance-Vector Multicast Routing Protocol]. [[dac-glossary]] Discretionary Access Control:: {empty} [[des-glossary]] Data Encryption Standard:: A method of encrypting information, traditionally used as the method of encryption for UNIX(R) passwords and the man:crypt[3] function. [[dsr-glossary]] Data Set Ready:: An RS232C signal sent from the modem to the computer or terminal indicating a readiness to send and receive data. + See crossref:glossary[dtr-glossary,Also Data Terminal Ready]. [[dtr-glossary]] Data Terminal Ready:: An RS232C signal sent from the computer or terminal to the modem indicating a readiness to send and receive data. [[ddb-glossary]] Debugger:: An interactive in-kernel facility for examining the status of a system, often used after a system has crashed to establish the events surrounding the failure. [[dsdt-glossary]] Differentiated System Description Table:: An ACPI table, supplying basic configuration information about the base system. [[dvmrp-glossary]] Distance-Vector Multicast Routing Protocol:: {empty} [[dns-glossary]] Domain Name System:: The system that converts humanly readable hostnames (i.e., mail.example.net) to Internet addresses and vice versa. [[drm-glossary]] Direct Rendering Manager:: The man:drm[7] kernel module allows client applications direct access to the graphical hardware via the Direct Rendering Infrastructure. [[dhcp-glossary]] Dynamic Host Configuration Protocol:: A protocol that dynamically assigns IP addresses to a computer (host) when it requests one from the server. The address assignment is called a “lease”. [discrete] == E ECOFF:: See crossref:glossary[ecoff-glossary,Extended COFF]. ELF:: See crossref:glossary[elf-glossary,Executable and Linking Format]. ESP:: See crossref:glossary[esp-glossary,Encapsulated Security Payload]. [[esp-glossary]] Encapsulated Security Payload:: {empty} [[elf-glossary]] Executable and Linking Format:: {empty} [[ecoff-glossary]] Extended COFF:: {empty} [discrete] == F FADT:: See crossref:glossary[fadt-glossary,Fixed ACPI Description Table]. FAT:: See crossref:glossary[fat-glossary,File Allocation Table]. FAT16:: See crossref:glossary[fat16-glossary,File Allocation Table (16-bit)]. FTP:: See crossref:glossary[ftp-glossary,File Transfer Protocol]. [[fat-glossary]] File Allocation Table:: {empty} [[fat16-glossary]] File Allocation Table (16-bit):: {empty} [[ftp-glossary]] File Transfer Protocol:: A member of the family of high-level protocols implemented on top of TCP which can be used to transfer files over a TCP/IP network. [[fadt-glossary]] Fixed ACPI Description Table:: {empty} [discrete] == G GUI:: See crossref:glossary[gui-glossary,Graphical User Interface]. [[giant-glossary]] Giant:: The name of a mutual exclusion mechanism (a sleep `mutex`) that protects a large set of kernel resources. Although a simple locking mechanism was adequate in the days where a machine might have only a few dozen processes, one networking card, and certainly only one processor, in current times it is an unacceptable performance bottleneck. FreeBSD developers are actively working to replace it with locks that protect individual resources, which will allow a much greater degree of parallelism for both single-processor and multi-processor machines. [[gui-glossary]] Graphical User Interface:: A system where the user and computer interact with graphics. [discrete] == H HTML:: See crossref:glossary[html-glossary,HyperText Markup Language]. HUP:: See crossref:glossary[hup-glossary,HangUp]. [[hup-glossary]] HangUp:: {empty} [[html-glossary]] HyperText Markup Language:: The markup language used to create web pages. [discrete] == I I/O:: See crossref:glossary[io-glossary,Input/Output]. IASL:: See crossref:glossary[iasl-glossary,Intel’s ASL compiler]. IMAP:: See crossref:glossary[imap-glossary,Internet Message Access Protocol]. IP:: See crossref:glossary[ip-glossary,Internet Protocol]. IPFW:: See crossref:glossary[ipfw-glossary,IP Firewall]. IPP:: See crossref:glossary[ipp-glossary,Internet Printing Protocol]. IPv4:: See crossref:glossary[ipv4-glossary,IP Version 4]. IPv6:: See crossref:glossary[ipv6-glossary,IP Version 6]. ISP:: See crossref:glossary[isp-glossary,Internet Service Provider]. [[ipfw-glossary]] IP Firewall:: {empty} [[ipv4-glossary]] IP Version 4:: The IP protocol version 4, which uses 32 bits for addressing. This version is still the most widely used, but it is slowly being replaced with IPv6. + See crossref:glossary[ipv6-glossary,Also IP Version 6]. [[ipv6-glossary]] IP Version 6:: The new IP protocol. Invented because the address space in IPv4 is running out. Uses 128 bits for addressing. [[io-glossary]] Input/Output:: {empty} [[iasl-glossary]] Intel’s ASL compiler:: Intel’s compiler for converting ASL into AML. [[imap-glossary]] Internet Message Access Protocol:: A protocol for accessing email messages on a mail server, characterised by the messages usually being kept on the server as opposed to being downloaded to the mail reader client. + See Also Post Office Protocol Version 3. [[ipp-glossary]] Internet Printing Protocol:: {empty} [[ip-glossary]] Internet Protocol:: The packet transmitting protocol that is the basic protocol on the Internet. Originally developed at the U.S. Department of Defense and an extremely important part of the TCP/IP stack. Without the Internet Protocol, the Internet would not have become what it is today. For more information, see link:ftp://ftp.rfc-editor.org/in-notes/rfc791.txt[RFC 791]. [[isp-glossary]] Internet Service Provider:: A company that provides access to the Internet. [discrete] == K [[kame-glossary]] KAME:: -Japanese for “turtle”, the term KAME is used in computing circles to refer to the link:http://www.kame.net/[KAME Project], who work on an implementation of IPv6. +Japanese for “turtle”, the term KAME is used in computing circles to refer to the link:https://www.kame.net/[KAME Project], who work on an implementation of IPv6. KDC:: See crossref:glossary[kdc-glossary,Key Distribution Center]. KLD:: See crossref:glossary[kld-glossary,Kernel ld(1)]. KMS:: See crossref:glossary[kms-glossary,Kernel Mode Setting]. KSE:: See crossref:glossary[kse-glossary,Kernel Scheduler Entities]. KVA:: See crossref:glossary[kva-glossary,Kernel Virtual Address]. Kbps:: See crossref:glossary[kbps-glossary,Kilo Bits Per Second]. [[kms-glossary]] Setting the display mode in kernel space. [[kld-glossary]] Kernel man:ld[1]:: A method of dynamically loading functionality into a FreeBSD kernel without rebooting the system. [[kse-glossary]] Kernel Scheduler Entities:: A kernel-supported threading system. See the link:https://people.freebsd.org/~kuriyama/www/kse[KSE Project home page] for further details. [[kva-glossary]] Kernel Virtual Address:: {empty} [[kdc-glossary]] Key Distribution Center:: {empty} [[kbps-glossary]] Kilo Bits Per Second:: Used to measure bandwidth (how much data can pass a given point at a specified amount of time). Alternates to the Kilo prefix include Mega, Giga, Tera, and so forth. [discrete] == L LAN:: See crossref:glossary[lan-glossary,Local Area Network]. LOR:: See crossref:glossary[lor-glossary,Lock Order Reversal]. LPD:: See crossref:glossary[lpd-glossary,Line Printer Daemon]. [[lpd-glossary]] Line Printer Daemon:: {empty} [[lan-glossary]] Local Area Network:: A network used on a local area, e.g. office, home, or so forth. [[lor-glossary]] Lock Order Reversal:: The FreeBSD kernel uses a number of resource locks to arbitrate contention for those resources. A run-time lock diagnostic system found in FreeBSD-CURRENT kernels (but removed for releases), called man:witness[4], detects the potential for deadlocks due to locking errors. (man:witness[4] is actually slightly conservative, so it is possible to get false positives.) A true positive report indicates that “if you were unlucky, a deadlock would have happened here”. + -True positive LORs tend to get fixed quickly, so check https://lists.FreeBSD.org/subscription/freebsd-current and the link:http://sources.zabbadoz.net/freebsd/lor.html[LORs Seen] page before posting to the mailing lists. +True positive LORs tend to get fixed quickly, so check https://lists.FreeBSD.org/subscription/freebsd-current and the link:https://sources.zabbadoz.net/freebsd/lor.html[LORs Seen] page before posting to the mailing lists. [discrete] == M MAC:: See crossref:glossary[mac-glossary,Mandatory Access Control]. MADT:: See crossref:glossary[madt-glossary,Multiple APIC Description Table]. MFC:: See crossref:glossary[mfc-glossary,Merge From Current]. MFH:: See crossref:glossary[mfh-glossary,Merge From Head]. MFS:: See crossref:glossary[mfs-glossary,Merge From Stable]. MFV:: See crossref:glossary[mfv-glossary,Merge From Vendor]. MIT:: See crossref:glossary[mit-glossary,Massachusetts Institute of Technology]. MLS:: See crossref:glossary[mls-glossary,Multi-Level Security]. MOTD:: See crossref:glossary[motd-glossary,Message Of The Day]. MTA:: See crossref:glossary[mta-glossary,Mail Transfer Agent]. MUA:: See crossref:glossary[mua-glossary,Mail User Agent]. [[mta-glossary]] Mail Transfer Agent:: An application used to transfer email. An MTA has traditionally been part of the BSD base system. Today Sendmail is included in the base system, but there are many other MTAs, such as postfix, qmail and Exim. [[mua-glossary]] Mail User Agent:: An application used by users to display and write email. [[mac-glossary]] Mandatory Access Control:: {empty} [[mit-glossary]] Massachusetts Institute of Technology:: {empty} [[mfc-glossary]] Merge From Current:: To merge functionality or a patch from the -CURRENT branch to another, most often -STABLE. [[mfh-glossary]] Merge From Head:: To merge functionality or a patch from a repository HEAD to an earlier branch. [[mfs-glossary]] Merge From Stable:: In the normal course of FreeBSD development, a change will be committed to the -CURRENT branch for testing before being merged to -STABLE. On rare occasions, a change will go into -STABLE first and then be merged to -CURRENT. + This term is also used when a patch is merged from -STABLE to a security branch. + See crossref:glossary[mfc-glossary,Also Merge From Current]. [[mfv-glossary]] Merge From Vendor:: {empty} [[motd-glossary]] Message Of The Day:: A message, usually shown on login, often used to distribute information to users of the system. [[mls-glossary]] Multi-Level Security:: {empty} [[madt-glossary]] Multiple APIC Description Table:: {empty} [discrete] == N NAT:: See crossref:glossary[nat-glossary,Network Address Translation]. NDISulator:: See crossref:glossary[projectevil-glossary,Project Evil]. NFS:: See crossref:glossary[nfs-glossary,Network File System]. NTFS:: See crossref:glossary[ntfs-glossary,New Technology File System]. NTP:: See crossref:glossary[ntp-glossary,Network Time Protocol]. [[nat-glossary]] Network Address Translation:: A technique where IP packets are rewritten on the way through a gateway, enabling many machines behind the gateway to effectively share a single IP address. [[nfs-glossary]] Network File System:: {empty} [[ntfs-glossary]] New Technology File System:: A filesystem developed by Microsoft and available in its “New Technology” operating systems, such as Windows(R) 2000, Windows NT(R) and Windows(R) XP. [[ntp-glossary]] Network Time Protocol:: A means of synchronizing clocks over a network. [discrete] == O OBE:: See crossref:glossary[obe-glossary,Overtaken By Events]. ODMR:: See crossref:glossary[odmr-glossary,On-Demand Mail Relay]. OS:: See crossref:glossary[os-glossary,Operating System]. [[odmr-glossary]] On-Demand Mail Relay:: {empty} [[os-glossary]] Operating System:: A set of programs, libraries and tools that provide access to the hardware resources of a computer. Operating systems range today from simplistic designs that support only one program running at a time, accessing only one device to fully multi-user, multi-tasking and multi-process systems that can serve thousands of users simultaneously, each of them running dozens of different applications. [[obe-glossary]] Overtaken By Events:: Indicates a suggested change (such as a Problem Report or a feature request) which is no longer relevant or applicable due to such things as later changes to FreeBSD, changes in networking standards, the affected hardware having since become obsolete, and so forth. [discrete] == P PAE:: See crossref:glossary[pae-glossary,Physical Address Extensions]. PAM:: See crossref:glossary[pam-glossary,Pluggable Authentication Modules]. PAP:: See crossref:glossary[pap-glossary,Password Authentication Protocol]. PC:: See crossref:glossary[pc-glossary,Personal Computer]. PCNSFD:: See crossref:glossary[pcnfsd-glossary,Personal Computer Network File System Daemon]. PDF:: See crossref:glossary[pdf-glossary,Portable Document Format]. PID:: See crossref:glossary[pid-glossary,Process ID]. POLA:: See crossref:glossary[pola-glossary,Principle Of Least Astonishment]. POP:: See crossref:glossary[pop-glossary,Post Office Protocol]. POP3:: See crossref:glossary[pop3-glossary,Post Office Protocol Version 3]. PPD:: See crossref:glossary[ppd-glossary,PostScript Printer Description]. PPP:: See crossref:glossary[ppp-glossary,Point-to-Point Protocol]. PPPoA:: See crossref:glossary[pppoa-glossary,PPP over ATM]. PPPoE:: See crossref:glossary[pppoe-glossary,PPP over Ethernet]. [[pppoa-glossary]] PPP over ATM:: {empty} [[pppoe-glossary]] PPP over Ethernet:: {empty} PR:: See crossref:glossary[pr-glossary,Problem Report]. PXE:: See crossref:glossary[pxe-glossary,Preboot eXecution Environment]. [[pap-glossary]] Password Authentication Protocol:: {empty} [[pc-glossary]] Personal Computer:: {empty} [[pcnfsd-glossary]] Personal Computer Network File System Daemon:: {empty} [[pae-glossary]] Physical Address Extensions:: A method of enabling access to up to 64 GB of RAM on systems which only physically have a 32-bit wide address space (and would therefore be limited to 4 GB without PAE). [[pam-glossary]] Pluggable Authentication Modules:: {empty} [[ppp-glossary]] Point-to-Point Protocol:: {empty} [[pointyhat]] Pointy Hat:: A mythical piece of headgear, much like a dunce cap, awarded to any FreeBSD committer who breaks the build, makes revision numbers go backwards, or creates any other kind of havoc in the source base. Any committer worth his or her salt will soon accumulate a large collection. The usage is (almost always?) humorous. [[pdf-glossary]] Portable Document Format:: {empty} [[pop-glossary]] Post Office Protocol:: See Also Post Office Protocol Version 3. [[pop3-glossary]] Post Office Protocol Version 3:: A protocol for accessing email messages on a mail server, characterised by the messages usually being downloaded from the server to the client, as opposed to remaining on the server. + See crossref:glossary[imap-glossary,Also Internet Message Access Protocol]. [[ppd-glossary]] PostScript Printer Description:: {empty} [[pxe-glossary]] Preboot eXecution Environment:: {empty} [[pola-glossary]] Principle Of Least Astonishment:: As FreeBSD evolves, changes visible to the user should be kept as unsurprising as possible. For example, arbitrarily rearranging system startup variables in [.filename]#/etc/defaults/rc.conf# violates POLA. Developers consider POLA when contemplating user-visible system changes. [[prime-glossary]] PRIME:: A method of multiple physical graphics coprocessors coexisting by sharing their direct memory access buffers. [[pr-glossary]] Problem Report:: A description of some kind of problem that has been found in either the FreeBSD source or documentation. See extref:{problem-reports}[Writing FreeBSD Problem Reports]. [[pid-glossary]] Process ID:: A number, unique to a particular process on a system, which identifies it and allows actions to be taken against it. [[projectevil-glossary]] Project Evil:: The working title for the NDISulator, written by Bill Paul, who named it referring to how awful it is (from a philosophical standpoint) to need to have something like this in the first place. The NDISulator is a special compatibility module to allow Microsoft Windows(TM) NDIS miniport network drivers to be used with FreeBSD/i386. This is usually the only way to use cards where the driver is closed-source. See [.filename]#src/sys/compat/ndis/subr_ndis.c#. [discrete] == R RA:: See crossref:glossary[ra-glossary,Router Advertisement]. RAID:: See crossref:glossary[raid-glossary,Redundant Array of Inexpensive Disks]. RAM:: See crossref:glossary[ram-glossary,Random Access Memory]. RD:: See crossref:glossary[rd-glossary,Received Data]. RFC:: See crossref:glossary[rfc-glossary,Request For Comments]. RISC:: See crossref:glossary[risc-glossary,Reduced Instruction Set Computer]. RPC:: See crossref:glossary[rpc-glossary,Remote Procedure Call]. RS232C:: See crossref:glossary[rs232c-glossary,Recommended Standard 232C]. RTS:: See crossref:glossary[rts-glossary,Request To Send]. [[ram-glossary]] Random Access Memory:: {empty} [[rcs-glossary]] Revision Control System:: The _Revision Control System (RCS)_ is one of the oldest software suites that implement “revision control” for plain files. It allows the storage, retrieval, archival, logging, identification and merging of multiple revisions for each file. RCS consists of many small tools that work together. It lacks some of the features found in more modern revision control systems, like Git, but it is very simple to install, configure, and start using for a small set of files. + See crossref:glossary[svn-glossary,Also Subversion]. [[rd-glossary]] Received Data:: An RS232C pin or wire that data is received on. + See crossref:glossary[td-glossary,Also Transmitted Data]. [[rs232c-glossary]] Recommended Standard 232C:: A standard for communications between serial devices. [[risc-glossary]] Reduced Instruction Set Computer:: An approach to processor design where the operations the hardware can perform are simplified but made as general purpose as possible. This can lead to lower power consumption, fewer transistors and in some cases, better performance and increased code density. Examples of RISC processors include the Alpha, SPARC(R), ARM(R) and PowerPC(R). [[raid-glossary]] Redundant Array of Inexpensive Disks:: {empty} [[rpc-glossary]] Remote Procedure Call:: {empty} [[rfc-glossary]] Request For Comments:: A set of documents defining Internet standards, protocols, and so forth. See www.rfc-editor.org. + Also used as a general term when someone has a suggested change and wants feedback. [[rts-glossary]] Request To Send:: An RS232C signal requesting that the remote system commences transmission of data. + See crossref:glossary[cts-glossary,Also Clear To Send]. [[ra-glossary]] Router Advertisement:: {empty} [discrete] == S SCI:: See crossref:glossary[sci-glossary,System Control Interrupt]. SCSI:: See crossref:glossary[scsi-glossary,Small Computer System Interface]. SG:: See crossref:glossary[sg-glossary,Signal Ground]. SLAAC:: See crossref:glossary[slaac-glossary,StateLess Address AutoConfiguration]. SMB:: See crossref:glossary[smb-glossary,Server Message Block]. SMP:: See crossref:glossary[smp-glossary,Symmetric MultiProcessor]. SMTP:: See crossref:glossary[smtp-glossary,Simple Mail Transfer Protocol]. SMTP AUTH:: See crossref:glossary[smtpauth-glossary,SMTP Authentication]. SSH:: See crossref:glossary[ssh-glossary,Secure Shell]. STR:: See crossref:glossary[str-glossary,Suspend To RAM]. SVN:: See crossref:glossary[svn-glossary,Subversion]. [[slaac-glossary]] StateLess Address AutoConfiguration:: {empty} [[smtpauth-glossary]] SMTP Authentication:: {empty} [[smb-glossary]] Server Message Block:: {empty} [[sg-glossary]] Signal Ground:: An RS232 pin or wire that is the ground reference for the signal. [[smtp-glossary]] Simple Mail Transfer Protocol:: {empty} [[ssh-glossary]] Secure Shell:: {empty} [[scsi-glossary]] Small Computer System Interface:: {empty} [[svn-glossary]] Subversion:: Subversion is a version control system currently used by the FreeBSD project. [[str-glossary]] Suspend To RAM:: {empty} [[smp-glossary]] Symmetric MultiProcessor:: {empty} [[sci-glossary]] System Control Interrupt:: {empty} [discrete] == T TCP:: See crossref:glossary[tcp-glossary,Transmission Control Protocol]. TCP/IP:: See crossref:glossary[tcpip-glossary,Transmission Control Protocol/Internet Protocol]. TD:: See crossref:glossary[td-glossary,Transmitted Data]. TFTP:: See crossref:glossary[tftp-glossary,Trivial FTP]. TGT:: See crossref:glossary[tgt-glossary,Ticket-Granting Ticket]. TSC:: See crossref:glossary[tsc-glossary,Time Stamp Counter]. [[tgt-glossary]] Ticket-Granting Ticket:: {empty} [[tsc-glossary]] Time Stamp Counter:: A profiling counter internal to modern Pentium(R) processors that counts core frequency clock ticks. [[tcp-glossary]] Transmission Control Protocol:: A protocol that sits on top of (e.g.) the IP protocol and guarantees that packets are delivered in a reliable, ordered, fashion. [[tcpip-glossary]] Transmission Control Protocol/Internet Protocol:: The term for the combination of the TCP protocol running over the IP protocol. Much of the Internet runs over TCP/IP. [[td-glossary]] Transmitted Data:: An RS232C pin or wire that data is transmitted on. + See crossref:glossary[rd-glossary,Also Received Data]. [[tftp-glossary]] Trivial FTP:: {empty} [discrete] == U UDP:: See crossref:glossary[udp-glossary,User Datagram Protocol]. UFS1:: See crossref:glossary[ufs1-glossary,Unix File System Version 1]. UFS2:: See crossref:glossary[ufs2-glossary,Unix File System Version 2]. UID:: See crossref:glossary[uid-glossary,User ID]. URL:: See crossref:glossary[url-glossary,Uniform Resource Locator]. USB:: See crossref:glossary[usb-glossary,Universal Serial Bus]. [[url-glossary]] Uniform Resource Locator:: A method of locating a resource, such as a document on the Internet and a means to identify that resource. [[ufs1-glossary]] Unix File System Version 1:: The original UNIX(R) file system, sometimes called the Berkeley Fast File System. [[ufs2-glossary]] Unix File System Version 2:: An extension to UFS1, introduced in FreeBSD 5-CURRENT. UFS2 adds 64 bit block pointers (breaking the 1T barrier), support for extended file storage and other features. [[usb-glossary]] Universal Serial Bus:: A hardware standard used to connect a wide variety of computer peripherals to a universal interface. [[uid-glossary]] User ID:: A unique number assigned to each user of a computer, by which the resources and permissions assigned to that user can be identified. [[udp-glossary]] User Datagram Protocol:: A simple, unreliable datagram protocol which is used for exchanging data on a TCP/IP network. UDP does not provide error checking and correction like TCP. [discrete] == V VPN:: See crossref:glossary[vpn-glossary,Virtual Private Network]. [[vpn-glossary]] Virtual Private Network:: A method of using a public telecommunication such as the Internet, to provide remote access to a localized network, such as a corporate LAN.