This section addresses some advanced or discouraged usages of variables, or implementation details that can be relevant for debugging or integration purpose. If you want to learn about how variables are defined and used in Rudder, see Variables.

Overriding generic_variable_definition by sorting policies

You can use the merge of "Generic Variable Definition" directive to define variable override.

This technique is discouraged, as it is rather hard to follow what value goes on which node. You should always prefer to use either global parameter/group property hierarchy override for IT ops knowledge, or creating `json` files in node local override directory, which is much easier to debug on site.

For example, let say you want to define a DNS variable with default value [default dns] and on some node case, a value [overridden dns]:

  • Create a Directive [1] with high priority: it will be your default case, so set DNS to [default dns].

  • Create an other Directive [2] with lower priority: it will be your specialized case, so set DNS to [overridden dns].

Then, a node with only Directive [1] will have the default value defined, and a node with both Directives will have the overriding one.

It works because on the agent, you can redeclare a variable name and reassign to it a new value: the last one wins (so in our case, the lowest priority).

Technical implementation of Node properties

On the server, one or more properties files are written for each node in the /var/rudder/share/<uuid>/rules/cfengine-community/properties.d/ directory. This directory is then copied to each node by the agent with all other policy files.

In the agent, properties are made available in the node.<namespace> container that contains the values. Those values are read from /var/rudder/cfengine-community/inputs/properties/*.json. All files are taken in order and override the previous ones - the last one wins.

The agent searches for optional properties files /var/rudder/local/properties.d/*.json, and will define variables or override existing properties.

Each file must contain at least 2 levels of JSON content, the first level is the namespace level and the second level is the key level.

The namespace name must be an ASCII name that doesn’t start with and must match the following regex: [a-zA-Z0-9][a-zA-Z0-9]*

For example:

    "datacenter": "Paris",
    "environment": "production",
    "customer": "Normation"

The merge is a first level merge done at the namespace level. This means that:

  • a key in a namespace is fully overridden by the same key in the same namespace in a later file.

  • a key in a namespace is never overridden by the same key in a different namespace

  • a key that is overridden never retains original data even if it is a data container itself

The result key is available in the node.<namespace> data variable. A usage example:


Note that even if properties' name is case-sensitive, collision can occur, on nodes based on Windows agent. We strongly recommend to use distinct strings for property’s name, in particular on Windows node.

To get the original data (for debug only) there is the properties.property_<fileid> variable. A usage example:


← Man pages Plugin format →