[CLUE-Tech] Managing multiple servers (long)

[Adam Bultman]

I currently manage some 20 odd servers.  Most are linux.  It's a mixture
of red hat and turbolinux.  Both are RPM based.  I think just about
everyone knows what's going on with turbolinux (hint:  think hindenburg).
However, I'm pretty much roped into RH/TL based web servers because of
Turbocluster (cheaper than a hardware solution).

I hate RPMs.  Just go to the gnucash web site for info on how bad
dependency hell is.  I am a strict from source person.  At home, I run
precisely one rred hat box, which is the public computer that random
visitors can use (it's a lot easier to admin).  My other boxes are a
mixture of slackware, debian, and beehive linux (www.beehive.nu).  I take
the time to compile everything from source.  Well, not always on debian
because it resolves dependencies itself.  Anyway, I've found I get things
a lot better, a lot more custom, and moreover, it *puts stuff where I tell
it, not where it's defaulted to go*.  I do all source on my servers at
work, too.  It's a pain sometimes (i.e. every other day a new version of
SSH) but I've found it's probably a heck ofa lot more trustworthy that
way. In a pinch, I can find how I built it, find the source, all that
jazz.  Yeah, it takes more time, but not really if you do things smart -
make a shell script that goes and compiles apache, php, mod_ssl, all that
jazz all at once. It's easy. When a new version of php/apache/mod_ssl
comes out, it takes me but a few moments to get it running.  Download,
then run ./build.sh . Done.







On 7 Oct 2002, Michael Robbert wrote:

> On Mon, 2002-10-07 at 09:51, Dan Harris wrote:
> > I wanted to get some advice from others here on distro suggestions,
> > hopefully without causing an all-out distro war. But we're all adults
> > here, right?
> >
> > Anyway, here's my scenario:
> >
> > I cut my teeth on Linux with Redhat 5.2 and have just stuck with RH ever
> > since.  RPM was a really nice feature.
> >
> > Then, as I started using more and more cutting-edge apps, I found myself
> > installing more things from source.  Sometimes, because that was the
> > only available form, sometimes because the rpm's were stale.  Soon, I
> > started having problems with RPMs like "libXYZ requires libABC, lib123,
> > libCRX, libblahblah" errors, aka "dependency hell".  I was thinking
> > "what the hell?  If you know you need them, go get them already!".  So I
> > learned about up2date and RHN.  So I tried running up2date several times
> >   but was denied because of high-demand on their servers.
> When you say cutting-edge apps, do you mean the latest versions of apps
> that Red Hat includes or do you mean apps that you can only get
> somewhere else? I don't bother with up2date either.
> >
> > Fast forward a few years- I now manage 8 redhat servers that are all
> > mission-critical systems.  Over the last few days I've realized that
> > every system is a completely different animal, with different versions
> > of everything, including the distro itself.  The idea of rebooting and
> > upgrading from CD's every 6 months is just not appealing to me.  I have
> > very little time to play sysadmin any more, nor the money to hire
> > someone to be dedicated to this task.  I need to spend as much time as
> > possible writing code, not applying patches and recompiling.
> 8 mission-critical systems and you're playing with packages so new that
> nobody has even build RPMs, sounds like playing with fire to me. I have
> no idea what your company does or what these systems are really meant to
> do, but if they are all really mission-critical then I'd think that
> you'd want to know that they are running packages that have been tested
> by a large part of the open source community. 8 servers and moving to 20
> soon I think that sounds like you should to expect to have a fair amount
> of sysadmin duties for somebody to do.
> >
> > I was so frustrated with a dependency problem last night that I was
> > ready to dump redhat completely.  So I started looking around at other
> > distros.  Debian of course has apt, which sounded really appealing since
> > it would handle dependencies automatically.  But I hadn't heard of
> > anyone using debian in a 'corporate' environment yet.
> Dependency Hell can be a problem and it gets worse the further you move
> from Red Hat's standard packaging. apt is an excellent solution and that
> is what I use on my 5 Red Hat servers as well as all the clients. I get
> apt4rpm from www.freshrpms.net which also has some additional packages
> on top of the standard Red Hat ones. I also run my own apt repository by
> mirroring a Red Hat mirror as well as freshrpm's ftp site. That is what
> I'd recommend since it sounds like all your experience is with Red Hat.
> In case you still want to move to Debian I did have a good friend back
> in Ohio that ran an entire small manufacturing firm on Debian servers.
> The only reason that I'd recommend that you move to Debian is if the
> packages you need are supplied by default in Debian and not Red Hat.
> >
> > Then, I looked into paying the $60/yr per system to subscribe to the
> > 'basic' redhat network.  The idea of letting up2date run willy-nilly on
> > my system, updating what it deems necessary is a bit scary for me.  I
> > dont trust that it's not going to overwrite something that I carefully
> > "configured --with-one-million-custom-options" with a 'default' install.
> Make sure you document these kinds of installs. You'll need to upgrade
> them at some point anyways and you'll want to know how you installed it
> before at least as a reference.
> >
> > Am I just being paranoid?  Should I bite the bullet and succumb to the
> > 'rpm way or no way' approach of redhat?  Or, is there a better distro
> > out there to do what I want?
> >
> > I'd really like some advice here from people who have been faced with
> > the problem of managing multiple servers (i expect to be up to 20
> > servers within the next two years).
> >
>
> Good Luck!
>
>

-- 
Adam Bultman
adam at glaven.org
[ http://www.glaven.org ]