rsyslog 8.2.0 (v8-stable) released
This is the first release of the greatly improved version 8 of rsyslog. Large parts of the core engine have been rewritten in order to support even greater performance and newly things like global variable support in RainerScript. The new engine is the foundation for the next couple of years of rsyslog technology. As another major design feature, an interface for external plugins has been added. Version 8.2 supports external output plugins, but external message modification and input plugins are also schedule to appear soon.
With the release of version 8, 7.6 is being as officially supported stable. However, we will support 7.6 for some while. So there is no urgent need to upgrade to v8.
ChangeLog:
http://www.rsyslog.com/changelog-for-8-2-0-v8-stable/
Download:
http://www.rsyslog.com/downloads/download-v8-stable/
As always, feedback is appreciated.
Best regards,
Florian Riedl
Changelog for 8.2.0 (v8-stable)
Version 8.2.0 [v8-stable] 2014-04-02
This starts a new stable branch based on 8.1.6 plus the following changes:
- we now use doc from the rsyslog-doc project
As such, the ./doc subtree has been removed. Instead, a cache of the rsyslog-doc project’s files has been included in ./rsyslog-doc.tar.gz. Note that the exact distribution mode for the doc is still under discussion and may change in future releases. This was agreed upon on the rsyslog mailing list. For doc issues and corrections, be sure to work with the rsyslog-doc project. It is currently hosted at https://github.com/rsyslog/rsyslog-doc - add support for specifying the liblogging-stdlog channel spec
new global parameter “stdlog.channelspec” - add “
defaultnetstreamdrivercertfile” global variable to set a default for the certfile.
Thanks to Radu Gheorghe for the patch. - omelasticsearch: add new “usehttps” parameter for secured connections
Thanks to Radu Gheorghe for the patch. - “action resumed” message now also specifies module type which makes troubleshooting a bit easier. Note that we cannot output all the config details (like destination etc) as this would require much more elaborate code changes, which we at least do not like to do in the stable version.
- add capability to override GnuTLS path in build process
Thanks to Clayton Shotwell for the patch - better and more consistent action naming, action queues now always contain the word “queue” after the action name
- bugfix: ompipe did resume itself even when it was still in error
See: https://github.com/rsyslog/rsyslog/issues/35
Thanks to github user schplat for reporting
rsyslog 7.6.3 (v7-stable) released
This release offers a couple of bug-fixes and also supports better interaction with librelp 1.2.5, which in turn supports anonymous TLS on platforms like CENTOS/RHEL 6 where GnuTLS is too old and RELP TLS was completely disable previously.
ChangeLog:
http://www.rsyslog.com/changelog-for-7-6-3-v7-stable/
Download:
http://www.rsyslog.com/downloads/download-v7-stable/
As always, feedback is appreciated.
Best regards,
Florian Riedl
Changelog for 7.6.3 (v7-stable)
Version 7.6.3 [v7.6-stable] 2014-03-27
- add capability to override GnuTLS path in build process
Thanks to Clayton Shotwell for the patch - support for librelp 1.2.5
Support new return states of librelp 1.2.5 to emit better error messages. For obvious reasons, librelp 1.2.5 is now required. - bugfix: ompipe used invalid default template
This is a regression from an old change (didn’t track it down precisely, but over a year ago). It used the Forwarding template instead of the file template (so we have a full syslog header). This fix corrects it back to previous behaviour, but new scripts that used the wrong format may now need to have the RSYSLOG_ForwardingFormat template explicitely be applied.
closes: https://github.com/rsyslog/rsyslog/issues/50 - bugfix: ompipe did emit many suspension messages for /dev/xconsole
(hopefully now) closes: https://github.com/rsyslog/rsyslog/issues/35
When it was present, but nobody reading from it. The problem is the way the rsyslog v7 engine tries to resolve failures in outputs. It does some retries, and along those lines some state information gets lost and it is close to impossible to retain it. However, the actual root problem is that ompipe does not reliably detect if it is able to recover. The problem here is that it actually does not know this before it does an actual write. These two things together mess up the logic that suppresses invalid resumption/suspension messages (actually, the plugin switches state really that often). Nevertheless, the prime problem with /dev/xconsole (and probably most other pipes as well) is that it gets full. So I have now added code that checks, during resume processing, if the pipe is writable. If it is not, resume is deferred. That should address the case.