Search Results for: error 51

In this recipe, we forward messages from one system to another one. Typical use cases are:

• the local system does not store any messages (e.g. has not sufficient space to do so)
• there is a (e.g. legal) requirement to consolidate all logs on a single system
• the server may run some advanced alerting rules, and needs to have a full picture or network activity to work well
• you want to get the logs to a different system in a different security domain (to prevent attackers from hiding their tracks)
• and many more …

In our case, we forward all messages to the remote system. Note that by applying different filters, you may only forward select entries to the remote system. Also note that you can include as many forwarding actions as you like. For example, if you need to have a backup central server, you can simply forward to both of them, using two different forwarding actions.

To learn how to configure the remote server, see recipe Receiving Messages from a Remote System.

Config Statements

# this is the simplest forwarding action:
*.* action(type="omfwd" target="192.0.2.1" port="10514" protocol="tcp")
# it is equivalent to the following obsolete legacy format line:
*.* @@192.0.2.1:10514 # do NOT use this any longer!
# Note: if the remote system is unreachable, processing will
# block here and discard messages after a while

# so a better use is
*.*  action(type="omfwd" target="192.0.2.2" port="10514" protocol="tcp"
            action.resumeRetryCount="100"
            queue.type="linkedList" queue.size="10000")
# this will de-couple the sending from the other logging actions,
# and prevent delays when the remote system is not reachable. Also,
# it will try to connect 100 times before it discards messages as
# undeliverable.
# the rest below is more or less a plain vanilla rsyslog.conf as 
# many distros ship it - it's more for your reference...
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none      /var/log/messages
# The authpriv file has restricted access.
authpriv.*                                    /var/log/secure
# Log all the mail messages in one place.
mail.*                                        /var/log/maillog
# Log cron stuff
cron.*                                        /var/log/cron
# Everybody gets emergency messages
*.emerg                                       :omusrmsg:*
# Save news errors of level crit and higher in a special file.
uucp,news.crit                                /var/log/spooler
# Save boot messages also to boot.log
local7.*                                      /var/log/boot.log

Things to think about

You need to select the protocol best suitable for your use case. If in doubt, TCP is a decent choice. This recipe uses TCP for that reason.

TCP forwarding is a build-in capability and always present. As such, no plugin needs to be loaded. The target can be specified by DNS name or IP address. Use IP addresses for most robust operations. If you use a DNS name and name resolution fails, forwarding may be disabled for some time. DNS resolution typically fails on the DNS server itself during system startup.

In this example, we forward to port 10514. We could as well remove the port=”…” parameter from the configuration, which would result in the default port being used. However, you need to specify the port address on the server in any case. So it is strongly advised to use an explicit port number to make sure that client and server configuration match each other (if they used different ports, the message transfer would not work.

This is a log-consolidation scenario. There exist at least two systems, a server and at least one client. The server is meant to gather log data from all the clients. Clients may (or may not) process and store messages locally. If they do doesn’t matter here. See recipe Sending Messages to a Remote Syslog Server for how to configure the clients.

Note that in this scenario, we just receive messages from remote machines but do not process them in any special way. Thus, messages from both the local and all remote systems show up in all log files that are written (as well, of course, in all other actions). While the log files contain the source, messages from all systems are intermixed. If you would like to record messages from remote systems to files different from the local system, please see recipe Storing Messages from a Remote System into a specific File for a potential solution.

This scenario provides samples for both UDP and TCP reception. There exist other choices (like RELP), but these are less frequently used. If in question what to use, check the rsyslog module reference and protocol documentation. Note that most devices send UDP messages by default. UDP is an unreliable transmission protocol, thus messages may get lost. TCP supports much more reliability, so if you can not accept message loss, you need to use TCP. Not all devices support TCP-based transports.

Things to think about

TCP and UDP recpetion are not build-in capabilities. You need to load the imtcp and/or imudp plugin in order to enable it. This needs to be done only once in rsyslog.conf. Do it right at the top. Also note that some distributions may package imtcp and/or imudp in separate packages. If so, you need to install them first.

Rsyslog versions prior to v3 had a command-line switch (-r/-t) to activate remote listening. This switch is still available by default and loads the required plugins and configures them with default parameters. However, that still requires the plugins are present on the system. It is recommended not to rely on compatibility mode but rather use proper configuration.

Note that the server port address specified in $InputTCPServerRun must match the port address that the clients send messages to.

Config Statements

# for TCP use:
module(load="imtcp") # needs to be done just once 
input(type="imtcp" port="514")
# for UDP use:
module(load="imudp") # needs to be done just once 
input(type="imudp" port="514")
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none      /var/log/messages
# The authpriv file has restricted access.
authpriv.*                                    /var/log/secure
# Log all the mail messages in one place.
mail.*                                        /var/log/maillog
# Log cron stuff
cron.*                                        /var/log/cron
# Everybody gets emergency messages
*.emerg                                       *
# Save news errors of level crit and higher in a special file.
uucp,news.crit                                /var/log/spooler
# Save boot messages also to boot.log
local7.*                                      /var/log/boot.log

How it works

Note that loading the plugins is not sufficient. You also need to activate the listeners. Note the subtle difference between the two startup commands. If you need to have listeners for multiple ports, you can define the startup commands more than once. If you need only TCP or only UDP, you can comment out the other part.