Now, I don’t want to spread rumours or create unnecessary panic. I don’t really doubt that the CentOS team will somehow manage to increase their pace a little bit, and their latest announcement regarding continuous releases (essentially “backported” security updates) goes into the right direction, if they can for once stick to their promised timelines.

Nonetheless, I need stability and consistency. That absolutely entails security updates, quite obviously. From my personal and professional experience, if it has to be Linux, RHEL-derivates are by far the best bet for enterprise environments. So, just in case, what else is in store for paranoid people like me who have committed to using RHEL and its forks/clones? (where FreeBSD sadly isn’t an option)

It’s not that I never heard of it before, but somehow I dismissed it as, well, scientific or academic: Scientific Linux. Probably I’m not the only one who was misguided by its name. The obvious questions are: Is it fully binary compatible with RHEL? What additions or modifications are included? Has anything important been removed? Who’s backing and supporting it? And: how up to date is it?

I had a close look at the website and repositories, and I was in for a very pleasant surprise actually: Scientific Linux is maintained by major scientific organisations, hence the name, and claims full binary compatibility with only very minor changes to the base installation of RHEL 6. The main goal of Scientific Linux (or “SL”) is to provide their users with an easy to customise RHEL-clone, which can be wrapped up into entirely new distributions (“Spins”). Also they provide a bit of entirely optional stuff, basically additions to the original. The important thing is: SL is a full clone, and it is entirely built from RHEL’s source RPMs (which can be found in SL’s repository of course, as the GPL requires).

How long has it been around, and how likely is it that it will last? Again a nice surprise: It’s actually older than CentOS, by about one year, and first appeared early 2004. And obviously it’s got the resources (and manpower) to keep it going. Their updates are released much faster than CentOS’s. For example for 6.0:  RHEL Nov/2010, SL Mar/2011, CentOS Jul/2011.  For 6.1: RHEL May/2011, SL Jul/2011, CentOS not yet available. Or for 5.7: RHEL Jul/2011, SL and CentOS both not released yet. However, SL has all the upstream updates available. The latest updates are from yesterday and include the issues in DHCP, Firefox et al, as announced by RedHat two days ago. None of these recent updates are in CentOS’s CR repository, despite the two-day old promise that said updates would be made available via CR within 24 hours. The latest CR updates are 5 days old. For me personally it doesn’t matter, because I’m not affected by the issues which were fixed since then; but others may be.

Don’t get me wrong. Five days is not a long time, especially as rolling everything out across the board will take a few days as well, given typical enterprise planning pace and decision making. However, it’s not really continuous and not in line with Karanbir’s own guesstimates.

Anyways. Time for some hands-on impressions. Or, wait, what do we expect to see in a binary-compatible RHEL-clone, which we haven’t seen in CentOS already? Exactly, despite some branding changes it is the same. The installed packages are identical as well, except the tiny differences mentioned above. In fact you could go install CentOS 6 and take the SL update repositories to update to more current packages (or SL 6.1). I’ve done that to prove my own theory. No surprises there. It’s not the most elegant way of updating CentOS, but certainly even less intrusive than using other third party repositories, and lesser trouble than building your own updates from RHEL’s source RPMs, believe me. Plus, SL’s updates originally come from RHEL.

Or… well… you could of course switch to SL altogether, given that you get essentially the same product, with shorter update delays. Taking the background, history, manpower and all that into account, the seemingly academic distribution actually looks a lot more enterprisy at the moment than CentOS does. I hope Karanbir Singh and his team can fill that gap very quickly. I’m not too keen on switching to SL, and I know that the CentOS team is very committed and doing a great job. But if we can’t get at least latest security updates for CentOS in a timely manner, it might become inevitable to switch.

That doesn’t mean that I will hastily switch the distributions of ~100 installations; nor should anybody else rush that decision. But come the time that we put 6.x in production, we might as well go for SL then. However, that’s certainly not going to happen this year any more, and requires careful side-by-side evaluation first, which is starting as I write this, and will last for months. How close we get to switching to SL seems to depend solely on CentOS; if they manage to get back to normal pace, this whole consideration may become obsolete. It’s good to know though that there are viable alternatives if need be.

So anyways, enough waffle here. Those of you who are interested, should follow this link: my step-by-step guide on how to set up a FreeBSD PV guest from scratch, including pygrub support. The tutorial will walk you through all the steps required from setting up an empty stub, over creating a HVM guest, to transforming that into a PV guest (or even hybrid, if you wish).

