discuss: Production use distribution? ---Re: [olug] Linux sys admin position

[Jacobs, Robert A.]

>-----Original Message-----
>From: Jeff Hinrichs [mailto:jeffh at delasco.com]
>
>Phil Brutsche said:
>> 1) APT.  It's hard to beat "apt-get install apache php4" and 
>get 90% of
>>     what's needed to run a webmail package.  RedHat's native 
>mechanism:
>> - Can't load stuff off the CD/a local mirror: wtf where they
>>       thinking?
>>     - requires you to register
>So, does your system email you when new errata fixes are 
>available?  

As Brian pointed out, you can script "apt-get update; apt-get upgrade"
into a CRON job in order to always have the most current stuff available.

The only disadvantage here is that debconf (the tool used to initially
configure debian packages during installation) is INTERACTIVE.  You can
force a "yes" option (I think) but this is probably not always a good 
idea.

If you are running Debian STABLE, you typically sign up to the debian
security mailing list.  The only changes made to STABLE (a.k.a "Woody")
are security updates; each time an update is made a message is posted to
debian-security.  So...yes, Debian will notify you when new patches are
available against STABLE installs.  Debian's two other branches (TESTING
(a.k.a "Sarge") and UNSTABLE (a.k.a "Sid") roll patches in automatically.

>Can
>you log in to a single interface and check the package status of all of
>your servers?  

I guess this depends on your situation.  As Brian noted, you can always
set up an apt-cache to maintain a cache of Debian packages, point all your
servers at that cache and update them from there -- in this scenario, no
client machine will have packages newer than the cache (as long as you
only allow updates from the cache).

"dpkg -l" will list all the packages installed on a Debian box with version
numbers, etc.  Again, a script should enable you to poll each Debian box for
this information.

>Can you schedule your package upgrades?

Create a CRON job or AT job with "apt-get update; apt-get dist-upgrade" and 
you'll have a "scheduled" package upgrade.  

>
>> 2) Package quality.  Have you seen some of the RPMs out there?  yuck!
>>     Have you tried updating some of those 3rd party RPMs?  
>yuck again!
>I only run the services that are needed on a server.  So, I 
>don't have any
>"3rd" party RPM problems.

This is one of the strengths of Debian.  Debian's Policy and Packaging
manuals [1]
and lengthy release cycle help to weed out a lot of problems with "3rd
Party" Debian 
packages.  Even if Debian were not working towards LSB compliance, the
strict policy 
and packaging manuals (which, I believe, are enforced in the packaging
tools) make 
installing Debian packages a joy.   

I realize that RH has done a lot of great work in this area (up2date,
apt4rpm, 
etc.) but I still hear RH users complain about dependency problems about
which I
never hear Debian users complain.  I'm not very familiar with either one of
these
tools so that is all I can say on the subject...

The price for Debian users is (usually) a longer release cycle (unless you
want
to run UNSTABLE -- which, and this is probably distro-centric propaganda, I
have
heard a number of debian users say is at least as stable as anything RH or
Mandrake
put out.  YMMV.)

>> 3) APT, reason #2: Ever tried upgrading RH 6.2 to RH 7.3?  
>On the fly?
>>     Without booting the install CD?  I've done it with 
>Debian 2.0 "hamm"
>> (RH 5.x vintage) installations, upgrading them to Debian 3.0
>> "woody". I should try it with Debian 1.1 one of these days...
>Point taken.  up2date won't move you up a release.  and 
>release upgrades
>from CD are not as suave as they need to be.  Often installs stuff you
>don't want so you end up having to remove lots of unneeded packages.

This is why, in Debian, I always use the "-s" switch with "apt-get".
"-s" tells apt to "simulate" whatever you tell it to do.  I like to run
a leaner machine; simulating the install prior to doing it has saved me
some headaches in the past.  I assume RH must have something similar with
rpm?

>> Amen!  You have *no* idea how aggravating it is to work 
>someone who only
>> knows RedHat specific tools.  They should pray I don't get a 
>chance to
>> admin one of their machines...
>You are referring to apt v. up2date?  Any other examples?  (Lips moving
>silently as in prayer)
>

Well, I can tell you based upon my experience with Red Hat and Mandrake,
that
it seemed that I was required to use a GUI tool in order to get anything
setup correctly.  CAVEAT:  I am a Debian-user and was used to where Debian
placed scripts, config files, etc.  The Debian filesystem seemed better
organized and was enforced through strong packaging policies that, I feel,
made it easier to work with.

