On 9/24/10 10:33 AM, "Francisco Reyes" <li...@stringsutils.com> wrote: > Aleksey Tsalolikhin writes: > >> Classes provide an implicit if/then test. There is no else. >> But you can negate a class: if not class, then x. >> Negate with !, like this: >> !class:: >> promise > > How about either nesting classes or having more than one condition? > > My initial plan was to have a test environment and a production environment, > but then I remembered I have two locations.. For now if I can't figure out > an easy way to separate variables I will just do one location.. > > I need to test > Am I in Location A > Is this test setup > Not test setup > Am I in location B
You don't just have to use classes, there are also variables... > I may also, not sure yet, have a test setup on location B. > Would it be easier to just have a policy server by location? You can do this if you need to for scalability or other business needs, but the location of the policy server is not necessarily tied to the location-specific information in your configuration files. For our larger sites, I deploy N+2 policy servers behind load balanced VIPs. Several smaller sites phone-home over WAN links to our "master" cluster (which just happened to be the first one built). The primary difference here is that the "master" cluster exports contents from CVS, and the other "mirrors" just rsync. Point being, the smaller sites pull location-specific configuration from the central policy host with no problem. > Even the "global" files that I will be copying have different settings > according to location. For example > /etc/resolve > /etc/ntp.conf For "global" files that will exist on almost every host we manage, we have stuff like this in CVS: CVSROOT/os/global/etc/resolv.conf.coloA CVSROOT/os/global/etc/resolv.conf.coloB CVSROOT/os/global/etc/resolv.conf.coloC ... Then in our 'global' policy we have a copy statement like: $(masterfiles)/os/global/etc/resolv.conf.$(location) dest=/etc/resolv.conf mode=0644 owner=0 group=0 server=$(policyhost) trustkey=true verify=true encrypt=true And $(location) is set to colo* matching the files in the repository. This location value is derived from our asset database (and cached locally by the module in case it's unreachable for some reason), but you could do something similar by just setting it via DNS sub-domain. Then as you spin-up new sites, policy doesn't change...you just checkin new site-specific files. _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
