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: Eli Stair
Subject: Re: Synchronizing replicated data from an RCS to multiple cfengine servers...
Date: Tue, 08 Nov 2005 12:48:28 -0800
User-agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513)


Yeah, I realize that came out a bit ambiguous.

The clients are all on schedules (cron & cfexecd). I'm updating the files served by cfserved with a push, i.e. the local confsrc they're serving up is only changed during checkout from the RCS and moved into place after some (TBD) validation.


         scheduled pulls
                         \
             cfservd - (pull) > clients
RCS (push) > cfservd - (pull) > clients
       ^     cfservd - (pull) > clients
       |
        \logged/authenticated push initiation



/eli



Mark Burgess wrote:
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
address@hidden
http://lists.gnu.org/mailman/listinfo/help-cfengine








reply via email to

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