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.
Large browser vendors have quite some time ago established model of "trusted" web sites based on SSL certificates signed by "trusted" CAs. This trend increasingly spreads to other applications and protocols. This article gives exact steps needed for obtaining Let's Encrypt's wildcard certificates from FreeBSD host, using DNS validation through dynamic updates of a BIND server's zones, using EFF's ACME client, certbot.
Most of the OpenBSD systems I am in charge of are deployed in data centres, powered by UPSs which provide them with electrical power during periods of public grid power outages. But there is also a number of OpenBSD systems I administer, which are deployed in much less favourable conditions; where frequent power outages last longer than UPS batteries do, or where there are no UPSs at all (such as branch office routers in godforsaken places where having electricity and Internet access at all is considered a lucky circumstance). These latter systems are likely to have high rate of unclean shutdowns caused by prolonged or unexpected power outages, which in turn increase the probability of their inability to boot without human intervention. This article describes steps to make OpenBSD system more resilient to unexpected power outages by minimising the possibility of inconsistent file systems after unclean shutdowns, which is achieved by mounting all disk partitions in read-only mode. Filesystems which have to be writable - /var /dev and /tmp - are mounted as writable memory file systems.
