# mod_sql.conf -- a proftpd.conf file for mod_sql/4.0 and higher
#
# This is a basic mod_sql-enabled ProFTPD configuration file. It is
# based on the 'basic.conf' sample configuration file.
#
# To fully understand this sample configuration you should read the
# other sample configurations and the README.mod_sql file which came
# with your distribution.
#
# NOTE ABOUT DIRECTIVES:
#
# When you're looking through the ProFTPD directive list, you'll see
# that every directive is marked with a 'Context'. This lists the
# blocks that the directive can legally appear in. The default server
# is known as the 'server config' context; the others are '<Global>',
# '<VirtualHost>', and '<Anonymous>'. These are all explained below.
#
# NOTE ABOUT DEFAULT, GLOBAL, ANONYMOUS, AND VIRTUAL BLOCKS:
#
# There are four types of 'contexts' in this file; three of them are
# explicitly marked and one is a catch-all. The three explicit contexts
# are the <Global>...</Global> block, the <Anonymous>...</Anonymous>
# block, and the <VirtualHost>...</VirtualHost> block (which isn't
# included in this sample). Many people just starting with ProFTPD
# seem to have trouble understanding the way these blocks nest and
# what they do.
#
# You should understand that any directive that *isn't* inside a
# <VirtualHost> block is part of the default server configuration. It
# doesn't matter if it's at the end of the file, between other
# <VirtualHost> blocks, or at the start of the file -- if it's not
# contained by a <VirtualHost> ... </VirtualHost> pair, it's applied to
# the default server.
#
# First of all, <Global> blocks set defaults for *every* server listed
# in the proftpd.conf file, including any <VirtualHost> blocks. They do
# not define an ftp server; it's just a shorthand way of specifying a set
# of directives in one place instead of in multiple spots.
#
# Second, <Anonymous> blocks do not define a server. They define a
# particular service that an FTP server provides. You can have
# <Anonymous> blocks in the default server configuration, or in
# <VirtualHost> blocks, but the <Anonymous> blocks are conceptually a
# *part* of a server, they do not define a server in and of themselves.
#
# Third, <VirtualHost> blocks define servers which are in addition to
# the default server, but they are *completely* separate in setup,
# except that they inherit any directives in a <Global> block.
# <VirtualHost> blocks can have their own <Anonymous> blocks, and must
# have their own IP or Port (since the FTP protocol doesn't support
# true name-based virtual hosts, like HTTP does).
#
# Finally, you should realize that all these explicitly-marked blocks
# are optional. The simplest configuration file will have no
# <VirtualHost> blocks and no <Anonymous> blocks. If you don't want
# anonymous logins, simply remove the anonymous block from this sample
# configuration file. If you want to configure a virtual host, simply
# add a complete set of server directives inside a <VirtualHost>
# block.
ServerName "ProFTPD Default Installation"
ServerType standalone
DefaultServer on
# Port 21 is the standard FTP port.
Port 21
# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask 022
# We put our mod_sql directives in a <Global> block so they'll be
# inherited by the <Anonymous> block below, and any other <VirtualHost>
# blocks we may want to add. For a simple server these don't need to
# be in a <Global> block but it won't hurt anything.
<Global>
# Specify our connection information. Both mod_sql_mysql and
# mod_sql_postgres use the same format, other backends may specify a
# different format for the first argument to SQLConnectInfo. By not
# specifying a fourth argument, we're defaulting to 'PERSESSION'
# connections -- a connection is made to the database at the start of
# the session and closed at the end. This should be fine for most
# situations.
SQLConnectInfo dbname@host:port username password
# Specify our authentication schemes. Assuming we're using
# mod_sql_mysql, here we're saying 'first try to authenticate using
# mysql's password scheme, then try to authenticate the user's
# password as plaintext'. Note that 'Plaintext' isn't a smart way to
# store passwords unless you've got your database well secured.
SQLAuthTypes Backend Plaintext
# Specify the table and fields for user information. If you've
# created the database as it specifies in 'README.mod_sql', you don't
# need to have this directive at all UNLESS you've elected not to
# create some fields. In this case we're telling mod_sql to look in
# table 'users' for the fields 'username','password','uid', and
# 'gid'. The 'homedir' and 'shell' fields are specified as 'NULL' --
# this will be explained below.
SQLUserInfo users username password uid gid NULL NULL
# Here we tell mod_sql that every user it authenticates should have
# the same home directory. A much more common option would be to
# specify a homedir in the database and leave this directive out. Note
# that this directive is necessary in this case because we specified
# the homedir field as 'NULL', above. mod_sql needs to get homedir
# information from *somewhere*, otherwise it will not allow access.
SQLDefaultHomedir "/tmp"
# This is not a mod_sql specific directive, but it's here because of
# the way we specified 'SQLUserInfo', above. By setting this to
# 'off', we're telling ProFTPD to allow users to connect even if we
# have no (or bad) shell information for them. Since we specified the
# shell field as 'NULL', above, we need to tell ProFTPD to allow the
# users in even though their shell doesn't exist.
RequireValidShell off
# Here we tell mod_sql how to get out group information. By leaving
# this commented out, we're telling mod_sql to go ahead and use the
# defaults for the tablename and all the field names.
# SQLGroupInfo groups groupname gid members
# For small sites, the following directive will speed up queries at
# the cost of some memory. Larger sites should read the complete
# description of the 'SQLAuthenticate' directive; there are options
# here that control the use of potentially expensive database
# queries. NOTE: these arguments to 'SQLAuthoritative' limit the way
# you can structure your group table. Check the README for more
# information.
SQLAuthenticate users groups usersetfast groupsetfast
# Finally, some example logging directives. If you have an integer
# field named 'count' in your users table, these directives will
# automatically update the field each time a user logs in and display
# their current login count to them.
# SQLNamedQuery getcount SELECT "count, userid from users where userid='%u'"
# SQLNamedQuery updatecount UPDATE "count=count+1 WHERE userid='%u'" users
# SQLShowInfo PASS "230" "You've logged on %{getcount} times, %u"
# SQLLog PASS updatecount
# close our <Global> block.
</Global>
# To prevent DoS attacks, set the maximum number of child processes
# to 30. If you need to allow more than 30 concurrent connections
# at once, simply increase this value. Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd)
MaxInstances 30
# Set the normal user and group permissions for the server.
User nobody
Group nogroup
# Normally, we want files to be overwriteable.
<Directory /*>
AllowOverwrite on
</Directory>
# A basic anonymous configuration, no upload directories. If you
# don't want to support anonymous access, simply remove this
# <Anonymous ..> ... </Anonymous> block.
<Anonymous ~ftp>
User ftp
Group ftp
# We want clients to be able to login with "anonymous" as well as "ftp"
UserAlias anonymous ftp
# Limit the maximum number of anonymous logins
MaxClients 10
# We want 'welcome.msg' displayed at login, and '.message' displayed
# in each newly chdired directory.
DisplayLogin welcome.msg
DisplayFirstChdir .message
# Limit WRITE everywhere in the anonymous chroot
<Limit WRITE>
DenyAll
</Limit>
</Anonymous>
