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 > >>[email protected] > >>http://lists.gnu.org/mailman/listinfo/help-cfengine > > > > > > >
_______________________________________________ Help-cfengine mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-cfengine
