help-cfengine
[Top][All Lists]
Advanced

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

Re: ctime vs checksum in copies


From: Atom Powers
Subject: Re: ctime vs checksum in copies
Date: Wed, 30 Nov 2005 14:09:02 -0800

This is an example of what I do:
####
editfiles:
        { # the Bacula file daemon
        /usr/local/etc/bacula-fd.conf
        AutoCreate
        EmptyEntireFilePlease
        InsertFile "$(FileSource)/common/usr/local/etc/bacula-fd.conf.temp"
        ReplaceAll "<-HOST->" With "$(host)"
        DefineClasses "newbacula"
        }
####
Where $(FileSource) is a local repository.

On 11/30/05, Nielsen, Steve <SNielsen@comscore.com> wrote:
> Generally I have this approach:
>
> - copy the template over to a "temp area" (i.e. /var/cfengine/temp)
> - do file edits on the temporary copy
> - compare the temp copy to the production and copy if changed (using
> checksum).
>
> This has worked really well for me.
>
> Steve
>
> -----Original Message-----
> From: help-cfengine-bounces+snielsen=comscore.com@gnu.org
> [mailto:help-cfengine-bounces+snielsen=comscore.com@gnu.org] On Behalf
> Of Paul Krizak
> Sent: Wednesday, November 30, 2005 1:14 PM
> To: help-cfengine@gnu.org
> Subject: ctime vs checksum in copies
>
> I've got a question about what you guys think the best solution is in
> this situation.
>
> I've got some files that must be customized on a per-host basis, but are
>
> based on a common "root" file.  My goal is to have the following system:
>
> * When the system is first installed, or if the file on the system is
> wildly different than the master, a copy: statement pulls down a fresh
> copy of the file, which an edifiles: stanza corrects for that specific
> host.
>
> * Later, if the master file changes, the clients should "know" to pull
> down a new copy of the file, and then perform the same editfiles: stanza
>
> again.
>
> Using "checksum" for the copy statement doesn't really work, since once
> you make a change to the file using editfiles:, the checksums don't
> match and thus the file gets copied every time.  On the upside, you're
> guaranteed to always have the correct version of the file on the target
> system.
>
> Using "ctime" for the copy statement *sounds* good, as the copy only
> happens when the "master" file updates on the server.  Where this falls
> flat, however, is on freshly installed systems, where the ctime of the
> *incorrect*, freshly-installed file is *later* than the ctime of the
> "master" file.  In this situation, the "master" file is not copied (and
> I wouldn't expect it to).
>
> I've got several cases in my (very lengthy) cfengine config where I run
> into this type of issue.  For small files, I can put the entire contents
>
> of the file into an editfiles: block and avoid using copy: at all.  This
>
> doesn't work for large files, however, as I don't want a cf.* file to
> have a 5,000-line config file in it with Append statements.
>
> For large files, I use checksum copies and just accept the fact that
> they will get copied every time cfagent runs.
>
> I'm looking to improve convergence in my config files...anybody else
> have clever workarounds for this problem?
>
> --
>
> Paul Krizak                         5900 E. Ben White Blvd. MS 625
> Advanced Micro Devices              Austin, TX  78741
> Linux/Unix Systems Engineering      Phone: (512) 602-8775
> Microprocessor Solutions Sector
>
>
>
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-cfengine
>
>
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-cfengine
>


--
--
Perfection is just a word I use occasionally with mustard.
--Atom Powers--




reply via email to

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