Chapter 6. Configuring logging
Most services in Red Hat Enterprise Linux log status messages, warnings, and errors. You can use the rsyslogd service to log these entries to local files or to a remote logging server.
6.1. Configuring a remote logging solution Copiar enlaceEnlace copiado en el portapapeles!
To ensure that logs from various machines in your environment are recorded centrally on a logging server, you can configure the Rsyslog application to record logs that fit specific criteria from the client system to the server.
6.1.1. The Rsyslog logging service Copiar enlaceEnlace copiado en el portapapeles!
The Rsyslog application, in combination with the systemd-journald service, provides local and remote logging support in Red Hat Enterprise Linux. The rsyslogd daemon continuously reads syslog messages received by the systemd-journald service from the Journal. rsyslogd then filters and processes these syslog events and records them to rsyslog log files or forwards them to other services according to its configuration.
The rsyslogd daemon also provides extended filtering, encryption protected relaying of messages, input and output modules, and support for transportation using the TCP and UDP protocols.
In /etc/rsyslog.conf, which is the main configuration file for rsyslog, you can specify the rules according to which rsyslogd handles the messages. Generally, you can classify messages by their source and topic (facility) and urgency (priority), and then assign an action that should be performed when a message fits these criteria.
In /etc/rsyslog.conf, you can also see a list of log files maintained by rsyslogd. Most log files are located in the /var/log/ directory. Some applications, such as httpd and samba, store their log files in a subdirectory within /var/log/.
6.1.2. Installing Rsyslog documentation Copiar enlaceEnlace copiado en el portapapeles!
The Rsyslog application has extensive online documentation that is available at https://www.rsyslog.com/doc/, but you can also install the rsyslog-doc documentation package locally.
Prerequisites
-
You have activated the
AppStreamrepository on your system. -
You are authorized to install new packages using
sudo.
Procedure
Install the
rsyslog-docpackage:yum install rsyslog-doc
# yum install rsyslog-docCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Open the
/usr/share/doc/rsyslog/html/index.htmlfile in a browser of your choice, for example:firefox /usr/share/doc/rsyslog/html/index.html &
$ firefox /usr/share/doc/rsyslog/html/index.html &Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.1.3. Configuring a server for remote logging over TCP Copiar enlaceEnlace copiado en el portapapeles!
The Rsyslog application enables you to both run a logging server and configure individual systems to send their log files to the logging server. To use remote logging through TCP, configure both the server and the client. The server collects and analyzes the logs sent by one or more client systems.
With the Rsyslog application, you can maintain a centralized logging system where log messages are forwarded to a server over the network. To avoid message loss when the server is not available, you can configure an action queue for the forwarding action. This way, messages that failed to be sent are stored locally until the server is reachable again. Note that such queues cannot be configured for connections using the UDP protocol.
The omfwd plug-in provides forwarding over UDP or TCP. The default protocol is UDP. Because the plug-in is built in, it does not have to be loaded.
By default, rsyslog uses TCP on port 514.
Prerequisites
- Rsyslog is installed on the server system.
-
You are logged in as
rooton the server. -
The
policycoreutils-python-utilspackage is installed for the optional step using thesemanagecommand. -
The
firewalldservice is running.
Procedure
Optional: To use a different port for
rsyslogtraffic, add thesyslogd_port_tSELinux type to port. For example, enable port30514:semanage port -a -t syslogd_port_t -p tcp 30514
# semanage port -a -t syslogd_port_t -p tcp 30514Copy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: To use a different port for
rsyslogtraffic, configurefirewalldto allow incomingrsyslogtraffic on that port. For example, allow TCP traffic on port30514:firewall-cmd --zone=<zone-name> --permanent --add-port=30514/tcp firewall-cmd --reload
# firewall-cmd --zone=<zone-name> --permanent --add-port=30514/tcp success # firewall-cmd --reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a new file in the
/etc/rsyslog.d/directory named, for example,remotelog.conf, and insert the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Save the changes to the
/etc/rsyslog.d/remotelog.conffile. Test the syntax of the
/etc/rsyslog.conffile:rsyslogd -N 1
# rsyslogd -N 1 rsyslogd: version 8.1911.0-2.el8, config validation run... rsyslogd: End of config validation run. Bye.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Make sure the
rsyslogservice is running and enabled on the logging server:systemctl status rsyslog
# systemctl status rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow Restart the
rsyslogservice.systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: If
rsyslogis not enabled, ensure thersyslogservice starts automatically after reboot:systemctl enable rsyslog
# systemctl enable rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Your log server is now configured to receive and store log files from the other systems in your environment.
6.1.4. Configuring remote logging to a server over TCP Copiar enlaceEnlace copiado en el portapapeles!
You can configure a system for forwarding log messages to a server over the TCP protocol. The omfwd plug-in provides forwarding over UDP or TCP. The default protocol is UDP. Because the plug-in is built in, you do not have to load it.
Prerequisites
-
The
rsyslogpackage is installed on the client systems that should report to the server. - You have configured the server for remote logging.
- The specified port is permitted in SELinux and open in firewall.
-
The system contains the
policycoreutils-python-utilspackage, which provides thesemanagecommand for adding a non-standard port to the SELinux configuration.
Procedure
Create a new file in the
/etc/rsyslog.d/directory named, for example,10-remotelog.conf, and insert the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where:
-
The
queue.type="linkedlist"setting enables a LinkedList in-memory queue, -
The
queue.filenamesetting defines a disk storage. The backup files are created with theexample_fwdprefix in the working directory specified by the preceding globalworkDirectorydirective. -
The
action.resumeRetryCount -1setting preventsrsyslogfrom dropping messages when retrying to connect if server is not responding, -
The
queue.saveOnShutdown="on"setting saves in-memory data ifrsyslogshuts down. The last line forwards all received messages to the logging server. Port specification is optional.
With this configuration,
rsyslogsends messages to the server but keeps messages in memory if the remote server is not reachable. A file on disk is created only ifrsyslogruns out of the configured memory queue space or needs to shut down, which benefits the system performance.
NoteRsyslog processes configuration files
/etc/rsyslog.d/in the lexical order.-
The
Restart the
rsyslogservice.systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
To verify that the client system sends messages to the server, follow these steps:
On the client system, send a test message:
logger test
# logger testCopy to Clipboard Copied! Toggle word wrap Toggle overflow On the server system, view the
/var/log/messageslog, for example:cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: test
# cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: testCopy to Clipboard Copied! Toggle word wrap Toggle overflow Where hostname is the host name of the client system. Note that the log contains the user name of the user that entered the
loggercommand, in this caseroot.
6.1.5. Configuring TLS-encrypted remote logging Copiar enlaceEnlace copiado en el portapapeles!
By default, Rsyslog sends remote-logging communication in the plain text format. If your scenario requires to secure this communication channel, you can encrypt it using TLS.
To use encrypted transport through TLS, configure both the server and the client. The server collects and analyzes the logs sent by one or more client systems.
You can use either the ossl network stream driver (OpenSSL) or the gtls stream driver (GnuTLS).
If you have a separate system with higher security, for example, a system that is not connected to any network or has stricter authorizations, use the separate system as the certifying authority (CA).
You can customize your connection settings with stream drivers on the server side on the global, module, and input levels, and on the client side on the global and action levels. The more specific configuration overrides the more general configuration. This means, for example, that you can use ossl in global settings for most connections and gtls on the input and action settings only for specific connections.
Prerequisites
-
You have
rootaccess to both the client and server systems. The following packages are installed on the server and the client systems:
-
The
rsyslogpackage. -
For the
osslnetwork stream driver, thersyslog-opensslpackage. -
For the
gtlsnetwork stream driver, thersyslog-gnutlspackage. -
For generating certificates by using the
certtoolcommand, thegnutls-utilspackage.
-
The
On your logging server, the following certificates are in the
/etc/pki/ca-trust/source/anchors/directory and your system configuration is updated by using theupdate-ca-trustcommand:-
ca-cert.pem- a CA certificate that can verify keys and certificates on logging servers and clients. -
server-cert.pem- a public key of the logging server. -
server-key.pem- a private key of the logging server.
-
On your logging clients, the following certificates are in the
/etc/pki/ca-trust/source/anchors/directory and your system configuration is updated by usingupdate-ca-trust:-
ca-cert.pem- a CA certificate that can verify keys and certificates on logging servers and clients. -
client-cert.pem- a public key of a client. -
client-key.pem- a private key of a client.
-
Procedure
Configure the server for receiving encrypted logs from your client systems:
-
Create a new file in the
/etc/rsyslog.d/directory named, for example,securelogser.conf. To encrypt the communication, the configuration file must contain paths to certificate files on your server, a selected authentication method, and a stream driver that supports TLS encryption. Add the following lines to the
/etc/rsyslog.d/securelogser.conffile:Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteIf you prefer the GnuTLS driver, use the
StreamDriver.Name="gtls"configuration option. See the documentation installed with thersyslog-docpackage for more information about less strict authentication modes thanx509/name.-
Save the changes to the
/etc/rsyslog.d/securelogser.conffile. Verify the syntax of the
/etc/rsyslog.conffile and any files in the/etc/rsyslog.d/directory:rsyslogd -N 1
# rsyslogd -N 1 rsyslogd: version 8.1911.0-2.el8, config validation run (level 1)... rsyslogd: End of config validation run. Bye.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Make sure the
rsyslogservice is running and enabled on the logging server:systemctl status rsyslog
# systemctl status rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow Restart the
rsyslogservice:systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: If Rsyslog is not enabled, ensure the
rsyslogservice starts automatically after reboot:systemctl enable rsyslog
# systemctl enable rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Create a new file in the
Configure clients for sending encrypted logs to the server:
-
On a client system, create a new file in the
/etc/rsyslog.d/directory named, for example,securelogcli.conf. Add the following lines to the
/etc/rsyslog.d/securelogcli.conffile:Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteIf you prefer the GnuTLS driver, use the
StreamDriver.Name="gtls"configuration option.-
Save the changes to the
/etc/rsyslog.d/securelogcli.conffile. Verify the syntax of the
/etc/rsyslog.conffile and other files in the/etc/rsyslog.d/directory:rsyslogd -N 1
# rsyslogd -N 1 rsyslogd: version 8.1911.0-2.el8, config validation run (level 1)... rsyslogd: End of config validation run. Bye.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Make sure the
rsyslogservice is running and enabled on the logging server:systemctl status rsyslog
# systemctl status rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow Restart the
rsyslogservice:systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: If Rsyslog is not enabled, ensure the
rsyslogservice starts automatically after reboot:systemctl enable rsyslog
# systemctl enable rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
On a client system, create a new file in the
Verification
To verify that the client system sends messages to the server, follow these steps:
On the client system, send a test message:
logger test
# logger testCopy to Clipboard Copied! Toggle word wrap Toggle overflow On the server system, view the
/var/log/messageslog, for example:cat /var/log/remote/msg/<hostname>/root.log Feb 25 03:53:17 <hostname> root[6064]: test
# cat /var/log/remote/msg/<hostname>/root.log Feb 25 03:53:17 <hostname> root[6064]: testCopy to Clipboard Copied! Toggle word wrap Toggle overflow Where
<hostname>is the hostname of the client system. Note that the log contains the user name of the user that entered the logger command, in this caseroot.
6.1.6. Configuring a server for receiving remote logging information over UDP Copiar enlaceEnlace copiado en el portapapeles!
The Rsyslog application enables you to configure a system to receive logging information from remote systems. To use remote logging through UDP, configure both the server and the client. The receiving server collects and analyzes the logs sent by one or more client systems. By default, rsyslog uses UDP on port 514 to receive log information from remote systems.
Follow this procedure to configure a server for collecting and analyzing logs sent by one or more client systems over the UDP protocol.
Prerequisites
- Rsyslog is installed on the server system.
-
You are logged in as
rooton the server. -
The
policycoreutils-python-utilspackage is installed for the optional step using thesemanagecommand. -
The
firewalldservice is running.
Procedure
Optional: To use a different port for
rsyslogtraffic than the default port514:Add the
syslogd_port_tSELinux type to the SELinux policy configuration, replacingportnowith the port number you wantrsyslogto use:semanage port -a -t syslogd_port_t -p udp portno
# semanage port -a -t syslogd_port_t -p udp portnoCopy to Clipboard Copied! Toggle word wrap Toggle overflow Configure
firewalldto allow incomingrsyslogtraffic, replacingportnowith the port number andzonewith the zone you wantrsyslogto use:firewall-cmd --zone=zone --permanent --add-port=portno/udp firewall-cmd --reload
# firewall-cmd --zone=zone --permanent --add-port=portno/udp success # firewall-cmd --reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow Reload the firewall rules:
firewall-cmd --reload
# firewall-cmd --reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Create a new
.conffile in the/etc/rsyslog.d/directory, for example,remotelogserv.conf, and insert the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where
514is the port numberrsysloguses by default. You can specify a different port instead.Verify the syntax of the
/etc/rsyslog.conffile and all.conffiles in the/etc/rsyslog.d/directory:rsyslogd -N 1
# rsyslogd -N 1 rsyslogd: version 8.1911.0-2.el8, config validation run...Copy to Clipboard Copied! Toggle word wrap Toggle overflow Restart the
rsyslogservice.systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: If
rsyslogis not enabled, ensure thersyslogservice starts automatically after reboot:systemctl enable rsyslog
# systemctl enable rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.1.7. Configuring remote logging to a server over UDP Copiar enlaceEnlace copiado en el portapapeles!
You can configure a system for forwarding log messages to a server over the UDP protocol. The omfwd plug-in provides forwarding over UDP or TCP. The default protocol is UDP. Because the plug-in is built in, you do not have to load it.
Prerequisites
-
The
rsyslogpackage is installed on the client systems that should report to the server. - You have configured the server for remote logging as described in Configuring a server for receiving remote logging information over UDP.
Procedure
Create a new
.conffile in the/etc/rsyslog.d/directory, for example,10-remotelogcli.conf, and insert the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where:
-
The
queue.type="linkedlist"setting enables a LinkedList in-memory queue. -
The
queue.filenamesetting defines a disk storage. The backup files are created with theexample_fwdprefix in the working directory specified by the preceding globalworkDirectorydirective. -
The
action.resumeRetryCount -1setting preventsrsyslogfrom dropping messages when retrying to connect if the server is not responding. -
The
enabled queue.saveOnShutdown="on"setting saves in-memory data ifrsyslogshuts down. -
The
portnovalue is the port number you wantrsyslogto use. The default value is514. The last line forwards all received messages to the logging server, port specification is optional.
With this configuration,
rsyslogsends messages to the server but keeps messages in memory if the remote server is not reachable. A file on disk is created only ifrsyslogruns out of the configured memory queue space or needs to shut down, which benefits the system performance.
NoteRsyslog processes configuration files
/etc/rsyslog.d/in the lexical order.-
The
Restart the
rsyslogservice.systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: If
rsyslogis not enabled, ensure thersyslogservice starts automatically after reboot:systemctl enable rsyslog
# systemctl enable rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
To verify that the client system sends messages to the server, follow these steps:
On the client system, send a test message:
logger test
# logger testCopy to Clipboard Copied! Toggle word wrap Toggle overflow On the server system, view the
/var/log/remote/msg/hostname/root.loglog, for example:cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: test
# cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: testCopy to Clipboard Copied! Toggle word wrap Toggle overflow Where
hostnameis the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this caseroot.
6.1.8. Load balancing helper in Rsyslog Copiar enlaceEnlace copiado en el portapapeles!
When used in a cluster, you can improve Rsyslog load balancing by modifying the RebindInterval setting.
RebindInterval specifies an interval at which the current connection is broken and is re-established. This setting applies to TCP, UDP, and RELP traffic. The load balancers perceive it as a new connection and forward the messages to another physical target system.
RebindInterval is helpful in scenarios when a target system has changed its IP address. The Rsyslog application caches the IP address when the connection is established, therefore, the messages are sent to the same server. If the IP address changes, the UDP packets are lost until the Rsyslog service restarts. Re-establishing the connection ensures the IP is resolved by DNS again.
Example usage of RebindInterval for TCP, UDP, and RELP traffic
action(type="omfwd" protocol="tcp" RebindInterval="250" target="example.com" port="514" …) action(type="omfwd" protocol="udp" RebindInterval="250" target="example.com" port="514" …) action(type="omrelp" RebindInterval="250" target="example.com" port="6514" …)
action(type="omfwd" protocol="tcp" RebindInterval="250" target="example.com" port="514" …)
action(type="omfwd" protocol="udp" RebindInterval="250" target="example.com" port="514" …)
action(type="omrelp" RebindInterval="250" target="example.com" port="6514" …)
6.1.9. Configuring reliable remote logging Copiar enlaceEnlace copiado en el portapapeles!
With the Reliable Event Logging Protocol (RELP), you can send and receive syslog messages over TCP with a much reduced risk of message loss. RELP provides reliable delivery of event messages, which makes it useful in environments where message loss is not acceptable. To use RELP, configure the imrelp input module, which runs on the server and receives the logs, and the omrelp output module, which runs on the client and sends logs to the logging server.
Prerequisites
-
You have installed the
rsyslog,librelp, andrsyslog-relppackages on the server and the client systems. - The specified port is permitted in SELinux and open in the firewall.
Procedure
Configure the client system for reliable remote logging:
On the client system, create a new
.conffile in the/etc/rsyslog.d/directory named, for example,relpclient.conf, and insert the following content:module(load="omrelp") *.* action(type="omrelp" target="_target_IP_" port="_target_port_")
module(load="omrelp") *.* action(type="omrelp" target="_target_IP_" port="_target_port_")Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where:
-
target_IPis the IP address of the logging server. -
target_portis the port of the logging server.
-
-
Save the changes to the
/etc/rsyslog.d/relpclient.conffile. Restart the
rsyslogservice.systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: If
rsyslogis not enabled, ensure thersyslogservice starts automatically after reboot:systemctl enable rsyslog
# systemctl enable rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Configure the server system for reliable remote logging:
On the server system, create a new
.conffile in the/etc/rsyslog.d/directory named, for example,relpserv.conf, and insert the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where:
-
log_pathspecifies the path for storing messages. -
target_portis the port of the logging server. Use the same value as in the client configuration file.
-
-
Save the changes to the
/etc/rsyslog.d/relpserv.conffile. Restart the
rsyslogservice.systemctl restart rsyslog
# systemctl restart rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: If
rsyslogis not enabled, ensure thersyslogservice starts automatically after reboot:systemctl enable rsyslog
# systemctl enable rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
To verify that the client system sends messages to the server, follow these steps:
On the client system, send a test message:
logger test
# logger testCopy to Clipboard Copied! Toggle word wrap Toggle overflow On the server system, view the log at the specified
log_path, for example:cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: test
# cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: testCopy to Clipboard Copied! Toggle word wrap Toggle overflow Where
hostnameis the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this caseroot.
6.1.10. Supported Rsyslog modules Copiar enlaceEnlace copiado en el portapapeles!
To expand the functionality of the Rsyslog application, you can use specific modules. Modules provide additional inputs (Input Modules), outputs (Output Modules), and other functionalities. A module can also provide additional configuration directives that become available after you load the module.
You can list the input and output modules installed on your system by entering the following command:
ls /usr/lib64/rsyslog/{i,o}m*
# ls /usr/lib64/rsyslog/{i,o}m*
You can view the list of all available rsyslog modules in the /usr/share/doc/rsyslog/html/configuration/modules/idx_output.html file after you install the rsyslog-doc package.
6.1.11. Configuring the netconsole service to log kernel messages to a remote host Copiar enlaceEnlace copiado en el portapapeles!
When logging to disk or using a serial console is not possible, you can use the netconsole kernel module and the same-named service to log kernel messages over a network to a remote rsyslog service.
Prerequisites
-
A system log service, such as
rsyslogis installed on the remote host. - The remote system log service is configured to receive incoming log entries from this host.
Procedure
Install the
netconsole-servicepackage:yum install netconsole-service
# yum install netconsole-serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the
/etc/sysconfig/netconsolefile and set theSYSLOGADDRparameter to the IP address of the remote host:SYSLOGADDR=192.0.2.1
# SYSLOGADDR=192.0.2.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enable and start the
netconsoleservice:systemctl enable --now netconsole
# systemctl enable --now netconsoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
-
Display the
/var/log/messagesfile on the remote system log server.
6.2. Using the logging system role Copiar enlaceEnlace copiado en el portapapeles!
As a system administrator, you can use the logging system role to configure a Red Hat Enterprise Linux host as a logging server to collect logs from many client systems.
6.2.1. Filtering local log messages by using the logging RHEL system role Copiar enlaceEnlace copiado en el portapapeles!
You can use the property-based filter of the logging RHEL system role to filter your local log messages based on various conditions. As a result, you can achieve for example:
- Log clarity: In a high-traffic environment, logs can grow rapidly. The focus on specific messages, like errors, can help to identify problems faster.
- Optimized system performance: Excessive amount of logs is usually connected with system performance degradation. Selective logging for only the important events can prevent resource depletion, which enables your systems to run more efficiently.
- Enhanced security: Efficient filtering through security messages, like system errors and failed logins, helps to capture only the relevant logs. This is important for detecting breaches and meeting compliance standards.
Prerequisites
- You have prepared the control node and the managed nodes.
- You are logged in to the control node as a user who can run playbooks on the managed nodes.
-
The account you use to connect to the managed nodes has
sudopermissions on them.
Procedure
Create a playbook file, for example,
~/playbook.yml, with the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The settings specified in the example playbook include the following:
logging_inputs-
Defines a list of logging input dictionaries. The
type: basicsoption covers inputs fromsystemdjournal or Unix socket. logging_outputs-
Defines a list of logging output dictionaries. The
type: filesoption supports storing logs in the local files, usually in the/var/log/directory. Theproperty: msg;property: contains; andproperty_value: erroroptions specify that all logs that contain theerrorstring are stored in the/var/log/errors.logfile. Theproperty: msg;property: !contains; andproperty_value: erroroptions specify that all other logs are put in the/var/log/others.logfile. You can replace theerrorvalue with the string by which you want to filter. logging_flows-
Defines a list of logging flow dictionaries to specify relationships between
logging_inputsandlogging_outputs. Theinputs: [files_input]option specifies a list of inputs, from which processing of logs starts. Theoutputs: [files_output0, files_output1]option specifies a list of outputs, to which the logs are sent.
For details about all variables used in the playbook, see the
/usr/share/ansible/roles/rhel-system-roles.logging/README.mdfile on the control node.Validate the playbook syntax:
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
On the managed node, test the syntax of the
/etc/rsyslog.conffile:rsyslogd -N 1
# rsyslogd -N 1 rsyslogd: version 8.1911.0-6.el8, config validation run... rsyslogd: End of config validation run. Bye.Copy to Clipboard Copied! Toggle word wrap Toggle overflow On the managed node, verify that the system sends messages that contain the
errorstring to the log:Send a test message:
logger error
# logger errorCopy to Clipboard Copied! Toggle word wrap Toggle overflow View the
/var/log/errors.loglog, for example:cat /var/log/errors.log Aug 5 13:48:31 hostname root[6778]: error
# cat /var/log/errors.log Aug 5 13:48:31 hostname root[6778]: errorCopy to Clipboard Copied! Toggle word wrap Toggle overflow Where
hostnameis the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this caseroot.
6.2.2. Applying a remote logging solution by using the logging RHEL system role Copiar enlaceEnlace copiado en el portapapeles!
You can use the logging RHEL system role to configure a remote logging solution, where one or more clients take logs from the systemd-journal service and forward them to a remote server. The server receives remote input from the remote_rsyslog and remote_files configurations, and outputs the logs to local files in directories named by remote host names.
As a result, you can cover use cases where you need for example:
- Centralized log management: Collecting, accessing, and managing log messages of multiple machines from a single storage point simplifies day-to-day monitoring and troubleshooting tasks. Also, this use case reduces the need to log into individual machines to check the log messages.
- Enhanced security: Storing log messages in one central place increases chances they are in a secure and tamper-proof environment. Such an environment makes it easier to detect and respond to security incidents more effectively and to meet audit requirements.
- Improved efficiency in log analysis: Correlating log messages from multiple systems is important for fast troubleshooting of complex problems that span multiple machines or services. That way you can quickly analyze and cross-reference events from different sources.
Prerequisites
- You have prepared the control node and the managed nodes.
- You are logged in to the control node as a user who can run playbooks on the managed nodes.
-
The account you use to connect to the managed nodes has
sudopermissions on them. - Define the ports in the SELinux policy of the server or client system and open the firewall for those ports. The default SELinux policy includes ports 601, 514, 6514, 10514, and 20514. To use a different port, see modify the SELinux policy on the client and server systems.
Procedure
Create a playbook file, for example,
~/playbook.yml, with the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The settings specified in the first play of the example playbook include the following:
logging_inputs-
Defines a list of logging input dictionaries. The
type: remoteoption covers remote inputs from the other logging system over the network. Theudp_ports: [ 601 ]option defines a list of UDP port numbers to monitor. Thetcp_ports: [ 601 ]option defines a list of TCP port numbers to monitor. If bothudp_portsandtcp_portsis set,udp_portsis used andtcp_portsis dropped. logging_outputs-
Defines a list of logging output dictionaries. The
type: remote_filesoption makes output store logs to the local files per remote host and program name originated the logs. logging_flows-
Defines a list of logging flow dictionaries to specify relationships between
logging_inputsandlogging_outputs. Theinputs: [remote_udp_input, remote_tcp_input]option specifies a list of inputs, from which processing of logs starts. Theoutputs: [remote_files_output]option specifies a list of outputs, to which the logs are sent.
The settings specified in the second play of the example playbook include the following:
logging_inputs-
Defines a list of logging input dictionaries. The
type: basicsoption covers inputs fromsystemdjournal or Unix socket. logging_outputs-
Defines a list of logging output dictionaries. The
type: forwardsoption supports sending logs to the remote logging server over the network. Theseverity: infooption refers to log messages of the informative importance. Thefacility: mailoption refers to the type of system program that is generating the log message. Thetarget: <host1.example.com>option specifies the hostname of the remote logging server. Theudp_port: 601/tcp_port: 601options define the UDP/TCP ports on which the remote logging server listens. logging_flows-
Defines a list of logging flow dictionaries to specify relationships between
logging_inputsandlogging_outputs. Theinputs: [basic_input]option specifies a list of inputs, from which processing of logs starts. Theoutputs: [forward_output0, forward_output1]option specifies a list of outputs, to which the logs are sent.
For details about all variables used in the playbook, see the
/usr/share/ansible/roles/rhel-system-roles.logging/README.mdfile on the control node.Validate the playbook syntax:
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
On both the client and the server system, test the syntax of the
/etc/rsyslog.conffile:rsyslogd -N 1
# rsyslogd -N 1 rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf rsyslogd: End of config validation run. Bye.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that the client system sends messages to the server:
On the client system, send a test message:
logger test
# logger testCopy to Clipboard Copied! Toggle word wrap Toggle overflow On the server system, view the
/var/log/<host2.example.com>/messageslog, for example:cat /var/log/<host2.example.com>/messages Aug 5 13:48:31 <host2.example.com> root[6778]: test
# cat /var/log/<host2.example.com>/messages Aug 5 13:48:31 <host2.example.com> root[6778]: testCopy to Clipboard Copied! Toggle word wrap Toggle overflow Where
<host2.example.com>is the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this caseroot.
6.2.3. Using the logging RHEL system role with TLS Copiar enlaceEnlace copiado en el portapapeles!
Transport Layer Security (TLS) is a cryptographic protocol designed to allow secure communication over the computer network.
You can use the logging RHEL system role to configure a secure transfer of log messages, where one or more clients take logs from the systemd-journal service and transfer them to a remote server while using TLS.
Typically, TLS for transferring logs in a remote logging solution is used when sending sensitive data over less trusted or public networks, such as the Internet. Also, by using certificates in TLS you can ensure that the client is forwarding logs to the correct and trusted server. This prevents attacks like "man-in-the-middle".
6.2.3.1. Configuring client logging with TLS Copiar enlaceEnlace copiado en el portapapeles!
You can use the logging RHEL system role to configure logging on RHEL clients and transfer logs to a remote logging system using TLS encryption.
This procedure creates a private key and a certificate. Next, it configures TLS on all hosts in the clients group in the Ansible inventory. The TLS protocol encrypts the message transmission for secure transfer of logs over the network.
You do not have to call the certificate RHEL system role in the playbook to create the certificate. The logging RHEL system role calls it automatically when the logging_certificates variable is set.
In order for the CA to be able to sign the created certificate, the managed nodes must be enrolled in an IdM domain.
Prerequisites
- You have prepared the control node and the managed nodes.
- You are logged in to the control node as a user who can run playbooks on the managed nodes.
-
The account you use to connect to the managed nodes has
sudopermissions on them. - The managed nodes are enrolled in an IdM domain.
Procedure
Create a playbook file, for example,
~/playbook.yml, with the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The settings specified in the example playbook include the following:
logging_certificates-
The value of this parameter is passed on to
certificate_requestsin thecertificateRHEL system role and used to create a private key and certificate. logging_pki_filesUsing this parameter, you can configure the paths and other settings that logging uses to find the CA, certificate, and key files used for TLS, specified with one or more of the following sub-parameters:
ca_cert,ca_cert_src,cert,cert_src,private_key,private_key_src, andtls.NoteIf you are using
logging_certificatesto create the files on the managed node, do not useca_cert_src,cert_src, andprivate_key_src, which are used to copy files not created bylogging_certificates.ca_cert-
Represents the path to the CA certificate file on the managed node. Default path is
/etc/pki/tls/certs/ca.pemand the file name is set by the user. cert-
Represents the path to the certificate file on the managed node. Default path is
/etc/pki/tls/certs/server-cert.pemand the file name is set by the user. private_key-
Represents the path to the private key file on the managed node. Default path is
/etc/pki/tls/private/server-key.pemand the file name is set by the user. ca_cert_src-
Represents the path to the CA certificate file on the control node which is copied to the target host to the location specified by
ca_cert. Do not use this if usinglogging_certificates. cert_src-
Represents the path to a certificate file on the control node which is copied to the target host to the location specified by
cert. Do not use this if usinglogging_certificates. private_key_src-
Represents the path to a private key file on the control node which is copied to the target host to the location specified by
private_key. Do not use this if usinglogging_certificates. tls-
Setting this parameter to
trueensures secure transfer of logs over the network. If you do not want a secure wrapper, you can settls: false.
For details about all variables used in the playbook, see the
/usr/share/ansible/roles/rhel-system-roles.logging/README.mdfile on the control node.Validate the playbook syntax:
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Additional resources
-
/usr/share/ansible/roles/rhel-system-roles.logging/README.mdfile -
/usr/share/doc/rhel-system-roles/logging/directory -
/usr/share/ansible/roles/rhel-system-roles.certificate/README.mdfile -
/usr/share/doc/rhel-system-roles/certificate/directory - Requesting certificates using RHEL system roles.
-
rsyslog.conf(5)andsyslog(3)manual pages
6.2.3.2. Configuring server logging with TLS Copiar enlaceEnlace copiado en el portapapeles!
You can use the logging RHEL system role to configure logging on RHEL servers and set them to receive logs from a remote logging system using TLS encryption.
This procedure creates a private key and a certificate. Next, it configures TLS on all hosts in the server group in the Ansible inventory.
You do not have to call the certificate RHEL system role in the playbook to create the certificate. The logging RHEL system role calls it automatically.
In order for the CA to be able to sign the created certificate, the managed nodes must be enrolled in an IdM domain.
Prerequisites
- You have prepared the control node and the managed nodes.
- You are logged in to the control node as a user who can run playbooks on the managed nodes.
-
The account you use to connect to the managed nodes has
sudopermissions on them. - The managed nodes are enrolled in an IdM domain.
Procedure
Create a playbook file, for example,
~/playbook.yml, with the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The settings specified in the example playbook include the following:
logging_certificates-
The value of this parameter is passed on to
certificate_requestsin thecertificateRHEL system role and used to create a private key and certificate. logging_pki_filesUsing this parameter, you can configure the paths and other settings that logging uses to find the CA, certificate, and key files used for TLS, specified with one or more of the following sub-parameters:
ca_cert,ca_cert_src,cert,cert_src,private_key,private_key_src, andtls.NoteIf you are using
logging_certificatesto create the files on the managed node, do not useca_cert_src,cert_src, andprivate_key_src, which are used to copy files not created bylogging_certificates.ca_cert-
Represents the path to the CA certificate file on the managed node. Default path is
/etc/pki/tls/certs/ca.pemand the file name is set by the user. cert-
Represents the path to the certificate file on the managed node. Default path is
/etc/pki/tls/certs/server-cert.pemand the file name is set by the user. private_key-
Represents the path to the private key file on the managed node. Default path is
/etc/pki/tls/private/server-key.pemand the file name is set by the user. ca_cert_src-
Represents the path to the CA certificate file on the control node which is copied to the target host to the location specified by
ca_cert. Do not use this if usinglogging_certificates. cert_src-
Represents the path to a certificate file on the control node which is copied to the target host to the location specified by
cert. Do not use this if usinglogging_certificates. private_key_src-
Represents the path to a private key file on the control node which is copied to the target host to the location specified by
private_key. Do not use this if usinglogging_certificates. tls-
Setting this parameter to
trueensures secure transfer of logs over the network. If you do not want a secure wrapper, you can settls: false.
For details about all variables used in the playbook, see the
/usr/share/ansible/roles/rhel-system-roles.logging/README.mdfile on the control node.Validate the playbook syntax:
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.4. Using the logging RHEL system roles with RELP Copiar enlaceEnlace copiado en el portapapeles!
Reliable Event Logging Protocol (RELP) is a networking protocol for data and message logging over the TCP network. It ensures reliable delivery of event messages and you can use it in environments that do not tolerate any message loss.
The RELP sender transfers log entries in the form of commands and the receiver acknowledges them once they are processed. To ensure consistency, RELP stores the transaction number to each transferred command for any kind of message recovery.
You can consider a remote logging system in between the RELP Client and RELP Server. The RELP Client transfers the logs to the remote logging system and the RELP Server receives all the logs sent by the remote logging system. To achieve that use case, you can use the logging RHEL system role to configure the logging system to reliably send and receive log entries.
6.2.4.1. Configuring client logging with RELP Copiar enlaceEnlace copiado en el portapapeles!
You can use the logging RHEL system role to configure a transfer of log messages stored locally to the remote logging system with RELP.
This procedure configures RELP on all hosts in the clients group in the Ansible inventory. The RELP configuration uses Transport Layer Security (TLS) to encrypt the message transmission for secure transfer of logs over the network.
Prerequisites
- You have prepared the control node and the managed nodes.
- You are logged in to the control node as a user who can run playbooks on the managed nodes.
-
The account you use to connect to the managed nodes has
sudopermissions on them.
Procedure
Create a playbook file, for example,
~/playbook.yml, with the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The settings specified in the example playbook include the following:
target- This is a required parameter that specifies the host name where the remote logging system is running.
port- Port number the remote logging system is listening.
tlsEnsures secure transfer of logs over the network. If you do not want a secure wrapper you can set the
tlsvariable tofalse. By defaulttlsparameter is set to true while working with RELP and requires key/certificates and triplets {ca_cert,cert,private_key} and/or {ca_cert_src,cert_src,private_key_src}.-
If the {
ca_cert_src,cert_src,private_key_src} triplet is set, the default locations/etc/pki/tls/certsand/etc/pki/tls/privateare used as the destination on the managed node to transfer files from control node. In this case, the file names are identical to the original ones in the triplet -
If the {
ca_cert,cert,private_key} triplet is set, files are expected to be on the default path before the logging configuration. - If both triplets are set, files are transferred from local path from control node to specific path of the managed node.
-
If the {
ca_cert-
Represents the path to CA certificate. Default path is
/etc/pki/tls/certs/ca.pemand the file name is set by the user. cert-
Represents the path to certificate. Default path is
/etc/pki/tls/certs/server-cert.pemand the file name is set by the user. private_key-
Represents the path to private key. Default path is
/etc/pki/tls/private/server-key.pemand the file name is set by the user. ca_cert_src-
Represents local CA certificate file path which is copied to the managed node. If
ca_certis specified, it is copied to the location. cert_src-
Represents the local certificate file path which is copied to the managed node. If
certis specified, it is copied to the location. private_key_src-
Represents the local key file path which is copied to the managed node. If
private_keyis specified, it is copied to the location. pki_authmode-
Accepts the authentication mode as
nameorfingerprint. permitted_servers- List of servers that will be allowed by the logging client to connect and send logs over TLS.
inputs- List of logging input dictionary.
outputs- List of logging output dictionary.
For details about all variables used in the playbook, see the
/usr/share/ansible/roles/rhel-system-roles.logging/README.mdfile on the control node.Validate the playbook syntax:
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.4.2. Configuring server logging with RELP Copiar enlaceEnlace copiado en el portapapeles!
You can use the logging RHEL system role to configure a server for receiving log messages from the remote logging system with RELP.
This procedure configures RELP on all hosts in the server group in the Ansible inventory. The RELP configuration uses TLS to encrypt the message transmission for secure transfer of logs over the network.
Prerequisites
- You have prepared the control node and the managed nodes.
- You are logged in to the control node as a user who can run playbooks on the managed nodes.
-
The account you use to connect to the managed nodes has
sudopermissions on them.
Procedure
Create a playbook file, for example,
~/playbook.yml, with the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The settings specified in the example playbook include the following:
port- Port number the remote logging system is listening.
tlsEnsures secure transfer of logs over the network. If you do not want a secure wrapper you can set the
tlsvariable tofalse. By defaulttlsparameter is set to true while working with RELP and requires key/certificates and triplets {ca_cert,cert,private_key} and/or {ca_cert_src,cert_src,private_key_src}.-
If the {
ca_cert_src,cert_src,private_key_src} triplet is set, the default locations/etc/pki/tls/certsand/etc/pki/tls/privateare used as the destination on the managed node to transfer files from control node. In this case, the file names are identical to the original ones in the triplet -
If the {
ca_cert,cert,private_key} triplet is set, files are expected to be on the default path before the logging configuration. - If both triplets are set, files are transferred from local path from control node to specific path of the managed node.
-
If the {
ca_cert-
Represents the path to CA certificate. Default path is
/etc/pki/tls/certs/ca.pemand the file name is set by the user. cert-
Represents the path to the certificate. Default path is
/etc/pki/tls/certs/server-cert.pemand the file name is set by the user. private_key-
Represents the path to private key. Default path is
/etc/pki/tls/private/server-key.pemand the file name is set by the user. ca_cert_src-
Represents local CA certificate file path which is copied to the managed node. If
ca_certis specified, it is copied to the location. cert_src-
Represents the local certificate file path which is copied to the managed node. If
certis specified, it is copied to the location. private_key_src-
Represents the local key file path which is copied to the managed node. If
private_keyis specified, it is copied to the location. pki_authmode-
Accepts the authentication mode as
nameorfingerprint. permitted_clients- List of clients that will be allowed by the logging server to connect and send logs over TLS.
inputs- List of logging input dictionary.
outputs- List of logging output dictionary.
For details about all variables used in the playbook, see the
/usr/share/ansible/roles/rhel-system-roles.logging/README.mdfile on the control node.Validate the playbook syntax:
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow