You make a good point about update.conf being self contained.
By moving the definition of cf_policy_hosts into update.conf that seems to work now.
I understand that this mechanism works as documented, meaning that it iterates of each server in the list. I guess I was hoping for a little more intelligence, in that it would only go onto other items if the first one failed. I realize I could hack this together by duplicating each copy line and using the failover item to define a class, but that just seems dirty. Am I missing something or is there a better way to get a master/slave or primary/secondary type of relationship between two cfengine "servers".
Thanks again, Michael On Apr 7, 2006, at 10:01 AM, Ed Brown wrote:
Michael Grubb wrote:Here are the relevant entries in update.conf: import: main.cf #... snip ... copy: $(cf_master_inputs) dest=$(cf_workdir)/inputs server=$(cf_policy_hosts) The relevant entry in main.cf: control: cf_policy_hosts = ( polserv1.domain:polserv2.domain )Um, this time I read a little more carefully. I don't know about doing any imports from update.conf, I just don't do it: update.conf alone should be capable of bootstrapping all your configurations.But even in context main, it doesn't work in my tests just now to define a list variable for 'server' in an imported file, for a copy action in the importing file.Because update.conf runs in it's own context, and should (at least in my view) be self-contained, there is no getting around some redundancy in its contents with cfagent.conf and friends. Try including your cf_policy_hosts definition in update.conf.-Ed _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org http://cfengine.org/mailman/listinfo/help-cfengine
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org http://cfengine.org/mailman/listinfo/help-cfengine
