Gentoo: Installing / Administering on Multiple Machines

[gboyce at badbelly.com (Gregory Boyce)]

On Wed, 2004-02-11 at 19:19, nmeyers at javalinux.net wrote:
> On Thu, Feb 12, 2004 at 12:12:21AM +0000, dsr at tao.merseine.nu wrote:
> > On Wed, Feb 11, 2004 at 04:19:05PM -0500, Joshua Pollak wrote:
> > > Hello, I've been running Gentoo on a personal basis for a very long 
> > > time, but I've never used it at work. I would like to propose its use 
> > > here at my company to replace our RedHat 9.0 machines.
> 
> Why?
> 
> I run Gentoo on my boxes, but I like living on the bleeding edge. If
> your company likes support and stability, it's much better off with RH
> than Gentoo.
> 
> Nathan

I've been a Gentoo user off and on since early 2002, and I'm currently
running it on most of my machines, including my desktop at work.  Even
with this, I definitely agree it's not a good idea to use a widescale
deployment of machines with Gentoo.  I'm actually in the process right
now of fixing some problems that a "emerge -u world" caused on my
machine, and I'm not running their "unstable" branch.

Joshua, if you definitely want to go with gentoo, here are some I would
definitely recommend.

1) Go with binary packages.  Gentoo does support binary packages
(although I haven't used them).  You should be able to build them
exactly how you want on one machine, and distribute to the rest.  No
need to expend binary compile time * the number of machines.

2) Compile for lowest common denominator.  It'll be hellish trying to
figure out why package X doesn't work, just to find out it's only broken
when using P4 optimizations and you're running a P3.  The speed
difference shouldn't be noticable if you're not throwing anything lower
than a P3 into the mix.

3) Look into the Gentoo Enterprise initiative that was just announced in
last week's gentoo news letter
(http://www.gentoo.org/news/en/gwn/20040202-newsletter.xml).  It's just
getting started, but it has similiar goals as you're discussing, and
perhaps you could help them as much as they help you.

4) If you're not going with binary packages and the enterprise edition
doesn't work out, consider running your own rsync repository that you
update by hand.  That way you can only upload the updated packages that
you've confirmed work.  Note that this would only be worthwhile if
you're supporting a LOT of machines.  If it's just a handful, fixing the
machines that end up with the occasional issue might be less of a time
sink.