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: Mark Burgess
Subject: Re: ctime vs checksum in copies
Date: Wed, 30 Nov 2005 21:26:37 +0100

Sure it does:

 install::

  (copy) type=checksum # only during install

 !install::

  (copy) type=ctime  # any other time

M

On Wed, 2005-11-30 at 14:19 -0600, Paul Krizak wrote:
> That's a fairly nifty approach, though it doesn't address the core issue 
> of having to pull the master template off the server every time cfagent 
> runs.  This isn't a big deal for 100-1000 hosts, but within 12 months 
> I'll be dealing with around 10,000 hosts, and doing something like 
> copying a 20k file once an hour (or even once a day) can do suprising 
> things to the network (like bring down filers)
> 
> I'm trying to plan ahead so that as our network grows, the amount of 
> network/CPU bandwidth required to keep the systems up to date stays 
> about the same or even goes down.
> 
> 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
> 
> 
> Nielsen, Steve 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: address@hidden
> > [mailto:address@hidden On Behalf
> > Of Paul Krizak
> > Sent: Wednesday, November 30, 2005 1:14 PM
> > To: address@hidden
> > 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?
> > 
> 
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-cfengine





reply via email to

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