Multiple Daemons on Same Host
What if you wanted to run multiple instances of proftpd
on the
same host? This is actually a prudent idea, for running one production
proftpd
while running a different, possibly newer
proftpd
for testing, side-by-side. Is it possible? Of course!
Different proftpd
daemons can coexist on the same machine,
but they cannot all use the same configuration file. There is a small list
of directives that need to have different parameters for each
proftpd
instance, i.e.:
PidFile
ScoreboardFile
ServerLog
SystemLog
Failure to assign different PidFile
s and
ScoreboardFile
s for each proftpd
will cause the
multiple instances to overwrite each other's files, and inevitably cause
problems. Keeping separate log files (ServerLog
,
SystemLog
, etc) for each daemon is simply a good idea.
What about the PassivePorts
directive? Do the different
proftpd
instances each need their own range? No.
When a passive data transfer is requested, proftpd
will choose a
random port from within a PassivePorts
range, but not before
then. If the port happens to be in use, proftpd
will try
another random port within the range, and so on, until the range is exhausted.
Thus multiple proftpd
instances should be able to share the same
PassivePorts
range without issue (assuming it is a decently wide
range).
There is one final setting which can cause problems: Port
.
An actual incident can help illustrate the issue:
I tried to setup another instance of proftpd. I copied my existing config
file and changed the port information. My production FTP server runs on port
1979. In the test config file I specified 1980. I started the testing
instance on the command line by executing the following command:
./proftpd -d 5 -n -c /etc/proftpd/proftpd.test.conf
The testing instance started up without any problems. Unfortunately, when a
client connected it gave the error message that the server is already bound
to port 1979. This is very strange, as the client connected successfully to
port 1980 in the first instance. How did the test server get the port
information of the other production server?
In reality, the test server did not "get" the port information from the
production instance. Instead, this admin was encountering the "L-1" issue.
The FTP RFCs state that for active data transfers, the source
port of the TCP connection (the source port of the TCP connection from the
server to the client) must be L-1, where L is the control
port number.
So if your control port (configured by the Port
directive in
proftpd.conf
) is 1980, then the source port that
proftpd
has to use, for any active data transfers (e.g.
for clients which use the PORT
or EPRT
commands), is
1979. If that port 1979 is already in use by another daemon (such as another
proftpd
instance as its control port), you have a collision,
and will likely see the "Address already in use" error message.
In the case, the test server should work if the following was used:
Port 1981
i.e. a port number that is the existing proftpd
's port
number plus two (or more).
Using the above configuration tricks, the same proftpd.conf
file could be used by both the production and the test daemons,
using something like:
# These directives need to differ depending on whether the test server
# or the production server is reading this configuration.
<IfDefine TEST>
Port 2121
PidFile /var/ftpd/proftpd.test.pid
ScoreboardFile /var/ftpd/proftpd.test.scoreboard
</IfDefine>
<IfDefine !TEST>
Port 2123
PidFile /var/ftpd/proftpd.pid
ScoreboardFile /var/ftpd/proftpd.scoreboard
</IfDefine>
Then, starting proftpd
with the proper command-line invocation
e.g.:
/usr/local/sbin/proftpd -DTEST ...
will use the test server configuration. Omitting the -D
option on the command-line will cause proftpd
to use the
production configuration.
Reducing FTP Traffic Impact on Host System
Some sites run proftpd
on a system which is used to host other
services as well (e.g. Apache, a file server, etc). These
sites might notice that when many FTP downloads or uploads are happening,
the other services start to be impacted: slower/stuttering web pages or
streaming video/music, for example.
Wouldn't it be nice if you could somehow tell proftpd
to use
a lower priority, i.e. in the manner of the nice(1)
command, for such data transfers? Fortunately, you can do exactly this using
the TransferPriority
directive. For example, a good default configuration to use is:
# Use a low process priority during all data transfers
TransferPriority APPE,RETR,STOR,STOU low
One user reporting always having stuttering streaming video when FTP data
transfers were happening. After using the TransferPriority
directive, that user saw no more video stream stuttering while still
approaching full LAN network speed for the FTP data transfer.
© Copyright 2017 The ProFTPD Project
All Rights Reserved