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.

Read here, what recently happened to many Twitter employees, including those dealing with confidential documents, which now have been published on Techcrunch.

The English translation of the original source can be found here.

These are the two lessons to learn:

• Do not use third-party services to store confidential information!
• Use passwords and security questions, which cannot be guessed easily!

A password must:

• not be shorter than 8 characters
• not contain only letters (better mix with numbers and special characters!)
• not contain natural language (i.e. words which can be found in dictionaries)
• not contain names, birth or anniversary dates, parts of (previous) home addresses, your favourite colour or hobby
• not be re-used on a whole bunch of different web sites
• not be stored in your email inbox (if a bloody stupid provider sends you non-temporary cleartext passwords, delete them instantly from any online media or computer, and change the password, unless you want the next worm or trojan to forward them to criminal parties)

Don’t think password hacking happens to the big players only. Those of you who have been running their own (web) servers for a while, shall have a look into the auth.log and access.log files (for a start). Hopefully that opens your eyes: Automated password cracking and site hacking attempts are no exception. They happen regularly to all of us. And they happen to all third-party services you use, but there you have no influence whatsoever, hence cannot do anything except making your passwords and security questions as difficult to guess as possible!

Please help making people aware of the necessity of strong passwords. Just share this post via Twitter, facebook, or whatever social network you are member of. Thank you!