I have experienced that when people talk about a system’s configuration, they mostly think of software to be installed and configuration files to be deployed. That’s true, they are part of a system configuration, but there’s more to it — if Configuration Management was only that, you could rightfully call it “provisioning” instead. For example, another part of a system’s configuration is that certain critical services must be running and/or certain other services must not be running. And in fact, any configuration management tool has provisions to manage system services and ensure they are in the desired state (while they may differ a lot on the “when” and “how” and “how often” the state is checked).

CFEngine is no exception. You can take advantage of ready-to-use frameworks like NCF or EFL, or  roll your own checks. What I’m presenting you today is a simple bundle that I wrote called watch_service, that you can use to ensure that certain system services are up or down.

My approach is similar to NCF’s bundle called service_action in that it tries to provide a generic, system-agnostic bundle to manage services but with a few differences:

• while service_action relies on information in NCF itself to make the bundle simpler to use, my watch_service relies only on CFEngine’s standard_services knowledge as available in the standard library;
• while service_action returns information to the agent in the form of namespace-scoped classes (e.g.: the service was in the desired state, or the service was not in the desired state and the problem has been fixed successfully), watch_service only reports about the events by means of another bundle called report, whose code will be also provided in the last part of this post.
• service_action supports many different actions, watch_service only supports “up” (ensure the service is running) or “down” (ensure the service is not running).

Continue reading →

Now that the upgrade from 3.4 to 3.6 is advancing slowly but steadily I am starting to check the features that are new in 3.6 compared to 3.4.  According to the docs namespaces were actually introduced in 3.4.0, but I didn’t take advantage of them yet, and it’s time to start.

When something is declared in a namespace (a bundle, a variable or whatnot) it must be referred to with its namespace. For example, if you declare a bundle test in the namespace nstest, you’ll refer to that bundle from outside the namespace (e.g. in the bundlesequence) as nstest:test. If you declare a variable, for example an array called conf in that bundle, that will be nstest:test.conf outside the namespace. So far so good.

Now, what happens inside the namespace? Well, I found one fact that is indeed surprising.

Continue reading →