Many RH users (and these could be the newbies) that I have spoken with do
not
know where application configuration files are located on their systems --
heck,
I'm an experienced linux user and I had a hard time finding certain app
config
files on RH -- they just weren't where I expected them to be -- or changing
files
I was familiar with produced unfamiliar results (Networking gave me fits on
Mandrake -- stupid GUI tool didn't see to work correctly and I had a heckuva
time getting my networking configured; Debian places all networking
configuration 
options into one "interfaces" file that is controlled by one "networking"
script!)

GUI tools are a nice, non-threatening way to work with a system -- but, when
it
comes to configuring an application, I prefer the command-line and direct
access to
the config file.  I believe GUI is the way to go when it comes to
introducing new
users to Linux (especially from Microsoft's products) but GUI configuration
tools, in many cases, become a crutch.

>>
>> You forgot one: package quality.
>Wouldn't that be more a function of the packager?  Or by using apt do I
>get +10 karma?

With RH, yes I think it is a function of the packager.  However, with 
Debian, the community AND the tools used to create .deb files enforce
packaging policy.  A package cannot get into STABLE unless it runs on ALL
of Debian's supported architectures and adheres to Debian's policies.

So...yes, by using APT you do get +10 karma -- because you leverage the 
power of The Debian Way (TM).

With all the PRO-Debian propaganda I just spewed, I think, in the issue of
balance, I'll present some things I DON'T like:

1.  Debian's font support has been spotty.  I had a heckuva time getting 
    fonts looking decent on my debian box despite hours of pouring over
    font howtos and deuglification tutorials.  It seems like all the other
    distros have this game down.

2.  Unless you can and want to run UNSTABLE, Debian's packages are "behind"
    the other distros.  I think the Debian packages are "better" but they 
    are certainly not cutting edge (if you are running STABLE, they can feel
    positively ancient).

3.  Debian's text-based installer is both a blessing and a curse.  There is 
    something to be said for Mandrake's and Red Hat's installer -- provide 
    some initial info, press enter and come back 30 minutes later to an 
    installed system.  With Debian, you have to babysit the install because 
    debconf will periodically poll you for info -- the installer is
text-based
    because Debian recognizes that most Linux installs are server-based and 
    do not require a GUI.

4.  I still can't get my Sony DSC-P50 digital camera running under Debian!

To bring things back on topic:

1.  There is no commercial Debian support (of which I am aware).  We had 
    Progeny, we had Corel.  Now we only have the Debian community.  Don't
get 
    me wrong, the debian community is awesome (the debian-user list gets 
    somewhere between 200 and 300 messages a day on average) but it is not 
    commercial support.  Commercial support equals "peace of mind" in the
business 
    world.  In the business world, you want to know that you can dial-up
your 
    support personnel and gripe, moan and complain to someone who is
obligated to 
    treat your problem as a priority.
    
    Try moaning and complaining on a community-supported mailing list
sometime:
    won't get you anywhere, might even get you banned or blacklisted.

    As an aside, HP was pushing Debian as their distro of choice for R&D [2]

    but I haven't heard anything recently...and given the state Carly
Fiorina
    has driven HP into, who knows anymore...

2.  Red Hat, whether it was marketing or reality, was heralded as the first
    user-friendly Linux.  It is the most popular distro because it offers
support
    and it is familiar i.e. an object in motion tends to stay in motion.
Unless
    another distro offers a compelling reason to switch, overcoming that
momentum
    will be difficult.  This is a contributing reason to Microsoft's success

    (anti-trust issues aside) i.e. don't tell me why I should use your
distro, 
    convince me why I shouldn't continue using what I've got now.  

    Change is painful -- few organizations are willing to change without
compelling 
    reason.  Is Debian better than Red Hat?  In my opinion, yes.  Is Debian
SOOOO 
    much better than Red Hat that an organization should switch from Red Hat
to 
    Debian or to Mandrake or to SUSE?  Honestly, probably not. 

    Personally, in a given organization I would probably target Linux
distros to 
    particular applications.  End-users would probably get an RPM-based
distro
    that "Just Works" (Red Hat or Mandrake with leaning towards RH because
RH has
    demonstrated that it is a stable company, offers support contracts, is
(wrongly)
    equated with Linux in the mainstream (which means it gets better support
from
    vendors), etc. -- between the two, I personally prefer Mandrake but
MandrakeSoft, 
    as a company, seems to be struggling).  Servers would get Debian because
of 
    stability, ease of management, prompt security updates, etc. (In all
honesty,
    servers would probably get *BSD because of security track records).

Anyways, I've spewed my thoughts across the screen long enough...

rob

[1] Debian Developer Documentation
    http://www.debian.org/doc/devel-manuals

[2] H.P. adopting Debian Linux for Internal R&D
 
http://www.computerworld.com/softwaretopics/os/story/0,10801,60507,00.html