Re: bcfg2
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.
Furthering the already existent shell scripting skills that most
sysadmins already have is what I was talking about.
How are bugs getting addressed in this
model ? Are the Duke and the Fedora Infrastructure deployments
effectively forks of the same thing ?
That really depends on what we want to 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?
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.
not really. You're extending your knowledge that already exists (every
sysadmin is implicitly capable of moderate to advanced shell scripting)
rather than capturing a specialized knowledge set for a single use.
> 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.
and we've addressed a lot of them.
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)
This is just it. I don't care to learn another one-off language. There
are enough of those as it is.
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.
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
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.
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.
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.
it has nothing to do with the language itself, just the proliferation of
ones we rely on for admin tools.
-sv