Menu
▾
▴
[Proftpd-docs] www.proftpd.org/docs/modules mod_core.html, 1.1, 1.2 mod_log.html, 1.1, 1.2
|
From: TJ S. <cas...@us...> - 2012-03-19 18:27:48
|
Update of /cvsroot/pdd/www.proftpd.org/docs/modules In directory vz-cvs-3.sog:/tmp/cvs-serv20452 Modified Files: mod_core.html mod_log.html Log Message: Updating website copies of mod_core, mod_log docs. Index: mod_log.html =================================================================== RCS file: /cvsroot/pdd/www.proftpd.org/docs/modules/mod_log.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- mod_log.html 9 Nov 2011 23:52:12 -0000 1.1 +++ mod_log.html 19 Mar 2012 18:27:45 -0000 1.2 @@ -196,6 +196,13 @@ character, use "%%". <p> +The default <code>LogFormat</code> is: +<pre> + "%h %l %u %t \"%r\" %s %b" +</pre> +which produces log entries in the <a href="http://www.w3.org/Daemon/User/Config/Logging.html#common-logfile-format">Common Log Format</a>. + +<p> The following meta sequences/variables are available and are replaced as indicated when logging. @@ -333,7 +340,7 @@ <tr> <td> <code>%s</code> </td> - <td>Numeric FTP response code (status)</td> + <td>Numeric FTP response code (status); see <a href="http://www.faqs.org/rfcs/rfc959.html">RFC 959</a> Section 4.2.1</td> </tr> <tr> Index: mod_core.html =================================================================== RCS file: /cvsroot/pdd/www.proftpd.org/docs/modules/mod_core.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- mod_core.html 9 Nov 2011 23:52:11 -0000 1.1 +++ mod_core.html 19 Mar 2012 18:27:45 -0000 1.2 @@ -19,15 +19,28 @@ <h2>Directives</h2> <ul> + <li><a href="#AllowFilter">AllowFilter</a> + <li><a href="#DebugLevel">DebugLevel</a> + <li><a href="#DenyFilter">DenyFilter</a> <li><a href="#GroupOwner">GroupOwner</a> + <li><a href="#HideGroup">HideGroup</a> + <li><a href="#HideNoAccess">HideNoAccess</a> + <li><a href="#HideUser">HideUser</a> <li><a href="#Include">Include</a> <li><a href="#MaxCommandRate">MaxCommandRate</a> + <li><a href="#MaxInstances">MaxInstances</a> <li><a href="#PassivePorts">PassivePorts</a> <li><a href="#PathAllowFilter">PathAllowFilter</a> <li><a href="#PathDenyFilter">PathDenyFilter</a> <li><a href="#ProcessTitles">ProcessTitles</a> <li><a href="#Protocols">Protocols</a> + <li><a href="#ScoreboardFile">ScoreboardFile</a> + <li><a href="#ScoreboardMutex">ScoreboardMutex</a> + <li><a href="#ServerIdent">ServerIdent</a> + <li><a href="#SyslogFacility">SyslogFacility</a> + <li><a href="#SyslogLevel">SyslogLevel</a> <li><a href="#TCPBacklog">TCPBacklog</a> + <li><a href="#TimeoutIdle">TimeoutIdle</a> <li><a href="#TimeoutLinger">TimeoutLinger</a> <li><a href="#Trace">Trace</a> <li><a href="#TraceLog">TraceLog</a> @@ -36,6 +49,118 @@ </ul> <hr> +<h2><a name="AllowFilter">AllowFilter</a></h2> +<strong>Syntax:</strong> AllowFilter <em>pattern [flags]</em><br> +<strong>Default:</strong> None<br> +<strong>Context:</strong> "server config", <code><VirtualHost></code>, <code><Global></code>, <code><Anonymous></code>, +<code><Directory></code>, .ftpaccess<br> +<strong>Module:</strong> mod_core<br> +<strong>Compatibility:</strong> 1.2.0pre7 and later + +<p> +The <code>AllowFilter</code> allows the configuration of a regular expression +<em>pattern</em> that must be matched for all command arguments sent to +ProFTPD. It is extremely useful in controlling what characters may be sent in +a command to ProFTPD, preventing some possible types of attacks against ProFTPD. + +<p> +The regular expression <em>pattern</em> is applied against the arguments to the +command sent by the client, so care must be taken when creating a proper regex. +Commands that fail the regex match result in a "Forbidden command" error being +returned to the client. If the <em>pattern</em> contains whitespace, it +<b>must</b> be enclosed in quotes. + +<p> +The optional <em>flags</em> parameter, if present, modifies how the +given<em>pattern</em> will be evaludated. The supported flags are: +<ul> + <li><b>nocase|NC</b> (<b>n</b>o <b>c</b>ase)<br> + This makes the <em>pattern</em> case-insensitive, <i>i.e.</i> there is + no difference between 'A-Z' and 'a-z' when <em>pattern</em> is matched + against the path + </li> +</ul> + +<p> +The example below allows commands which contain alphanumeric characters and +whitespace: +<pre> + AllowFilter "^[a-zA-Z0-9 ,]*$" +</pre> + +<p> +The <a href="../howto/Filters.html">Filters</a> howto covers filtering in +greater detail. + +<p> +See also: <a href="#DenyFilter"><code>DenyFilter</code></a>, <a href="#PathAllowFilter"><code>PathAllowFilter</code></a>, <a href="#PathDenyFilter"><code>PathDenyFilter</code></a> + +<p> +<hr> +<h2><a name="DebugLevel">DebugLevel</a></h2> +<strong>Syntax:</strong> DebugLevel <em>level</em><br> +<strong>Default:</strong> DebugLevel 0<br> +<strong>Context:</strong> "server config", <code><VirtualHost></code>, <code><Global></code><br> +<strong>Module:</strong> mod_core<br> +<strong>Compatibility:</strong> 1.2.8rc1 and later + +<p> +The <code>DebugLevel</code> directive configures the debugging level the +server will use when logging. The <em>level</em> parameter must be between 0 +and 10. This directive will take precedence over any +<code>-d</code>/<code>--debug</code> command-line debugging option used. + +<p> +The <a href="../howto/Logging.html">Logging</a> howto covers logging in +greater detail. + +<p> +<hr> +<h2><a name="DenyFilter">DenyFilter</a></h2> +<strong>Syntax:</strong> DenyFilter <em>pattern [flags]</em><br> +<strong>Default:</strong> None<br> +<strong>Context:</strong> "server config", <code><VirtualHost></code>, <code><Global></code>, <code><Anonymous></code>,<code><Directory></code>, .ftpaccess<br> +<strong>Module:</strong> mod_core<br> +<strong>Compatibility:</strong> 1.2.0pre7 and later + +<p> +The <code>DenyFilter</code> directive, like the <code>AllowFilter</code> +directive, specifies a regular expression <em>pattern</em> which must not +match any of the command arguments. If the <em>pattern</em> does match, a +"Forbidden command" error is returned to the client. This can be especially +useful for forbidding certain command argument combinations from ever reaching +ProFTPD. + +<p> +Note that the <code>PASV</code> SFTP command <b>cannot</b> be blocked using +this directive. + +<p> +The optional <em>flags</em> parameter, if present, modifies how the +given<em>pattern</em> will be evaludated. The supported flags are: +<ul> + <li><b>nocase|NC</b> (<b>n</b>o <b>c</b>ase)<br> + This makes the <em>pattern</em> case-insensitive, <i>i.e.</i> there is + no difference between 'A-Z' and 'a-z' when <em>pattern</em> is matched + against the path + </li> +</ul> + +<p> +For example, to reject commands which contain the percent (<code>%</code>) +character, you could use: +<pre> + DenyFilter "%" +</pre> + +<p> +The <a href="../howto/Filters.html">Filters</a> howto covers filtering in +greater detail. + +<p> +See also: <a href="#AllowFilter"><code>AllowFilter</code></a>, <a href="#PathAllowFilter"><code>PathAllowFilter</code></a>, <a href="#PathDenyFilter"><code>PathDenyFilter</code></a> + +<hr> <h2><a name="GroupOwner">GroupOwner</a></h2> <strong>Syntax:</strong> GroupOwner <em>group-name|"~"</em><br> <strong>Default:</strong> None<br> @@ -74,6 +199,113 @@ See also: <a href="#UserOwner"><code>UserOwner</code></a> <hr> +<h2><a name="HideGroup">HideGroup</a></h2> +<strong>Syntax:</strong> HideGroup <em>group-name</em><br> +<strong>Default:</strong> None<br> +<strong>Context:</strong> <code><Anonymous></code>, <code><Directory></code><br> +<strong>Module:</strong> mod_core<br> +<strong>Compatibility:</strong> 0.99.0 and later + +<p> +The <code>HideGroup</code> directive configures a <code><Directory></code> +or <code><Anonymous></code> section to hide all directory entries owned +by the specified <em>group-name</em>. The <em>group-name</em> can also be +<code>~</code> (tilde), which is evaluated as the <em>group-name</em> of +the primary group of the logged-in user. This can be combined with a prefix +<code>!</code> (exclamation point) character, <i>e.g.</i> "!~", to mean +"any group that is not the primary group of the logged-in-user". + +<p> +Normally, hidden directories and files cannot be seen via <code>LIST</code> or +<code>NLST</code> commands but can be operated on via other FTP commands +(<code>CWD</code>, <code>DELE</code>, <code>RETR</code>, <i>etc</i>). This +behavior can be modified via the <code>IgnoreHidden</code> directive. + +<p> +Examples: +<pre> + <Directory <i>path</i>> + # Hide all files belonging to group 'wheel' + HideGroup wheel + + # Hide all files belonging to the primary group of the logged-in user + HideGroup ~ + + # Hide all files that are NOT owned by the primary group of the logged-in + # user + HideGroup !~ + </Directory> +</pre> + +<p> +See also: <a href="#HideUser"><code>HideUser</code></a>, <a href="#HideNoAccess"><code>HideNoAccess</code></a>, <a href="#IgnoreHidden"><code>IgnoreHidden</code></a> + +<hr> +<h2><a name="HideNoAccess">HideNoAccess</a></h2> +<strong>Syntax:</strong> HideNoAccess <em>on|off</em><br> +<strong>Default:</strong> None<br> +<strong>Context:</strong> <code><Anonymous></code>, <code><Directory></code><br> +<strong>Module:</strong> mod_core<br> +<strong>Compatibility:</strong> 0.99.0 and later + +<p> +The <code>HideNoAccess</code> directive configures a +<code><Directory></code> or <code><Anonymous></code> section to +hide all directory entries in a directory listing (<i>e.g.</i> via the +<code>LIST</code> or <code>NLST</code> FTP commands) to which the current +logged-in, authenticated user has no access. Normal Unix-style permissions +<b>always</b> apply, so that although a user may not be able to see a directory +entry that has "HideNoAccess on" applied, they will receive a normal +"Permission denied" error message when attempting to blindly manipulate the +file system object. The directory or file can be made completely invisible to +all FTP commands by applying <code>IgnoreHidden</code> in conjunction with +<code>HideNoAccess</code>. + +<p> +See also: <a href="#HideGroup"><code>HideGroup</code></a>, <a href="#HideUser"><code>HideUser</code></a>, <a href="#IgnoreHidden"><code>IgnoreHidden</code></a> + +<hr> +<h2><a name="HideUser">HideUser</a></h2> +<strong>Syntax:</strong> HideUser <em>user-name</em><br> +<strong>Default:</strong> None<br> +<strong>Context:</strong> <code><Anonymous></code>, <code><Directory></code><br> +<strong>Module:</strong> mod_core<br> +<strong>Compatibility:</strong> 0.99.0 and later + +<p> +The <code>HideUser</code> directive configures a <code><Directory></code> +or <code><Anonymous></code> section to hide all directory entries owned +by the specified <em>user-name</em>. The <em>user-name</em> can also be +<code>~</code> (tilde), which is evaluated as the <em>user-name</em> of +the logged-in user. This can be combined with a prefix <code>!</code> +(exclamation point) character, <i>e.g.</i> "!~", to mean "any user that is not +the logged-in-user". + +<p> +Normally, hidden directories and files cannot be seen via <code>LIST</code> or +<code>NLST</code> commands but can be operated on via other FTP commands +(<code>CWD</code>, <code>DELE</code>, <code>RETR</code>, <i>etc</i>). This +behavior can be modified via the <code>IgnoreHidden</code> directive. + +<p> +Examples: +<pre> + <Directory <i>path</i>> + # Hide all files belonging to user 'root' + HideUser root + + # Hide all files belonging to the logged-in user + HideUser ~ + + # Hide all files that are NOT owned by the logged-in user + HideUser !~ + </Directory> +</pre> + +<p> +See also: <a href="#HideGroup"><code>HideGroup</code></a>, <a href="#HideNoAccess"><code>HideNoAccess</code></a>, <a href="#IgnoreHidden"><code>IgnoreHidden</code></a> + +<hr> <h2><a name="Include">Include</a></h2> <strong>Syntax:</strong> Include <em>path|pattern</em><br> <strong>Default:</strong> None<br> @@ -87,9 +319,10 @@ <p> Shell-style (<code>fnmatch(3)</code>) wildcard characters can be used to -include several files at once, in alphabetical order. In addition, if -<code>Include</code> points to a directory, rather than a file, then -<code>proftpd</code> will read all files in that directory. <b>Note</b> +include several files at once, in alphabetical order. (If no matches for +the pattern are found, the <code>Include</code> directive is silently ignored.) +In addition, if <code>Include</code> points to a directory, rather than a file, +then <code>proftpd</code> will read all files in that directory. <b>Note</b> that including entire directories is <b>not</b> recommended, as it is easy to accidentally leave temporary files in a directory that can cause <code>proftpd</code> to fail. @@ -132,6 +365,33 @@ <p> <hr> +<h2><a name="MaxInstances">MaxInstances</a></h2> +<strong>Syntax:</strong> MaxInstances <em>count</em><br> +<strong>Default:</strong> None<br> +<strong>Context:</strong> server config<br> +<strong>Module:</strong> mod_core<br> +<strong>Compatibility:</strong> 1.1.6p11 and later + +<p> +The <code>MaxInstances</code> directive configures the maximum number of child +(session) processes that may be spawned by the <code>proftpd</code> daemon +process when running with "ServerType standalone" configured. The directive +has no effect when <code>proftpd</code> is configured with "ServerType inetd". + +<p> +Each <code>proftpd</code> child process represents a single client connection, +and thus this directive also controls the maximum number of simultaneous +connections allowed. Additional connections beyond the configured limit are +logged, and silently disconnected. The <code>MaxInstances</code> directive +can be used to prevent undesirable denial-of-service attacks (<i>e.g.</i> +by repeatedly connecting to the FTP control port, a malicious client could try +to cause <code>proftpd</code> to repeatedly fork new processes, creating a +"fork-bomb"). By default, no limit is placed on the number of child +processes that may run at one time; it is <b>highly recommended</b> that a +maximum number, suitable to your sites traffic, be configured. + +<p> +<hr> <h2><a name="PassivePorts">PassivePorts</a></h2> <strong>Syntax:</strong> PassivePorts <em>min max</em><br> <strong>Default:</strong> None<br> @@ -180,7 +440,7 @@ <h2><a name="PathAllowFilter">PathAllowFilter</a></h2> <strong>Syntax:</strong> PathAllowFilter <em>pattern [flags]</em><br> <strong>Default:</strong> None<br> -<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global>, <code><Anonymous></code>, <code><Directory></code>, .ftpaccess<br> +<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code>, <code><Anonymous></code>, <code><Directory></code>, .ftpaccess<br> <strong>Module:</strong> mod_core<br> <strong>Compatibility:</strong> 1.1.7 and later @@ -204,7 +464,7 @@ </pre> <p> -The optional <em>flags</em> paramete, if present, modifies how the given +The optional <em>flags</em> parameter, if present, modifies how the given <em>pattern</em> will be evaludated. The supported flags are: <ul> <li><b>nocase|NC</b> (<b>n</b>o <b>c</b>ase)<br> @@ -219,14 +479,14 @@ greater detail. <p> -See also: <a href="#PathDenyFilter"><code>PathDenyFilter</code</a> +See also: <a href="#PathDenyFilter"><code>PathDenyFilter</code></a> <p> <hr> <h2><a name="PathDenyFilter">PathDenyFilter</a></h2> <strong>Syntax:</strong> PathDenyFilter <em>pattern [flags]</em><br> <strong>Default:</strong> None<br> -<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global>, <code><Anonymous></code>, <code><Directory></code>, .ftpaccess<br> +<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code>, <code><Anonymous></code>, <code><Directory></code>, .ftpaccess<br> <strong>Module:</strong> mod_core<br> <strong>Compatibility:</strong> 1.1.7 and later @@ -245,7 +505,7 @@ </pre> <p> -The optional <em>flags</em> paramete, if present, modifies how the given +The optional <em>flags</em> parameter, if present, modifies how the given <em>pattern</em> will be evaludated. The supported flags are: <ul> <li><b>nocase|NC</b> (<b>n</b>o <b>c</b>ase)<br> @@ -260,14 +520,14 @@ greater detail. <p> -See also: <a href="#PathAllowFilter"><code>PathAllowFilter</code</a> +See also: <a href="#PathAllowFilter"><code>PathAllowFilter</code></a> <p> <hr> <h2><a name="ProcessTitles">ProcessTitles</a></h2> <strong>Syntax:</strong> ProcessTitles <em>terse|verbose</em><br> <strong>Default:</strong> ProcessTitles verbose<br> -<strong>Context:</strong> server config +<strong>Context:</strong> server config<br> <strong>Module:</strong> mod_core<br> <strong>Compatibility:</strong> 1.3.4rc2 and later @@ -340,6 +600,227 @@ <p> <hr> +<h2><a name="ScoreboardFile">ScoreboardFile</a></h2> +<strong>Syntax:</strong> ScoreboardFile <em>path|"none"</em><br> +<strong>Default:</strong> ScoreboardFile /usr/local/var/proftpd.scoreboard</br> +<strong>Context:</strong> server config<br> +<strong>Module:</strong> mod_core<br> +<strong>Compatibility:</strong> 1.2.7rc1 and later + +<p> +The <code>ScoreboardFile</code> directive sets the path to the file where the +daemon will store its run-time "scoreboard" session information. This file is +necessary for support features such as +<a href="mod_auth.html#MaxClients"><code>MaxClients</code></a> to work properly, +as well as other utilities (such as <a href="../utils/ftpwho.html">ftpwho</a>, +<a href="../utils/ftptop.html">ftptop</a>, and +<a href="../utils/ftpcount.html">ftpcount</a>). <b>Note</b> that the directory +containing the scoreboard <b>cannot</b> be world-writable. + +<p> +For performance reasons, it is <b>strongly recommended</b> that the +<code>ScoreboardFile</code> path <i>not</i> be located on a networked +filesystem, but rather be located on a local physical disk. + +<p> +In order to <i>disable</i> scoreboarding (which can increase performance, +at the cost of functionality), any of the following can be used: +<pre> + ScoreboardFile /dev/null + ScoreboardFile none + ScoreboardFile off +</pre> +Please read the +<a href="../howto/Scoreboard.html#ScoreboardDisabling">Scoreboard</a> howto +before disabling scoreboarding. + +<p> +<hr> +<h2><a name="ScoreboardMutex">ScoreboardMutex</a></h2> +<strong>Syntax:</strong> ScoreboardMutex <em>path</em><br> +<strong>Default:</strong> ScoreboardMutex /usr/local/var/proftpd.scoreboard.lck</br> +<strong>Context:</strong> server config<br> +<strong>Module:</strong> mod_core<br> +<strong>Compatibility:</strong> 1.3.4rc1 and later + +<p> +The <code>ScoreboardMutex</code> directive sets the path to a "mutex" file +which is used for scoreboard locking/synchronization; this mutex is used to +increase the daemon's performance under load. + +<p> +For performance reasons, it is <b>strongly recommended</b> that the +<code>ScoreboardMutex</code> path <i>not</i> be located on a networked +filesystem, but rather be located on a local physical disk. It is best if +the <code>ScoreboardMutex</code> be located in the same directory as the +<a href="#ScoreboardFile"><code>ScoreboardFile</code></a>. + +<p> +<hr> +<h2><a name="ServerIdent">ServerIdent</a></h2> +<strong>Syntax:</strong> ServerIdent <em>off|on "identification string"</em><br> +<strong>Default:</strong> ServerIdent on "ProFTPD [version] Server (server name) [hostname]"<br> +<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br> +<strong>Module:</strong> mod_core<br> +<strong>Compatibility:</strong> 1.2.0pre2 and later + +<p> +The <code>ServerIdent</code> directive sets the default message displayed when +a new client connects. Setting this to <em>off</em> displays: +<pre> + [<i>hostname</i>] FTP server ready. +</pre> +If set to <em>on</em>, the directive can take an optional string argument, +which will be displayed instead of the default text. Sites desiring to give +out minimal information will probably want a setting like: +<pre> + ServerIdent on "FTP Server ready." +</pre> +which won't even reveal the hostname. + +<p> +An example of a custom identification string might be: +<pre> + ServerIdent on "Welcome to ftp.linux.co.uk" +</pre> + +<p> +<hr> +<h2><a name="SyslogFacility">SyslogFacility</a></h2> +<strong>Syntax:</strong> SyslogFacility <em>facility</em><br> +<strong>Default:</strong> SyslogFacility daemon<br> +<strong>Context:</strong> server config<br> +<strong>Module:</strong> mod_core<br> +<strong>Compatibility:</strong> 1.1.6 and later + +<p> +By default, ProFTPD logs its activity via the Unix syslog mechanism, which +allows for several different general classifications of logging messages, +known as "facilities." Normally, all authentication related messages are +logged with the <code>AUTHPRIV</code> (or <code>AUTH</code>) facility +(since these messages are intended to be secure, and never seen by unwanted +eyes), while normal operational messages are logged with the +<code>DAEMON</code> facility. The <code>SyslogFacility</code> directive +allows <b>all</b> logging messages to be directed to a different facility than +the default. + +<p> +When this directive is used, <b>all</b> logging is done with the specified +<em>facility</em>, both authentication (secure) and otherwise. The +<em>facility</em> argument must be one of the following: +<ul> + <li><code>AUTH</code> (or <code>AUTHPRIV</code>) + <li><code>CRON</code> + <li><code>DAEMON</code> + <li><code>FTP</code> + <li><code>KERN</code> + <li><code>LPR</code> + <li><code>MAIL</code> + <li><code>NEWS</code> + <li><code>USER</code> + <li><code>UUCP</code> + <li><code>LOCAL0</code> + <li><code>LOCAL1</code> + <li><code>LOCAL2</code> + <li><code>LOCAL3</code> + <li><code>LOCAL4</code> + <li><code>LOCAL5</code> + <li><code>LOCAL6</code> + <li><code>LOCAL7</code> +</ul> +For more information on syslog facilities, see the <code>syslog.conf</code> +man page. + +<p> +The <a href="../howto/Logging.html">Logging</a> howto covers logging in +greater detail. + +<p> +See also: <a href="#SyslogLevel"><code>SyslogLevel</code></a>, +<a href="mod_log.html#SystemLog"><code>SystemLog</code></a> + +<p> +<hr> +<h2><a name="SyslogLevel">SyslogLevel</a></h2> +<strong>Syntax:</strong> SyslogLevel <em>level</em><br> +<strong>Default:</strong> SyslogLevel debug<br> +<strong>Context:</strong> server config<br> +<strong>Module:</strong> mod_core<br> +<strong>Compatibility:</strong> 1.2.0rc2 and later + +<p> +The <code>SyslogLevel</code> directive adjusts the verbosity of the messages +recorded via the default Unix syslog logging. The following <em>levels</em> +are available, in order of decreasing significance: + +<p> +<table border=1> + <tr> + <td><b>Level</b></td> + <td><b>Description</b></td> + </tr> + + <tr> + <td><code>emerg</code></td> + <td>Emergencies (<i>e.g.</i> the system is unusable)</td> + </tr> + + <tr> + <td><code>alert</code></td> + <td>Action must be taken immediately</td> + </tr> + + <tr> + <td><code>crit</code></td> + <td>Critical conditions</td> + </tr> + + <tr> + <td><code>error</code></td> + <td>Error conditions</td> + </tr> + + <tr> + <td><code>warn</code></td> + <td>Warning conditions</td> + </tr> + + <tr> + <td><code>notice</code></td> + <td>Normal but significant conditions</td> + </tr> + + <tr> + <td><code>info</code></td> + <td>Informational</td> + </tr> + + <tr> + <td><code>debug</code></td> + <td>Debug-level messages</td> + </tr> +</table> + +<p> +When a particular <em>level</em> is specified, messages from all other levels +of higher significance will be reported as well. For example, when: +<pre> + SyslogLevel info +</pre> +is configured, then messages with log levels of <code>notice</code> and +<code>warn</code> will also be logged. Using a level of at least +<code>crit</code> is recommended. + +<p> +The <a href="../howto/Logging.html">Logging</a> howto covers logging in +greater detail. + +<p> +See also: <a href="#SyslogFacility"><code>SyslogFacility</code></a>, +<a href="mod_log.html#SystemLog"><code>SystemLog</code></a> + +<p> +<hr> <h2><a name="TCPBacklog">TCPBacklog</a></h2> <strong>Syntax:</strong> TCPBacklog <em>backlog-size</em><br> <strong>Default:</strong> 5<br> @@ -391,8 +872,37 @@ <p> <hr> +<h2><a name="TimeoutIdle">TimeoutIdle</a></h2> +<strong>Syntax:</strong> TimeoutIdle <em>seconds</em><br> +<strong>Default:</strong> 600 seconds<br> +<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code>, <code><Anonymous></code><br> +<strong>Module:</strong> mod_core<br> +<strong>Compatibility:</strong> 0.99.0 and later + +<p> +The <code>TimeoutIdle</code> directive configures the maximum number of +<em>seconds</em> that <code>proftpd</code> will allow clients to stay connected +without receiving any data on either the control or data connection. If data +are received on either connection, the idle timer is reset. Setting +<code>TimeoutIdle</code> to zero disables the idle timer completely, meaning +that clients can stay connected forever, without sending data. <b>Note</b>: +this is generally a <b>very bad idea</b>, as a "hung" TCP connection which is +never properly disconnected (<i>e.g.</i> the remote network may have become +disconnected from the Internet, <i>etc</i>) will cause a session process to +never exit, until manually killed. This session process will thus linger, using +up one of the <a href="#MaxInstances"><code>MaxInstances</code></a> as well as +any of the other configured limits. The maximum allowed <em>seconds</em> value +is 65535 (108 minutes). + +<p> +See also: <a href="mod_auth.html#TimeoutLogin"><code>TimeoutLogin</code></a>, +<a href="mod_xfer.html#TimeoutNoTransfer"><code>TimeoutNoTransfer</code></a>, +<a href="mod_xfer.html#TimeoutStalled"><code>TimeoutStalled</code></a>. + +<p> +<hr> <h2><a name="TimeoutLinger">TimeoutLinger</a></h2> -<strong>Syntax:</strong> TimeoutLinger <em>secs</em><br> +<strong>Syntax:</strong> TimeoutLinger <em>seconds</em><br> <strong>Default:</strong> 30<br> <strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br> <strong>Module:</strong> mod_core<br> @@ -409,7 +919,8 @@ <p> If the client aborts a transfer and there is a long delay, this lingering close is the most likely culprit. So if you encounter this delay, set -<code>TimeoutLinger</code> to a low number to remove the delay. +<code>TimeoutLinger</code> to a low number to remove the delay. The maximum +allowed <em>seconds</em> is 65535 (108 minutes). <p> For the curious, here are the full details: some FTP clients will close their @@ -545,7 +1056,7 @@ <p> <hr> <h2><a name="Installation">Installation</a></h2> -The <code>mod_core</code>module is <b>always</b> installed. +The <code>mod_core</code> module is <b>always</b> installed. <p> <hr><br> @@ -556,7 +1067,7 @@ <br><hr> <font size=2><b><i> -© Copyright 2000-2011 The ProFTPD Project<br> +© Copyright 2000-2012 The ProFTPD Project<br> All Rights Reserved<br> </i></b></font> |
