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.
