help-cfengine
[Top][All Lists]
Advanced

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

Re: Synchronizing replicated data from an RCS to multiple cfengine serve


From: Mark Burgess
Subject: Re: Synchronizing replicated data from an RCS to multiple cfengine servers...
Date: Tue, 08 Nov 2005 21:40:31 +0100

Not sure what you mean by "push". I would not get clients to check stuff
out of a repository directly. That doesn't sound scalable or very secure
(I probably worry too much), but as long
as the appropriate version is checked out in an area that cfservd can
export, there should be no problems copying with it.

I never recommend actual network push mechanisms because they don't work
when hosts are down or unavailable, or DNS doesn't work etc. So it
depends a little on what you mean. You can always simulate push with
cfrun for those accessible hosts.

M

On Tue, 2005-11-08 at 11:37 -0800, Eli Stair wrote:
> I'm moving from a haphazard model with all cfengine config and managed 
> files sitting on disk in one place, and occasionally edited in-place... 
> to storing the config tree and managed files in our Perforce system. 
> I'm referencing the relevant articles here:
> 
> http://lists.gnu.org/archive/html/help-cfengine/2004-07/msg00014.html
> http://www.onlamp.com/pub/a/onlamp/2004/05/13/distributed_cfengine.html
> http://madstop.com/
> 
> What I'm leaning towards is a push-model initiated udpate of the cfservd 
> systems, forcing them to checkout commited (final) changes from the RCS. 
>   Files served by cfengine will be kept in a local ramdisk for speed 
> reasons.  The makefile method Jamie Wilkinson mentioned seems apropos, I 
> like the NIS-like feel of being able to manage things behind the scenes 
> and then with one command update the served-state, though I don't know 
> make so will try it with Perl.
> 
> The only pitfalls I can forsee moving this direction are:
> 1  making sure the ramdisk size/state is sane before starting cfservd 
> (lest you wipe the configs of every connecting host....)
> 
> 2  handling checkout from the RCS and sanity-checking (make sure 
> errorcodes from checkout are handled, and overwrite of existing data is 
> aborted on error)
> 
> 1 is trivial.
> 2 probably requires a bit more work that I think I'm expecting, as the 
> consequences of replicating bad/incomplete/empty checkouts are severe.
> 
> Does anyone see (or experienced) any other issues that are likely to 
> result from this?  Any tips or suggestions on how you are handling a 
> similar situation?
> 
> Cheers,
> 
> /eli
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-cfengine





reply via email to

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