Changelog for 7.1.3 (v7-devel)

Version 7.1.3  [devel] 2012-09-17

  • introduced “set” and “unset” config statements
  • bugfix: missing support for escape sequences in RainerScript only \’ was supported. Now the usual set is supported. Note that v5 used \x as escape where x was any character (e.g. “\n” meant “n” and NOT LF). This also means there is some incompatibility to v5 for well-know sequences. Better break it now than later.
  • bugfix: invalid property name in property-filter could cause abort if action chaining (& operator) was used
    http://bugzilla.adiscon.com/show_bug.cgi?id=355
    Thanks to pilou@gmx.com for the bug report

Rsyslog Windows Agent 1.1 Released

Adiscon is proud to announce the 1.1 release of RSyslog Windows Agent. This is a minor release.

This release contains a bugfix for the Filterengine.

Build-IDs: Service 1.1.107, Client 1.1.119

Bugfixes

  • Filterengine:
    A problem within the Filterengine was fixed that caused testing filters like TRUE and FALSE not to work as expected.

 

Version 1.1 is a free download. Customers with existing 1.x keys can contact our Sales department for upgrade prices. If you have a valid Upgrade Insurance ID, you can request a free new key by sending your Upgrade Insurance ID to sales@adiscon.com. Please note that the download enables the free 30-day trial version if used without a key – so you can right now go ahead and evaluate it.

Rsyslog Windows Agent 1.1 Released

Adiscon is proud to announce the 1.1 release of RSyslog Windows Agent. This is a minor release.

This release contains a bugfix for the Discard Action

Build-IDs: Service 1.1.106, Client 1.1.119

Bugfixes

  • Discard Action:
    Fixed “Discard Action”, the Action works now as expected.

 

Version 1.1 is a free download. Customers with existing 1.x keys can contact our Sales department for upgrade prices. If you have a valid Upgrade Insurance ID, you can request a free new key by sending your Upgrade Insurance ID to sales@adiscon.com. Please note that the download enables the free 30-day trial version if used without a key – so you can right now go ahead and evaluate it.

rsyslog 7.1.2 (v7-devel) released

This is a bugfixing release vor the v7 development branch. It includes critical fixes for a message duplication bug, a bug when using multiple rulesets and some more. For more information please take a look into the ChangeLog.

ChangeLog:

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

Download:

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

As always, feedback is appreciated.

Best regards,
Florian Riedl

Changelog for 7.1.2 (v7-devel)

Version 7.1.2  [devel] 2012-09-12

  • bugfix: messages were duplicated, sometimes massively regression from new code in 7.1.1 and reason for early release
  • bugfix: remove invalid socket option call from imuxsock
    Thanks to Cristian Ionescu-Idbohrn and Jonny Törnbom
  • bugfix: abort when invalid property name was configured in property-based filter
  • bugfix: multiple rulesets did no longer work correctly (7.1.1 regression)

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