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 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? Even the "global" files that I will be copying have different settings according to location. For example /etc/resolve /etc/ntp.conf Within each location those files are the same regardless of machine functionality. For best practises is it better to have a single setup or to have one setup per site? I can't think of any file that will be the same on my two, soon to be three, locations. In other words, within each location there are many files that are common to many or all machines, but the files are all different to the same files on another location. The way I see it. Pros of single setup it that it is all in one place so when trying to see what cfengine is doing across the whole company there is only one place to look. Cons of single setup is that then the setup will likely be significantly more complex. The more locations the more complexity. Pros of multiple setups. Each config is simpler. Cons of multiple setups. May need to look at different places to see all the rules, but I think perhaps a unified version control system may somewhat solve the issue. _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
