[svlug] Choice of Linus to Install

[Karsten M. Self]

Please do *not* CC on list posts.

on Sun, Aug 08, 2004 at 05:27:11PM -0700, Brian Street (brian.street at bayarea.net) wrote:
> Karsten M. Self wrote:
> 
> >on Fri, Aug 06, 2004 at 02:52:32AM -0700, Richard Evans 
> >(rgevans at rawbw.com) wrote:
> > 
> >
> >>I know I am asking for it..


> I'd like to think I'm a relatively experienced, and competent, system
> administrator across multiple OSes (multiple unix and windows) but
> light on linux in particular.

Well!  Get cracking then!

If you've got general Unix experience, Linux will be pretty familiar
overall.  Distros vary, but generally it's most similar to Solaris/HPUX,
with bits and pieces borrowed from all over.  If you're familiar with
the Nemeth books, take a look at her Linux version released a couple of
years ago.

The major differences are greater transparancy, and greater currency, in
Linux.  If you're already using the GNU toolset, you're going to find
most of userland is very familiar.  If you aren't, you're likely to be
pleasantly suprised.

 
> I've been a lurker on this mailing list for awhile and can't say as I
> recall seeing anything that says these linux versions are better for
> firewall applications versus application/file servers. Do they break
> down in this fashion or is distinguishing factors more along the lines
> of ability/ease/timeliness of upgrades?

I'd say discriminating characteristics are more a matter of marketing
influence and top-tier vendor relationships than anything.  And that
these are highly orthogonal to overall technical quality.  Within
specified regimes (say, Linux-on-Mainframe), vendor relations and
support levels are likely going to strongly favor certain distros (eg:
SuSE).

In the firewall space, a distro which allows you to minimize the total
build and exposure is going to be strongly favored.  Here I'd put
OpenBSD (not a Linux distro, but a BSD) and Debian GNU/Linux as the
primary candidates, though there are also specifically tailored
microdistros.  Which raises another fact:  there are several hundred
"distributions" of GNU/Linux, ranging from the top three (Debian, RH,
SuSE) through other general distros (Xandros, Lindows, Mandrake), and
then many, many specialized distros focussing on specific application
areas, architectures, national regions (eg: China, Brazil), security
(SELinux, STRONG Linux), clustering (Mosix, Beowulf), or boot
configurations (LNX-BBC, tomsrtbt, Knoppix...).  Etc.

There are also numerous turnkey firewall systems which bundle both
distro and hardware, in which case the decision's already made for you,
though you _should_ perform due-dilligence to find out what the
underlying base system is.  The medium^Wdistro is the message^Wsystem.

In a corporate environment, RH and SuSE are likely going to lead because
of their marketing and partnership operations, though Debian is a strong
contender, and does have a very strong tier-one supporter in HP.  For
those who'd think that a corporate distro is a positive selling point,
I'll note the cautionary tales of a certain outfit formerly known as
Caldera (now a smoking crater operation), and of Red Hat's radical
changes in vendor support plans with the transition to RHEL.  Both
transitions left many organizations in the lurch.  There's a somewhat
paradoxical stability in banking on a community-based distribution.

 
> I would wager a guess that certain distros are quicker to include the
> latest features than others as well as timely support (as in how fast
> do they fix bugs) or is this again more a personal opinion as seems to
> be the case with so many distros.

Debian's offered a mix of currency vs. stability in its stable vs.
unstalbe (and now testing and experimental) releases for most of a
decade.  Recently, other major distros have been following a similar
tack, as with Fedora Core, (and formerly Rawhide), and similar type
arrangements.

Truth is, "latest" features largely boil down to:

  - Kernel-level support, generally of devices, though also for
    performance and scalability enhancements.  This is pretty much
    independent of any other system components, and can be applied to
    systems of any vintage.  If you're looking at firewalling and the
    like, iptables/ipchains and related features are also
    kernel-dependent.

  - Core system library enhancements.  These are complex and highly
    interdependent relationships, and are _not_ easily applied to
    existing systems, absent significant other upgrades.  This is where
    Debian's package management and policy systems excel.


  - Application-specific enhancements.  Features available in a more
    current version of an application.  This could be desktop apps
    (GNOME, OpenOffice, Mozilla), services (Exim vs. Exim4, Apache vs.
    Apach2, BIND8 vs. BIND9), languages (Perl 5 vs. Perl6, Python vs.
    Python 2), etc.  These may or may not be dependent on library
    features, which could result in greater or lesser interdependencies.
    Again, Debian excells in resolving these relationships.

So it's really a matter of what it is that you really need, and what
trade-offs (stability, availability, compatibility) you're willing to
make.
 