What is GlusterFS, and what is it not?

You can think of GlusterFS as a RAID device, which works across the boundaries of a single physical disk array. Take RAID-1 for example, which mirrors data between two identical disks. In GlusterFS’s jargon, you run two bricks in replicate mode, where a brick is defined as storage in general terms; it can be an array of disks (which could use RAID), a single disk, a partition, a directory. Anything that can be mounted into your filesystem hierarchy qualifies as a brick. The key feature of GlusterFS is now, to treat bricks on different physical machines as one volume, which can be accessed by any number of clients. It can be mounted either via Fuse/GlusterFS client, or even via NFS or CIFS/Samba.  You can use RAID-0 style striping for read speed, RAID-1 style mirroring for real-time replication, RAID-10 for both, or you can go beyond any of those and spread the stripes or mirrors across any number of bricks. 4-node replication? No problem at all. GlusterFS gives you truly enormous flexibility and performance when it comes to making large amounts of data available across multiple nodes.
Since version 3.2 (if I’m not mistaken), they have even added GeoReplication, which allows a Master/Slave setup, where the slave can be a local or remote site. Be it for backups or to have a standby version of your application in a different geographical location… it’s possible. Due to the fact that GeoReplication does not require locking or synchronous replication, the network speed to your remote site isn’t that important either. It copes well with it.

This sounds very different than for example a DRBD/GFS2 or DRBD/OCFS2 setup, doesn’t it? And indeed it is! GlusterFS, unlike DRBD, is not providing a block device. What it means is that it compares hashes of files, and if files on nodes differ (for example after a failure), it will copy entire files across, not only the changed blocks. In normal day-to-day operation that’s not a big problem, in particular as you get a lot of flexibility, which is unmatched by other solutions. Where it does make a difference is during recovery. More on that in the Caveats section.

A variety of different connectors

I mentioned earlier that you can use a couple of different ways to connect to your GlusterFS volumes. First, there’s their own GlusterFS client, which uses the kernel’s Fuse layer. This client is Gluster’s recommendation, if your workload requires a high amount of fast write operations. If your workload is more about reading small files quickly, they recommend NFS. (The NFS server is part of the glusterd daemon, which serves the volumes to the clients.) Samba/CIFS is probably mainly targeting Windows clients.

All these connectors have their advantages and disadvantages. You want to test that thoroughly for your particular workload. Also, in SELinux environments, you will require some tweaking of your policies, if you use the GlusterFS client, whereas NFS is a lot more straight forward (don’t forget that apache needs to be allowed to access NFS directly if that’s your intention; setsebool -P httpd_use_nfs=on is your friend). I know most people find it easier to switch off SELinux altogether, but for me personally that is never an option. I’d rather spend hours tweaking the SELinux policies, if necessary. Anyhow, the bottom line is that both NFS and CIFS make GlusterFS very attractive for platforms beyond Linux. FreeBSD for example, although I’m not sure if the native client has reached a production-ready state there yet; I shall give that a spin soon, and in the meantime NFS will do.

Performance

As a rule of thumb you can say that high-availabily, robustness, scalability etc always come with a downside: write performance. During write operations, all nodes need to be kept in sync, which means that the weakest “link” (or slowest disk for that matter) together with some locking and network/protocol overhead determines the actual write speed. That is normal. (Note: pure throughput must not be confused with the time it takes to actually be able to access a file on a different node than it was written to)

For that reason you can never expect a high availability file system to solve all your problems. There’s no such thing as “one size fits it all”. Your application need to be cluster/HA aware. In practice that means you will have to select carefully which type of information you store where. This is of course true for GlusterFS, too. However, when it comes to read performance, GlusterFS is actually very fast. Not as fast as a local block device, obviously, but personally I wasn’t able to tell the difference between native NFS and Gluster’s NFS implementation. The GlusterFS client (fuse/glusterfs, not NFS) however seems to be a little bit slower reading data, while being faster writing. It really depends on your workload. Bottom line is: GlusterFS is fast and flexible, which alone is a big plus over many other solutions. For maximum read performance you can of course use stripes (data scattered across multiple nodes), which the glusterfs client connects to simultaneously. It’s kind of obvious that in particular big files benefit from such a setup.

Caveats

