There are 69 unlogged users and 0 registered users online.
You are an anonymous user. You can register for free by clicking here
Rsyslog, the enhanced syslogd for Linux and Unix
Rsyslog is an enhanced multi-threaded syslogd supporting, among others, MySQL, syslog/tcp, RFC 3195, permitted sender lists, filtering on any message part, and fine grain output format control. It is quite compatible to stock sysklogd and can be used as a drop-in replacement. Its advanced features make it suitable for enterprise-class, encryption protected syslog relay chains while at the same time being very easy to setup for the novice user. An optional web interface - phpLogCon - can be used to visualize all data online. In November 2007, rsyslog has become the default syslogd for the Fedora project.
We have just released rsyslog 3.19.1, an update of the development branch. This version primarily fixes some problems with the build system. There were some files missing, which could result in strange warnings. Also, some minor code cleanup to get rid of some compiler warnings is included. This version is highly recommended for all users of the development branch. Note, however, that it is still not suitable for use on production machines.
It is the first release that natively supports TLS for plain TCP syslog. Actually, it is the world's first implementation of the upcoming syslog-transport-tls IETF standard. As this standard is not yet finished, the implementation is obviously experimental.
Native TLS is a big improvement over existing functionality. For example, rsyslog can now be used without the help of stunnel, which relieves us of some problems from those configurations. To the best of my knowledge, rsyslog is the first open-source syslogd offering TLS support natively.
The current TLS functionality is limited to the bare minimum. During the next few weeks, I will improve it based on my own spec and feedback (hopefully received). My hope is to have a production-grade implementation by summer at latest. Please note rsyslog's premium and ultra-reliable RELP protocol does not yet support TLS (but can be used with stunnel without the real problems legacy tcp had with it). My plan is to let TLS mature with legacy syslog and then move it to RELP. Thus I can limit my development to one major use case, which I think will facilitate things.
There is some documentation on how to use the new TLS mode:
Currently, TLS is provided via GnuTLS. As I outlined earlier on the list, GnuTLS offered much more support to getting started (documentation and sample-code wise). I will focus on GnuTLS until I am fully satisfied with the TLS implementation). I'll then see that I can also integrate NSS. Advise in this regard would be highly welcome, so if you have some knowledge in this area, please contribute.
In order to support TLS (and multiple libraries!), a major rewrite of the networking components has been done. Rsyslog now supports a so-called "network streams" (netstreams) driver interface. This interface enables app-level functionality (like the legacy tcp syslog sender and receiver) to work with dynamically selectable netstream drivers (like plain (unencrypted) TCP) and TLS). This interface will enable rsyslog to utilize other TLS drivers (and even other protocols) in the future. Different drivers can even be used concurrently.
Rsyslog now has been split into a runtime system and tools (with currently rsyslogd being the only tool). This design will further strengthen modularization and help make rsyslog functionality available in small parts.
Finally, the RFC 3195 input has been rewritten in the form of an input plugin. It can now be build as part of the normal build procedure.
Please note that there were a couple of major changes. I expect the initial 3.19.0 to be quite Unstable. I recommend it for testing environments, only. Even those parts that were not directly touched may have become a bit destabilized due to the runtime split. So please use it with care. Feedback, however, would be more than welcome, because I need to start somewhere to stabilize this release. That can only be done with your help. So please use it on test systems, try to break it and file bug reports when it fails.
We have just released rsyslog 3.16.1, a release of the v3-stable branch. This version contains one important bug fix. The imklog input plugin did not correctly start up in some environments and could even cause a segfault. This is now corrected. Upgrading to 3.16.1 is strongly recommended for all users of the v3-stable branch who use imklog.
Version 2.1.0 is the first beta version of the v2 branch. PhpLogCon has been completely rewritten from scratch. It now offers a state-of-the art modern user interface and also is able to work with log files and not just databases. For example, it can be used to view a remote server's log files over the web (proper authentication settings highly recommended).
I have just released rsyslog 3.16.0, a v3-stable release. This release brings a major new feature, RELP support, to the stable branch. RELP enables lossless transmission of syslog messages, in cases where even plain tcp syslog fails. Other than that, the release contains a few bugfixes.
Users of the v3-stable branch are advised to update to the new release.
Rsyslog 3.17.1 has just been released. The primary new feature is full BSD platform support. Rsyslog now not only compiles cleanly on BSD, but also now supports BSD's kernel log natively. In general, kernel logging has been improved and better documented. High-precision timestamps for the kernel log have been enabled. There are also some minor other enhancements as well as a couple of bug fixes. Rsyslog 3.17.1 is a recommended update for all users of the devel branch.
I have just released 3.14.2, an update to v3-stable. It is a purely bug-fixing release. Most importantly, it fixes a problem that caused imklog not to pull module symbols correctly from recent kernels. Also, a segfault caused by using expression-based filters is fixed. There are also some other fixes, see ChangeLog for details. This is a recommended update for all v3-stable branch users.
rsyslog 3.15.1 has been released. This is a refresh of the beta branch, providing new bug fixes. The beta branch currently features the RELP protocol and will be the next v3-stable once it has sufficiently matured.
rsyslog 3.17.0 has just been released. It is part of the development branch. The primary new feature is the ability to send email alerts based on syslog or file data. The action engine now has the ability to carry out an action only once within a configured interval and/or only during specific time frames. Option processing has been improved and a number of stability updates have been included. This is a recommended update for all users of the development version.
More information on the major new feature can be found here:
The following is a sample code snippet that alerts the operator when disk problems are detected:
$ModLoad ommail
$ActionMailSMTPServer mail.example.net
$ActionMailFrom rsyslog@example.net
$ActionMailTo operator@example.net
$template mailSubject,"disk problem on %hostname%"
$template mailBody,"RSYSLOG Alert\r\nmsg='%msg%'"
$ActionMailSubject mailSubject
# make sure we receive a mail only once in six
# hours (21,600 seconds ;))
$ActionExecOnlyOnceEveryInterval 21600
# the if ... then ... mailBody mus be on one line!
if $msg contains 'hard disk fatal failure' then :ommail:;mailBody
Note that we now have the ability to limit an action to be executed only once inside a specific period. In the above sample, the email alert happens only if there was no other such alert within the past 6 hours - this is absolutely vital to prevent an accidental DoS on your mailbox ;) ... but it may also be handy with other actions (e.g. SNMP trap notification etc etc). It's implemented at the action engine level, so it will work with any action, even file or database writes.
I would be most interested in feedback on the new email feature, including clever use cases. I am sure it can be quite useful (especially if you think about imfile...), but would really appreciate to hear from you (and prove this in practice)!
I am glad to finally announce rsyslog 3.14.1, the first version of the v3 stable branch.
This version offers almost all features of the current development version to those in need of a stable branch. Among others, this includes support for multiple database backends, queued and offline operations, SNMP and text file support. It is a big step compared to the v2 stable branch. Users are advised to check the compatibility notes before the update. It's not strictly necessary, but will enable to use rsyslog in the most efficient and problem-free way.
Please note that development continues inside the v3 branch. The v3 stable branch will see future feature enhancements after they have sufficiently matured. The v2 stable branch is still supported. It is quite featureless (compared to v3) but extremely solid. So if you are (or need to be) ultra-conservative, you can still take the v2 route. Feature-wise v2 is a dead end and only bug fixes will be provided.
The general recommendation is that the v3 stable branch be used for regular production machines. The Fedora project will feature rsyslog v3 stable in its upcoming release 9.
Please note that I made a mistake two days ago: I accidently released 3.14.0 to the web, without it being actually ready. For this reason, I have renamed the release to 3.14.1. There will never be an official 3.14.0 release. If you happen to have it downloaded and installed, please accept my apologies. You should get 3.14.1 whenever you are ready.
