Debian Enterprise (not a Starfleet metaphor)
Karsten M. Self
kmself@ix.netcom.com
Wed, 17 Dec 2003 01:31:32 -0800
--AhhlLboLdkugWU4S
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
on Tue, Dec 16, 2003 at 09:14:05PM -0800, Sean 'Shaleh' Perry (shaleh@speak=
easy.net) wrote:
> hey Johnie, its been a while (-:
>=20
> On Tuesday 16 December 2003 20:22, johnie@nyip.net wrote:
> >
> > Somehow I suspect this isn't true, so I have two questions:
> >
> > 1. Has anyone here run Debian for critical work -- say as RDBMS or
> > part of a cluster of application servers, webservers etc. -- or
> > read of that being done by others? Or maybe as smart firewalls,
> > or OpenOffice deployments that saved money compared to Windows....
> >
>=20
> I have used Debian quietly at work on numerous occasions. It has *ALWAYS=
*=20
> been a struggle. Here is my most recent case study.
Sean, good points. Also discussed, BTW, at LWCE Debian BoF.
Some responses.
First, among companies using Debian: Gator, The Register, T-Mobile,
SearchScout, based on Netcraft results. And there's ye olde "Who's
Using Debian" page: http://www.debian.org/users/
> The IT department wanted a ticket system and did not want to use
> engineering's bugzilla. So I looked around and decided to use Request
> Tracker. This being a RH shop I used RH 8 and started following the
> docs. For those of you who do not know, Request Tracker uses lots of
> perl modules and usually mod_perl in apache. I had to build *ALL* of
> it. Took me like 3 days to get everything working. Recently the
> apache authentication broke. The Windows admin changed something so
> my hooks into Active Directory no longer work. System is like 3
> months old. I decided to re-install with Debian because I was tired
> of maintaining RH by hand. Made a backup of /etc and the SQL db along
> with some other data. Installed Debian -- took about an hour. Did an
> apt-get install request-tracker3. Waited 20 minutes. Put the data
> back into the SQL table, read the
> /usr/share/doc/request-tracker3/README.Debian.gz. Was up and running
> 30 minutes later. This has been my experience with damn near all of
> my RH --> Debian changes. It works and my boss is none the wiser.
Ayup....
FWIW, I hit pretty much all those points at a small webhosting outfit I
was at a year ago. They specifically wanted to upgrade a bunch of RH
servers running a motley mix of 6.0 - 7.2 to 7.3, which they would "stay
with for a while". Except, of course, that 7.3 is being EOLd in
January.... This place defines low margin.
Note that HP have announced (extended) support for Debian, which means
we've got a tier-one tech company backing the distro.
> Why not Debian?
>=20
> *) linux =3D=3D RedHat, why not just use RH?, the next admin we hire will
> know RH, etc.
I'm working on a pitch, part of which addresses the "you get what you
pay for" objection to GNU/Linux (or Debian). As a counter, look at what
you're paying for with the alternative:
- Marketing. Note that marketing is in no small part papering over
your own shortcomings.
- Pretty packaging.
- Certification (yeah, it would be nice for Debian...)
- Customizations. Particularly kernel tweaks. After struggling with
a raw 2.4.23 build for most of a week, I was really happy to get
Herbert Xu's DEBs and source finally. RH apparently does even more
extensive tweakage. Those who've seen it (some VAers in this group,
right?) say it's pretty hoary stuff.
> *) we often have some piece of proprietary software that says it will
> only run on RH X.Y.
Response: Then get RH specifically for $PROPRIETARY_SW ... and note how
much of a damned pain it is to maintain, by comparison. Note too that
for any two bits of sufficiently complex proprietary SW, constraints may
well mean you have to dedicate a system to it. And given the cost of
$PROPRIETARY_SW, the cost of licensing and HW is likely minimal.
There are also fun games to be had with chroots and UML.
> *) it is hard to beat anaconda + kick start. DAMN HARD!! Sure, once
> it is installed Debian kicks RH's ass left, right, and backwards.
> However, my bosses like scripted, easily replacable servers.
> Especially because we either a) are stuck with shit hardware or b)
> hardware gets stolen by other departments and we have to make new
> servers out of whatever is left / swapped.
There's FAI.
There's also cloning. Boot the new box with Knoppix. Clone an existing
config onto it with rsync, tar|ssh, whatever. Modify kernel modules,
tweak net, cat <hostname> > /etc/hostname, and you're largely set.=20
Or:
# Old box
dpkg --get-selections > packages =20
# New box
dpkg --get-selections < packages=20
apt-get update
apt-get -du dist-upgrade
A friend recently migrated a system across platforms by the latter
method, in an afternoon.
My HO is that if you're installing systems in a production environment,
you're likely doing the wrong thing anyway -- netboot, slaves, or other
clustering configs are what you want.
> You are right now coming up with crafty ways around this. Well disk imag=
es=20
> don't work because we have no storage space. Everything else I have seen=
is=20
> a horrible kluge.
The package list + /etc option is largely the equivalent of having disk
images, and is only slightly slower. If you can't get resources for
20-40 GiB to run a local apt mirror / cache, you've got bigger problems.
> *) RH makes releases. Debian will get one out some day. Maybe.
Debian's releases work.
> It is that last item that damns us eternally. As long as Debian
> floats down the river of time at its own pace we will never have any
> serious place in the market. Yes I know releases are stupid and
> meaningless. But my boss won't listen. The book publishers won't
> listen. The news media only wants to hear announcements.
One of the major changes with RHEL is to slow down RH's release cycle.
Previously, major releases were made annually. I don't have specifics
on the new schedule, but it's going to be longer. Debian really isn't
_much_ slower, it's just that the date itself is a matter of gross
anxiety while it's pinned down. Release dates:
0.93R6 Oct 26, 1995
1.1 ``buzz'' Jun 17, 1996
1.2 ``rex'' Dec 12, 1996
1.3 ``bo'' Jun 5, 1997
2.0 ``hamm'' Jul 24, 1998
2.1 ``slink'' Mar 9, 1999
2.2 ``potato'' Aug 15, 2000
3.0 ``woody'' Jul 19, 2002
=2E..that's 1.5 - 2 years recently, which is roughly comparable to what
RHEL is targeted for. In a production environment, a Good Thing[tm].
Particularly as you can _also_ track development via unstable/testing on
a test rack to plot compatibility and migration staging. Note too that
the potato support discussion indicated that production shops would
_like_ to have 12-24 months support after new release for old-stable,
though currently support is generally offered only for 12 months.
Gamers and tweakers bitch about this. For production environments, the
option of having a release which _is_ stable when it's put out, and
which has a _supported_ lifetime of 2-3 years, including security
updates, should be highly attractive.
The one remaining problem is getting Debian up on newer HW. Simply:
the installer doesn't support a lot of stuff. My fix here is to use one
of the installation options above, bootstrapped from Knoppix, LNX-BBC,
or similar bootable media. You get the best of both worlds: a system
that's autoconfigured for HW at boot using current tweaks, and a known
good Debian install.
> > 2. Will anyone admit to having docs for the commercial RedHat or
> > United Linux dists, that would explain what is so great and
> > "enterprise" about them? (their kernel patches blah blah)
> > I admit it, I'm not above borrowing ideas.
> >
>=20
> *) kernel work
Apparently not to be discounted. And difficult to RE.
> *) commercial vendors say "we work on XX"
Certification for ISVs isn't to be sneered at...if you need to run
proprietary SW. LSB + free software gets you around much of this.
> *) Perception of polish (not shared by the admins, but bosses thing
> "hey, came from a company, must be good.")
See marketing, above.
> Note, I have NEVER seen a company pay for RH. It will be really,
> really interesting to see what happens with Fedora. I honestly think
> this will only serve to strengthen Windows in the market. The
> marketing engines of Redmond are killing us and frankly their software
> is finally as stable as ours.
My read is that RH are chasing Sun. They're playing an interesting
Christensen[1] squeeze: Going after upmarket dollars, by cannibalizing
Sun's own much higher licensing/HW costs. This leaves RH vulnerable
themselves to bottom-end encroachment, which they're somewhat addressing
with Fedora. I've written on this elsewhere (BALUG/SVLUG lists, one or
the other or both).
Peace.
--------------------
Notes:
1. _Innovator's Dillemma_
--=20
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Hi! I'm a .signature virus. Copy me into
your ~/.signature to help me spread!
--AhhlLboLdkugWU4S
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/4CJ0efG8443k044RAutDAKCFjo26Z2EhQd3//+JEBQL97JCz2wCeO+3h
a5LKAeWDu6VCRLNgbto0Dgc=
=gR9h
-----END PGP SIGNATURE-----
--AhhlLboLdkugWU4S--