Will Maier wrote:
On Tue, Dec 19, 2006 at 03:00:04AM -0700, Clint Pachl wrote:
I would use a dedicated, highly secure and always backed-up box to
store/manage a central repository (CVS/SVN). This repos will hold
all the necessary bytes (binaries, config files, ports, etc.) to
"re-image" any machine from scratch. Each node on the network
would then "pull" everything it needs from the central repos using
method X. That's the part I'm trying to figure out. I want the
whole automation system to be simple and would like to use only
default tools.
I think I understand the reason why you want this ('only default
tools'). That said, there are good reasons that specialized tools
exist to solve this problem: it's complex. You want your install and
configuration management system to be robust; something hacked out
of whatever happens to be in base seems potentially quite fragile.
I'm not so convinced it is that complex on a homogeneous OpenBSD
network. OpenBSD is a very manageable system, such as the entire OS
contained in compressed tarballs for easy extraction and the flexible
ports system. Both of these entities are easily scriptable. Then all
there is to worry about is system configs and custom binaries, which can
be easily managed by CVS. A hierarchal CVS structure can be built to
mange global (all nodes in network), group (groups of similar servers),
and single (things specific to a node, like /etc/myname) nodes. You
apply global settings first, overwriting with more specific settings.
A pull-only system assumes that the clients actually pull. What if
they don't? How do you know when their last successful pull was?
If you implement a "push" system, how do you know if something was
actually pushed? What if something was pushed, how do you know the
"pushee" did the right thing with what it was given? This argument goes
both ways, but solved simply. A system should report what it does after
it pushes or pulls. The other end should also report. So if the results
show someone is pushing, but no one is pulling or visa-versa, you have a
problem. This system could be implemented using mail or central syslog.
A good argument for "pull" systems:
http://www.infrastructures.org/bootstrap/pushpull.shtml
What do others think about push vs pull management systems? What tools
are you using to implement your push/pull management system?
If all they're doing is pulling, do you need eg one pf.conf file per
client? How many clients do you have? How many might you have in a
year? two years? Using a client imaging system as the sole
configuration management system is heavy-handed and inflexible --
you'll find lots of situations where you want more control over who
gets what file (or what action occurs where).
Just because it is a pull system doesn't mean that every node must pull
the same collection. It would pull first from global, then group, then a
repository dedicated to that specific node.
cfengine was mentioned elsewhere in this thread, and it's the most
prominent FOSS configuration management thingy that I'm aware of.
It's got warts, but it's widely used and mostly solves the problems
you're looking to solve.
This is what I don't like to hear: as you say, "It's got worts...",
"mostly solves the problems.." Why not build something that has no worts
and solves all problems all the time to your specs. And most
importantly, I use OpenBSD because of its simplicity and robustness and
I like my tools to act the same. I guess I haven't heard enough good
about cfengine to pique my interest in it.
-pachl