> One of the reasons I ask is that a selling factor, from a corporate
> viewpoint, for installing OTS Unix (I would never, given the choice,
> put company critical applications on M$ - but in the real world we
> don't usually have this choice for a variety of reasons) vs. Linux is
> that I can always call the manufacturer for support when my butt is on
> the line.  In the linux world (yes, there are a couple of companies
> that provide paid technical support for linux distros) most of the
> support comes from a mailing list...or am I missing the boat on this
> assumption.

There are numerous options for Linux support, ranging from mailing lists
and IRC support to tier one vendors for the top three leading distros.
Including Debian.  There are also other options ranging from independent
consultants to mid-tier VARs offering support services.  Some of these
will advertise in various venues such as Linux Journal, on the Debian
Project's Consultants page, etc.

 
> Another reason for asking, is to find out what arguments have been
> used to successfully bring in the first linux servers to the M$ world
> (as is the case I'm trying to make at the moment). I can certainly
> argue the upfront cost and uptime but that might not be enough to sway
> the jury.

The single most compelling argument is increased control over your own
internal corporate/organizational systems.  Ultimately, control
translates to control over costs.

The up-front cost argument is a bit murky.  *Any* conversion of existing
systems will involve costs, and those costs will almost always exceed
the apparent costs of continuing the status quo.

However, the status quo itself will involve transitions.  If you're
currently running Win2K or Win2K3, there's eventual Longhorn migration.
If you're still running NT Server, you're already on an EOL'd product.

The key selling points, in general, are:

  - Choice.  Linux is about choice.  Of distributions, of vendors, of
    hardware, of architectures, of deployment models, of software.
    While there are certainly a set of generally favored configurations,
    if they don't suit your business/organizational needs, you can
    change them.  You're not stuck with a "single seamless integrated"
    solution -- or as they say in the Army:  one size fits none.  Fit
    your information systems to your business, not vice versa.

  - Low aquisition cost.  The software, by and large, _is_ freely
    available.  And while free-as-in-speech is what many people
    emphasize, I feel that free-as-in-beer matters too.

  - Easy replication.  Whether for additional rollouts, failover,
    redundancy, testing purposes, it's generally trivial from a
    procedural standpoint, and fully alloweed from a licensing
    standpoint, to clone or extend additional systems from an existing
    deployment.  No special tools or additional licensing required.

  - Security.  Operationally, there are far fewer security issues with
    Linux systems than legacy MS Windows systems.  Microsoft has been
    trying for years to promote FUD saying it ain't so, but that doesn't
    change the fact that there are far better tools to see what's
    running on a Linux system, to minimize what's running on a Linux
    system, and simply, to minimize what's on a system to reduce its
    exposure profile, in ways which simply aren't possible under legacy
    MS Windows.  Any boss, regardless of hair pointiness, is going to
    know about spyware and viruses.  These are simply not problems on
    the Linux side of the house[1].

  - Flexibility.  You can deploy Linux as workstations or servers, as
    thin clients, as mixed-model deployments (eg:  NFS mounted /usr and
    /home), on a wide range of hardware.  Often you can retain existing
    hardware otherwise long past its useful life, though you may want to
    upgrade some components (video and NIC being the most likely).
    That's a $10 - $50 investment in extending equipment life for years.

  - Capability.  Between available software, scalability, access, and
    local customization, there's little that Linux cannot do, and
    virtually no imposed artificial limits.  If you can identify
    *specific* legacy needs which aren't met by Linux, then by all means
    deploy legacy OSs to deal with them.  Otherwise, look at a
    transition plan involving incremental migration.  For servers, that
    means services moved one at a time to a Linux system and checking
    for any incompatibilities resulting.  For desktops, it means
    breaking your Microsoft dependency cycle with apps such as
    OpenOffice, Mozilla, and the GIMP, and transitioning a few key power
    users to a part-time remote desktop (Cygwin's X server is very
    useful for this), before making a complete cutover.  Remote access,
    WINE, Crossover Office, and VMWare can patch in as needed, but
    you'll find those needs are likely few.  The really key ingredients
    are planning, time, and selling the upside.


 
Peace.

--------------------
Notes:

1.  Though as I've said before and I'll say again, this isn't something
    we want to be *too* smug about.  Though much of this is due to the
    Linux/Unix architecture and security model which prevents ordinary
    users from writing to system files and directories, it's also
    dependent on applications being written in sane ways, such that they
    don't arbitrarially execute (or allow execution) of untrusted
    programs.  Still, the highly modular structure of Linux/Unix means
    that you're far less likely to be stuck with single-source, take-it-
    or-leave-it spaghettiware which tangles functionality deeply between
    what should be wholly independent and features.

-- 
Karsten M. Self <karsten at linuxmafia.com>        http://linuxmafia.com/~karsten
    Ceterum censeo, Caldera delenda est.