bcfg2

[David Lutterkort]

This has gone way longer than I wanted to; just to make sure: the main
points I was trying to make was (1) for Fedora infrastructure there
should be a very good understanding how complex things need to be and
(2) that the choice of tool should be based on matching those needs to
the features of the tools available.

A couple comments to Seth's post:

On Thu, 2006-12-21 at 01:37 -0500, seth vidal wrote:
> On Wed, 2006-12-20 at 11:53 -0800, David Lutterkort wrote:
> 
> > So it's not just glump, but also a whole bunch of custom shell scripts
> > that effectively implement (part of) the functionality of a config mgmt
> > tool without calling it that ?
> 
> It's a bunch of shell scripts. Learning a new language that you will
> never use somewhere else is the problem I'm citing with items like
> puppet and cfengine.

Like everythign else, it's a tradeoff; there are problems for which
domain-specific languages are appropriate and others for which they
aren't. It's a matter of degrees, and what you have to invest in
learning a new language you hopefully gain in clarity, abstraction,
security etc. At the same time, puppet's (and even more so cfengine's)
language are very simple and by design very restricted in what you can
and can't do.

> > What happens when one of the machines gets compromised ? How much easy
> > access does the config mgmt tool give you when you break into one
> > machine ? For example, can you use that to get your hands on ssh keys
> > for another machine ?
> 
> I don't deploy ssh keys that way. It's a chicken-and-egg problem. You
> have to have a special key in order to get a special key, so how do you
> get the first special key? 

You didn't really answer how you deal with security breeches.

As for ssh keys: they are (by design) not very useful for establishing
trust in a setting with a central authority. SSL (X509, really) certs
are much better for that, and the way you do that is by giving each
client it's own cert; you still have the issue of how to get that cert
onto the client initially, and the answer depends on your level of
paranoia - a very paranoid solution would be to generate the signed cert
and private key on a  USB stick, carry it to the client and clean out
the USB stick after copying the keypair onto the client.

Basing trust on SSL certs buys you at least two things over ssh keys:
(1) trust is ultimately derived from the fact that the certs are signed
by the central authority, (2) certs can be revoked individually and
centrally if they should be compromised.

With certs in place, you can send ssh keys securely from your central
server to each client, and _know_ that you are really talking to the
right guy.

The reason ssh keys even come up is that if you have to rebuild a
machine you would usually want it to keep its host keys so that you
don't have 

> I'm not bad-mouthing ruby. This doesn't have to do with it being ruby.
> Right now in order to maintain a system running for admin tasks we
> require:
> 
> python - stay consistent and reliable for yum and friends
> bash - stay consistent and reliable for all the init scripts, etc

And, in reality also perl; at least on my system, 'yum erase perl' wants
to uninstall stuff like bind, php(!), postfix, psutils, a number of
system-config- things, samba, squid, subversion, and, worst of all,
gaim.

> If we start tying down ruby or any other language as we move along we
> end up having more and more pieces of the OS that we cannot deploy new
> versions of w/o fear of breaking our administrative infrastructure.

There are many ways to break a system on upgrade or otherwise, and the
tools around a specific language are pretty low on that list. From your
experience with yum, how much breakage is caused by python bugs, how
much by bugs in components that yum relies on, how much by bugs in yum
itself and how much by user error ? I would assume the lion's share of
these problems, as with any tool, is bugs in the tool itself. Actually,
I assume user error is the biggest cuase here; and some user errors
definitely fall into teh category of user interface bugs of the tool.

> So if puppet needs a version of ruby or some number of gems in order to
> run, but we want to have a ruby install for rails that needs a different
> version then we have to screw around with multiple version installs of
> ruby and keep up with those installs for security patching.

How does that have anything to do with implementation language ? This
exact same argument works for any sizeable component, and it's a danger
everytime more than one important tool relies on that component. You
could rewrite the above paragraph and turn it into an argument why yum
shouldn't use sqlite or expat.

BTW, puppet's requirements are by design very simple, especially for the
client: ruby and facter, a ruby library developed in concert with puppet
(which could really be bundled with puppet) And I would not even look at
a config management tool that wants rails on the client ;)

> That's what I mean. I'd like to keep our administrative language
> requirements to a minimum. Since anaconda, yum and most of the
> system-config-* tools are in python, it makes since to tie down python
> for administrative uses, but if we keep adding components in more
> languages we end up with progressively more problems.

Again, that argument is only valid if there's some evidence that
language-related problems are a significant part of the overall problems
a sysadmin encounters. And you need to contrast that with the problems
that are caused by choosing an inadequate tool - or worse, no tool - for
the wrong reasons. I hope we can all agree that for config management
there is a lot of room for improvement in any which way.

Clearly, adding another language is of some concern, but I think it's
far from the most important issue to look at; things like functionality,
match of the features to what's needed, viability of the tool's
community, development method (are bugs fixed responsively? patches
accepted? are there automated tests?) etc. deserve serious attention.

David