Thank you: [CLUE-Tech] cannot get ftpd started

[Jason Friedman]

Thanks, Jim, for your reply.

It ended up not being any of the things you suggested, though those were things that at one time or another have "gotten" me.  And the "netstat -nap | grep :21" command is handy, I'll hold onto that one.

For whatever it's worth, I think the problem was this:

root at charles /etc/xinetd.d $ ll *ftp*
-rw-r--r--    1 root     root          325 Sep 14 19:30 gssftp
-rw-r--r--    1 root     root          492 Sep 14 19:30 tftp
-rw-r--r--    1 root     root          275 Sep 15 17:22 vsftpd
-rw-r--r--    1 root     root          361 Sep 21 03:28 wu-ftpd

These files appear in /etc/xinetd.d as a result of an "install everything" install of RedHat 7.3.

root at charles /etc/xinetd.d $ grep 'disable' *ftp*
gssftp:	disable	= yes
tftp:	disable	= yes
vsftpd:	disable	= no
wu-ftpd:	disable	= no

I think xinetd may have been trying to start both vsftpd and wu-ftpd.  I wonder why it wouldn't pick one (even randomly)?   Anyway, after disabling vsftpd, my FTP server is answering requests.

THANK YOU VERY MUCH!

On 2002.09.21 04:32 Jim Ockers wrote:
> Jason:
> 
> > I'm trying to get an ftp daemon running.  I'm using Red Hat 7.3.  I tried
> > starting it through xinetd, but no luck (I'm reasonably sure I know how to use
> > xinetd, as I started telnetd and ipop3d that way). 
> 
> First of all you should be sure xinetd is running.  (Service xinetd start)
> 
> Then, to start the FTP daemon with xinetd, you edited the /etc/xinetd.d/wu-ftpd
> file, and changed the "disable = yes" to "disable = no".  Then, you issued a
> SIGUSR2 signal to xinetd, right?  (Or, did a "service xinetd restart").  ((Or,
> you could always reboot.  Where have we heard that before?))
> 
> > So, I tried a brute force method:
> > $ /usr/sbin/in.ftpd
> 
> This is probably not going to work, because the file descriptor that the FTP
> daemon expects to get is a socket.  When you start it from the interactive
> shell, you aren't giving it a socket as a file descriptor, which is why it's 
> complaining.
> 
> You can verify that something is listening on port 21 (it won't be the FTP 
> daemon, but it will be xinetd) by doing this:
> 
> [73] maradi.ockers.net:/etc $ netstat -nap | grep :21
> tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      9520/xinetd
> 
> Just because there is a listener on port 21 does not mean that any sockets can 
> be opened to that port on your IP address.  You may have an iptables firewall 
> running, which may be blocking (at the INPUT chain of the filter table) 
> inbound FTP connections, even from localhost perhaps.
> 
> You should run "iptables -F" to clear the entire iptables, then try to connect 
> to your FTP again.  You should try to originate the connection from your 
> localhost if possible, by doing "ftp 127.0.0.1" at the command prompt, and see 
> if any FTP daemon responds.
> 
> Then, you'll verify that you don't have a filtering firewall or something else 
> that is living between the host you're coming from and the FTP server.  It's 
> possible that a filtering firewall can also prevent inbound FTP (or any other 
> type of access), depending on its configuration.
> 
> Hope this helps.
> 
> > But,
> 
> > $ ps -ef | grep ftp
> > root     27081     1  0 Sep14 ?        00:02:51 /usr/bin/gftp-gtk
> > root     27084 27081  0 Sep14 ?        00:00:04 /usr/bin/gftp-gtk
> 
> > and,
> 
> > $ tail /var/log/messages
> > Sep 21 03:29:16 charles ftpd[25655]: wu-ftpd - TLS settings: control allow, client_cert allow, data allow
> > Sep 21 03:29:16 charles ftpd[25655]: getpeername (/usr/sbin/in.ftpd): Socket operation on non-socket
> 
> --
> Jim Ockers (ockers at ockers.net)
> Contact info: please see http://www.ockers.net/
> 
> Fight Spam! Join CAUCE (Coalition Against Unsolicited Commercial Email)
> at http://www.cauce.org/ .
> 
> _______________________________________________
> CLUE-Tech mailing list
> CLUE-Tech at clue.denver.co.us
> http://clue.denver.co.us/mailman/listinfo/clue-tech
>