Starting ProFTPD in standalone mode it doesn't show in "ps" It could be many things, possibly something like not running ProFTPD as root (it needs to be run as root initially, but will switch to a non-privileged user). Regardless, ProFTPD logs all errors via the standard syslog mechanism. You need to check your system logs in order to determine what the problem is.
It doesn't work!
There are many times when there's a completely random problem which appears to be insoluble. The best place to ask for help is definately the mailing list (proftpd-l) but it's not productive to ask for help without giving enough information for intelligent debugging.
Have you?
Checked your logs
Tried the server in debug mode
Read the FAQ?
Checked the mailing list archive?
Are you running the latest version?
When posting try giving enough information, this might include but not be limited to.
OS and server version (proftpd -vv)
List of included modules (proftpd -l)
Appropriate log extracts
Output fom debug mode
Configration fragment
You aren't starting ProFTPD as root, or you have inetd configured to run ProFTPD as a user other than root. The ProFTPD daemon must be started as root in order to bind to tcp ports lower than 1024, or to open your shadow password file when authenticating users. The daemon switches uid/gids to the user and group specified by the User/Group directives during normal operation, so a "ps" will show it running as the user you specified.
0.0.0.0 is INADDR_ANY, which means to bind to any interface. The "address in use" will normally mean that something has already bound to that address.
Under linux it is possible to run:
fuser -n tcp 21
to get the PID of the process currently bound to port ProFTPD is configured to run as.
The most common cause is that ProFTPD is configured standalone and inetd is still configured for port 21. Comment out the line starting "ftp" in /etc/inetd.conf and restart (killall -HUP inetd or something similar should do the trick) and try again.
The user attempting to login has been given a shell that is not listed in the system's /etc/shells file. By default, proftpd will require that users logging in have valid shells. Use the RequireValidShell directive to turn off this requirement:
RequireValidShell off
You have ProFTPD configured to run in inetd mode rather than standalone. In this mode, ProFTPD expects that it will be run from the inetd super-server, which implies that stdin/stdout will be sockets instead of terminals. As a result, socket operations will fail and the above error will be printed. If you wish to run ProFTPD from the shell, in standalone mode, you'll need to modify your proftpd.conf configuration file and add or edit the ServerType directive to read:
ServerType standalone
The hosting machine has a poorly configured hostname setup to the point where the resolver library cannot determine the IP from the name. Solutions include, fixing the DNS for the domain, fixing the hostname, fixing the /etc/hosts file. Which one works for you will largely depend on your OS and exactly what is wrong.
The FTP Specification defines that two sockets should be used for all communications. The first runs over port 21 and is the control channel over which all commands and response codes are sent. Whenever data is required to be transfered, for example for a file download, a directory listing etc etc. A second channel is created on demand, this socket can take one of two forms.
non-Passive
The server end of the data socket uses port 20. This is nice and easy to work into a firewall configuration.
Passive
The port at either end is dynamically allocated. This is virtually impossible to cater for in a firewall configuration given that the port mapping will be different for every data connection.
The solution is to force the users to configure their clients to use the non-passive mode (ie port 20)
No, or at least not in the HTTP/1.1 manner of virtual hosting. This is an inbuilt limitation of the current FTP RFC., unlike the HTTP/1.1 spec there is no mechanism comparable to the "Host: foo.bar.com" HTTP header for specifying which host the connection is for. Therefore the only method for determining which VirtualHost the connection is destined for is by the destination IP.
The one exception to this is if you host multiple servers on the same IP but using different ports, however this requires that the connecting client uses a non-standard port and therefore is probably not a good solution for mass hosting.
Is there anything in the pipeline to fix this?
There is a draft standard http://search.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-12.txt with the IETF which extends and improves on the FTP specification including support for a HOST command. However given that the IP crunch is coming from websites and not virtual ftp servers this is unlikely to be pushed through any time soon.
Find the line in /etc/inetd.conf that looks something like this:
ftp stream tcp nowait root in.ftpd in.ftpd
Replace it with:
ftp stream tcp nowait root in.proftpd in.proftpd
Then, find your inetd process in the process listing and send it the SIGHUP signal so that it will rehash and reconfigure itself. You may also need to add in.ProFTPD to hosts.allow on your system.
Yup. Although ProFTPD has built-in IP access control (see the Deny and Allow directives), many admins choose to consolidate IP access control in one place via in.tcpd. Just configure ProFTPD to run from inetd as any other tcp-wrapper wrapped daemon and add the appropriate lines to hosts.allow/deny files.
If running ProFTPD in standalone mode, mod_wrap can be used to direct the server to use the normal hosts.allow/deny files.
Yes. Use a <VirtualHost> block with your machine's FQDN (Fully Qualified Domain Name) or IP address, and a Port directive inside the <VirtualHost> block. For example, if your host is named "myhost.mydomain.com" and you want to run an additional FTP server on port 2001, you would:
...
<VirtualHost myhost.mydomain.com>
Port 2001
...
</VirtualHost>
Yes the mod_ratio module provides for doing just this.
The ratio directives take four numbers: file ratio, initial file credit, byte ratio, and initial byte credit. Setting either ratio to 0 disables that check.
The directives are HostRatio (matches FQDN, wildcards allowed), AnonRatio (matches password entered at login), UserRatio (accepts "*" for "any user"), and GroupRatio.
Ratios on # enable module
UserRatio ftp 0 0 0 0
HostRatio master.debian.org 0 0 0 0 # leech access (default)
GroupRatio proftpd 100 10 5 100000 # 100:1 files, 10 file cred 5:1 bytes, 100k byte cred
AnonRatio billg@microsoft.com 1 0 1 0 # 1:1 ratio, no credits
UserRatio * 5 5 5 50000 # special default case
This example is for someone who (1) has downloaded 1 file of 82k, (2) has uploaded nothing, (3) has a ratio of 5:1 files and 5:1 bytes, (4) has 4 files and 17k credit remaining, and (5) is now changing directory to /art/nudes/young/carla. The initial credit, not shown, was 5 files and 100k (UserRatio * 5 5 5 100000).
Version 2.0 and above of this module integrate with mod_sql.
Limitations of mod_ratio
It appears that the ratio limits in mod_ratio are only maintained on a per session basis and there is no ongoing tracking of usage.
This is probably caused by a firewall or DNS timeout. By default ProFTPD will try to do both DNS and ident lookups against the incoming connection. If these are blocked or excessively delayed a slower than normal login will result. To turn off DNS and ident use:
UseReverseDNS off
IdentLookups off
IdentLookups and tcpwrappers ***
Oct 7 12:30:48 salvage2 proftpd[8874]: FTP session closed. Oct 7 12:30:48 salvage2 proftpd[8874]: FTP session closed. Oct 7 12:30:48 salvage2 proftpd[8874]: FTP session closed. Oct 7 12:30:48 salvage2 proftpd[8874]: FTP session closed.
The above log extract is likely to be caused by a local monitoring system or a particularly aggressive DoS attack. Most service monitoring systems try opening the ftp port on the target server to detect whether it is active and running. Most of the time these tests are followed by an immediate "QUIT" or disconnection.
TCPdump/TCPshow on the server in question should show which machine on your network is is generating these connections.
The ftpwho command lists the state of each ftp connection to the server and what it's current activity is. However this does not detail the connection information on a virtual by virtual basis.
Sort, of it's not quite as clean as the socket binding under Apache but the principle works something like this.
Standalone mode
To listen on the primary IP of a host use the SocketBindTight directive
To listen on a interfaces which are not the primary host interface use the SocketBindTight directive, place your server configuration in a <VirtualHost ftp.mydomain.com> block and use "Port 0" for the main host configuration and and "Port 21" inside the VirtualHost block.
inetd
There are two approaches possible, the first is to use the patch from Daniel Roesen <droesen@entire-systems.com> (check the mailing list archives).
The second method is to run ProFTPD from xinetd (http://synack.net/xinetd/), a more advanced replacement of inetd. An entry for this in xinetd.conf would be something like this:
service ftp { disable = no flags = REUSE socket_type = stream wait = no user = root server = /usr/sbin/proftpd log_on_success += DURATION USERID log_on_failure += USERID nice = 10 #bind = [IP to bind to] }
ftpshut, allows the server to disallow connections with a message without actually taking down the service. The shutdown can be scheduled for a point in the future or right now, existing connections can be allowed to finish, or be terminated now. Re-enabling is done by removing the /etc/shutmsg file.
No, the shutmsg file works at a daemon level not at a virtual host level.
This depends on the mode you're running the server in.
inetd
Unless you're making a configuration change to inetd itself nothing needs doing. The server reloads the configuration everytime a new connection is made.
Standalone
Either stop and start the server completely (a little aggressive for most admins tastes) or send a SIGHUP to the master daemon process.
A bug was introduced in 1.2.0rc2 which prevented the PORT command working properly and therefore breaking the data socket under certain conditions. The bug was documented as bug 240 and has been fixed in CVS. A rc3 release is due before the end of Jan 2001.
Proftpd was unable to work out what IP is associated with the hostname in the VirtualHost block. Normally caused by a problem with the DNS resolution of the host, check the resolv.conf file and that your chosen nameservers are functional.
AllowStoreRestart is disabled by default because it will allow any writable file to be corrupted by a malicious user. It is recommended that this option is only used with authenticated users and then only in certain directories.
As mentioned in the description of the HiddenStores configuration directive, use of that directive is incompatible with the FTP command REST. Either disable use of REST with the AllowRetrieveRestart and AllowStoreRestart directives, or do not use HiddenStores.
The default behaviour for ProFTPD is to display all times relative to GMT. To use local time set "TimesGMT off" in the server section of the config. There is a known issue with Redhat 7, with regard to time handling. http://www.redhat.com/support/errata/rh7-errata-bugfixes.html
There appear to be some problems with both the use of sendfile() in ProFTPD and with the implementation within certain operating systems.
Short answer, no. Longer answer is no, but you can minimise the effects. The cleanest approach on servers which have significant amounts of traffic appears to be to use ftpshut to block new connections and terminate existing ones after a pre-determined time period and then to upgrade and restart. This approach limits the number of downloads which are terminated part way through.
The default ProFTPD configuration file uses the user "nouser" and the group "nogroup", some systems / distributions do not have the group "nogroup" defined. The solution is to either add the group "nogroup" to /etc/groups or to change the "nogroup" entry in the proftpd.conf to a group which does exist.
The setting of the group privileges for a process uses the setgroups(2) system call. This call will fail with the above error message for one of two reasons: there is a negative GID value for one of the groups, or the maximum number of groups for a single user has been exceeded.
Ideally, all IDs, both UID and GID, will be positive. Unfortunately, it is common on many systems to use -1 or -2, especially for such users as 'nobody', or group 'nogroup'. Use of these values uses C's treatment of data types to make the actual numeric value very high; some functions, like setgroups(), do not like this, though. In general, always use positive ID numbers.
The other limitation is the number of supplemental groups for a user (eg non-primary groups, the ones configured in /etc/group). The maximum number of supplemental groups to which a user may belong is defined by the operating system constant NGROUPS_MAX. On some operating systems, such as Solaris, this limitation may be tunable.
Some other applications may not encounter this error if they use the initgroups(3) function, which reads the /etc/group file for a user's supplemental group memberships, and sets those groups. This function, however, silently ignores any supplemental groups for user greater than NGROUPS_MAX, unlike setgroups(2), which complains.
If this is the cause of your error message, any solution will most likely involve reducing the number of groups your users are members of, or tuning the NGROUPS_MAX value, if your operating system allows it.