I’ve been a big fan of FreeBSD since I first acquired 4.4 on 4 CDs. By that point, I had already spent a lot of time in Linux, but I was always put off by its instability and inconsistency. Once I had FreeBSD installed, it felt like a dream. Everything worked the way it was supposed to, and the consistency of its design meant even older documentation would be mostly applicable without having to figure out how my system was different. There is a reason why in the early days of the Internet, a huge portion of servers ran FreeBSD.
But, that was a while ago. Since then, Linux has matured greatly and has garnered a lot of momentum, becoming the dominant Unix platform. FreeBSD certainly hasn’t stood still, however. The FreeBSD team has kept current with hardware support, new features, and a modern, performant design.
As far as hardware support, it is extremely well supported on i386 and amd64 architectures, which are considered Tier-1 platforms.. PowerPC, Sparc64, ARM, and ia64 architectures are considered Tier-2. This means that those systems are not supported by the security team, and security patches must be ported to the individual architectures by their respective teams. Additionally, new features added to Tier-1 should be workable on Tier-2 platforms, but implementation isn’t required before integration into the main source tree. Tier-2 systems shouldn’t be considered broken – they generally work quite well, even in production environments. Sparc64 is perhaps the best supported of the Tier-2 platforms.
I don’t really have access to a wide range of hardware at all – my Dell laptop is the only thing I can really tinker with, so most of this review was conducted in VMware, which fully supports FreeBSD. I would actually prefer FreeBSD, but for two minor problems. First, at least on my laptop, FreeBSD may not properly throttle back the CPU when it gets too hot, so tasks that really hits my laptop hard cause an overheat alarm and the FreeBSD will shut itself off. This has only happened once, and it did shut-off gracefully. The other one isn’t so minor: My laptop has hybrid graphics (IntelHD and NVidia). There is no way, supported or unsupported, to use the NVidia graphics. This is fine 90% of the time, but for that 10%, I’d really miss it.
Finally, FreeBSD might be the most prominent of the BSDs, but it certainly isn’t the only one. In the upcoming weeks, I will be doing more of these covering some of the other BSDs.
Installation and Configuration
For a long time, FreeBSD used the venerable
sysinstall, a text-based installation system. It wasn’t pretty, but it worked well. Recently, they switched to
bsdinstall, a text-based installation system which isn’t pretty, but works well. It has lost some features while gaining others, but it is a much more flexible design, and will ultimately be significant improvement. The install process is currently simpler, but
bsdinstall offers greater levels of scriptability and customization, if your environment requires it.
The install process itself is fairly straight forward, but there are definite benefits to being familiar with FreeBSD. They steps consist of configuring your network, partitioning the disk, and choosing your distribution components from a total of five options. After this, the root password is set, and a users can be added. One thing that it doesn’t tell you is that if you want to be able to su into the root account, the user needs to be a part of the group wheel.
Another area of potential trouble that the installer doesn’t alert you to is that if you are sharing a disk with another OS, the FreeBSD bootloader won’t be installed. After copying files, and before rebooting, the opportunity is given to drop to a shell for further configuration. A single command is all that is needed to install the bootloader in this situation. Unfortunately, there is no immediate help given on how to do this, or that it even needs to be done, but information on what to do is located in the FreeBSD Handbook. Again, it is very helpful to have prior experience with FreeBSD to fix this.
Overall, the installation is quick, taking only about 10 minutes or so from a USB stick to a hard disk. When it’s done, it boots to a console login prompt. Some further configuration may be needed. This may involve adding extra users if required, and configuring additional network adapters, as only one is configured during the install.
After configuring the base system, the next thing you’ll want to do is update the system and install the ports tree. The system can be updated with the
FreeBSD-update command. This will install the latest security patches. FreeBSD differs from most Linux distributions, in that updating the system provides only security updates, and not feature-updates. New feature are rolled into new releases, which happen on a roughly annual basis. If you need to customize your system, you can download the latest source and rebuild the the kernel or the whole system, depending on your needs. The source tree and the FreeBSD Handbook have much documentation on this process. On my laptop, with 8GB of RAM and a 2.2GHz quad-core Sandy Bridge processor,
make -j10 buildworld (which builds the entire system) takes about 45 minutes to complete.
For additional software, the ports tree is one of FreeBSD’s strong points. There are more than 24,000 ports available. A simple
make install will build and install an application and all of it’s dependencies. It will prompt you to set configuration options if needed, and will even create package files if instructed. If you need to use another system to grab the package files, you can even generate a shell script that will automatically fetch the needed files for you. There are also a whole suite of port management tools to ease the processes of updating and upgrading software.
For regular package management, FreeBSD falls flat initially. It’s package tools are rather antiquated, and lack many features. For example, there is no built-in way to upgrade a package automatically – it has to be uninstalled and reinstalled manually. There are ports available to streamline certain package tasks, however. For example, you can use
bsdadminscripts from the ports tree. This provides tools to automatically upgrade packages without having to build them via ports. However, the
bsdadminscripts package still utilizes the regular package tools, and because of that is limited in what it can manage. There is a much superior option available, however, that modernizes FreeBSD package management.
Available in FreeBSD 9.1 (but not yet ready) is
pkgng, the precursor to the next package system due to arrive in FreeBSD 10.0. This tool adds significant functionality and makes package management much simpler. Tools are included to convert your package database from the old system to the new. Currently, the only packages available from the FreeBSD servers via
pkgng is pkgng itself. However, the folks behind PC-BSD have setup a pkgng repository with instructions on how to use it with FreeBSD, and this is what I recommend you do. If you have newer Intel graphics, this is necessary if you don’t want to build Xorg yourself, since PC-BSD defaults to a new version built with KMS support. Most packages available in ports should be available, and ports can be integrated into
pkgng, using that for package installation rather than the old method. Using
pkgng to install a group of packages performs significantly faster, as well. Again, I strongly recommend you use this setup.
One of the great features of FreeBSD is native ZFS support. All the needed tools are included out of the box, and all that is needed to be done is to add
zfs_enable="YES" to /etc/rc.conf. This will allow your ZFS pools and datasets to be automatically mounted at boot. If you plan on using Jails (as I am in this review), I would strongly recommend ZFS to host your jails on. ZFS’s snapshot and copy-on-write features make it an excellent choice for managing your jails efficiently.
It isn’t necessary to use ZFS for the rest of the system. In fact, bsdinstall doesn’t handle ZFS too well beyond basic zpool creation. However, if you are set on using ZFS from top to bottom, it is possible and not at all difficult if you’re comfortable with the console. I won’t cover that here, but there is an excellent guide for having ZFS as root. If that guide doesn’t quite fit for your needs, there are plenty more.
Jails and Virtualization
Jails are one of FreeBSD’s flagship features. They provide advanced features compared to traditional chroot environments, without the security problems traditional chroots have had. Processes within a jail cannot see processes that exist outside of the jail. Additionally, each jail has it’s own IP addresses and hostname. Like any OS-level virtualization option, the kernel is shared, so you can only run FreeBSD-built software within a jail. However, unlike true virtualization solutions, there is absolutely no performance hit. Networking and disk I/O operate at full speed.
There are three ways to install a jail. First, you can use bsdinstall, the same install program that installs the base system, to install from an installation disk. Alternatively, you can download the source for FreeBSD, compile it, and install into a jail location.
Finally, you can use ezjail, available via the ports tree. This the most widely used and easiest to use solution. If you use ezjail, it conserves disk space by using FreeBSD’s nullfs feature to create a duplicate userland without copying files. Additionally, ezjail will take full advantage of ZFS features, using it’s own native snapshot and copy-on-write to also avoid duplication of the userland.
Using ZFS with ezjail is simple. Just create a new zpool mounted at /usr/jails, then change a handful of ZFS-related settings in /usr/local/etc/ezjail.conf. This file is well documented within the file, and there is also a man page with more detail.
Using ezjail, creating a basejail is as easy as running
ezjail-admin install. All subsequent jails are based on the basejail, but it is possible to create other flavors if you are running multiple jails with common features. Options are available to include the ports tree, man pages, choose where to download the base system, or choose the release version you wish to use. You could potentially even install a significantly older FreeBSD release in a jail. This hasn’t been well tested, but there is no real reason why it shouldn’t work. It is even possible to install the Debian/kFreeBSD userland inside a jail, as well as something seemingly crazy, but still useful: CentOS 5.5 in a jail.
I created three jails on my test installation: A publicly accessible web server running Dokuwiki, a server to handle dhcp and dns for an internal network, and a Samba server providing shared storage. In a situation such as this, if the publicly facing web server was compromised, the rest of the system would remain protected.
While the security offered is potent, it isn’t automatic or 100% complete. There are a number of well documented and well understood situations where a privileged user within a jail can team up with an unprivileged user on the host to and get privileged access on the host. Care must also be taken when creating devfs rule sets for jails. By default, only a very limited selection of devices are accessible within a jail, but many services require greater access to certain devices. As an example, dhcp needs access to packet filter devices, and the OpenSSH server needs /dev/random. If a device node is exposed to the jail in an insecure way, such as write access given when only read access is needed, and that jail is compromised, the misconfiguration might be leveraged to cause havoc.
FreeBSD Jails have been around since the 4.x series, and while mature, until recently it has lacked a key feature round in Solaris Zones and Linux OpenVS: The ability to impose resource limits on per-jail basis. New with 9.x is Hierarchical Resource Limits. This system allows an administrator to place various limits on jails, and have triggers for each limit that can log events, execute scripts, or deny resources. Triggers can be set for various counters, such as memory usage, stack size, process count, or others. Currently, CPU rate and I/O limiting isn’t implemented, but CPU rate limiting is coming for 10.x.
If jails isn’t enough to meet your needs, and you need to virtualize your whole system, FreeBSD makes great guest OS. The best option is to run it under VMware, as it is officially supported by VMware, and has been for several years. FreeBSD is also supported under Amazon’s EC2 service, and tools are available to create instances to run under Microsoft’s Azure service.
If you want to virtualize FreeBSD on your desktop, FreeBSD’s support of both VMware and Virtualbox guest additions is complete, with accelerated graphics, automatic cursor grabbing and ungrabbing, and shared folders. It also runs under Parallels Desktop for OSX, and both VirtualPC and Hyper-V for Windows.
If you wish to virtualize another OS on your FreeBSD system, your options are rather limited. Currently, only Virtualbox runs, and that is without USB support, since that requires a closed-source, proprietary driver that isn’t available for FreeBSD. Aside from the lack of USB support, Virtualbox is stable and runs as expected.
FreeBSD on the Desktop
It doesn’t happen automatically, but FreeBSD can be made into a fine desktop. If you are a KDE user, the story couldn’t be much better. The latest KDE version is always available via ports, since with each release the KDE team keeps an eye towards FreeBSD compatibility. Installation, whether via ports or packages, presents a KDE desktop, with the only modification being the initial background image.
Gnome is a different story. Gnome 2 is available in the Ports tree, but Gnome 3 is not. Most of the Gnome developers don’t seem to interesting in supporting anything other than Linux. There is third-party repository available at www.pkgdemon.com that provides a method to build Gnome 3 inside of the ports tree, as well as Cinnamon if you prefer an updated Gnome 2 desktop. I am not a Gnome fan, so I did not attempt this.
Some things are important to know about running Xorg on FreeBSD. First, the packaged Xorg (as well as the default configuration when building from ports) includes hald and dbus, but those services are not enabled by default, so when you launch X, your mouse and keyboard won’t work. To enable them,
dbus_enable="yes" need to be added to the
Second, and more importantly, video support is somewhat limited. Currently, Kernel Mode Setting is only partially implemented. IntelHD graphics requiring KMS work with some caveats (Such as, no text console after the kernel module is loaded, and a kernel panic when unloading the module), but AMD Radeon chipsets are not. Pre-KMS drivers do work, with 3D acceleration when available, and NVidia graphics are fully supported by NVidia’s proprietary driver. This driver actually works very well and is well supported. It has been available for 10 years, and provides the necessary libraries for running OpenGL applications under Linux emulation. Performance should be good (It was awesome in the past, rivaling Windows XP and besting Linux by 50%), but I unfortunately cannot test the current versions, as my laptop is an uses NVidia’s Optimus, and I can only use the IntelHD graphics under FreeBSD.
There are some other issues with FreeBSD as a desktop to be aware of. A weird quirk of FreeBSD package management is that the default package repository doesn’t get updated; all the packages are the same version as what is found in the ports tree included with that particular release. Besides the RELEASE branch, there is also STABLE and CURRENT. The STABLE branch is updated along with the standard ports tree, and there is typically about a week or so of lag time between the port being updated and the corresponding package being available. If you want the cutting-edge branch, you can switch to CURRENT, which provides the absolute latest, untested packages. Currently, CURRENT and STABLE are identical, but this isn’t always the case.
Also, even when the packagesite is correctly set, it might not find existing packages. This occurs because, when you do something like
pkg_add -r firefox, it will look at a path normally ending in
Latest/firefox.tbz, which is a symlink to
../All/firefox-##.##.tbz (Depending on the version). The symlink might be pointing to an older version that is no longer there. Using the full path to the correct package will fix this issue, or you can wait for the symlinks to be updated. Of course, using PC-BSD’s package repository with the new package manager doesn’t have these issues. I can’t understate how helpful this is.
Obviously, FreeBSD has a ways to go to be as smooth on the desktop as newer Linux distributions, but if you are willing to put up with these relatively minor problems, it does make a fast, stable desktop. Adobe’s Flash player is available via the Ports tree (It uses Linux emulation and a shim to provide it to native browsers). There are also plenty of kernel tunables to optimize your system for desktop usage (There is a good guide available here), and ALSA and PulseAudio emulation is available when applications don’t support OSS.
Final Thoughts and the Future of FreeBSD
FreeBSD is a complete and well-engineered system. While much of what they do involves less fanfare than Linux, they have a strong and active development and user community. They have kept pace with technology and still maintain a powerful system with modern features, and have done so mostly without anything feeling tacked on. The consistency of the system is why I prefer it over Linux – significant changes can rarely, if ever, be described as disruptive. But, changes still are made.
Slated for FreeBSD 10 are a number of improvements, many incremental. Virtual Private Systems, or VPS, is a new OS-level virtualization technology that will offer true virtualization of kernel resources, even providing live migration between hosts. The BSD Hypervisor is also nearing completion, which will turn FreeBSD into a type-2 hypervisor. KMS is also being expanded upon, with AMD graphics slated for support, and many other more incremental changes are coming, but there is a major change looming on the horizon.
Very important from a technological standpoint as well as a philosophical standpoint is removal of GPL from the base system. There are some environments where the GPL is not appreciated or allowed (such as certain embedded scenarios), and these changes allow FreeBSD to fit into those environments. It is also important for the FreeBSD project, as it helps to strengthen the identity of the project and the license. FreeBSD 10 is slated to be released the 18th of November, and the team is very good about hitting their target dates.
There is still plenty of development going on the BSD world, and as I alluded to at the top, this is meant to be the first of several articles on BSD that I’ll be writing in the coming weeks, time allowing. OpenBSD and NetBSD are of course on my list, as are a half dozen or so other smaller or more specialized BSD projects. So, stay tuned!
David Hutchinson is a student of both Networking and Computer Science, and an all-around science and technology enthusiest.