From b9dc14cb020bdec5ce0fbace2fadce19c98d0501 Mon Sep 17 00:00:00 2001
From: Rainer Gerhards
The name "rsyslog" stems back to the -planned support for syslog-reliable. Ironically, the initial release -of rsyslog did NEITHER support syslog-reliable NOR tcp based syslog. -Instead, it contains enhanced configurability and other enhancements -(like database support). The reason for this is that full support for -RFC 3195 would require even more changes and especially fundamental architectural -changes. Also, questions asked on the loganalysis list and at other -places indicated that RFC3195 is NOT a prime priority for users, but -rather better control over the output format. So here we are, with -a rsyslod that covers a lot of enhancements, but not a single one -of these that made its name ;) Since version 0.9.2, receiving syslog messages -via plain tcp is finally supported, a bit later sending via TCP, too. Starting -with 1.11.0, RFC 3195 is finally support at the receiving side (a.k.a. "listener"). -Support for sending via RFC 3195 is still due. Anyhow, rsyslog has come much -closer to what it name promises.
-The next enhancement scheduled is support for the new syslog-protocol -internet draft format, not the least to see how easy/complicated it is -to implement. We already know that some subleties of syslog-protocol will -require at least one considerable architectural change to the syslogd -and this might delay things a little. Our immediate goal is to receive -feedback and get the bugs out of the current release. Only after that -we intend to advance the code and introduce new features. -
-The database support was included so that our web-based syslog interface -can be used. This is another open source project which can be found -under http://www.phplogcon.org. We highly recommend having a look at -it. It might not work for you if you expect thousands of messages per -second (because your database won't be able to provide adequate performance), -but in many cases it is a very handy analysis and troubleshooting tool. - -
-Rsyslogd supports an enhanced syslog.conf file format, and also works -with the standard syslog.conf. In theory, it should be possible to simply replace -the syslogd binary with the one that comes with rsyslog. Of course, in order -to use any of the new features, you must re-write your syslog.conf. To learn -how to do this, please review our commented sample.conf -file. It outlines the enhancements over stock syslogd. -
If you are interested in the IHE -environment, you might be interested to hear that rsyslog supports message with -sizes of 32k and more. This feature has been tested, but by default is turned off -(as it has some memory footprint that we didn't want to put on users not -actually requiring it). Search the file syslogd.c and search for "IHE" - you -will find easy and precise instructions on what you need to change (it's just -one line of code!). Please note that RFC 3195/COOKED supports 1K message sizes -only. It'll probably support longer messages in the future, but it is our -believe that using larger messages with current RFC 3195 is a violation of the -standard.
Be sure to visit Rainer's syslog block -to get some more insight into the development of rsyslog and syslog in general.
-The name "rsyslog" stems back to the +planned support for syslog-reliable. Ironically, the initial release +of rsyslog did NEITHER support syslog-reliable NOR tcp based syslog. +Instead, it contains enhanced configurability and other enhancements +(like database support). The reason for this is that full support for +RFC 3195 would require even more changes and especially fundamental architectural +changes. Also, questions asked on the loganalysis list and at other +places indicated that RFC3195 is NOT a prime priority for users, but +rather better control over the output format. So here we are, with +a rsyslod that covers a lot of enhancements, but not a single one +of these that made its name ;) Since version 0.9.2, receiving syslog messages +via plain tcp is finally supported, a bit later sending via TCP, too. Starting +with 1.11.0, RFC 3195 is finally support at the receiving side (a.k.a. "listener"). +Support for sending via RFC 3195 is still due. Anyhow, rsyslog has come much +closer to what it name promises.
+The next enhancement scheduled is support for the new syslog-protocol +internet draft format, not the least to see how easy/complicated it is +to implement. We already know that some subleties of syslog-protocol will +require at least one considerable architectural change to the syslogd +and this might delay things a little. Our immediate goal is to receive +feedback and get the bugs out of the current release. Only after that +we intend to advance the code and introduce new features. +
+The database support was included so that our web-based syslog interface +can be used. This is another open source project which can be found +under http://www.phplogcon.org. We highly recommend having a look at +it. It might not work for you if you expect thousands of messages per +second (because your database won't be able to provide adequate performance), +but in many cases it is a very handy analysis and troubleshooting tool. + +
+Rsyslogd supports an enhanced syslog.conf file format, and also works +with the standard syslog.conf. In theory, it should be possible to simply replace +the syslogd binary with the one that comes with rsyslog. Of course, in order +to use any of the new features, you must re-write your syslog.conf. To learn +how to do this, please review our commented sample.conf +file. It outlines the enhancements over stock syslogd. +
If you are interested in the IHE +environment, you might be interested to hear that rsyslog supports message with +sizes of 32k and more. This feature has been tested, but by default is turned off +(as it has some memory footprint that we didn't want to put on users not +actually requiring it). Search the file syslogd.c and search for "IHE" - you +will find easy and precise instructions on what you need to change (it's just +one line of code!). Please note that RFC 3195/COOKED supports 1K message sizes +only. It'll probably support longer messages in the future, but it is our +believe that using larger messages with current RFC 3195 is a violation of the +standard.
In June 2007, Peter Vrabec from Red Hat helped us to create +RPM files for Fedora as well as supporting IPv6. There also seemed to be some +interest from the Red Hat community. This interest and new ideas resulted in a +very busy time with many great additions.
In July 2007, Andrew +Pantyukhin added BSD ports files for rsyslog and liblogging. We were strongly +encouraged by this too. It looks like rsyslog is getting more and more momentum. +Let's see what comes next...
Be sure to visit Rainer's syslog block +to get some more insight into the development of rsyslog and syslog in general.
+Thanks to some volunteers, rsyslog is also available in package form on -some distributions. All available packages are listed below. If you would -like to maintain a package for a new distribution, please mail me at -rgerhards@adiscon.com. Any help is *deeply* -appreciated. While I create the core daemon, the package maintainers are really -filling it with life, making it available to the average user. I am very -grateful for that!
-This list has last been updated on 2006-09-26 by -Rainer Gerhards. -New packages may appear at any time, so be sure to check this page whenever you -need a new one.
-Maintained by James Bergamin.
-Bennet Todd maintains packages that should work on almost any Linux. -He keeps a current i386 tree. There is also a PPC tree, but that one is not paid -much attention for (anyhow, it is known to typically work well, too).
-Please visit -http://bent.latency.net/bent/, select the relevant tree and then do a search -for rsyslog.
- - - + + +Thanks to some volunteers, rsyslog is also available in package form on +some distributions. All available packages are listed below. If you would +like to maintain a package for a new distribution, please mail me at +rgerhards@adiscon.com. Any help is *deeply* +appreciated. While I create the core daemon, the package maintainers are really +filling it with life, making it available to the average user. I am very +grateful for that!
+This list has last been updated on 2007-07-06 by +Rainer Gerhards. +New packages may appear at any time, so be sure to check this page whenever you +need a new one.
+Red Hat has recently begun to build RPMs for rsyslog. The URL changes, but a +good place to look for them is at +freshmeat's rsyslog info page.
+Give +http://www.freshports.org/sysutils/rsyslog/ a try.
+Maintained by James Bergamin.
+Bennet Todd maintains packages that should work on almost any Linux. +He keeps a current i386 tree. There is also a PPC tree, but that one is not paid +much attention for (anyhow, it is known to typically work well, too).
+Please visit +http://bent.latency.net/bent/, select the relevant tree and then do a search +for rsyslog.
+ + + diff --git a/doc/status.html b/doc/status.html index f3deafbf..ade8da15 100644 --- a/doc/status.html +++ b/doc/status.html @@ -4,12 +4,12 @@This page reflects the status as of 2007-07-05.
+This page reflects the status as of 2007-07-10.
development: 1.15.0 - change log - -download
-stable: 1.0.4 - change log - -download
+development: 1.15.1 - change log - +download
+stable: 1.0.5 - change log - +download