If you intend to deploy GlusterFS, you better plan a serious amount of time for the first tests, integration into your setup, including benchmarks and failover. GlusterFS is powerful and not too difficult to get started with, but you’ll soon run into various rather specific questions, which aren’t documented well (or not at all). Quite frankly the online documentation is poor, or rudimentary. Obviously Gluster, a business, wants to sell their expertise, and there’s nothing wrong with it. So be prepared to browse mailing list archives or hang out in #gluster in irc.freenode.net or so.

GlusterFS has matured a lot over the last years, and you certainly don’t need to be worried about losing data (after all it’s filesystem based and you can copy anything out of the bricks’ directories directly, if you wish). However, some major issues and pitfalls still exist.

• If you reintroduce or replace a node, which was either faulty or offline for a while, the self-healing will transfer entire files back from up-2-date nodes onto the reintroduced one. This consumes a lot of network bandwidth, and even worse, CPU load (possibly due to the hash comparison). If a GlusterFS brick lives on a box together with other services, you will experience a significant performance hit.
• Large files are locked while being replicated. In practice that means that you really can’t use GlusterFS as a backend for VMs at the moment, unless recovery always happens in a controlled manner at times where you can afford to shut down running VMs for the entire duration of the healing. That somehow defeats the purpose of a high-availability storage cluster.
  However, a GlusterFS engineer has told me earlier today on irc.freenode.net that this issue will be tackled in GlusterFS 3.3, if not earlier. Only a question of months, I suppose.
• You absolutely must synchronise the system time of all bricks. If you’re not doing that already anyway, do it before deploying GlusterFS. (use NTP for your own sanity)
• Make sure that the bricks of one volume are of identical size and that you don’t by mistake fill the disk space by other means. I had a situation the other day where I wanted to replace a brick; what I didn’t realise first was that someone set a disk quota on the new brick. Consequently it stopped writing long before all data could be copied. However, GlusterFS did not warn me, nor did it report an error; it actually confirmed successful migration, although only 1/3 of the files were transferred!
  Clearly the lack of accessible disk space wasn’t GlusterFS’s fault, and is probably not a common scenario either, but it should spit out at least an error message. Imagine what would have happened if I had taken the other node offline after allegedly successful migration! Total mess.

Presumably none of these things would have happened, if I had taken their commercial offerings.  Those of you who prefer D.I.Y., better be prepared to spend a serious amount of time to fit it into your use-case and more importantly… monitor it closely!

Summary

GlusterFS has made a lot of positive progress over the last 2-3 years. It’s very easy to get started, especially on RHEL/CentOS, and it offers enormous flexibility and opportunities. The new CLI makes basic configuration much much easier than it used to be before. With a few simple commands you can create your volumes (on multiple servers, aka “peers”, simultaneously). You could say that it’s actually fun to use GlusterFS!

However, if you (like me) are looking at GlusterFS as a backend for Xen or VMware VMs in order to facilitate live-migration and resilience, you will probably need to wait for version 3.3, unless controlled recovery with planned downtime is an option for you. Might be worth keeping an eye on their Git repository (I certainly will). While using it to serve files for all sorts of things already, I’m really looking forward to using it as a backend for Xen soon!

Version 3.3 brings some other new promising features, too… Unified storage, object storage… I see memcached on the list of dependencies… looks promising. Beta 1 is out, by the way.

So where’s the but? Here it comes: …but if something unexpected happens, you are seriously screwed. Here are a few examples from the past couple of months.

Changing a NIC, which is also management interface, of a pool server — This was about the worst nightmare I’ve ever had. What you’d expect to do is: shutdown the machine, open it, replace the NIC, close it, switch it on again, wait for it to boot and start the VMs, done. What really happened is: I had to actually wipe and re-install the whole box, because there was apparently no documented, reverse-engineerable, or otherwise known way to just simply change the MAC address somewhere, because that is managed by the pool master. Now, as the NIC was broken, the master wasn’t able to communicate with the pool server any more (not even on the second NIC, because that was not the management interface). Attempts to change it failed. Not even the “xe” tool was functional any more, so I couldn’t really gather the UUIDs in order to search through configurations etc. The master refused to talk to the pool server, and the pool server with the broken (and afterwards replaced NIC) refused to let me change anything, because that should be done on the master. Catch 22.

