The ServerType configuration directive for ProFTPD can cause confusion for those just starting with this server. What is the purpose for this directive? What are these "inetd" and "standalone" types, and why does one need to choose one or the other?

The purpose of this directive is to choose between the two operating modes for almost all Unix network servers: does the server listen on its port for client requests itself, or does the server let some other process do the listening, and call the server when needed? Traditionally, that "other process" has been inetd, a "super server" that listens on all interfaces, all ports on a Unix machine, and calls the appropriate server based on the port contacted. A more modern replacement for inetd is found in the xinetd server; this server functions much the same way. The other mode of operation is to have the server listen on the port(s) itself, and handle client requests accordingly. The latter mode is the standalone ServerType, the former is the inetd mode (which covers both the inetd and xinetd processes).

This directive is mandatory, and must be set to one mode or the other. The two modes are incompatible (two processes cannot be bound to the same interface/port combination simultaneously), and thus the proftpd must be told in which mode it is to operate.

Inetd Mode
In inetd mode, the proftpd server expects to be started by the inetd (or xinetd) servers. It is these servers, inetd/xinetd, that listen on the FTP port (usually 21) for connection requests, then start proftpd and pass the connection off. This mode is usually best suited for low traffic sites, for sites that do not handle many FTP sessions.

Example /etc/inetd.conf entry:

  ftp    stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/proftpd
The inetd.conf man pages discuss these fields in greater detail.

An example xinetd configuration is:

  service ftp
        disable = no
        flags			= IPv4
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/sbin/proftpd
        server_args             = -c /etc/proftpd.conf
The xinetd configuration is usually found in /etc/xinetd.conf or in the /etc/xinetd.d/ directory.

Note: Solaris users may find that their /etc/inetd.conf file ships with an ftp entry that looks similar to the above, except that it has "tcp6" rather than "tcp". For proftpd to function properly in such cases, that "tcp6" will need to be changed to "tcp". Solaris uses the tcp6 keyword to have its inetd pass IPv6 sockets to the called program; proftpd must have been configured with the --enable-ipv6 option to handle such sockets.

Inetd Mode and Non-standard Ports
A note about using non-standard ports in your configuration via the Port configuration directive: making these work while in inetd mode and using inetd (as oppposed to xinetd) is problematic. The first column of an /etc/inetd.conf entry lists a protocol name. The port for that protocol is listed in the /etc/services file. For services that run on non-standard ports, however, /etc/services has no entry, and inetd is programmed so as to always reference that file. This means that if use of non-standard ports and use of inetd are required, the /etc/services file will need to be edited. Avoid this situation if possible.

Compared to inetd, xinetd's configuration format is more flexible: it can be configured to use non-standard ports using the port attribute:

       port             determines  the  service  port.  If  this
                        attribute  is  specified  for  a  service
                        listed in /etc/services, it must be equal
                        to the port number listed in that file.
as described in the xinetd.conf(5) man page.

If your proftpd server is running in this mode, you do not need to worry about restarting any servers whenever changes are made to the proftpd.conf configuration file. Since proftpd is started for each new FTP session by inetd/xinetd, and part of that startup process includes reading the configuration file, any changes will be seen by any new FTP sessions once the changes are made.

If you attempt to start a proftpd server configured with a ServerType of standalone, and already have inetd/xinetd also configured to handle FTP connections, this kind of error message will appear in your proftpd logs: - Failed binding to, port 21: Address already in use - Check the ServerType directive to ensure you are configured correctly.
More information might be found by debugging your configuration.

Standalone Mode
In this mode, the proftpd listens for incoming FTP session requests itself, and forks off child processes to handle those requests. This mode is best suited for high traffic, popular sites; the overhead of having to parse the configuration file each time, as is done for inetd-handled sessions, is avoided in this mode. Also, there is no need to change any other configuration files other than the proftpd.conf, for ports, virtual servers, or anything else.

When running in this mode, the server will need to be restarted whenever changes are made to the configuration file. There is a page that describes how this can be done.

Many administrators are accustomed to using tcpwrappers to secure their network servers; indeed, this is a good practice to get into. However, the most common way this is done is through inetd. When running a proftpd server in standalone mode, then, it is not quite as straightforward; however, it is not hard, either. The mod_wrap module can be compiled into your proftpd. This module allows a standalone proftpd server to use the normal /etc/hosts.allow, /etc/hosts.deny files, in addition to other files (something that normal tcpwrappers configurations cannot do).

If you try to start a proftpd server configured with a ServerType of inetd from the command line (or from some shell wrapper script), this kind of error message will appear in your proftpd logs: - Fatal: Socket operation on non-socket - (Running from command line? Use `ServerType standalone' in config file!)
More information might be found by debugging your configuration.

Switching Modes
Changing from one ServerType mode to the other is a simple process, as long as the few steps involved are followed.

To change from inetd to standalone, make sure to remove any FTP configurations from /etc/inetd.conf, /etc/xinetd.conf, /etc/xinetd.d/, or wherever your superserver's configuration file(s) reside. Once this is done, make sure those changes are seen by restarting inetd/xinetd. Then, make sure

  ServerType standalone
is in your proftpd.conf. Start the proftpd server from the command line, to make sure all is working. You can then easily start server from an init.d script such as the one mentioned here.

To change from standalone to inetd, make sure your proftpd is stopped completely. Add a configuration entry for FTP into your inetd/xinetd configuration (mentioned above), then restart inetd/xinetd to have those configuration changes seen. Check your proftpd.conf to see that

  ServerType inetd
is there.

Frequently Asked Questions
Question: I have configured:

  <IfModule mod_ident.c>
    IdentLookups off

  ServerIdent off
in my proftpd.conf, but my logins are still slow. Why?
Answer: Another source of slow logins can be xinetd, or tcpwrappers compiled for reverse DNS lookups (i.e. with the -DPARANOID option).

If you are using ServerType inetd, and you are using xinetd to run proftpd, then you should check your /etc/xinetd.conf (or /etc/xinetd.d/proftpd or similar) file for the USERID parameter, e.g.:

  log_on_success          += DURATION USERID
  log_on_failure          += USERID
As per the xinetd.conf documentation, the use of USERID in your configuration causes xinetd to do an IDENTD lookup:
        USERID      logs the user id of the remote user  using
                    the   RFC  1413  identification  protocol.
                    This option is available only  for  multi-
                    threaded stream services.
Removing USERID from your xinetd configuration for proftpd often suffices to fix the slow logins.

Another solution is simply to switch your ServerType to "standalone".

© Copyright 2017-2020 The ProFTPD Project
All Rights Reserved