[Infrastructures] Re: Host installs?

[Daniel Pittman]

On Thu, 6 Feb 2003, Joel Huddleston wrote:
>> 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.

[...]

> As far as trimming down package sets themselves, disk is cheap. An
> inert binary is just that, inert. 

Unless it's SUID or SGID to something and allows privilege escalation.
I do take your point, though.

> As a rule, I disable, not de-install or fail to install if there is a
> chance I might need that software subsystem. 

I use an approach of making it easy to have a subsystem installed or
removed from a machine, fully automatically, without any need for hard
work on my part.

[...]

> 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.

I don't consider that a good argument -- it's only going to stop a stock
script, not a real attack.

OTOH, not having tools there until they are asked for means that our
developers *don't* build an undocumented dependency on the FooBarWiz
utility at version 3.14, then complain when it blows up because that
utility was upgraded or removed.

> YMMV.

*nod*

>>> 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.

[...]

> The crucial issue of that paragraph had to do with home directories,
> common package architectures, configuration files, data files and the
> like. 

Thanks for stating that -- it's what I meant, but not clear from what I
said.

[...]

> 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."

I must remember that; there is some risk of Oracle landing here in the
next year or so.

> 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.

That's my feeling. I still don't feel that installing everything is a
good idea, but I have heard a lot more coherent arguments in support of
it now.

This can only be a good thing.

     Daniel

-- 
All that I have written appears to me as so much straw after 
the things that have been revealed to me.
        -- St. Thomas Aquinas