diff --git a/documentation/content/en/books/handbook/bsdinstall/_index.adoc b/documentation/content/en/books/handbook/bsdinstall/_index.adoc index 2ee52c6588..2d610c108b 100644 --- a/documentation/content/en/books/handbook/bsdinstall/_index.adoc +++ b/documentation/content/en/books/handbook/bsdinstall/_index.adoc @@ -1,1239 +1,1239 @@ --- 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 path: "/books/handbook/" --- [[bsdinstall]] = Installing FreeBSD :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :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. After reading this chapter, you will know: * 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. Before doing this, check that the system is ready for an installation 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. + 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. An alternative is to use virtualization (crossref:virtualization[virtualization,Virtualization]) which allows multiple operating systems to run at the same time without modifying any disk partitions. . *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 <>. * `*-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 <>. 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-13.1-RELEASE-amd64` and `CHECKSUM.SHA512-FreeBSD-13.1-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 you need to compare the calculated _checksum_ against the correct file, 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] .... % sha256sum -c CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-amd64 FreeBSD-13.1-RELEASE-amd64-dvd1.iso FreeBSD-13.1-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] .... -# dd if=FreeBSD-13.0-RELEASE-amd64-memstick.img of=/dev/da0 bs=1M conv=sync +# dd if=FreeBSD-13.1-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 <>. 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 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, <>. [[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 Support`: If the system hangs during boot, try toggling this option to `Off`. * `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 <> 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 <>. [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 <>. [[bsdinstall-keymap-loading]] .Keymap Loading image::bsdinstall-keymap-loading.png[Keymap loading] After the keymaps have been loaded, bsdinstall displays the menu shown in <>. 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 <>. [[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-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 <> 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 <>. [[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 if you have sufficient disk space or multiple disks. 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] After the btn:[Entire Disk] option is chosen, bsdinstall displays a dialog indicating that the disk will be erased. [[bsdinstall-ufs-warning]] .Confirmation image::bsdinstall-ufs-warning.png[Menu indicating the user that all data on the disk will be deleted and asking for confirmation] 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 <>. [[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 <>. [[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 move the cursor between fields. [[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 <> 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: the _freebsd-boot_ partition should be no larger than 512K due to current boot code limitations. ==== 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 <>. [[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 <> 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”]. 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 <>. [[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 <>. 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 <> 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. 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 `ftp://ftp.freebsd.org (Main Site)` will automatically route you 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: * `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[]. * `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. * `moused` - Enable this service if the mouse will be used from the command-line system console. * `ntpdate` - Enable automatic clock synchronization at boot time. Note that the functionality of this program is now available in the man:ntpd[8] daemon and the man:ntpdate[8] utility will soon be retired. * `ntpd` - The Network Time Protocol (NTP) daemon for automatic clock synchronization. Enable this service if you wish to synchronise your system clock with a remote time server or pool. * `powerd` - System power control utility for power control and energy saving. * `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]. * `disable_sendmail` - Disable the sendmail mail transport agent. * `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]. * `enable_aslr` - Enable address layout randomization. For more information about address layout randomization the link:https://en.wikipedia.org/wiki/Address_space_layout_randomization[Wikipedia article] can be consulted. [[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 <> 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 <>. * `Root Password` - Described in <>. * `Hostname` - Described in <>. * `Network` - Described in <>. * `Services` - Described in <>. * `System Hardening` - Described in <>. * `Time Zone` - Described in <>. * `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 you want to open a shell to make manual changes.] 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 <>, 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 <>, 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/cutting-edge/_index.adoc b/documentation/content/en/books/handbook/cutting-edge/_index.adoc index 825c66ee6d..e2e28b1eef 100644 --- a/documentation/content/en/books/handbook/cutting-edge/_index.adoc +++ b/documentation/content/en/books/handbook/cutting-edge/_index.adoc @@ -1,1111 +1,1112 @@ --- title: Chapter 25. Updating and Upgrading FreeBSD part: Part III. System Administration prev: books/handbook/l10n next: books/handbook/dtrace description: Information about how to keep a FreeBSD system up-to-date with freebsd-update or Git, how to rebuild and reinstall the entire base system, etc tags: ["updating", "upgrading", "documentation", "FreeBSD-STABLE", "FreeBSD-CURRENT", "Security Patches"] showBookMenu: true weight: 29 path: "/books/handbook/" --- [[updating-upgrading]] = Updating and Upgrading FreeBSD :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 25 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/cutting-edge/ 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::[] [[updating-upgrading-synopsis]] == Synopsis FreeBSD is under constant development between releases. Some people prefer to use the officially released versions, while others prefer to keep in sync with the latest developments. However, even official releases are often updated with security and other critical fixes. Regardless of the version used, FreeBSD provides all the necessary tools to keep the system updated, and allows for easy upgrades between versions. This chapter describes how to track the development system and the basic tools for keeping a FreeBSD system up-to-date. After reading this chapter, you will know: * How to keep a FreeBSD system up-to-date with freebsd-update or Git. * How to compare the state of an installed system against a known pristine copy. * How to keep the installed documentation up-to-date with Git or documentation ports. * The difference between the two development branches: FreeBSD-STABLE and FreeBSD-CURRENT. * How to rebuild and reinstall the entire base system. Before reading this chapter, you should: * Properly set up the network connection (crossref:advanced-networking[advanced-networking,Advanced Networking]). * Know how to install additional third-party software (crossref:ports[ports,Installing Applications: Packages and Ports]). [NOTE] ==== Throughout this chapter, `git` is used to obtain and update FreeBSD sources. Optionally, the package:devel/git[] port or package may be used. ==== [[updating-upgrading-freebsdupdate]] == FreeBSD Update Applying security patches in a timely manner and upgrading to a newer release of an operating system are important aspects of ongoing system administration. FreeBSD includes a utility called `freebsd-update` which can be used to perform both these tasks. This utility supports binary security and errata updates to FreeBSD, without the need to manually compile and install the patch or a new kernel. Binary updates are available for all architectures and releases currently supported by the security team. The list of supported releases and their estimated end-of-life dates are listed at https://www.FreeBSD.org/security/[https://www.FreeBSD.org/security/]. This utility also supports operating system upgrades to minor point releases as well as upgrades to another release branch. Before upgrading to a new release, review its release announcement as it contains important information pertinent to the release. Release announcements are available from https://www.FreeBSD.org/releases/[https://www.FreeBSD.org/releases/]. [NOTE] ==== If a man:crontab[5] utilizing the features of man:freebsd-update[8] exists, it must be disabled before upgrading the operating system. ==== This section describes the configuration file used by `freebsd-update`, demonstrates how to apply a security patch and how to upgrade to a minor or major operating system release, and discusses some of the considerations when upgrading the operating system. [[freebsdupdate-config-file]] === The Configuration File The default configuration file for `freebsd-update` works as-is. Some users may wish to tweak the default configuration in [.filename]#/etc/freebsd-update.conf#, allowing better control of the process. The comments in this file explain the available options, but the following may require a bit more explanation: [.programlisting] .... # Components of the base system which should be kept updated. Components world kernel .... This parameter controls which parts of FreeBSD will be kept up-to-date. The default is to update the entire base system and the kernel. Individual components can instead be specified, such as `src/base` or `src/sys`. However, the best option is to leave this at the default as changing it to include specific items requires every needed item to be listed. Over time, this could have disastrous consequences as source code and binaries may become out of sync. [.programlisting] .... # Paths which start with anything matching an entry in an IgnorePaths # statement will be ignored. IgnorePaths /boot/kernel/linker.hints .... To leave specified directories, such as [.filename]#/bin# or [.filename]#/sbin#, untouched during the update process, add their paths to this statement. This option may be used to prevent `freebsd-update` from overwriting local modifications. [.programlisting] .... # Paths which start with anything matching an entry in an UpdateIfUnmodified # statement will only be updated if the contents of the file have not been # modified by the user (unless changes are merged; see below). UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile .... This option will only update unmodified configuration files in the specified directories. Any changes made by the user will prevent the automatic updating of these files. There is another option, `KeepModifiedMetadata`, which will instruct `freebsd-update` to save the changes during the merge. [.programlisting] .... # When upgrading to a new FreeBSD release, files which match MergeChanges # will have any local changes merged into the version from the new release. MergeChanges /etc/ /var/named/etc/ /boot/device.hints .... List of directories with configuration files that `freebsd-update` should attempt to merge. The file merge process is a series of man:diff[1] patches similar to man:mergemaster[8], but with fewer options. Merges are either accepted, open an editor, or cause `freebsd-update` to abort. When in doubt, backup [.filename]#/etc# and just accept the merges. See man:mergemaster[8] for more information about `mergemaster`. [.programlisting] .... # Directory in which to store downloaded updates and temporary # files used by FreeBSD Update. # WorkDir /var/db/freebsd-update .... This directory is where all patches and temporary files are placed. In cases where the user is doing a version upgrade, this location should have at least a gigabyte of disk space available. [.programlisting] .... # When upgrading between releases, should the list of Components be # read strictly (StrictComponents yes) or merely as a list of components # which *might* be installed of which FreeBSD Update should figure out # which actually are installed and upgrade those (StrictComponents no)? # StrictComponents no .... When this option is set to `yes`, `freebsd-update` will assume that the `Components` list is complete and will not attempt to make changes outside of the list. Effectively, `freebsd-update` will attempt to update every file which belongs to the `Components` list. Refer to man:freebsd-update.conf[5] for more details. [[freebsdupdate-security-patches]] === Applying Security Patches The process of applying FreeBSD security patches has been simplified, allowing an administrator to keep a system fully patched using `freebsd-update`. More information about FreeBSD security advisories can be found in crossref:security[security-advisories,"FreeBSD Security Advisories"]. FreeBSD security patches may be downloaded and installed using the following commands. The first command will determine if any outstanding patches are available, and if so, will list the files that will be modifed if the patches are applied. The second command will apply the patches. [source,shell] .... # freebsd-update fetch # freebsd-update install .... If the update applies any kernel patches, the system will need a reboot in order to boot into the patched kernel. If the patch was applied to any running binaries, the affected applications should be restarted so that the patched version of the binary is used. [NOTE] ==== Usually, the user needs to be prepared to reboot the system. To know if the system requires a reboot due to a kernel update, execute the commands `freebsd-version -k` and `uname -r`. Reboot the system if the outputs differ. ==== The system can be configured to automatically check for updates once every day by adding this entry to [.filename]#/etc/crontab#: [.programlisting] .... @daily root freebsd-update cron .... If patches exist, they will automatically be downloaded but will not be applied. The `root` user will be sent an email so that the patches may be reviewed and manually installed with `freebsd-update install`. If anything goes wrong, `freebsd-update` has the ability to roll back the last set of changes with the following command: [source,shell] .... # freebsd-update rollback Uninstalling updates... done. .... Again, the system should be restarted if the kernel or any kernel modules were modified and any affected binaries should be restarted. Only the [.filename]#GENERIC# kernel can be automatically updated by `freebsd-update`. If a custom kernel is installed, it will have to be rebuilt and reinstalled after `freebsd-update` finishes installing the updates. The default kernel name is _GENERIC_. The man:uname[1] command may be used to verify its installation. [NOTE] ==== Always keep a copy of the [.filename]#GENERIC# kernel in [.filename]#/boot/GENERIC#. It will be helpful in diagnosing a variety of problems and in performing version upgrades. Refer to <> for instructions on how to get a copy of the [.filename]#GENERIC# kernel. ==== Unless the default configuration in [.filename]#/etc/freebsd-update.conf# has been changed, `freebsd-update` will install the updated kernel sources along with the rest of the updates. Rebuilding and reinstalling a new custom kernel can then be performed in the usual way. The updates distributed by `freebsd-update` do not always involve the kernel. It is not necessary to rebuild a custom kernel if the kernel sources have not been modified by `freebsd-update install`. However, `freebsd-update` will always update [.filename]#/usr/src/sys/conf/newvers.sh#. The current patch level, as indicated by the `-p` number reported by `uname -r`, is obtained from this file. Rebuilding a custom kernel, even if nothing else changed, allows `uname` to accurately report the current patch level of the system. This is particularly helpful when maintaining multiple systems, as it allows for a quick assessment of the updates installed in each one. [[freebsdupdate-upgrade]] === Performing Major and Minor Version Upgrades Upgrades from one minor version of FreeBSD to another, like from FreeBSD 9.0 to FreeBSD 9.1, are called _minor version_ upgrades. _Major version_ upgrades occur when FreeBSD is upgraded from one major version to another, like from FreeBSD 9.X to FreeBSD 10.X. Both types of upgrades can be performed by providing `freebsd-update` with a release version target. [NOTE] ==== If the system is running a custom kernel, make sure that a copy of the [.filename]#GENERIC# kernel exists in [.filename]#/boot/GENERIC# before starting the upgrade. Refer to <> for instructions on how to get a copy of the [.filename]#GENERIC# kernel. ==== -The following command, when run on a FreeBSD 9.0 system, will upgrade it to FreeBSD 9.1: +The following command, when run on a FreeBSD 13.0 system, will upgrade it to FreeBSD 13.1: [source,shell] .... -# freebsd-update -r 9.1-RELEASE upgrade +# freebsd-update -r 13.1-RELEASE upgrade .... After the command has been received, `freebsd-update` will evaluate the configuration file and current system in an attempt to gather the information necessary to perform the upgrade. A screen listing will display which components have and have not been detected. For example: [source,shell] .... Looking up update.FreeBSD.org mirrors... 1 mirrors found. -Fetching metadata signature for 9.0-RELEASE from update1.FreeBSD.org... done. +Fetching metadata signature for 13.0-RELEASE from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/smp src/base src/bin src/contrib src/crypto src/etc src/games src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin world/base world/info world/lib32 world/manpages The following components of FreeBSD do not seem to be installed: kernel/generic world/catpages world/dict world/doc world/games world/proflibs Does this look reasonable (y/n)? y .... At this point, `freebsd-update` will attempt to download all files required for the upgrade. In some cases, the user may be prompted with questions regarding what to install or how to proceed. When using a custom kernel, the above step will produce a warning similar to the following: [source,shell] .... WARNING: This system is running a "MYKERNEL" kernel, which is not a -kernel configuration distributed as part of FreeBSD 9.0-RELEASE. +kernel configuration distributed as part of FreeBSD 13.0-RELEASE. This kernel will not be updated: you MUST update the kernel manually before running "/usr/sbin/freebsd-update install" .... This warning may be safely ignored at this point. The updated [.filename]#GENERIC# kernel will be used as an intermediate step in the upgrade process. Once all the patches have been downloaded to the local system, they will be applied. This process may take a while, depending on the speed and workload of the machine. Configuration files will then be merged. The merging process requires some user intervention as a file may be merged or an editor may appear on screen for a manual merge. The results of every successful merge will be shown to the user as the process continues. A failed or ignored merge will cause the process to abort. Users may wish to make a backup of [.filename]#/etc# and manually merge important files, such as [.filename]#master.passwd# or [.filename]#group# at a later time. [NOTE] ==== The system is not being altered yet as all patching and merging is happening in another directory. Once all patches have been applied successfully, all configuration files have been merged and it seems the process will go smoothly, the changes can be committed to disk by the user using the following command: [source,shell] .... # freebsd-update install .... ==== The kernel and kernel modules will be patched first. If the system is running with a custom kernel, use man:nextboot[8] to set the kernel for the next boot to the updated [.filename]#/boot/GENERIC#: [source,shell] .... # nextboot -k GENERIC .... [WARNING] ==== Before rebooting with the [.filename]#GENERIC# kernel, make sure it contains all the drivers required for the system to boot properly and connect to the network, if the machine being updated is accessed remotely. In particular, if the running custom kernel contains built-in functionality usually provided by kernel modules, make sure to temporarily load these modules into the [.filename]#GENERIC# kernel using the [.filename]#/boot/loader.conf# facility. It is recommended to disable non-essential services as well as any disk and network mounts until the upgrade process is complete. ==== The machine should now be restarted with the updated kernel: [source,shell] .... # shutdown -r now .... Once the system has come back online, restart `freebsd-update` using the following command. Since the state of the process has been saved, `freebsd-update` will not start from the beginning, but will instead move on to the next phase and remove all old shared libraries and object files. [source,shell] .... # freebsd-update install .... [NOTE] ==== Depending upon whether any library version numbers were bumped, there may only be two install phases instead of three. ==== The upgrade is now complete. If this was a major version upgrade, reinstall all ports and packages as described in <>. [[freebsd-update-custom-kernel-9x]] ==== Custom Kernels with FreeBSD 9.X and Later Before using `freebsd-update`, ensure that a copy of the [.filename]#GENERIC# kernel exists in [.filename]#/boot/GENERIC#. If a custom kernel has only been built once, the kernel in [.filename]#/boot/kernel.old# is the `GENERIC` kernel. Simply rename this directory to [.filename]#/boot/GENERIC#. If a custom kernel has been built more than once or if it is unknown how many times the custom kernel has been built, obtain a copy of the `GENERIC` kernel that matches the current version of the operating system. If physical access to the system is available, a copy of the `GENERIC` kernel can be installed from the installation media: [source,shell] .... # mount /cdrom # cd /cdrom/usr/freebsd-dist # tar -C/ -xvf kernel.txz boot/kernel/kernel .... Alternately, the `GENERIC` kernel may be rebuilt and installed from source: [source,shell] .... # cd /usr/src # make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null .... For this kernel to be identified as the `GENERIC` kernel by `freebsd-update`, the [.filename]#GENERIC# configuration file must not have been modified in any way. It is also suggested that the kernel is built without any other special options. Rebooting into the [.filename]#GENERIC# kernel is not required as `freebsd-update` only needs [.filename]#/boot/GENERIC# to exist. [[freebsdupdate-portsrebuild]] ==== Upgrading Packages After a Major Version Upgrade Generally, installed applications will continue to work without problems after minor version upgrades. Major versions use different Application Binary Interfaces (ABIs), which will break most third-party applications. After a major version upgrade, all installed packages and ports need to be upgraded. Packages can be upgraded using `pkg upgrade`. To upgrade installed ports, use a utility such as package:ports-mgmt/portmaster[]. A forced upgrade of all installed packages will replace the packages with fresh versions from the repository even if the version number has not increased. This is required because of the ABI version change when upgrading between major versions of FreeBSD. The forced upgrade can be accomplished by performing: [source,shell] .... # pkg-static upgrade -f .... A rebuild of all installed applications can be accomplished with this command: [source,shell] .... # portmaster -af .... This command will display the configuration screens for each application that has configurable options and wait for the user to interact with those screens. To prevent this behavior, and use only the default options, include `-G` in the above command. Once the software upgrades are complete, finish the upgrade process with a final call to `freebsd-update` in order to tie up all the loose ends in the upgrade process: [source,shell] .... # freebsd-update install .... If the [.filename]#GENERIC# kernel was temporarily used, this is the time to build and install a new custom kernel using the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]. Reboot the machine into the new FreeBSD version. The upgrade process is now complete. [[freebsdupdate-system-comparison]] === System State Comparison The state of the installed FreeBSD version against a known good copy can be tested using `freebsd-update IDS`. This command evaluates the current version of system utilities, libraries, and configuration files and can be used as a built-in Intrusion Detection System (IDS). [WARNING] ==== This command is not a replacement for a real IDS such as package:security/snort[]. As `freebsd-update` stores data on disk, the possibility of tampering is evident. While this possibility may be reduced using `kern.securelevel` and by storing the `freebsd-update` data on a read-only file system when not in use, a better solution would be to compare the system against a secure disk, such as a DVD or securely stored external USB disk device. An alternative method for providing IDS functionality using a built-in utility is described in crossref:security[security-ids,"Binary Verification"] ==== To begin the comparison, specify the output file to save the results to: [source,shell] .... # freebsd-update IDS >> outfile.ids .... The system will now be inspected and a lengthy listing of files, along with the SHA256 hash values for both the known value in the release and the current installation, will be sent to the specified output file. The entries in the listing are extremely long, but the output format may be easily parsed. For instance, to obtain a list of all files which differ from those in the release, issue the following command: [source,shell] .... # cat outfile.ids | awk '{ print $1 }' | more /etc/master.passwd /etc/motd /etc/passwd /etc/pf.conf .... This sample output has been truncated as many more files exist. Some files have natural modifications. For example, [.filename]#/etc/passwd# will be modified if users have been added to the system. Kernel modules may differ as `freebsd-update` may have updated them. To exclude specific files or directories, add them to the `IDSIgnorePaths` option in [.filename]#/etc/freebsd-update.conf#. [[updating-bootcode]] == Updating Bootcode The following manuals describe the upgrade process of bootcode and boot loaders: man:gpart[8], man:gptboot[8], man:gptzfsboot[8], and man:loader.efi[8]. [[updating-upgrading-documentation]] == Updating the Documentation Set Documentation is an integral part of the FreeBSD operating system. While an up-to-date version of the FreeBSD documentation is always available on the FreeBSD web site (link:https://docs.FreeBSD.org[Documentation Portal]), it can be handy to have an up-to-date, local copy of the FreeBSD website, handbooks, FAQ, and articles. This section describes how to use either source or the FreeBSD Ports Collection to keep a local copy of the FreeBSD documentation up-to-date. For information on editing and submitting corrections to the documentation, refer to the FreeBSD Documentation Project Primer for New Contributors (extref:{fdp-primer}[FreeBSD Documentation Project Primer for New Contributors]). [[updating-installed-documentation]] === Updating Documentation from Source Rebuilding the FreeBSD documentation from source requires a collection of tools which are not part of the FreeBSD base system. The required tools can be installed following extref:{fdp-primer}[these steps, overview-quick-start] from the FreeBSD Documentation Project Primer. Once installed, use `git` to fetch a clean copy of the documentation source: [source,shell] .... # git clone https://git.FreeBSD.org/doc.git /usr/doc .... The initial download of the documentation sources may take a while. Let it run until it completes. Future updates of the documentation sources may be fetched by running: [source,shell] .... # git pull .... Once an up-to-date snapshot of the documentation sources has been fetched to [.filename]#/usr/doc#, everything is ready for an update of the installed documentation. A full update may be performed by typing: [source,shell] .... # cd /usr/doc # make .... [[current-stable]] == Tracking a Development Branch FreeBSD has two development branches: FreeBSD-CURRENT and FreeBSD-STABLE. This section provides an explanation of each branch and its intended audience, as well as how to keep a system up-to-date with each respective branch. [[current]] === Using FreeBSD-CURRENT FreeBSD-CURRENT is the "bleeding edge" of FreeBSD development and FreeBSD-CURRENT users are expected to have a high degree of technical skill. Less technical users who wish to track a development branch should track FreeBSD-STABLE instead. FreeBSD-CURRENT is the very latest source code for FreeBSD and includes works in progress, experimental changes, and transitional mechanisms that might or might not be present in the next official release. While many FreeBSD developers compile the FreeBSD-CURRENT source code daily, there are short periods of time when the source may not be buildable. These problems are resolved as quickly as possible, but whether or not FreeBSD-CURRENT brings disaster or new functionality can be a matter of when the source code was synced. FreeBSD-CURRENT is made available for three primary interest groups: . Members of the FreeBSD community who are actively working on some part of the source tree. . Members of the FreeBSD community who are active testers. They are willing to spend time solving problems, making topical suggestions on changes and the general direction of FreeBSD, and submitting patches. . Users who wish to keep an eye on things, use the current source for reference purposes, or make the occasional comment or code contribution. FreeBSD-CURRENT should _not_ be considered a fast-track to getting new features before the next release as pre-release features are not yet fully tested and most likely contain bugs. It is not a quick way of getting bug fixes as any given commit is just as likely to introduce new bugs as to fix existing ones. FreeBSD-CURRENT is not in any way "officially supported". To track FreeBSD-CURRENT: . Join the {freebsd-current} and the {dev-commits-src-main} lists. This is _essential_ in order to see the comments that people are making about the current state of the system and to receive important bulletins about the current state of FreeBSD-CURRENT. + The {dev-commits-src-main} list records the commit log entry for each change as it is made, along with any pertinent information on possible side effects. + To join these lists, go to {mailing-lists}, click on the list to subscribe to, and follow the instructions. In order to track changes to the whole source tree, not just the changes to FreeBSD-CURRENT, subscribe to the {dev-commits-src-all}. . Synchronize with the FreeBSD-CURRENT sources. Typically, `git` is used to check out the -CURRENT code from the `main` branch of the FreeBSD Git repository (see crossref:mirrors[git,“Using Git”] for details). . Due to the size of the repository, some users choose to only synchronize the sections of source that interest them or which they are contributing patches to. However, users that plan to compile the operating system from source must download _all_ of FreeBSD-CURRENT, not just selected portions. + Before compiling FreeBSD-CURRENT, read [.filename]#/usr/src/Makefile# very carefully and follow the instructions in <>. Read the {freebsd-current} and [.filename]#/usr/src/UPDATING# to stay up-to-date on other bootstrapping procedures that sometimes become necessary on the road to the next release. . Be active! FreeBSD-CURRENT users are encouraged to submit their suggestions for enhancements or bug fixes. Suggestions with accompanying code are always welcome. [[stable]] === Using FreeBSD-STABLE FreeBSD-STABLE is the development branch from which major releases are made. Changes go into this branch at a slower pace and with the general assumption that they have first been tested in FreeBSD-CURRENT. This is _still_ a development branch and, at any given time, the sources for FreeBSD-STABLE may or may not be suitable for general use. It is simply another engineering development track, not a resource for end-users. Users who do not have the resources to perform testing should instead run the most recent release of FreeBSD. Those interested in tracking or contributing to the FreeBSD development process, especially as it relates to the next release of FreeBSD, should consider following FreeBSD-STABLE. While the FreeBSD-STABLE branch should compile and run at all times, this cannot be guaranteed. Since more people run FreeBSD-STABLE than FreeBSD-CURRENT, it is inevitable that bugs and corner cases will sometimes be found in FreeBSD-STABLE that were not apparent in FreeBSD-CURRENT. For this reason, one should not blindly track FreeBSD-STABLE. It is particularly important _not_ to update any production servers to FreeBSD-STABLE without thoroughly testing the code in a development or testing environment. To track FreeBSD-STABLE: . Join the {freebsd-stable} in order to stay informed of build dependencies that may appear in FreeBSD-STABLE or any other issues requiring special attention. Developers will also make announcements in this mailing list when they are contemplating some controversial fix or update, giving the users a chance to respond if they have any issues to raise concerning the proposed change. + Join the relevant git list for the branch being tracked. For example, users tracking the {betarel-current-major}-STABLE branch should join the {dev-commits-src-branches}. This list records the commit log entry for each change as it is made, along with any pertinent information on possible side effects. + To join these lists, go to {mailing-lists}, click on the list to subscribe to, and follow the instructions. In order to track changes for the whole source tree, subscribe to {dev-commits-src-all}. . To install a new FreeBSD-STABLE system, install the most recent FreeBSD-STABLE release from the crossref:mirrors[mirrors,FreeBSD mirror sites] or use a monthly snapshot built from FreeBSD-STABLE. Refer to link:https://www.FreeBSD.org/snapshots/[www.freebsd.org/snapshots] for more information about snapshots. + To compile or upgrade an existing FreeBSD system to FreeBSD-STABLE, use `git` to check out the source for the desired branch. Branch names, such as `stable/9`, are listed at link:https://www.FreeBSD.org/releng/[www.freebsd.org/releng]. . Before compiling or upgrading to FreeBSD-STABLE , read [.filename]#/usr/src/Makefile# carefully and follow the instructions in <>. Read the {freebsd-stable} and [.filename]#/usr/src/UPDATING# to keep up-to-date on other bootstrapping procedures that sometimes become necessary on the road to the next release. [[translate-n-number]] === The N-number When tracking down bugs it is important to know which versions of the source code have been used to create the system exhibiting an issue. FreeBSD provides version information compiled into the kernel. man:uname[1] retrieves this information, for example: [source,shell] .... % uname -v FreeBSD 14.0-CURRENT #112 main-n247514-031260d64c18: Tue Jun 22 20:43:19 MDT 2021 fred@machine:/usr/home/fred/obj/usr/home/fred/git/head/amd64.amd64/sys/FRED .... The final field gives information regarding the kernel name, the person that built it, and the location that it was compiled in. Looking at the 4th field, it is made up of several parts: [source,shell] .... main-n247514-031260d64c18 main <.> n247514 <.> 031260d64c18 <.> <.> .... <.> Git branch name. Note: comparisons of n-numbers are only valid on branches published by the project (`main`, `stable/XX` and `releng/XX`). Local branches will have n-numbers that will overlap commits of their parent branch. <.> The n-number is a linear count of commits back to the start of the Git repository starting with the Git hash included in the line. <.> Git hash of the checked out tree <.> Sometimes a suffix of `-dirty` is present when the kernel was built in a tree with uncommitted changes. It is absent in this example because the FRED kernel was built from a pristine checkout. The `git rev-list` command is used to find the n-number corresponding to a Git hash. For example: [source,shell] .... % git rev-list --first-parent --count 031260d64c18 <.> 247514 <.> .... <.> git hash to translate (the hash from the above example is reused) <.> The n-number. Usually this number is not all that important. However, when bug fixes are committed, this number makes it easy to quickly determine whether the fix is present in the currently running system. Developers will often refer to the hash of the commit (or provide a URL which has that hash), but not the n-number since the hash is the easily visible identifier for a change while the n-number is not. Security advisories and errata notices will also note an n-number, which can be directly compared against your system. When you need to use shallow Git clones, you cannot compare n-numbers reliably as the `git rev-list` command counts all the revisions in the repository which a shallow clone omits. [[makeworld]] == Updating FreeBSD from Source Updating FreeBSD by compiling from source offers several advantages over binary updates. Code can be built with options to take advantage of specific hardware. Parts of the base system can be built with non-default settings, or left out entirely where they are not needed or desired. The build process takes longer to update a system than just installing binary updates, but allows complete customization to produce a tailored version of FreeBSD. [[updating-src-quick-start]] === Quick Start This is a quick reference for the typical steps used to update FreeBSD by building from source. Later sections describe the process in more detail. [WARNING] ==== When switching from man:mergemaster[8] to man:etcupdate[8], the first run might merge changes incorrectly generating spurious conflicts. To prevent this, perform the following steps *before* updating sources and building the new world: [source,shell] .... # etcupdate extract <.> # etcupdate diff <.> .... <.> Bootstrap the database of stock [.filename]#/etc# files; for more information see man:etcupdate[8]. <.> Check the diff after bootstrapping. Trim any local changes that are no longer needed to reduce the chance of conflicts in future updates. ==== [.procedure] ==== * Update and Build + [source,shell] .... # git pull /usr/src <.> check /usr/src/UPDATING <.> # cd /usr/src <.> # make -j4 buildworld <.> # make -j4 kernel <.> # shutdown -r now <.> # etcupdate -p <.> # cd /usr/src <.> # make installworld <.> # etcupdate -B <.> # shutdown -r now <.> .... <.> Get the latest version of the source. See <> for more information on obtaining and updating source. <.> Check [.filename]#/usr/src/UPDATING# for any manual steps required before or after building from source. <.> Go to the source directory. <.> Compile the world, everything except the kernel. <.> Compile and install the kernel. This is equivalent to `make buildkernel installkernel`. <.> Reboot the system to the new kernel. <.> Update and merge configuration files in [.filename]#/etc/# required before installworld. <.> Go to the source directory. <.> Install the world. <.> Update and merge configuration files in [.filename]#/etc/#. <.> Restart the system to use the newly-built world and kernel. ==== [[updating-src-preparing]] === Preparing for a Source Update Read [.filename]#/usr/src/UPDATING#. Any manual steps that must be performed before or after an update are described in this file. [[updating-src-obtaining-src]] === Updating the Source FreeBSD source code is located in [.filename]#/usr/src/#. The preferred method of updating this source is through the Git version control system. Verify that the source code is under version control: [source,shell] .... # cd /usr/src # git remote --v origin https://git.freebsd.org/src.git (fetch) origin https://git.freebsd.org/src.git (push) .... This indicates that [.filename]#/usr/src/# is under version control and can be updated with man:git[1]: [[synching]] [source,shell] .... # git pull /usr/src .... The update process can take some time if the directory has not been updated recently. After it finishes, the source code is up to date and the build process described in the next section can begin. [NOTE] ==== *Obtaining the Source:* + If the output says `fatal: not a git repository`, the files there are missing or were installed with a different method. A new checkout of the source is required. [[updating-src-obtaining-src-repopath]] .FreeBSD Versions and Repository Branches [cols="10%,10%,80%", options="header"] |=== | uname -r Output | Repository Path | Description |`_X.Y_-RELEASE` |`releng/_X.Y_` |The Release version plus only critical security and bug fix patches. This branch is recommended for most users. |`_X.Y_-STABLE` |`stable/_X_` | The Release version plus all additional development on that branch. _STABLE_ refers to the Applications Binary Interface (ABI) not changing, so software compiled for earlier versions still runs. For example, software compiled to run on FreeBSD 10.1 will still run on FreeBSD 10-STABLE compiled later. STABLE branches occasionally have bugs or incompatibilities which might affect users, although these are typically fixed quickly. |`_X_-CURRENT` |`main` |The latest unreleased development version of FreeBSD. The CURRENT branch can have major bugs or incompatibilities and is recommended only for advanced users. |=== Determine which version of FreeBSD is being used with man:uname[1]: [source,shell] .... # uname -r -10.3-RELEASE +13.1-RELEASE .... -Based on <>, the source used to update `10.3-RELEASE` has a repository path of `releng/10.3`. That path is used when checking out the source: +Based on <>, the source used to update `13.1-RELEASE` has a repository path of `releng/13.1`. +That path is used when checking out the source: [source,shell] .... # mv /usr/src /usr/src.bak <.> -# git clone --branch releng/10.3 https://git.FreeBSD.org/src.git /usr/src <.> +# git clone --branch releng/13.1 https://git.FreeBSD.org/src.git /usr/src <.> .... <.> Move the old directory out of the way. If there are no local modifications in this directory, it can be deleted. <.> The path from <> is added to the repository URL. The third parameter is the destination directory for the source code on the local system. ==== [[updating-src-building]] === Building from Source The _world_, or all of the operating system except the kernel, is compiled. This is done first to provide up-to-date tools to build the kernel. Then the kernel itself is built: [source,shell] .... # cd /usr/src # make buildworld # make buildkernel .... The compiled code is written to [.filename]#/usr/obj#. These are the basic steps. Additional options to control the build are described below. [[updating-src-building-clean-build]] ==== Performing a Clean Build Some versions of the FreeBSD build system leave previously-compiled code in the temporary object directory, [.filename]#/usr/obj#. This can speed up later builds by avoiding recompiling code that has not changed. To force a clean rebuild of everything, use `cleanworld` before starting a build: [source,shell] .... # make cleanworld .... [[updating-src-building-jobs]] ==== Setting the Number of Jobs Increasing the number of build jobs on multi-core processors can improve build speed. Determine the number of cores with `sysctl hw.ncpu`. Processors vary, as do the build systems used with different versions of FreeBSD, so testing is the only sure method to tell how a different number of jobs affects the build speed. For a starting point, consider values between half and double the number of cores. The number of jobs is specified with `-j`. [[updating-src-building-jobs-example]] .Increasing the Number of Build Jobs [example] ==== Building the world and kernel with four jobs: [source,shell] .... # make -j4 buildworld buildkernel .... ==== [[updating-src-building-only-kernel]] ==== Building Only the Kernel A `buildworld` must be completed if the source code has changed. After that, a `buildkernel` to build a kernel can be run at any time. To build just the kernel: [source,shell] .... # cd /usr/src # make buildkernel .... [[updating-src-building-custom-kernel]] ==== Building a Custom Kernel The standard FreeBSD kernel is based on a _kernel config file_ called [.filename]#GENERIC#. The [.filename]#GENERIC# kernel includes the most commonly-needed device drivers and options. Sometimes it is useful or necessary to build a custom kernel, adding or removing device drivers or options to fit a specific need. For example, someone developing a small embedded computer with severely limited RAM could remove unneeded device drivers or options to make the kernel slightly smaller. Kernel config files are located in [.filename]#/usr/src/sys/arch/conf/#, where _arch_ is the output from `uname -m`. On most computers, that is `amd64`, giving a config file directory of [.filename]#/usr/src/sys/amd64/conf/#. [TIP] ==== [.filename]#/usr/src# can be deleted or recreated, so it is preferable to keep custom kernel config files in a separate directory, like [.filename]#/root#. Link the kernel config file into the [.filename]#conf# directory. If that directory is deleted or overwritten, the kernel config can be re-linked into the new one. ==== A custom config file can be created by copying the [.filename]#GENERIC# config file. In this example, the new custom kernel is for a storage server, so is named [.filename]#STORAGESERVER#: [source,shell] .... # cp /usr/src/sys/amd64/conf/GENERIC /root/STORAGESERVER # cd /usr/src/sys/amd64/conf # ln -s /root/STORAGESERVER . .... [.filename]#/root/STORAGESERVER# is then edited, adding or removing devices or options as shown in man:config[5]. The custom kernel is built by setting `KERNCONF` to the kernel config file on the command line: [source,shell] .... # make buildkernel KERNCONF=STORAGESERVER .... [[updating-src-installing]] === Installing the Compiled Code After the `buildworld` and `buildkernel` steps have been completed, the new kernel and world are installed: [source,shell] .... # cd /usr/src # make installkernel # shutdown -r now # cd /usr/src # make installworld # shutdown -r now .... If a custom kernel was built, `KERNCONF` must also be set to use the new custom kernel: [source,shell] .... # cd /usr/src # make installkernel KERNCONF=STORAGESERVER # shutdown -r now # cd /usr/src # make installworld # shutdown -r now .... [[updating-src-completing]] === Completing the Update A few final tasks complete the update. Any modified configuration files are merged with the new versions, outdated libraries are located and removed, then the system is restarted. [[updating-src-completing-merge-etcupdate]] ==== Merging Configuration Files with man:etcupdate[8] man:etcupdate[8] is a tool for managing updates to files that are not updated as part of an installworld such as files located in [.filename]#/etc/#. It manages updates by doing a three-way merge of changes made to these files against the local versions. It is also designed to minimize the amount of user intervention, in contrast to man:mergemaster[8]'s interactive prompts. [NOTE] ==== In general, man:etcupdate[8] does not need any specific arguments for its job. There is however a handy in between command for sanity checking what will be done the first time man:etcupdate[8] is used: [source,shell] .... # etcupdate diff .... This command allows the user to audit configuration changes. ==== If man:etcupdate[8] is not able to merge a file automatically, the merge conflicts can be resolved with manual interaction by issuing: [source,shell] .... # etcupdate resolve .... [WARNING] ==== When switching from man:mergemaster[8] to man:etcupdate[8], the first run might merge changes incorrectly generating spurious conflicts. To prevent this, perform the following steps *before* updating sources and building the new world: [source,shell] .... # etcupdate extract <.> # etcupdate diff <.> .... <.> Bootstrap the database of stock [.filename]#/etc# files; for more information see man:etcupdate[8]. <.> Check the diff after bootstrapping. Trim any local changes that are no longer needed to reduce the chance of conflicts in future updates. ==== [[updating-src-completing-merge-mergemaster]] ==== Merging Configuration Files with man:mergemaster[8] man:mergemaster[8] provides a way to merge changes that have been made to system configuration files with new versions of those files. man:mergemaster[8] is an alternative to the preferred man:etcupdate[8] With `-Ui`, man:mergemaster[8] automatically updates files that have not been user-modified and installs new files that are not already present: [source,shell] .... # mergemaster -Ui .... If a file must be manually merged, an interactive display allows the user to choose which portions of the files are kept. See man:mergemaster[8] for more information. [[updating-src-completing-check-old]] ==== Checking for Outdated Files and Libraries Some obsolete files or directories can remain after an update. These files can be located: [source,shell] .... # make check-old .... and deleted: [source,shell] .... # make delete-old .... Some obsolete libraries can also remain. These can be detected with: [source,shell] .... # make check-old-libs .... and deleted with [source,shell] .... # make delete-old-libs .... Programs which were still using those old libraries will stop working when the library has been deleted. These programs must be rebuilt or replaced after deleting the old libraries. [TIP] ==== When all the old files or directories are known to be safe to delete, pressing kbd:[y] and kbd:[Enter] to delete each file can be avoided by setting `BATCH_DELETE_OLD_FILES` in the command. For example: [source,shell] .... # make BATCH_DELETE_OLD_FILES=yes delete-old-libs .... ==== [[updating-src-completing-restart]] ==== Restarting After the Update The last step after updating is to restart the computer so all the changes take effect: [source,shell] .... # shutdown -r now .... [[small-lan]] == Tracking for Multiple Machines When multiple machines need to track the same source tree, it is a waste of disk space, network bandwidth, and CPU cycles to have each system download the sources and rebuild everything. The solution is to have one machine do most of the work, while the rest of the machines mount that work via NFS. This section outlines a method of doing so. For more information about using NFS, refer to crossref:network-servers[network-nfs,"Network File System (NFS)"]. First, identify a set of machines which will run the same set of binaries, known as a _build set_. Each machine can have a custom kernel, but will run the same userland binaries. From that set, choose a machine to be the _build machine_ that the world and kernel are built on. Ideally, this is a fast machine that has sufficient spare CPU to run `make buildworld` and `make buildkernel`. Select a machine to be the _test machine_, which will test software updates before they are put into production. This _must_ be a machine that can afford to be down for an extended period of time. It can be the build machine, but need not be. All the machines in this build set need to mount [.filename]#/usr/obj# and [.filename]#/usr/src# from the build machine via NFS. For multiple build sets, [.filename]#/usr/src# should be on one build machine, and NFS mounted on the rest. Ensure that [.filename]#/etc/make.conf# and [.filename]#/etc/src.conf# on all the machines in the build set agree with the build machine. That means that the build machine must build all the parts of the base system that any machine in the build set is going to install. Also, each build machine should have its kernel name set with `KERNCONF` in [.filename]#/etc/make.conf#, and the build machine should list them all in its `KERNCONF`, listing its own kernel first. The build machine must have the kernel configuration files for each machine in its [.filename]#/usr/src/sys/arch/conf#. On the build machine, build the kernel and world as described in <>, but do not install anything on the build machine. Instead, install the built kernel on the test machine. On the test machine, mount [.filename]#/usr/src# and [.filename]#/usr/obj# via NFS. Then, run `shutdown now` to go to single-user mode in order to install the new kernel and world and run `mergemaster` as usual. When done, reboot to return to normal multi-user operations. After verifying that everything on the test machine is working properly, use the same procedure to install the new software on each of the other machines in the build set. The same methodology can be used for the ports tree. The first step is to share [.filename]#/usr/ports# via NFS to all the machines in the build set. To configure [.filename]#/etc/make.conf# to share distfiles, set `DISTDIR` to a common shared directory that is writable by whichever user `root` is mapped to by the NFS mount. Each machine should set `WRKDIRPREFIX` to a local build directory, if ports are to be built locally. Alternately, if the build system is to build and distribute packages to the machines in the build set, set `PACKAGES` on the build system to a directory similar to `DISTDIR`. diff --git a/documentation/content/en/books/handbook/jails/_index.adoc b/documentation/content/en/books/handbook/jails/_index.adoc index efc0b4e0c2..a53c90ea97 100644 --- a/documentation/content/en/books/handbook/jails/_index.adoc +++ b/documentation/content/en/books/handbook/jails/_index.adoc @@ -1,1230 +1,1230 @@ --- title: Chapter 16. Jails part: Part III. System Administration prev: books/handbook/security next: books/handbook/mac description: Jails improve on the concept of the traditional chroot environment in several ways tags: ["jails", "creating", "managing", "updating", "ezjail"] showBookMenu: true weight: 20 path: "/books/handbook/" --- [[jails]] = Jails :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 16 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/jails/ 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::[] [[jails-synopsis]] == Synopsis Since system administration is a difficult task, many tools have been developed to make life easier for the administrator. These tools often enhance the way systems are installed, configured, and maintained. One of the tools which can be used to enhance the security of a FreeBSD system is _jails_. Jails have been available since FreeBSD 4.X and continue to be enhanced in their usefulness, performance, reliability, and security. Jails build upon the man:chroot[2] concept, which is used to change the root directory of a set of processes. This creates a safe environment, separate from the rest of the system. Processes created in the chrooted environment can not access files or resources outside of it. For that reason, compromising a service running in a chrooted environment should not allow the attacker to compromise the entire system. However, a chroot has several limitations. It is suited to easy tasks which do not require much flexibility or complex, advanced features. Over time, many ways have been found to escape from a chrooted environment, making it a less than ideal solution for securing services. Jails improve on the concept of the traditional chroot environment in several ways. In a traditional chroot environment, processes are only limited in the part of the file system they can access. The rest of the system resources, system users, running processes, and the networking subsystem are shared by the chrooted processes and the processes of the host system. Jails expand this model by virtualizing access to the file system, the set of users, and the networking subsystem. More fine-grained controls are available for tuning the access of a jailed environment. Jails can be considered as a type of operating system-level virtualization. A jail is characterized by four elements: * A directory subtree: the starting point from which a jail is entered. Once inside the jail, a process is not permitted to escape outside of this subtree. * A hostname: which will be used by the jail. * An IP address: which is assigned to the jail. The IP address of a jail is often an alias address for an existing network interface. * A command: the path name of an executable to run inside the jail. The path is relative to the root directory of the jail environment. Jails have their own set of users and their own `root` account which are limited to the jail environment. The `root` account of a jail is not allowed to perform operations to the system outside of the associated jail environment. This chapter provides an overview of the terminology and commands for managing FreeBSD jails. Jails are a powerful tool for both system administrators, and advanced users. After reading this chapter, you will know: * What a jail is and what purpose it may serve in FreeBSD installations. * How to build, start, and stop a jail. * The basics of jail administration, both from inside and outside the jail. [IMPORTANT] ==== Jails are a powerful tool, but they are not a security panacea. While it is not possible for a jailed process to break out on its own, there are several ways in which an unprivileged user outside the jail can cooperate with a privileged user inside the jail to obtain elevated privileges in the host environment. Most of these attacks can be mitigated by ensuring that the jail root is not accessible to unprivileged users in the host environment. As a general rule, untrusted users with privileged access to a jail should not be given access to the host environment. ==== [[jails-terms]] == Terms Related to Jails To facilitate better understanding of parts of the FreeBSD system related to jails, their internals and the way they interact with the rest of FreeBSD, the following terms are used further in this chapter: man:chroot[8] (command):: Utility, which uses man:chroot[2] FreeBSD system call to change the root directory of a process and all its descendants. man:chroot[2] (environment):: The environment of processes running in a "chroot". This includes resources such as the part of the file system which is visible, user and group IDs which are available, network interfaces and other IPC mechanisms, etc. man:jail[8] (command):: The system administration utility which allows launching of processes within a jail environment. host (system, process, user, etc.):: The controlling system of a jail environment. The host system has access to all the hardware resources available, and can control processes both outside of and inside a jail environment. One of the important differences of the host system from a jail is that the limitations which apply to superuser processes inside a jail are not enforced for processes of the host system. hosted (system, process, user, etc.):: A process, user or other entity, whose access to resources is restricted by a FreeBSD jail. [[jails-build]] == Creating and Controlling Jails Some administrators divide jails into the following two types: "complete" jails, which resemble a real FreeBSD system, and "service" jails, dedicated to one application or service, possibly running with privileges. This is only a conceptual division and the process of building a jail is not affected by it. When creating a "complete" jail there are two options for the source of the userland: use prebuilt binaries (such as those supplied on an install media) or build from source. === Installing a Jail [[jails-install-internet]] ==== To install a Jail from the Internet The man:bsdinstall[8] tool can be used to fetch and install the binaries needed for a jail. This will walk through the picking of a mirror, which distributions will be installed into the destination directory, and some basic configuration of the jail: [source,shell] .... # bsdinstall jail /here/is/the/jail .... Once the command is complete, the next step is configuring the host to run the jail. [[jails-install-iso]] ==== To install a Jail from an ISO To install the userland from installation media, first create the root directory for the jail. This can be done by setting the `DESTDIR` variable to the proper location. Start a shell and define `DESTDIR`: [source,shell] .... # sh # export DESTDIR=/here/is/the/jail .... Mount the install media as covered in man:mdconfig[8] when using the install ISO: [source,shell] .... # mount -t cd9660 /dev/`mdconfig -f cdimage.iso` /mnt # cd /mnt/usr/freebsd-dist/ .... Extract the binaries from the tarballs on the install media into the declared destination. Minimally, only the base set needs to be extracted, but a complete install can be performed when preferred. To install just the base system: [source,shell] .... # tar -xf base.txz -C $DESTDIR .... To install everything except the kernel: [source,shell] .... # for set in base ports; do tar -xf $set.txz -C $DESTDIR ; done .... [[jails-install-source]] ==== To build and install a Jail from source The man:jail[8] manual page explains the procedure for building a jail: [source,shell] .... # setenv D /here/is/the/jail # mkdir -p $D <.> # cd /usr/src # make buildworld <.> # make installworld DESTDIR=$D <.> # make distribution DESTDIR=$D <.> # mount -t devfs devfs $D/dev <.> .... <.> Selecting a location for a jail is the best starting point. This is where the jail will physically reside within the file system of the jail's host. A good choice can be [.filename]#/usr/jail/jailname#, where _jailname_ is the hostname identifying the jail. Usually, [.filename]#/usr/# has enough space for the jail file system, which for "complete" jails is, essentially, a replication of every file present in a default installation of the FreeBSD base system. <.> If you have already rebuilt your userland using `make world` or `make buildworld`, you can skip this step and install your existing userland into the new jail. <.> This command will populate the directory subtree chosen as jail's physical location on the file system with the necessary binaries, libraries, manual pages and so on. <.> The `distribution` target for make installs every needed configuration file. In simple words, it installs every installable file of [.filename]#/usr/src/etc/# to the [.filename]#/etc# directory of the jail environment: [.filename]#$D/etc/#. <.> Mounting the man:devfs[8] file system inside a jail is not required. On the other hand, any, or almost any application requires access to at least one device, depending on the purpose of the given application. It is very important to control access to devices from inside a jail, as improper settings could permit an attacker to do nasty things in the jail. Control over man:devfs[8] is managed through rulesets which are described in the man:devfs[8] and man:devfs.conf[5] manual pages. === Configuring the Host Once a jail is installed, it can be started by using the man:jail[8] utility. The man:jail[8] utility takes four mandatory arguments which are described in the <>. Other arguments may be specified too, e.g., to run the jailed process with the credentials of a specific user. The `_command_` argument depends on the type of the jail; for a _virtual system_, [.filename]#/etc/rc# is a good choice, since it will replicate the startup sequence of a real FreeBSD system. For a _service_ jail, it depends on the service or application that will run within the jail. Jails are often started at boot time and the FreeBSD [.filename]#rc# mechanism provides an easy way to do this. [.procedure] * Configure jail parameters in [.filename]#jail.conf#: + [.programlisting] .... www { host.hostname = www.example.org; # Hostname ip4.addr = 192.168.0.10; # IP address of the jail path = "/usr/jail/www"; # Path to the jail mount.devfs; # Mount devfs inside the jail exec.start = "/bin/sh /etc/rc"; # Start command exec.stop = "/bin/sh /etc/rc.shutdown"; # Stop command } .... + Configure jails to start at boot time in [.filename]#rc.conf#: + [.programlisting] .... jail_enable="YES" # Set to NO to disable starting of any jails .... + The default startup of jails configured in man:jail.conf[5], will run the [.filename]#/etc/rc# script of the jail, which assumes the jail is a complete virtual system. For service jails, the default startup command of the jail should be changed, by setting the `exec.start` option appropriately. + [NOTE] ==== For a full list of available options, please see the man:jail.conf[5] manual page. ==== man:service[8] can be used to start or stop a jail by hand, if an entry for it exists in [.filename]#jail.conf#: [source,shell] .... # service jail start www # service jail stop www .... Jails can be shut down with man:jexec[8]. Use man:jls[8] to identify the jail's `JID`, then use man:jexec[8] to run the shutdown script in that jail. [source,shell] .... # jls JID IP Address Hostname Path 3 192.168.0.10 www /usr/jail/www # jexec 3 /etc/rc.shutdown .... More information about this can be found in the man:jail[8] manual page. [[jails-tuning]] == Fine Tuning and Administration There are several options which can be set for any jail, and various ways of combining a host FreeBSD system with jails, to produce higher level applications. This section presents: * Some of the options available for tuning the behavior and security restrictions implemented by a jail installation. * Some of the high-level applications for jail management, which are available through the FreeBSD Ports Collection, and can be used to implement overall jail-based solutions. [[jails-tuning-utilities]] === System Tools for Jail Tuning in FreeBSD Fine tuning of a jail's configuration is mostly done by setting man:sysctl[8] variables. A special subtree of sysctl exists as a basis for organizing all the relevant options: the `security.jail.*` hierarchy of FreeBSD kernel options. Here is a list of the main jail-related sysctls, complete with their default value. Names should be self-explanatory, but for more information about them, please refer to the man:jail[8] and man:sysctl[8] manual pages. * `security.jail.set_hostname_allowed: 1` * `security.jail.socket_unixiproute_only: 1` * `security.jail.sysvipc_allowed: 0` * `security.jail.enforce_statfs: 2` * `security.jail.allow_raw_sockets: 0` * `security.jail.chflags_allowed: 0` * `security.jail.jailed: 0` These variables can be used by the system administrator of the _host system_ to add or remove some of the limitations imposed by default on the `root` user. Note that there are some limitations which cannot be removed. The `root` user is not allowed to mount or unmount file systems from within a man:jail[8]. The `root` inside a jail may not load or unload man:devfs[8] rulesets, set firewall rules, or do many other administrative tasks which require modifications of in-kernel data, such as setting the `securelevel` of the kernel. The base system of FreeBSD contains a basic set of tools for viewing information about the active jails, and attaching to a jail to run administrative commands. The man:jls[8] and man:jexec[8] commands are part of the base FreeBSD system, and can be used to perform the following simple tasks: * Print a list of active jails and their corresponding jail identifier (JID), IP address, hostname and path. * Attach to a running jail, from its host system, and run a command inside the jail or perform administrative tasks inside the jail itself. This is especially useful when the `root` user wants to cleanly shut down a jail. The man:jexec[8] utility can also be used to start a shell in a jail to do administration in it; for example: + [source,shell] .... # jexec 1 tcsh .... [[jails-tuning-admintools]] === High-Level Administrative Tools in the FreeBSD Ports Collection Among the many third-party utilities for jail administration, one of the most complete and useful is package:sysutils/ezjail[]. It is a set of scripts that contribute to man:jail[8] management. Please refer to <> for more information. [[jails-updating]] === Keeping Jails Patched and up to Date Jails should be kept up to date from the host operating system as attempting to patch userland from within the jail may likely fail as the default behavior in FreeBSD is to disallow the use of man:chflags[1] in a jail which prevents the replacement of some files. It is possible to change this behavior but it is recommended to use man:freebsd-update[8] to maintain jails instead. Use `-b` to specify the path of the jail to be updated. To update the jail to the latest patch release of the version of FreeBSD it is already running, then execute the following commands on the host: [source,shell] .... # freebsd-update -b /here/is/the/jail fetch # freebsd-update -b /here/is/the/jail install .... To upgrade the jail to a new major or minor version, first upgrade the host system as described in crossref:cutting-edge[freebsdupdate-upgrade,“Performing Major and Minor Version Upgrades”]. Once the host has been upgraded and rebooted, the jail can then be upgraded. -For example to upgrade from 12.0-RELEASE to 12.1-RELEASE, on the host run: +For example to upgrade from 12.2-RELEASE to 12.3-RELEASE, on the host run: [source,shell] .... -# freebsd-update -b /here/is/the/jail --currently-running 12.0-RELEASE -r 12.1-RELEASE upgrade +# freebsd-update -b /here/is/the/jail --currently-running 12.2-RELEASE -r 12.3-RELEASE upgrade # freebsd-update -b /here/is/the/jail install # service jail restart myjail # freebsd-update -b /here/is/the/jail install .... Then, if it was a major version upgrade, reinstall all installed packages and restart the jail again. This is required because the ABI version changes when upgrading between major versions of FreeBSD. From the host: [source,shell] .... # pkg -j myjail upgrade -f # service jail restart myjail .... [[jails-application]] == Updating Multiple Jails The management of multiple jails can become problematic because every jail has to be rebuilt from scratch whenever it is upgraded. This can be time consuming and tedious if a lot of jails are created and manually updated. This section demonstrates one method to resolve this issue by safely sharing as much as is possible between jails using read-only man:mount_nullfs[8] mounts, so that updating is simpler. This makes it more attractive to put single services, such as HTTP, DNS, and SMTP, into individual jails. Additionally, it provides a simple way to add, remove, and upgrade jails. [NOTE] ==== Simpler solutions exist, such as ezjail, which provides an easier method of administering FreeBSD jails but is less versatile than this setup. ezjail is covered in more detail in <>. ==== The goals of the setup described in this section are: * Create a simple and easy to understand jail structure that does not require running a full installworld on each and every jail. * Make it easy to add new jails or remove existing ones. * Make it easy to update or upgrade existing jails. * Make it possible to run a customized FreeBSD branch. * Be paranoid about security, reducing as much as possible the possibility of compromise. * Save space and inodes, as much as possible. This design relies on a single, read-only master template which is mounted into each jail and one read-write device per jail. A device can be a separate physical disc, a partition, or a vnode backed memory device. This example uses read-write nullfs mounts. The file system layout is as follows: * The jails are based under the [.filename]#/home# partition. * Each jail will be mounted under the [.filename]#/home/j# directory. * The template for each jail and the read-only partition for all of the jails is [.filename]#/home/j/mroot#. * A blank directory will be created for each jail under the [.filename]#/home/j# directory. * Each jail will have a [.filename]#/s# directory that will be linked to the read-write portion of the system. * Each jail will have its own read-write system that is based upon [.filename]#/home/j/skel#. * The read-write portion of each jail will be created in [.filename]#/home/js#. [[jails-service-jails-template]] === Creating the Template This section describes the steps needed to create the master template. It is recommended to first update the host FreeBSD system to the latest -RELEASE branch using the instructions in crossref:cutting-edge[makeworld,“Updating FreeBSD from Source”]. Additionally, this template uses the package:sysutils/cpdup[] package or port and link:{handbook}mirrors/#git[Git] will be used to download the FreeBSD Ports Collection. [.procedure] . First, create a directory structure for the read-only file system which will contain the FreeBSD binaries for the jails. Then, change directory to the FreeBSD source tree and install the read-only file system to the jail template: + [source,shell] .... # mkdir /home/j /home/j/mroot # cd /usr/src # make installworld DESTDIR=/home/j/mroot .... . Next, prepare a FreeBSD Ports Collection for the jails as well as a FreeBSD source tree, which is required for mergemaster: + [source,shell] .... # cd /home/j/mroot # mkdir usr/ports # git clone -o freebsd https://git.FreeBSD.org/ports.git /home/j/mroot/usr/ports # cpdup /usr/src /home/j/mroot/usr/src .... . Create a skeleton for the read-write portion of the system: + [source,shell] .... # mkdir /home/j/skel /home/j/skel/home /home/j/skel/usr-X11R6 /home/j/skel/distfiles # mv etc /home/j/skel # mv usr/local /home/j/skel/usr-local # mv tmp /home/j/skel # mv var /home/j/skel # mv root /home/j/skel .... . Use mergemaster to install missing configuration files. Then, remove the extra directories that mergemaster creates: + [source,shell] .... # mergemaster -t /home/j/skel/var/tmp/temproot -D /home/j/skel -i # cd /home/j/skel # rm -R bin boot lib libexec mnt proc rescue sbin sys usr dev .... . Now, symlink the read-write file system to the read-only file system. Ensure that the symlinks are created in the correct [.filename]#s/# locations as the creation of directories in the wrong locations will cause the installation to fail. + [source,shell] .... # cd /home/j/mroot # mkdir s # ln -s s/etc etc # ln -s s/home home # ln -s s/root root # ln -s ../s/usr-local usr/local # ln -s ../s/usr-X11R6 usr/X11R6 # ln -s ../../s/distfiles usr/ports/distfiles # ln -s s/tmp tmp # ln -s s/var var .... . As a last step, create a generic [.filename]#/home/j/skel/etc/make.conf# containing this line: + [.programlisting] .... WRKDIRPREFIX?= /s/portbuild .... + This makes it possible to compile FreeBSD ports inside each jail. Remember that the ports directory is part of the read-only system. The custom path for `WRKDIRPREFIX` allows builds to be done in the read-write portion of every jail. [[jails-service-jails-creating]] === Creating Jails The jail template can now be used to setup and configure the jails in [.filename]#/etc/rc.conf#. This example demonstrates the creation of 3 jails: `NS`, `MAIL` and `WWW`. [.procedure] . Add the following lines to [.filename]#/etc/fstab#, so that the read-only template for the jails and the read-write space will be available in the respective jails: + [.programlisting] .... /home/j/mroot /home/j/ns nullfs ro 0 0 /home/j/mroot /home/j/mail nullfs ro 0 0 /home/j/mroot /home/j/www nullfs ro 0 0 /home/js/ns /home/j/ns/s nullfs rw 0 0 /home/js/mail /home/j/mail/s nullfs rw 0 0 /home/js/www /home/j/www/s nullfs rw 0 0 .... + To prevent fsck from checking nullfs mounts during boot and dump from backing up the read-only nullfs mounts of the jails, the last two columns are both set to `0`. . Configure the jails in [.filename]#/etc/rc.conf#: + [.programlisting] .... jail_enable="YES" jail_set_hostname_allow="NO" jail_list="ns mail www" jail_ns_hostname="ns.example.org" jail_ns_ip="192.168.3.17" jail_ns_rootdir="/usr/home/j/ns" jail_ns_devfs_enable="YES" jail_mail_hostname="mail.example.org" jail_mail_ip="192.168.3.18" jail_mail_rootdir="/usr/home/j/mail" jail_mail_devfs_enable="YES" jail_www_hostname="www.example.org" jail_www_ip="62.123.43.14" jail_www_rootdir="/usr/home/j/www" jail_www_devfs_enable="YES" .... + The `jail__name__rootdir` variable is set to [.filename]#/usr/home# instead of [.filename]#/home# because the physical path of [.filename]#/home# on a default FreeBSD installation is [.filename]#/usr/home#. The `jail__name__rootdir` variable must _not_ be set to a path which includes a symbolic link, otherwise the jails will refuse to start. . Create the required mount points for the read-only file system of each jail: + [source,shell] .... # mkdir /home/j/ns /home/j/mail /home/j/www .... . Install the read-write template into each jail using package:sysutils/cpdup[]: + [source,shell] .... # mkdir /home/js # cpdup /home/j/skel /home/js/ns # cpdup /home/j/skel /home/js/mail # cpdup /home/j/skel /home/js/www .... . In this phase, the jails are built and prepared to run. First, mount the required file systems for each jail, and then start them: + [source,shell] .... # mount -a # service jail start .... The jails should be running now. To check if they have started correctly, use `jls`. Its output should be similar to the following: [source,shell] .... # jls JID IP Address Hostname Path 3 192.168.3.17 ns.example.org /home/j/ns 2 192.168.3.18 mail.example.org /home/j/mail 1 62.123.43.14 www.example.org /home/j/www .... At this point, it should be possible to log onto each jail, add new users, or configure daemons. The `JID` column indicates the jail identification number of each running jail. Use the following command to perform administrative tasks in the jail whose JID is `3`: [source,shell] .... # jexec 3 tcsh .... [[jails-service-jails-upgrading]] === Upgrading The design of this setup provides an easy way to upgrade existing jails while minimizing their downtime. Also, it provides a way to roll back to the older version should a problem occur. [.procedure] . The first step is to upgrade the host system. Then, create a new temporary read-only template in [.filename]#/home/j/mroot2#. + [source,shell] .... # mkdir /home/j/mroot2 # cd /usr/src # make installworld DESTDIR=/home/j/mroot2 # cd /home/j/mroot2 # cpdup /usr/src usr/src # mkdir s .... + The `installworld` creates a few unnecessary directories, which should be removed: + [source,shell] .... # chflags -R 0 var # rm -R etc var root usr/local tmp .... . Recreate the read-write symlinks for the master file system: + [source,shell] .... # ln -s s/etc etc # ln -s s/root root # ln -s s/home home # ln -s ../s/usr-local usr/local # ln -s ../s/usr-X11R6 usr/X11R6 # ln -s s/tmp tmp # ln -s s/var var .... . Next, stop the jails: + [source,shell] .... # service jail stop .... . Unmount the original file systems as the read-write systems are attached to the read-only system ([.filename]#/s#): + [source,shell] .... # umount /home/j/ns/s # umount /home/j/ns # umount /home/j/mail/s # umount /home/j/mail # umount /home/j/www/s # umount /home/j/www .... . Move the old read-only file system and replace it with the new one. This will serve as a backup and archive of the old read-only file system should something go wrong. The naming convention used here corresponds to when a new read-only file system has been created. Move the original FreeBSD Ports Collection over to the new file system to save some space and inodes: + [source,shell] .... # cd /home/j # mv mroot mroot.20060601 # mv mroot2 mroot # mv mroot.20060601/usr/ports mroot/usr .... . At this point the new read-only template is ready, so the only remaining task is to remount the file systems and start the jails: + [source,shell] .... # mount -a # service jail start .... Use `jls` to check if the jails started correctly. Run `mergemaster` in each jail to update the configuration files. [[jails-ezjail]] == Managing Jails with ezjail Creating and managing multiple jails can quickly become tedious and error-prone. Dirk Engling's ezjail automates and greatly simplifies many jail tasks. A _basejail_ is created as a template. Additional jails use man:mount_nullfs[8] to share many of the basejail directories without using additional disk space. Each additional jail takes only a few megabytes of disk space before applications are installed. Upgrading the copy of the userland in the basejail automatically upgrades all of the other jails. Additional benefits and features are described in detail on the ezjail web site, https://erdgeist.org/arts/software/ezjail/[]. [[jails-ezjail-install]] === Installing ezjail Installing ezjail consists of adding a loopback interface for use in jails, installing the port or package, and enabling the service. [[jails-ezjail-install-procedure]] [.procedure] . To keep jail loopback traffic off the host's loopback network interface `lo0`, a second loopback interface is created by adding an entry to [.filename]#/etc/rc.conf#: + [.programlisting] .... cloned_interfaces="lo1" .... + The second loopback interface `lo1` will be created when the system starts. It can also be created manually without a restart: + [source,shell] .... # service netif cloneup Created clone interfaces: lo1. .... + Jails can be allowed to use aliases of this secondary loopback interface without interfering with the host. + Inside a jail, access to the loopback address `127.0.0.1` is redirected to the first IP address assigned to the jail. To make the jail loopback correspond with the new `lo1` interface, that interface must be specified first in the list of interfaces and IP addresses given when creating a new jail. + Give each jail a unique loopback address in the `127.0.0.0/8` netblock. . Install package:sysutils/ezjail[]: + [source,shell] .... # cd /usr/ports/sysutils/ezjail # make install clean .... . Enable ezjail by adding this line to [.filename]#/etc/rc.conf#: + [.programlisting] .... ezjail_enable="YES" .... . The service will automatically start on system boot. It can be started immediately for the current session: + [source,shell] .... # service ezjail start .... [[jails-ezjail-initialsetup]] === Initial Setup With ezjail installed, the basejail directory structure can be created and populated. This step is only needed once on the jail host computer. In both of these examples, `-p` causes the ports tree to be retrieved with man:portsnap[8] into the basejail. That single copy of the ports directory will be shared by all the jails. Using a separate copy of the ports directory for jails isolates them from the host. The ezjailFAQ explains in more detail: http://erdgeist.org/arts/software/ezjail/#FAQ[]. [[jails-ezjail-initialsetup-procedure]] [.procedure] . To Populate the Jail with FreeBSD-RELEASE + For a basejail based on the FreeBSD RELEASE matching that of the host computer, use `install`. -For example, on a host computer running FreeBSD 10-STABLE, the latest RELEASE version of FreeBSD -10 will be installed in the jail): +For example, on a host computer running FreeBSD 13-STABLE, the latest RELEASE version of FreeBSD 13 will be installed in the jail) + [source,shell] .... # ezjail-admin install -p .... . To Populate the Jail with `installworld` + The basejail can be installed from binaries created by `buildworld` on the host with `ezjail-admin update`. + In this example, FreeBSD 10-STABLE has been built from source. The jail directories are created. Then `installworld` is executed, installing the host's [.filename]#/usr/obj# into the basejail. + [source,shell] .... # ezjail-admin update -i -p .... + The host's [.filename]#/usr/src# is used by default. A different source directory on the host can be specified with `-s` and a path, or set with `ezjail_sourcetree` in [.filename]#/usr/local/etc/ezjail.conf#. [TIP] ==== The basejail's ports tree is shared by other jails. However, downloaded distfiles are stored in the jail that downloaded them. By default, these files are stored in [.filename]#/var/ports/distfiles# within each jail. [.filename]#/var/ports# inside each jail is also used as a work directory when building ports. ==== [TIP] ==== The FTP protocol is used by default to download packages for the installation of the basejail. Firewall or proxy configurations can prevent or interfere with FTP transfers. The HTTP protocol works differently and avoids these problems. It can be chosen by specifying a full URL for a particular download mirror in [.filename]#/usr/local/etc/ezjail.conf#: [.programlisting] .... ezjail_ftphost=http://ftp.FreeBSD.org .... See the crossref:mirrors[mirrors,mirrors] section for a list of sites. ==== [[jails-ezjail-create]] === Creating and Starting a New Jail New jails are created with `ezjail-admin create`. In these examples, the `lo1` loopback interface is used as described above. [[jails-ezjail-create-steps]] [.procedure] .Procedure: Create and Start a New Jail . Create the jail, specifying a name and the loopback and network interfaces to use, along with their IP addresses. In this example, the jail is named `dnsjail`. + [source,shell] .... # ezjail-admin create dnsjail 'lo1|127.0.1.1,em0|192.168.1.50' .... + [TIP] ==== Most network services run in jails without problems. A few network services, most notably man:ping[8], use _raw network sockets_. In jails, raw network sockets are disabled by default for security. Services that require them will not work. Occasionally, a jail genuinely needs raw sockets. For example, network monitoring applications often use man:ping[8] to check the availability of other computers. When raw network sockets are actually needed in a jail, they can be enabled by editing the ezjail configuration file for the individual jail, [.filename]#/usr/local/etc/ezjail/jailname#. Modify the `parameters` entry: [.programlisting] .... export jail_jailname_parameters="allow.raw_sockets=1" .... Do not enable raw network sockets unless services in the jail actually require them. ==== . Start the jail: + [source,shell] .... # ezjail-admin start dnsjail .... . Use a console on the jail: + [source,shell] .... # ezjail-admin console dnsjail .... The jail is operating and additional configuration can be completed. Typical settings added at this point include: [.procedure] . Set the `root` Password + Connect to the jail and set the `root` user's password: + [source,shell] .... # ezjail-admin console dnsjail # passwd Changing local password for root New Password: Retype New Password: .... . Time Zone Configuration + The jail's time zone can be set with man:tzsetup[8]. To avoid spurious error messages, the man:adjkerntz[8] entry in [.filename]#/etc/crontab# can be commented or removed. This job attempts to update the computer's hardware clock with time zone changes, but jails are not allowed to access that hardware. . DNS Servers + Enter domain name server lines in [.filename]#/etc/resolv.conf# so DNS works in the jail. . Edit [.filename]#/etc/hosts# + Change the address and add the jail name to the `localhost` entries in [.filename]#/etc/hosts#. . Configure [.filename]#/etc/rc.conf# + Enter configuration settings in [.filename]#/etc/rc.conf#. This is much like configuring a full computer. The host name and IP address are not set here. Those values are already provided by the jail configuration. With the jail configured, the applications for which the jail was created can be installed. [TIP] ==== Some ports must be built with special options to be used in a jail. For example, both of the network monitoring plugin packages package:net-mgmt/nagios-plugins[] and package:net-mgmt/monitoring-plugins[] have a `JAIL` option which must be enabled for them to work correctly inside a jail. ==== [[jails-ezjail-update]] === Updating Jails [[jails-ezjail-update-os]] ==== Updating the Operating System Because the basejail's copy of the userland is shared by the other jails, updating the basejail automatically updates all of the other jails. Either source or binary updates can be used. To build the world from source on the host, then install it in the basejail, use: [source,shell] .... # ezjail-admin update -b .... If the world has already been compiled on the host, install it in the basejail with: [source,shell] .... # ezjail-admin update -i .... Binary updates use man:freebsd-update[8]. These updates have the same limitations as if man:freebsd-update[8] were being run directly. The most important one is that only -RELEASE versions of FreeBSD are available with this method. Update the basejail to the latest patched release of the version of FreeBSD on the host. For example, updating from RELEASE-p1 to RELEASE-p2. [source,shell] .... # ezjail-admin update -u .... To upgrade the basejail to a new version, first upgrade the host system as described in crossref:cutting-edge[freebsdupdate-upgrade,“Performing Major and Minor Version Upgrades”]. Once the host has been upgraded and rebooted, the basejail can then be upgraded. man:freebsd-update[8] has no way of determining which version is currently installed in the basejail, so the original version must be specified. Use man:file[1] to determine the original version in the basejail: [source,shell] .... # file /usr/jails/basejail/bin/sh -/usr/jails/basejail/bin/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.3, stripped +/usr/jails/basejail/bin/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.0, FreeBSD-style, stripped .... -Now use this information to perform the upgrade from `9.3-RELEASE` to the current version of the host system: +Now use this information to perform the upgrade from `13.0-RELEASE` to the current version of the host system: [source,shell] .... -# ezjail-admin update -U -s 9.3-RELEASE +# ezjail-admin update -U -s 13.0-RELEASE .... After updating the basejail, man:mergemaster[8] must be run to update each jail's configuration files. How to use man:mergemaster[8] depends on the purpose and trustworthiness of a jail. If a jail's services or users are not trusted, then man:mergemaster[8] should only be run from within that jail: [[jails-ezjail-update-mergemaster-untrusted]] .man:mergemaster[8] on Untrusted Jail [example] ==== Delete the link from the jail's [.filename]#/usr/src# into the basejail and create a new [.filename]#/usr/src# in the jail as a mountpoint. Mount the host computer's [.filename]#/usr/src# read-only on the jail's new [.filename]#/usr/src# mountpoint: [source,shell] .... # rm /usr/jails/jailname/usr/src # mkdir /usr/jails/jailname/usr/src # mount -t nullfs -o ro /usr/src /usr/jails/jailname/usr/src .... Get a console in the jail: [source,shell] .... # ezjail-admin console jailname .... Inside the jail, run `mergemaster`. Then exit the jail console: [source,shell] .... # cd /usr/src # mergemaster -U # exit .... Finally, unmount the jail's [.filename]#/usr/src#: [source,shell] .... # umount /usr/jails/jailname/usr/src .... ==== [[jails-ezjail-update-mergemaster-trusted]] .man:mergemaster[8] on Trusted Jail [example] ==== If the users and services in a jail are trusted, man:mergemaster[8] can be run from the host: [source,shell] .... # mergemaster -U -D /usr/jails/jailname .... ==== [TIP] ==== After a major version update it is recommended by package:sysutils/ezjail[] to make sure your `pkg` is of the correct version. Therefore enter: [source,shell] .... # pkg-static upgrade -f pkg .... to upgrade or downgrade to the appropriate version. ==== [[jails-ezjail-update-ports]] ==== Updating Ports The ports tree in the basejail is shared by the other jails. Updating that copy of the ports tree gives the other jails the updated version also. The basejail ports tree is updated with man:portsnap[8]: [source,shell] .... # ezjail-admin update -P .... [[jails-ezjail-control]] === Controlling Jails [[jails-ezjail-control-stop-start]] ==== Stopping and Starting Jails ezjail automatically starts jails when the computer is started. Jails can be manually stopped and restarted with `stop` and `start`: [source,shell] .... # ezjail-admin stop sambajail Stopping jails: sambajail. .... By default, jails are started automatically when the host computer starts. Autostarting can be disabled with `config`: [source,shell] .... # ezjail-admin config -r norun seldomjail .... This takes effect the next time the host computer is started. A jail that is already running will not be stopped. Enabling autostart is very similar: [source,shell] .... # ezjail-admin config -r run oftenjail .... [[jails-ezjail-control-backup]] ==== Archiving and Restoring Jails Use `archive` to create a [.filename]#.tar.gz# archive of a jail. The file name is composed from the name of the jail and the current date. Archive files are written to the archive directory, [.filename]#/usr/jails/ezjail_archives#. A different archive directory can be chosen by setting `ezjail_archivedir` in the configuration file. The archive file can be copied elsewhere as a backup, or an existing jail can be restored from it with `restore`. A new jail can be created from the archive, providing a convenient way to clone existing jails. Stop and archive a jail named `wwwserver`: [source,shell] .... # ezjail-admin stop wwwserver Stopping jails: wwwserver. # ezjail-admin archive wwwserver # ls /usr/jails/ezjail-archives/ wwwserver-201407271153.13.tar.gz .... Create a new jail named `wwwserver-clone` from the archive created in the previous step. Use the [.filename]#em1# interface and assign a new IP address to avoid conflict with the original: [source,shell] .... # ezjail-admin create -a /usr/jails/ezjail_archives/wwwserver-201407271153.13.tar.gz wwwserver-clone 'lo1|127.0.3.1,em1|192.168.1.51' .... [[jails-ezjail-example-bind]] === Full Example: BIND in a Jail Putting the BINDDNS server in a jail improves security by isolating it. This example creates a simple caching-only name server. * The jail will be called `dns1`. * The jail will use IP address `192.168.1.240` on the host's `re0` interface. * The upstream ISP's DNS servers are at `10.0.0.62` and `10.0.0.61`. * The basejail has already been created and a ports tree installed as shown in <>. [[jails-ezjail-example-bind-steps]] .Running BIND in a Jail [example] ==== Create a cloned loopback interface by adding a line to [.filename]#/etc/rc.conf#: [.programlisting] .... cloned_interfaces="lo1" .... Immediately create the new loopback interface: [source,shell] .... # service netif cloneup Created clone interfaces: lo1. .... Create the jail: [source,shell] .... # ezjail-admin create dns1 'lo1|127.0.2.1,re0|192.168.1.240' .... Start the jail, connect to a console running on it, and perform some basic configuration: [source,shell] .... # ezjail-admin start dns1 # ezjail-admin console dns1 # passwd Changing local password for root New Password: Retype New Password: # tzsetup # sed -i .bak -e '/adjkerntz/ s/^/#/' /etc/crontab # sed -i .bak -e 's/127.0.0.1/127.0.2.1/g; s/localhost.my.domain/dns1.my.domain dns1/' /etc/hosts .... Temporarily set the upstream DNS servers in [.filename]#/etc/resolv.conf# so ports can be downloaded: [.programlisting] .... nameserver 10.0.0.62 nameserver 10.0.0.61 .... Still using the jail console, install package:dns/bind99[]. [source,shell] .... # make -C /usr/ports/dns/bind99 install clean .... Configure the name server by editing [.filename]#/usr/local/etc/namedb/named.conf#. Create an Access Control List (ACL) of addresses and networks that are permitted to send DNS queries to this name server. This section is added just before the `options` section already in the file: [.programlisting] .... ... // or cause huge amounts of useless Internet traffic. acl "trusted" { 192.168.1.0/24; localhost; localnets; }; options { ... .... Use the jail IP address in the `listen-on` setting to accept DNS queries from other computers on the network: [.programlisting] .... listen-on { 192.168.1.240; }; .... A simple caching-only DNS name server is created by changing the `forwarders` section. The original file contains: [.programlisting] .... /* forwarders { 127.0.0.1; }; */ .... Uncomment the section by removing the `/\*` and `*/` lines. Enter the IP addresses of the upstream DNS servers. Immediately after the `forwarders` section, add references to the `trusted` ACL defined earlier: [.programlisting] .... forwarders { 10.0.0.62; 10.0.0.61; }; allow-query { any; }; allow-recursion { trusted; }; allow-query-cache { trusted; }; .... Enable the service in [.filename]#/etc/rc.conf#: [.programlisting] .... named_enable="YES" .... Start and test the name server: [source,shell] .... # service named start wrote key file "/usr/local/etc/namedb/rndc.key" Starting named. # /usr/local/bin/dig @192.168.1.240 freebsd.org .... A response that includes [source,shell] .... ;; Got answer; .... shows that the new DNS server is working. A long delay followed by a response including [source,shell] .... ;; connection timed out; no servers could be reached .... shows a problem. Check the configuration settings and make sure any local firewalls allow the new DNS access to the upstream DNS servers. The new DNS server can use itself for local name resolution, just like other local computers. Set the address of the DNS server in the client computer's [.filename]#/etc/resolv.conf#: [.programlisting] .... nameserver 192.168.1.240 .... A local DHCP server can be configured to provide this address for a local DNS server, providing automatic configuration on DHCP clients. ==== diff --git a/documentation/content/en/books/handbook/virtualization/_index.adoc b/documentation/content/en/books/handbook/virtualization/_index.adoc index 6d4067d786..f7ed3fab3e 100644 --- a/documentation/content/en/books/handbook/virtualization/_index.adoc +++ b/documentation/content/en/books/handbook/virtualization/_index.adoc @@ -1,1172 +1,1172 @@ --- title: Chapter 23. Virtualization part: Part III. System Administration prev: books/handbook/filesystems next: books/handbook/l10n description: Virtualization software allows multiple operating systems to run simultaneously on the same computer tags: ["virtualization", "Parallels", "VMware", "VirtualBox", "bhyve", "XEN"] showBookMenu: true weight: 27 path: "/books/handbook/" --- [[virtualization]] = Virtualization :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 23 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/virtualization/ 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::[] [[virtualization-synopsis]] == Synopsis Virtualization software allows multiple operating systems to run simultaneously on the same computer. Such software systems for PCs often involve a host operating system which runs the virtualization software and supports any number of guest operating systems. After reading this chapter, you will know: * The difference between a host operating system and a guest operating system. * How to install FreeBSD on the following virtualization platforms: ** Parallels Desktop(Intel(R)-based Apple(R) macOS(R)) ** VMware Fusion(Intel(R)-based Apple(R) macOS(R)) ** VirtualBox(TM)(Microsoft(R) Windows(R), Intel(R)-based Apple(R) macOS(R), Linux) ** bhyve(FreeBSD) * How to tune a FreeBSD system for best performance under virtualization. Before reading this chapter, you should: * Understand the crossref:basics[basics,basics of UNIX(R) and FreeBSD]. * Know how to crossref:bsdinstall[bsdinstall,install FreeBSD]. * Know how to crossref:advanced-networking[advanced-networking,set up a network connection]. * Know how to crossref:ports[ports,install additional third-party software]. [[virtualization-guest-parallelsdesktop]] == FreeBSD as a Guest on Parallels Desktop for macOS(R) Parallels Desktop for Mac(R) is a commercial software product available for Intel(R) based Apple(R) Mac(R) computers running macOS(R) 10.4.6 or higher. FreeBSD is a fully supported guest operating system. Once Parallels has been installed on macOS(R), the user must configure a virtual machine and then install the desired guest operating system. [[virtualization-guest-parallelsdesktop-install]] === Installing FreeBSD on Parallels Desktop on Mac(R) The first step in installing FreeBSD on Parallels is to create a new virtual machine for installing FreeBSD. Select [.guimenuitem]#FreeBSD# as the menu:Guest OS Type[] when prompted: image::parallels-freebsd1.png[Parallels setup wizard showing FreeBSD as chosen OS] Choose a reasonable amount of disk and memory depending on the plans for this virtual FreeBSD instance. 4GB of disk space and 512MB of RAM work well for most uses of FreeBSD under Parallels: image::parallels-freebsd2.png[Parallels setup wizard showing the amount of RAM allocated] image::parallels-freebsd3.png[Parallels setup wizard showing the disk menu] image::parallels-freebsd4.png[Parallels setup wizard showing the menu for setting the disk size and type] image::parallels-freebsd5.png[Parallels setup wizard showing the menu for setting the disk location] Select the type of networking and a network interface: image::parallels-freebsd6.png[Parallels setup wizard showing the network menu] image::parallels-freebsd7.png[Parallels setup wizard showing the menu with the network type options] Save and finish the configuration: image::parallels-freebsd8.png[Parallels setup wizard showing the menu to configure the name of the machine and the directory where to save the configuration] image::parallels-freebsd9.png[Parallels setup wizard indicating that the configuration is complete and asking the user if he wants to start guest OS installation] After the FreeBSD virtual machine has been created, FreeBSD can be installed on it. This is best done with an official FreeBSD CD/DVD or with an ISO image downloaded from an official FTP site. Copy the appropriate ISO image to the local Mac(R) filesystem or insert a CD/DVD in the Mac(R)'s CD-ROM drive. Click on the disc icon in the bottom right corner of the FreeBSD Parallels window. This will bring up a window that can be used to associate the CD-ROM drive in the virtual machine with the ISO file on disk or with the real CD-ROM drive. image::parallels-freebsd11.png[Parallels showing a summary of the newly created machine with information and actions to execute on the machine] Once this association with the CD-ROM source has been made, reboot the FreeBSD virtual machine by clicking the reboot icon. Parallels will reboot with a special BIOS that first checks if there is a CD-ROM. image::parallels-freebsd10.png[Parallels showing the BIOS running] In this case it will find the FreeBSD installation media and begin a normal FreeBSD installation. Perform the installation, but do not attempt to configure Xorg at this time. image::parallels-freebsd12.png[Parallels showing a snippet of the FreeBSD installation process] When the installation is finished, reboot into the newly installed FreeBSD virtual machine. image::parallels-freebsd13.png[Parallels showing the boot of FreeBSD] [[virtualization-guest-parallels-configure]] === Configuring FreeBSD on Parallels After FreeBSD has been successfully installed on macOS(R) X with Parallels, there are a number of configuration steps that can be taken to optimize the system for virtualized operation. [.procedure] . Set Boot Loader Variables + The most important step is to reduce the `kern.hz` tunable to reduce the CPU utilization of FreeBSD under the Parallels environment. This is accomplished by adding the following line to [.filename]#/boot/loader.conf#: + [.programlisting] .... kern.hz=100 .... + Without this setting, an idle FreeBSD Parallels guest will use roughly 15% of the CPU of a single processor iMac(R). After this change the usage will be closer to 5%. . Create a New Kernel Configuration File + All of the SCSI, FireWire, and USB device drivers can be removed from a custom kernel configuration file. Parallels provides a virtual network adapter used by the man:ed[4] driver, so all network devices except for man:ed[4] and man:miibus[4] can be removed from the kernel. . Configure Networking + The most basic networking setup uses DHCP to connect the virtual machine to the same local area network as the host Mac(R). This can be accomplished by adding `ifconfig_ed0="DHCP"` to [.filename]#/etc/rc.conf#. More advanced networking setups are described in crossref:advanced-networking[advanced-networking,Advanced Networking]. [[virtualization-guest-vmware]] == FreeBSD as a Guest on VMware Fusion for macOS(R) VMware Fusion for Mac(R) is a commercial software product available for Intel(R) based Apple(R) Mac(R) computers running macOS(R) 10.11 or higher. FreeBSD is a fully supported guest operating system. Once VMware Fusion has been installed on macOS(R), the user can configure a virtual machine and then install the desired guest operating system. [[virtualization-guest-vmware-install]] === Installing FreeBSD on VMware Fusion The first step is to start VMware Fusion which will load the Virtual Machine Library. Click [.guimenuitem]#+->New# to create the virtual machine: image::vmware-freebsd01.png[width=35%] This will load the New Virtual Machine Assistant. Choose [.guimenuitem]#Create a custom virtual machine# and click [.guimenuitem]#Continue# to proceed: image::vmware-freebsd02.png[width=45%] Select [.guimenuitem]#Other# as the [.guimenuitem]#Operating System# and either [.guimenuitem]#FreeBSD X# or [.guimenuitem]#FreeBSD X 64-bit#, as the menu:Version[] when prompted: image::vmware-freebsd03.png[width=45%] Choose the firmware(UEFI is recommended): image::vmware-freebsd04.png[width=45%] Choose [.guimenuitem]#Create a new virtual disk# and click [.guimenuitem]#Continue#: image::vmware-freebsd05.png[width=45%] Check the configuration and click [.guimenuitem]#Finish#: image::vmware-freebsd06.png[width=45%] Choose the name of the virtual machine and the directory where it should be saved: image::vmware-freebsd07.png[width=45%] Press command+E to open virtual machine settings and click [.guimenuitem]#CD/DVD#: image::vmware-freebsd08.png[width=45%] Choose FreeBSD ISO image or from a CD/DVD: image::vmware-freebsd09.png[width=45%] Start the virtual machine: image::vmware-freebsd10.png[width=25%] Install FreeBSD as usual: image::vmware-freebsd11.png[width=25%] Once the install is complete, the settings of the virtual machine can be modified, such as memory usage and the number of CPUs the virtual machine will have access to: [NOTE] ==== The System Hardware settings of the virtual machine cannot be modified while the virtual machine is running. ==== image::vmware-freebsd12.png[width=45%] The status of the CD-ROM device. Normally the CD/DVD/ISO is disconnected from the virtual machine when it is no longer needed. image::vmware-freebsd09.png[width=45%] The last thing to change is how the virtual machine will connect to the network. To allow connections to the virtual machine from other machines besides the host, choose [.guimenuitem]#Connect directly to the physical network (Bridged)#. Otherwise, [.guimenuitem]#Share the host's internet connection (NAT)# is preferred so that the virtual machine can have access to the Internet, but the network cannot access the virtual machine. image::vmware-freebsd13.png[width=45%] After modifying the settings, boot the newly installed FreeBSD virtual machine. [[virtualization-guest-vmware-configure]] === Configuring FreeBSD on VMware Fusion After FreeBSD has been successfully installed on macOS(R) X with VMware Fusion, there are a number of configuration steps that can be taken to optimize the system for virtualized operation. [.procedure] . Set Boot Loader Variables + The most important step is to reduce the `kern.hz` tunable to reduce the CPU utilization of FreeBSD under the VMware Fusion environment. This is accomplished by adding the following line to [.filename]#/boot/loader.conf#: + [.programlisting] .... kern.hz=100 .... + Without this setting, an idle FreeBSD VMware Fusion guest will use roughly 15% of the CPU of a single processor iMac(R). After this change, the usage will be closer to 5%. . Create a New Kernel Configuration File + All of the FireWire, and USB device drivers can be removed from a custom kernel configuration file. VMware Fusion provides a virtual network adapter used by the man:em[4] driver, so all network devices except for man:em[4] can be removed from the kernel. . Configure Networking + The most basic networking setup uses DHCP to connect the virtual machine to the same local area network as the host Mac(R). This can be accomplished by adding `ifconfig_em0="DHCP"` to [.filename]#/etc/rc.conf#. More advanced networking setups are described in crossref:advanced-networking[advanced-networking,Advanced Networking]. + . Install drivers and open-vm-tools + To run FreeBSD smoothly on VMWare, drivers should be installed: + [source,shell] .... # pkg install xf86-video-vmware xf86-input-vmmouse open-vm-tools .... [[virtualization-guest-virtualbox]] == FreeBSD as a Guest on VirtualBox(TM) FreeBSD works well as a guest in VirtualBox(TM). The virtualization software is available for most common operating systems, including FreeBSD itself. The VirtualBox(TM) guest additions provide support for: * Clipboard sharing. * Mouse pointer integration. * Host time synchronization. * Window scaling. * Seamless mode. [NOTE] ==== These commands are run in the FreeBSD guest. ==== First, install the package:emulators/virtualbox-ose-additions[] package or port in the FreeBSD guest. This will install the port: [source,shell] .... # cd /usr/ports/emulators/virtualbox-ose-additions && make install clean .... Add these lines to [.filename]#/etc/rc.conf#: [.programlisting] .... vboxguest_enable="YES" vboxservice_enable="YES" .... If man:ntpd[8] or man:ntpdate[8] is used, disable host time synchronization: [.programlisting] .... vboxservice_flags="--disable-timesync" .... Xorg will automatically recognize the `vboxvideo` driver. It can also be manually entered in [.filename]#/etc/X11/xorg.conf#: [.programlisting] .... Section "Device" Identifier "Card0" Driver "vboxvideo" VendorName "InnoTek Systemberatung GmbH" BoardName "VirtualBox Graphics Adapter" EndSection .... To use the `vboxmouse` driver, adjust the mouse section in [.filename]#/etc/X11/xorg.conf#: [.programlisting] .... Section "InputDevice" Identifier "Mouse0" Driver "vboxmouse" EndSection .... HAL users should create the following [.filename]#/usr/local/etc/hal/fdi/policy/90-vboxguest.fdi# or copy it from [.filename]#/usr/local/share/hal/fdi/policy/10osvendor/90-vboxguest.fdi#: [.programlisting] .... input input.mouse vboxmouse /dev/vboxguest .... Shared folders for file transfers between host and VM are accessible by mounting them using `mount_vboxvfs`. A shared folder can be created on the host using the VirtualBox GUI or via `vboxmanage`. For example, to create a shared folder called _myshare_ under [.filename]#/mnt/bsdboxshare# for the VM named _BSDBox_, run: [source,shell] .... # vboxmanage sharedfolder add 'BSDBox' --name myshare --hostpath /mnt/bsdboxshare .... Note that the shared folder name must not contain spaces. Mount the shared folder from within the guest system like this: [source,shell] .... # mount_vboxvfs -w myshare /mnt .... [[virtualization-host-virtualbox]] == FreeBSD as a Host with VirtualBox(TM) VirtualBox(TM) is an actively developed, complete virtualization package, that is available for most operating systems including Windows(R), macOS(R), Linux(R) and FreeBSD. It is equally capable of running Windows(R) or UNIX(R)-like guests. It is released as open source software, but with closed-source components available in a separate extension pack. These components include support for USB 2.0 devices. More information may be found on the http://www.virtualbox.org/wiki/Downloads[Downloads page of the VirtualBox(TM) wiki]. Currently, these extensions are not available for FreeBSD. [[virtualization-virtualbox-install]] === Installing VirtualBox(TM) VirtualBox(TM) is available as a FreeBSD package or port in package:emulators/virtualbox-ose[]. The port can be installed using these commands: [source,shell] .... # cd /usr/ports/emulators/virtualbox-ose # make install clean .... One useful option in the port's configuration menu is the `GuestAdditions` suite of programs. These provide a number of useful features in guest operating systems, like mouse pointer integration (allowing the mouse to be shared between host and guest without the need to press a special keyboard shortcut to switch) and faster video rendering, especially in Windows(R) guests. The guest additions are available in the menu:Devices[] menu, after the installation of the guest is finished. A few configuration changes are needed before VirtualBox(TM) is started for the first time. The port installs a kernel module in [.filename]#/boot/modules# which must be loaded into the running kernel: [source,shell] .... # kldload vboxdrv .... To ensure the module is always loaded after a reboot, add this line to [.filename]#/boot/loader.conf#: [.programlisting] .... vboxdrv_load="YES" .... To use the kernel modules that allow bridged or host-only networking, add this line to [.filename]#/etc/rc.conf# and reboot the computer: [.programlisting] .... vboxnet_enable="YES" .... The `vboxusers` group is created during installation of VirtualBox(TM). All users that need access to VirtualBox(TM) will have to be added as members of this group. `pw` can be used to add new members: [source,shell] .... # pw groupmod vboxusers -m yourusername .... The default permissions for [.filename]#/dev/vboxnetctl# are restrictive and need to be changed for bridged networking: [source,shell] .... # chown root:vboxusers /dev/vboxnetctl # chmod 0660 /dev/vboxnetctl .... To make this permissions change permanent, add these lines to [.filename]#/etc/devfs.conf#: [.programlisting] .... own vboxnetctl root:vboxusers perm vboxnetctl 0660 .... To launch VirtualBox(TM), type from an Xorg session: [source,shell] .... % VirtualBox .... For more information on configuring and using VirtualBox(TM), refer to the http://www.virtualbox.org[official website]. For FreeBSD-specific information and troubleshooting instructions, refer to the http://wiki.FreeBSD.org/VirtualBox[relevant page in the FreeBSD wiki]. [[virtualization-virtualbox-usb-support]] === VirtualBox(TM) USB Support VirtualBox(TM) can be configured to pass USB devices through to the guest operating system. The host controller of the OSE version is limited to emulating USB 1.1 devices until the extension pack supporting USB 2.0 and 3.0 devices becomes available on FreeBSD. For VirtualBox(TM) to be aware of USB devices attached to the machine, the user needs to be a member of the `operator` group. [source,shell] .... # pw groupmod operator -m yourusername .... Then, add the following to [.filename]#/etc/devfs.rules#, or create this file if it does not exist yet: [.programlisting] .... [system=10] add path 'usb/*' mode 0660 group operator .... To load these new rules, add the following to [.filename]#/etc/rc.conf#: [.programlisting] .... devfs_system_ruleset="system" .... Then, restart devfs: [source,shell] .... # service devfs restart .... Restart the login session and VirtualBox(TM) for these changes to take effect, and create USB filters as necessary. [[virtualization-virtualbox-host-dvd-cd-access]] === VirtualBox(TM) Host DVD/CD Access Access to the host DVD/CD drives from guests is achieved through the sharing of the physical drives. Within VirtualBox(TM), this is set up from the Storage window in the Settings of the virtual machine. If needed, create an empty IDECD/DVD device first. Then choose the Host Drive from the popup menu for the virtual CD/DVD drive selection. A checkbox labeled `Passthrough` will appear. This allows the virtual machine to use the hardware directly. For example, audio CDs or the burner will only function if this option is selected. HAL needs to run for VirtualBox(TM)DVD/CD functions to work, so enable it in [.filename]#/etc/rc.conf# and start it if it is not already running: [.programlisting] .... hald_enable="YES" .... [source,shell] .... # service hald start .... In order for users to be able to use VirtualBox(TM)DVD/CD functions, they need access to [.filename]#/dev/xpt0#, [.filename]#/dev/cdN#, and [.filename]#/dev/passN#. This is usually achieved by making the user a member of `operator`. Permissions to these devices have to be corrected by adding these lines to [.filename]#/etc/devfs.conf#: [.programlisting] .... perm cd* 0660 perm xpt0 0660 perm pass* 0660 .... [source,shell] .... # service devfs restart .... [[virtualization-host-bhyve]] == FreeBSD as a Host with bhyve The bhyve BSD-licensed hypervisor became part of the base system with FreeBSD 10.0-RELEASE. This hypervisor supports a number of guests, including FreeBSD, OpenBSD, and many Linux(R) distributions. By default, bhyve provides access to serial console and does not emulate a graphical console. Virtualization offload features of newer CPUs are used to avoid the legacy methods of translating instructions and manually managing memory mappings. The bhyve design requires a processor that supports Intel(R) Extended Page Tables (EPT) or AMD(R) Rapid Virtualization Indexing (RVI) or Nested Page Tables (NPT). Hosting Linux(R) guests or FreeBSD guests with more than one vCPU requires VMX unrestricted mode support (UG). Most newer processors, specifically the Intel(R) Core(TM) i3/i5/i7 and Intel(R) Xeon(TM) E3/E5/E7, support these features. UG support was introduced with Intel's Westmere micro-architecture. For a complete list of Intel(R) processors that support EPT, refer to https://ark.intel.com/content/www/us/en/ark/search/featurefilter.html?productType=873&0_ExtendedPageTables=True[]. RVI is found on the third generation and later of the AMD Opteron(TM) (Barcelona) processors. The easiest way to tell if a processor supports bhyve is to run `dmesg` or look in [.filename]#/var/run/dmesg.boot# for the `POPCNT` processor feature flag on the `Features2` line for AMD(R) processors or `EPT` and `UG` on the `VT-x` line for Intel(R) processors. [[virtualization-bhyve-prep]] === Preparing the Host The first step to creating a virtual machine in bhyve is configuring the host system. First, load the bhyve kernel module: [source,shell] .... # kldload vmm .... Then, create a [.filename]#tap# interface for the network device in the virtual machine to attach to. In order for the network device to participate in the network, also create a bridge interface containing the [.filename]#tap# interface and the physical interface as members. In this example, the physical interface is _igb0_: [source,shell] .... # ifconfig tap0 create # sysctl net.link.tap.up_on_open=1 net.link.tap.up_on_open: 0 -> 1 # ifconfig bridge0 create # ifconfig bridge0 addm igb0 addm tap0 # ifconfig bridge0 up .... [[virtualization-bhyve-freebsd]] === Creating a FreeBSD Guest Create a file to use as the virtual disk for the guest machine. Specify the size and name of the virtual disk: [source,shell] .... # truncate -s 16G guest.img .... Download an installation image of FreeBSD to install: [source,shell] .... -# fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/12.2/FreeBSD-12.2-RELEASE-amd64-bootonly.iso -FreeBSD-12.2-RELEASE-amd64-bootonly.iso 100% of 230 MB 570 kBps 06m17s +# fetch https://download.freebsd.org/releases/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-amd64-bootonly.iso +FreeBSD-13.1-RELEASE-amd64-bootonly.iso 366 MB 16 MBps 22s .... FreeBSD comes with an example script for running a virtual machine in bhyve. The script will start the virtual machine and run it in a loop, so it will automatically restart if it crashes. The script takes a number of options to control the configuration of the machine: `-c` controls the number of virtual CPUs, `-m` limits the amount of memory available to the guest, `-t` defines which [.filename]#tap# device to use, `-d` indicates which disk image to use, `-i` tells bhyve to boot from the CD image instead of the disk, and `-I` defines which CD image to use. The last parameter is the name of the virtual machine, used to track the running machines. This example starts the virtual machine in installation mode: [source,shell] .... -# sh /usr/share/examples/bhyve/vmrun.sh -c 1 -m 1024M -t tap0 -d guest.img -i -I FreeBSD-12.2-RELEASE-amd64-bootonly.iso guestname +# sh /usr/share/examples/bhyve/vmrun.sh -c 1 -m 1024M -t tap0 -d guest.img -i -I FreeBSD-13.1-RELEASE-amd64-bootonly.iso guestname .... The virtual machine will boot and start the installer. After installing a system in the virtual machine, when the system asks about dropping in to a shell at the end of the installation, choose btn:[Yes]. Reboot the virtual machine. While rebooting the virtual machine causes bhyve to exit, the [.filename]#vmrun.sh# script runs `bhyve` in a loop and will automatically restart it. When this happens, choose the reboot option from the boot loader menu in order to escape the loop. Now the guest can be started from the virtual disk: [source,shell] .... # sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 1024M -t tap0 -d guest.img guestname .... [[virtualization-bhyve-linux]] === Creating a Linux(R) Guest In order to boot operating systems other than FreeBSD, the package:sysutils/grub2-bhyve[] port must be first installed. Next, create a file to use as the virtual disk for the guest machine: [source,shell] .... # truncate -s 16G linux.img .... Starting a virtual machine with bhyve is a two step process. First a kernel must be loaded, then the guest can be started. The Linux(R) kernel is loaded with package:sysutils/grub2-bhyve[]. Create a [.filename]#device.map# that grub will use to map the virtual devices to the files on the host system: [.programlisting] .... (hd0) ./linux.img (cd0) ./somelinux.iso .... Use package:sysutils/grub2-bhyve[] to load the Linux(R) kernel from the ISO image: [source,shell] .... # grub-bhyve -m device.map -r cd0 -M 1024M linuxguest .... This will start grub. If the installation CD contains a [.filename]#grub.cfg#, a menu will be displayed. If not, the `vmlinuz` and `initrd` files must be located and loaded manually: [source,shell] .... grub> ls (hd0) (cd0) (cd0,msdos1) (host) grub> ls (cd0)/isolinux boot.cat boot.msg grub.conf initrd.img isolinux.bin isolinux.cfg memtest splash.jpg TRANS.TBL vesamenu.c32 vmlinuz grub> linux (cd0)/isolinux/vmlinuz grub> initrd (cd0)/isolinux/initrd.img grub> boot .... Now that the Linux(R) kernel is loaded, the guest can be started: [source,shell] .... # bhyve -A -H -P -s 0:0,hostbridge -s 1:0,lpc -s 2:0,virtio-net,tap0 -s 3:0,virtio-blk,./linux.img \ -s 4:0,ahci-cd,./somelinux.iso -l com1,stdio -c 4 -m 1024M linuxguest .... The system will boot and start the installer. After installing a system in the virtual machine, reboot the virtual machine. This will cause bhyve to exit. The instance of the virtual machine needs to be destroyed before it can be started again: [source,shell] .... # bhyvectl --destroy --vm=linuxguest .... Now the guest can be started directly from the virtual disk. Load the kernel: [source,shell] .... # grub-bhyve -m device.map -r hd0,msdos1 -M 1024M linuxguest grub> ls (hd0) (hd0,msdos2) (hd0,msdos1) (cd0) (cd0,msdos1) (host) (lvm/VolGroup-lv_swap) (lvm/VolGroup-lv_root) grub> ls (hd0,msdos1)/ lost+found/ grub/ efi/ System.map-2.6.32-431.el6.x86_64 config-2.6.32-431.el6.x 86_64 symvers-2.6.32-431.el6.x86_64.gz vmlinuz-2.6.32-431.el6.x86_64 initramfs-2.6.32-431.el6.x86_64.img grub> linux (hd0,msdos1)/vmlinuz-2.6.32-431.el6.x86_64 root=/dev/mapper/VolGroup-lv_root grub> initrd (hd0,msdos1)/initramfs-2.6.32-431.el6.x86_64.img grub> boot .... Boot the virtual machine: [source,shell] .... # bhyve -A -H -P -s 0:0,hostbridge -s 1:0,lpc -s 2:0,virtio-net,tap0 \ -s 3:0,virtio-blk,./linux.img -l com1,stdio -c 4 -m 1024M linuxguest .... Linux(R) will now boot in the virtual machine and eventually present you with the login prompt. Login and use the virtual machine. When you are finished, reboot the virtual machine to exit bhyve. Destroy the virtual machine instance: [source,shell] .... # bhyvectl --destroy --vm=linuxguest .... [[virtualization-bhyve-uefi]] === Booting bhyve Virtual Machines with UEFI Firmware In addition to bhyveload and grub-bhyve, the bhyve hypervisor can also boot virtual machines using the UEFI userspace firmware. This option may support guest operating systems that are not supported by the other loaders. In order to make use of the UEFI support in bhyve, first obtain the UEFI firmware images. This can be done by installing package:sysutils/bhyve-firmware[] port or package. With the firmware in place, add the flags `-l bootrom,_/path/to/firmware_` to your bhyve command line. The actual bhyve command may look like this: [source,shell] .... # bhyve -AHP -s 0:0,hostbridge -s 1:0,lpc \ -s 2:0,virtio-net,tap1 -s 3:0,virtio-blk,./disk.img \ -s 4:0,ahci-cd,./install.iso -c 4 -m 1024M \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ guest .... package:sysutils/bhyve-firmware[] also contains a CSM-enabled firmware, to boot guests with no UEFI support in legacy BIOS mode: [source,shell] .... # bhyve -AHP -s 0:0,hostbridge -s 1:0,lpc \ -s 2:0,virtio-net,tap1 -s 3:0,virtio-blk,./disk.img \ -s 4:0,ahci-cd,./install.iso -c 4 -m 1024M \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CSM.fd \ guest .... [[virtualization-bhyve-framebuffer]] === Graphical UEFI Framebuffer for bhyve Guests The UEFI firmware support is particularly useful with predominantly graphical guest operating systems such as Microsoft Windows(R). Support for the UEFI-GOP framebuffer may also be enabled with the `-s 29,fbuf,tcp=_0.0.0.0:5900_` flags. The framebuffer resolution may be configured with `w=_800_` and `h=_600_`, and bhyve can be instructed to wait for a VNC connection before booting the guest by adding `wait`. The framebuffer may be accessed from the host or over the network via the VNC protocol. Additionally, `-s 30,xhci,tablet` can be added to achieve precise mouse cursor synchronization with the host. The resulting bhyve command would look like this: [source,shell] .... # bhyve -AHP -s 0:0,hostbridge -s 31:0,lpc \ -s 2:0,virtio-net,tap1 -s 3:0,virtio-blk,./disk.img \ -s 4:0,ahci-cd,./install.iso -c 4 -m 1024M \ -s 29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait \ -s 30,xhci,tablet \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ guest .... Note, in BIOS emulation mode, the framebuffer will cease receiving updates once control is passed from firmware to guest operating system. [[virtualization-bhyve-zfs]] === Using ZFS with bhyve Guests If ZFS is available on the host machine, using ZFS volumes instead of disk image files can provide significant performance benefits for the guest VMs. A ZFS volume can be created by: [source,shell] .... # zfs create -V16G -o volmode=dev zroot/linuxdisk0 .... When starting the VM, specify the ZFS volume as the disk drive: [source,shell] .... # bhyve -A -H -P -s 0:0,hostbridge -s 1:0,lpc -s 2:0,virtio-net,tap0 -s3:0,virtio-blk,/dev/zvol/zroot/linuxdisk0 \ -l com1,stdio -c 4 -m 1024M linuxguest .... [[virtualization-bhyve-nmdm]] === Virtual Machine Consoles It is advantageous to wrap the bhyve console in a session management tool such as package:sysutils/tmux[] or package:sysutils/screen[] in order to detach and reattach to the console. It is also possible to have the console of bhyve be a null modem device that can be accessed with `cu`. To do this, load the [.filename]#nmdm# kernel module and replace `-l com1,stdio` with `-l com1,/dev/nmdm0A`. The [.filename]#/dev/nmdm# devices are created automatically as needed, where each is a pair, corresponding to the two ends of the null modem cable ([.filename]#/dev/nmdm0A# and [.filename]#/dev/nmdm0B#). See man:nmdm[4] for more information. [source,shell] .... # kldload nmdm # bhyve -A -H -P -s 0:0,hostbridge -s 1:0,lpc -s 2:0,virtio-net,tap0 -s 3:0,virtio-blk,./linux.img \ -l com1,/dev/nmdm0A -c 4 -m 1024M linuxguest # cu -l /dev/nmdm0B Connected Ubuntu 13.10 handbook ttyS0 handbook login: .... [[virtualization-bhyve-managing]] === Managing Virtual Machines A device node is created in [.filename]#/dev/vmm# for each virtual machine. This allows the administrator to easily see a list of the running virtual machines: [source,shell] .... # ls -al /dev/vmm total 1 dr-xr-xr-x 2 root wheel 512 Mar 17 12:19 ./ dr-xr-xr-x 14 root wheel 512 Mar 17 06:38 ../ crw------- 1 root wheel 0x1a2 Mar 17 12:20 guestname crw------- 1 root wheel 0x19f Mar 17 12:19 linuxguest crw------- 1 root wheel 0x1a1 Mar 17 12:19 otherguest .... A specified virtual machine can be destroyed using `bhyvectl`: [source,shell] .... # bhyvectl --destroy --vm=guestname .... [[virtualization-bhyve-onboot]] === Persistent Configuration In order to configure the system to start bhyve guests at boot time, the following configurations must be made in the specified files: [.procedure] . [.filename]#/etc/sysctl.conf# + [.programlisting] .... net.link.tap.up_on_open=1 .... . [.filename]#/etc/rc.conf# + [.programlisting] .... cloned_interfaces="bridge0 tap0" ifconfig_bridge0="addm igb0 addm tap0" kld_list="nmdm vmm" .... [[virtualization-host-xen]] == FreeBSD as a Xen(TM)-Host Xen is a GPLv2-licensed https://en.wikipedia.org/wiki/Hypervisor#Classification[type 1 hypervisor] for Intel(R) and ARM(R) architectures. FreeBSD has included i386(TM) and AMD(R) 64-Bit https://wiki.xenproject.org/wiki/DomU[DomU] and https://en.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud[Amazon EC2] unprivileged domain (virtual machine) support since FreeBSD 8.0 and includes Dom0 control domain (host) support in FreeBSD 11.0. Support for para-virtualized (PV) domains has been removed from FreeBSD 11 in favor of hardware virtualized (HVM) domains, which provides better performance. Xen(TM) is a bare-metal hypervisor, which means that it is the first program loaded after the BIOS. A special privileged guest called the Domain-0 (`Dom0` for short) is then started. The Dom0 uses its special privileges to directly access the underlying physical hardware, making it a high-performance solution. It is able to access the disk controllers and network adapters directly. The Xen(TM) management tools to manage and control the Xen(TM) hypervisor are also used by the Dom0 to create, list, and destroy VMs. Dom0 provides virtual disks and networking for unprivileged domains, often called `DomU`. Xen(TM) Dom0 can be compared to the service console of other hypervisor solutions, while the DomU is where individual guest VMs are run. Xen(TM) can migrate VMs between different Xen(TM) servers. When the two xen hosts share the same underlying storage, the migration can be done without having to shut the VM down first. Instead, the migration is performed live while the DomU is running and there is no need to restart it or plan a downtime. This is useful in maintenance scenarios or upgrade windows to ensure that the services provided by the DomU are still provided. Many more features of Xen(TM) are listed on the https://wiki.xenproject.org/wiki/Category:Overview[Xen Wiki Overview page]. Note that not all features are supported on FreeBSD yet. [[virtualization-host-xen-requirements]] === Hardware Requirements for Xen(TM) Dom0 To run the Xen(TM) hypervisor on a host, certain hardware functionality is required. Hardware virtualized domains require Extended Page Table (http://en.wikipedia.org/wiki/Extended_Page_Table[EPT]) and Input/Output Memory Management Unit (http://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware[IOMMU]) support in the host processor. [NOTE] ==== In order to run a FreeBSD Xen(TM) Dom0 the box must be booted using legacy boot (BIOS). ==== [[virtualization-host-xen-dom0-setup]] === Xen(TM) Dom0 Control Domain Setup Users of FreeBSD 11 should install the package:emulators/xen-kernel47[] and package:sysutils/xen-tools47[] packages that are based on Xen version 4.7. Systems running on FreeBSD-12.0 or newer can use Xen 4.11 provided by package:emulators/xen-kernel411[] and package:sysutils/xen-tools411[], respectively. Configuration files must be edited to prepare the host for the Dom0 integration after the Xen packages are installed. An entry to [.filename]#/etc/sysctl.conf# disables the limit on how many pages of memory are allowed to be wired. Otherwise, DomU VMs with higher memory requirements will not run. [source,shell] .... # echo 'vm.max_wired=-1' >> /etc/sysctl.conf .... Another memory-related setting involves changing [.filename]#/etc/login.conf#, setting the `memorylocked` option to `unlimited`. Otherwise, creating DomU domains may fail with `Cannot allocate memory` errors. After making the change to [.filename]#/etc/login.conf#, run `cap_mkdb` to update the capability database. See crossref:security[security-resourcelimits,"Resource Limits"] for details. [source,shell] .... # sed -i '' -e 's/memorylocked=64K/memorylocked=unlimited/' /etc/login.conf # cap_mkdb /etc/login.conf .... Add an entry for the Xen(TM) console to [.filename]#/etc/ttys#: [source,shell] .... # echo 'xc0 "/usr/libexec/getty Pc" xterm onifconsole secure' >> /etc/ttys .... Selecting a Xen(TM) kernel in [.filename]#/boot/loader.conf# activates the Dom0. Xen(TM) also requires resources like CPU and memory from the host machine for itself and other DomU domains. How much CPU and memory depends on the individual requirements and hardware capabilities. In this example, 8 GB of memory and 4 virtual CPUs are made available for the Dom0. The serial console is also activated and logging options are defined. The following command is used for Xen 4.7 packages: [source,shell] .... # echo 'hw.pci.mcfg=0' >> /boot/loader.conf # echo 'if_tap_load="YES"' >> /boot/loader.conf # echo 'xen_kernel="/boot/xen"' >> /boot/loader.conf # echo 'xen_cmdline="dom0_mem=8192M dom0_max_vcpus=4 dom0pvh=1 console=com1,vga com1=115200,8n1 guest_loglvl=all loglvl=all"' >> /boot/loader.conf .... For Xen versions 4.11 and higher, the following command should be used instead: [source,shell] .... # echo 'if_tap_load="YES"' >> /boot/loader.conf # echo 'xen_kernel="/boot/xen"' >> /boot/loader.conf # echo 'xen_cmdline="dom0_mem=8192M dom0_max_vcpus=4 dom0=pvh console=com1,vga com1=115200,8n1 guest_loglvl=all loglvl=all"' >> /boot/loader.conf .... [TIP] ==== Log files that Xen(TM) creates for the DomU VMs are stored in [.filename]#/var/log/xen#. Please be sure to check the contents of that directory if experiencing issues. ==== Activate the xencommons service during system startup: [source,shell] .... # sysrc xencommons_enable=yes .... These settings are enough to start a Dom0-enabled system. However, it lacks network functionality for the DomU machines. To fix that, define a bridged interface with the main NIC of the system which the DomU VMs can use to connect to the network. Replace _em0_ with the host network interface name. [source,shell] .... # sysrc cloned_interfaces="bridge0" # sysrc ifconfig_bridge0="addm em0 SYNCDHCP" # sysrc ifconfig_em0="up" .... Restart the host to load the Xen(TM) kernel and start the Dom0. [source,shell] .... # reboot .... After successfully booting the Xen(TM) kernel and logging into the system again, the Xen(TM) management tool `xl` is used to show information about the domains. [source,shell] .... # xl list Name ID Mem VCPUs State Time(s) Domain-0 0 8192 4 r----- 962.0 .... The output confirms that the Dom0 (called `Domain-0`) has the ID `0` and is running. It also has the memory and virtual CPUs that were defined in [.filename]#/boot/loader.conf# earlier. More information can be found in the https://www.xenproject.org/help/documentation.html[Xen(TM) Documentation]. DomU guest VMs can now be created. [[virtualization-host-xen-domu-setup]] === Xen(TM) DomU Guest VM Configuration Unprivileged domains consist of a configuration file and virtual or physical hard disks. Virtual disk storage for the DomU can be files created by man:truncate[1] or ZFS volumes as described in crossref:zfs[zfs-zfs-volume,“Creating and Destroying Volumes”]. In this example, a 20 GB volume is used. A VM is created with the ZFS volume, a FreeBSD ISO image, 1 GB of RAM and two virtual CPUs. The ISO installation file is retrieved with man:fetch[1] and saved locally in a file called [.filename]#freebsd.iso#. [source,shell] .... -# fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/12.0/FreeBSD-12.0-RELEASE-amd64-bootonly.iso -o freebsd.iso +# fetch https://download.freebsd.org/releases/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-amd64-bootonly.iso -o freebsd.iso .... A ZFS volume of 20 GB called [.filename]#xendisk0# is created to serve as the disk space for the VM. [source,shell] .... # zfs create -V20G -o volmode=dev zroot/xendisk0 .... The new DomU guest VM is defined in a file. Some specific definitions like name, keymap, and VNC connection details are also defined. The following [.filename]#freebsd.cfg# contains a minimum DomU configuration for this example: [source,shell] .... # cat freebsd.cfg builder = "hvm" <.> name = "freebsd" <.> memory = 1024 <.> vcpus = 2 <.> vif = [ 'mac=00:16:3E:74:34:32,bridge=bridge0' ] <.> disk = [ '/dev/zvol/tank/xendisk0,raw,hda,rw', <.> '/root/freebsd.iso,raw,hdc:cdrom,r' <.> ] vnc = 1 <.> vnclisten = "0.0.0.0" serial = "pty" usbdevice = "tablet" .... These lines are explained in more detail: <.> This defines what kind of virtualization to use. `hvm` refers to hardware-assisted virtualization or hardware virtual machine. Guest operating systems can run unmodified on CPUs with virtualization extensions, providing nearly the same performance as running on physical hardware. `generic` is the default value and creates a PV domain. <.> Name of this virtual machine to distinguish it from others running on the same Dom0. Required. <.> Quantity of RAM in megabytes to make available to the VM. This amount is subtracted from the hypervisor's total available memory, not the memory of the Dom0. <.> Number of virtual CPUs available to the guest VM. For best performance, do not create guests with more virtual CPUs than the number of physical CPUs on the host. <.> Virtual network adapter. This is the bridge connected to the network interface of the host. The `mac` parameter is the MAC address set on the virtual network interface. This parameter is optional, if no MAC is provided Xen(TM) will generate a random one. <.> Full path to the disk, file, or ZFS volume of the disk storage for this VM. Options and multiple disk definitions are separated by commas. <.> Defines the Boot medium from which the initial operating system is installed. In this example, it is the ISO image downloaded earlier. Consult the Xen(TM) documentation for other kinds of devices and options to set. <.> Options controlling VNC connectivity to the serial console of the DomU. In order, these are: active VNC support, define IP address on which to listen, device node for the serial console, and the input method for precise positioning of the mouse and other input methods. `keymap` defines which keymap to use, and is `english` by default. After the file has been created with all the necessary options, the DomU is created by passing it to `xl create` as a parameter. [source,shell] .... # xl create freebsd.cfg .... [NOTE] ==== Each time the Dom0 is restarted, the configuration file must be passed to `xl create` again to re-create the DomU. By default, only the Dom0 is created after a reboot, not the individual VMs. The VMs can continue where they left off as they stored the operating system on the virtual disk. The virtual machine configuration can change over time (for example, when adding more memory). The virtual machine configuration files must be properly backed up and kept available to be able to re-create the guest VM when needed. ==== The output of `xl list` confirms that the DomU has been created. [source,shell] .... # xl list Name ID Mem VCPUs State Time(s) Domain-0 0 8192 4 r----- 1653.4 freebsd 1 1024 1 -b---- 663.9 .... To begin the installation of the base operating system, start the VNC client, directing it to the main network address of the host or to the IP address defined on the `vnclisten` line of [.filename]#freebsd.cfg#. After the operating system has been installed, shut down the DomU and disconnect the VNC viewer. Edit [.filename]#freebsd.cfg#, removing the line with the `cdrom` definition or commenting it out by inserting a `+#+` character at the beginning of the line. To load this new configuration, it is necessary to remove the old DomU with `xl destroy`, passing either the name or the id as the parameter. Afterwards, recreate it using the modified [.filename]*freebsd.cfg*. [source,shell] .... # xl destroy freebsd # xl create freebsd.cfg .... The machine can then be accessed again using the VNC viewer. This time, it will boot from the virtual disk where the operating system has been installed and can be used as a virtual machine. [[virtualization-host-xen-troubleshooting]] === Troubleshooting This section contains basic information in order to help troubleshoot issues found when using FreeBSD as a Xen(TM) host or guest. [[virtualization-host-xen-troubleshooting-host]] ==== Host Boot Troubleshooting Please note that the following troubleshooting tips are intended for Xen(TM) 4.11 or newer. If you are still using Xen(TM) 4.7 and having issues consider migrating to a newer version of Xen(TM). In order to troubleshoot host boot issues you will likely need a serial cable, or a debug USB cable. Verbose Xen(TM) boot output can be obtained by adding options to the `xen_cmdline` option found in [.filename]#loader.conf#. A couple of relevant debug options are: * `iommu=debug`: can be used to print additional diagnostic information about the iommu. * `dom0=verbose`: can be used to print additional diagnostic information about the dom0 build process. * `sync_console`: flag to force synchronous console output. Useful for debugging to avoid losing messages due to rate limiting. Never use this option in production environments since it can allow malicious guests to perform DoS attacks against Xen(TM) using the console. FreeBSD should also be booted in verbose mode in order to identify any issues. To activate verbose booting, run this command: [source,shell] .... # echo 'boot_verbose="YES"' >> /boot/loader.conf .... If none of these options help solving the problem, please send the serial boot log to mailto:freebsd-xen@FreeBSD.org[freebsd-xen@FreeBSD.org] and mailto:xen-devel@lists.xenproject.org[xen-devel@lists.xenproject.org] for further analysis. [[virtualization-host-xen-troubleshooting-guest]] ==== Guest Creation Troubleshooting Issues can also arise when creating guests, the following attempts to provide some help for those trying to diagnose guest creation issues. The most common cause of guest creation failures is the `xl` command spitting some error and exiting with a return code different than 0. If the error provided is not enough to help identify the issue, more verbose output can also be obtained from `xl` by using the `v` option repeatedly. [source,shell] .... # xl -vvv create freebsd.cfg Parsing config from freebsd.cfg libxl: debug: libxl_create.c:1693:do_domain_create: Domain 0:ao 0x800d750a0: create: how=0x0 callback=0x0 poller=0x800d6f0f0 libxl: debug: libxl_device.c:397:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=unknown libxl: debug: libxl_device.c:432:libxl__device_disk_set_backend: Disk vdev=xvda, using backend phy libxl: debug: libxl_create.c:1018:initiate_domain_create: Domain 1:running bootloader libxl: debug: libxl_bootloader.c:328:libxl__bootloader_run: Domain 1:not a PV/PVH domain, skipping bootloader libxl: debug: libxl_event.c:689:libxl__ev_xswatch_deregister: watch w=0x800d96b98: deregister unregistered domainbuilder: detail: xc_dom_allocate: cmdline="", features="" domainbuilder: detail: xc_dom_kernel_file: filename="/usr/local/lib/xen/boot/hvmloader" domainbuilder: detail: xc_dom_malloc_filemap : 326 kB libxl: debug: libxl_dom.c:988:libxl__load_hvm_firmware_module: Loading BIOS: /usr/local/share/seabios/bios.bin ... .... If the verbose output does not help diagnose the issue there are also QEMU and Xen(TM) toolstack logs in [.filename]#/var/log/xen#. Note that the name of the domain is appended to the log name, so if the domain is named `freebsd` you should find a [.filename]#/var/log/xen/xl-freebsd.log# and likely a [.filename]#/var/log/xen/qemu-dm-freebsd.log#. Both log files can contain useful information for debugging. If none of this helps solve the issue, please send the description of the issue you are facing and as much information as possible to mailto:freebsd-xen@FreeBSD.org[freebsd-xen@FreeBSD.org] and mailto:xen-devel@lists.xenproject.org[xen-devel@lists.xenproject.org] in order to get help.