A summary of all of the bad Linux advice in the CentOS thread earlier this month

[Tyler Morgan]

Hi! My boss has one of our email aliases subscribed to get filepro-list 
digested to us and, well, I stumbled across this CentOS discussion 
earlier this month and am a little scared at some of the bad advice in it:

http://mailman.celestial.com/pipermail/filepro-list/2011-May/026119.html 
"Cent OS migration"

This is in no way meant to be personal at all. I have great respect for 
anyone who can deal with Filepro on a day to day basis. However, I 
(usually) don't have to; I am a Unix admin and have been since I broke 
my parents computer with Slackware on a 0.9x kernel around 15 years ago.

Also, to buy some credibility, I recently setup Filepro 5.0.0 on 
VMware-hosted 64bit CentOS 5.6 servers and it seems to work fine 
according to the coders. Don't ask about the version. I'm more than 
happy to answer any questions on how I made this work but honestly it 
was really easy overall. We were halfway to making it work in Debian 6.0 
(much more challenging because Debian has ditched a lot of legacy stuff 
where CentOS and RHEL have held onto it -- termcap, 32bit support come 
to mind). In the interest of practicality we switched to CentOS and had 
it running surprisingly quickly.

And of course there is a lot of good information in that interesting 
thread as well.

Let's talk about distributions of Unix/Linux first. There was a lot of 
bad advice regarding specific Linux distributions and downright horrible 
advice regarding BSD. I think it is just a lack of perspective.

CentOS is a perfectly fine RPM-based Linux distribution that is about to 
get very slowly screwed over by the for-profit RHEL juggernaut. RHEL 
gave us a preview of their view of the future of Linux by announcing 
that they were no longer releasing their kernel patches as nicely 
SRPM'ed up little files. Instead, it is now up to the community to diff 
out their code and create their own patchfiles. Conversely, RHEL is free 
to pillage anything it wants from the OSS community without any 
unnecessary hassles.

Here is one of the many stories online about that with some good links: 
http://www.g-loaded.eu/2011/03/02/rhel-kernel-source-released-with-patches-already-applied/

The fact that RHEL is a for-profit company screws up a lot of the OSS 
mentality that makes it so great. Want another example? Try installing 
Mono on a RHEL box. You can't without about a dozen commands of 
trickery. Even though the RPMs exist, they purposefully make it hard 
because Mono is a project that competes directly with aspects of RHEL's 
for-profit business model.

And don't take their RHEL-certified thing too seriously. Sometimes that 
is important (being able to call VMWare because you're working with 
certified hardware is really nice), but sometimes it's just marketing. 
I'd tentatively argue RHEL-certified falls into the latter camp; 
admittedly without having much experience caring about it. HP Proliants 
are alright overall. I like their iLO cards and their cute amber warning 
lights on every single thing.

Anyway, I use both RHEL and CentOS at work and each has their 
application but honestly we are slowly phasing out RHEL for CentOS and, 
eventually, if I have my way, will slowly phase out CentOS for my 
personal Linux-of-choice: Debian. Everything under VMWare, of course. 
For my needs, both at home and at work, Debian has consistently been the 
most balanced distribution in the long time I have used Linux.

Really though, Linux-to-Linux, the only 2 significant differences are 
the package management system (RPM vs. Deb vs. BSD's ports tree are the 
main contenders) and the release cycle which is a to-each-their-own 
situation to me. Some people can't stand how slow Debian is to update, 
some people hate having to upgrade 15-30 packages on a monthly basis and 
love locking their versions down. It all depends on what you need from 
the OS and where your system architecture is going. But, no matter what, 
if you're not applying security patches and dealing with the occasional 
consequences, you're doing it wrong.

The complete discounting of *BSD really irked me. Okay, sure, Filepro 
mailing list -- it doesn't work on BSD. Great to know! But let's not 
completely discount something like OpenBSD -- by far the most secure and 
best documented, full-featured Unix distribution in existence, or the 
amount of *BSD code under your Linux distro's hood.