I consulted the official support forum, but nobody knew an answer there either. I’m sure there is a way to change it easily. After all it’s a Linux box with a modified Xen, but still not an unaccessible blackbox. Hang on… actually it felt a bit like that. I would like to think that Citrix certainly knows an easy solution, but as I’m not paying thousands of Pounds for a product, which is almost entirely based on free software, they of course kept quiet. (The bloody toolstack, which complicated things, is their own development, by the way.)

End of that experience was that I had to remove the server from the pool (XenServer would then wipe the box, so you can’t re-join the pool later, either… awesome). After a clean setup and restoring all the VMs from previously created snapshots, the machine was finally able to join the pool. That was 6 hours after the NIC broke. Fortunately all VMs have an identical twin running on another machine, so it didn’t cause downtime (except a few minor hiccups while I was fiddling about with network settings). Otherwise all websites/applications would have been offline for 6 hours.

Without the XenServer toolstack, I could have resolved the issue within 10 minutes, which includes all of the steps mentioned earlier (what I would have expected).

I learned my lesson from it. As live-migration of VMs isn’t really necessary in most cases (my customers’ applications don’t benefit from it), it’s actually better to not form pools of your servers. Disconnected standalone servers are a lot easier to maintain and you don’t risk side-effects with pool members, because there aren’t any. The only real downside is that VLANs need to be configured individually on each server. Same applies to shared resources (NAS etc). But that’s fine.

Another almost unbelievable example is deleting snapshots. I create them all the time, because if something goes wrong, or someone breaks a VM setup, you want to be able to roll back to a previous version. Snapshots are one of the biggest advantages of virtualisation. A whole VM can be brought back to an older state within seconds. Or you can export it and reimport it elsewhere, clone another instance from it, work there, swing later. Anyways, if you use that feature often, it fills your disk (even the huge disks you get nowadays). So you regularly delete them and get your space back. Right? Nope, wrong. With XenServer you may or may not get your space back. When your monitoring tells you that you are running out of disk space, although you haven’t done anything but rotating snapshots in a while, you scratch your head in disbelief. Well, at least I did. Unfortunately, the official documentation confirms my observations. When I first read that reclaiming space causes downtime, I wasn’t sure if laughing or crying was the best course of action.

In a production environment, you can’t just go ahead and suspend VMs just to get space back. Even if you only reduce performance (without causing downtimes, as we’re running twins of everything), you need to make affected customers aware of it. And how do you explain that? “Sorry, Sir, I need to suspend your service, because I need to delete old snapshots.” They’ll think you’re taking the piss.

Again, this “feature” is brought to you by Citrix’s toolstack, not Xen. If I decide to delete an LVM-based snapshot of a running VM on Xen, I can do that any time. No need to suspend anything or to manually reclaim free space afterwards.

My favourite subject is VLANs. I don’t know how many hours I’ve wasted trying to find what I did wrong, just to figure out in the end that it was not my fault… Citrix apparently manipulated the bridge code and never really tested it. You have to actually install ebtables (iptables for bridges, if you will) to work around that issue. I observed exactly the same thing as the poster there, and many others did, too. Their forums are full of problems related to VLANs and NIC bonding. Problems get worse with two NICs. VLANs may work out-of-the-box on both, only one, or none of the NICs. Apparently it depends on the used NIC (well, I’m assuming here that nobody uses old NICs without VLAN support any more nowadays), which of the NIC is management interface, and a couple of other factors like weather, mood etc.

Once you know about the workaround mentioned earlier, you can solve it. But now, when you update your XenServer version, you can’t rely on Citrix. They might just remove the required kernel modules so that ebtables wouldn’t work any more. Sounds unlikely? Well, reality is that ebtables did work until XenServer version 5.5, but in 5.6 the kernel support was removed (see last post here). To fix it, you end up downloading the XenServer SDK (which includes all the open source bits they are using) and recompile the kernel yourself.

I won’t go deeper into this subjcet, but there are several issues with bonded NICs as well. And the management interface can never be on a tagged VLAN. All those are restrictions/problems solely related to Citrix’s stuff. Linux itself lets you create any combination of bonds and VLANs on as many interfaces as you want to. Unfortunately, you need to unlearn all about Linux network configuration, because if you try applying your knowledge, XenServer will overwrite your configuration as soon as you reboot (best case) or use its API or Windows client to manage NICs/VLANs.

