Bug 89632 - rpm ftp globs do not work properly in RH9
Summary: rpm ftp globs do not work properly in RH9
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
(Show other bugs)
Version: 9
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-25 13:04 UTC by Kevin Taylor
Modified: 2007-04-18 16:53 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-05-02 16:10:45 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
first connection to a failing server, second to the updates.redhat.com server (6.26 KB, text/plain)
2003-04-25 14:23 UTC, Kevin Taylor
no flags Details
example of RH7.1 debug message (1.99 KB, text/plain)
2003-04-25 14:28 UTC, Kevin Taylor
no flags Details
ftp -d output, not really too conclusive from the client side (5.78 KB, text/plain)
2003-04-25 14:38 UTC, Kevin Taylor
no flags Details

Description Kevin Taylor 2003-04-25 13:04:17 UTC
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):

How reproducible:

Steps to Reproduce:
1.listed above

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@
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
NLST /pub/system/patch/redhat/7.1/*.rpm

and starts getting files.

Comment 1 Jeff Johnson 2003-04-25 13:29:33 UTC
Add --ftpdebug to see what's on the wire. Attach failing
output here, please.

Comment 2 Kevin Taylor 2003-04-25 14:23:16 UTC
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

Comment 3 Kevin Taylor 2003-04-25 14:28:44 UTC
Created attachment 91299 [details]
example of RH7.1 debug message

Comment 4 Jeff Johnson 2003-04-25 14:32:58 UTC
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.

Comment 5 Jeff Johnson 2003-04-25 14:34:29 UTC
Ah, so the problem is NLST not LIST, needs to be used.

Grrr, FTP is a mess.

Comment 6 Kevin Taylor 2003-04-25 14:38:22 UTC
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.

Comment 7 Kevin Taylor 2003-05-02 16:04:43 UTC
will there be a special bug release for this? or some sort of workaround?

Comment 8 Jeff Johnson 2003-05-02 16:10:45 UTC
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.

Comment 9 Kevin Taylor 2003-09-23 14:36:00 UTC
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.

Comment 10 Kevin Taylor 2003-09-23 17:35:38 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.