RE: best way to express an 'editfiles' idiom?

[Wheeler, John]

I use somewhat of a hybrid copy approach as well. I generally store all
config files in cvs. These config files are then seeded with values that
must be replaced. After a checkout, the file is copied and the values
are replaced with editfiles Replaceall based on classes that dictate the
replacement values.

If you require a service to be restarted based on the file changing, you
could edit the file in the cvs sandbox and copy to the destination only
if the files differ.

> -----Original Message-----
> From: Eric Sorenson [mailto:eric@explosive.net]
> Sent: Monday, July 21, 2003 1:09 AM
> To: Daniel Pittman
> Cc: help-cfengine@gnu.org
> Subject: Re: best way to express an 'editfiles' idiom?
> 
> On Mon, 21 Jul 2003, Daniel Pittman wrote:
> 
> > OTOH, I don't really want to use 'copy' for a number of these files,
> > because that is a pain when postfix adds a new daemon, for example,
or
> > with a config file for Squid or something.
> 
> Personally, I greatly prefer to use 'copy' for any of this
configuration
> management work. After a couple of attempts to work out how to do
tasks
> that seemed straightforward to me inside 'editfiles' and ending up
with
> baroque hacks that failed, I became disillusioned with the idea of
> editing files in-place with cfengine.
> 
> With some hierarchy to the file selection in cfengine
> (everyone->computers like me-> my hostname) and some version control
on
> the repository, this turns out to have several advantages over
> 'editfiles':
> 
>     - you can use whatever generative front ends (perl!) to put the
>     files in place
>     - you can see at a glance what changes you've made from week to
week
>     ('rcsdiff', commit logs, etc) instead of having to infer it from
>     changes you've made to the 'editfiles'
>     - I'd aregue that your examples, postfix adding a new daemon or a
> Squid config
>     changing on a running system, are a momentous and unusual enough
>     events you'd really want to test the change and then roll out the
>     exact working file from the testbed; versus test the change,
>     figure out how to make 'editfiles' turn the live version into
>     the new version, roll out the cfengine config and hope the change
>     'took' properly...
> 
> With these points in mind, a 'copy' line for each file I manage turned
> out to not be so bad :-)  YMMV, and I'd love to hear more discussion
on
> this topic...
> 
> --
> 
>     Eric Sorenson - EXPLOSIVE Networking - http://explosive.net
> 
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-cfengine