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):
Steps to Reproduce:
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:
then it quits and rpm gives the glob error.
On 7.1, the sniffer shows these commands:
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
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
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
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)))
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.