Use cases
This chapter gives a few examples for using Rudder. We have no doubt that you’ll have your own ideas too, that we’re impatient to hear about…
Dynamic groups by operating system
Create dynamic groups for each operating system you administer, so that you can apply specific policies to each type of OS. When new nodes are added to Rudder, these policies will automatically be applied to them.
Library of preventive policies
Why not create policies for emergency situations in advance? You can then put your IT infrastructure in "panic" mode in just a few clicks.
For example, using the provided Techniques, you could create a Name resolution Directive to use your own internal DNS servers for normal situations, and a second, alternative Directive, to use Google’s public DNS servers, in case your internal DNS servers are no longer available.
Standardizing configurations
You certainly have your own best practices (let’s call them good habits) for setting up your SSH servers.
But is that configuration the same on all your servers? Enforce the settings your really want using an OpenSSH server policy and apply it to all your Linux servers. SSH servers can then be stopped or reconfigured manually many times, Rudder will always restore your preferred settings and restart the SSH server in less than 5 minutes.
Using Rudder as an Audit tool
Using Rudder as an Audit tool is useful if you do not want to make any changes on the system, temporarily (freeze period, etc.) or permanently.
To use Rudder as an Audit tool without modifying any configuration on your systems, set the Policy Mode to Audit in the Settings, and do not allow overriding.
Using Audit mode to validate a policy before applying it
Before applying a configuration policy to some systems (a new policy or a new system), you can switch the policy mode of the directive defining this policy or of the nodes it is applied to to Audit.
This is particularly useful when adding rules to enforce policies that are supposed to be already applied: you can measure the gap between expected and actual state, and check what changes would be made before applying them.
← Key Features Technical architecture and software dependencies →