Why I Use FreeBSD
2013-10-28
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.
Jails
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.