Why I Use FreeBSD
Installing packages from source
Recently, I had SSHed into one of Debian Stable virtual machines I was using as a file server. The main services I was running were FTP, an HTTP server with a directory listing and a Samba server, with shares set up for a few users on my
LAN. All in all, it wasn’t anything very complex, it was extremely run-of-the-mill, and could have almost been installed by
tasksel file-server or some similar list of packages almost certainly installed on thousands of servers.
A problem arose with the server after I realised I needed to enable several options in ProFTPd, the FTP server I was using. There isn’t a way to do this easily on Debian, as far as I’m aware. I know about the
apt-get source command, but, as far as I have read, that command can only build packages with the options that the person who made the source package specified. Essentially, it’s a system focused not on customisation of packages, but on staying on the bleeding edge of updates for that package. I don’t really see any point in this, so
apt-get source seems useless for my purposes. It would be useful in a context similar to that of
sbopkg, the SlackBuilds package manager, which is useful because it provides access to a wider variety of packages than official mirrors. Debian has all of the packages one could desire prepackaged and mirrored, so the one possible use of
apt-get source is null.
At this point, the only option available to me was to download the source from proftpd.org and use the Makefiles provided with the source to compile and install ProFTPd. There are several problems with this approach:
dpkg, the Debian package manager, is never involved, meaning dependencies and upgrades cannot be handled automatically - it is up to me to fetch the tarball and recompile it.
Having a multitude of extracted tarballs, CVS repositories and Git repositories lying around on my system causes clutter and confusion. One might say that naming and organising my directories should be my responsibility. The fact of the matter is that it should not be handled manually - that is a time-wasting and error-prone approach.
This solution is not scalable. With dozens of packages across many servers needing to be recompiled whenever there is an important security fix, I could find myself without any time to devote to real, important server maintenance tasks. Eventually, manual compilation of packages would become impossible.
This is a stark contrast to FreeBSD’s solution to the problem of package customisation. On FreeBSD (and any other *BSD), the ports collection provides a convenient way to compile your own packages. Quite simply, you search for your packages using “whereis” or “make search”, navigate to its location under /usr/ports, then
make it. That is obviously not the only way to make use of ports - that method suffers from essentially all of the same problems as before!
If we look back to the original example, that of ProFTPd, I can demonstrate the power of ports. Using
sysutils/portmaster, a handy script for building, then installing packages from source, I can install ProFTPd with my desired configuration:
$ sudo portmaster ftp/proftpd ===>>> Port directory: /usr/ports/ftp/proftpd ===>>> Gathering distinfo list for installed ports ===>>> Launching 'make checksum' for ftp/proftpd in background <Most of the output removed for brevity> ===>>> The following actions were performed: Installation of ftp/proftpd (proftpd-1.3.4d)
Basically, I specified which port to install, which caused portmaster to begin the process of downloading the source, checking its integrity and most importantly, launching
make config, which opens a menu with the compile options for ProFTPd. After I select the ones I want, I can then let portmaster compile the port into a package, which is installed using the FreeBSD package manager. From this point, I can either update it from a mirror of binary packages (this would be faster, but the package would not have my compile-time options enabled) or upgrade it using portmaster. The process of upgrading hundreds of packages from source is a single command:
portmaster -a. The convenience and power of FreeBSD ports is only one of the reasons I use it and the other *BSDs on my servers.
On Debian and indeed all other GNU/Linux operating systems, you have a few choices when it comes to virtualisation. You can go with KVM, Xen or VirtualBox, all of which are the standard, heavyweight, fully virtualised solutions. Alternatively, if you think the immense overhead that comes with fully virtualising a server is too much, you can use Linux containers. There are problems with using LXC, however, problems which are extremely important for security conscious sysadmins.
If a malicious hacker gains access to your LXC and manages to use a privilege elevation exploit to gain root on that box, it is not only the virtual box which is compromised - root within an LXC translates to root outside the container. This means that LXCs are essentially useless if you are virtualising for the sake of security. Similarly, shutting down an LXC using the
shutdown binary results in the host machine shutting down. While this is less serious from a security perspective than the gaining root (since you need to be root to shut down in the first place), it can be irritating.
Jails on FreeBSD face none of these issues. FreeBSD jails have existed since FreeBSD 4.0, which was released 13 years ago. A massive amount of development has been targeted at adapting the FreeBSD kernel and userspace to playing nicely within a jail and when hosting jails; this effort has resulted in an excellent virtualisation solution. Much like a traditional virtual machine, a jail has its own kernel, its own procfs, its own devices and everything you would find in a real FreeBSD system. Using
make buildworld && make installworld into an appropriate jail directory is all that is needed to create a jail. After this is done and the networking is set up, the environment viewed from within a jail is indistinguishable from a real FreeBSD system.