Why I’m not fond of Ubuntu Servers

16/05/2010 – 11:11 pm

Recently I have found myself complaining about Ubuntu Server more often, and people apparently start taking offence. First, let me clarify that I do think that Ubuntu is a very good option for desktop computers, if you’re not too keen on running commercial operating systems like Windows or Mac OSX. Without Ubuntu founder Mark Shuttleworth‘s help, Linux still wouldn’t be that popular on desktop computers. That is a great achievement and certainly helped Linux to become more mature (both on desktops and servers), as wider interest in Linux automatically helped growing the community of developers who participated in various Linux-related and open source projects.

That said, we must not forget Ubuntu’s focus, which I think (and I will expand on it later) is still valid: desktop and laptop computers.

Ubuntu aims to bring the latest drivers and technologies to desktops (I will use desktop as a term for desktop computers, laptops, and netbooks here). It has to, because otherwise it won’t be able to compete with proprietary operating systems (read: Windows and Mac OSX). To achieve that, it has to put the GPL/non-GPL debate (which is a big issue for Debian et al) aside. There’s a bunch of repositories of not exactly free (or not even open source) software, which is essential to get certain hardware (e.g. graphics cards) and software (e.g. media codecs) working: Restricted, Multiverse, Universe, Medibuntu, etc. Although they are not officially supported, all of them except Medibuntu are included in /etc/apt/sources.list and active, plus they reside on *.ubuntu.com servers. So it’s a bit difficult to not consider them part of Ubuntu, or at least part of the Ubuntu-Conquers-The-Desktop success, which makes the discussion of “who’s responsible for what?” a bit more difficult to answer. But it’s a crucial question in an enterprise setup. This is just one example why I think that Ubuntu is not targeting enterprise server environments, and you can’t be the best choice for something, which you are not focused at. More further down…

I’ve just installed Ubuntu Server 10.4 LTS in a virtual machine here to verify whether my past experience still holds true. I went for the Install Ubuntu Server option, and only used defaults (except that I added OpenSSH). So except stated otherwise, I will refer to this version, which is the latest release for servers and allegedly targets enterprises.

The intention of this article is not to compare Linux distributions with each other or give any recommendations as to which Linux distribution is the best one to go for in an enterprise environment. It’s not my intention to badmouth Ubuntu or say that it’s not suitable for servers at all, either. I’m merely explaining why I’m not a big fan of Ubuntu, as I’ve been asked that question a couple of times recently. Okay, maybe I’ve provoked that question a little. :-)  It’s no secret though that my favourite Linux distribution for servers is CentOS, if it has to be Linux, or FreeBSD, if the scenario permits and the operating system decision is a matter of what we want to achieve rather than what we want to use. But again, that’s a separate discussion and beyond the scope of this article. Also, there’s no “one size fits it all”. I have noticed that many people stick to the things they know or like best in many situations, where another operating system or Linux distribution might have been more suitable for a certain job. Although I can’t scientifically prove it, this seemingly applies to many people who use or did use Ubuntu on desktops. Maybe we should use the “fanboi” term not only for Apple’s repeat customers, but also for Ubuntu users :-)

Okay, back to the original question, why I don’t like Ubuntu on servers…

Let me first define what my expectations are:

  1. There is no such thing as one single server. Servers come in pairs at the very least. I build environments which are as fail-safe as possible (and affordable), load-balanced, robust.
  2. Implementing the very latest developments and technologies usually does more harm than good, because they can’t have been tested by as many people as older features. I prefer well-tested, solid operating systems. If I really need a more up-to-date version of, say, PHP, then I build a package for that. I don’t need the entire distribution to include the latest features just because I need only one package to be a bit more up-to-date! (NB: I am talking about feature updates here, not security patches!)
  3. I expect the operating system to provide reasonable security standards and default settings and leave the rest to me.
  4. I prefer using established standard tools and best practices over “Mate, we’ve quickly put together a new tool for you”
  5. I decide what is installed and what isn’t. I don’t need the OS to tell me what it thinks is good for me.
  6. Most of all I expect a proper release cycle and thorough testing before labelling something as a final release. (Oh, I did mention that before, didn’t I? :) )
  7. I don’t like operating systems or derivates, which are entirely built on top of an existing one. Additional layers cause additional dependencies, often inherit errors, and make it more difficult to track down where an error comes from, and who has introduced it.

