This page presents detailled information about rulesets.
The variable namespace is unique and global.
Doing so, users can easily detect such design errors and nodes and services are protected from doing checks and fixes based on an unexpected rule.
All variable names are prefixed by OSVC_COMP_ by the collector before serving the a requesting agent. As the agent loads these variables in the session's environment, this prefixing ensures no pre-existing variable can be overwritten.
Compliance objects always expect a variable prefix name as its first parameter. Such a prefix starts with OSVC_COMP_, as described above, but the rest of the string is user-defined.
The choice of this user-defined prefix is important as it allows a single call to a compliance object to handle a set of variables, eventually picked in different rulesets.
A ruleset contextually exports the authkey-class variables OSVC_COMP_SUPPORT_TEAM_AUTHKEYS_PRD_[0-9]* to the production nodes. A ruleset contextually exports the authkey-class variables OSVC_COMP_SUPPORT_TEAM_AUTHKEYS_DEV_[0-9]* to the development nodes.
Fixing this same module on a production node will deploy the ssh public keys of the members of the production support team, but will deploy the ssh public keys of the members of the development support team.
The collector auto-generates rules for nodes and services. These rules export data known to the collector about the node or the service.
to implement condition in the modules based on information usually not available to the node, such as its geolocation or power lines. Note, this case is better handled by contextual rulesets.
This ruleset is exported to nodes and services. It contains information about the node where the nodemgr compliance ... command or the svcmgr -s <svcname> compliance ... command is executed.
This ruleset is exported to services only. It contains information about the service the svcmgr -s <svcname> compliance ... command is executed on.
This ruleset is exported to services only. It contains information about the status of the service the svcmgr -s <svcname> compliance ... command is executed on.
Contextual ruleset variables are exported to the nodes and services matching the ruleset's filterset.
Rulesets can be flagged as published or not published.
Ruleset encapsulation is achieved by attaching a ruleset (the child) to another ruleset (the parent).
Encapsulation can be arbitrarily deep.
Encapsulated rulesets visibility is evaluated by walking the encapsulation tree top-down.
Customize rules of a ruleset based on contextual information. For example, a ruleset describing a monitoring agent configuration might want to point a different tarball based on which operating system and which version is executing the compliance module. For another example, a ruleset publishing the nameservers to use might want to publish different nameserver lists for different datacenters.
Minimize the number of filtersets necessary to cover all needs. As filters are cumulative in a nested contextual ruleset relationship, encapsulation aleviate the need to define as filtersets most filterset combinations. For example, x86 servers => linux servers, x86 servers => solaris servers, x86 servers => freebsd servers, x86_86 servers => linux servers, x86_86 servers => solaris servers, x86_86 servers => freebsd servers would require 5 filtersets, where a flat ruleset design would require 6. The factorization factor increases dramatically with ruleset complexity.
from a server, if the team responsible property of the server matches one of the ruleset publication groups.
from a service, if one of its application code responsible groups matches one of the ruleset publication groups.
A ruleset can also be visible because it is encapsulted in a visible top-level ruleset or moduleset, whatever the encapsulation depth, and whatever the ownership of the child.
Upon creation or cloning, the new ruleset is stored at the tree head and is owned by and published to the creator's primary group, or the creator's private group (user_<n>) if he has no primary group set.
The creator can then add, delete, rename, change the value of rules without the rulesets of servers and services being affected.
When the design session is over, the creator's can attach new groups to the ruleset and/or insert the ruleset as a child of a visible ruleset.