John Sanders shared a pattern for canonifying lists in #CFEngine on irc.freenode.net yesterday. It’s a useful reference so I thought I would replicate it here. 1 2 3 4 5 6 <td class="line-data"> <pre class="line-pre"><div class="line" id="file-output-LC1"> % cf-agent -KIf ./example_canonify_list.cf R: canonified site: www_example_com R: canonified site: www_example2_com R: alternate canonified site: www_example_com R: alternate canonified site: www_example2_com !! Method invoked repairs <div class="gist-meta"> <a href="https://gist.github.com/nickanderson/5271023/raw/d57a43831308cf31f0a5fe237b3d3436ed3d3049/Output" style="float:right">view raw</a> <a href="https://gist.
There is a known bug where getindices is unable to get the index of a dynamically generated array until the next pass. This comes up from time to time so I thought I would post an example using a pattern shared on the CFEngine help mailing list. The policy below shows 3 working examples. They are mostly similar, example0 shows the simplest workaround, example1 and example2 in addition show ways to suppress the “Duplicate selection of value for variable” messages.
bundle common knowledge(status) { vars: "software" string => "$(status)", policy => "free"; !isUsable:: "software" string => "usable", policy => "free"; isUsable:: "software" string => "reusable", policy => "free"; classes: "isUsable" expression => regcmp("$(software)", "usable"); "reUsable" expression => regcmp("$(software)", "resuable"); reports: Morning|Afternoon|Evening|Night:: "Before software can be reusable it first has to be useable.", comment => "Ralph Johnson"; }
Changelogs are just as important as the most important meal of the day. OK so I don’t always eat breakfast, but I do make an effort to read changelogs. CFEngine 3.4.2 was released today. What I found interesting was that the default masterfiles policy has been updated. body executor control now calls $(sys.workdir)/inputs/update.cf instead of failsafe.cf. And $(sys.workdir)/failsafe/failsafe.cf (which was new as of 3.4.0) is gone. I think its a good change.
Sometimes you want to know what value zenoss has for something. The numbers sent in alerts seem to be the value that zenoss has, but the graphs are usually formatted to make more sense. 1394606080 might come in an alert, but on the graph it would show as 1.3 or 1.4G. It can cause some slight confusion when other people expect 90% of 1.4G instead of 90% of 1394606080 to be an alert threshold.
Over the past several months 2 years (since 3.1.2 release, wow time flys when your having fun. I checked and 3.1.2 was released on Dec 9th 2010.) I have seen a few questions regarding how the default CFEngine policy update works, and more specifically how cf_promises_validated plays into the update process. This is my stab at describing the history and behaviour. I welcome any corrections. The default failsafe.cf update policy is simple in nature.
CFEngine defines a classes for decision making during runs. Many of these hard classes you can see by running cf-promises -v. That wont show you all the other classes that are raised during a policy run. You could run something like this to see what classes are raised during execution. cf-agent -KIv | grep "cf3>\s*+" | grep -v : But that isn’t really a clear picture under normal operation. You can use the allclassesreport in body agent control to write out a list of classes defined during execution in /var/cfengine/state/allclasses.
Methods type promises are powerful abstraction tools in CFEngine 3. Methods allow you to activate bundles (optionally parametrized) from other bundles. This allows encapsulation of knowledge and lends itself to re-usability. I just want to share an example of calling bundles dynamically. It’s a contrived example, but I thought it was neat so here it is. R: in bundle agent handler1: I got value1 R: in bundle agent handler1: I got value2 !
Are you going to LinuxCon/CloudOpen 2012? I am, and I think I have settled on my picks (at least until I look at the schedule again, lots of great options). Special thanks to CFEngine for sponsering me! Here are my picks for the minute. Building the Open Cloud – Mark Hinkle, Citrix{#9046eff8494ef50f48da95349905592e} The OpenNebula Cloud Platform for Data Center Virtualization – Carlos Martin, OpenNebula{#5561a1f9b3d063dcca4b7abdc5dbc44b} Cloning SysAdmins with the Cloud and Juju – Clint Byrum, Canonical{#82e5d5410f32e11be9bd9bddf2b81570} A Collaborative Approach to Managing Linux Configurations – Diego Zamboni, CFEngine{#da5dea5f6f017f925dac66eec964f13f} Building FOSS Clouds – Joe Brockmeier, Citrix{#c28982d2a4f52cbfbb4000ce030a1771} Automation and DevOps Best Practices – Rob Hirschfeld, Dell{#f0cd279b854c642d12e7d531c68c53f0} Scaling Configuration Management Across Data Center and Cloud – Mark Burgess, CFEngine{#e9936ee3a0369080a61b61f5eb9a88d4} Editing with vi: Advanced Topics, Part I – Aleksey Tsaloikhin, Vertical Sysadmin, Inc.
I was inspired by William Orr’s svn commit hook and looked up the magic needed to flesh out the git pre-commit hook I submitted to the Design Center a while back. Now the index is checked out to its own temporary directory and cf-promises validates promises.cf and failsafe.cf before allowing the commit to proceed. Now you won’t get syntax errors if you have forgotten to add a new policy file to the index but its already included in your body common control inputs list.