Let me start with 7., because I hear you saying “But…”. ;-)  No, CentOS is not built on top of RedHat! It’s a 100% clone minus proprietary stuff, logos, and license/support costs. Ubuntu however is derived from Debian and has added loads of stuff, which includes many things that Debian refuses to include (e.g. proprietary drivers and non-GPL code in general), while incorporating lots of Debian packages. Remember this severe OpenSSL bug exactly two years ago? What happened was that Debian broke the random number generator (making keys predictable) in their OpenSSL package.  The only distributions affected were Debian and all derivates including Ubuntu, but not RedHat or clones/derivates thereof. I don’t blame Ubuntu for inheriting broken code, because nobody can possibly read and understand the source code of everything. However, that was when I lost trust in Debian (the code change was an utterly stupid attempt to get rid off compiler warnings without understanding what the code does), and as it is the foundation of Ubuntu, I can’t trust it either. You may call it nitpicking, but making changes (and introducing bugs) to crucial security related features, which would definitely not have gotten the upstream’s approval, if they had pushed it upstream, is pretty bad stuff. All SSH keys had to be re-generated and SSL certificates replaced. Not  a big deal for only a bunch of servers, but a massive amount of work for an enterprise.

Let me continue traversing the list above. Number 6: Releases. First of all, before installing a new update, I would like to be able to assess what changes will occur to my systems. That’s what release notes are for. However, if you are on the Ubuntu Server home page and click on Resources and then a bit further down on Release Notes, you in fact end up only with known issues for both Ubuntu Desktop and Server. It takes quite a while to find the actual key specs at least, hidden somewhere in the wiki. But I wanted to elaborate on release cycles…

From a server Linux distribution I would expect that it has been presented to a huge group of users prior to its final release. Ideally it goes through various beta or pre-release cycles, giving the users time to test (some things need time to test them properly) and developers time to fix issues. Ubuntu however sets deadlines: every April and October of each year, there’s has to be a major release. In other words: In a half-year cycle new features have to be selected, introduced, and tested. It doesn’t seem to be top priority to have rock-solid releases. Let me quote an Ubuntu developer:  ”And remember that, since this is a long-term supported (LTS) release, there are ample opportunities for further bugfixes after the final release by way of the SRU process[2]. Point releases for Ubuntu and Kubuntu LTS will be made at roughly six-month intervals, with the first expected in July 2010 to address any critical issues not identified or fixed in time for the 10.04 LTS release.”

I’m sure he didn’t mean it, but it sounds like: “Hurry up. Doesn’t matter if we can’t fix things on time, as we’ll come up with a bugfix release in July anyway.”  Beta 2, release candidate, and final release were published within only three weeks, by the way. Ubuntu, Ubuntu Server, and Kubuntu at the same time. It does raise questions, doesn’t it?

If you look at FreeBSD, just to compare two entirely different release policies, you’ll find that they first work out what issues need to be addressed and which features may be introduced. Then they come up with a very rough schedule. And then, after they have frozen the code, they go through many stages for major releases: BETA 1-4, Documentation updates, Release Candidate 1-3, Release. From the code freeze (except for bug fixes) to the actual release of 8.0 in November 2009, it took them 4.5 months. And, as usual, the result is a rock-solid operating system. The minor release 8.1 is planned for July this year (but not yet announced for a good reason). I expect it to be available in September or so. ;-) In my opinion, it’s much more important to get the issues solved rather than sticking to a fixed deadline.

Number 5: I’m the boss! As I said earlier, I just installed 10.04 LTS Server here. Although I did not select any packages except OpenSSH, I ended up with an installation eating 818 MB on my disk. Hello? It turned out that a whole pile of useless stuff is installed by default: Wireless support, PPP (yeah, good old dial-up!) support, file system support for NTFS and FAT32, tools to compile C/C++ etc. Seriously, that’s not funny. So the first thing I will have to do is remove all the litter (or scroll through lists of useless crap at install time and deselect there).

