[BlueOnyx:16967] Proftpd behavior
George F. Nemeyer
tigerwolf at tigerden.com
Thu Feb 5 15:06:33 PET 2015
Last night proftp went south for no immediately apparent reason, and the
active monitor was complaining.
Looking at proftpd logs showed lots of this sort of thing:
2015-02-05 03:30:02,953 mod_ban/0.6.2: added ban event for
2015-02-05 03:45:03,423 mod_ban/0.6.2: obtained shmid 720898 for
but the ban.tab log file is always 0 bytes and the date hasn't changed
from the install default.
The 'added ban event' entries don't give a clue as to what IP may be
involved, though some other entries look like:
2015-02-05 04:15:03,533 mod_ban/0.6.2: ban event ClientConnectRate
entry '127.0.0.1' has expired (841 seconds ago)
So I suspect that it may be the sausalito active monitor probes that's
causing at least part of the issue.
I noticed the /etc/proftpd.conf file had also been changed at some point
last night. In investing this, I found a <VirtualHost... > entry for a
bogus IP there. It was apparently added when I added a new site but
typoed the IP number. I had corrected the IP from the admin GUI, but the
bad <VirtualHost...> block didn't get removed. I manually edited the
proftpd.conf file to delete it.
Finally, I saw pam_abl had blocked 'root'...which happens a lot. When I
removed that block, proftpd began to respond normally again.
So the questions for education are:
Is proftpd logging properly since-
1. It logs 'ban events' without any indication of what IP is causing it?
2. 'ban.tab' is always empty with original date?
3. 'controls.log' and 'tls.log' also seem always empty, but the date
Is there a way to tell proftpd 'forget all your blocks' to open it up?
Should <VirtualHost..> entries get purged by some mechanism as part of the
routine changes/removal of sites? Is having a bogus one likely to cause
Should a pam_abl 'root' block cause proftpd to fail to accept *all*
connections (which appeared to be the case)?
Any insights would be helpful.
More information about the Blueonyx