Rsyslog Windows Agent 1.1b Released

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

This release contains a bugfix for the Filterengine.

Build-IDs: Service 1.1.108, Client 1.1.119

Bugfixes

  • Fixed/Readded support for the “-r -o” command line switch. This command switch enables you to run the service in console mode for a single run only. This currently only works with one v1 Eventlog Monitor configured. In this case the service will process all Events, and quits the process afterwards.

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.

How to use authpriv on Solaris

Usually you can filter for a facility by a facility name. In the case of authpriv which I want to describe now, this is fairly easy:

authpriv.*     /var/log/authprivlog

That will work just fine with rsyslog on any common Linux system.

But, when using Solaris, some things work similar and some work different. In the case of authpriv the name will not work. Thus you have to use a different way to filter for authpriv. Whilst the name will not work, the facility number works. So a possible filter looks like that:

if $syslogfacility == 10 then /var/log/authprivlog

Valid values would be 4 or 10 as described in RFC5424.

Changelog for 6.4.2 (v6-stable)

Version 6.4.2  [V6-STABLE] 2012-09-20

  • bugfix: potential abort, if action queue could not be properly started
    This most importantly could happen due to configuration errors.
  • bugfix: remove invalid socket option call from imuxsock
    Thanks to Cristian Ionescu-Idbohrn and Jonny Törnbom
  • 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-known sequences. Better break it now than later.
  • bugfix: config validation run did not always return correct return state

rsyslog 7.1.4 (v7-devel) released

This version implements the “missing bits” for full JSON handling: json support inside variable evaluation, the string concatenation operator and copying of full json trees in variable assignment. Most importantly, the json structure is now also persisted across disk-queues. The release also contains a number of bug fixes.

ChangeLog:

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

Download:

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

As always, feedback is appreciated.

Best regards,
Florian Riedl

Changelog for 7.1.4 (v7-devel)

Version 7.1.4  [devel] 2012-09-19

  • implemented ability for CEE-based properties to be stored in disk queues
  • implemented string concatenation in expressions via &-operator
  • implemented json subtree copy in variable assignment
  • implemented full JSON support for variable manipulation
  • introduced “subtree”-type templates
  • bugfix: omfile action did not respect “template” parameter
    … and used default template in all cases
  • bugfix: MsgDup() did not copy CEE structure
    This function was called at various places, most importantly during “last messages repeated n times” processing and omruleset. If CEE(JSON) data was present, it was lost as part of the copy process.
  • bugfix: debug output indicated improper queue type

How to set variables in rsyslog v7

With rsyslog 7.1.3 we introduced the opportunity to set variables inside the rsyslog.conf. Though, this does not work with standard properties, this can be done with CEE/lumberjack-type properties. Variable customization should be considered an aid for template generation and modification.

Note that CEE/lumberjack properties, as implemented in rsyslog,  can be hierarchical and levels are delimited by the bang sign (based on lumberjack recommendations). So “!uid” is the uid field in the CEE root, whereas “!usr!uid” is the uid field inside the usr container. Nesting can be as deep as desired. Currently, all parts of the CEE tree can be accessed. In later versions, this may require the setting of a global option.

A variable can be set by using the following:

set varname = expression;

Please note the semicolon at the end. This is needed to separate from other config lines as well as to keep compatibility with older versions. The expression can be an arbitrary complex expression, just like in an “if” statement.

Concrete examples:

set $!usr!level2!var1 = "test";  
set $!usr!level2!var1 = $msg; # update variable with native MSG field
set $!usr!level2!var2 = 1+1; # set !usr!level2!var2 = 2
set $!usr!level2 = $fromhost; # invalid

The last example is invalid because it tries to replace a complete container with the content of a single regular property.

There is also an accompanying “unset” statement to remove a variable that is no longer needed. This is primarily meant to restructure a CEE container. It’s syntax simply is:

unset varname;

Again, note the semicolon at the end. A concrete example is

unset !usr!level2!var1;

which removes a single element. But full containers can also be removed:

unset !usr!level2

Note that all variables are assigned to the message currently being processed. There currently is no way to set global variables.

Scroll to top