FreeBSD offers two basic technologies for installing third-party applications. The easiest way is installing precompiled packages from official FreeBSD's package repositories. Somewhat more complicated, but more flexible way is compiling and installing applications using ports. Main shortcoming of official precompiled packages is the fact that they are being built with default set of options, whereas advanced setups often need to enable non-default option (e.g. LDAP authentication), change target database support (e.g. PostgreSQL instead of MySQL), or to disable undesirable default option (e.g. X11 support on headless servers). Luckily, there's additional way which combines flexibility of ports with simplicity of packages provided by Poudriere. The following article will help you set your own FreeBSD package repository where you will be able to compile your own packages from ports, and serve them to your other FreeBSD boxes. In a jail, of course!
In previous post we have prepared our jail host to be jail-friendly. In this one we will set up our first jail.
Now that we have secured our FreeBSD system, as well as our data partitions - both UFS and ZFS - from unavailability caused by disk failures, we will prepare it for its role of jail host. This requires reconfiguration of services that bind to all available interfaces to bind to specific interfaces instead. Jail manpage's section about setting up the host environment gives general guidelines, but it mentions services which are usually not enabled by default on contemporary FreeBSD versions (sendmail, inetd and rpcbind), while it does not mention services which are (ssh, ntp and syslog). This article gives instruction on how to bind sshd, ntpd and syslogd to specific interfaces, as well on how to create additional loopback interface. Finally we will modify hosts file.
In two previous articles we installed FreeBSD onto mirrored pair of disks as well as additional mirror for UFS data partition. gmirror and UFS are mature technologies which are quite stable and efficient, but lack some functionalities expected from modern filesystems. That's where ZFS comes into play. According to FreeBSD Handbook, ZFS is an advanced file system designed to solve major problems found in previous storage subsystem software. More than a file system, ZFS is fundamentally different from traditional file systems. Combining the traditionally separate roles of volume manager and file system provides ZFS with unique advantages. This article assumes FreeBSD has already been installed onto mirrored pair of disks and UFS data partition has already been added. We will now add RAIDZ volume consisting of four SATA disks which can survive failure of one of the disks. Write performance will be increasing by configuring two NVMe disks for ZIL (ZFS Intention Log), while read performance will be increased by adding single NVMe disk for Cache.
In another article we installed FreeBSD onto mirrored pair of disks. We intentionally used fairly small but very fast nvme disks so that our FreeBSD setup works as fast as possible. However, we wouldn't be able to fit much services onto such small storage. Good news is we shouldn't. There are many reasons to put data on separate partition, or - even better - on separate disk(s). First and foremost, exhausting free space on / could crash complete system, while filling up /var could disable syslog functionality. On busy servers which need a lot of disk IOPS and bandwidth it is good to ensure that basic OS functionality won't be slowed down by greedy services from disk IOPS and bandwidth point of view. This article builds upon mentioned article and describes how to make anothergmirror volume from two SATA disks, format it as UFS and mount it under /ufsdata partition.
Important OpenBSD systems should be installed onto a pair of mirrored disks so that malfunction of a single disk won't shut down services and cause data loss. OpenBSD FAQ has section about Installing to a Mirror which covers both MBR and GPT partitioning schemes. Seasoned admins familiar with OpenBSD's way of naming devices and tools such as fdisk and disklabel will find everything they need regarding mirrored setup there. This article adds a bit more information about installing OpenBSD to a mirror in newcomer friendly format.
Hosting services is much more fun when we can be sure that malfunction of a single disk won't shut down services and cause data loss. FreeBSD Handbook has a chapter about Creating a Mirror with Two New Disks, but it suggests some outdated practices such as legacy BIOS boot and MBR partitioning scheme as opposed to UEFI boot and GPT partitoning scheme described in this article. Furthermore, contrary to examples in FreeBSD Handbook which use device nodes such as ada directly, this article describes using geom labels for gmirror creation. Finally, we set our fstab using custom gpt labels as oposed to automatically created partitions under /dev/mirror/ described in FreeBSD Handbook.
