News

Rsyslog Windows Agent Released

The rsyslog Windows agent enables customers to integrate Windows Event Logs into their central rsyslog-based logging system. Even more, it supports acting as a syslog relay as well. This enables small branch offices only runnig Windows to provide local syslog sources to the central server as well.

We have released the first full-featured version of this product today. It is based on Adiscon’s mature suite of Windows-to-syslog tools.  Most importantly, it provides the ability to fully extract Windows Event Log data, including local resolution of user IDs, SIDs, GUIDs and similiar objects. It not only supports the current Windows Event Log format but  also the legacy (pre Windows-2008/Vista) event log system. The technology behind this tool is already in use at thousands of customer sites for many years (in the form of, for example, EventReporter and other Adiscon products).

The rsyslog Agent for Windows has been highly optimized for use with rsyslog at the back end. For example, it supports mutually-authenticated, TLS encrypted syslog as well as the RELP protocol for reliable delivery. Also, it provides an initial implementation of cee-enhanced syslog, and is the world’s first-ever solution to do so (details can be found in the configuration guide for cee-enhanced syslog).

By purchasing rsyslog Agent for Windows customers not only get first class event log integration, they also help fund further improving the rsyslog solution as whole. The package even contains limited rsyslog professional services.

A trial version can be downloaded from the rsyslog Windows agent page.

rsyslog 5.8.8 (v5-stable) released

This is a bug-fixing release. It fixes the wrong computed facility and severity in imklog and a problem with rsyslog aborting on startup if no binary to execute was configured for omprog.

ChangeLog:

http://www.rsyslog.com/changelog-for-5-8-8-v5-stable/

Download:

http://www.rsyslog.com/rsyslog-5-8-8-v5-stable/

As always, feedback is appreciated.

Best regards,

Florian Riedl

rsyslog 6.3.7 (v6-devel) released

With this release, all builtin actions support the new v6 config format. Also, the release contains much enhanced statistics counters and various bug fixes. Recommended for all users of the v6-devel branch.

ChangeLog:

http://www.rsyslog.com/changelog-for-6-3-7-v6-devel/

Download:

http://www.rsyslog.com/rsyslog-6-3-7-v6-devel/

As always, feedback is appreciated.

Best regards,
Florian Riedl

rsyslog 5.9.5 (v5-devel) released

This release brings many additional statistics counters and a couple of bug fixes. Note that the default setting of $IMUxSockRateLimitInterval was changed to 0, as rate limiting seems to have caused more trouble than it was worth. To enable it, simply set it to 200, the previous default.

ChangeLog:

http://www.rsyslog.com/changelog-for-5-9-5-v5-devel/

Download:

http://www.rsyslog.com/rsyslog-5-9-5-devel/

As always, feedback is appreciated.

Best regards,
Tim Eifler

rsyslog 5.8.7 (v5-stable) released

This is a bug-fixing release. The most important patches resolve instabilities with RFC5424 header fields and information loss when non-wellformed messages are submitted to the system log socket.

ChangeLog:

http://www.rsyslog.com/changelog-for-5-8-7-v5-stable/

Download:

http://www.rsyslog.com/rsyslog-5-8-7-v5-stable/

As always, feedback is appreciated.

Best regards,

Tim Eifler

rsyslog 6.2.0 (v6-stable) released

This is the initial stable release of rsyslog v6. It is basically the last beta version plus some more fixes. This version provides functional and performance enhancements, for example the Hadoop (HDFS) support has been considerably speeded up by supporting batched insert mode. Also, TCP transmission overhead for TLS has been dramatically improved. TCP now also supports input worker thread pools. Most importantly, rsyslog now supports log normalization via liblognorm rule bases. This permits very high performance normalization of semantically equal messages from different devices (and thus in different syntaxes).

Note that config scoping, available in the beta versions, is NOT supported by v6-stable. This was decided because it would have been functionality equivalent to the new config language upcoming in v6.3 (already available as part of the devel version). As scoping was not available in any earlier versions, introducing it in v6.2 would have added, in the long term, just another method of doing some identicaly thing via the ugly old config language. This would have lead to user confusion and more complex than necessary code. If you are interested in the cleaner config language, we strongly encourage you to have a look at rsyslog 6.3.