I could go on and on and on. There are many other quirks like being unable to shutdown a VM when for some reason it can’t attach to a VNC console (but keeps trying, although you absolutely don’t need a console to shut it down); having a “force” option for many commands, which is useless, because it doesn’t force anything; being unable to remove stale shared storage; having to work around limitations which would for example disallow you to build a pool with an i7 920 and an i7 930 server; and quite a few more, which are of minor relevance in a production environment.

Don’t get me wrong. If you dig deep enough, you will find problems in any similarly complex software. And Citrix’s XenServer is not a bad product at all. Much of the functionality like live-migration isn’t available in VMware’s free version ESXi, and said free version doesn’t run on top of CentOS but on a custom Linux, which officially you can’t access via SSH (there are ways though, but you can’t expect any support at all). Also, XenServer’s GUI is self-explanatory and easy to use — and certainly one of the main reasons for using XenServer, because whoever is going to use it after you set it up for them, they won’t have many problems getting started.

However, if you don’t have lesser knowledgeable people using it later, and if you don’t mind going the extra mile, you probably get most flexibility and reliability if you set up Xen instead (the vanilla or “real” one, not XenServer). XenServer doesn’t really provide any additional functionality, which isn’t available in Xen. (Some people even say the opposite is true, and you only get full Xen functionality if you purchase XenServer’s extra licenses; I wouldn’t go that far.) It does add convenience with its GUI and toolstack though, which you’d otherwise have to implement yourself — snapshots, shared storage use, starting up any type of guest OS etc. Most of those things aren’t exactly rocket science; only a few are a bit more tricky. But you can script/automate them as you please and you don’t need to expect any bad surprises caused by 3rd parties.

For example, I disabled Xen’s bridging code (by commenting out a single line in their scripts) and do the whole network configuration with standard OS tools, keeping it independent and consistent for future updates. (More details here.) Snapshots are easy enough to do with LVM, too. Live-migration I haven’t tested yet, but it doesn’t look too difficult to do either. (We don’t really need that feature here anyway)

What I’ve struggled with was getting different OS running, namely FreeBSD. But now that I have sorted that out, I can easily clone and fork more FreeBSD VMs on the vanilla Xen machines. Hence, Citrix XenServer isn’t providing any benefits there either.

As you can see (and as the title suggests), I’m considerably fed up with XenServer’s quirks; some of them are too huge to accept them in production environments. Consequently, we’re going to “migrate” back to Xen, where we can. (Admittedly, in some environments we won’t be able to do that for another year or so.)

Once you’ve worked out how XenServer stores VM backups (yep, they did their own thing there too, and the format is really stupid), it’s not too difficult to convert them. I’ve done that for both CentOS and FreeBSD XenServer images. They run smoothly on vanilla Xen after converting them back.

Once again the “keep it simple” motto wins. Additional toolstacks and bloat cause more problems than necessary, and the manufacturer turns out to be the only one benefitting from it — as often is the case. So long, XenServer — Hello Xen!

(Update: Only three hours after I published this, one of our XenServers started refusing to create new VMs from templates…)

(Update 2: It’s cursed. Yesterday I was all of a sudden unable to attach any block devices, hence I was unable to start new VMs, reboot existing ones, or increase storage. I’m not the only one, who faces that problem and does not get any help from the experts at Citrix.)

(Update 3, Aug 25th: Done. Last weekend we’ve transformed the last remaining XenServers to vanilla Xen. Thanks to the twin-design, this went through without any downtimes whatsoever; was a major piece of work though, but certainly worth it. Chapter closed. )

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 ) 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…

First of all, questions like this, which do not tell anything about the author’s aims and intentions, are not answerable. One could as well ask: Ferrari or Landrover? I’d suggest taking the Ferrari for the next cross-country rally, whereas the Landrover is definitely the best choice for the F1 track. Anyway, you got my point.

This blog post has potential for flamewars between the lovers of BSD and Linux, and also between lovers of either of the Linux distributions. So let me emphasize that this is my personal opinion.

Let me kick off with two certainly arguable statements and take it from there:

• Production environment: The operating system of your choice should be the one, which you are most comfortable administering, because it’s your job to secure it to the best of your knowledge and solve upcoming issues within the least possible amount of time and effort.
• Experimental environment: Do whatever you want to. Experimental environments are meant to gain more knowledge, experience or compare it with other environments.