So much code that so many people could not live without was written by 
the BSD folks. You know that free IPSec stack you're using for your 
OpenVPN sessions you couldn't live without? Or uh, SSH? Written by 
OpenBSD in the 90s. OSX on your Macbook? Based on FreeBSD.

And don't even get me started on how awesome at networking BSD is 
(OpenBSD in particular). Don't feel like spending $5 grand on a pair of 
HSRP capable Cisco routers for your border? OpenBSD was nice enough to 
reverse engineer it and then rewrite it as CARP in such a way where they 
couldn't be sued for violating Cisco's patents on HSRP. Now you can 
spend about $650 on a pair of commodity-hardware 1U rackmount servers 
and make a nearly equally capable border router. Never, ever use Linux 
as a router. iptables literally pales, falls over dead, and then 
decomposes before your eyes when compared to pf.

I'm not saying you should look to any BSD to host your application -- 
especially if it's Filepro! Linux is just as good in almost every way 
and much easier to manage in my opinion, except when it comes to 
networking. However, discounting it so quickly with remarks like "less 
than 1% of the community uses it" is really going to rub long-time Unix 
nerds the wrong way.

Some remarks on LVM were the next thing that caught my eye as bad 
information. I can't count the number of times my life has been made 
exponentially easier by using LVM2 for everything.

I may be misreading slightly, but it was implied that LVM suffers from a 
similar issue as RAID0 -- if you lose 1 physical chunk of it, the whole 
array is gone. That is sort of true, but definitely not the whole story. 
If you lose any physical volume in a volume group, all of your logical 
volumes that belong to that volume group are gone -- no argument here. 
This is why you have to plan your (redundant) physical volumes carefully 
before putting LVM on top of them.

It's actually a very similar situation to picking what level of RAID you 
want. LVM can be configured as a "JBOD" which suffers the same risks as 
any other JBOD. This is hardly anything to hold against it. The totally 
reliable, sort of magical, well supported, well documented, and easy to 
use virtual "partitioning" system LVM provides can make your life really 
easy when you're moving stuff around or need to rethink your disk situation.

And that leads me into answering a question someone asked that never got 
a reply: RAID5 is still significantly slower for writing than RAID10 (or 
RAID0+1, your preference). For reading you can probably make RAID5 
faster but honestly I use RAID10 for anything that has to be fast. RAID1 
plus the occasional hot spare for anything that can be averagely fast 
and is important. RAID5 for large amounts of storage that is expected to 
be sort of slow to write to (but pretty speedy to read from!).

Oh Bill. I respect your oldschool ways but /u, really? Don't use /u and 
the word competent in the same sentence. This is 100% preference and has 
nothing to do with skill level. And I 100% prefer to not make a mess of 
my filesystem by unnecessarily rearranging things. As far as installing 
to /usr/local/* always... well... I can't say I disagree in general, but 
at the end of the day: install to where ever makes it easy.

Again, unless there is a really good reason, I am not a fan of making it 
hard on myself. Defaults, defaults, defaults -- they are what get QA'ed 
most often! Unnecessary complication based solely on preference can lead 
to nightmare webs of pain after a decade of doing it and not cleaning up 
after yourself. Or, frankly, not accepting times change.

Speaking of which: "If it's not tape, it's not a backup" -- heh, well, 
no. Sure, tape has its uses, but again, there is absolutely no reason to 
think enterprise-level magnetic drives are not equally reliable and come 
with a whole slew of benefits over tape. Instead of worrying so badly 
about what media you're backing up to, why not make sure you're backing 
up to multiple locations. And monitor them daily. And test restores 
often. And break stuff on purpose occasionally. These are the things 
that are important when you're talking about backups -- not the media.

Lot's of /good/ advice on not touching SCO and using real RAID 
controllers! They are worth every penny.

Anyway, I know this isn't a Linux or BSD mailing list, but it's always a 
best practice to have different perspectives on questionable statements 
or advice. I sincerely mean no disrespect and wish everyone well!

Have a nice weekend,
Tyler