Also, I can’t remember that I have been asked whether or not I wanted AppArmor installed. I don’t! SELinux has been in the mainline Linux kernel since 2003. I don’t want that to be removed and replaced with another solution. At least I would like to have a choice. (However, I do embrace that Ubuntu comes with AppArmor now, which is still better than Debian’s and Ubuntu’s ignorance towards SELinux or any other security implementations over the last couple of years.)  Although iptables is available, per default it’s disabled. But instead they have the cool “ufw” tool, a front-end to the netfilter firewall, as they call it. What it does is using OpenBSD’s pf syntax to create rules for iptables. I guess I should like that, because pf’s syntax makes a lot more sense than iptable’s. Unfortunately, I don’t like any “front-ends” messing with my settings. On Linux, I expect to use iptables as the common standard. OpenBSD’s pf (packet filter) can be found on OpenBSD, NetBSD and FreeBSD. So again, I have to remove unnecessary stuff.

Furthermore, in the enterprise section, I would expect thoroughly tested support for DRBD, GFS2, heartbeat, haproxy et al in order to build solid clusters. However, GFS2 is marked experimental in Ubuntu 10.04. So it has not been tested properly in Ubuntu, which is a shame, because it has been on RedHat Enterprise Linux, where it comes from. And as GFS2 is one of the very few cluster-aware filesystems on Linux, I kind of would expect that to be thoroughly tested (GFS and GFS2 have been out there for years). Or why did Ubuntu Server claim to be an enterprise Linux again? Oh right, must have something to do with the Gentlemen’s agreement between Amazon and Ubuntu to exclusively ease access to Amazon EC2, a proprietary “cloud” (don’t get me started on this term). So what Ubuntu users get is an increasingly strong mix of GPL stuff with proprietary extensions.

Again, I’m not saying that Ubuntu is bad. And I really do appreciate Mark’s effort to create a very good desktop Linux, which keeps up with recent technology development and hardware support. For the server, on the other hand, I am a bit more conservative. I don’t need half-baked support for quite literally everything there. Nor do I need the very latest libraries and features. What I do need is robustness. I prefer a minimal base installation (which includes standard tools and security measurements) and to take it from there. And I prefer things which have been really thoroughly tested. Experimental is a word I don’t really want to read there. Bottom line is that Ubuntu Server feels a bit like an experimental server Linux for beginners.

That, my friends, is why I’m not fond of Ubuntu. Admittedly, I got a bit carried away here. And I do know that many of you (especially the Ubuntu “fanboi” folks :P ) will disagree. At the end of the day, every systems administrator has got their own preferences. Each to their own. No Ubuntu for me (unless I’m being forced to). :-)

Now bring on the stones you want to throw at me…

  1. 2 Responses to “Why I’m not fond of Ubuntu Servers”

  2. I 100% agree with your expectations for a server. And there is another point
    you did not mention. You say that packages are half-baked. Sometimes it’s
    even worse. Since it inherits debian’s packages, many of them are simply full of unfixed
    bugs, because they refuse to fix bugs in a stable release. I had to explain
    that to several customers who had trouble with a very old version of haproxy shipped by default
    in debian. I told them that fixes were available, they replied “no, I’m on
    the latest version” (of their distro). It turned out that the package maintainer tried hard
    to push the fixes in mainstream but they were refused because “not critical
    enough”. Sure, a non-working load balancer at the entry point of your infrastructure is not a
    critical problem… And I had the same experience several years ago with a
    version of gcc-3.0 which emitted bad code and had miscompiled the apache package. They
    decided not to fix any of them since the next release would upgrade gcc
    anyway. What a nice consideration of their users… So now I know that debian must never be installed
    on a server otherwise you get a massive amount of unfixed crap, along with
    some “innovative” security fixes such as the openssl random issue you talked above. Surely
    the same happens with ubuntu since it inherits their packages.

    I tend to find CentOS sometimes a bit heavy but at least it relies on
    thoroughly tested code. You might also like Slackware which looks a lot like
    FreeBSD and which you have 100% control over. This is very appreciable on a server. The only
    caveat is that there is no “LTS” release.

    By Willy Tareau on May 17, 2010

  3. On the “LTS” subject, I’m not sure what that’s worth anyway. That kind of defeats the purpose of staying absolutely up-to-date, which apparently is what Ubuntu “fanbois” get so excited about. ;)
    If they want to reduce their feature update cycle to once every 2 years, they can as well go for CentOS or other conservative distributions.

    Thanks for you comment, by the way, Willy. Nice to see a celebrity commenting on my blog. And thanks for haproxy! Rock-solid piece of excellent software!

    By admin on May 18, 2010

Post a Comment

*