sipXecs 4.6 now bundles the open source tool called "cfengine" to apply configuration to a system and manage services. This is a role that a C++ service called "sipxsupervisor" previously filled. sipxsupervisor will continue to be installed and used for until all management is converted to cfengine scripts.
cfengine has many advantages over sipxsupervisor including:
- scripts you can develop without compiling
- rich libraries of scripts to perform common operations
- documentation and written books
- support for idempotent operations.
- scripts that execute then exit so cannot leave memory leaks
- reporting
- key based security built in
Here are some helpful tips with working with cfengine.
Online documentation
- Reference Manual - Best doc for explaining what functions are built into cfengine
- Tutorial - Goes into theory quickly so I don't think it makes the greatest tutorial but you may find some useful explanations however. Much of it regarding how servers work together has already be integrated into sipXecs, or simply does not apply to how sipXecs uses cfengine.
- Standard cfengine Library - There's a library of utilities we including in sipXecs that are available to you scripts.
How to develop cfengine scripts independently
Like a shell script, many times it makes sense to develop your cfengine script outside of sipXecs. Here is the simplest script you could write, and how you could execute it.
# this is a comment
bundle agent mytest {
vars:
any::
"foo" string => "bar";
commands:
any::
"/bin/touch"
args => "/tmp/bar";
classes:
any::
"myflag" expression => fileexists("/tmp/foobar");
files:
any::
"/tmp/foo"
create => "true";
reports:
linux::
"foo variable is $(foo)";
myflag::
"/tmp/foobar does exist";
!myflag::
"/tmp/foobar does *not* exist";
}
body common control {
bundlesequence => {
"mytest"
};
}
And how to run script
cd /var/cfengine/inputs cf-agent -IKvf mytest.cf
"classes" are just booleans
If you're coming from a programming background, classes usually mean OOP. In cfengine, think of them as booleans or flags you define.
Inside an agent "bundle" you can use any of the following "promise types"
- vars
- classes
- outputs
- interfaces
- files
- packages
- environments
- methods
- processes
- services
- commands
- storage
- databases
- reports
They are "executed" in this order. This is very important. Normally the order is exactly what you want, but sometimes it is not. For example you may want a promise in the "commands" section to execute before a promise in "files" section. When this is true, the most straightforward way to to break your bundle into two separate bundles and then change the order in the "inputs" order. Unfortunately your variables are now spread across the two bundles.