This document is currently being enhanced. Please pardon its current appearance.
Rsyslogd is configured via the rsyslog.conf file, typically found in /etc. By default, rsyslogd reads the file /etc/rsyslog.conf.
While rsyslogd contains enhancements over standard syslogd, efforts have been made to keep the configuration file as compatible as possible. While, for obvious reasons, enhanced features require a different config file syntax, rsyslogd should be able to work with a standard syslog.conf file. This is especially useful while you are migrating from syslogd to rsyslogd.
Rsyslog supports standard sysklogd's configuration file format and extends it. So in general, you can take a "normal" syslog.conf and use it together with rsyslogd. It will understand everything. However, to use most of rsyslogd's unique features, you need to add extended configuration directives.
Rsyslogd supports the classical, selector-based rule lines. They are still at the heart of it and all actions are initiated via rule lines. A rule lines is any line not starting with a $ or the comment sign (#). Lines starting with $ carry rsyslog-specific directives.
Every rule line consists of two fields, a selector field and an action field.
These two fields are separated by one or more spaces or tabs. The selector field
specifies a pattern of facilities and priorities belonging to the specified
action.
Lines starting with a hash mark ("#'') and empty lines are ignored.
Allowed sender lists can be used to specify which remote systems are allowed to send syslog messages to rsyslogd. With them, further hurdles can be placed between an attacker and rsyslogd. If a message from a system not in the allowed sender list is received, that message is discarded. A diagnostic message is logged, so that the fact is recorded (this message can be turned off with the "-w" rsyslogd command line option).
Allowed sender lists can be defined for UDP and TCP senders seperately. There can be as many allowed senders as needed. The syntax to specify them is:
$AllowedSender <protocol>, ip[/bits], ip[/bits]
"$AllowedSender" is the directive - it must be written exactly as shown and the $ must start at the first column of the line. "<protocol>" is either "UDP" or "TCP". It must immediately be followed by the comma, else you will receive an error message. "ip[/bits]" is a machine or network ip address as in "192.0.2.0/24" or "127.0.0.1". If the "/bits" part is omitted, a single host is assumed (32 bits or mask 255.255.255.255). "/0" is not allowed, because that would match any sending system. If you intend to do that, just remove all $AllowedSender directives. If more than 32 bits are requested, they are adjusted to 32. Multiple allowed senders can be specified in a comma-delimited list. Also, multiple $AllowedSender lines can be given. They are all combined into one UDP and one TCP list. Performance-wise, it is good to specify those allowed senders with high traffic volume before those with lower volume. As soon as a match is found, no further evaluation is necessary and so you can save CPU cycles.
Rsyslogd handles allowed sender detection very early in the code, nearly as the first action after receiving a message. This keeps the access to potential vulnerable code in rsyslog at a minimum. However, it is still a good idea to impose allowed sender limitations via firewalling.
WARNING: by UDP design, rsyslogd can not identify a spoofed sender address in UDP syslog packets. As such, a malicous person could spoof the adress of an allowed sender, send such packets to rsyslogd and rsyslogd would accept them as being from the faked sender. To prevent this, use syslog via TCP exclusively. If you need to use UDP-based syslog, make sure that you do proper egress and ingress filtering at the firewall and router level.
An example for an allowed sender list is as follows:
$AllowedSender UDP, 127.0.0.1, 192.0.2.0/24
Templates are a key feature of rsyslog. They allow to specify any format a user might want. Every output in rsyslog uses templates - this holds true for files, user messages and so on. The database writer expects its template to be a proper SQL statement - so this is highly customizable too. You might ask how does all of this work when no templates at all are specified. Good question ;) The answer is simple, though. Templates compatible with the stock syslogd formats are hardcoded into rsyslogd. So if no template is specified, we use one of these hardcoded templates. Search for "template_" in syslogd.c and you will find the hardcoded ones.
A template consists of a template directive, a name, the actual template text and optional options. A sample is:
$template MyTemplateName,"\7Text %property% some more text\n",<options>The "$template" is the template directive. It tells rsyslog that this line contains a template. "MyTemplateName" is the template name. All other config lines refer to this name. The text within quotes is the actual template text. The backslash is an escape character, much as it is in C. It does all these "cool" things. For example, \7 rings the bell (this is an ASCII value), \n is a new line. C programmers and perl coders have the advantage of knowing this, but the set in rsyslog is a bit restricted currently.
All text in the template is used literally, except for things within percent
signs. These are properties and allow you access to the contents of the syslog
message. Properties are accessed via the property replacer (nice name, huh) and
it can do cool things, too. For example, it can pick a substring or do
date-specific formatting. More on this is below, on some lines of the property
replacer.
The <options> part is optional. It carries options influencing the template as
whole. See details below. Be sure NOT to mistake template options with property
options - the later ones are processed by the property replacer and apply to a
SINGLE property, only (and not the whole template).
Template options are case-insensitive. Currently defined are:
sql - format the string suitable for a SQL statement in MySQL format. This will
replace single quotes ("'") and the backslash character by their
backslash-escaped counterpart ("\'" and "\\") inside each field. Please note
that in MySQL configuration, the NO_BACKSLASH_ESCAPES
mode must be turned off for this format to work (this is the default).
stdsql - format the string suitable for a SQL statement that is to be
sent to a standards-compliant sql server. This will
replace single quotes ("'") by two single quotes ("''") inside each field.
You must use stdsql together with MySQL if in MySQL configuration the
NO_BACKSLASH_ESCAPES is turned on.
Either the sql or stdsql
option must be specified when a template is used for writing to a database,
otherwise injection might occur. Please note that due to the unfortunate fact
that several vendors have violated the sql standard and introduced their own
escape methods, it is impossible to have a single option doing all the work.
So you yourself must make sure you are using the right format. If you choose
the wrong one, you are still vulnerable to sql injection.
Please note that the database writer *checks* that the sql option is present in
the template. If it is not present, the write database action is disabled. This
is to guard you against accidential forgetting it and then becoming vulnerable
to SQL injection. The sql option can also be useful with files - especially if
you want to import them into a database on another machine for performance
reasons. However, do NOT use it if you do not have a real need for it - among
others, it takes some toll on the processing time. Not much, but on a really
busy system you might notice it ;)
The default template for the write to database action has the sql option set.
As we currently support only MySQL and the sql option matches the default MySQL
configuration, this is a good choice. However, if you have turned on
NO_BACKSLASH_ESCAPES in your MySQL config, you need
to supply a template with the stdsql option. Otherwise you will become
vulnerable to SQL injection.
To escape:
% = \%
\ = \\ --> '\' is used to escape (as in C)
$template TraditionalFormat,%timegenerated% %HOSTNAME% %syslogtag%%msg%\n"
Properties can be accessed by the property replacer
(see there for details).
Output Channels are a new concept first introduced in rsyslog 0.9.0. As of this
writing, it is still unclear if they will stay in rsyslog or go away. So if you
use them, be prepared to change you configuration file syntax when you upgrade
to a later release.
The idea behind output channel definitions is that it shall provide an umbrella
for any type of output that the user might want. In essence,
this is the "file" part of selector lines (and this is why we are not sure
output channel syntax will stay after the next review). There is a
difference, though: selector channels both have filter conditions (currently
facility and severity) as well as the output destination. Output channels define
the output defintion, only. As of this build, they can only be used to write to
files - not pipes, ttys or whatever else. If we stick with output channels, this
will change over time.
In concept, an output channel includes everything needed to know about an
output actions. In practice, the current implementation only carries
a filename, a maximum file size and a command to be issued when this file size
is reached. More things might be present in future version, which might also
change the syntax of the directive.
Output channels are defined via an $outchannel directive. It's syntax is as
follows:
$outchannel name,file-name,max-size,action-on-max-size
name is the name of the output channel (not the file), file-name is the file
name to be written to, max-size the maximum allowed size and action-on-max-size
a command to be issued when the max size is reached.
Please note that max-size is queried BEFORE writing the log message to the file.
So be sure to set this limit reasonably low so that any message might fit. For
the current release, setting it 1k lower than you expected is helpful. The
max-size must always be specified in bytes - there are no special symbols (like
1k, 1m,...) at this point of development.
Keep in mind that $outchannel just defines a channel with "name". It does not
activate it. To do so, you must use a selector line (see below). That selector
line includes the channel name plus an $ sign in front of it. A sample might be:
*.* $mychannel
In its current form, output channels primarily provide the ability to size-limit
an output file. To do so, specify a maximum size. When this size is reachead,
rsyslogd will execute the action-on-max-size command and then reopen the file
and retry. The command should be something like a log rotation script or a
similar thing.
WARNING
The current command logic is a quick hack. It simply issues the command via a system() call, which is very dirty. Don't make rsyslogd a suid binary and use action-on-max-size commands - this will mess up things. Fixing this is on top of the todo list and the fix will hopefully appear soon.
If there is no action-on-max-size command or the command did not resolve the situation, the file is closed and never reopened by rsyslogd (except, of course, by huping it). This logic was integrated when we first experienced severe issues with files larger 2gb, which could lead to rsyslogd dumping core. In such cases, it is more appropriate to stop writing to a single file. Meanwhile, rsyslogd has been fixed to support files larger 2gb, but obviously only on file systems and operating system versions that do so. So it can still make sense to enforce a 2gb file size limit.
Rsyslog offers two different types "filter conditions":
Selectors are the traditional way of filtering syslog messages. They have been kept in rsyslog with their orginal syntax, because it is well-known, highly effective and also needed for compatibility with stock syslogd configuration files. If you just need to filter based on priority and facility, you should do this with selector lines. They are not second-class citicens in rsyslog and offer the best performance for this job.
The selector field itself again consists of two parts, a facility and a
priority, separated by a period (``.''). Both parts are case insenstive and can
also be specified as decimal numbers, but don't do that, you have been warned.
Both facilities and priorities are described in rsyslog(3). The names mentioned
below correspond to the similar LOG_-values in /usr/include/rsyslog.h.
The facility is one of the following keywords: auth, authpriv, cron, daemon,
kern, lpr, mail, mark, news, security (same as auth), syslog, user, uucp and
local0 through local7. The keyword security should not be used anymore and mark
is only for internal use and therefore should not be used in applications.
Anyway, you may want to specify and redirect these messages here. The facility
specifies the subsystem that produced the message, i.e. all mail programs log
with the mail facility (LOG_MAIL) if they log using syslog.
Please note that the upcoming next syslog-RFC specifies many more facilities.
Support for them will be added in a future version of rsyslog, which might
require changes to existing configuration files.
The priority is one of the following keywords, in ascending order: debug, info,
notice, warning, warn (same as warning), err, error (same as err), crit, alert,
emerg, panic (same as emerg). The keywords error, warn and panic are deprecated
and should not be used anymore. The priority defines the severity of the message
The behavior of the original BSD syslogd is that all messages of the specified
priority and higher are logged according to the given action. Rsyslogd behaves the same, but has some extensions.
In addition to the above mentioned names the rsyslogd(8) understands the
following extensions: An asterisk (``*'') stands for all facilities or all
priorities, depending on where it is used (before or after the period). The
keyword none stands for no priority of the given facility.
You can specify multiple facilities with the same priority pattern in one
statement using the comma (``,'') operator. You may specify as much facilities
as you want. Remember that only the facility part from such a statement is
taken, a priority part would be skipped.
Multiple selectors may be specified for a single action using the semicolon (``;'') separator. Remember that each selector in the selector field is capable to overwrite the preceding ones. Using this behavior you can exclude some priorities from the pattern.
Rsyslogd has a syntax extension to the original BSD source, that makes its use more intuitively. You may precede every priority with an equation sign (``='') to specify only this single priority and not any of the above. You may also (both is valid, too) precede the priority with an exclamation mark (``!'') to ignore all that priorities, either exact this one or this and any higher priority. If you use both extensions than the exclamation mark must occur before the equation sign, just use it intuitively.
Property-based filters are unique to rsyslogd. They allow to filter on any property, like HOSTNAME, syslogtag and msg. A list of all currently-supported properties can be found in the property replacer documentation (but keep in mind that only the properties, not the replacer is supported). With this filter, each properties can be checked against a specified value, using a specified compare operation. Currently, there is only a single compare operation (contains) available, but additional operations will be added in the future.
A property-based filter must start with a colon in column 0. This tells rsyslogd that it is the new filter type. The colon must be followed by the property name, a comma, the name of the compare operation to carry out, another comma and then the value to compare against. This value must be quoted. There can be spaces and tabs between the commas. Property names and compare operations are case-sensitive, so "msg" works, while "MSG" is an invalid property name. In brief, the syntax is as follows:
:property, [!]compare-operation, "value"
The following compare-operations are currently supported:
| contains | Checks if the string provided in value is contained in the property. There must be an exact match, wildcards are not supported. |
| isequal | Compares the "value" string provided and the property contents. These two values must be exactly equal to match. The difference to contains is that contains searchs for the value anywhere inside the property value, whereas all characters must be identical for isequal. As such, isequal is most useful for fields like syslogtag or FROMHOST, where you probably know the exact contents. |
| startswith | Checks if the value is found exactly at the beginning of the
property value. For example, if you search for "val" with
it will be a match if msg contains "values are in this message" but it won't match if the msg contains "There are values in this message" (in the later case, contains would match). Please note that "startswith" is by far faster than regular expressions. So even once they are implemented, it can make very much sense (performance-wise) to use "startswith". |
| regex | NOT YET IMPLEMENTED - value holds an regular expression |
You can use the bang-character (!) immediately in front of a compare-operation, the outcome of this operation is negated. For example, if msg contains "This is an informative message", the following sample would not match:
:msg, contains, "error"
but this one matches:
:msg, !contains, "error"
Using negation can be useful if you would like to do some generic processing but exclude some specific events. You can use the discard action in conjunction with that. A sample would be:
*.* /var/log/allmsgs-including-informational.log
:msg, contains, "informational" ~
*.* /var/log/allmsgs-but-informational.log
Do not overlook the red tilde in line 2! In this sample, all messages are written to the file allmsgs-including-informational.log. Then, all messages containing the string "informational" are discarded. That means the config file lines below the "discard line" (number 2 in our sample) will not be applied to this message. Then, all remaining lines will also be written to the file allmsgs-but-informational.log.
Value is a quoted string. It supports some escape sequences:
\" - the quote character (e.g. "String with \"Quotes\"")
\\ - the backslash character (e.g. "C:\\tmp")
Escape sequences always start with a backslash. Additional escape sequences might be added in the future. Backslash characters must be escaped. Any other sequence then those outlined above is invalid and may lead to unpredictable results.
Probably, "msg" is the most prominent use case of property based filters. It is the actual message text. If you would like to filter based on some message content (e.g. the presence of a specific code), this can be done easily by:
:msg, contains, "ID-4711"
This filter will match when the message contains the string "ID-4711". Please note that the comparison is case-sensitive, so it would not match if "id-4711" would be contained in the message.
Getting property-based filters right can sometimes be challenging. In order to help you do it with as minimal effort as possible, rsyslogd spits out debug information for all property-based filters during their evaluation. To enable this, run rsyslogd in foreground and specify the "-d" option.
Boolean operations inside property based filters (like 'message contains "ID17" or message contains "ID18"') are currently not supported (except for "not" as outlined above). Please note that while it is possible to query facility and severity via property-based filters, it is far more advisable to use classic selectors (see above) for those cases.
The action field of a rule describes what to do with the message. In general,
message content is written to a kind of "logfile". But also other actions might
be done, like writing to a database table or forwarding to another host.
Templates can be used with all actions. If used, the specified template is used
to generate the message content (instead of the default template). To specify a
template, write a semicolon after the action value immediately followed by the
template name.
Beware: templates MUST be defined BEFORE they are used. It is OK to define some
templates, then use them in selector lines, define more templates and use use
them in the following selector lines. But it is NOT permitted to use a template
in a selectore line that is above its definition. If you do this, the selector
line will be ignored.
Typically messages are logged to real files. The file has to be specified with
full pathname, beginning with a slash "/''.
You may prefix each entry with the minus ``-'' sign to omit syncing the file
after every logging. Note that you might lose information if the system crashes
right behind a write attempt. Nevertheless this might give you back some
performance, especially if you run programs that use
logging in a very verbose manner.
If your system is connected to a reliable UPS and you receive lots of log data (e.g. firewall logs), it might be a very good idea to turn of syncing by specifying the "-" in front of the file name.
This version of rsyslogd(8) has support for logging output to named pipes (fifos). A fifo or named pipe can be used as a destination for log messages by prepending a pipe symbol (``|'') to the name of the file. This is handy for debugging. Note that the fifo must be created with the mkfifo(1) command before rsyslogd(8) is started.
If the file you specified is a tty, special tty-handling is done, same with /dev/console.
Rsyslogd provides full remote logging, i.e. is able to send messages to a
remote host running rsyslogd(8) and to receive messages from remote hosts. The
remote host won't forward the message again, it will just log them locally. To
forward messages to another host, prepend the hostname with the at sign (``@'').
Using this feature you're able to control all syslog messages on one host, if
all other machines will log remotely to that. This tears down
administration needs.
Please note that this version of rsyslogd by default does NOT forward messages
it has received from the network to another host. Specify the
-h option to enable this.
Usually critical messages are also directed to ``root'' on that machine. You can specify a list of users that shall get the message by simply writing the login. You may specify more than one user by separating them with commas (",''). If they're logged in they get the message. Don't think a mail would be sent, that might be too late.
Emergency messages often go to all users currently online to notify them that something strange is happening with the system. To specify this wall(1)-feature use an asterisk ("*'').
This allows logging of the message to a database table. Currently, only MySQL
databases are supported. By default, a MonitorWare-compatible schema is required
for this to work. You can create that schema with the createDB.SQL file that
came with the rsyslog package. You can also
use any other schema of your liking - you just need to define a proper template
and assign this template to the action.
The database writer is called by specifying a greater-then sign (">") in front
of the database connect information. Immediately after that
sign the database host name must be given, a comma, the database name, another
comma, the database user, a comma and then the user's password. If a specific
template is to be used, a semicolong followed by the template name can follow
the connect information. This is as follows:
>dbhost,dbname,dbuser,dbpassword;dbtemplate
If the discard action is carried out, the received message is immediately discarded. No further processing of it occurs. Discard has primarily been added to filter out messages before carrying on any further processing. For obvious reasons, the results of "discard" are depending on where in the configuration file it is being used. Please note that once a message has been discarded there is no way to retrive it in later configuration file lines.
Discard can be highly effective if you want to filter out some annoying messages that otherwise would fill your log files. To do that, place the discard actions early in your log files. This often plays well with property-based filters, giving you great freedom in specifying what you do not want.
Discard is just the single tilde character with no further parameters:
~
For example,
*.* ~
discards everything (ok, you can achive the same by not running rsyslogd at all...).
Binds an output channel definition (see there for details) to this action. Output channel actions must start with a $-sign, e.g. if you would like to bind your output channel definition "mychannel" to the action, use "$mychannel". Output channels support template definitions like all all other actions.
This executes a program in a subshell. The programm is passed the template-generated message as the only command line parameter. Rsyslog waits until the program terminates and only then continues to run.
^programm-to-execute;template
The program-to-execute can be any valid executable.
WARNING: The Shell Execute action was added to serve an urgent need. While it is considered reasonable save when used with some thinking, its implications must be considered. The current implementation uses a system() call to execute the command. This is not the best way to do it (and will hopefully changed in further releases). Also, proper escaping of special characters is done to prevent command injection. However, attackers always find smart ways to circumvent escaping, so we can not say if the escaping applied will really safe you from all hassles. Lastely, rsyslog will wait until the shell command terminates. Thus, a program error in it (e.g. an infinite loop) can actually disable rsyslog. Even without that, during the programs run-time no messages are processed by rsyslog. As the IP stacks buffers are quickly overflowed, this bears an increased risk of message loss. You must be aware of these implications. Even though they are severe, there are several cases where the "shell execute" action is very useful. This is the reason why we have included it in its current form. To mitigate its risks, always a) test your program thouroughly, b) make sure its runtime is as short as possible (if it requires a longer run-time, you might want to spawn your own sub-shell asynchronously), c) apply proper firewalling so that only known senders can send syslog messages to rsyslog. Point c) is especially important: if rsyslog is accepting message from any hosts, chances are much higher that an attacker might try to exploit the "shell execute" action.
Every ACTION can be followed by a template name. If so, that template is used for message formatting. If no name is given, a hardcoded default template is used for the action. There can only be one template name for each given action. The default template is specific to each action. For a description of what a template is and what you can do with it, see "TEMPLATES" at the top of this document.
Below are example for templates and selector lines. I hope they are self-explanatory. If not, please see www.monitorware.com/rsyslog/ for advise.
Please note that the samples are split across multiple lines. A template MUST
NOT actually be split across multiple lines.
A template that resambles traditional syslogd file output:
$template TraditionalFormat,"%timegenerated% %HOSTNAME%
%syslogtag%%msg:::drop-last-lf%\n"
A template that tells you a little more about the message:
$template precise,"%syslogpriority%,%syslogfacility%,%timegenerated%,%HOSTNAME%,
%syslogtag%,%msg%\n"
A template for RFC 3164 format:
$template RFC3164fmt,"<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag%%msg%"
A template for the format traditonally used for user messages:
$template usermsg," XXXX%syslogtag%%msg%\n\r"
And a template with the traditonal wall-message format:
$template wallmsg,"\r\n\7Message from syslogd@%HOSTNAME% at %timegenerated%
A template that can be used for the database write (please note the SQL
template option)
$template MySQLInsert,"insert iut, message, receivedat values
('%iut%', '%msg:::UPPERCASE%', '%timegenerated:::date-mysql%')
into systemevents\r\n", SQL
The following template emulates WinSyslog
format (it's an Adiscon format, you do
not feel bad if you don't know it ;)). It's interesting to see how it takes
different parts out of the date stamps. What happens is that the date stamp is
split into the actual date and time and the these two are combined with just a
comma in between them.
$template WinSyslogFmt,"%HOSTNAME%,%timegenerated:1:10:date-rfc3339%,
%timegenerated:12:19:date-rfc3339%,%timegenerated:1:10:date-rfc3339%,
%timegenerated:12:19:date-rfc3339%,%syslogfacility%,%syslogpriority%,
%syslogtag%%msg%\n"
# Store critical stuff in critical
#
*.=crit;kern.none /var/adm/critical
This will store all messages with the priority crit in the file /var/adm/critical,
except for any kernel message.
# Kernel messages are first, stored in the kernel
# file, critical messages and higher ones also go
# to another host and to the console. Messages to
# the host finlandia are forwarded in RFC 3164
# format (using the template defined above).
#
kern.* /var/adm/kernel
kern.crit @finlandia;RFC3164fmt
kern.crit /dev/console
kern.info;kern.!err /var/adm/kernel-info
The first rule direct any message that has the kernel facility to the file /var/adm/kernel.
The second statement directs all kernel messages of the priority crit and higher
to the remote host finlandia. This is useful, because if the host crashes and
the disks get irreparable errors you might not be able to read the stored
messages. If they're on a remote host, too, you still can try to find out the
reason for the crash.
The third rule directs these messages to the actual console, so the person who
works on the machine will get them, too.
The fourth line tells rsyslogd to save all kernel messages that come with
priorities from info up to warning in the file /var/adm/kernel-info. Everything
from err and higher is excluded.
# The tcp wrapper loggs with mail.info, we display
# all the connections on tty12
#
mail.=info /dev/tty12
This directs all messages that uses mail.info (in source LOG_MAIL | LOG_INFO) to
/dev/tty12, the 12th console. For example the tcpwrapper tcpd(8) uses this as
it's default.
# Store all mail concerning stuff in a file
#
mail.*;mail.!=info /var/adm/mail
This pattern matches all messages that come with the mail facility, except for
the info priority. These will be stored in the file /var/adm/mail.
# Log all mail.info and news.info messages to info
#
mail,news.=info /var/adm/info
This will extract all messages that come either with mail.info or with news.info
and store them in the file /var/adm/info.
# Log info and notice messages to messages file
#
*.=info;*.=notice;\
mail.none /var/log/messages
This lets rsyslogd log all messages that come with either the info or the notice
facility into the file /var/log/messages, except for all
messages that use the mail facility.
# Log info messages to messages file
#
*.=info;\
mail,news.none /var/log/messages
This statement causes rsyslogd to log all messages that come with the info
priority to the file /var/log/messages. But any message coming either with the
mail or the news facility will not be stored.
# Emergency messages will be displayed using wall
#
*.=emerg *
This rule tells rsyslogd to write all emergency messages to all currently logged
in users. This is the wall action.
# Messages of the priority alert will be directed
# to the operator
#
*.alert root,rgerhards
This rule directs all messages with a priority of alert or higher to the
terminals of the operator, i.e. of the users ``root'' and ``rgerhards'' if
they're logged in.
*.* @finlandia
This rule would redirect all messages to a remote host called finlandia. This is
useful especially in a cluster of machines where all syslog messages will be
stored on only one machine.
In the format shown above, UDP is used for transmitting the message. The
destination port is set to the default auf 514. Rsyslog is also capable of using
much more secure and reliable TCP sessions for message forwarding. Also, the
destination port can be specified. To select TCP, simply add one additional @ in
front of the host name (that is, @host is UPD, @@host is TCP). For example:
*.* @@finlandia
To specify the destination port on the remote machine, use a colon followed by
the port number after the machine name. The following forwards to port 1514 on
finlandia:
*.* @@finlandia:1514
This syntax works both with TCP and UDP based syslog. However, you will probably
primarily need it for TCP, as there is no well-accepted port for this transport
(it is non-standard). For UDP, you can usually stick with the default auf 514,
but might want to modify it for security rea-
sons. If you would like to do that, it's quite easy:
*.* @finlandia:1514
*.* >dbhost,dbname,dbuser,dbpassword;dbtemplate
This rule writes all message to the database "dbname" hosted on "dbhost". The
login is done with user "dbuser" and password "dbpassword". The actual table
that is updated is specified within the template (which contains the insert
statement). The template is called "dbtemplate" in this case.
:msg,contains,"error" @errorServer
This rule forwards all messages that contain the word "error" in the msg part to the server "errorServer". Forwarding is via UDP. Please note the colon in fron
Rsyslogd uses a slightly different syntax for its configuration file than the
original BSD sources. Originally all messages of a specific priority and above
were forwarded to the log file. The modifiers ``='', ``!'' and ``-'' were added
to make rsyslogd more flexible and to use it in a more intuitive manner.
The original BSD syslogd doesn't understand spaces as separators between the
selector and the action field.
When compared to syslogd from sysklogd package, rsyslogd offers additional
features (like template and database support). For obvious reasons, the syntax for
defining such features is available
in rsyslogd, only.