On Tue, 2006-12-19 at 14:14 +0100, Axel Thimm wrote: I've begun to package it up, since it looks useful in for my work as well. There's at least one dependency that isn't in FE yet so I'm working on packaging that as well. I'll try and get the review requests up later today. Jeff

On Tue, 2006-12-19 at 08:58 -0700, Orion Poplawski wrote: I haven't looked at Puppet in depth, but one con is that it's written in Ruby (not that there's anything wrong with that). But there may be license issues with bcfg2 so that may be an option as well. I haven't looked at cfengine yet either, but from what I've seen it's cryptic configuration is a major con. Jeff

On Tue, 2006-12-19 at 10:15 -0600, Jeffrey C. Ollie wrote: What was wrong with glump and friends? It's simple, no cryptic formatting of files or craziness. The scripting language that runs on the hosts is whatever you want it to be. -sv

On Tue, 2006-12-19 at 18:15 +0100, Axel Thimm wrote: http://linux.duke.edu/projects/mini/glump/ https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218577 Jeff

On Tue, 2006-12-19 at 12:14 -0500, seth vidal wrote: There's nothing "wrong" with glump. It does an excellent job at what it was designed to do. I think that the issue here is that {cfengine, bcfg2, puppet} were designed to do more that serve out customized versions of config files, like checking ownership/permissions of files, the status of servcies, and whether packages are installed. We just need to look at the alternatives, figure out which one does what we want it to do, and move on from there. I'm not even sure that we've agreed on what we want a configuration management system to do for us yet. Personally, I'm going to be using glump to manage the configuration files for my umpteen bazillion wireless access points. Jeff

On Tue, 2006-12-19 at 12:43 -0500, seth vidal wrote: Correct me if I am wrong, but my impression is that glump is mostly a template-expansion tool with a custom language expressed in XML. The two most important features that full-blown config mgmt tools add to that are * direct control over individual entries in database-like config files (like /etc/hosts, /etc/passwd etc.) * flexible grouping of config settings that is flexible enough to express variations with little effort How do you handle security ? E.g., how do you keep host A getting its hands on the config for host B ? That is important when you manage security-sensitive parts of a machine's config with the tool. How do you deal with failures ? Logging ? Do you know whether the chown actually changed anything ? (Which might be cause for concern) ? Don't get me wrong - glump might be the right tool for the Fedora infrastructure, but you should be conscious about the issues it does _not_ address compared to a full-fledged config mgmt tool. David

On Wed, 2006-12-20 at 02:07 -0500, seth vidal 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 ? How are bugs getting addressed in this model ? Are the Duke and the Fedora Infrastructure deployments effectively forks of the same thing ? 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 ? It sounds to me that instead of reading a few webpages about your config mgmt tool of choice, you have to read and understand a bunch of shell scripts and/or shell libraries (assuming common concerns like logging are addressed by those scripts); you're just trading one kind of learning with another. It's more an issue that if you try to centrally manage configs for machines you quickly run into most of the issues a tool like puppet addresses; from what you've been saying, glump definitely had to address a lot of them. I can't really judge that without having seen the shell scripts that are necessary to make glump more than a template-expansion mechanism. What bothers me about the whole config mgmt space is that even though lots of people encounter those problems, and even though config mgmt is an important problem in practice, there's no tools that are commonly used for it. That's partially because the incumbent (cfengine) falls short on many fronts, and partially because it's so easy to get started with sth really simple and site-specific like glump w/o supporting shell scripts. By the time you realize that your own tool has to address a lot of the harder problems that tools like puppet wrestle with it's too late since migrating to another tool has become a major task. I've spent quite some time looking for a good config mgmt system, and IMHO, puppet is by far the most promising of the lot (including bcfg2). I'd much rather Fedora settled on a relatively widespread and mature tool and worked with its community to address whatever shortcomigns it has than go off and do another custom config tool; and in my experience, puppet is pretty easy to learn and work with (and I am willing to put money where my mouth is if somebody could point me to what kind of prototype setup would help them understand better what puppet is and isn't) True, it has its own language, though the language is straightforard and simple: http://reductivelabs.com/projects/puppet/documentation/languagetutorial.html As to why it has its own language: check question four on the FAQ (http://reductivelabs.com/projects/puppet/faq.html) What exactly is that saying to people who use the ruby that we ship in Fedora ? I understand that there is some concern that another language might cause upgrade problems, but that's true for _any_ additonal software that is used; upgrade problems aren't restricted to language interpreters. And ruby _is_ a mature language that has been around for a pretty long time, i.e. the ruby interpreter poses as much risk for random breakage as any other package you might want to use to maintain your system. David

On Wed, 2006-12-20 at 21:42 +0100, Axel Thimm wrote: That is understandable (though a little different from the reasons given a few days ago here) - I hope that phear of ruby won't keep people from having a look at puppet and comparing its features to bcfg2. David

On 12/20/06, seth vidal <skvidal(a)linux.duke.edu&gt; wrote: That has been my biggest fear of deploying puppet myself. I wish I had the skill to make a 'portage' of it to python as its meta language is what I want in a system. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"

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: 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. 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 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. 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. 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 ;) 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

On Dec 21, 2006, at 7:37, seth vidal wrote: I'm sorry, that's just FUD. Generally: There are lots of components that, if you were truly paranoid, you couldn't upgrade without fear of breaking any sort of mildly complex infrastructure anyway. Yet most of us go along alright with frequent-ish "yum upgrade" or (of course) "up2date -u". More specifically: I don't know the change history of python well, but with for instance perl then any sort of breakage is extremely rare. Maybe I have selective memory, but I don't recall any actually. You should see the lengths they go to to preserve obscure side-effects of bugs and undocumented "features" as they still rapidly are developing and enhancing perl 5. I've only been using Ruby casually for a few years, but I haven't gotten the impression that it's much different in the Ruby community. As someone else pointed out: It's really not reasonable to say "oh, we don't trust we won't break our own packages so let's not use them". Dog food and all. In particular not if the worst case scenario is to login to each box manually to downgrade a bad RPM to get the administration infrastructure going again. Your other argument: "Few here programs in Ruby and critically depending on something we can't fix sucks" is much much better. :-) As a, future, counter argument then the stateless guys are planning to use puppet as a part of that system. If so then there's a good chance it'll be very well integrated with Fedora and RHEL. - ask -- http://develooper.com/ - http://askask.com/

On Tue, 2006-12-19 at 12:14 -0500, seth vidal wrote: To my untrained eye, the glue.xml looks very much like its own language (sure, a simple one, but just because it's XML doesn't mean that it's not its own language. David