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
