redhat vs. debian (was: Re: Problems with Redhat 9)

On Fri, Apr 11, 2003 at 05:15:52PM -0700, Yazz D. Atlas wrote:
> I have been reading the thread and here is my personal reasons for using
> Redhat over Debian on multiple servers. 

> My personal systems I can count
> on both hands and keeping Debian updated isn't really an issue but for
> production/work system (over 100 of them) it started to eat up more of
> my time.

I use debian on my own boxes precisely *because* of the updating method. I
don't have to build any custom packages because RH hasn't released a new
version yet; nor do I have to pay RH money for the privilege of keeping my
system up to date; nor do I have to deal with RH's package repositories -- I
can choose the one closest to me (often a 10MB line and two hops to the
aforementioned 1.5TB FTP server).

>      1. The Redhat Kernel rocks! Plain and simple, look at the amount of
>         patches to the kernel compared to a stock Debian or a default
>         un-patched kernel. 

I disagree. I consider all 1000+ patches to be a dubious thing... there
might be very good reasons Linus hasn't included them in the stock kernel.
Maybe they're implementing some new buzzword-compliant misfeature that
hasn't been completely debugged yet, or doing something that makes them work
with redhat boxen, but stock kernels won't work quite right on the same
system.

on my RH7.2 workstation I tried building my own kernel from source
and installing it; but:
sound didn't work (plain old sb16 card)
networking was flaky, dropping packets and making NFS unusable

whereas this exact same kernel config had worked just fine on the identical
hardware when it was a RH6.2 box.

the system worked fine only if you used redhat kernels.

on a further divergence...
I also noticed that RH's XFree86 package broke the Matrox driver. Dualhead
worked just fine on the box, running X 4.0.3, without the Matrox binary
driver. when I upgraded to RH7.2 and X 4.1.0; it no longer would display to
the second head without the Matrox binary.

since that point I have begun to distrust redhat more and more.

> Some of my Debian system run custom compiled
>         Redhat kernels because of drivers and the patches in the kernel
>         were needed.

I can't gainsay that they add some nice drivers at times; and if their
kernels have the necessary drivers, then go use the tool that works. :)

>      2. Redhat Network. Currently nobody has written a tool individuals
>         can install and maintain that monitors your different servers
>         packages like rhn does 

never having used RHN, I don't know anything about it. I was under the
impression that using its updating feature is something you have to pay for;
because you can only use RH's servers.

why should I pay to use someone's crappy servers (or take the
free-but-bandwidth-limited option that some tools like RedCarpet offer);
when I can use apt or grab to access a server of my choosing?

Real-Time tried to become a Ximian 'partner' so we could keep a local copy
of their server and have decent bandwidth (we're already an official Redhat,
Debian, Slackware, Mandrake, and OpenOffice mirror); but they didn't want to
talk to us. soured us a bit on anyone's tools that don't give you a choice
of servers.

also, there's a definite feeling at our company, that "If you have to pay
for it, it might not be worth it." there's so much good free (as in speech
and beer) software out there, that it's rare to find a payware package
that's substantially better (for our sometimes limited purposes) than
something we can find or build ourselves.

> Be nice if there was but I haven't found
>         it. Make a private Debian Network where an admin could quickly
>         see what sytems need what patch and could just click to apply
>         them.

it *would* be nice to have a tool that kept track of system up-to-dateness.
I'm leery about applying updates willy-nilly tho. the systems I maintain are
a pretty heterogenous bunch (all customized to the customer's
requirements and hardware), spread all over the country (and sometimes the
world); and it's entirely possible to break things
during the course of an upgrade. This usually leads to a customer calling us
to say that "the Internet is down" (which is really troublesome when you
have to walk someone through logging in at the console and stopping
iptables, in German). I'm generally careful enough to avoid locking myself
out; but only because I pay attention to the box I'm working on at the time
and apply updates carefully.
(this is one of the reasons I like GRAB; it lets you easily select which
packages to install and shows you what the version numbers are; unlike
apt4rpm, which does neither).

for just monitoring system status we use netsaint. :)
(I wonder if it would be possible to build a netsaint module that checks for
up-to-dateness?)

>      3. Production Tree. I don't need to maintain my own Debian mirror
>         of packages that I have patched/upgrade/etc. Upgrading 50
>         servers one day and then another 50 a week latter you are left
>         with machine with different packages if you need to point at the
>         unstable tree in Debian. Keeping a personal stable tree eats up
>         a lot of time.

this is the big disadvantage of Debian... 'unstable' is really cool and
up-to-date... but sometimes *too* up-to-date. 'testing' is the bastard
stepchild and isn't up-to-date enough sometimes; and not guaranteed to be
bug-free.

generally we just run 'stable' on servers; and if we need newer packages we
build them ourselves (which we'd likely do anyway on redhat; we already
maintain our own base of customized packages -- another reason we need to be
able to point update tools to our own repository).

>      4. 3rd party software. While alien (tool for installing rpm's under
>         Debian) works 90% of the time. You might still have to run
>         Debian unstable if there are libs that are required. Not to
>         mention dealing with vendors that expect that your running
>         Redhat.

can't gainsay this; but it hasn't been a problem for the few debian boxen we
have.

> If I burn 10 CD's and pop them in machines I can just boot them and come
> back in an hour or so. Then login and register them with rhn. Give the
> machine static IP's and place it in our production environment.
> 
> The install method relies on DHCP and NFS. Inside the NFS mount are
> different chrooted installs. 

sounds just like what we do. our kickstart CD has a number of optional
configurations (different amounts of memory, hardware or software RAID); we
choose one, walk away, and 15 minutes later we have an installed system.

we then have a number of custom apt virtual packages (empty except for
dependencies, just like the 'jablicator' packages you mention) for
installing configurations of a firewall, fileserver, ipsec server, backup
server. etc.
then there's a script that walks through a number of steps (so we don't
forget), asking for IP addresses, ntp servers, dns servers, etc; then builds
a mindi iso backup/rescue CD. (tho I'll admit that the script is pretty
cumbersome and of dubious help at the moment).

> I remember reading about someone looking for a kickstart method for
> Debian. 



> View of md5sum's
> 
> The md5sum's that Redhat uses on its packages is cool but if your still
> using Debian look at the package "debsums". It can build a md5sum
> history based on sums in the package or if the package is missing them
> will download the package and create them based on the downloaded
> package. 

ah. cool. I knew there was likely to be something like that. :)

> Its handy but if you got rooted its much better to reinstall
> then rely on md5sums. 

yeah, we don't trust md5sums if there's been a known breakin. it's just one
more tool useful for seeing if you *might* have been broken into; or if you
have flaky hardware or what.
I was just using them yesterday on a box that kept returning different
md5sums on binaries; tripwire would never give the same report twice --
files would appear to be changed on one run; unchanged the next. 'rpm
-Va|grep 5' wouldn't report changed md5sums tho.
I spent quite a while trying to see if the box had been broken into (it was
an active firewall in a company about an hour's drive away, so going to the
console and rebooting on a rescue disk was not an option); but the problem
was solved some time later when the local admin called to say that the box
was emitting a horrible burning smell and the CPU fan wasn't turning...

Carl Soderstrom.
-- 
       ***** These are my opinions.  Get your own. :-) *****

Systems Administrator
Real-Time Enterprises
www.real-time.com