config

rsyslog 6.3.3 config format improvements

In rsyslog 6.3.3, the config processor has finally changed. The old legacy processor (and with it the early RainerScript implementation) is thrown out and has been replaced by the so-called RainerScript processor (why that crazy name?). This is an extremely important step for rsyslog, as it now has the foundation for a much better and intuitive rsyslog.conf format. However, most of that can not be seen in 6.3.3, as it requires more work, especially in the plugin arena. Still, there are a couple of smaller improvements available.

Most importantly, the performance of script based filters has been considerably enhanced. Preliminary testing shows a three times speedup (we’ll do more benchmarking at a later stage; there is also still lots of room for optimization ;-)).

The ugliness of continuation lines has been removed. They may still be used, and this may make a lot of sense with some actions, but you are usually no longer forced to use continuation lines. Take this config snippet from a leading distro:


if ( \
     /* kernel up to warning except of firewall  */ \
     ($syslogfacility-text == 'kern')      and      \
     ($syslogseverity <= 4 /* warning */ ) and not  \
     ($msg contains 'IN=' and $msg contains 'OUT=') \
 ) or ( \
     /* up to errors except of facility authpriv */ \
     ($syslogseverity <= 3 /* errors  */ ) and not  \
     ($syslogfacility-text == 'authpriv')           \
 ) \
then /dev/tty10
& |/dev/xconsole

This can now be written as follows:


if (
     /* kernel up to warning except of firewall  */
     ($syslogfacility-text == 'kern')      and
     ($syslogseverity <= 4 /* warning */ ) and not
     ($msg contains 'IN=' and $msg contains 'OUT=')
 ) or (
     /* up to errors except of facility authpriv */
     ($syslogseverity <= 3 /* errors  */ ) and not
     ($syslogfacility-text == 'authpriv')
 )
then /dev/tty10

& |/dev/xconsole

Continue reading “rsyslog 6.3.3 config format improvements”

rsyslog 6.3.0 (devel) released

The release of rsyslog 6.3.0 introduces a new major feature. With this release we introduce a new config system. You can find some information about the new config system in Rainer’s blog:

http://blog.gerhards.net/2011/06/new-rsyslog-config-system-materializes.html

ChangeLog:

http://www.rsyslog.com/changelog-for-6-3-0-devel/

Download:

http://www.rsyslog.com/rsyslog-6-3-0-devel/

As always, feedback is appreciated.

Best regards,
Florian Riedl

new rsyslog config system materializes

The past weeks we have worked pretty hard on the new rsyslog config system. The legacy system was quite different from what you expect in modern software. Most importantly, the legacy system applied directives as the config file was read, which made it extremely hard to restructure the config file format. That also prevented features like privilege drop from working fully correct.

We have now basically changed the config system so that there is a clear difference between the config load phase and applying the config. Most importantly, this means privilege drop now works correctly in all cases. Other than that, there are no user-visible enhancements at the moment. However, the internal plumbing has changed dramatically and enables future change. Most importantly, this finally creates a path to a new config language, as we now have a clear interface as part of the in-memory representation of the config, which is config language agnostic.

With this initial release, there may still be some things inside the core that can be optimized. Right now, the system aims at the capability to have multiple config objects loaded (but not active) at the same time. However, there are some data instances where this is not cleanly followed in order to reuse some code. This is not a problem, because the rest of the rsyslog engine does not support dynamic config reload (and thus multiple configs at runtime) at all.

Also it must be noted that the current code is quite experimental. So there is some risk involved in running the initial 6.3.0 version. However, all dramatic changes were made to the config system. That means if the system initializes correctly, it will most probably run without any issues. The risk window is constrained to the initial startup, what should be quite controllable. Users that use privilege drop are advised to check that their configurations work as expected. The previous system did some initialization with full privileges. This is no longer the case, except for modules that actually require full privileges (e.g. imtcp to bind privileged ports). Most importantly, files are now created with dropped privileges right from the beginning. I expect that some (unclean) configurations will run into trouble with that. The good news about that is that they would run into trouble with older releases as well, but only after a HUP. Now things break immediately, what makes them much easier to diagnose.

Changing the settings

Go back to What is imuxsock?

Before we can begin testing on how rate limiting works, we should change the default settings. By default, rate limiting will only work, if a process sends more than 200 messages in 5 seconds.To have some influence on the rate limiting we have basically two options:

$SystemLogRateLimitInterval [number]
$SystemLogRateLimitBurst [number]

The SystemLogRateLimitInterval determines the amount of time that is being measured for rate limiting. By default this is set to 5 seconds. The SystemLogRateLimitBurst defines the amount of messages, that have to occur in the time limit of SystemLogRateLimitInterval, to trigger rate limiting. Here, the default is 200 messages. For creating a more effective test, we will alter the default values.

To change these settings we open the rsyslog configuration. Open the configuration with vi (please note, that we use the default configuration path):

vi /etc/rsyslog.conf

Now we need to search the right spot for the entries. Find the following:

$ModLoad imuxsock.so

This entry will load the imuxsock module.

Now insert two new lines under the ModLoad command and fill them as follows:

$SystemLogRateLimitInterval 2
$SystemLogRateLimitBurst 50

These are the option for the module with some values. This means in plain words, that rate limiting will take effect if more than 50 messages occur in 2 seconds.

To make sure, that we will see all messages that are logged, we insert another entry into the configuration. Go to the section in the rsyslog.conf that holds the “Rules”. Insert a new rule that looks like this:

*.* /var/log/everything.log

You can name the file as you want. Every log message will be written into this file for our review.

Save the configuration file and exit vi. Now we need to restart rsyslog. This is necessary because it will only load the configuration once on startup.

Go on to First try to test rate limiting (fail)

Scroll to top