diff options
| author | Rainer Gerhards <rgerhards@adiscon.com> | 2008-02-21 09:41:56 +0000 |
|---|---|---|
| committer | Rainer Gerhards <rgerhards@adiscon.com> | 2008-02-21 09:41:56 +0000 |
| commit | 227c44dbe0f3ce8ab465829c2d6114d5e6b38470 (patch) | |
| tree | a15b84c5f20af5ac42687424e71fd20c5e61ad14 /doc/v3compatibility.html | |
| parent | 4ff521048dbab0557c863c28321693e1f31c6a96 (diff) | |
| download | rsyslog-227c44dbe0f3ce8ab465829c2d6114d5e6b38470.tar.gz rsyslog-227c44dbe0f3ce8ab465829c2d6114d5e6b38470.tar.xz rsyslog-227c44dbe0f3ce8ab465829c2d6114d5e6b38470.zip | |
cleanup for 3.11.4v3-11-4
Diffstat (limited to 'doc/v3compatibility.html')
| -rw-r--r-- | doc/v3compatibility.html | 196 |
1 files changed, 108 insertions, 88 deletions
diff --git a/doc/v3compatibility.html b/doc/v3compatibility.html index 4a391f97..221d8302 100644 --- a/doc/v3compatibility.html +++ b/doc/v3compatibility.html @@ -1,119 +1,139 @@ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html><head> +<html><head><title>Compatibility notes for rsyslog v3</title> -<title>Writing syslog Data to MySQL</title><meta name="KEYWORDS" content="syslog, mysql, syslog to mysql, howto"></head><body> +<meta name="KEYWORDS" content="syslog, mysql, syslog to mysql, howto"> +</head><body> <h1>Compatibility notes for rsyslog v3</h1> - <p><small><i>Written by - <a href="http://www.gerhards.net/rainer">Rainer - Gerhards</a> (2007-12-17)</i></small></p> -<p>Rsyslog aims to be a drop-in replacement for sysklogd. However, version 3 has -some considerable enhancements, which lead to some backward compatibility issues -both in regard to sysklogd and rsyslog v1 and v2.</p> -<p>Rsyslog v3 is currently under initial development. Compatibility issues may -be resolved, so be sure to check back often. Also, comments and suggestions are -appreciated. Feedback right in time can now have a big impact on the route we -take ;)</p> +<p><small><i>Written by <a href="http://www.gerhards.net/rainer">Rainer Gerhards</a> +(2007-12-17)</i></small></p> +<p>Rsyslog aims to be a drop-in replacement for sysklogd. +However, version 3 has some considerable enhancements, which lead to +some backward compatibility issues both in regard to sysklogd and +rsyslog v1 and v2.</p> +<p>Rsyslog v3 is currently under initial development. +Compatibility issues may be resolved, so be sure to check back often. +Also, comments and suggestions are appreciated. Feedback right in time +can now have a big impact on the route we take ;)</p> <h2>inputs</h2> -<p>With v2 and below, inputs were automatically started together with rsyslog. -In v3, inputs are optional! They come in the form of plug-in modules. -<font color="#ff0000"><b>At least one input module must be loaded to make -rsyslog do any useful work.</b></font> The config file directives doc briefly -lists which config statements are available by which modules.</p> -<p>It is suggested that input modules be loaded in the top part of the config -file. Here is an example, also highlighting the most important modules:</p> -<p><b>$ModLoad immark.so # provides --MARK-- message capability<br> +<p>With v2 and below, inputs were automatically started together +with rsyslog. In v3, inputs are optional! They come in the form of +plug-in modules. +<font color="#ff0000"><b>At least one input module +must be loaded to make rsyslog do any useful work.</b></font> +The config file directives doc briefly lists which config statements +are available by which modules.</p> +<p>It is suggested that input modules be loaded in the top part +of the config file. Here is an example, also highlighting the most +important modules:</p> +<p><b>$ModLoad immark.so # provides --MARK-- +message capability<br> $ModLoad imudp.so # provides UDP syslog reception<br> -$ModLoad imtcp.so # provides TCP syslog reception and GSS-API (if compiled -to support it)<br> -$ModLoad imuxsock.so # provides support for local system logging (e.g. via -logger command)<br> -$ModLoad imklog.so # provides kernel logging support (previously done by rklogd)</b></p> +$ModLoad imtcp.so # provides TCP syslog reception and GSS-API +(if compiled to support it)<br> +$ModLoad imuxsock.so # provides support for local system logging (e.g. +via logger command)<br> +$ModLoad imklog.so # provides kernel logging support (previously done +by rklogd)</b></p> <h2>command line options</h2> -<p>A number of command line options have been removed. New config file -directives have been added for them. Once we implement compatibiltiy mode, these -options will return, but only if running in non-v3-native mode.</p> +<p>A number of command line options have been removed. New config +file directives have been added for them. Once we implement +compatibiltiy mode, these options will return, but only if running in +non-v3-native mode.</p> <h2>-m command line option</h2> -<p>The -m command line option is ignored for the time being. There is no default -mark period. If you need a 20 minute mark period you need to</p> +<p>The -m command line option is ignored for the time being. +There is no default mark period. If you need a 20 minute mark period +you need to</p> <p><b>$ModLoad immark.so # wherever this is<br> $MarkMessageInterval 1800 # 30 minutes</b></p> <h2>-r command line option</h2> -<p>Is also no longer available. Use the <b>$UDPSeverRun <port></b> config file -directives. You can now also set the local address the server should listen to -via <b>$UDPServerAddress <ip></b> config directive.</p> -<p>The following example configures an UDP syslog server at the local address -192.0.2.1 on port 514:</p> +<p>Is also no longer available. Use the <b>$UDPSeverRun +<port></b> config file directives. You can now also +set the local address the server should listen to via <b>$UDPServerAddress +<ip></b> config directive.</p> +<p>The following example configures an UDP syslog server at the +local address 192.0.2.1 on port 514:</p> <p><b>$ModLoad imudp.so<br> -$UDPSeverAddress 192.0.2.1 # this MUST be before the $UDPServerRun directive!<br> +$UDPSeverAddress 192.0.2.1 # this MUST be before the $UDPServerRun +directive!<br> $UDPServerRun 514</b></p> -<p>"$UDPServerAddress *" means listen on all local interfaces. This is the -default if no directive is specified.</p> -<p>Please note that now multiple listeners are supported. For example, you can -do the following:</p> +<p>"$UDPServerAddress *" means listen on all local interfaces. +This is the default if no directive is specified.</p> +<p>Please note that now multiple listeners are supported. For +example, you can do the following:</p> <p><b>$ModLoad imudp.so<br> -$UDPSeverAddress 192.0.2.1 # this MUST be before the $UDPServerRun directive!<br> +$UDPSeverAddress 192.0.2.1 # this MUST be before the $UDPServerRun +directive!<br> $UDPServerRun 514<br> $UDPSeverAddress * # all local interfaces<br> $UDPServerRun 1514</b></p> -<p>These config file settings run two listeners: one at192.0.2.1:514 and one on -port 1514, which listens on all local interfaces.</p> +<p>These config file settings run two listeners: one +at192.0.2.1:514 and one on port 1514, which listens on all local +interfaces.</p> <h2>Default port for UDP (and TCP) Servers</h2> -<p>Please note that with pre-v3 rsyslogd, a service database lookup was made -when a UDP server was started and no port was configured. Only if that failed, -the IANA default of 514 was used. For TCP serves, this lookup was never done and -514 always used if no specific port was configured. For consitency, both TCP and -UDP now use port 514 as default. If a lookup is desired, you need to specify it -in the "Run" directive, e.g. "<i>$UDPServerRun syslog</i>".</p> +<p>Please note that with pre-v3 rsyslogd, a service database +lookup was made when a UDP server was started and no port was +configured. Only if that failed, the IANA default of 514 was used. For +TCP serves, this lookup was never done and 514 always used if no +specific port was configured. For consitency, both TCP and UDP now use +port 514 as default. If a lookup is desired, you need to specify it in +the "Run" directive, e.g. "<i>$UDPServerRun syslog</i>".</p> <h2>klogd</h2> -<p>klogd has (finally) been replaced by a loadable input module. To enable klogd -functionality, do</p> +<p>klogd has (finally) been replaced by a loadable input module. +To enable klogd functionality, do</p> <p><b>$ModLoad imklog.so</b></p> -<p>A limited set of klogd command line settings is now supported via -rsyslog.conf. That set of configuration directives is to be expanded. So far, we -support:</p> +<p>A limited set of klogd command line settings is now supported +via rsyslog.conf. That set of configuration directives is to be +expanded. So far, we support:</p> <p>$klogSymbolsTwice [on/off]<br> $DebugPrintKernelSymbols [on/off] # spits *a lot* of messages at startup</p> <h2>Queue Modes for the Main Message Queue</h2> -<p>Either "FixedArray" or "LinkedList" is recommended. "Direct" is available, -but should not be used except for a very good reason ("Direct" disables queueing -and will potentially lead to message loss on the input side).</p> +<p>Either "FixedArray" or "LinkedList" is recommended. "Direct" +is available, but should not be used except for a very good reason +("Direct" disables queueing and will potentially lead to message loss +on the input side).</p> <h1>TODO List</h1> -<p>I have decided to move the todo list for v3 also into this document. After -all, it is kind of a compatibility issue ;) But, more seriously, I think this is -a good place to make sure nothing is forgotten. Remember that as of now, rsyslog -v3 is in its early stage of development and so there definitely are some nits -that will give you grief. This section here tells you what it is.</p> +<p>I have decided to move the todo list for v3 also into this +document. After all, it is kind of a compatibility issue ;) But, more +seriously, I think this is a good place to make sure nothing is +forgotten. Remember that as of now, rsyslog v3 is in its early stage of +development and so there definitely are some nits that will give you +grief. This section here tells you what it is.</p> <h2>-c option</h2> -<p>needs to be implemented. So far, only -c3 is supported. Everything else does -not change anything but just provides a warning message. In short: there is no -backwards compatibility yet.</p> +<p>needs to be implemented. So far, only -c3 is supported. +Everything else does not change anything but just provides a warning +message. In short: there is no backwards compatibility yet.</p> <h2>Thread Termination</h2> -<p>Thread termination in mode 1 needs to be looked at. I begin to think that it -is OK if we simply cancel the thread, because we already have a different -cleanup function. Otherwise, there is a potential for a race condition after we -unblocked the TermOK mutex but before select() is entered. If the signal then -occurs, we may have a problem. However, I would like to create the other input -modules first so that I have more working experience with termination -requirements. Again, I think this will lead to changes in thread termination.</p> -<p>So far, this issue is resolved, but there is still some code present that -needs to go away (right now disabled). I keep it in because I will make the -final decision based on experience gained during creation of input modules.</p> +<p>Thread termination in mode 1 needs to be looked at. I begin to +think that it is OK if we simply cancel the thread, because we already +have a different cleanup function. Otherwise, there is a potential for +a race condition after we unblocked the TermOK mutex but before +select() is entered. If the signal then occurs, we may have a problem. +However, I would like to create the other input modules first so that I +have more working experience with termination requirements. Again, I +think this will lead to changes in thread termination.</p> +<p>So far, this issue is resolved, but there is still some code +present that needs to go away (right now disabled). I keep it in +because I will make the final decision based on experience gained +during creation of input modules.</p> <h2>Call Encapsulation</h2> -<p>In an ideal world, the modules should call back only to some well-defined and -specifically exported interface functions. Right now, we do not have an ideal -world and the input modules make some calls back into the core. This needs to be -re-thought but is accepted for the time being.</p> +<p>In an ideal world, the modules should call back only to some +well-defined and specifically exported interface functions. Right now, +we do not have an ideal world and the input modules make some calls +back into the core. This needs to be re-thought but is accepted for the +time being.</p> <h2>No real Modules yet</h2> -<p>As already said in "Call Encapsulation", the modules look like such, but are -not really able to work stand alone. The worst in this regard are</p> +<p>As already said in "Call Encapsulation", the modules look like +such, but are not really able to work stand alone. The worst in this +regard are</p> <ul> - <li>imudp/omfwd/syslogd.c</li> - <li>imtcp</li> +<li>imudp/omfwd/syslogd.c</li> +<li>imtcp</li> </ul> -<p>But the others are not necessarily better. I have moved the code to the -modules, because now at least the majority of code is where it belongs to. But -there are still a large number of global variables, cross-function calls and the -like. This needs to be solved when we try to claim a real modular design. That's -not an easy task, but, hey, aren't we up for that...? ;)</p> +<p>But the others are not necessarily better. I have moved the +code to the modules, because now at least the majority of code is where +it belongs to. But there are still a large number of global variables, +cross-function calls and the like. This needs to be solved when we try +to claim a real modular design. That's not an easy task, but, hey, +aren't we up for that...? ;)</p> <p> </p> </body></html>
\ No newline at end of file |