CentOS 5.2 review

So, what with the new job at datacash being very enterprise oriented one of the distro’s I’m working on is CentOS. I haven’t used it before so I wanted to install it at home and get a feel for this community created enterprise class distro.

Now reviewing CentOS is different for me, as it’s goals are rather different from the distro’s I have mostly worked with the last few years. After all, it’s meant for big-iron servers with rock-solid stability and not for general desktop use. So obviously I could not evaluate it on the same terms, but need to do so from it’s own point.

The first thing that hit was that the 2.6.18 kernel is too old to see my SATA drives (this is not a general thing, mine is one of only a few SATA controllers that are not supported by such an old kernel), luckily I do have a non-SATA drive too so I could load it without problems, but I would need to upgrade the kernel before I could see my other drive (which has all my data on it).
This is a major issue for users. Now I understand the older kernel is for stability – but if it’s meant for big iron, then my recent AMD64 motherboard not being fully supported must surely be an issue in their target market as well. That’s one mark down.
The second mark down happened when I wanted to double check the content of one of the partitions before wiping. Since it doesn’t see all my drives, it also doesn’t see the ones it does detect entirely the same way – so I wanted to ensure that I was erasing the right partition.
Turns out the busybox shell in the installer doesn’t have ls ! I could mount the partition to check, but I couldn’t check it. I figured out how to get a view by typing ./ and tab (others have suggested ‘echo *’ would work too) but this is a stupid shortcoming ! Why bother giving a shell if it’s crippled without one of the most well known and often used and BASIC unix commands ? Two marks down.

Third early issue was that it couldn’t pick up my 22″ LCD monitor – I have a backup of my xorg.conf file so this was fixable but annoying as I had to install in text mode. This one however I am willing to forgive for a big-iron distro (on a desktop system it would be utterly unacceptable as fancy screens are standard hardware there).

On the very next screen – it bombed out when it was supposed to format the drive. Cost me restarting the install and manually formatting (by now they’ve lost all but the most experience linux sysadmins, clearly this is not a system for junior tech staff)… so far my experiment was not looking heartening. But after rebooting I used
mke2fs -j /dev/hda2
to wipe it myself and retried the install – this time without CentOS having to do the formatting.

That brought me to a screen for selecting a bootloader, either grub or none-at-all… this is obviously a relic from when lilo was still included… it is also a majorly stupid idea to keep a useless dialog that should clearly have been retired long ago… CentOS was losing browny points faster than Robert Mugabe on the installer.

From there though the installer worked quite well. I don’t know if the graphical installer is better since I couldn’t try it, but the text based one is an area where CentOS should do some serious work as it creates a very negative first impression of the system. The installer reminded me very much of it’s ancient redhat 5.0/6.0 ancestor (before anaconda HAD graphics… and being text aside… seems to have been utterly unevolved since then.. Still I was determined to keep going and find out why this little distro is giving RHEL a run for it’s money – since it clearly wasn’t the process of getting it, I guessed it must be in what comes after, so on I ventured to find out what that would be.

Much like it’s redhat roots the system has a variety of package suites, including either gnome or KDE desktops and a very complete server selection (that is after all it’s major market). I chose a KDE desktop, and the server option (but not the server gui option). My choice not to include server gui packages was motivated by the fact that I am simply more comfortable managing servers on the command line, but this may not be for everyone. In it’s preferred enterprise market though, I suspect that this is by far the most common setup for server usages (Without the KDE of course but mine IS on my home desktop after all – I want to play with the server stuff here but it’s not a server).

Having made my choices, the main installer started, all this was pretty much identical to good old fashioned redhat style distro’s the world over. To my surprise these needed the entire 7 CD set, despite me only choosing two sets of packages – clearly the selections within sets are very complete as other distros ship quite functional KDE desktops on a single CD… then I remembered that these are usually liveCD’s these days which compress about 3Gb onto a CD and realized that with that considered 7 Disks for a similar setup from normal packages on an anaconda style installer was really not so surprising at all.
What surprised me was the absense of a Developer set of packages (as is common with Fedora and other redhat likes), though the server system installed most the scripting languages you could want (as they are often used on servers) it seems like CentOS is not at all interested in being a platform to program on, after all if they were they would surely have given the ability to choose a desktop and the usual dev packages and IDE’s like the rest.

Once the packages were installed, it was time to reboot. This at least, was relatively painless, with a nice graphical grub screen. The text based bootup didn’t bother me – after all I was trying an enterprise system and I actually dislike most graphical boots on Linux. Shortly thereafter the setup tool popped up and I could configure a number of items further. This is the same old setup tool we’ve known from redhat for years, while I was typing this though it timed out -clearly it assumes if you are not there, it should boot by itself.
And here I also realized that, alone among all the distro’s I’ve ever tried, CentOS did not let me create a normal user account during installation. Leaving me with only my root account, which refused to log in … not cool.
I ended up rebooting into single user mode so I could reset the root password.
At least that worked as it should have, and I could change the password and finally log into my new CentOS installation.

Thus far of course, X didn’t even work so next steps would be to fix this. This would not be easy because I also lacked access to my other drive, and I had stupidly placed my xorg.conf backup there instead of on the memory stick.
Finally CentOS was starting to show how it shines, having left me in a less than ideal post-install state, the system proved to be very nice and fully equiped for repairs and maintenance in record time even from basic states. This does correlate to frequent needs in the enterprise where many big servers may lack things like X entirely.

Yum may not be apt but I don’t get the complaints myself, the two are really pretty much functional equivalents and even their command lists are very nearly identical. I have always been able to switch between them easily and CentOS’s out-of-the-box repos worked fine for me.

I took the time while waiting to have a look around and started seeing the diamond behind the rough. The default setups were well thought out and though I installed all the server packages the system did not enable any (which is good). Essentially CentOS had skimped severely on desktop stuff but in it’s enterprise server focus, I could already smell the true potential. If only it had not been hidden but such a terrifyingly under-equipped installer.

So on to trying to fix the problems. I would need to try and get a newer kernel, so first thing to do is check for an updated official one. Yum has a glitch here for newbies so watch out: yum update does not do what apt-get update does. It doesn’t just update the repos but installs all updates too – so if you don’t want that, don’t use this command.
The command to just update repos is: yum check-update

Yum had an update available, but only to a later version 2.6.18
So that left me wondering if my SATA drive would be supported by the update – and with no real way to check without doing a big download and install first, well unless I went and dug through the kernel changelogs and even then I couldn’t know what patches CentOS may have.
I checked CentOS website, including much searching and could find nothing to tell me yes or no.

In the end I downloaded the kernel package for Fedora 9 which I reckon will let me get my system working the way it should.
Stay tuned for part 2 where I will (hopefully) get X going and start looking at the system itself (when was the last time this sort of thing was even IN a distro review ?)