3 minute read

It’s now been almost four months since I relapsed into running some FreeBSD servers, and I’ve now had time to lift them through my first FreeBSD major version upgrade; up to version 14.

“What!? Didn’t you say you used to run that system a decade ago?”

Well, confession time: Back then I was really wet behind the ears. We needed a load balancer for a new service. I was the only one in the company remotely interested in other systems than Windows, and I had just enough experience to know that the Windows-based load balancing alternatives at the time were horrible. Horrible enough that Microsoft withdrew its own contender from the market, actually. So I read up on load balancing and high availability and ended up choosing FreeBSD for its CARP protocol, and HAProxy on top of that for its load balancing and reverse proxy capabilities.

But I was scared to death of breaking something in production, so once I had set things up and had them working, I basically just left the FreeBSD servers there until the system was retired a while later - the product didn’t do as well as planned. Anyway, in hindsight I could’ve managed that load balancer solution a bit better…

Since then I’ve had a lot more experience running Unix-like systems in production, and I have a lot more overlap with developer experience than I did as a relatively green Windows Server administrator. It turns out a side effect of that, is that you get better at taking precautions against any mistakes you might make, and you get less scared of not being able to recover from such mistakes. Go figure.

So what can I say about the FreeBSD upgrade process?

Like most things in FreeBSD, it’s a more manual and low-level process than we may be used to from other operating systems. The process basically consists of the steps any operating system upgrade has to perform, but with FreeBSD you get slightly more involved in each individual steps. The gist of it is that you switch your updaters to look for content related to the new release, then you update the base system until there’s nothing left to update, then you update your packages and/or ports, and then you attempt yet another system update for good measure.

The system keeps you informed about what’s about to happen, with choices to proceed or abort. You get presented with applicable diffs for configuration files where the installer wants to replace lines, and I would say it’s all very confidence-inspiring. Though the suggested changes usually are the correct ones, you shouldn’t blindly accept them. But the suggestions are very clear and if you’re competent enough to configure your FreeBSD server to begin with, you shouldn’t have any problem at all making the correct decisions during such an upgrade. Also you get multiple thoughtful prompts with recommendations and next steps to take.

If you run FreeBSD on ZFS, the installer also snapshots your boot environment just like during minor updates. This provides an additional recovery path if something would go horribly wrong.

And this experience mirrors much of what I’ve experienced with FreeBSD over the last few months. Running a few FreeBSD servers in a pet-like fashion brings some genuine fun back into server management. It’s rewarding in a completely different way from what I experience managing modern Linux servers at work. It all feels robust and solid and uses modern server technology as you’d expect, but managing the server it feels like old good ideas have been refined in contact with new good ideas rather than the apparent throwing away of old ideas you often see in the Linux world. Don’t get me wrong: Both approaches are required for technology to evolve, but it’s good for the soul to have a few machines that feel unapologetically mature.