v7

rsyslog 7.1.1 (v7-devel) released

This is the first release that supports the new rule engine, which in turn supports unlimited nesting inside rsyslog.conf. Note that the new rule engine also supports if … then … else … constructs. This new engine lays the foundation for all other work to be done in v7. As discussed on the mailing list, BSD-style blocks are no longer supported.

ChangeLog:

http://www.rsyslog.com/changelog-for-7-1-1-v7-devel/

Download:

http://www.rsyslog.com/rsyslog-7-1-1-v7-devel/

As always, feedback is appreciated.

Best regards,
Florian Riedl

BSD-Style blocks will go away in rsyslog v7

Rsyslog supports BSD-style blocks since ages. They were a pretty handy tool to group actions together that should act only on remote hosts or log messages from specific programs. However, the v7 config system with its full nesting capabilities provides a much better – and easy to use – way to specify this. If both systems are mixed, the problem is that BSD-style blocks can be used to violate the nesting structure (examples below). Also, support for them adds a lot to rule engine code complexity. And finally, they are also very seldom used, few users even know they exist.

As a result, I have decided to drop support for BSD-style blocks in rsyslog v7 and above. A poll on the mailing list a week ago did not make anybody speak up against that change. So I assume none is hurt. This is especially the case as the conversion of BSD-style blocks to nested config is a very easy one.

Let’s look at this example:

!prog1
 *.* /var/log/prog1.log
 *.* /var/log/prog1again.log
 !prog2
 *.* /var/log/prog2.log
 *.* /var/log/prog2again.log
This code can very simply be replaced by:
 if $programname == 'prog1' then {
   /var/log/prog1.log
   /var/log/prog1again.log
}
if $programname == 'prog2' then {
   /var/log/prog2.log
   /var/log/prog2again.log
}

And if you prefer the more powerful action statments (probably not so much benefit for this use case…), you can write:

if $programname == 'prog1' then {
   action(type="omfile" file="/var/log/prog1.log")
   action(type="omfile" file="/var/log/prog1again.log")
}
if $programname == 'prog2' then {
   action(type="omfile" file="/var/log/prog2.log")
   action(type="omfile" file="/var/log/prog2again.log")
}

I expect that usually these easy cases happen. HOWEVER, if I had kept support for BSD-style blocks, one could configure things like this:

!prog1
if $msg contains 'test' then  {
                action(type="omfile" file="/var/log/somefile")
                !prog2
                mail.* :mmjsonparse:
                               & action(type="omfile" file="/var/log/somefile2")
                !prog3
                               & ~
                !prog4
                if $msg contains 'test2' then
                               /var/log/logfile
                else
                               /var/log/logfile2
}

Can you make out the actual nesting structure of this config? When, for example, programname needs to be “prog3” and what happens then? IMHO this combination can cause considerable user confusion and frustration. As such, I made a sharp cut and removed it.

My apologies for those that need to do the manual conversion. I am sure the time is well-invested in the long term.

rsyslog 7.1.0 (v7-devel) released

This release kicks off rsyslog v7. Version 7.1.0 is very similar to v6-devel, except that it contains the important capability to work with hierarchical properties. Note that this version does not yet contain the new ruleengine work – this will be part of the next v7 release. This release is primarily intended for those interested in working with the hierarchical properties. Note that the code obviously is currently in a somewhat experimental state.

ChangeLog:

http://www.rsyslog.com/changelog-for-7-1-0-v7-devel/

Download:

http://www.rsyslog.com/rsyslog-7-1-0-v7-devel/

As always, feedback is appreciated.

Best regards,
Florian Riedl

Scroll to top