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

[Mark Burgess]

I see :)

On Tue, 2005-11-08 at 12:48 -0800, Eli Stair wrote:
> 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
> > 
> > 
> > 
>