# 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 '', # '', and ''. 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 ... block, the ... # block, and the ... 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 # block is part of the default server configuration. It # doesn't matter if it's at the end of the file, between other # blocks, or at the start of the file -- if it's not # contained by a ... pair, it's applied to # the default server. # # First of all, blocks set defaults for *every* server listed # in the proftpd.conf file, including any 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, blocks do not define a server. They define a # particular service that an FTP server provides. You can have # blocks in the default server configuration, or in # blocks, but the blocks are conceptually a # *part* of a server, they do not define a server in and of themselves. # # Third, 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 block. # blocks can have their own 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 # blocks and no 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 # 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 block so they'll be # inherited by the block below, and any other # blocks we may want to add. For a simple server these don't need to # be in a block but it won't hurt anything. # 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 block. # 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. AllowOverwrite on # A basic anonymous configuration, no upload directories. If you # don't want to support anonymous access, simply remove this # ... block. 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 DenyAll