Those who know me will know that I’m a long term CentOS user – this actually started from my love of RHEL, back in my early Linux using days when I was running Red Hat 8.0.
Whilst it made financial sense for Red Hat to switch to making their product only available in binary form for their customers, at the same time I can’t help but feel this has damaged the appeal of Red Hat for geeks like myself – I’m no longer able to setup friends, family or customers without the funds for RHEL with a quality, enterprise-grade free (as in beer + freedom) distribution.
I do wonder if this contributes to reduced market awareness in the small business space and also whether it reduces the likeliness of geeks like myself promoting the software – after all, if I can’t run RHEL myself, I’m likely to look at other distributions and options and end up promoting those.
With the lack of a free Red Hat enterprise-grade distribution, there are only a couple options for wanting a Red Hat-style experience:
- Fedora – the community developed distribution that forms the future base of RHEL, a fantastic distribution in it’s own right, but with only 12 months support per release, not suitable for server deployments.
- CentOS – the community free re-spin of RHEL with their trademarks removed to make it legally redistributable.
I’ve been using CentOS heavily on my servers and Fedora on my workstations, however there are a number of security delays that are concerning me about CentOS which have been recently highlighted in an LWN article.
Essentially, the core problem is that the latest version of CentOS is still only 5.5, whilst Red Hat have had 5.6 out for some time, with numerous security updates in it that have yet to be released for CentOS…..
Having systems vulnerable to known exploits with no upstream patches is always a pretty serious concern to any system administrator…. this is leading me to re-think my usage of CentOS and to consider whether I should consider other platforms.
I’ve never been a huge fan of Debian in the past, but I’m considering giving it a more detailed look and try – Debian has the advantages of a strong community (like Fedora has) but without the limitation of a short support life – although then again, Debian’s releases and support spans are a little less rigid than Red Hat, which is somewhat annoying.
There’s a few server platforms that come to mind – Ubuntu LTS, Mint Linux, Debian, Open/SuSe or of course, Fedora.
The other option is that I could spin my own distribution – based on the number of custom RPMs I already build, rebuilding Red Hat’s update packages for my own needs wouldn’t be too hard, but I really don’t want to get caught up in distribution maintenance for the next 5 years plus it’s not suitable for customer deployments – so even if I decide that a custom built system is best for me, it still doesn’t solve the “what do I install for others?” question.
Maybe I need Fedora LTS – long term support for specific versions of Fedora – 3 or 5 years would be wonderful and meet the needs of server administrators.
This was tried once before, with the Fedora Legacy project, but it didn’t last long – possibly the goal of supporting *all* the releases was too much to reasonably handle, so an approach of selection even/odd number releases only might make it more feasible – I know that I’d certain be willing to contribute.
Anyway, this is a late night concerned system administrator brain dump about the problem, interested in thoughts and comments from others here about distributions they use/would consider in the server environment.
Well, as a long-time Debian user I can strongly recommend Debian (well over and above Ubuntu LTSes; I can explain why at a later date in detail if you care to ask) — but I’m also not a full-time Sysadmin and I therefore have no real experience in explaining the differences between the two systems.
Debian’s release schedules are reasonably predictable — there is one release every 2-3 years (24 months, almost to the day between the most recent two releases), and the old version of ‘stable’ remains supported for at least a year after the new version is released (so you get plenty of time to plan migrations if that’s what you need). Basically, planning to upgrade your systems is more than predictable enough in the majority of cases.
There’s also an official backports archive now, so if you need to track the bleeding edge for certain packages, you can do that whilst not breaking your system.
Finally, wrt security, the security team provide security updates for three distributions (oldstable, stable and testing [the version which will soon become stable]).
— Of course, choosing Debian means learning another package format, which isn’t necessarily a bad idea, but if you’re so sold on RPM (you shouldn’t be), perhaps SuSE is what you should be looking at.
I’d love to know why people choose Debian instead of Ubuntu LTS?
Two reasons. The first is stability. With Debian, releases are made once the distribution is completely stable: their criterion for this is that there are no known release-critical bugs in the ‘main’ archive and that all the release goals have been met. The first part of this criterion means that the system is likely to be highly bug-free upon release (people use the distro in its ‘Testing’ form before release to make sure this is so). On the other hand, Ubuntu LTS is *nothing* more than a specially-marked edition of Ubuntu. So it’s just another one of the releases which are made every six months without fail. In my experience, this tends to mean that QA testing for Ubuntu releases continues for a considerable amount of time after the release is made.
Secondly, QA/support for Ubuntu only extends to packages included in their ‘Main’ archive, which is actually quite small (the vast majority of packages distributed by Ubuntu are in ‘Universe’). In Debian, *every* package that is distributed by Debian (‘main’, which is equivalent to main+Universe+a bit more in Ubuntu) is subject to support + quality assurance from the project. This means that whatever packages you install, you’re guaranteed security updates and bugfixes as they come in. No such luck with Ubuntu, unless you stick to the packages which are included in ‘main’.
I’ll also add: the packages that constitute Ubuntu’s ‘universe’ tend to come straight from the Debian Unstable distribution; this is the distribution for which Debian’s security team *doesn’t* provide security updates, and for which there is no QA/stability criterion.
I also thought about changing distributions due to not having access to Offical RHEL binaries, and CentOS taking too long, but I found that I wasn’t really happy with any other distribution. Most of these problems aren’t “really” problems, but rather personal taste and not something which makes one distribution superior to another.
I find Debian to be quite messy, for example, just look at the default Apache config shipped with Debian… some people like their configs to be “modular” like Debian does, but I dislike the way Debian has done it. There are other packages which have their configuration files broken down in a similar way. Also, I find it very annoying how Debian occasionally tries to help you with configuring packages. Eg if you install postfix or samba, it’ll present you with a small interface to help you get started. I’m sure there is probably a way to turn it off, but I haven’t really used debian enough to be bothered to look. I’m also not a fan of debs.
Ubuntu has the same problem, plus a short release cycle, which make it quite a bad choice for a server.
Fedora has too short of a lifespan, but I love using it on my Laptop, but again, not really ideal for a server.
RHEL and Gentoo are the only distributions I am really comfortable with.
Although most of my machines (virtual and physical) are running RHEL, a few of my VMs are running Gentoo.
I love Gentoo, its easy to add a patch to an ebuild file, and very easy to write a new ebuild, but it is indeed a lot of work to maintain, which isn’t great when using it on a server, but I’m OK with that.
So for a while now my other solution has been to build the SRPMS that CentOS are taking too long to release, myself.
I generally wait a couple of days or weeks (depending on the severity of the bug) in hope that CentOS get there before me.
As you know, most recently I just built all of the RHEL6 SRPMS so I can get the *-devel packages! I got inpatient after waiting for CentOS 6 for 4 months! :)
Indeed, I share some feelings there, Red Hat’s design for the distribution is my favorite compared to the other vendors.
I’m tempted to build packages myself like you’re doing, but then I’m stuck in a cycle of having to maintain them myself….
Maybe I should just build my own distribution again ;-)
I’ve written a horrible horrible script that rsyncs the SRPMS from RedHat’s FTP server, and checks for any new files then builds it. If it fails, I get a notification, so I can check it myself, so the maintenance isn’t that bad for me right now… but I’d much rather if I didn’t have to do it.
It only took 1 week to build everything on a dual AMD Opteron 248 box with 8GB RAM, I’m sure it’d take half the time with a better box :P
Hi,
Reading this interesting conversation I must ask:
Why not purchase RHEL subscriptions via a certified Red Hat Partner.
Self support, Standard or premium support packages.
Pls guide me here with your thoughts.
Rgrds
Joakim Holmer
Elva (Red Hat Premier Partner Sweden)
hi Joakim,
Sadly the licensing options don’t really cater to my needs – I can get a self-support subscription which is reasonably priced, but that only allows for one virtual guest.
I run around 20 virtual machines, which makes my entry level option the standard subscription at $1,999 USD, which is far more than I’d want to spend for my personal system.
TBH, I think Red Hat should consider offering free licenses for one server/unlimited guests to RHCE/RHCA qualified individuals – it would encourage continual use of their platform as well as probably getting more bug reports & fixes from geeks tinkering.
regards,
jethro
Well, I must say, the Fedora may greate useful for Personal Use, because it indicates the future of RHEL serials, or you may get confused when in futuer enterprise use ;-)