[Infrastructures] Re: Host installs?

[Joel Huddleston]

Jumping in...

> On Wed, 5 Feb 2003, Stephen Schaefer wrote:
>> Things may have improved, but my past experience is that, due to deep
>> and undocumented dependencies, finding the right supporting packages
>> to add to a minimal install takes days, not minutes.
>
> If that's your experience, I can certainly see how you would feel less
> enthusiastic about it than I do -- my experience is generally the
> reverse.

I am reminded of the time that I tried to install a slightly dissimilar
Sun box using a well tested and mature jumpstart server that just
"installed the whole distribution." For some reason, this *one* box (out
of, perhaps 60) would not reboot on the installed OS. It would panic and
crash. Hours of troubleshooting later, we discovered the SUNWCXALL package
cluster that added "OEM hardware support" to the SUNWCALL package cluster.
That one box had a different video card, made by an OEM, and could not use
Sun drivers.

The rule we took away from this experience was -- install the whole kernel
even if you are not planning on using the WizyWizbang Frimptical
Confongulator in your infrastructure, if the OS vendor has the driver,
drop it on the box.

As far as trimming down package sets themselves, disk is cheap. An inert
binary is just that, inert. As a rule, I disable, not de-install or fail
to install if there is a chance I might need that software subsystem.
Tripwire and patch to the latest security set everywhere, frequently. My
inetd.conf tends towards 3 lines if you ignore the comments. My systems
tend to run about 20% of the files in the init.d directory at boot. I even
disable seemingly innocuous services such as nscd.

On the other hand, I have had coworkers recommend removing the telnet
binary, not just the telnetd server binary, but the client as well. His
argument: "We don't use telnet. Putting it on the box just makes it easier
for a hacker to leapfrog from the box."  Whatever.

YMMV.


>> I may not be alone in this. From the "Bootstrapping an Infrastructure"
>> paper, "Step 10: Client File Access":
>>
>> "In keeping with the virtual machine concept, it is important that
>> every process on every host see the exact same file namespace. This
>> allows applications and users to always find their data and home
>> directories in the same place, regardless of which host they're on."
>
> I don't think that's quite talking about the same issue.
>
> My reading of that is to ensure that you keep the data, not the
> application install set, identical on every machine.
>
> So, you don't have /home on each machine as a distinct item, you make
> sure that everyone gets the same /home on every machine.

Yes and no. At that site, we *did* install the whole OS. In addition,
every application could run on any box if a correct configuration and
dataset were copied to it. All of the applications were installed in such
a way that, if the application directory was not on the box, then it was
automounted from the NFS server.

The crucial issue of that paragraph had to do with home directories,
common package architectures, configuration files, data files and the
like.  For instance, if your site uses
/usr/freeware/{bin|man|lib|share|etc} to hold opensource binaries not
distributed by the Vendor, do that on EVERY OS you install.  The perl
binary (you *do* use perl, right?) should be available at the same place
on every OS and version.

If the new guy, Bob, comes in with the Instimatix Ver 3.141 UNIX variant
and he wants his perl binary to be in /nonos/admin/perly/bin/perl because
that is where he always puts it on an Instimatix box, then smack him
around until he sees the advantage of portable scripts. If you have
internal developers, sit down with them and show them how their
application will work better if it has a static install location, a
machine-specific configuration location and a separate, (possibly)
shareable data location.

We spent several rounds in the ring with Oracle DBAs trying to show them
the wisdom of this scheme. Then Oracle published the OFA document and made
our arguments shorter. We could just say, "Please read the OFA and get
back to me with any questions."

Many thanks for the lively discussion on this topic. It is obvious that a
lot of people have put a lot of thought into it.  This is good. I would
have to say that I am still from the install-it-all camp. This is
primarily because the environments where I have lived have necessitated
the repurpose-on-the-fly methodology in order to satisfy user's needs.

Again, YMMV.

-- 
Joel Huddleston
OK, Joke's over. Bring back the constitution.