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/proftpdThe
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:
golem.castaglia.org - Failed binding to 127.0.0.1, port 21: Address already in use golem.castaglia.org - 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:
golem.castaglia.org - Fatal: Socket operation on non-socket golem.castaglia.org - (Running from command line? Use `ServerType standalone' in config file!)More information might be found by debugging your configuration.
Switching Modes
To change from inetd to standalone, make sure to remove any
FTP configurations from
Changing from one ServerType
mode to the other is a simple
process, as long as the few steps involved are followed.
/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 inetdis there.
Frequently Asked Questions
If you are using
Another solution is simply to switch your
Question: I have configured:
<IfModule mod_ident.c>
IdentLookups off
</IfModule>
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).
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.
ServerType
to "standalone".
© Copyright 2017-2020 The ProFTPD Project
All Rights Reserved