Webapp administration
The rudder-jetty
service, usually called the Rudder webapp, is part of the rudder-server
package
and runs on Rudder servers only. It provides the Web interface of Rudder, its HTTP API,
computes the policies to apply and handles reports and inventories from nodes
(but does not communicate directly with them, but only through relay
services, namely apache2/httpd
, rudder-relay
and rudder-cf-serverd
).
It is implemented in Scala, runs in a JVM and embeds a Jetty application server.
It has three main data stores:
-
A local Git repository (
/var/rudder/configuration-repository
) containing the policy definitions -
A PostgreSQL database storing policies and compliance data
-
A local LDAP database (the
rudder-slapd
service) storing node inventories
Configuration
Webapp base configuration is stored in /opt/rudder/etc/rudder-web.properties
, with default
values and comments explaining the settings. It uses a key-value structure following the
".properties" format.
This configuration can be edited directly or overridden (starting from 7.2) with files
in /opt/rudder/etc/rudder-web.properties.d
.
Only files with extension .properties
, .prop
and .config
will be taken into account.
The overriding is done by sorting files in lexicographical order so that values of properties
in the last file are used.
Example
The base default configuration contains:
rudder.auth.provider=file
To override this value can add an /opt/rudder/etc/rudder-web.properties.d/10-ldap-auth.properties
file containing:
rudder.auth.provider=ldap,file
Then this value would be used instead of the default.
But if you also have a /opt/rudder/etc/rudder-web.properties.d/60-custom-ldap.properties
file containing
rudder.auth.provider=ldap
Then it’s this value that will be used (as it has higher priority due to override file name ordering).
Data files
The webapp is loaded from /opt/rudder/share/webapp/rudder.war
.
It’s main data directories are:
-
/var/rudder/inventories
(on on simple relays): to forward inventories to upstream relay or root server. On root server, the webapp monitors this folder directly. -
/var/rudder/shared/
: policy files for the nodes, generated by the webapp -
/var/rudder/configuration-repository
: git repository containing the policy definitions (groups, directives, techniques, etc.)
HTTP
The webapp exposes its HTTP interface (Web+API) on http://localhost:8080/, and is served by an apache httpd reverse proxy configuration.
See the API documentation for more information about the API.
Logging
The webapp outputs its logs directly into /var/log/rudder/webapp
, and handles daily
log file rotation itself.
The files names have a /var/log/rudder/webapp/YEAR_MONTH_DAY.stderrout.log
format.
The log levels are configurable in /opt/rudder/etc/logback.xml
.
The logging configuration changes are detected and applied automatically and there is no need to reload or restart the service.
Performance
See the dedicated page for configuration advice to you webapp’s performance.
Monitoring
Status
You can use Rudder’s status HTTP API to check if the Webapp is running correctly:
# Locally on the server, directly calling the service HTTP interface
curl --header "X-API-Token: $(cat /var/rudder/run/api-token)" http://127.0.0.1:8080/rudder/api/latest/system/status
# Remotely with a dedicated API token, through reverse proxy
curl --header "X-API-Token: MY_TOKEN" https://rudder.example.com/rudder/api/latest/system/status
Gives:
{
"action": "getStatus",
"result": "success",
"data": {
"global": "OK"
}
}
See the API documentation for details.
Healthcheck
The health check API can also be used to monitor more possible problem (expired licenses, low disk space, etc.)
curl --header "X-API-Token: yourToken" "https://rudder.example.com/rudder/api/latest/system/healthcheck"
{
"result": "success",
"action": "getHealthcheckResult",
"data": [
{
"name": "RAM available",
"msg": "Only 2GB of RAM left",
"status": "Critical"
}
]
}
See the API documentation for details.
← Rudder security & hardening Relayd administration →