In this context, let’s be clear about this: Any server that is accessible from any other untrusted machine (aka Internet), is a production environment! Why so? Because it could easily be turned into a threat to others (if not secured properly), which can cause trouble with your ISP or with third parties, which leads to costs, and in the worst case lawsuits! This means: Although you run it for your own pleasure, you have to ensure that your pleasure does not become a nuisance to others — be it by your mistake or by third parties taking over your server. Should be common sense, but apparently it’s not.

Now that we’ve understood that the playground approach is misplaced in a server environment, you may want agree with my previous statements.

“I hear you, but which Linux/BSD/Unix is the best for which aims?” Let me first briefly explain how things have evolved and why a FreeBSD user will have problems recommending any Linux distribution.

Unlike any Linux distribution, which strictly speaking is merely the kernel bundled with a bunch of (mostly) GNU tools and programs, FreeBSD is a real operating system, where all core elements are maintained by a central “authority”, the FreeBSD Project (which is funded by donations collected by the FreeBSD Foundation). That ensures a high level of integrity and as a result stability. FreeBSD (like NetBSD) is a fork of the original BSD by the Berkeley University, which was derived from AT&T Unix. Nowadays you find three major BSDs out there: FreeBSD, NetBSD, and OpenBSD (which was forked from NetBSD). They are maintained by their core teams, and cross-port various functionality whenever suitable (e.g. OpenBSD’s packet filter pf). When you install any of these BSD’s base, you will end up with a working operating system and all core tools needed to administer it.

When you install any of the approximately 250 different Linux distributions out there, you more precisely install a third-party bootloader, the Linux kernel, and a whole bunch of third-party (GNU) tools and software. What exactly you end up with, depends on the taste and policies of the distributors. It should be easy to understand that a distribution which focuses on including the latest drivers and software in every release, cannot be as stable as a distribution with a rather long release cycle that has got a big number of enterprise-level users. Essentially they are all the same, but the collection of software and tools (and their branding and look&feel) differs. As various GNU projects have got a lot of cross-dependencies (e.g. PHP with GD, ImageMagick, MySQL, to mention a popular one), it is a tedious and time-consuming task to bundle the right versions with each other in order to get a stable system.

Or in other words: A Linux distributor has to ensure that their selection of third-party software form a stable system, whereas the major BSD derivates maintain the core system themselves. In the BSD world, third-party software isn’t part of the core functionality. Hence BSD doesn’t depend on the good will of other software projects. However, you can of course get a lot of third-party software, too: The portstree (in FreeBSD for example), currently contains over 20,000 different programs, carefully selected and tested, and linked against other ports and/or the core libraries. As the latter are provided by the BSD maintainers, you can be sure to have a solid foundation.

If you look at SELinux, it was a rather chaotic uncoordinated situation in the beginning: SELinux was developed and maintained by the NSA, and was not part of the kernel initially, but you could compile it as a kernel module (don’t get me started on kernel modules on a server). The tools to actually use it are part of the GNU coreutils package — third party software, strictly speaking. When SELinux reached a stable status and was supported by the Linux kernel, some distributors decided to include and activate it by default (Fedora, RHEL, and CentOS), while others didn’t make use of it at all (Debian, Ubuntu). So security was a matter of the distributor’s taste. That happens when there’s no central “authority” which ensures continuity, and coordinates kernel (and related) development. A sad result was that people didn’t want to get used to SELinux, because it wasn’t (and still isn’t) accepted as a standard and must-have. Even nowadays you read recommendations like “use ‘setenforce 0′”, which effectively switches SELinux restrictions and its security improvements off! As far as I know, only RHEL and CentOS install and activate SELinux and its utilities by default. They are also the only mainstream Linux distributions which activate the iptables firewall by default, and apply a restrictive ruleset, by the way.

You’ll still even find Linux distributions, which allegedly target the server market, without SELinux utilities installed. How can you ignore huge security enhancements in a server environment? Ah right, the distributor has got a different taste and would probably add no other security tools.

Apologies for my sarcasm. Linux is not all bad, but you must not expect any distribution to be as rock-solid as any of the three main BSDs. Let’s check out which Linux is the least of all evil

The first commercial distribution back in the early 90′s was Slackware, which nowadays is only being used on a minority of Linux-based servers. Slackware is sort of considered geeky.

