diff options
Diffstat (limited to 'doc/history.html')
| -rw-r--r-- | doc/history.html | 154 |
1 files changed, 80 insertions, 74 deletions
diff --git a/doc/history.html b/doc/history.html index 91ee4909..02dec93c 100644 --- a/doc/history.html +++ b/doc/history.html @@ -1,75 +1,81 @@ -<html>
-<head>
-<title>rsyslog history</title>
-</head>
-<body>
-<h1>RSyslog - History</h1>
-
-<b>Rsyslog is a GPL-ed, enhanced syslogd. Among others, it offers support for
-reliable syslog over TCP, writing to
-MySQL databases and fully configurable output formats (including great timestamps).</b>
-Rsyslog was initiated by Rainer Gerhards. It has
-been forked from the <a href="http://www.infodrom.org/projects/sysklogd/">sysklogd standard package</a>.
-The goal of the
-rsyslog project is to provide a more configurable and reliable
-syslog deamon while retaining drop-in replacement capabilities for stock syslogd. By "reliable", we mean support for reliable transmission
-modes like TCP or <a href="http://www.monitorware.com/Common/en/glossary/rfc3195.php">RFC 3195</a> (syslog-reliable).
-We do NOT imply that the sysklogd package is unreliable. In fact, the
-opposite is the case and we assume that for the time being the well-used
-sysklogd package offers better program reliability than our
-brand-new modifications to it.
-
-</p><p>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.</p><p>
-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.
-</p><p>
-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 <a href="http://www.phplogcon.org">http://www.phplogcon.org</a>. 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.
-
-</p>
-<p>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 <a href="sample.conf.php">sample.conf</a>
-file. It outlines the enhancements over stock syslogd.
-<p>If you are interested in the <a href="http://en.wikipedia.org/wiki/IHE">IHE</a>
-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.<p>Be sure to visit Rainer's <a href="http://rgerhards.blogspot.com/">syslog block</a>
-to get some more insight into the development of rsyslog and syslog in general.</p>
-<h2>Some useful links</h2>
-<ul>
- <li><a href="http://www.rsyslog.com/Topic4.phtml">the rsyslog change log</a></li>
-</ul>
-</body>
+<html> +<head> +<title>rsyslog history</title> +</head> +<body> +<h1>RSyslog - History</h1> + +<b>Rsyslog is a GPL-ed, enhanced syslogd. Among others, it offers support for +reliable syslog over TCP, writing to +MySQL databases and fully configurable output formats (including great timestamps).</b> +Rsyslog was initiated by Rainer Gerhards. It has +been forked from the <a href="http://www.infodrom.org/projects/sysklogd/">sysklogd standard package</a>. +The goal of the +rsyslog project is to provide a more configurable and reliable +syslog deamon while retaining drop-in replacement capabilities for stock syslogd. By "reliable", we mean support for reliable transmission +modes like TCP or <a href="http://www.monitorware.com/Common/en/glossary/rfc3195.php">RFC 3195</a> (syslog-reliable). +We do NOT imply that the sysklogd package is unreliable. In fact, the +opposite is the case and we assume that for the time being the well-used +sysklogd package offers better program reliability than our +brand-new modifications to it. + +</p><p>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.</p><p> +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. +</p><p> +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 <a href="http://www.phplogcon.org">http://www.phplogcon.org</a>. 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. + +</p> +<p>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 <a href="sample.conf.php">sample.conf</a> +file. It outlines the enhancements over stock syslogd. +<p>If you are interested in the <a href="http://en.wikipedia.org/wiki/IHE">IHE</a> +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.<p>In <b>June 2007</b>, 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.<p>In <b>July 2007</b>, 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...<p>Be sure to visit Rainer's <a href="http://rgerhards.blogspot.com/">syslog block</a> +to get some more insight into the development of rsyslog and syslog in general.</p> +<h2>Some useful links</h2> +<ul> + <li><a href="http://www.rsyslog.com/Topic4.phtml">the rsyslog change log</a></li> +</ul> +</body> </html>
\ No newline at end of file |