580 lines
24 KiB
HTML
580 lines
24 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<title>ProFTPD: Logging</title>
|
|
</head>
|
|
|
|
<body bgcolor=white>
|
|
|
|
<hr>
|
|
<center><h2><b><i>ProFTPD: Logging</i></b></h2></center>
|
|
<hr>
|
|
|
|
<p>
|
|
<b>Logging</b><br>
|
|
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 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>
|
|
Anyone who can write to the directory where ProFTPD is writing a log file can
|
|
almost certainly gain access to the UID that the server is started under, which
|
|
is normally <code>root</code>. <b>Do not</b> give people write access to the
|
|
directory where the logs are stored without being aware of the consequences:
|
|
if the logs directory is writable (by a non-<code>root</code> user), someone
|
|
could replace a log file with a symlink to some other system file, and then
|
|
<code>root</code> might overwrite that file with arbitrary data. If the log
|
|
files themselves are writable (by a non-<code>root</code> user), then someone
|
|
may be able to overwrite the log itself with bogus data.
|
|
|
|
<p>
|
|
When opening log files, <code>proftpd</code> will by default log a warning if
|
|
the file being opened for logging is in a directory that does not exist, or
|
|
is world-writable. The log file will <b>not</b> be written in world-writable
|
|
directories; there are no exceptions. (If you have configured log files in
|
|
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="../modules/mod_log.html#AllowLogSymlinks"><code>AllowLogSymlinks</code></a> directive.
|
|
|
|
<p>
|
|
In addition, log files may contain information supplied directly by the client,
|
|
without escaping. Therefore, it is possible for malicious clients to insert
|
|
control-characters in the log files, so care must be taken in dealing with
|
|
raw logs.
|
|
|
|
<p><a name="Syslog"></a>
|
|
<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>,
|
|
<code>info</code>, and <code>debug</code> (debugging is done at this syslog
|
|
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. See the <a href="LogLevels.html">log level</a> documentation for
|
|
more details on these settings.
|
|
|
|
<p><a name="LogFiles"></a>
|
|
<b>Log Files</b><br>
|
|
There are three main types of logs that a <code>proftpd</code> daemon can
|
|
generate: <code>TransferLog</code>, <code>SystemLog</code>, and
|
|
<code>ExtendedLog</code>.
|
|
|
|
<p><a name="TransferLog"></a>
|
|
<b><i><code>TransferLog</code></i></b><br>
|
|
A <a href="../modules/mod_core.html#TransferLog"><code>TransferLog</code></a>
|
|
is the most common log kept, recording file transfers. It is written in the
|
|
<code>xferlog(5)</code> format, described here, <b>and</b> in the
|
|
<code>xferlog(5)</code> man page.
|
|
|
|
<p>
|
|
Each entry in the <code>TransferLog</code> is a single line of space-delimited
|
|
fields:
|
|
<table border=1 summary="TransferLog Fields">
|
|
<tr>
|
|
<td> <b>Field</b></td>
|
|
<td> <b>Values</b></td>
|
|
<td> <b>Description</b></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> <em>current-time</em></td>
|
|
<td> DDD MMM dd hh:mm:ss YYYY</td>
|
|
<td> Current <b>local</b> time at the time of transfer</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> <em>transfer-time</em></td>
|
|
<td> Seconds</td>
|
|
<td> Total time in <b>seconds</b> for the transfer</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> <em>remote-host</em></td>
|
|
<td> String</td>
|
|
<td> Remote client DNS name (or IP address)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> <em>file-size</em></td>
|
|
<td> Bytes</td>
|
|
<td> Number of bytes transferred</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> <em>filename</em></td>
|
|
<td> String</td>
|
|
<td> Name of the transferred file</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> <em>transfer-type</em></td>
|
|
<td> Flags</td>
|
|
<td> Indicates whether the transfer was an ASCII (<code>"a"</code>) or
|
|
binary (<code>"b"</code>) transfer</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> <em>special-action-flag</em></td>
|
|
<td> Flags</td>
|
|
<td> One or more single character indicating any special action taken: "C" (compressed), "U" (uncompressed), "T" (tarred), "_" (no action)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> <em>direction</em></td>
|
|
<td> Flags</td>
|
|
<td> Direction of the transfer: "o" (outgoing, <i>i.e.</i> download), "i" (incoming, <i>i.e.</i> upload), "d" (deleted)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> <em>access-mode</em></td>
|
|
<td> Flags</td>
|
|
<td> Method by which the user is logged in: "a" (anonymous), "g" (guest), "r" (real user)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> <em>username</em></td>
|
|
<td> String</td>
|
|
<td> Authenticated username</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> <em>service-name</em></td>
|
|
<td> String</td>
|
|
<td> Name of the service used: "ftp", "sftp", "scp", <i>etc</i></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> <em>authentication-method</em></td>
|
|
<td> Flags</td>
|
|
<td> Method of authentication used: "0" (none), "1" (<a href="https://www.ietf.org/rfc/rfc1413.txt">RFC 1413</a>)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> <em>authenticated-user-id</em></td>
|
|
<td> Flags</td>
|
|
<td> Name of user provided by RFC 1413 lookup, otherwise "*"</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> <em>completion-status</em></td>
|
|
<td> Flags</td>
|
|
<td> Single character indicating the status of the transfer: "c" (complete), "i" (incomplete)</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>
|
|
<b>History of the <code>xferlog(5)</code> Format</b><br>
|
|
This xferlog(5) format seems a bit odd, right? To understand this, it helps
|
|
to keep in mind the history of this format. The xferlog(5) format
|
|
<b>predates</b> ProFTPD. The ProFTPD Project copied this format from
|
|
<a href="http://wu-ftpd.therockgarden.ca/man/xferlog.html">wu-ftpd</a>, which
|
|
was <em>the</em> popular FTP server at that time. There were already existing
|
|
tools/scripts which knew how to parse that format, so ProFTPD used it. Since
|
|
then, <code>wu-ftpd</code> has waned in maintenance and popularity; other
|
|
FTP servers (<i>e.g.</i> <code>pure-ftpd</code>, <code>vsftpd</code>, but
|
|
<b>not</b> the built-in <code>ftpd</code> on FreeBSD) have since then picked
|
|
up the <code>xferlog(5)</code> format from ProFTPD. Thus this log format has
|
|
a 20+ year history, and keeps going.
|
|
|
|
<p>
|
|
This history helps explain certain fields in the <code>xferlog(5)</code>
|
|
format, such as the <em>authentication-method</em> and
|
|
<em>authenticated-user-id</em> fields. These fields were more relevant in
|
|
the past, when the RFC 1413 Identd protocol was more widespread in use. Now,
|
|
<b>very</b> few sites run <code>identd</code> servers; these fields in the
|
|
log format are thus archaic. Thus in almost all ProFTPD-generated
|
|
<code>TransferLog</code> entries, <em>authentication-method</em> will be "0",
|
|
and <em>authenticated-user-id</em> will be "*".
|
|
|
|
<p>
|
|
Likewise, the <em>special-action-flags</em> field mentions "compressed" and
|
|
"uncompressed" files; these flags specifically refer to the
|
|
<a href="https://en.wikipedia.org/wiki/Compress"><code>compress</code></a>
|
|
Unix program, which used the ".Z" file extension. This compression utility
|
|
has been superseded with <i>e.g.</i> <code>gzip</code>, <code>bzip2</code>,
|
|
and others these days. Thus the <em>special-action-flags</em> field in
|
|
ProFTPD-generated <code>TransferLog</code> entries is almost always "_".
|
|
|
|
<p><a name="SystemLog"></a>
|
|
<b><i><code>SystemLog</code></i></b><br>
|
|
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>
|
|
<b><i><code>ExtendedLog</code></i></b><br>
|
|
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"></a>
|
|
<b>Use of <code>syslog</code> 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:
|
|
<ul>
|
|
<li>Webalizer: <a href="http://www.webalizer.org/">http://www.webalizer.org/</a>
|
|
<li>HTTP-analyze: <a href="http://www.netstore.de/Supply/http-analyze/">http://www.netstore.de/Supply/http-analyze/</a>
|
|
<li>Report Magic: <a href="http://www.reportmagic.org/">http://www.reportmagic.org/</a>
|
|
<li>FTPWeblog: <a href="http://www.nihongo.org/snowhare/utilities/ftpweblog/">http://www.nihongo.org/snowhare/utilities/ftpweblog/</a>
|
|
</ul>
|
|
|
|
<p><a name="LogRotation"></a>
|
|
<b>Log Rotation</b><br>
|
|
On even a moderately busy server, the quantity of information stored in the log
|
|
files is very large. It will consequently be necessary to periodically rotate
|
|
the log files by moving or deleting the existing logs. This cannot be done
|
|
while the processes are running, because the processes will continue writing to
|
|
the old log file as long as they hold the file open. Instead, the server must
|
|
be <a href="Stopping.html">restarted</a> after the log files are moved or
|
|
deleted so that the processes will open new log files.
|
|
|
|
<p>
|
|
The <code>SIGHUP</code> signal, for restarting ProFTPD, goes to the "master"
|
|
daemon process, the process that is listening for new connections. Whenever a
|
|
new connection is received, the daemon process forks off a <i>separate new session process</i> which handles that connection, including logging for that
|
|
session.
|
|
|
|
<p>
|
|
Part of handling of a session often involves handling the
|
|
<code>DefaultRoot</code> directive, which uses the <code>chroot(2)</code>
|
|
function to restrict the session process. This means, in practice, that once
|
|
the process is chrooted, it <b>cannot</b> re-open the configured log files
|
|
anymore, as those log paths are not located within the restricted portion of
|
|
the filesystem.
|
|
|
|
<p>
|
|
This means that any log rotation will need to handle the case where existing
|
|
session processes continue writing to the old log files, until those sessions
|
|
complete. If one is using <code>logrotate</code>, for example, this means
|
|
using the <code>copytruncate</code> and/or <code>delaycompress</code> settings.
|
|
|
|
<p>
|
|
Another way to perform log rotation is using <a href="#FIFOs">FIFOs</a> as
|
|
discussed in the next section.
|
|
|
|
<p><a name="FIFOs"></a>
|
|
<b>FIFOs (<i>a.k.a.</i> named pipes)</b><br>
|
|
ProFTPD is capable of writing log files to FIFOs, from which another
|
|
process can read. Use of this capability dramatically increases the
|
|
flexibility of logging, without adding code to the main server. In order to
|
|
write logs to a pipe, simply create the FIFO at the desired path
|
|
(<code>man mkfifo(1)</code>), and use that path in the logging configuration
|
|
directive.
|
|
|
|
<p>
|
|
One important use of piped logs is to allow log rotation without having to
|
|
restart the server. One such popular flexible log rotation program is
|
|
<a href="http://www.ford-mason.co.uk/resources/cronolog/">cronolog</a>;
|
|
however, at present cronolog requires a small patch to enable it to read
|
|
from a FIFO (by default, cronolog reads data from stdin). Please contact
|
|
the author of this article for details concerning the patch.
|
|
|
|
<p>
|
|
Here's an example of FIFO-based logging script, based on one posted by Michael
|
|
Renner:
|
|
<pre>
|
|
#!/usr/bin/perl
|
|
|
|
use strict;
|
|
|
|
use File::Basename qw(basename);
|
|
use Sys::Syslog qw(:DEFAULT setlogsock);
|
|
|
|
my $program = basename($0);
|
|
|
|
my $fifo = '/var/log/proftpd-log.fifo';
|
|
my $syslog_facility = 'daemon';
|
|
my $syslog_level = 'info';
|
|
|
|
open(FIFO, "< $fifo") or die "$program: unable to open $fifo: $!\n";
|
|
|
|
setlogsock 'unix';
|
|
|
|
openlog($program, 'pid', $syslog_facility);
|
|
syslog($syslog_level, $_) while (<FIFO>);
|
|
closelog();
|
|
|
|
close(FIFO);
|
|
exit 0;
|
|
</pre>
|
|
More complex filtering can be added to such scripts.
|
|
|
|
<p>
|
|
If using FIFOs, there are some caveats to keep in mind. If you use in
|
|
<code>init.d</code> script to start <code>standalone</code> daemons, you can
|
|
add commands to start the FIFO logging programs first, before the daemon.
|
|
For <code>inetd</code>-run servers, consider wrapping up the necessary
|
|
commands for starting a FIFO reader and the server into a simple shell
|
|
script, or simply run the FIFO-reading program from an <code>init.d</code>
|
|
script, and save the overhead of starting that process, in addition to the
|
|
<code>proftpd</code> process, for each FTP session.
|
|
|
|
<p>
|
|
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
|
|
process to the file <code>var/proftpd/proftpd.pid</code>. This filename can be
|
|
changed with the <a href="../modules/mod_core.html#PidFile"><code>PidFile</code></a> directive. The process ID (<i>aka</i> PID) is for use by the administrator
|
|
in restarting and terminating the daemon by sending signals to the parent
|
|
process. For more information see the <a href="Stopping.html">stopping and
|
|
starting</a> page.
|
|
|
|
<p>
|
|
<b>Scoreboard File</b><br>
|
|
The last type of "logging" is done via the scoreboard file. The
|
|
scoreboard is binary-formatted file the server uses to store information
|
|
about each session; it is this file that is read by <code>ftptop</code>,
|
|
<code>ftpwho</code> and <code>ftpcount</code>. The location for the
|
|
scoreboard file is determined by the
|
|
<a href="../modules/mod_core.html#ScoreboardFile"><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>
|
|
<font color=red>Question</font>: I configured my <code>ExtendedLog</code>
|
|
directive (or <code>SystemLog</code>, or other logs) to point to a FIFO.
|
|
The FIFO path exists. But when I try to start <code>proftpd</code>, it
|
|
fails to start with this error:
|
|
<pre>
|
|
unable to open ExtendedLog '/path/to/extlog.fifo': No such device or address
|
|
</pre>
|
|
Shouldn't this work?<br>
|
|
<font color=blue>Answer</font>: The "No such device or address" error occurs
|
|
when you configure <code>proftpd</code> to log to a FIFO, <b>and</b> the
|
|
FIFO reader process has not yet been started. In times past,
|
|
<code>proftpd</code> would wait indefinitely on startup, waiting for the FIFO
|
|
reader process to start; now, <code>proftpd</code> tries to open the FIFO
|
|
in a nonblocking mode, so that it can fail immediately if there is no process
|
|
on the other end of the FIFO.
|
|
|
|
<p>
|
|
The "fix" is to make sure that any FIFO reader processes are started
|
|
<i>before</i> starting <code>proftpd</code>.
|
|
|
|
<p>
|
|
<font color=red>Question</font>: How can I configure <code>proftpd</code> so
|
|
that <b>nothing</b> is logged for certain clients/IP addresses?<br>
|
|
<font color=blue>Answer</font>: Using a combination of <a href="Classes.html">classes</a> and the <a href="../contrib/mod_ifsession.html"><code>mod_ifsession</code></a> module, this can be done using a configuration like this:
|
|
<pre>
|
|
<Class invisible>
|
|
From 1.2.3.4
|
|
</Class>
|
|
|
|
<IfClass invisible>
|
|
# Disable all logging of these clients
|
|
SystemLog none
|
|
ExtendedLog /path/to/ext.log NONE
|
|
TransferLog none
|
|
</IfClass>
|
|
</pre>
|
|
|
|
<p>
|
|
<font color=red>Question</font>: How can I configure <code>proftpd</code> so
|
|
that it does <em>no logging at all</em>? I have a very small embedded system
|
|
for development/testing, and so do not need or want the logging.<br>
|
|
<font color=blue>Answer</font>: To do this, you will need to disable much
|
|
of the builtin, default logging that <code>proftpd</code> does, <i>e.g.</i>:
|
|
<pre>
|
|
# Discard the normal logging
|
|
SystemLog none
|
|
|
|
# Disable xferlog(5) logging
|
|
TransferLog none
|
|
|
|
# Disable logging to b/u/wtmp files
|
|
WtmpLog off
|
|
</pre>
|
|
In addition, you may need to go through your <code>proftpd.conf</code> file
|
|
(as well as any <code>Include</code> config files), and remove all
|
|
<code>ExtendedLog</code> and <code>TraceLog</code> directives. Also remove
|
|
any per-module <code><i>*</i>Log</code> directives like <code>BanLog</code>,
|
|
<code>SFTPLog</code>, <code>SQLLogFile</code>, <code>TLSLog</code>, <i>etc</i>.
|
|
|
|
<p>
|
|
You might be tempted to symlink the log files configured to
|
|
<code>/dev/null</code>, rather than changing the <code>proftpd.conf</code>.
|
|
This approach can work, <b><i>if you also use the <code>AllowLogSymlinks</code> directive</i></b>, <i>i.e.</i>:
|
|
<pre>
|
|
# Allow proftpd to write logs to symlinks; note that this is insecure,
|
|
# as the symlinks might be changed to point to other files such that
|
|
# proftpd will overwrite them.
|
|
AllowLogSymlinks on
|
|
</pre>
|
|
|
|
<p>
|
|
<font color=red>Question</font>: I see:
|
|
<pre>
|
|
wtmp /var/log/wtmp: No such file or directory
|
|
</pre>
|
|
in my logs. What is <code>WtmpLog</code> logging? The description in the
|
|
documentation is quite vague.<br>
|
|
<font color=blue>Answer</font>: The <code>wtmp</code> logging support is
|
|
<b>not</b> specific to <code>proftpd</code>, and instead is a more general Unix
|
|
facility; this is why the ProFTPD documentation does not cover it in great
|
|
detail. To learn more about <code>wtmp</code> (or any of its other
|
|
incarnations: <code>wtmpx</code>, <code>utmp</code>, <code>utmpx</code>),
|
|
please find their related man pages.
|
|
|
|
<p>
|
|
Now to make the "No such file or directory" log message go away, simply tell
|
|
<code>proftpd</code> to stop trying to use <code>wtmp</code> logging by using
|
|
the <a href="../modules/mod_auth.html#WtmpLog"><code>WtmpLog</code></a>
|
|
directive:
|
|
<pre>
|
|
WtmpLog off
|
|
</pre>
|
|
in your <code>proftpd.conf</code>.
|
|
|
|
<p>
|
|
<font color=red>Question</font>: I usually run in a non-English locale; my
|
|
ProFTPD version is older than 1.3.6, <i>and</i> I use <code>fail2ban</code>.
|
|
Unfortunately, <code>fail2ban</code> has trouble with the non-English
|
|
localized dates in the syslog messages, <i>e.g.</i>:
|
|
<pre>
|
|
juil. 28 16:42:17 server-hostname proftpd[9423] server-hostname ...
|
|
</pre>
|
|
in my logs. How can I get ProFTPD to log using the English locale, for
|
|
working with <code>fail2ban</code> properly?<br>
|
|
<font color=blue>Answer</font>: The locale-related environment variable which
|
|
governs how dates are formatted is the <code>LC_TIME</code> environment
|
|
variable. Thus you need to set that environment variable, <em>before</em>
|
|
ProFTPD is started, to use the English locale if you want English localization,
|
|
<i>e.g.</i>:
|
|
<pre>
|
|
$ export LC_TIME=en_US.UTF-8
|
|
$ service proftpd start
|
|
</pre>
|
|
Note that the above is only really needed due to the older version of ProFTPD.
|
|
|
|
<p>
|
|
In later version of ProFTPD, the syslog logging format changed (to avoid such
|
|
localization issues), so that it now looks like:
|
|
<pre>
|
|
2017-07-28 16:42:17 server-hostname proftpd[9423] server-hostname ...
|
|
</pre>
|
|
This should help many such log-parsing issues.
|
|
|
|
<p>
|
|
<hr>
|
|
<font size=2><b><i>
|
|
© Copyright 2017-2024 The ProFTPD Project<br>
|
|
All Rights Reserved<br>
|
|
</i></b></font>
|
|
<hr>
|
|
|
|
</body>
|
|
</html>
|