News

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.

rsyslog 5.8.6 (v5-stable) released

This is a maintenance release offering bug fixes. For example for a small bug in property-based filter and a fix for $ActionExecOnlyOnce and more .For more detailed information, please read the changelog.

ChangeLog:

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

Download:

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

As always, feedback is appreciated.

Best regards,

Tim Eifler

rsyslog 6.3.6 (v6-devel) released

We have just released a new development version of rsyslog v6. This is primarily a maintenance release fixing a really annoying problem with reading the config file.

ChangeLog:

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

Download:

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

As always, feedback is appreciated.

Best regards,
Florian Riedl

rsyslog 4.8.0 (v4-stable) released

There are no changes compared to 4.7.5, just a re-release with the new version number as new v4-stable. The most important new feature (for the v4-stable branch!) is Solaris support.

Note: major new development to v4 is concluded  and will only be done for custom projects.

ChangeLog:

http://www.rsyslog.com/changelog-for-4-8-0-v4-stable/

Download:

http://www.rsyslog.com/rsyslog-4-8-0-v4-stable/

As always, feedback is appreciated.

Best regards,
Tim Eifler

rsyslog multiple buxfixes released

Hi all,

There has a security issue been identified that can potentially lead to DoS. It is triggered by malformed RFC3164 messages. An abort only happens under very specific environmental trigger factors. Full details can be found in our security advisory here:

http://www.rsyslog.com/potential-dos-with-malformed-tag/

We would like to thank the Red Hat security team for finding this issue and working with us to resolve it.

As a consequence, we have updated all currently active versions. Please note that they do not only contain the fix for the security issue mentioned above but also other stability updates. For obvious reasons, updating to these versions is recommended. For details, please see the relevant ChangeLog.

  • v4-stable: 4.6.8
  • v4-beta: 4.7.5
  • v5-stable: 5.8.5
  • v5-devel: 5.9.3
  • v6-beta: 6.1.12
  • v6-devel: 6.3.5

All versions are available right now. If you do not want to update, you should consider applying an update to older versions. The fix is trivial, so it should apply to all vulnerable versions without problems (but we have not checked the myriad of versions out there). The security advisory contains the details.

The Changelogs and Download Links can be found below:

As always, feedback is appreciated.

Best regards,
Florian Riedl

Scroll to top