Description of Problem: Running Seawolf on two IA64 machines. On both, attempting to FTP into the machines gives a login prompt. Upon entering the username, the password prompt appears. After entering the password, the connection hangs indefinately until you kill the FTP client process on the client end. FTP is useless until this problem is solved.
You are using wu-ftpd and not the kerberos ftp daemon, correct?
wu, as far as I know: [root@donkeykong /root]# rpm -qa | grep -i ftpd wu-ftpd-2.6.1-16 [root@donkeykong /root]# [root@donkeykong /root]# ls -lsa /etc/xinetd.d/*ftp* 4 -rw-r--r-- 1 root root 361 Jul 31 15:43 /etc/xinetd.d/wu-ftpd [root@donkeykong /root]#
I've just tried this between 3 of our build machines, and I'm not seeing any problems. Check your network connectivity and hardware.
Network connectivity is fine: You can telnet/ssh in and login without a hitch. Another detail: In the default setup, /etc/ftpaccess has the following lines uncommented: # Don't allow system accounts to log in over ftp deny-uid %-99 %65534- deny-gid %-99 %65534- allow-uid ftp allow-gid ftp If those lines are uncommented, you get: [minter@stonecold ]$ ftp donkeykong Connected to donkeykong.rtp.avanticorp.com. 220 donkeykong.rtp.avanticorp.com FTP server (Version wu-2.6.1-16) ready. Name (donkeykong:minter): minter 331 Password required for minter. Password: 530 Login incorrect. Login failed. ftp> If I comment those lines out, you get: 530 Login incorrect. [minter@stonecold ]$ ftp donkeykong Connected to donkeykong.rtp.avanticorp.com. 220 donkeykong.rtp.avanticorp.com FTP server (Version wu-2.6.1-16) ready. Name (donkeykong:minter): minter 331 Password required for minter. Password: [INDEFINATE HANG] Running ps on the ftpserver shows: [root@donkeykong /root]# ps auxwww | grep -i ftp root 29763 0.0 0.0 5856 3600 ? DN 13:51 0:00 ftpd: stonecold.rtp.avanticorp.com: connected: IDLE So I don't think it's a networking problem on our end. It _could_ be authentication, but we have a standard NIS setup, and auth works for other services. --Wade
Guess it's a nis or pam problem then - can't reproduce it here with fairly standard nis and kerberos accounts though. Tried all of those as well as local accounts, no problems. Do you get anything in /var/log/messages when this happens? Can you strace the pid of the ftp server process when it happens? Do anonymous logins work? What is your UID, if you're being blocked by %-99 %65534-?
The strace provided the clue I needed. We have an optical jukebox server that serves up about 70 NFS mountpoints from optical platters. Attempting to access one of these mountpoints results in a ~20sec delay while the platter is moved into position and made available. Looking at the strace on my ftp login, wu-ftpd appears to be checking every mountpoint defined in /etc/fstab, and doing a "chdir" into those directories. With our setup, that will result in huge delays and an eventual timeout. So that's what's going on. The question now is: Is there a way to disable this NFS checking at logintime, or do you suggest a workaround for this?
Don't know off the top of my head what's causing this; I'll have to read the source before I can answer.
Ok. Here's some of the output from the strace: open(".", O_RDONLY) = 8 chdir("/archive") = 0 SYS_1211(0x80000fffffff5c29, 0x80000fffffff49a0, 0xc8, 0x4000000000048180, 0xc000000000000899, 0, 0x4000000000058ba0, 0) = 0 chdir("dist00009") = 0 getcwd("/archive/dist00009", 4095) = 19 fchdir(8) = 0 close(8) = 0 open(".", O_RDONLY) = 8 chdir("/archive") = 0 SYS_1211(0x80000fffffff5c29, 0x80000fffffff49a0, 0xc8, 0x4000000000048180, 0xc000000000000899, 0, 0x4000000000058ba0, 0) = 0 chdir("dist00010") = 0 getcwd("/archive/dist00010", 4095) = 19 upeek: ptrace(PTRACE_PEEKUSER, ... ): Input/output error
I managed to work around the problem by finding an autofs init script that emulates Sun direct maps, thus eliminating the need to have all of those optical platter mountpoints listed in the fstab. So I guess it's problem solved, unless this is a deeper issue with wu-ftpd that needs investigating. Thanks!
Traced down to wu-ftpd trying to access all directories in fstab; changing description and priority but leaving it open until we've figured out for sure why this is being done.
Please use vsftpd, wu-ftpd is not maintained anymore.