bcfg2

[David Lutterkort]

On Wed, 2006-12-20 at 02:07 -0500, seth vidal wrote:
> On Tue, 2006-12-19 at 14:45 -0800, David Lutterkort 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
> 
> Which we cover in the set of scripts (just shell scripts) that I sent
> along with our glump configs to mike mcgrath when he was looking at it.

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 ?
 
> > 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.
> 
> Not terribly important when all the machines are managed by the same
> people.

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 ?

> The point is you're not learning a new set of skills and a new layout of
> things to get the job done. You're just extending the skills you already
> have. Glump just lets you deploy them in a logical sets to lots of
> various systems.

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.

> glump isn't trying to be everything for everyone. 

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.

> It's just a very straightforward mechanism for keeping track of systems.

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)

> my concerns about puppet are the new language for things:
> 
> class passwordsync {
> # remotefile is syntactic sugar - see the defintion in the docs
> remotefile { "/etc/passwd":
> server => 'server',
> source => 'passwd',
> }
> }

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)

> and of course the concern I issued before is that it ties us into yet
> another scripting language for systems-maintenance tasks.

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