BSD

rsyslog 7.5.1 (v7-devel) released

This release opens the new 7.5 development branch. Most importantly, this version provides certificate-based authentication for RELP. It also includes mmfields, a module that can be used to parse CEF and other similar delimited formats. BSD-support has been improved and imjournal has been hardened to prevent corrupt journal databases from spamming the system too much. More information about configuring the certificate-based authentication for RELP: http://www.rsyslog.com/using-tls-with-relp/

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

Download: http://www.rsyslog.com/rsyslog-7-5-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.
Scroll to top