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.
> we have a cron job that runs hourly and nightly that requests
its jobs
> via glump.
>
> glump puts together the shell script for that host and hands it back.
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.
> so if we want to check ownerships or update packages it would
be:
>
>
> chown user.group /path/to/file
> yum -d0 -e0 -y install your_pkg_set
How do you deal with failures ? Logging ? Do you know whether the chown
actually changed anything ? (Which might be cause for concern) ?
That's up to how you want to write the shell script. If you need that
level of caution, do so. If you don't, don't. You can report via logging
or alerts, pretty much whatever function you want to run in your shell
script.
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.
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.
glump isn't trying to be everything for everyone. It's just a very
straightforward mechanism for keeping track of systems. copyfile and
other such tools are just an easy way of deploying file updates for
them.
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',
}
}
and of course the concern I issued before is that it ties us into yet
another scripting language for systems-maintenance tasks.
-sv