A couple of years ago, the big players were RedHat Linux in the English-speaking countries, and SuSE in the German-speaking areas. That has changed. RedHat Linux for the commodity market does not exist any more (it is now the community-maintained Fedora Linux, supported by RedHat). RedHat’s own Linux distribution is RedHat Enterprise Linux, which obviously targets enterprise-level customers, who are willing to pay for licenses and professional support. For those who don’t, CentOS as a de-branded RHEL copy has become more and more popular. It claims 100% binary compatibility with RHEL, without asking for license fees, and without offering professional paid support. The target group for both RHEL and CentOS are enterprises and server installations, whereas Fedora targets the desktop market.

Especially in Germany, Debian Linux is also widely used. The easy package management with apt-get certainly played an important role in its success. Fedora introduced yum to make RPM package management as easy. (Open)SuSE seems to lose market share. YaST as their package manager could be one reason.

Ubuntu was started as a Debian derivate just a few years ago, and initially aimed the desktop market trying to keep up with current hardware drivers and new features. Apart from its LTS (long term support) versions, which are being released once every two years, the life cycle of the half-year releases is very short. However, Ubuntu has experienced great success and played an important role in making Linux a widely accepted desktop operating system. In my opinion it is not the best choice for server installations where robustness is more important than introducing the latest features and device drivers, though. It also lacks SELinux utilities in its default installation.

For the tough cookies, there’s also Gentoo Linux, which covers kind of a niche market: people who believe in stability by compiling everything from scratch (and most obviously took BSD as an example), but who are reluctant to leave the Linux terrain towards BSD. Why am I saying this? Simply because compiling from scratch is rather not suitable for newbies, but all the effort still doesn’t provide a BSD level of stability in a Linux environment as too many bits and pieces are actually third-party software.

Personally, although I used to prefer Debian (before SELinux became de facto standard), I cannot take that distribution seriously any more. They made a terrible mistake when they “patched” the OpenSSL library, turning all generated keys and certificates built with them into garbage (or what do we call keys and certs which are created with a predictable random generator?). In my opinion, it shows pretty well why a more centralised approach of maintaining core components is better. There’s a thin line between diversity and mess. When distributors start patching core components just like that, rather than contributing code to the upstream projects, the diversity will soon equal mess — and introduce absolutely unnecessary distribution-related security flaws.

In my personal opinion, CentOS is the Linux distribution for a server setup (or RHEL for those who rely on professional support), whereas a desktop or laptop user’s best bet would be Ubuntu (if you can live with a short release cycle and are happy to update your whole system often) or Fedora.

However, I do prefer FreeBSD for servers (as you could easily tell after reading all this).  And on a desktop/laptop, MacOS is my favourite. (I know that paying for solid software is political incorrect nowadays, but at least it has a reliable — FreeBSD/Darwin — foundation!)

Under very high load and many concurrent read requests (I set up the company’s mail server with ZFS and root from ZFS), the two disks in the Raid array repeatedly lost sync, forcing an automatic re-silvering (auto healing) process to be started, which blocked the system as everything (except /boot) was running from that ZFS arrray. As far as I figured out, the system halted entirely as there was another inconsistency occuring while the re-silvering was still in progress.

I would have investigated further, if it wasn’t a crucial production machine. And that kind of traffic is very difficult to simulate under laboratory situations (maybe I can do that when I have more time). So I had to revert back to UFS as the downtime had to be minimized. It’s a shame, really, because I love the features ZFS offers. On my private server it runs very smoothly, but traffic, load and I/O are not comparable to the mail server in question.

After having set up the minimal FreeBSD and doing some tuning (such as creating the ZFS volumes), I ran some tests. You won’t believe me, but writing a 10GB file (/dev/random to the ZFS volume) resulted in a transfer rate at about 160MB/sec and reading (cp testfile /dev/null) was done at a speed of more than 270MB/sec!!

To be continued…

Consequently we asked for quotes on bigger NetApp devices. Unfortunately, they cost more than a good car. The investigation on other solutions began…

After doing some research and testing as well performance as failure behaviour, the decision was made: I will setup a storage cluster based on i386 hardware and GlusterFS. Its speed was quite impressive. And also the fact that mirroring (for data security) and striping (for performance) can be combined, is very convincing.

We will start with two huge servers which run partly in mirrored and partly in striped mode. The only thing which needs to be tested before hand is, if FreeBSD’s UFS in combination with its snapshot feature makes sense here (this could be a bit tricky). If it works, this solution will be as good as the proprietary offer. But it costs less than 1/5!

I will keep you posted.