help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Editfiles Considered Harmful


From: Ted Zlatanov
Subject: Re: Editfiles Considered Harmful
Date: Thu, 04 Dec 2003 10:19:54 -0500
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (usg-unix-v)

On Wed, 3 Dec 2003, eric@explosive.net wrote:

> Use CVS. Make a directory tree that looks like a filesystem, and
> populate each leaf directory with the files you want to
> manage. Either make separate trees per host-class or use class-keyed
> filename extensions in a unified tree, it really doesn't matter. Use
> copy: with checksums, not date-stamps, so machines which get
> installed after your latest config change still get the
> authoritative version.  Use a define=className in your copy
> directive to specify triggers for restarting the affected service
> daemon (remembering to pre-declare className with AddInstallables in
> your control: section).

I did this as well, it is interesting to see how many others along
with me have hit on the same idea of a logical repository that's
distributed to physical locations.  I guess that validates the need
for it.

The way I implemented this hierarchy in cfperl
(http://lifelogs.com/cfperl) was to use logical names for files, so
the whole hierarchy wouldn't be stored.  So for instance /etc/passwd
is just called "passwd".  This is a pain when you're defining the
files, but you end up with very manageable hierarchies.  There are two
cases for file distribution though.  I'll show what I mean for a
machine "horse" of only groups "solaris" and "server."

"global" files are preferred from a global namespace before the
specific namespace version.  So if /etc/nsswitch.conf maps to
"nsswitch.conf" we would search thus:

1. ROOT/spec/server/solaris/nsswitch.conf or
   ROOT/spec/solaris/server/nsswitch.conf
(if both exist, that's an error)

2. ROOT/spec/solaris/nsswitch.conf or ROOT/spec/server/nsswitch.conf
(if both exist, that's an error)

3. ROOT/spec/nsswitch.conf

4. ROOT/horse/nsswitch.conf

"specific" files are preferred from the specific namespace before the
global namespace.  So let's say we're concerned with
/.ssh/authorized-hosts and map it to ssh-authorized-hosts.  Given the
same "horse" machine in classes "solaris" and "server," the search
would now be:

1. ROOT/horse/ssh-authorized-hosts

2. ROOT/spec/server/solaris/ssh-authorized-hosts or
   ROOT/spec/solaris/server/ssh-authorized-hosts
(if both exist, that's an error)

3. ROOT/spec/solaris/ssh-authorized-hosts or
   ROOT/spec/server/ssh-authorized-hosts 
(if both exist, that's an error)

4. ROOT/spec/ssh-authorized-hosts

It would be nice if cfengine itself included this sort of deployment
hierarchy or something similar, but I'm pretty happy with it as
provided by cfperl.

Ted




reply via email to

[Prev in Thread] Current Thread [Next in Thread]