With the arrival of the stable v6 version, version 4 will be retired and is no longer officially supported (but support is provided under maintenance contracts, of course).

ChangeLog:

http://www.rsyslog.com/changelog-for-6-2-0-v6-stable/

Download:

http://www.rsyslog.com/rsyslog-6-2-0-v6-stable/

As always, feedback is appreciated.

Best regards,
Florian Riedl

LogTools 0.1.0 Released

We are happy to announce the initial public release of LogTools. This package aims at providing useful tools for log file manipulation and processing. The initial release focuses on a core ingredient, the tamper-proof log store. Besides that, the well-documented format is designed for long-term archiving. Both features together make it very useful for storing both valuable audit information as well as log files potentially meant as evidence in court.

Both the source tarball and an experimental Debian package are available via the LogTools download page.

The log store is tamper-proof by using a chain of hashes. This provides tamper protection if the last hash of the hash chain is regularly saved. In upcoming releases, the hash chain will become protected by digital signatures using strong cryptography. With that, it is no longer necessary (but still beneficial) to keep hashes in a separate location (that would guard even against a compromised key).

The log store is long-term-archival-friendly because its documented format is designed to remain easy to read and interpret even in many years: it is text-based, clearly documented (in the man page or, for example, here) and easily extensible. To support extensibility, it supports different record types and a cryptographic field that can be extended by type specifiers as well (this is not used initially because it is not needed – but the capability is already present). It is our pledge that this format will remain readable while it is being extended in the future.

So LogStore format is a perfect solution for tamper-protected texttual data that must last. And note that we say “textual data”, not “syslog messages” or even “log messages”. No matter what it is, if it is in text format, LogStore can protect it!

LogTools are also a good Linux citizen, following the Unix tradition of small tools that do one job and do it well. With the initial release, two filter-type programs (logreader and logwriter) have been released. They permit to create and read log stores (including a functionality to extract the last used hash for easy transmission). These tools can perfectly be used inside processing pipes. That, among others, means that LogStore data is perfectly “greppable”. Integration with other tools is simple. For example, to make rsyslog write LogStore format, rsyslog’s omprog output module can be utilized. All tools that can emit data to stdout can also be used to write LogStore format. So immediately there is a myriad of options available.

LogTools is an active project that will be further extend with new tools with the same philosophy. One of the next steps planned is to integrate liblognorm techology for easy normalization of incoming semi-structured data. We also appreciate suggestions, so please make yourself heard.

rsyslog 5.9.4 (devel) released

This release provides support for “trusted properties”, which may enhance overall system security. This is a new concept and feedback on it is appreciated. For more details on trusted properties, please visit

http://www.rsyslog.com/what-are-trusted-properties/

or Rainer’s blog post with some more background about trusted properties:

http://blog.gerhards.net/2011/11/trusted-properties-in-rsyslog.html

In addition to this feature, we have reduced dependency on libgcrypt and fixed some bugs.

ChangeLog:

http://www.rsyslog.com/changelog-for-5-9-4-v5-devel/

Download:

http://www.rsyslog.com/rsyslog-5-9-4-devel/

As always, feedback is appreciated.

Best regards,
Florian Riedl

First Impression of Journald

We got a couple of questions on the planned new logging system that shall come with systemd. Rainer Gerhards, rsyslog’s development lead, has taken a quick look at journald and posted about his first impression. Have a look at his blog post journal and rsyslog if you are interested in how we think rsyslog is affected. In the mean time, there is also a description of why we think journald’s log chaining is simply broken and conveys a false sense of security.

rsyslog client for Windows

As it currently looks, Adiscon will most probably create a specialised Windows client for rsyslog. This will be based on Adiscon’s MonitorWare technology and provide excellent and high speed integration of Windows clients into a rsyslog infrastructure. While the idea has somewhat matured, we are currently thinking about the details. Expect more information as discussions progress!

In the mean time, you may want to have a look at Adiscon’s EventReporter, which provides excellent Windows-to-rsyslog event log forwarding.

Scroll to top