Menu
▾
▴
[Proftpd-docs] www.proftpd.org/docs/howto Logging.html,1.2,1.3
|
From: TJ S. <cas...@us...> - 2012-03-19 18:28:22
|
Update of /cvsroot/pdd/www.proftpd.org/docs/howto In directory vz-cvs-3.sog:/tmp/cvs-serv21504 Modified Files: Logging.html Log Message: Updating website copy of Logging howto. Index: Logging.html =================================================================== RCS file: /cvsroot/pdd/www.proftpd.org/docs/howto/Logging.html,v retrieving revision 1.2 retrieving revision 1.3 diff -u -d -r1.2 -r1.3 --- Logging.html 24 Feb 2010 18:55:58 -0000 1.2 +++ Logging.html 19 Mar 2012 18:28:20 -0000 1.3 @@ -17,10 +17,11 @@ Logging the activity of the server is an integral part of effective server administration. ProFTPD provides several different and flexing logging mechanisms. When examining the different logging mechanisms, have in -mind the intended use of the logged data, the volume, any post-processing -that may need to be done, etc. Log files are more useful when they contain a -complete record of server activity. It is often easier to simply post-process -the log files to remove requests that you do not want to consider. +mind the intended use of the logged data, the volume of data being logged, +any post-processing that may need to be done, <i>etc</i>. Log files are more +useful when they contain a complete record of server activity. It is often +easier to simply post-process the log files to remove requests that you do not +want to consider. <p> <b>Security Warning</b><br> @@ -42,7 +43,7 @@ your <code>proftpd.conf</code> that are not appearing, check for the warnings about world-writable directories.) The <code>proftpd</code> process will also, by default, log a warning if the file given is a symlink; this symlink check -can be configured via the <a href="http://www.proftpd.org/docs/directives/linked/config_ref_AllowLogSymlinks.html"><code>AllowLogSymlinks</code></a> directive. +can be configured via the <a href="../modules/mod_log.html#AllowLogSymlinks"><code>AllowLogSymlinks</code></a> directive. <p> In addition, log files may contain information supplied directly by the client, @@ -51,7 +52,7 @@ raw logs. <p><a name="Syslog"></a> -<b><code>syslog</code></b><br> +<b>Unix <code>syslog</code> Logging</b><br> By default, <code>proftpd</code> will log via <code>syslog(3)</code>, using the <code>daemon</code> facility (<code>auth</code> for some logging), at various levels: <code>err</code>, <code>notice</code>, <code>warn</code>, @@ -59,32 +60,84 @@ level). The location of the server's log files in this case is determined by your <code>/etc/syslog.conf</code> configuration. +<p> +You can fine-tune your <code>proftpd</code>'s syslog-based logging via the +<a href="../modules/mod_core.html#SyslogFacility"><code>SyslogFacility</code></a> and <a href="../modules/mod_core.html#SyslogLevel"><code>SyslogLevel</code></a> directives. + <p><a name="LogFiles"></a> -<b><code>Log Files</code></b><br> +<b>Log Files</b><br> There are three main types of logs that a <code>proftpd</code> daemon can -generate: <code>TransferLog</code>s, a <code>SystemLog</code>, and -<code>ExtendedLog</code>s. +generate: <code>TransferLog</code>, <code>SystemLog</code>, and +<code>ExtendedLog</code>. <p><a name="TransferLog"></a> -A <a href="http://www.proftpd.org/docs/directives/linked/config_ref_TransferLog.html"><code>TransferLog</code></a> is the most common log kept, recording file -transfers. Its format is described in the <code>xferlog(5)</code> man page, -also available <a href="http://www.castaglia.org/proftpd/doc/xferlog.html">here</a> +A <a href="../modules/mod_core.html#TransferLog"><code>TransferLog</code></a> +is the most common log kept, recording file transfers. Its format is described +in the <code>xferlog(5)</code> man page, +also available <a href="http://www.castaglia.org/proftpd/doc/xferlog.html">here</a>. <p><a name="SystemLog"</a> -If the site administrator wants to have <code>proftpd</code> log its -messages to a file rather than going through <code>syslogd</code>, the -<a href="http://www.proftpd.org/docs/directives/linked/config_ref_SystemLog.html"><code>SystemLog</code></a> configuration directive is the one to use. There -is only one such file kept for the entire daemon. See the <a href="http://www.proftpd.org/docs/directives/linked/config_ref_ServerLog.html"><code>ServerLog</code></a> directive for keeping a similar log on a per-vhost basis. +If the site administrator wants to have <code>proftpd</code> log its messages +to a file rather than going through <code>syslogd</code>, the +<a href="../modules/mod_log.html#SystemLog"><code>SystemLog</code></a> +configuration directive is the one to use. There is only one such file kept +for the entire daemon. See the +<a href="../modules/mod_log.html#ServerLog"><code>ServerLog</code></a> +directive for keeping a similar log on a per-vhost basis. Note that the +<a href="../modules/mod_core.html#DebugLevel"><code>DebugLevel</code></a> +directive only applies to <code>SystemLog</code> files; it does not materially +affect the syslog-based logging messages. <p><a name="ExtendedLog"></a> -The <a href="http://www.proftpd.org/docs/directives/linked/config_ref_ExtendedLog.html">ExtendedLog</a> directive is used to create log files of a very -flexible and configurable format, and to have granular control over what is -logged, and when. The format of an <code>ExtendedLog</code> is described -using the <a href="http://www.proftpd.org/docs/directives/linked/config_ref_LogFormat.html">LogFormat</a> directive. Multiple <code>ExtendedLogs</code> can -be configured, each with a different format. +The <a href="../modules/mod_log.html#ExtendedLog"><code>ExtendedLog</code></a> +directive is used to create log files of a very flexible and configurable +format, and to have granular control over what is logged, and when. The format +of an <code>ExtendedLog</code> is described using the +<a href="../modules/mod_log.html#LogFormat">LogFormat</a> directive. +Multiple <code>ExtendedLogs</code> can be configured, each with a different +<code>LogFormat</code>. <!-- Add note/chunk about FTP response codes, from RFC959, for ExtendedLog? --> +<p><a name="SyslogVSFileLog"> +<b>Use of syslog versus file logging</b><br> +Most sites will choose to have <code>proftpd</code> log via syslog (which is +the default) or to a file (via the <code>SystemLog</code> directive). In +either case, there is the question of logging <i>verbosity</i>, <i>i.e.</i> +which messages to log. This verbosity is determined by the +<a href="../modules/mod_core.html#SyslogLevel"><code>SyslogLevel</code></a> +directive. ProFTPD will log everything by default, meaning that the default +<code>SyslogLevel</code> is effectively <code>debug</code>. If, however, you +have your <code>proftpd</code> configured to log via syslog, then you +<i>should</i> also check your <code>/etc/syslog.conf</code> file, to see what +additional filtering of log messages is being applied by syslog. For example, +if <code>/etc/syslog.conf</code> contained something like: +<pre> + # Log anything (except mail) of level info or higher. + *.info;mail.none;authpriv.none;cron.none /var/log/messages +</pre> +then ProFTPD's log messages below the <code>info</code> level would be filtered +out <b>by syslog</b>. When you are using syslog logging, the +<code>SyslogLevel</code> configuration directive applies only to the proftpd +logging, and does not control the additional syslog filtering. + +<p> +For finer-grained control of the <code>debug</code> level log messages, ProFTPD +internally implements different levels for its <code>debug</code> log messages. +Currently ProFTPD has level 1 through level 10 <code>debug</code> messages. +The <a href="../modules/mod_core.html#DebugLevel"><code>DebugLevel</code></a> +directive is used control the verbosity/filtering of these messages. Since +these different debug levels are purely a ProFTPD convention, the +<code>DebugLevel</code> directive has no effect on syslog logging. Also, if +your <code>SyslogLevel</code> configuration uses a level higher than +<code>debug</code>, then the <code>DebugLevel</code> configuration will have +no effect — your <code>debug</code> level messages are already filtered +out by the <code>SyslogLevel</code> filtering. + +<p> +The last point to mention is that the +<a href="../modules/mod_core.html#SyslogFacility"><code>SyslogFacility</code></a> directive only applies to syslog logging; it has no effect on file logging. + <p><a name="LogAnalysis"></a> <b>Log Analysis</b><br> There are a variety of log analyzers available; these are just a few: @@ -144,12 +197,12 @@ my $syslog_facility = 'daemon'; my $syslog_level = 'info'; - open(FIFO, "< $fifo") or die "$program: unable to open $fifo: $!\n"; + open(FIFO, "< $fifo") or die "$program: unable to open $fifo: $!\n"; setlogsock 'unix'; openlog($program, 'pid', $syslog_facility); - syslog($syslog_level, $_) while (<FIFO>); + syslog($syslog_level, $_) while (<FIFO>); closelog(); close(FIFO); @@ -171,11 +224,28 @@ FIFO-based log readers are a very powerful tool, but they should not be used where a simpler solution like off-line post-processing is available. +<p> +<b>Note</b>: In ProFTPD 1.3.3, the code was changed to use nonblocking +<code>open(2)</code> system calls when opening log files. This was done to +prevent a <code>proftpd</code> process from blocking indefinitely +(<i>i.e.</i> "hanging") if the log file was a FIFO, and there was no FIFO +reader process running when the log file was opened. However, some sites +<i>do</i> want this blocking open behavior, as their FIFO reader processes +may be temporarily busy. To get the pre-1.3.3 blocking behavior, you will +need to compile proftpd using the <code>--disable-nonblocking-log-open</code> +configure option. + <p><a name="SQLLogging"></a> <b>SQL Logging</b><br> The <code>mod_sql</code> module also enables some powerful and complex logging capabilities... +<p><a name="TraceLogging"></a> +<b>Trace Logging</b><br> +ProFTPD also supports a much more verbose form of logging called "trace +logging". This form of logging is covered in greater detail +<a href="Tracing.html">here</a>. + <p><a name="PidFile"></a> <b>Pid File</b><br> On startup, <code>proftpd</code> saves the process ID of the parent daemon @@ -194,6 +264,35 @@ scoreboard file is determined by the <a href="http://www.proftpd.org/docs/directives/linked/config_ref_ScoreboardFile.html"><code>ScoreboardFile</code></a> directive. +<p><a name="FAQ"></a> +<b>Frequently Asked Questions</b><br> + +<p> +<font color=red>Question</font>: How can I direct the <code>TransferLog</code> +logging to syslog?<br> +<font color=blue>Answer</font>: It is not currently possible to configure +proftpd to log <code>TransferLog</code> data to syslog. <b>However</b>, you +<i>can</i> configure an <code>ExtendedLog</code> which logs to syslog, and +which uses a <code>LogFormat</code> to log the data you wish. For example: +<pre> + LogFormat xfer "%h %l %u %t\"%r\" %s %b" + ExtendedLog syslog:notice xfer +</pre> +tells proftpd to log that <code>LogFormat</code> via syslog at the "notice" +syslog level. + +<p> +<font color=red>Question</font>: I have <code>SystemLog</code> in my +<code>proftpd.conf</code>, and when I use the <code>SyslogLevel</code> directive +to try to filter the messages which <code>proftpd</code> logs to my +<code>SystemLog</code>, it doesn't work. Why not?<br> +<font color=blue>Answer</font>: When ProFTPD is configured to log everything +to a file via the <code>SystemLog</code> directive, it will do just that: +log <i>everything</i>, without any filtering, regardless of any +<code>SyslogLevel</code> directive. <b>However</b>, this changed in +ProFTPD 1.3.4rc1: in that release, the <code>SyslogLevel</code> directive was +made to apply to file-based logging as well. + <p> <hr> Last Updated: <i>$Date$</i><br> |
