As CentOS is currently in a bit worrying situation with security updates arriving late, and major and point releases being months behind, it’s probably a good idea to have a look around and check what else is out there that claims to be binary compatible with RHEL. With more than 100 active installations of CentOS, I just have to make sure that we’re ready for the worst case. Obviously purchasing subscriptions with RHEL for all those installations is not an option; the customers can’t possibly agree to the significantly higher costs that would force on them.
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.