Rudder - Management

Client-server communication

Configure the networks from which nodes are allowed to connect to the Rudder policy servers to get their updated configuration policy.

You can add as many networks as you want, the expected format is: NetworkIP/mask, for example "42.42.0.0/16".

Relay synchronization method

Configure the method used to synchronize files between Relay servers and the Rudder server.

The classic method doesn't require any setup and use the standard protocol. However, it does not scale beyond 1000 nodes per relay.

The rsync method triggers rsync synchronization between each Relay and the Rudder server, for the selected resources (policies and/or shared files). It is more efficient, but you need to manually set up rsync on the Relay servers, and proceed with the SSH key exchange. Note that ressources not selected below won't be synchronized.

Finally, the manual method disable all synchronization of policies and shared files between the Relay servers and the Rudder server; you will need to manually set up a transfer method.

[messages]

Security

[messages]

Protocol

[messages]
Unexpected reports interpretation
The two following settings affect the interpretation given to some type of unexpected reports when computing compliance. These options will take effects when the next reports are received from a node or if you "clear caches" below.

Duplicated reports

Due to the underlying protocol used to send compliance reports back to the policy server (syslog), it may happen that some reports, for an unitary control point, are duplicated. In that case, compliance for the corresponding element will be "unexpected": Rudder was awaiting one report, but it got two. The risk to have a real error reported as a duplicated messages is very low, as messages need to have the same timestamp and information message to be considered duplicated on a given node.

That option will ignore the duplicated message in compliance computation and log an information level message about that duplication. A double duplication will still be ignored but with a warning log, and more duplicates will lead to an error log and an unexpected compliance.

It is safe to ignore duplicated reports and you should check that option.

Unbounded reports by elements when a variable is used

Rudder await exactly one compliance report for each configuration point of control. If it gets more than one, the leftover reports will be considered as unexpected. This is not what one want in the case where:

  • the point of control is parametrized by a variable,
  • that variable is multivalued.

For example, if you build a technique in editor with the generic method "Variable iterator" to define a list of packages and you use the resulting variable in "Package present" generic method for the "name" parameter, it is normal and expected to get several compliance reports, one for each configuration value.

That option allows to increase the number of expected reports to the number of configuration values and so it avoids to get and "unexpected" compliance in that case.

Unless it is more important for you to get "unexpected" compliance than the actual compliance of each configuration value, you should check that option.

[messages]

Set default settings value on node acceptation

Configure the default state and policy mode that a node get when it is accepted.

[messages]

Change audit logs

If enabled, prompt users to enter a message explaining the reason for each configuration change they make.
These messages will be stored in each Event log and as the commit message for the underlying git repository in

[messages]

Modified files

Every time Rudder modifies a file (by file editing or copying from a remote source), a backup is created on the agent under /var/rudder/modified-files/.

[messages]

Logging

All nodes in Rudder send reports via syslog to this Rudder root server. These logs are stored in an SQL database in order to determine compliance information displayed in this web interface. However, it can be useful to also store this information in a plain text log file, for example for statistics or debugging purposes. The option below enables this.

Also, the full output from each agent run is stored in a file under /var/rudder/cfengine-community/outputs/. These files are automatically removed to save on disk space. You can configure the retention time (Time To Live) they are kept for here.

[messages]

Usage survey participation

To help the Rudder team continue to improve this software day after day, we are running a survey to collect usage statistics.

These statistics are submitted anonymously, and include overall statistics about your instance of Rudder (number of Rules, Directives, Nodes, etc). No potentially-sensitive data is included (only stock Rudder-provided techniques are examined, no hostnames, etc). We highly value your privacy, as we do our own, so we will never share individual submissions (only globally compiled statistics).

If you want to check the information that is sent, just run /opt/rudder/bin/rudder-metrics-reporting -v on your Rudder server. This won't send any information without your consent.

This information is very valuable to the development team, as it helps us focus on the features that matter most and better understand what our users care about. Please consider participating in the survey!

[messages]
Display compliance and recent changes columns on rule summary
In directive configuration page, we have the possibility to choose rules for the directive. The rule are presented in a summary table which look alike the one in rule page. For performance on aesthetic reason, you may want to hide compliance and recent changes columns on that table. The column will still be displayed on the rule page.
[messages]

Display changes graphs

In Rules table, we display a graph for each Rule showing its activity (number of repaired reports).

Unfortunately, some browsers (especially Firefox) have trouble displaying them and make Rule pages almost unusable.

If you experience slow loading of Rules pages, you can disable this feature here.

[messages]

Enable script evaluation in Directives

If enabled, all password fields can contain a JavaScript expression. These expressions are evaluated during promise generation, and can therefore provide unique values for each node. Read the script documentation for more information.
[messages]

Clear policy caches

Clear cached data. This will trigger a full policy update, and regenerate all promise files.

[error]

Manage dynamic groups

Groups in Rudder can be static (fixed list of nodes) or dynamic (the list of nodes is built from a search query).

To take into account new nodes and changes to their inventory, dynamic groups must be reloaded regularly.

Currently, Rudder will automatically do this reload every 5 minutes (see /opt/rudder/etc/rudder-web.properties).

[error]

Manage Technique library

Techniques in Rudder are read from the filesystem (in /var/rudder/configuration-repository/techniques).

To take into account new Techniques and changes, the Technique library must be updated regularly.

Currently, Rudder will automatically do this update every 5 minutes (see /opt/rudder/etc/rudder-web.properties).

Launch support script

Launch the support script (/opt/rudder/bin/rudder-support-info) to get information about your setup.

The provided information are used to troubleshoot Rudder.

Data includes various commands about your install (package version ...), your system and useful logs

[error]