From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 Description of problem: Under RH 7.1, we were able to use the ftp capabilities of rpm to assist us in spraying updates to several machines using the format: rpm -UvFh ftp://host/path/to/*.rpm Under RH9 this no longer works, I'm receiving this error: error: File not found by glob: ftp://host/path/to/*.rpm Our ftp server is wu-ftpd. I also tried issuing a glob command to an NcFtpd and ArgoFTP server, they also failed....worst case scenario should be that it reports that files are not found or report nothing. This DOES work however when connecting to updates.redhat.com, so whatever ftp server you're using works ok...but not these others. Version-Release number of selected component (if applicable): rpm-4.2.0 How reproducible: Always Steps to Reproduce: 1.listed above 2. 3. Additional info: Note: this feature was working ok on RH7.1 Just for informational purposes, I ran a network sniffer to find out what commands were being run: On RH9, these commands are issued: USER anonymous PASS root@ TYPE I PASV LIST /pub/system/patch/redhat/9 then it quits and rpm gives the glob error. On 7.1, the sniffer shows these commands: USER anonymous PASS root TYPE I PASV NLST /pub/system/patch/redhat/7.1/*.rpm and starts getting files.
Add --ftpdebug to see what's on the wire. Attach failing output here, please.
Created attachment 91298 [details] first connection to a failing server, second to the updates.redhat.com server Here is a listing of what's in the one directory on the server: #ls -al /ftp/pub/system/patch/redhat/9 total 1952 drwxr-xr-x 2 root sys 43 Apr 25 06:14 . drwxr-xr-x 4 root sys 31 Apr 25 06:13 .. -rw-r--r-- 1 root sys 996093 Apr 25 06:14 LPRng-3.8.19-3.1.i386.rpm
Created attachment 91299 [details] example of RH7.1 debug message
Can you do the same LIST command using a ftp client? There's probably a debug option on the client to display the FTP protocol too. That info would help identify what the problem is, all I can tell from the trace is that "LIST *" is not returning what's in the directory.
Ah, so the problem is NLST not LIST, needs to be used. Grrr, FTP is a mess.
Created attachment 91301 [details] ftp -d output, not really too conclusive from the client side Yeah, it looks like maybe a regular listing is throwing off the rpm client when it sees all of the permissions/size info returned.
will there be a special bug release for this? or some sort of workaround?
Nope, I'm unable to support or maintain non-linux network functionality like this. The fix for one server is s/LIST/NLST/, the fix for others is exactly the opposite, coming up with an AC-DC solution requires non-linux servers for testing. Deferred because I'd like to support, but alas, cannot.
just a small note on this. I'm not sure if this is really an NLST vs. LIST thing. I managed (finally) to get around to rebuilding rpm from the source rpm, and got the NLST change in there, but it still doesn't work, and I noticed this in the ftp debug output: -> NLST /pub/system/patch/redhat/9 <- 150 Opening BINARY mode data connection for file list. <- 226 Transfer complete. I notice when logged in through ftp interactively, it doesn't create the directory in binary mode, it does it in ASCII mode. When connecting to the redhat updates server, it doesn't tell me the mode at all. So, I'm going to see if I can force an ascii mode transfer when listing files and see if that solves it.
I modified rpmio/rpmio.c and changed line 1131 to if ((rc = ftpCommand(u, NULL, "TYPE", "A", NULL))) goto errxit; just to see what would happen, and it does then correctly get the file list and begin to transfer files....but in ASCII mode, which is what I expected. So, what I want to do is put something on either side of line 854 in rpmio/rpmrpc.c: u->openError = ftpReq(fd, "LIST", path); Something that would put ftp into ASCII mode, then list, then go back to binary mode....but I don't know how to get the syntax right to make that happen.