Requirements
Browser support for UI
Rudder can be used with recent version (less than 2 years old) of Firefox, Chrome (and derivatives), and Edge. Internet Explorer is not supported.
Network flows - Firewall configuration
The following network flows are used by Rudder for regular operations. Make sure your firewalls allow these connections.
| From | To | Destination | Usage |
|---|---|---|---|
User or API client |
Root |
tcp/443 |
Access Web interface/API |
Node |
Relay/Root |
tcp/443 |
Send reports and inventories, fetch files |
Linux/AIX node |
tcp/5309 |
Fetch policies |
|
Windows node |
tcp/443 |
Fetch policies |
|
Relay |
Root |
tcp/443 |
Send reports and inventories, fetch files |
tcp/5309 |
Fetch policies |
||
Relay/Root |
Linux/AIX node |
tcp/5309 |
[optional] Trigger remote agent run |
Root |
Relay |
tcp/443 |
| If you still have pre-6.0 agents, or use the syslog-only report mode, you also need to have udp/514 (or tcp/514 depending on what you configured) open from nodes to relays or root, and from relays to root server. |
Security
Your Rudder server and relays should generally not be exposed on the Internet. If you manage nodes on remote networks, the usage of a VPN for Rudder communications is recommended.
By default, nodes listen on port 5309 to allow remote agent trigger. On nodes having public interfaces
it is recommended to only allow connection to this port from the server through firewall configuration.
You can also totally disable the service on simple nodes (but not server or relayd) if you don’t want to use remote run with
systemctl disable rudder-cf-serverd && systemctl restart rudder-agent (or an equivalent Rudder policy).
JVM requirements
JVM Version
Rudder fully supports OpenJDK JVM version 1.8u92 to 14.x. Usage of long term support version 11 is recommended.
Version 1.8 prior to u92 are not supported due to the use of JVM option CrashOnOutOfMemoryError. In any case, even if you
are blocked on java 1.8 branch, you should really use the latest version available (8u292 as of 2021-04): there are major
performance impact and security risk by not doing so.
OpenJDK 15 is not yet fully supported in Rudder 6.x branch because of the removal of JVM native JS engine in that version. You can use JVM 15 but you will need to disable "script evaluation in Directives" in Settings → General. That limit will be lifted in Rudder 7.0.
Other JVM should work but they are not thoroughly tested. Please contact Rudder team for more information on that topic or dedicated support.
JVM Security Policy
Rudder needs unlimited strength security policy because it uses a variety of advanced
hashing and cryptographic algorithms only available in that mode.
Any recent JVM (JDK 8 > 8u161, all JDK 9 and more recent) is configured by default with this policy.
You can check your case by running the following command on your server:
jrunscript -e 'exit (javax.crypto.Cipher.getMaxAllowedKeyLength("RC5") >= 256 ? 0 : 1);'; echo $?
If it returns 0, you have the correct policy. In other cases, you will need to change it.
For that, you can download the
unlimited strength policy for JDK 8 here.
Then, simply copy the java.policy file into $JAVA_HOME/jre/lib/security/java.policy.
Cloud compatibility
The agent provides an abstraction that permits a high level management of the infrastructure. This abstraction is independent of the underlying hardware. This also works for the cloud - we can define configuration rules in Rudder that will be applied as well inside a cloud instance as in a virtual server or in a physical machine of a datacenter.
Any cloud instance based on one of the supported operating system is automatically supported.
Hardware specifications for Rudder Agent
Rudder agent has a very small footprint, and only consumes:
-
10 to 20 MB of RAM during an agent run
-
a few kB on the network to check or update its policies
-
a few kB on the network to report
-
around 100 MB of disk space for the installed files and the workspace
These figures will vary depending on your configuration (backup retention, number of configured components to check, etc…).
Hardware specifications and sizing for Rudder Root Server
A dedicated server is strongly recommended, either physical or virtual with at least one dedicated core. Rudder Server runs on both 32 (if available) and 64 bit versions of every supported Operating System.
|
Rudder does not fear big infrastructures. It is currently used in production in infrastructure with more than 9000 nodes. |
Memory
The required amount of RAM mainly depends on the number of managed nodes. A general rule for the minimal values, on a stand-alone server is:
-
less than 50 nodes: 2 GB
-
between 50 and 1000 nodes: 4 GB
-
more than 1000 nodes: 4 GB + 1 GB of RAM by 500 nodes beyond 1000.
When your server has more than 2 GB of RAM, you have to configure the RAM allocated to the Java Virtual Machine as explained in the section about webapplication RAM configuration.
When your server has more than 4 GB, you may need to also tune the PostgresSQL server, as explained in the optimize PostgreSQL Server section.
|
As an example, a Rudder server which manages 2600 nodes (with a lot of policies checked) will need:
In our load-tests, with such a configuration, the server is not stressed and the user experience is good. |
CPU
The number of cores necessary also depends on the number of managed nodes. A general rule for the minimal values, on a stand-alone server is: * less than 50 nodes: 2 cores * between 50 and 1000 nodes: 4 cores * more than 1000 nodes: 4 cores + one core per 1000 nodes beyond 1000, when not in full compliance * more than 1000 nodes: 6 cores + one core per 500 nodes beyond 1000, when in full compliance
Adding more cores makes the Web Interface faster, and especially the policy generation part. PostgreSQL and rsyslog both need more computing power when a lot of nodes are involved in full compliance, that’s why the requirement grows more quickly.
Disk
To manage more than 100 nodes, it is strongly recommended to use SSD or NAS/SAN with low latency, to avoid slowdown during policy generation and inventories management.
The PostgreSQL database will take up most of the disk space needed by Rudder. The storage necessary for the database can be estimated by counting around 500 to 900 kB per Directive per Node per Day of retention of node execution reports (default is 4 days), plus 150 kB per Directive per Node per Day of archiving (default is 0 days), plus 150 kB per Directive per Node per Day of compliance retention (default is 8 days) :
max_space = number of Directives * number of Nodes * ( retention duration in days * 900 kB + archive retention in days * 150 + compliance retention in days * 150 )
For example, a default installation with 500 nodes and an average of 50 Directives by node, should require between 76 GB and 114 GB of disk space for PostgreSQL.
Follow the reports Retention section to configure the retention duration.
|
Be careful to correctly size your /var partition. Compliance data are growing fast, and PostgreSQL doesn’t like at all to encounter a write error because the disk is full. It is also advised to set-up your monitoring to check for available space on that partition. Special attention should be given to:
Note: When using Syslog reporting, ticking "Log all reports received to `/var/log/rudder/reports/all.log`" under the Administration → Settings tab in the Rudder web interface will record all logs from nodes in a text file, on top from the SQL database. This uses a lot of disk space, and is disabled by default in Rudder 6.1. |
← Compatible OS Quick installation →