Re: Synchronizing replicated data from an RCS to multiple cfengine servers...

[Eli Stair]

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
> > Help-cfengine@gnu.org
> > http://lists.gnu.org/mailman/listinfo/help-cfengine