The following configuration parameters control ProFTPD features and configuration:
Syntax: AccessGrantMsg message
Default: Dependent on login type
Context: server config, <VirtualHost>, <Anonymous>, <Global>
Module: mod_core
Compatibility: 0.99.0pl5 and later
Normally, a 230 response message is sent to an FTP client immediately after authentication, with a standard message indicating that the user has either logged in or that anonymous access has been granted. This message can be customized with the AccessGrantMsg directive. In the message argument, the magic cookie '%u' is replaced with the username specified by the client during login. Example:
AccessGrantMsg "Guest access granted for %u."
Syntax: Allow ["from"] "all"|"none"|host|network[,host|network[,...]]
Default: allow all
Context: <Limit>
Module: mod_core
Compatibility: 0.99.0pl6 and later
The Allow directive is used inside a <Limit> context to explicitly specify which hosts and/or networks have access to the commands or operations being limited. Allow is typically used in conjunction with Order and Deny in order to create sophisticated (or perhaps not-so-sophisticated) access control rules. Allow takes an optional first argument; the keyword from. Using from is purely cosmetic. The remaining arguments are expected to be a list of hosts and networks which will be explicitly granted access. The magic keyword all can be used to indicate that all hosts will explicitly be granted access (analogous to the AllowAll directive, except with a lower priority). Additionally, the magic keyword none can be used to indicate that no hosts or networks will be explicitly granted access (although this does not prevent them from implicitly being granted access). If all or none is used, no other hosts or networks can be supplied.
Host and network addresses can be specified by name or numeric address. For security reasons, it is recommended that all address information be supplied numerically. Relying solely on named addresses causes security to depend a great deal upon DNS servers which may themselves be vulnerable to attack or spoofing. Numeric addresses which specify an entire network should end in a trailing period (i.e. 10.0.0. for the entire 10.0.0 subnet). Named address which specify an entire network should begin with a trailing period (i.e. .proftpd.org for the entire proftpd.org domain).
The selection made can be selectively negated using the ! operator, this allows a large block of hosts or IPs to be selected while still allowing single hosts to be weeded out as required.
Example:
<Limit LOGIN>
Order Allow,Deny
Allow from 128.44.26.,128.44.26.,myhost.mydomain.edu,.trusted-domain.org
Deny from all
</Limit>
Syntax: AllowAll
Default: Default is to implicitly AllowAll, but not explicitly
Context: <Directory>, <Anonymous>, <Limit>, .ftpaccess
Module: mod_core
Compatibility: 0.99.0 and later
The AllowAll directive explicitly allows access to a <Directory>, <Anonymous> or <Limit> block. Although proftpd's default behavior is to allow access to a particular object, the default is an implicit allow. AllowAll creates an explicit allow, overriding any higher level denial directives.
Syntax: AllowChmod on|off
Default: true
Context: server config, <Directory>, <VirtualHost>, <Anonymous>, <Global>, .ftpaccess
Module: mod_site
Compatibility: 1.2.0rc1 and later
AllowChmod allows control over whether the "SITE CHMOD" command is allowed to clients.
Example:
AllowChmod false
Syntax: AllowFilter regular-expression
Default: None
Context: server config, <VirtualHost>, <Anonymous>, <Global>
Module: mod_core
Compatibility: 1.2.0pre7 and later
AllowFilter allows the configuration of a regular expression that must be matched for all commands 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. The regular expression is applied against the entire 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. Command filtering is not applied to passwords (arguments to the PASS command).
If the regular-expression argument contains whitespace, it must be enclosed in quotes.
Example:
# Only allow commands containing alphanumeric characters and whitespace
AllowFilter "^[a-zA-Z0-9 ,]*$"
See Also: DenyFilter
Syntax: AllowForeignAddress on|off
Default: off
Context: server config, <VirtualHost>, <Anonymous>, <Global>
Module: mod_core
Compatibility: 1.1.7 and later
Normally, proftpd disallows clients from using the ftp PORT command with anything other than their own address (the source address of the ftp control connection), as well as preventing the use of PORT to specify a low-numbered (< 1024) port. In either case, the client is sent an "Invalid port" error and a message is syslog'd indicating either "address mismatch" or "bounce attack". By enabling this directive, proftpd will allow clients to transmit foreign data connection addresses that do not match the client's address. This allows such tricks as permitting a client to transfer a file between two FTP servers without involving itself in the actual data connection. Generally it's considered a bad idea, security-wise, to permit this sort of thing.
AllowForeignAddress only affects data connection addresses; not tcp ports. There is no way (and no valid reason) to allow a client to use a low-numbered port in its PORT command.
Syntax: AllowGroup group-expression
Default: None
Context: <Limit>
Module: mod_core
Compatibility: 1.1.1 and later
AllowGroup specifies a group-expression that is specifically permitted within the context of the <Limit> block it is applied to. group-expression has the same format as that used in DefaultRoot, in that it should contain a comma separated list of groups or "not" groups (by prefixing a group name with the `!' character) that are to be allowed access to the block. The expression is parsed as a boolean "and" list, meaning that ALL elements of the expression must evaluate to logically true in order for the explicit allow to apply.
See Also: DenyGroup, DenyUser, AllowUser
Syntax: AllowOverwrite on|off
Default: off
Context: server config, <VirtualHost>, <Anonymous>, <Directory>, <Global>, .ftpaccess
Module: mod_core
Compatibility: 0.99.0 and later
The AllowOverwrite directive permits newly transfered files to overwrite existing files. By default, ftp clients cannot overwrite existing files.
Syntax: AllowUser user-expression
Default: None
Context: <Limit>
Module: mod_core
Compatibility: 1.1.7 and later
AllowUser specifies a user-expression that is specifically permitted access within the context of the <Limit> block it is applied to. user-expression has a similar syntax as that used in AllowGroup, in that it should contain a comma delimited list of users or "not" users (by prefixing a user name with the `!' character) that are to be allowed access to the block. The expression is parsed as a boolean "and" list, meaning that ALL elements of the expression must evaluate to logically true in order to the explicit allow to apply.
See Also: DenyUser, DenyGroup, AllowGroup
Syntax: AllowRetrieveRestart on|off
Default: on
Context: server config, <VirtualHost>, <Anonymous>,
<Directory>, <Global>, .ftpaccess
Module: mod_core
Compatibility: 0.99.0 and later
The AllowRetrieveRestart directive permits or denies clients from performing "restart" retrieve file transfers via the FTP REST command. By default this is enabled, so that clients may resume interrupted file transfers at a later time without losing previously collected data.
Syntax: AllowStoreRestart on|off
Default: off
Context: server config, <VirtualHost>, <Anonymous>,
<Directory>, <Global>, .ftpaccess
Module: mod_core
Compatibility: 0.99.0 and later
The AllowStoreRestart directive permits or denies clients from "restarting" interrupted store file transfers (those sent from client to server). By default restarting (via the REST command) is not permitted when sending files to the server. Care should be taken to disallow anonymous ftp "incoming" transfers to be restarted, as this will allow clients to corrupt or increase the size of previously stored files (even if not their own).
Syntax: AnonRequirePassword on|off
Default: off
Context: <Anonymous>
Module: mod_core
Compatibility: 0.99.0 and later
Normally, anonymous FTP logins do not require the client to authenticate themselves via the normal method of a transmitted cleartext password which is hashed and matched against an existing system user's password. Instead, anonymous logins are expected to enter their e-mail address when prompted for a password. Enabling the AnonRequirePassword directive requires anonymous logins to enter a valid password which must match the password of the user that the anonymous daemon runs as. However using AuthUsingAlias authentication can be matched against the password of the login username. This can be used to create "guest" accounts, which function exactly as normal anonymous logins do (and thus present a "chrooted" protected file system to the client), but require a valid password on the server's host system.
Example of a "guest" account configuration:
<Anonymous ~roger>
User roger
Group other
UserAlias proftpd roger
AnonRequirePassword on
# Deny write operations to all directories, underneath root-dir
# Default is to allow, so we don't need a <Limit> for read operations.
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
# Deny all read/write operations in incoming. Because these are command-group
# limits, we can explicitly permit certain operations which will take precedence
# over our group limit.
<Directory incoming>
<Limit READ WRITE>
DenyAll
</Limit>
# The only command allowed in incoming is STOR (transfer file from client to server)
<Limit STOR>
AllowAll
</Limit>
</Directory>
</Anonymous>
Syntax: AnonRatio foo1 foo2 foo3
Default: None known
Context: <Directory>, <Anonymous>, <Limit>,.ftpaccess
Module: mod_ratio
Compatibility: at least 1.2.0 and later
The AnonRatio directive .... INCOMPLETE
Example:
AnonRatio
Syntax: <Anonymous root-directory>
Default: None
Context: server config,<VirtualHost>, <Global>
Module: mod_core
Compatibility: 0.99.0 and later
The Anonymous configuration block is used to create an anonymous FTP login, and is terminated by a matching </Anonymous> directive. The root-directory parameters specifies which directory the daemon will first chdir to, and then chroot, immediately after login. Once the chroot operation successfully completes, higher level directories are no longer accessible to the running child daemon (and thus the logged in user). By default, proftpd assumes an anonymous login if the remote client attempts to login as the currently running user; unless the current user is root, in which case anonymous logins are not allowed regardless of the presence of an <Anonymous> block. To force anonymous logins to be bound to a user other than the current user, see the User and Group directives. In addition, if a User or Group directive is present in an <Anonymous> block, the daemon permanently switches to the specified uid/gid before chroot()ing.
Normally, anonymous logins are not required to authenticate with a password, but are expected to enter a valid e-mail address in place of a normal password (which is logged). If this behavior is undesirable for a given <Anonymous> configuration block, it can be overridden via the AnonRequirePassword directive.
Note: Chroot()ed anonymous directories do not need to have supplemental system files in them, nor do they need to have any sort of specific directory structure. This is because proftpd is designed to acquire as much system information as possible before the chroot, and to leave open those files which are needed for normal operation and reside outside the new root directory.
Example of a typical anonymous FTP configuration:
<Anonymous /home/ftp>
User ftp # After anonymous login, daemon runs as user ftp.
Group ftp # After anonymous login, daemon runs as group ftp.
UserAlias anonymous ftp # Client login as 'anonymous' is aliased to 'ftp'.
# Deny write operations to all directories, underneath root-dir
# Default is to allow, so we don't need a <Limit> for read operations.
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
<Directory incoming>
<Limit READ WRITE>
DenyAll
</Limit>
<Limit STOR>
AllowAll
</Limit>
</Directory>
</Anonymous>
Syntax: AnonymousGroup group-expression
Default: None
Context: server config, <VirtualHost>, <Global>
Module: mod_core
Compatibility: 1.1.3 and later
The AnonymousGroup directive specifies a group-expression to which all matching users will be considered anonymous logins. The group-expression argument is a boolean logically ANDed list of groups to which the user must be a member of (or non-member if the group name is prefixed with a `!' character). For more information on group-expressions see the DefaultRoot directive.
If the authenticating user is matched by an AnonymousGroup directive, no valid password is required, and a special dynamic anonymous configuration is created, with the user's home directory as the default root directory. If a DefaultRoot directive also applies to the user, this directory is used instead of the user's home dir.
Great care should be taken when using AnonymousGroup, as improper configuration can open up user home directories to full read/write access to the entire world.
Syntax: AuthAliasOnly on|off
Default: off
Context: server config, <VirtualHost>, <Anonymous>, <Global>
Module: mod_core
Compatibility: 1.1.3 and later
AuthAliasOnly restricts authentication to "aliased" logins only; i.e. those usernames provided by clients which are "mapped" to a real userid by the UserAlias directive. Turning AuthAliasOnly `on' in a particular context will cause proftpd to completely ignore all non-aliased logins for the entire context. If no contexts are available without AuthAliasOnly set to `on', proftpd rejects the client login and sends an appropriate message to syslog.
Syntax: AuthGroupFile path
Default: None
Context: server config, <VirtualHost>, <Global>
Module: mod_unixpw
Compatibility: 1.0.3/1.1.1 and later
AuthGroupFile specifies an alternate groups file, having the same format as the system /etc/group file, and if specified is used during authentication and group lookups for directory/access control operations. The path argument should be the full path to the specified file. AuthGroupFile can be configured on a per-VirtualHost basis, so that virtual FTP servers can each have their own authentication database (most often used in conjunction with AuthUserFile).
Note that this file need not reside inside a chroot()ed directory structure for Anonymous or DefaultRoot logins, as it is held open for the duration of client connections.
Syntax: AuthPAM on|off
Default: on
Context: server config,<VirtualHost>, <Global>
Module: mod_pam
Compatibility: 1.2.0rc1 and later
This directive determines whether PAM is used as an authentication method by ProFTPD. Enabled by default to fit in with the design policy of using PAM as the primary authentication mechanism.
Syntax: AuthPAMAuthoritative on|off
Default: off
Context: server config,<VirtualHost>, <Global>
Module: mod_unixpw
Compatibility: 1.2.0pre3 and later
This directive allows you to control whether or not PAM is the ultimate authority on authentication. Setting this directive to on will cause authentication to fail if PAM authentication fails. The default setting, off, allows other modules and directives such as AuthUserFile and friends to authenticate users, should PAM authentication fail.
If you are having problems with PAM and using other directives like AuthUserFile, set this directive to off.
Syntax: AuthPAMConfig service
Default: ftp
Context: server config,<VirtualHost>, <Global>
Module: mod_pam
Compatibility: 1.2.0rc1 and later
This directive allows you to specify the PAM service name used in authentication. PAM allows you to specify a service name to use when authenticating. This allows you to configure different PAM service names to be used for different virtual hosts.
The directive was renamed from PAMConfig post 1.2.0 pre10
Example:
# Virtual host foobar authenticates differently than the rest. AuthPAMConfig
foobar
This assumes you have a PAM service named foobar configured
in your /etc/pam.conf file or /etc/pam.d directory.
Syntax: AuthUserFile path
Default: None
Context: server config,<VirtualHost>, <Global>
Module: mod_unixpw
Compatibility: 1.0.3/1.1.1 and later
AuthUserFile specifies an alternate passwd file, having the same format as the system /etc/passwd file, and if specified is used during authentication and user lookups for directory/access control operations. The path argument should be the full path to the specified file. AuthUserFile can be configured on a per-VirtualHost basis, so that virtual FTP servers can each have their own authentication database (most often used in conjunction with AuthGroupFile).
Note that this file need not reside inside a chroot()ed directory structure for Anonymous or DefaultRoot logins, as it is held open for the duration of client connections.
Syntax: AuthUsingAlias on|off
Default: off
Context: <Anonymous>
Module: mod_core
Compatibility: 1.2.0pre9 and later
Normally, when the AnonRequirePassword directive is used, the authentication is done using the password entry of the daemon process. However under certain circumstances it may be required for the authentication to be done using the login username & password instead.
An example of an Anonymous configuration using AuthUsingAlias
# Basic Read-Only Anonymous Configuration.
<Anonymous /home/ftp>
UserAlias anonymous nobody
UserAlias ftp nobody
AuthAliasOnly on
<Limit WRITE>
DenyAll
</Limit>
</Anonymous>
# Give Full Read-Write Anonymous Access to certain users
<Anonymous /home/ftp>
AnonRequirePassword on
AuthAliasOnly on
AuthUsingAlias on
# The list of authorized users.
# user/pass lookup is for each user, not password entry
# of server uid ('nobody' in this example).
UserAlias fred nobody
UserAlias joe nobody
<Limit ALL>
AllowAll
</Limit>
</Anonymous>
Syntax: Bind address
Default: None
Context: server config, <VirtualHost>
Module: mod_core
Compatibility: 1.1.6 and later
The Bind directive allows additional IP addresses to be bound to a main or VirtualHost configuration. Multiple Bind directives can be used to bind multiple addresses. The address argument should be either a fully qualified domain name or a numeric dotted-quad IP address. Incoming connections destined to an additional address added by Bind are serviced by the context containing the directive. Additionally, if SocketBindTight is set to on, a specific listen connection is created for each additional address.
Syntax: ByteRatioErrMsg foo1 foo2 foo3
Default: None known
Context: <Directory>, <Anonymous>, <Limit>,.ftpaccess
Module: mod_ratio
Compatibility: at least 1.2.0 and later
The ByteRatioErrMsg directive .... INCOMPLETE
Example:
ByteRatioErrMsg
Syntax: CDPath directory
Default: None
Context: server config, <VirtualHost>, <Anonymous>,
<Global>
Module: mod_core
Compatibility: 1.2.0pre2 and later
Adds an entry to a search path that is used when changing directories. For example:
CDPath /home/public CDPath /var/develThis allows a user to cd into any directory directly under /home/public or /var/devel, provided they have the appropriate rights. So, if /home/public/proftpd exists,
cd proftpd will bring the user to that directory, regardless of where
they currently are in the directory tree.
Syntax: Class "name" limit|regex|ip value
Default: None
Context: server config, <VirtualHost>
Module: mod_core
Compatibility: 1.2.0pre9 and later
Controls class based access. Class base access allows each connecting IP to
be classified into a separate class. Each class has its own maximum number
of connections. limit sets the maximum number of connections
for that class name, regex sets a hostname regex (POSIX) for
inclusion in the class and ip sets an IP/netmask based inclusion.
The default class is called default. Example:
Classes on Class local limit 100 Class default limit 10 Class local regex .*foo.com Class local ip 172.16.1.0/24This creates two classes, local and default, with local being everything in *.foo.com and 172.16.1.* combined.
Syntax: Classes on|off
Default: Off
Context: server config, <VirtualHost>
Module: mod_core
Compatibility: 1.2.0pre9 and later
Controls class based access. Enables class based access control. see: Class
Syntax: CommandBufferSize size
Default: None
Context: server config, <VirtualHost>, <Global>
Module: mod_core
Compatibility: 1.2.0pre7 and later
The CommandBufferSize directive controls the maximum command length permitted to be sent to the server. This allows you to effectively control what the longest command the server may accept it, and can help protect the server from various Denial of Service or resource-consumption attacks.
Syntax: CwdRatioMsg foo1 foo2 foo3
Default: None known
Context: <Directory>, <Anonymous>,
<Limit>, .ftpaccess
Module: mod_ratio
Compatibility: at least 1.2.0 and later
The CwdRatioMsg directive .... INCOMPLETE
Example:
CwdRatioMsg
Syntax: DefaultChdir directory
[group-expression]
Default: ~
Context: server config, <VirtualHost>, <Anonymous>, <Global>
Module: mod_auth
Compatibility: 1.2.0pre2 and later
Determines the directory a user is placed in after logging in. By default, the user is put in their home directory. The specified directory can be relative to the user's home directory.
NOTE: if the specified directory is not available the user will not be able to log in.
Syntax: DefaultQuota value in bytes
Default: 0
Context: server, <VirtualHost>, <Anonymous>
Module: mod_quota
Compatibility: at least 1.2.0 and later
The DefaultQuota directive sets the default quota in bytes, this value is used if the .quota file does not exist.
Example:
#
# Set default to 1kb
#
DefaultQuota 1024
Syntax: DefaultRoot directory [group-expression]
Default: /
Context: server config, <VirtualHost>, <Global>
Module: mod_auth
Compatibility: 0.99.0pl7 and later
The DefaultRoot directive controls the default root directory assigned to a user upon login. If DefaultRoot is set to a directory other than "/", a chroot operation is performed immediately after a client authenticates. This can be used to effectively isolate the client from a portion of the host system filespace. The specified root directory must begin with a / or can be the magic character '~'; meaning that the client is chroot jailed into their home directory. If the DefaultRoot directive specifies a directory which disallows access to the logged-in user's home directory, the user's current working directory after login is set to the DefaultRoot instead of their normal home directory. DefaultRoot cannot be used in <Anonymous> configuration blocks, as the <Anonymous> directive explicitly contains a root directory used for Anonymous logins.
The special character '~' is replaced with the authenticating user's home directory immediately after login. Note that the default root may be a subdirectory of the home directory, such as "~/anon-ftp".
The optional group-expression argument can be used to restrict the DefaultRoot directive to a unix group, groups or subset of groups. The expression takes the format: [!]group-name1[,[!]group-name2[,...]]. The expression is parsed in a logical boolean AND fashion, such that each member of the expression must evaluate to logically TRUE in order for the DefaultRoot directive to apply. The special character '!' is used to negate group membership.
Care should be taken when using DefaultRoot. Chroot "jails" should not be used as methods for implementing general system security as there are potentially ways that a user can "escape" the jail.
Example of a DefaultRoot configuration:
ServerName "A test ProFTPD Server"
ServerType inetd
User ftp
Group ftp
#
# This causes proftpd to perform a chroot into the authenticating user's directory immediately after login.
# Once this happens, the user is unable to "see" higher level directories.
# Because a group-expression is included, only users who are a member of
# the group 'users' and NOT a member of 'staff' will have their default
# root directory set to '~'.
DefaultRoot ~ users,!staff
...
Syntax: DefaultServer on|off
Default: off
Context: server config,<VirtualHost>
Module: mod_core
Compatibility: 0.99.0pl6 and later
The DefaultServer directive controls which server configuration is used as the default when an incoming connection is destined for an IP address which is neither the host's primary IP address or one of the addresses specified in a <VirtualHost> configuration block. Normally such "unknown" connections are issued a "no server available to service your request" message and disconnected. When DefaultServer is turned on for either the primary server configuration or a virtual server, all unknown destination connections are serviced by the default server. Only a single server configuration can be set to default.
Syntax: DefaultTransferMode ascii|binary
Default: ascii
Context: server config, <VirtualHost>, <Global>
Module: mod_core
Compatibility: 1.2.0pre9 and later
DefaultTransferMode sets the default transfer mode of the server. By default, carriage-return/linefeed translation will be performed (ASCII mode).
Syntax: DeferWelcome on|off
Default: off
Context: server config, <VirtualHost>, <Global>
Module: mod_core
Compatibility: 0.99.0 and later
The DeferWelcome directive configures a master or virtual server to delay transmitting the ServerName and address to new connections, until a client has successfully authenticated. If enabled, the initial welcome message will be exceedingly generic and will not give away any type of information about the host that the daemon is actively running on. This can be used by security-conscious administrators to limit the amount of "probing" possible from non-trusted networks/hosts.
Syntax: DeleteAbortedStores on|off
Default: off
Context: server, <VirtualHost>,
<Directory>, <Anonymous>, <Global>, .ftpaccess
Module: mod_core
Compatibility: 1.2.0rc3 and later
The DeleteAbortedStores directive controls whether ProFTPD deletes partially uploaded files if the transfer is stopped via the ABOR command rather than a connection failure.
Syntax: Deny ["from"] "all"|"none"|host|network[,host|network[,...]]
Default: None
Context: <Limit>
Module: mod_core
Compatibility: 0.99.0pl6 and later
The Deny directive is used to create a list of hosts and/or networks which will explicitly be denied access to a given <Limit> context block. The magic keywords all and none can be used to indicate that all hosts are denied access, or that no hosts are explicitly denied (respectively). For more information on the syntax and usage of Deny see: Allow and Order.
The selection made can be selectively negated using the ! operator, this allows a large block of hosts or IPs to be blocked while still allowing single hosts to be excluded from the filter
Deny from example.net !trustedhost.example.net
Syntax: DenyAll
Default: None
Context: <Directory>, <Anonymous>, <Limit>, .ftpaccess
Module: mod_core
Compatibility: 0.99.0 and later
The DenyAll directive is analogous to a combination of "order deny,allow <cr> deny from all", with the exception that it has a higher precendance when parsed. It is provided as a convenient method of completely denying access to a directory, anonymous ftp or limit block. Because of its precedence, it should not be intermixed with normal Order/Deny directives. The DenyAll directive can be overridden at a lower level directory by using AllowAll. DenyAll and AllowAll are mutually exclusive.
Syntax: DenyFilter regular-expression
Default: None
Context: server config, <VirtualHost>, <Anonymous>, <Global>
Module: mod_core
Compatibility: 1.2.0pre7 and later
Similar to AllowFilter, DenyFilter specifies a regular expression which must not match any command. If the regex does match, a "Forbidden command" error is returned to the client. This can be especially useful for forbidding certain command combinations from ever reaching ProFTPD.
Example:
# We don't want to allow any commands with % being sent to the server
DenyFilter "%"
See Also: AllowFilter
Syntax: DenyGroup group-expression
Default: None
Context: <Limit>
Module: mod_core
Compatibility: 1.1.1 and later
DenyGroup specifies a group-expression that is specifically denied within the context of the <Limit> block it is applied to. group-expression has the same format as that used in DefaultRoot, in that it should contain a comma separated list of groups or "not" groups (by prefixing a group name with the `!' character) that are to be denied access to the block. The expression is parsed as a boolean "and" list, meaning that ALL elements of the expression must evaluate to logically true in order for the explicit deny to apply.
See Also: AllowGroup, AllowUser, DenyUser
Syntax: DenyUser user-expression
Default: None
Context: <Limit>
Module: mod_core
Compatibility: 1.1.7 and later
DenyUser specifies a user-expression that is specifically denied within the context of the a href="#Limit"><Limit> block it is applied to. user-expression is a comma delimited list of users or "not" users (by prefixing a user name with the `!' character). The expression is parsed as a boolean "and" list, meaning that all elements of the expression must evaluate to logically true in order for the explicit deny to apply.
See Also: AllowUser, DenyGroup, AllowGroup
Syntax: <Directory pathname>
Default: None
Context: server config, <VirtualHost>, <Anonymous>, <Global>
Module: mod_core
Compatibility: 0.99.0 and later
This directive creates a block of configuration directives which applies only to the specified directory and its sub-directories. The block is ended with </Directory>. Per-directory configuration is enabled during run-time with a "closest" match algorithm, meaning that the <Directory> directive with the closest matching path to the actual pathname of the file or directory in question is used. Per-directory configuration is inherited by all sub-directories until a closer matching <Directory> is encountered, at which time the original per-directory configuration is replaced with the closer match. Note that this does not apply to <Limit> </Limit> blocks, which are inherited by all sub-directories until a <Limit> block is reached in a closer match.
Example:
<Directory /users/robroy/private>
HideNoAccess
</Directory>
A trailing slash and wildcard ("/*") can be appended to the directory, specifying that the configuration block applies only to the contents (and sub-contents), not to the actual directory itself. Such wildcard matches always take precedence over non-wildcard <Directory> configuration blocks. <Directory> blocks cannot be nested (they are automatically nested at run-time based on their pathnames). Pathnames must always be absolute (except inside <Anonymous>), and should not reference symbolic links. Pathnames inside an <Anonymous> block can be relative, indicating that they are based on the anonymous root directory.
[Notes for ProFTPD 1.1.3 and later only]
Pathnames that begin with the special character '~' and do not specify
a username immediately after ~ are put into a special deferred mode.
When in deferred mode, the directory context is not hashed and sorted into the
configuration tree at boot time, but rather this hashing is deferred until a
user authenticates, at which time the '~' character is replaced with the user's
home directory. This allows a global <Directory> block which applies to
all user's home directories, or sub-directories thereof.
Example:
<Directory ~/anon-ftp>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
Syntax: DirFakeGroup On|Off [groupname]
Default: DirFakeGroup Off
Context: server config, <VirtualHost>, <Anonymous>, <Global>
Module: mod_ls
Compatibility: 1.1.5
DirFakeGroup and its companion directive, DirFakeUser, can be used to hide the true group and user owners of files in a directory listing. If simply turned On, DirFakeGroup will display all files as being owned by group 'ftp'. Optionally, the groupname argument can be used to specify a specific group other than 'ftp'. Both DirFakeGroup and DirFakeUser are completely cosmetic; the groupname or username specified need not exists on the system, and neither directive affects permissions, real ownership or access control in any way.
Syntax: DirFakeMode octal-mode
Default: None
Context: server config, <VirtualHost>, <Anonymous>, <Directory>, <Global>
Module: mod_ls
Compatibility: 1.1.6
The DirFakeMode directive configures a mode (or permissions) which will be displayed for ALL files and directories in directory listings. For each subset of permissions (user, group, other), the "execute" permission for directories is added in listings if the "read" permission is specified by this directive. For example:
DirFakeMode 0640
Will result in:
-rw-r----- ... arbitrary.file
drwxr-x--- ... arbitrary.directory
As with DirFakeUser, and DirFakeGroup, the "fake" permissions shown in directory listings are cosmetic only, they do not affect real permissions or access control in any way.
Syntax: DirFakeUser On|Off [username]
Default: Off
Context: server config, <VirtualHost>, <Anonymous>, <Global>
Module: mod_ls
Compatibility: 1.1.5
See DirFakeGroup
Syntax: DisplayConnect filename
Default: None
Context: server config, <VirtualHost>, <Global>
Module: mod_code
Compatibility: 1.2.0pre2 and later
The DisplayConnect directive configures an ASCII text filename which will be displayed to the user when they initially connect but before they login. The filename can be either relative or absolute. In the case of a relative filename, the file is searched for starting in the home directory of the user the server is running as. As this can lead confusion, absolute pathnames are suggested. If the file cannot be found or accessed, no error occurs and nothing is logged or displayed to the client.
Syntax: DisplayFirstChdir filename
Default: None
Context: server config, <VirtualHost>, <Anonymous>,
<Directory>, <Global>
Module: mod_code
Compatibility: 0.99.0 and later, magic cookies only in 0.99.0pl10
and later
The DisplayFirstChdir directive configures an ASCII text filename which will be displayed to the user the first time they change into a directory (via CWD) per a given session. The file will also be displayed if proftpd detects that its last modification time has changed since the previous CWD into a given directory. If the filename is relative, it is looked for in the new directory that the user has changed into. Note that for anonymous ftp logins (see <Anonymous>), the file must reside inside the chroot()ed file system space. If the file cannot be found or accessed, no error occurs and nothing is logged or displayed to the client.
DisplayFirstChdir, DisplayConnect, DisplayLogin, DisplayQuit, support the following "magic cookies" (only in 0.99.0pl10 and later), which are replaced with their respective strings before being displayed to the user.
| %T | Current Time | |
| %F | Available space on file system | |
| %C | Current working directory | |
| %R | Remote host name | |
| %L | Local host name | |
| %u | Username reported by ident protocol | |
| %U | Username originally used in login | |
| %M | Max number of connections | |
| %N | Current number of connections | |
| %E | Server admin's e-mail address | |
| %x | The name of the user's class | |
| %y | Current number of connections from the user's class | |
| %z | Max number of connections from the user's class |
NOTE: not all of these may have a rational value, depending on the context in which they're used (e.g., %u if ident lookups are off).
Syntax: DisplayGoAway filename
Default: None
Context: server config, <VirtualHost>, <Anonymous>, <Global>
Module: mod_core
Compatibility: 1.2.0pre8 and later
The DisplayGoAway directive specifies an ASCII text filename which will be displayed to the user if the class they're a member of has too many users logged in and their login request has been denied.
DisplayGoAway supports the same "magic cookies" as DisplayFirstChdir.
See Also: DisplayFirstChdir
Syntax: DisplayLogin filename
Default: None
Context: server config, <VirtualHost>, <Anonymous>,
<Global>
Module: mod_core
Compatibility: 0.99.0 and later
The DisplayLogin directive configures an ASCII text filename which will be displayed to the user when they initially login. The filename can be either relative or absolute. In the case of a relative filename, the file is searched for in the initial directory a user is placed in immediately after login (home directory for unix user logins, anonymous-root directory for anonymous logins). Note: that for jailed logins, the file must reside inside the chroot()ed file system space. If the file cannot be found or accessed, no error occurs and nothing is logged or displayed to the client.
DisplayLogin supports the same "magic cookies" as DisplayFirstChdir.
Syntax: DisplayQuit filename
Default: None
Context: server config, <VirtualHost>, <Anonymous>,
<Global>
Module: mod_core
Compatibility: 1.2.0pre8 and later
DisplayQuit configures an ASCII text filename which will be displayed to the user when they quit. The filename can be either relative or absolute. In the case of a relative filename, the file is searched for in current directory a user is in when they logout -- for this reason, a absolute filename is usually preferable.
NOTE: for jailed logins, the file must reside inside the chroot()ed file system space. If the file cannot be found or accessed, no error occurs and nothing is logged or displayed to the client.
DisplayQuit supports the "magic cookies" listed under DisplayFirstChdir.
Syntax: DisplayReadme filename or pattern
Default: None
Context: server config, <VirtualHost>, <Anonymous>,
<Global>
Module: mod_readme
Compatibility: 1.2.0pre8 and later
The DisplayReadme directive notifies the user of the last change date of the specified file or pattern. Only a single DisplayReadme directive is allowed per configuration scope.
DisplayReadme README
Will result in:
Please read the file README it was last modified on Sun Oct 17 10:36:14
1999 - 0 days ago
Being displayed to the user on a cwd.
DisplayReadmePattern README*
Will result in:
Please read the file README
it was last modified on Tue Jan 25 04:47:48 2000 - 0 days ago
Please read the file README.first
it was last modified on Tue Jan 25 04:48:04 2000 - 0 days ago
Being displayed to the user on a cwd.
Syntax: filename [[command-classes] format-nickname]
Default: None
Context: server config, <VirtualHost>, <Anonymous>
<Global>
Module: mod_log
Compatibility: 1.1.6pl1 and later
The ExtendedLog directive allows customizable logfiles to be generated, either globally or per VirtualHost. The filename argument must contain an absolute pathname to a logfile which will be appended to when proftpd starts. Multiple logfiles (potentially with different command classes and formats) can be created.
Optionally, the command-classes argument can be used to control which types of commands are logged. If not command classes are specified, proftpd logs all commands by default (passwords are hidden). command-classes is a comma delimited (no whitespace!) list of which commands to log. The following are valid classes:
If a format-nickname argument is supplied, ExtendedLog will use the predefined logformat (created by LogFormat). Otherwise, the default format of "%h %l %u %t \"%r\" %s %b" is used.
For example, to log all read and write operations to /var/log/ftp.log (using the default format), you could:
ExtendedLog /var/log/ftp.log read,write
See Also: LogFormat, TransferLog
Syntax: FileRatioErrMsg foo1 foo2 foo3
Default: None known
Context: <Directory>, <Anonymous>, <Limit>,.ftpaccess
Module: mod_ratio
Compatibility: at least 1.2.0 and later
The FileRatioErrMsg directive .... INCOMPLETE
Example:
FileRatioErrMsg
Syntax: FooBarDirective thingy
Default: none
Context: server config, <Anonymous>, <Limit>
Module: mod_sample
Compatibility: at least 1.2.0 and later
FooBarDirective is a dummy directive to be used as a coding example only.
Syntax: <Global>
Default: None
Context: server config, <VirtualHost>
Module: mod_core
Compatibility: 1.1.6 and later
The Global configuration block is used to create a set of configuration directives which is applied universally to both the main server configuration and all VirtualHost configurations. Most, but not all other directives can be used inside a Global block.
In addition, multiple <Global> blocks can be created. At runtime, all Global blocks are merged together and finally into each server's configuration. Global blocks are terminated by a matching </Global> directive.
Syntax: Group groupid
Default: None
Context: server config, <VirtualHost>, <Anonymous>,
<Global>
Module: mod_core
Compatibility: 0.99.0 and later
The Group directive configures which group the server daemon will normally run at. See User for more details.
Syntax: GroupOwner groupname
Default: None
Context: <Anonymous>, <Directory>, .ftpaccess
Module: mod_core
Compatibility: 0.99.0 and later
The GroupOwner directive configures which group all newly created directories and files will be owned by, within the context that GroupOwner is applied to. The group ID of groupname cannot be 0. Note that GroupOwner cannot be used to override the host OS/file system user/group paradigm. If the current user is not a member of the specified group, new files and directories will not be able to be chown()ed to the GroupOwner group. If this happens, file STOR (send file from client to server) and MKD (mkdir) operations will succeed normally, however the new directory entries will be owned by the current user's default group (a warning message is also logged) instead of by the desired group. If you also use UserOwner in the same context, this restriction is lifted.
Syntax: GroupPassword groupid hashed-password
Default: None
Context: server config, <VirtualHost>, <Anonymous>,
<Global>
Module: mod_core
Compatibility: 0.99.0pl5 and later
The GroupPassword directive creates a special "group" password which allows all users in the specified group to authenticate using a single password. The group/password supplied is only effective inside the context to which GroupPassword is applied. The hashed-password argument is a standard cleartext password which has been passed through the standard unix crypt() library function. Extreme care should be taken when using GroupPassword, as serious security problems may arise if group membership is not carefully controlled.
See Also: UserPassword
Syntax: GroupRatio foo1 foo2 foo3
Default: None known
Context: <Directory>, <Anonymous>,
<Limit>, .ftpaccess
Module: mod_ratio
Compatibility: at least 1.2.0 and later
The GroupRatio directive .... INCOMPLETE
Example:
GroupRatio
Syntax: HiddenStor on|off
Default: off
Context: <Directory>, <Anonymous>, <VirtualHost>, <Global>
Module: mod_core
Compatibility: 1.2.0pre5 and later
The HiddenStor directive enables two-step file uploads: files are uploaded
as ".in.filename." and once the upload is complete,
renamed to just "filename". This provides a
degree of atomicity and helps prevent 1) incomplete uploads and 2) files being
used while they're still in the progress of being uploaded. Note:
if the temporary file name is already in use (e.g., a server crash during upload),
it will prevent the file from being uploaded.
Syntax: HideGroup groupid
Default: None
Context: <Directory>, <Anonymous>
Module: mod_core
Compatibility: 0.99.0 and later
The HideGroup directive configures a <Directory> or <Anonymous> block to hide all directory entries owned by the specified group, unless the group is the primary group of the currently logged-in, authenticated user . Normally, hidden directories and files cannot be seen via LIST or NLST commands but can be operated on via other FTP commands (CWD, DELE, RETR, etc). This behavior can be modified via the IgnoreHidden directive.
See Also: HideUser, HideNoAccess, IgnoreHidden
Syntax: HideNoAccess on|off
Default: None
Context: <Directory>,<Anonymous>
Module: mod_core
Compatibility: 0.99.0 and later
The HideNoAccess directive configures a <Directory> or <Anonymous> block to hide all directory entries in a directory listing (via the LIST or NLST FTP commands) to which the current logged-in, authenticated user has no access to. Normal Unix-style permissions always apply, so that although a user may not be able to see a directory entry that has HideNoAccess 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 IgnoreHidden in conjunction with HideNoAccess.
See Also: HideUser, HideGroup, IgnoreHidden
Syntax: HostRatio foo1 foo2 foo3
Default: None known
Context: <Directory>, <Anonymous>,
<Limit>, .ftpaccess
Module: mod_ratio
Compatibility: at least 1.2.0 and later
The HostRatio directive .... INCOMPLETE
Example:
HostRatio
Syntax: HostsAllowSyslogLevel facility-level
Default: none
Context: server, <Anonymous>, <VirtualHost>
Module: mod_wrap
Compatibility: 1.2.0 and later
Proftpd can log when a connection is allowed as the result of a rule in the file specified in UseHostsAllowFile to the Unix syslog mechanism. A discussion on the facility levels which can be used is given in the SyslogFacility directive
.See Also: HostsDenySyslogLevel
Example: HostsAllowSyslogLevel local3
Syntax: HostsDenySyslogLevel facility-level
Default: none
Context: server, <Anonymous>, <VirtualHost>
Module: mod_wrap
Compatibility: 1.2.0 and later
Proftpd can log when a connection is rejected as the result of a rule in the file specified in UseHostsAllowFile to the Unix syslog mechanism. A discussion on the facility levels which can be used is given in the SyslogFacility directive
.See Also: HostsAllowSyslogLevel
Example: HostsDenySyslogLevel local3
Syntax: HideUser userid
Default: None
Context: <Directory>, <Anonymous>
Module: mod_core
Compatibility: 0.99.0 and later
The HideUser directive configures a <Directory> or <Anonymous> block to hide all directory entries owned by the specified user, unless the owning user is the currently logged-in, authenticated user. Normally, hidden directories and files cannot be seen via LIST or NLST commands but can be operated on via other FTP commands (CWD, DELE, RETR, etc). This behavior can be modified via the IgnoreHidden directive.
See Also: HideGroup, HideNoAccess, IgnoreHidden
Syntax: IdentLookups on|off
Default: on
Context: server config, <VirtualHost>, <Global>
Module: mod_core
Compatibility: 1.1.5 and later
Normally, when a client initially connects to proftpd, the ident protocol (RFC1413) is used to attempt to identify the remote username. This can be controlled via the IdentLookups directive.
Syntax: IgnoreHidden on|off
Default: offbr>
Context: <Limit>
Module: mod_core
Compatibility: 0.99.0 and later
Normally, files hidden via HideNoAccess, HideUser or HideGroup can be operated on by all FTP commands (assuming Unix file permissions allow access), even though they do not appear in directory listings. Additionally, even when normal file system permissions disallow access, proftpd returns a "Permission denied" error to the client, indicating that the requested object does exist, even if it cannot be acted upon. IgnoreHidden configures a <Limit> block to completely ignore any hidden directory entries for the set of limited FTP commands. This has the effect of returning an error similar to "No such file or directory" when the client attempts to use the limited command upon a hidden directory or file.
Syntax: Include file
Default: None
Context: Any
Module: mod_core
Compatibility: 1.2.0 and later
This directive allows you to include another configuration file within your current configuration file.
Syntax: <Limit command|command-group [command2 ..]>
Default: None
Context: server config, <VirtualHost>, <Directory>, <Anonymous>, <Global>, .ftpaccess
Module: mod_core
Compatibility: 0.99.0 and later
The Limit configuration block is used to place access restrictions on one or more FTP commands, within a given context. Limits flow downward, so that a Limit configuration in the server config context applies to all <Directory> and <Anonymous> blocks that also reside in the configuration; until it is overridden by a "lower" <Limit> block. Any number of command parameters can be specified, against which the contents of the <Limit> block will be applied. command can be any valid FTP command, but is generally one of the following:
In addition, the following command-groups are accepted. They have a lower precedence than real commands, meaning that a real command limit will always be applied instead of the command-group.
Finally, a special command is allowed which can be used to control login access:
<Limit> command restrictions should not be confused with file/directory access permission. While limits can be used to restrict a command on a certain directory, they cannot be used to override the file permissions inherent to the base operating/file system.
See Also: IgnoreHidden
Syntax: LDAPAuthBinds on|off
Default: off
Context: server config, <VirtualHost>, <Global>
Module: mod_ldap
Compatibility: mod_ldap v2.5 and later
Specifies whether to use authenticated binds. Normally, a privileged
LDAP DN will be used to bind to the LDAP server to obtain user
information, including the userPassword attribute. If
LDAPAuthBinds is set to on, the DN specified
by LDAPDNInfo will be used to fetch all user information
except the userPassword attribute. Then, mod_ldap will bind to the LDAP
server as the user who is logging in via FTP with the user-supplied
password. If this bind succeeds, the user is considered authenticated
and is allowed to log in. This method of LDAP authentication has the
added benefit of supporting any password encryption scheme that your
LDAP server supports.
Syntax: LDAPDefaultAuthScheme crypt|clear
Default: "crypt"
Context: server config, <VirtualHost>, <Global>
Module: mod_ldap
Compatibility: mod_ldap v2.0 and later
Specifies the authentication scheme used for passwords with no {prefix}
in the LDAP database. For example, if you are using something like
userPassword: mypass in your LDAP database, you would want to set
LDAPDefaultAuthScheme to clear.
Syntax: LDAPDefaultGID default-gid
Default: None
Context: server config, <VirtualHost>, <Global>
Module: mod_ldap
Compatibility: mod_ldap v2.0 and later
This directive is useful primarily in virtual-user environments common in large-scale ISPs and hosting organizations. If a user does not have a LDAP gidNumber attribute, the LDAPDefaultGID is used. This allows one to have a large number of users in an LDAP database without gidNumber attributes; setting this configuration directive will automatically assign those users a single GID.
Syntax: LDAPDefaultUID default-uid
Default: None
Context: server config, <VirtualHost>, <Global>
Module: mod_ldap
Compatibility: mod_ldap v2.0 and later
This directive is useful primarily in virtual-user environments common in large-scale ISPs and hosting organizations. If a user does not have a LDAP uidNumber attribute, the LDAPDefaultUID is used. This allows one to have a large number of users in an LDAP database without uidNumber attributes; setting this configuration directive will automatically assign those users a single UID.
Syntax: LDAPDNInfo "ldap-dn" "dn-password"
Default: "" "" (anonymous bind)
Context: server config, <VirtualHost>, <Global>
Module: mod_ldap
Compatibility: mod_ldap v2.0 and later
This directive specifies the LDAP DN and password to use when binding to the LDAP server. If this configuration directive is not specified, anonymous binds are used.
Syntax: LDAPDoAuth on|off "auth-base-prefix" "search-filter-template"
Default: off
Context: server config, <VirtualHost>, <Global>
Module: mod_ldap
Compatibility: mod_ldap v2.0 and later
This configuration directive activates LDAP authentication. The second argument to this directive is the LDAP prefix to use for authentication. The third argument is a template to be used for the search filter; %u will be replaced with the username that is being authenticated. By default, the search filter template "(&(uid=%u)(objectclass=posixAccount))" is used. Search filter templates are only supported in mod_ldap v2.7 and later.
Syntax: LDAPDoUIDLookups on|off "uid-base-prefix" "search-filter-template"
Default: off
Context: server config, <VirtualHost>, <Global>
Module: mod_ldap
Compatibility: mod_ldap v2.0 and later
This configuration directive activates LDAP UID-to-name lookups in directory listings. The second argument to this directive is the LDAP prefix to use for UID-to-name lookups. The third argument is a template to be used for the search filter; %u will be replaced with the UID that is being looked up. By default, the search filter template "(&(uidNumber=%u)(objectclass=posixAccount))" is used. Search filter templates are only supported in mod_ldap v2.7 and later.
Syntax: LDAPDoGIDLookups on|off "uid-base-prefix" "search-filter-template"
Default: off
Context: server config, <VirtualHost>, <Global>
Module: mod_ldap
Compatibility: mod_ldap v2.0 and later
This configuration directive activates LDAP GID-to-name lookups in directory listings. The second argument to this directive is the LDAP prefix to use for GID-to-name lookups. The third argument is a template to be used for the search filter; %u will be replaced with the GID that is being looked up. By default, the search filter template "(&(gidNumber=%u)(objectclass=posixGroup))" is used. Search filter templates are only supported in mod_ldap v2.7 and later.
Syntax: LDAPHomedirOnDemand on|off directory-mode
Default: off
Context: server config, <VirtualHost>, <Global>
Module: mod_ldap
Compatibility: mod_ldap v2.0 and later
LDAPHomedirOnDemand activates on-demand home directory creation. If a user logs in and does not yet have a home directory, a home directory is created automatically. The home directory will be owned by the same user and group that ProFTPD is running as (see the User and Group configuration directives). The second argument allows you to specify the mode (default permissions) to use when creating home directories on demand. If no directory mode is specified, the default of 0755 is used. Directory mode setting is only supported in mod_ldap v2.7 or later.
Syntax: LDAPHomedirOnDemandSuffix "additional-directory"
Default: ""
Context: server config, <VirtualHost>, <Global>
Module: mod_ldap
Compatibility: mod_ldap v2.6 and later
LDAPHomedirOnDemandSuffix allows you to specify an additional directory to be created within a user's home directory when it is created on demand. For example, if a user's home directory is "/home/user", setting this configuration directive to "public_html" will also create "/home/user/public_html" on demand. To use this feature, you must also activate LDAPHomedirOnDemand in your configuration.
Syntax: LDAPNegativeCache on|off
Default: off
Context: server config, <VirtualHost>, <Global>
Module: mod_ldap
Compatibility: mod_ldap v1.1 and later
LDAPNegativeCache specifies whether or not to cache negative responses from the LDAP server when using LDAP for UID/GID lookups. This option is useful if you also use/are in transition from another authentication system; if there are many users in your old authentication system that aren't in the LDAP database, there can be a significant delay when a directory listing is performed as the UIDs not in the LDAP database are repeatedly looked up in an attempt to present usernames instead of UIDs in directory listings. With LDAPNegativeCache set to on, negative ("not found") responses from the LDAP server will be cached and speed will improve on directory listings that contain many users not present in the LDAP database.
Syntax: LDAPQueryTimeout timeout-seconds
Default: default-api-timeout
Context: server config, <VirtualHost>, <Global>
Module: mod_ldap
Compatibility: mod_ldap v2.0 and later
Sets the timeout used for LDAP directory queries. The default is the default timeout used by your LDAP API.
Syntax: LDAPSearchScope onelevel|subtree
Default: subtree
Context: server config, <VirtualHost>, <Global>
Module: mod_ldap
Compatibility: mod_ldap v2.6 and later
Set the scope used for LDAP searches. The default setting, subtree, searches for all entries in the tree from the current level down. Setting this directive to onelevel searches only one level deep in the LDAP tree.
Syntax: LDAPServer "hostname1:port hostname2:port ..."
Default: "localhost"
Context: server config, <VirtualHost>, <Global>
Module: mod_ldap
Compatibility: mod_ldap v1.0 and later
LDAPServer allows you to to specify the hostname(s) and port(s) of the LDAP server(s) to use for LDAP authentication. If no LDAPServer configuration directive is present, the default LDAP servers specified by your LDAP API will be used.
Syntax: LeechRatioMsg foo1 foo2 foo3
Default: None known
Context: <Directory>, <Anonymous>, <Limit>,.ftpaccess
Module: mod_ratio
Compatibility: at least 1.2.0 and later
The LeechRatioMsg directive defines the response message sent back to the client upon breaking their quota limits.
Example:
LeechRatioMsg "please upload as well as download"
Syntax: LogFormat nickname "format-string"
Default: default "%h %l %u %t \"%r\" %s %b"
Context: server config
Module: mod_log
Compatibility: 1.1.6pl1 and later
The LogFormat directive can be used to create a custom logging format for use with the ExtendedLog directive. Once created, the format can be referenced by the specified nickname.
The format-string argument can consist of any combination of letters, numbers and symbols. The special character % is used to start a meta-sequence (see below). To insert a literal % character, use %%. The following meta sequences are available and are replaced as indicated when logging.
| %A | Anonymous username (password given), or UNKNOWN if non-anonymous | |
| %b | Bytes sent for request | |
| %f | Filename stored or retrieved, absolute path (not chrooted) | |
| %F | Filename stored or retrieved, as the client sees it | |
| %{FOOBAR}e | Contents of environment variable FOOBAR | |
| %h | Remote host name | |
| %a | Remote IP address | |
| %l | Remote username (from ident), or UNKNOWN if ident lookup failed | |
| %m | Command (method) name received from client, e.g., RETR | |
| %p | Local server port number | |
| %v | Local server name | |
| %P | Local server process id (pid) | |
| %r | Full command line received from client | |
| %t | Current local time | |
| %{format}t | Current local time formatted (strftime(3) format) | |
| %T | Time taken to transmit/receive file, in seconds | |
| %s | Numeric FTP response code (status) | |
| %u | Local authenticated userid |
See Also: ExtendedLog, TransferLog
Syntax: LoginPasswordPrompt on|off
Default: on
Context: server config, <VirtualHost>, <Anonymous>,
<Global>
Module: mod_auth
Compatibility: 1.2.0pre1 and later
If set to off, ProFTPd will skip the password request if the
login will be denied regardless of password, e.g., if a <Limit LOGIN>
directive forbids the connection.
Syntax: LsDefaultOptions "options string"
Default: None
Context: server config, <VirtualHost>, <Anonymous>, <Global>
Module: mod_ls
Compatibility: 1.1.6 and later
Normally, FTP commands involving directory listings (NLST, LIST and STAT) use the arguments (options) passed by the client to determine what files are displayed and the format they are displayed in. Using the LsDefaultOptions directive can alter the default behavior of such listings, but implying that a certain option (or options) is always present. For example, to force all directory listings to always display ".dotfiles", one might:
LsDefaultOptions "-a"
Syntax: MaxClients number|none [message]
Default: none
Context: server config, <Anonymous>, <VirtualHost>,
<Global>
Module: mod_core
Compatibility: 0.99.0 and later
The MaxClients directive configures the maximum number of authenticated clients which may be logged into a server or anonymous account. Once this limit is reached, additional clients attempting to authenticate will be disconnected.
The special value none may be supplied which removes all maximum connection limits from the applicable configuration context. Additionally, an optional message argument may be used which will be displayed to a client attempting to exceed the maximum value; immediately before disconnection. The message argument is parsed for the magic string "%m", which is replaced with the configured maximum value. If message is not supplied, a system-wide default message is used.
Example:
MaxClients 5 "Sorry, the maximum number of allowed users are already
connected (%m)"
Results in:
530 Sorry, the maximum number of allowed users are already connected
(5)
Syntax: MaxClientsPerHost number|none [message]
Default: none
Context: server config, <Anonymous>, <VirtualHost>,
<Global>
Module: mod_core
Compatibility: 1.1.7 and later
The MaxClientsPerHost directive configures the maximum number of clients allowed to connect per host. The optional argument message may be used which will be displayed to a client attempting to exceed the maximum value. If message is not supplied, a system-wide default message is used.
Example:
MaxClientsPerHost 1 "Sorry, you may not connect more than one
time."
Results in:
530 Sorry, you may not connect more than one time.
Syntax: MaxClientsPerUser number|none [message]
Default: none
Context: server config, <Anonymous>, <VirtualHost>, <Global>
Module: mod_core
Compatibility: 1.2.0 and later
The MaxClientsPerUser directive configures the maximum number of authenticated clients that can log into the server for any given user. This is to limit the effect of some of the more popular ftp clients which can open multiple connections to a server and perform parallel downloads. Once the limit is reached additional authentication attempts will be disconnected.
An optional message argument may be used which will be displayed to a client attempting to exceed the maximum value; immediately before disconnection. The message argument is parsed for the magic string "%m", which is replaced with the configured maximum value. If message is not supplied, a system-wide default message is used.
Example:
MaxClientsPerUser 1 "Please do not abuse this facility
you are already connected %m times from your host."
Results in:
530 Please do not abuse this facility you are already
connected 1 times from your host.
Syntax: MaxInstances number
Default: none
Context: server config
Module: mod_core
Compatibility: 1.1.6pl1
The MaxInstances directive configures the maximum number of child processes that may be spawned by a parent proftpd process in standalone mode. The directive has no effect when used on a server running in inetd mode.
Because each child proftpd process represents a single client connection, this directive also controls the maximum number of simultaneous connections allowed. Additional connections beyond the configured limit are syslog'd and silently disconnected. The MaxInstances directive can be used to prevent undesirable denial-of-service attacks (repeatedly connecting to the ftp port, causing proftpd to fork-bomb). By default, no limit is placed on the number of child processes that may run at one time.
Syntax: MaxLoginAttempts number
Default: 3
Context: server config, <VirtualHost>, <Global>
Module: mod_core
Compatibility: 0.99.0 and later
The MaxLoginAttempts directive configures the maximum number of times a client may attempt to authenticate to the server during a given connection. After the number of attempts exceeds this value, the user is disconnected and an appropriate message is logged via the syslog mechanism.
Syntax: MySQLInfo hostname sqluser sqlpass dbname
Default: none
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: at least 1.2.0 and later
This directive is deprecated, use SQLConnectInfo instead.
Configures the MySQL database driver (the database may be remote). A connection isn't made until use of a SQL feature requires it, after which it may be held open for the lifetime of the FTP session depending on the directives in use. Use `""' to specify a null password.
Syntax: MultilineRFC2228 on|off
Default: off
Context: server config
Module: mod_core
Compatibility: 1.2.0pre3 and later
By default, proftpd sends multiline responses as per RFC 959, i.e.:
200-First line More lines... 200 Last lineRFC 2228 specifies that "6xy" response codes will be sent as follows:
600-First line 600-More lines... 600 Last lineNote that 2228 ONLY specifies this for response codes starting with '6'. Enabling this directive causes ALL responses to be sent in this format, which may be more compatible with certain web browsers and clients. Also note that this is NOT the same as wu-ftpd's multiline responses, which do not comply with any RFC. Using this method of multilines is more likely to be compatible with all clients, although it isn't strictly RFC, and is thus not enabled by default.
Syntax: Order allow,deny|deny,allow
Default: allow,deny
Context: <Limit>
Module: mod_core
Compatibility: 0.99.0pl6 and later
The Order directive configures the order in which Allow and Deny directives are checked inside of a <Limit> block. Because Allow directives are permissive, and Deny directives restrictive, the order in which they are examined can significantly alter the way security functions.
If the default setting of allow,deny is used, "allowed" access permissions are checked first. If an Allow directive explicitly allows access to the <Limit> context, access is granted and any Deny directives are never checked. If Allow did not explicitly permit access, Deny directives are checked. If any Deny directive applies, access is explicitly denied. Otherwise, access is granted.
When deny,allow is used, "deny" access restrictions are checked first. If any restriction applies, access is denied immediately. If nothing is denied, Allow permissions are checked. If an Allow explicitly permits access, access to the entire context is permitted; otherwise access is implicitly denied.
For clarification, the following illustrates the steps used when checking Allow/Deny access:
Order allow,deny
Order deny,allow
Syntax: PassivePorts min-pasv-port max-pasv-port
Default: none
Context: server config, <VirtualHost>, <Global>
Module: mod_core
Compatibility: 1.2.0rc3 and later
PassivePorts restricts the range of ports from which the server will select when sent the PASV command from a client. The server will randomly choose a number from within the specified range until an open port is found. Should no open ports be found within the given range, the server will default to a normal kernel-assigned port, and a message logged.
The port range selected must be in the non-privileged range (eg greater than or equal to 1024); it is STRONGLY RECOMMENDED that the chosen range be large enough to handle many simultaneous passive connections (for example, 49152-65534, the IANA-registered ephemeral port range).
Syntax: PathAllowFilter regular-expression
Default: None
Context: server config, <VirtualHost>, <Anonymous>,
<Global>
Module: mod_core
Compatibility: 1.1.7 and later
PathAllowFilter allows the configuration of a regular expression that must be matched for all newly uploaded (stored) files. The regular expression is applied against the entire pathname specified by the client, so care must be taken when creating a proper regex. Paths that fail the regex match result in a "Forbidden filename" error being returned to the client.
If the regular-expression argument contains whitespace, it must be enclosed in quotes.
Example:
# Only allow filenames containing alphanumeric characters
PathAllowFilter ".*/[a-zA-Z0-9]+$"
Syntax: PathDenyFilter regular-expression
Default: None
Context: server config, <VirtualHost>, <Anonymous>,
<Global>
Module: mod_core
Compatibility: 1.1.7 and later
Similar to PathAllowFilter, PathDenyFilter specifies a regular expression which must not match any uploaded pathnames. If the regex does match, a "Forbidden filename" error is returned to the client. This can be especially useful for forbidding .ftpaccess or .htaccess files.
Example:
# We don't want .ftpaccess or .htaccess files to be uploaded
PathDenyFilter "(\\.ftpaccess)|(\\.htaccess)$"
Syntax: PersistentPasswd on|off
Default: Platform dependent
Context: server config
Module: mod_unixpw
Compatibility: 1.1.5 and later
The PersistentPasswd directive controls how proftpd handles authentication, user/group lookups, and user/group to name mapping. If set to On, proftpd will attempt to open the system-wide /etc/passwd, /etc/group (and /etc/shadow, potentially) files itself, holding them open even during a chroot()ed login (note that /etc/shadow is never held open, for security reasons). On some platforms, you must turn this option on, as the libc functions are incapable of accessing these databases from inside of a chroot(). At configure-time, the configuration script will attempt to detect whether or not you need this support, and make it the default. However, such "guessing" may fail, and you will have to manually enable or disable the feature. If you cannot see user or group names when performing a directory listing inside an anonymous chrooted login, this indicates you must enable the directive. Use of the AuthUserFile or AuthGroupFile directives will force partial support for persistent user or group database files; regardless of PersistentPasswd's setting.
Note: NIS or NIS+ users will most likely want to disable this feature, regardless of proftpd's detected configuration defaults. Failure to disable this will make your NIS/NIS+ maps not work!
Syntax: PidFile filename
Default: none
Context: server config, <Global>
Module: mod_core
Compatibility: 1.2.0rc2 and later
The PidFile directive sets the file to which the server records the process id of the daemon. The filename should be relative to the system root, ie /var/run/proftpd/pidfile. The PidFile is only used in standalone mode.
It is often useful to be able to send the server a signal, so that it closes and then reopens its ErrorLog and TransferLog, and re-reads its configuration files. This is done by sending a SIGHUP (kill -1) signal to the process id of the master daemon listed in the PidFile.
Syntax: Port port-number
Default: 21
Context: server config, <VirtualHost>
Module: mod_core
Compatibility: 0.99.0 and later
The Port directive configures the tcp port which proftpd will listen on while running in standalone mode. It has no effect when used upon a server running in inetd mode (see ServerType). The directive can be used in conjunction with <VirtualHost> in order to run a virtual server on the same IP address as the master server, but listening on a different port.
Syntax: PostgresInfo hostname sqluser sqlpass dbname
Default: none
Context: server config, <VirtualHost>
Module: mod_sql
Compatibility: at least 1.2.0 and later
This directive is deprecated, use SQLConnectInfo instead.
Configures the Posgresql database driver (the database may be remote). A connection isn't made until use of a SQL feature requires it, after which it may be held open for the lifetime of the FTP session depending on the directives in use.
Example:
PostgresInfo myserver.example.com proftpd wibble ftpusers
Syntax: PostgresPort port-number
Default: 5432
Context: <Directory>, <VirtualHost>
Module: mod_sql
Compatibility: at least 1.2.0 and later
This directive is deprecated, use SQLConnectInfo instead.
Specifies which TCP/IP port to use for connecting. Default is 5432, or UNIX socket for localhost.
Example:
PostgresPort 3306
Syntax: Quotas on|off
Default: none
Context: server, <VirtualHost>, <Anonymous>
Module: mod_quota
Compatibility: at least 1.2.0 and later
The Quotas directive enables or disables Quota support.
Example:
Quotas on
Syntax: QuotaBlockSize number of bytes
Default: None
Context: server, <VirtualHost>, <Anonymous>
Module: mod_quota
Compatibility: at least 1.2.0 and later
The QuotaBlockSize directive is used in conjuntion with the QuotaBlockName directive to control how the user output is handled. QuotaBlockSize specifies the factor by which the values in the user reports are divided before display.
Example:
QuotaBlockSize 1024
Syntax: QuotaBlockName name
Default: byte
Context: server, <VirtualHost>, <Anonymous>
Module: mod_quota
Compatibility: at least 1.2.0 and later
The QuotaBlockName directive is used in conjunction with the QuotaBlockSize directive to control user output from the module. This directive specifies the name given to the values displayed (ie byte, kilobyte, kb etc etc).
Example:
QuotaBlockName kb
Syntax: QuotaCalc foo1 foo2 foo3
Default: None
Context: server, <VirtualHost>, <Anonymous>
Module: mod_quota
Compatibility: at least 1.2.0 and later
The QuotaCalc directive controls whether calculation is done on the fly. If the directive is set to 'on' and either there is no .quota file or the quota would go negative then calculation is done on the fly rather than at the end of the session.
Syntax: QuotaExempt uid, uid, uid
Default: None
Context: server, <VirtualHost>, <Anonymous>
Module: mod_quota
Compatibility: at least 1.2.0 and later
The QuotaExempt directive lists the UIDs which are not subject to quota controls, using UIDs rather than symbolic user names speeds up the loading and resolution process.
Example:
QuotaExempt 3000,3401,500
Syntax: QuotaType soft|hard
Default: soft
Context: server, <VirtualHost>, <Anonymous>
Module: mod_quota
Compatibility: at least 1.2.0 and later
The QuotaType directive defines what happens to files which break the quota limits as they are uploaded. Setting the type to hard ensures that the file which violates the quota is deleted.
uploaded.Syntax: RateReadBPS byte_per_sec-number
Default: 0
Context: server config, <VirtualHost>, <Anonymous>,
<Directory>, <Global>
Module: mod_xfer
Compatibility: 1.2.0 and later
RateReadBPS sets the allowed byte per second download bandwidth in the given config context. Zero means no bandwidth limit. (See RateReadFreeBytes about limiting bandwidth only after some amount of downloaded bytes.) The usual place for this directive is in <VirtualHost> or <Directory> sections.
Syntax: RateReadFreeBytes number of bytes
Default: 0
Context: server config, <VirtualHost>, <Anonymous>,
<Directory>, <Global>
Module: mod_xfer
Compatibility: 1.2.0 and later
RateReadFreeBytes is the amount of bytes to be transferred without any bandwidth limits, so with that option you can give full bandwidth for small files while limiting big ones. (See RateReadHardBPS on further info about what happens after the free amount was transferred.)
Syntax: RateReadHardBPS on/off
Default: off
Context: server config, <VirtualHost>, <Anonymous>,
<Directory>, <Global>
Module: mod_xfer
Compatibility: 1.2.0 and later
RateReadHardBPS forces the bandwidth to the given RateReadBPS value after the RateReadFreeBytes amount of file was transfered. This means that if the user have huge bandwidth and downloaded the "free" amount fast, HardBPS will stop the transfer until the average goes down to the given limit. If the amount of FreeBytes is high and the ReadBPS is low then the user may wait for extended periods of time until the transfer continues. :-)
Syntax: RateWriteBPS byte_per_sec-number
Default: 0
Context: server config, <VirtualHost>, <Anonymous>, <Directory>, <Global>
Module: mod_xfer
Compatibility: 1.2.0 and later
RateWriteBPS sets the allowed byte per second upload bandwidth in the given config context. Zero means no bandwidth limit. (See RateWriteFreeBytes about limiting bandwidth only after some amount of uploaded bytes.) The usual place for this directive is in <VirtualHost> or <Directory> sections.
Syntax: RateWriteFreeBytes number of bytes
Default: 0
Context: server config, <VirtualHost>, <Anonymous>,
<Directory>, <Global>
Module: mod_xfer
Compatibility: 1.2.0 and later
RateWriteFreeBytes is the amount of bytes to be transferred without any bandwidth limits, so with that option you can give full bandwidth for small files while limiting big ones. (See RateWriteHardBPS on further info about what happens after the free amount was transferred.)
Syntax: RateWriteHardBPS on/off
Default: off
Context: server config, <VirtualHost>, <Anonymous>,
<Directory>, <Global>
Module: mod_xfer
Compatibility: 1.2.0 and later
RateWriteHardBPS forces the bandwidth to the given RateWriteBPS value after the RateWriteFreeBytes amount of file was transfered. This means that if the user have huge bandwidth and uploaded the "free" amount fast, HardBPS will stop the transfer until the average goes down to the given limit. If the amount of FreeBytes is high and the WriteBPS is low then the user may wait for extended periods of time until the transfer continues. :-)
Syntax: RatioFile foo1 foo2 foo3
Default: None known
Context: <Directory>, <Anonymous>,
<Limit>, .ftpaccess
Module: mod_ratio
Compatibility: at least 1.2.0 and later
The RatioFile directive .... INCOMPLETE
Example:
RatioFile
Syntax: Ratios foo1 foo2 foo3
Default: None known
Context: <Directory>, <Anonymous>,
<Limit>, .ftpaccess
Module: mod_ratio
Compatibility: at least 1.2.0 and later
The Ratios directive .... INCOMPLETE
Example:
Ratios
Syntax: RatioTempFile foo1 foo2 foo3
Default: None known
Context: <Directory>, <Anonymous>,
<Limit>, .ftpaccess
Module: mod_ratio
Compatibility: at least 1.2.0 and later
The RatioTempFile directive .... INCOMPLETE
Example:
RatioTempFile
Syntax: RequireValidShell on|off
Default: on
Context: server config, <VirtualHost>, <Anonymous>,
<Global>
Module: mod_core
Compatibility: 0.99.0 and later
The RequireValidShell directive configures the server, virtual host or anonymous login to allow or deny logins which do not have a shell binary listed in /etc/shells. By default, proftpd disallows logins if the user's default shell is not listed in /etc/shells. If /etc/shells cannot be found, all default shells are assumed to be valid.
Syntax: RootLogin on|off
Default: off
Context: server config, <VirtualHost>, <Anonymous>,
<Global>
Module: mod_auth
Compatibility: 1.1.5 and later
Normally, proftpd disallows root logins under any circumstance. If a client attempts to login as root, using the correct password, a special security message is sent to syslog. When the RootLogin directive is turned On, the root user may authenticate just as any other user could (assuming no other access control measures deny access); however the root login security message is still sysloged. Obviously, extreme care should be taken when using this directive.
Syntax: SaveRatios foo1 foo2 foo3
Default: None known
Context: <Directory>, <Anonymous>,
<Limit>, .ftpaccess
Module: mod_ratio
Compatibility: at least 1.2.0 and later
The SaveRatios directive .... INCOMPLETE
Example:
SaveRatios
Syntax: ScoreboardPath path
Default: /var/run
Context: server config
Module: mod_core
Compatibility: 1.1.6 and later
The ScoreboardPath directive sets the directory where proftpd run-time scoreboard files (proftpd-*) are kept. These file(s) are necessary for MaxClients to work properly, as well as other utilities (such as ftpwho and ftpcount).
Syntax: "admin-email-address"
Default: root@[ServerName]
Context: server config, <VirtualHost>
Module: mod_core
Compatibility: 0.99.0pl10 and later
The ServerAdmin directive sets the email address of the administrator for the server or virtualhost. This address is displayed in magic cookie replacements (see DisplayLogin and DisplayFirstChdir).
Syntax: off|on [identification string]
Default: ProFTPD [version] Server (server name) [hostname]
Context: server config, <VirtualHost>, <Global>
Module: mod_core
Compatibility: 1.2.0pre2 and later
The ServerIdent directive sets the default message displayed when
a new client connects. Setting this to
off displays "[hostname] FTP
server ready." If set to on, 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
ServerIdent on "FTP Server ready.", which won't even
reveal the hostname.
Syntax: ServerName "name"
Default: "ProFTPD Server [version]"
Context: server config, <VirtualHost>
Module: mod_core
Compatibility: 0.99.0 and later
The ServerName directive configures the string that will be displayed to a user connecting to the server (or virtual server if the directive is located in a <VirtualHost> block).
See Also: <VirtualHost>
Syntax: ServerType type-identifier
Default: standalone
Context: server config
Module: mod_core
Compatibility: 0.99.0 and later
The ServerType directive configures the server daemon's operating mode. The type-identifier can be one of two values:
Syntax: ShowDotFiles on|off
Default: Off
Context: server config, <VirtualHost>, <Anonymous>, <Global>
Module: mod_ls
Compatibility: 0.99.0pl6 and later -- Deprecated
If set to on, files starting with a '.', except for the
directories '.' and '..', will be displayed in
directory listings. This directive has been deprecated in favor of
LsDefaultOptions -- e.g., LsDefaultOptions
"-A" -- and may be removed in future versions.
See Also: LsDefaultOptions
Syntax: ShowSymlinks on|off
Default: on
Context: server config, <VirtualHost>, <Anonymous>, <Global>
Module: mod_core
Compatibility: 0.99.0pl6 and later
Symbolic links (if supported on the host OS and filesystem) can be either shown in directory listings (including the target of the link) or can be "hidden" (proftpd dereferences symlinks and reports the target's permissions and ownership). The default behavior is to show all symbolic links when normal users are logged in, and hide them for anonymous sessions. If a symbolic link cannot be dereferenced for any reason (permissions, target does not exist, etc) and ShowSymlinks is off, proftpd displays the link as a directory entry of type 'l' (link) with the ownership and permissions of the actual link.
Under ProFTPD versions 1.1.5 and higher, the default behavior in regard to ShowSymlinks has been changed so that symbolic links are always displayed as such (in all cases), unless ShowSymlinks off is explicitly set.
Syntax: SocketBindTight on|off
Default: off
Context: server config
Module: mod_core
Compatibility: 0.99.0pl6 and later
The SocketBindTight directive controls how proftpd creates and binds its initial tcp listen sockets in standalone mode (see ServerType). The directive has no effect upon servers running in inetd mode, because listen sockets are not needed or created. When SocketBindTight is set to off (the default), a single listening socket is created for each port that the server must listen on, regardless of the number of IP addresses being used by <VirtualHost> configurations. This has the benefit of typically requiring a relatively small number of file descriptors for the master daemon process, even if a large number of virtual servers are configured. If SocketBindTight is set to on, a listen socket is created and bound to a specific IP address for the master server and all configured virtual servers. This allows for situations where an administrator may wish to have a particular port be used by both proftpd (on one IP address) and another daemon (on a different IP address). The drawback is that considerably more file descriptors will be required if a large number of virtual servers must be supported.
Example: Two servers have been configured (one master and one virtual), with the IP addresses 10.0.0.1 and 10.0.0.2, respectively. The 10.0.0.1 server runs on port 21, while 10.0.0.2 runs on port 2001.
SocketBindTight off
#default
# proftpd creates two sockets, both bound to ALL
available addresses.
# one socket listens on port 21, the
other on 2001. Because each socket is
# bound to all available
addresses, no other daemon or user process will be
# allowed
to bind to ports 21 or 2001.
...
SocketBindTight on
#
proftpd creates two sockets again, however one is bound to
10.0.0.1, port 21
# and the other to 10.0.0.2, port
2001. Because these sockets are "tightly"
# bound to
IP addresses, port 21 can be reused on any address OTHER than
# 10.0.0.1, and visa-versa with 10.0.0.2, port 2001.
One side-effect of setting SocketBindTight to on is that connections to non-bound addresses will result in a "connection refused" message rather than the typical "500 Sorry, no server available to handle request on xxx.xxx.xxx.xxx.", due to the fact that no listen socket has been bound to the particular address/port pair. This may or may not be aesthetically desirable, depending on your circumstances.
Syntax: SQLAuthTypes OpenSSL|Crypt|Backend|Plaintext|Empty
Default: none
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
This directive deprecates 'SQLEmptyPasswords', 'SQLScrambledPasswords', 'SQLSSLHashedPasswords', 'SQLPlaintextPasswords', and 'SQLEncryptedPasswords'.
Specifies the allowed authentication types and their check order. There must be at least one authentication method specified
SQLAuthTypes Crypt Empty
The above configuration fragment means check whether the password in the database matches in UNIX crypt() format; if that fails, check to see if the password in the database is empty (matching ANY given password); if that fails, mod_sql refuses to authenticate the user.
Currently supported types
Syntax: SQLAuthoritative on|off
Default: off
Context: server config
Module: mod_sql
Compatibility: 1.2.0rc2 and later
Specifies whether authentication stops at mod_mysql, or whether other possibilites (like standard UNIX logins) are tried. Default is off - other handlers will be tried.
This is a *very* powerful directive. If SQLAuthoritative is set, *all* authorization goes through your SQL database -- group lookups, uid lookups, etc. See the 'SQLDoAuth' and 'SQLDoGroupAuth' directives, too.
Syntax: SQLConnectInfo connection-info [username] [password]
Default: none
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
This directive deprecates 'MySQLInfo', 'PostgresInfo', and 'PostgresPort'.
Specifies connection information. Connection-info specifies the database, host, port, and other backend-specific information. username and password specify the username and password to connect as, respectively. Both default to NULL, which the backend will treat in some backend-specific manner. If you specify a password, you MUST specify a username.
Any given backend has the opportunity (but not the responsibility) to check for syntax errors in the connection-info field at proftpd startup, but you shouldn't expect semantic errors (i.e., can't connect to the database) to be caught until mod_sql attempts to connect for a given host.
The MySQL and Postgres backends connection-info is expected to be of the form:
database[@hostname][:port]
hostname will default to a backend-specific hostname (which happens to be 'localhost' for both the MySQL and Postgres backends), and port will default to a backend-specific default port (3306 for the MySQL backend, 5432 for the Postgres backend).
For example
Backends may require different information in the connection-info field; check your backend module for specifics.
Syntax: SQLDefaultGID number
Default: 65533
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
Sets the default GID for users. Must be greater than SQLMinID.
Syntax: SQLDefaultUID number
Default: 65533
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
Sets the default UID for users. Must be greater than SQLMinID.
Syntax: SQLDoAuth on|off
Default: on
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
Activates SQL authentication. This overrides all other directives -- SQLDoGroupAuth and SQLAuthoritative are ineffectual if SQLDoAuth is off.
Syntax: SQLDoGroupAuth on|off
Default: on
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
This directive causes mod_sql to pretend it has no group information. It necessarily breaks ALL CONFIG FILES up to 1.2.0rc2, since mod_sql now assumes that group information is available UNLESS this directive is set to OFF.
This DOESN'T override SQLAuthoritative -- if SQLAuthoritative is set to 'On' but SQLDoGroupAuth is set to 'Off', all group-related queries will fail without giving other modules the opportunity to handle them.
Prior to 1.2.0, there was no way to provide group information from the database. This caused a few bugs, and reduced the functionality of this module.
Syntax: SQLEmptyPasswords on|off
Default: off
Context: server config
Module: mod_sql
Compatibility: 1.2.0rc2 and later
This directive is DEPRECATED. Please use SQLAuthTypes instead.
Specifies whether an empty (non-NULL but zero-length) password is acceped from the database. Default is no, and truly NULL passwords are never accepted. If the retrieved password is empty then whatever password the user typed is accepted as valid, but the module logs a warning at debug level 4.
Example:
SQLEmptyPasswords on
Syntax: SQLEncryptedPasswords on|off
Default: on
Context: server config
Module: mod_sql
Compatibility: 1.2.0rc2 and later
This directive is DEPRECATED. Please use SQLAuthTypes instead.
Specifies whether the password in the database may be in UNIX crypt() format. Default is true, with this being the only check done. A tool for generating crypted password text may be found at ftp://ftp.linpeople.org/pub/People/lilo/source/makepasswd-1.07.tar.gz
Example:
SQLEncryptedPasswords off
Syntax: SQLGIDField fieldname
Default: gid
Context: server config
Module: mod_sql
Compatibility: 1.2.0rc2 and later
Specifies the field in the user table that holds the user's GID. When a GID is retrieved from the database it is checked against the value of SQLMinID. If the database has no value (missing column) or the retrieved value is less than SQLMinID, the user's GID is set to SQLDefaultGID.
Example:
SQLGidField custgid
Syntax: SQLGroupGIDField fieldname
Default: gid
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
Specifies the field in the group table that holds the group's GID.
Syntax: SQLGroupMembersField fieldname
Default: gid
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
Specifies the field in the group table that holds the group's member list.
Syntax: SQLGroupTable table
Default: groups
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
Specifies the name of the table that holds group information.
Syntax: SQLGroupnameField fieldname
Default: groupname
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
Specifies the field in the group table that holds the group name.
Syntax: SQLHomedir /path/to/virtual/site
Default: none
Context: server config
Module: mod_sql
Compatibility: 1.2.0rc2 and later
Specifies the homedir to use for all users authenticated with this module, overriding any SQLHomedirField directive. If no homedir is set with either directive, authentication is turned off.
Example:
SQLHomedir /ftp/vhost/ftp.example.com/
Syntax: SQLHomedirField fieldname
Default: none
Context: server config
Module: mod_sql
Compatibility: 1.2.0rc2 and later
Specifies what field holds the home directory, for users authenticated with this module. The directory can also be defined for all users using SQLHomedir. If no homedir is set with either directive, authentication is turned off.
Example:
SQLHomedirField home
Syntax: SQLHomedirOnDemand on|off
Default: off
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
Specifies whether to automatically create a user's home directory if it doesn't exist at login.
Syntax: SQLKey key-value
Default: none
Context: server config, Global, VirtualHost
Module: mod_sql
Compatibility: 1.2.0 and later
This directive is DEPRECATED. Please use SQLWhereClause instead.
SQLKey
Syntax: SQLKeyField column-name
Default: none
Context: server config, Global, VirtualHost
Module: mod_sql
Compatibility: 1.2.0 and later
This directive is DEPRECATED. Please use SQLWhereClause instead.
SQLKeyField
Syntax: SQLLogDirs on
Syntax: SQLLogDirs fieldname
Default: off
Context: server config
Module: mod_sql
Compatibility: 1.2.0rc2 and later
Activates logging of the last directory the user changed to. This is done after every CHDIR command - the initial login to "/" does not count. Also, the last dir is displayed during login in this format:
230 "/pub/debian/Incoming" was last directory.
Example:
SQLLogDirs dirfield
Syntax: SQLLogHits hit-table
Syntax: SQLLogHits hit-table pathname-field hits-field
Syntax: SQLLogHits hit-table filename-field hits-field dir-field
Default: off, or `filename, hits' if fields unspecified
Context: server config
Module: mod_sql
Compatibility: only available with the Debian package.
Activates logging of RETR commands on a file to a separate table for this purpose. This is done during an approved RETR command, whether it completes or not.
If one argument is given, the `hits' field is incremented where the `filename' field matches the pathname requested for RETR. If three are given, the 2 extra strings are used for the pathname field and hits field.
If four arguments are given, the fourth string is used as the field name for logging the directory. In this case the real path is used -- symbolic links are dereferenced and the path split into dir and filename parts.
Syntax: SQLLogHosts on
Syntax: SQLLogHosts host-field ipaddr-field time-field
Default: off, or (`fhost faddr ftime') if fields unspecified
Context: server config
Module: mod_sql
Compatibility: at least 1.2.0 and later
Activates logging of host, IP, and last-login timestamp to the user database. (The time is inserted as `now'). This is done immediately after a successful PASS command.
Example:
SQLLogHosts on
Syntax: SQLLogHosts on|off
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
No details yet
Syntax: SQLLoginCountField fieldname
Default: none
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: at least 1.2.0 and later
Activates incrementation of a login count for the user, done with `set count = count + 1'. This is done immediately after a successful PASS command.
Example:
SQLLoginCountField logincount
Syntax: SQLLogStats on
Syntax: SQLLogStats F-stor-field F-retr-field B-stor-field B-retr-field
Default: off, or `fstor fretr bstor bretr"' if fields unspecified
Context: server config
Module: mod_sql
Compatibility: at least 1.2.0 and later
Activates logging of upload/download statistics for this user. This is updated after every successfully completed STOR and RETR, in a way that allows for concurrent transfers.
This directive is _required_ when using this module in conjunction with mod_ratio.
Example:
SQLLogStats off
Syntax: SQLPasswordField fieldname
Default: password
Context: server config
Module: mod_sql
Compatibility: 1.2.0rc2 and later
Using this directive activates SQL authentication functions, if a database driver is configured. It specifies which field holds the password, and has no default.
Example:
SQLPasswordField passwd
Syntax: SQLMinID minumumid
Default: 999
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
SQLMinID is checked whenever retrieving a user's GID or UID. If the retrieved values for GID or UID are less than the value of SQLMinID, they are reported as the values of, respectively, 'SQLDefaultGID' and 'SQLDefaultUID'.
Syntax: SQLPlaintextPasswords on|off
Default: off
Context: server config
Module: mod_sql
Compatibility: at least 1.2.0 and later
This directive is DEPRECATED. Please use SQLAuthTypes instead.
Specifies whether the two passwords should be compared as plaintext. Default is no - passwords must be UNIX DES-encrypted (the default). Setting this does not turn off other tests.
Example:
SQLPlaintextPasswords on
Syntax: SQLRatios foo1 foo2 foo3
Default: None known
Context: <Directory>, <Anonymous>,
<Limit>, .ftpaccess
Module: mod_sql
Compatibility: at least 1.2.0 and later
The SQLRatios directive .... INCOMPLETE
Example:
SQLRatios
Syntax: SQLShellField fieldname
Default: shell
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
Specifies the field in the user table that holds the user's shell. If this field doesn't exist or the result of the query is NULL, the shell is reported as "".
Syntax: SQLUidField fieldname
Default: none, UID is 655533
Context: server config
Module: mod_sql
Compatibility: at least 1.2.0 and later
Specifes what field holds the uid number, for users authenticated with this module. Default is to use the compiled-in default 65533. If the retrieved uid is in the range reserved for admin accounts (0-9999), 65533 is used instead.
Example:
SQLUidField custuid
Syntax: SQLUserTable tablename
Default: users
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0rc2 and later
Specifies the table used to look up the other information, defaults to `users'.
Example:
SQLUserTable liveusers
Syntax: SQLUsernameField fieldname
Default: userid
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0rc2 and later
Specifies the name of the username field, defaults to `userid'. This is used in a WHERE clause for all other operations.
Example:
SQLUsernameField customerid
Syntax: whereclause
Default: none
Context: server config, <Global>, <VirtualHost>
Module: mod_sql
Compatibility: 1.2.0 and later
This directive deprecates 'SQLKey' and 'SQLKeyField'.
Specifies a where clause that is added to every user query (this has no effect on group queries). The where clause *must* contain all relevant punctuation, and *must not* contain a leading 'and'.
As an example of switching from the old-style 'SQLKey' and
'SQLKeyField' directives, if you had:
This would be appended to every user-related query as the string
" and (LoginAllowed = 'true')"
Syntax: facility-level 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 AUTHPRIV (or AUTH) facility
[intended to be secure, and never seen by unwanted eyes], while
normal operational messages are logged with the DAEMON
facility. The SyslogFacility directive allows ALL logging messages
to be directed to a different facility than the default. When this
directive is used, ALL logging is done with the specified
facility, both authentication (secure) and otherwise. The facility-level argument must be one
of the following: AUTH (or
AUTHPRIV), CRON, DAEMON, KERN, LPR, MAIL,
NEWS, USER, UUCP, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5,
LOCAL6 or LOCAL7. See Also: SystemLog Syntax: SyslogLevel emerg|alert|crit|error|warn|notice|info|debug SyslogLevel adjusts the verbosity of the messages recorded in the
error logs. The following levels are available, in order
of decreasing significance:
When a particular level is specified, messages from all other
levels of higher significance will be reported as well.
E.g., when Using a level of at least Syntax: filename The SystemLog directive disables proftpd's use of the syslog
mechanism and instead redirects all logging output to the
specified filename. The
filename argument should contain an
absolute path. Use of this directive overrides any facility set by
the SyslogFacility directive. Additionally, the special keyword NONE
can be used which disables all syslog style logging for the entire
configuration. Syntax: backlog-size The tcpBackLog directive controls the tcp "backlog
queue" when listening for connections in
standalone mode (see ServerType). It has no affect upon servers
in inetd mode. When a tcp connection is
established by the tcp/ip stack inside the kernel, there is a
short period of time between the actual establishment of the
connection and the acceptance of the connection by a user-space
program. The duration of this latency period is widely variable,
and can depend upon several factors (hardware, system load,
etc). During this period tcp connections cannot be accepted, as
the port that was previously "listening" has become
filled with the new connection. Under heavy connection load this
can result in occasional (or even frequent!) "connection
refused" messages returned to the incoming client, even when
there is a service available to handle requests. To eliminate
this problem, most modern tcp/ip stacks implement a "backlog
queue" which is simply a pre-allocation of resources
necessary to handle backlog-size
connections during the latency period. The larger the backlog
queue, the more connections can be established in a very short
time period. The trade-off, of course, is kernel memory and/or
other kernel resources. Generally it is not necessary to use a tcpBackLog directive,
unless you intend to service a large number of virtual hosts (see
<VirtualHost>), or have a
consistently heavy system load. If you begin to notice or hear of
"connection refused" messages from remote clients, try
setting a slightly higher value to this directive. Syntax: tcpNoDelay on|off The tcpNoDelay directive controls the use of the TCP_NODELAY
socket option (which disables the Nagle algorithm). ProFTPd uses
TCP_NODELAY by default, which usually is a benefit but this can
occasionally lead to problems with some clients, so tcpNoDelay is
provided as a way to disable this option. You will not normally
need to use this directive but if you have clients reporting
unusually slow connections, try setting this to
off.
Syntax: tcpReceiveWindow window-size The tcpReceiveWindow directive configures the size (in octets) of
all data connections' tcp receive windows. It is only used when
receiving a file from a client over the data
connection. Typically, a given tcp/ip implementation will use a
relatively small receive window size (the number of octets that
can be received at the tcp layer before a "turnaround"
acknowledgement is required). When transferring a large amount of
data over fast digital transmission lines which have a relatively
high latency, a small receive window can dramatically affect
perceived throughput because of the necessity to completely stop
the transfer occasionally in order to wait for the remote endpoint
to receive the acknowledgement and continue transmission. For
example, on a T1 line (assuming full 1.544Mbps
endpoint-to-endpoint throughput) with 100 ms latency, a 4k receive
buffer will very dramatically reduce the perceived throughput. The
default value of 8192 octets (8k) should be reasonable in common
network configurations. Additionally, proftpd allocates its
internal buffers to match the receive/ send window sizes; in order
to maximize the reception/transmission performance (reducing the
number of times data must be transfered from proftpd to the kernel
tcp/ip stack). The tradeoff, of course, is memory; both kernel-
and user-space. If running proftpd on a memory tight host (and on
a low-bandwidth connection), it might be advisable to decrease
both the tcpReceiveWindow and tcpSendWindow sizes. Syntax: tcpSendWindow window-size The tcpSendWindow directive configures the size (in octets) of
all data connections' tcp send windows. It is only used when
sending a file from the server to a client on the data
connection. For a detailed description of receive/send window
sizes see tcpReceiveWindow. Syntax: TimesGMT on|off The TimesGMT option causes the server to report all ls and MDTM times in
GMT and not local time.
Syntax: TimeoutIdle seconds The TimeoutIdle directive configures the maximum number of seconds that proftpd
will allow clients to stay connected without receiving any data on either
the control or data connection. If data is received on either connection,
the idle timer is reset. Setting TimeoutIdle to 0 disables the idle timer
completely (clients can stay connected for ever, without sending data). This
is generally a bad idea as a "hung" tcp connection which is never
properly disconnected (the remote network may have become disconnected from
the Internet, etc) will cause a child server to never exit (at least not for
a considerable period of time) until manually killed See Also: TimeoutLogin, TimeoutNoTransfer Syntax: TimeoutLogin seconds The TimeoutLogin directive configures the maximum number of seconds a client
is allowed to spend authenticating. The login timer is not reset when a client
transmits data, and is only removed once a client has transmitted an acceptable
USER/PASS command combination. See Also: TimeoutIdle, TimeoutNoTransfer Syntax: TimeoutNoTransfer seconds The TimeoutNoTransfer directive configures the maximum number of seconds
a client is allowed to spend connected, after authentication, without issuing
a command which results in creating an active or passive data connection (i.e.
sending/receiving a file, or receiving a directory listing). See Also: TimeoutIdle, TimeoutLogin Syntax: TimeoutStalled seconds The TimeoutStalled directive sets the maximum number of seconds a data connection
between the proftpd server and an FTP client can exist but have no actual
data transferred (i.e. "stalled"). If the seconds
argument is set to 0, data transfers are allowed to stall
indefinitely (the default). Syntax: TransferLog filename|NONE The TransferLog directive configures the full path to the "wu-ftpd style"
file transfer log. Separate log files can be created for each Anonymous
and/or VirtualHost. Additionally, the special keyword NONE can be used,
which disables wu-ftpd style transfer logging for the context in which the
directive is used (only applicable to version 1.1.7 and later). See Also: ExtendedLog, LogFormat Syntax: Umask file octal-mask [directory octal-mask] Umask sets the mask applied to newly created file and directory permissions
within a given context. By default, the Umask in the server configuration,
<VirtualHost> or <Anonymous>
block is used, unless overridden by a "per-directory" Umask setting.
Any arguments supplied must be an octal number, in the format 0xxx. An optional
second argument can specify a Umask to be used when creating directories.
If a second argument isn't specified, directories are created using the default
Umask in the first argument. For more information on umasks, consult your
operating system documentation/man pages. Syntax: UseFtpUsers on|off Legacy FTP servers generally check a special authorization file (typically
/etc/ftpusers) when a client attempts to authenticate. If the user's name
is found in this file, FTP access is denied. For compatibility sake, proftpd
defaults to checking this file during authentication. This behavior can be
suppressed using the UseFtpUsers configuration directive. Syntax: UseHostsAllowFile filename UseHostsAllowFile specifies the IPs, networks or name based masks
to be allowed to connect to the server in the same format
as the hosts.allow/deny files. Example: UseHostsAllowFile /etc/ftpd.allow Syntax: UseHostsDenyFile filename Specifies the hosts.deny compatible deny file for IP based
security checks. See UseHostsAllowFile Example: UseHostsDenyFile /etc/ftpd.deny Syntax: UseReverseDNS on|off Normally, incoming active mode data connections and outgoing passive mode
data connections have a reverse DNS lookup performed on the remote host's
IP address. In a chroot environment (such as <Anonymous>
or DefaultRoot), the /etc/hosts file cannot be
checked and the only possible resolution is via DNS. If for some reason, DNS
is not available or improperly configured this can result in proftpd blocking
("stalling") until the libc resolver code times out. Disabling this
directive prevents proftpd from attempting to reverse-lookup data connection
IP addresses.
Syntax: User userid The User directive configures which user the proftpd daemon will normally
run as. By default, proftpd runs as root which is considered undesirable
in all but the most trustful network configurations. The User directive used
in conjunction with the Group directive
instructs the daemon to switch to the specified user and group as quickly
as possible after startup. On some unix variants, the daemon will occasionally
switch back to root in order to accomplish a task which requires super-user
access. Once the task is completed, root privileges are relinquished and the
server continues to run as the specified user and group. When applied to a
<VirtualServer> block, proftpd
will run as the specified user/group on connections destined for the virtual
server's address or port. If either User or Group
is applied to an <Anonymous>
block, proftpd will establish an anonymous login when a user attempts to login
with the specified userid, as well as permanently switching to the corresponding
uid/gid (matching the User/Group parameters found in the anonymous block)
after login. Note: When an authorized unix user is authenticated and logs in, all former
privileges are released, the daemon switches permanently to the logged in
user's uid/gid, and is never again capable of switching back to root or any
other user/group. Syntax: UserDirRoot on|off When set to true, the chroot base directory becomes a subdirectory of the
anonymous ftp directory, based on the username of the current user. For
example, assuming user "foo" is aliased to "ftp", logging in as "foo" causes
proftpd to run as real user ftp, but to chroot into Syntax: UserAlias login-user userid ProFTPD requires a real username/uid when authenticating users as
provided by PAM, AuthUserFile or another authentication mechanism.
There are however times when additional aliases are required but it
is undesirable to provide additional login accounts. UserAlias provides a mechanism to do this, a typical and common
example is within Anonymous configuration blocks. It is normal for
the server to use 'ftp' as the primary authentication user, however
it is common practice for users to login using "anonymous". This is
achieved by adding the following to the config file.
Syntax: UserOwner username The UserOwner directive configures which user all newly created directories
and files will be owned by, within the context that UserOwner is applied to.
The user ID of username cannot be 0 (root).
Where it is used, the Syntax: UserPassword userid hashed-password The UserPassword directive creates a password for a particular user which
overrides the user's normal password in /etc/passwd (or /etc/shadow). The
override is only effective inside the context to which UserPassword is applied.
The hashed-password argument is a cleartext string
which has been passed through the standard unix crypt() function. Do
NOT use a cleartext password. This can be useful when combined with
UserAlias to provide multiple logins to an Anonymous FTP site. See Also: GroupPassword Syntax: <VirtualHost address> The VirtualHost configuration block is used to create an independent set
of configuration directives that apply to a particular hostname or IP address.
It is often used in conjunction with system level IP aliasing or dummy network
interfaces in order to establish one or more "virtual" servers which
all run on the same physical machine. The block is terminated with a </VirtualHost>
directive. By utilizing the Port directive inside a VirtualHost block, it is
possible to create a virtual server which uses the same address as the master
server, but listens on a separate tcp port (incompatible with ServerType inetd). When proftpd starts, virtual server connections are handled in one of two
ways, depending on the ServerType setting: Because of the method that the daemon uses to listen for connections when
in standalone mode, it is possible to support an
exceedingly large number of virtual servers, potentially exceeding the number
of per-process file descriptors. This is due to the fact that a single file
descriptor is used to listen to each configured port, regardless of the number
of addresses being monitored. Note that it may be necessary to increase
the tcpBackLog value on heavily loaded
servers in order to avoid kernel rejected client connections ("Connection
refused").
SQLKey true
SQLKeyfield LoginAllowed
You would now use:
SQLWhereClause "LoginAllowed = 'true'"
SyslogFacility
Default: None
Context: server config
Module: mod_core
Compatibility: 1.1.6 and later
SyslogLevel
Default: None
Context: server config, <VirtualHost>,
<Anonymous>, <Global>
Module: mod_core
Compatibility: Post 1.2.0rc2 CVS and later
Level
Description
emerg
Emergencies - system is unusable.
alert
Action must be taken immediately.
crit
Critical Conditions.
error
Error conditions.
warn
Warning conditions.
notice
Normal but significant condition.
info
Informational.
debug
Debug-level messages
SyslogLevel info is specified, then
messages with log levels of notice and
warn will also be posted.
crit is recommended.
SystemLog
Default: None
Context: server config
Module: mod_log
Compatibility: 1.1.6pl1 and later
tcpBackLog
Default: 5
Context: server config
Module: mod_core
Compatibility: 0.99.0 and later
tcpNoDelay
Default: on
Context: server config, <VirtualHost>, <Global>
Module: mod_core
Compatibility: 1.2.0pre3a and later
tcpReceiveWindow
Default: 8192
Context: server config, <VirtualHost>
Module: mod_core
Compatibility: 0.99.0 and later
tcpSendWindow
Default: 8192
Context: server config, <VirtualHost>
Module: mod_core
Compatibility: 0.99.0 and later
TimesGMT
Default: (versions prior to 1.2.0pre9) off - but MDTM reports in GMT
Default: (versions 1.2.0pre9 and beyond) on
Context: server config
Module: mod_core
Compatibility: 1.2.0pre9 and later
TimeoutIdle
Default: 600
Context: server config
Module: mod_core
Compatibility: 0.99.0 and later
TimeoutLogin
Default: 300
Context: server config
Module: mod_core
Compatibility: 0.99.0 and later
TimeoutNoTransfer
Default: 300
Context: server config
Module: mod_core
Compatibility: 0.99.0 and later
TimeoutStalled
Default: 3600
Context: server config
Module: mod_core
Compatibility: 1.1.6 and later
TransferLog
Default: /var/log/xferlog
Context: server config, <Anonymous>, <VirtualHost>,
<Global>
Module: mod_core
Compatibility: 1.1.4 and later
Umask
Default: None
Context: server config, <Anonymous>, <VirtualHost>,
<Directory>, <Global>, .ftpaccess
Module: mod_core
Compatibility: 0.99.0 and later
UseFtpUsers
Default: on
Context: server config, <Anonymous>, <VirtualHost>,
<Global>
Module: mod_core
Compatibility: 0.99.0 and later
UseHostsAllowFile
Default: /etc/hosts.allow
Context: server, <Anonymous>, <VirtualHost>
Module: mod_wrap
Compatibility: 1.2.0 and later
UseHostsDenyFile
Default: /etc/hosts.deny
Context: server, <Anonymous>, <VirtualHost>
Module: mod_wrap
Compatibility: 1.2.0 and later
UseReverseDNS
Default: on
Context: server config
Module: mod_core
Compatibility: 1.1.7 and later
User
Default: None
Context: server config, <VirtualHost>, <Anonymous>,
<Global>
Module: mod_core
Compatibility: 0.99.0 and later
UserDirRoot
Default: off
Context: <Anonymous>
Module: mod_auth
Compatibility: 1.2.0pre2 and later~ftp/foo
instead of just ~ftp.
UserAlias
Default: None
Context: server config, <VirtualHost>, <Anonymous>,
<Global>
Module: mod_auth
Compatibility: 0.99.0 and laterUserAlias anonymous ftp
UserOwner
Default: None
Context: <Anonymous>, <Directory>
Module: mod_core
Compatibility: 1.2pre11 and later
UserPassword
Default: None
Context: server config, <VirtualHost>, <Anonymous>,
<Global>
Module: mod_core
Compatibility: 0.99.0pl5 and later
<VirtualHost>
Default: None
Context: server config
Module: mod_core
Compatibility: 0.99.0 and later
The daemon examines the destination address and port of the incoming connection
handed off from inetd. If the connection matches one of the configured virtual
hosts, the connection is serviced based on the appropriate configuration.
If no virtual host matches, and the main server does not match, the client
is informed that no server is available to service their requests and disconnected.
After parsing the configuration file, the daemon begins listening for connections
on all configured ports, spawning child processes as necessary to handle
connections for either the main server or any virtual servers.
Syntax: UserRatio foo1 foo2 foo3
Default: None known
Context: <Directory>, <Anonymous>,
<Limit>, .ftpaccess
Module: mod_ratio
Compatibility: at least 1.2.0 and later
The UserRatio directive .... INCOMPLETE
Example:
UserRatio
Syntax: WtmpLog on|off|NONE
Default: on
Context: server config, <VirtualHost>, <Anonymous>, <Global>
Module: mod_core
Compatibility: 1.1.7 and later
The WtmpLog directive controls proftpd's logging of ftp connections to the host system's wtmp file (used by such commands as `last'). By default, all connections are logged via wtmp.
Please report any corrections or additions via Bugzilla or to Mark