trAvis - MANAGER

Edit File: mod_sql.conf

# 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 using crypt(3)'.
  SQLAuthTypes Backend Crypt

# 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
  DisplayChdir			.message

# Limit WRITE everywhere in the anonymous chroot
  <Limit WRITE>
    DenyAll
  </Limit>
</Anonymous>