|Summary:||HTTP network installs fail with FTP IO error|
|Product:||[Retired] Red Hat Linux||Reporter:||David Morse <david_j_morse>|
|Component:||installer||Assignee:||Erik Troan <ewt>|
|Status:||CLOSED RAWHIDE||QA Contact:||Brock Organ <borgan>|
|Version:||7.0||CC:||gaudet_roger, msw, tsombakos_mark|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2001-05-09 18:40:44 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description David Morse 2001-04-05 23:02:15 UTC
Attempting to install RH7 over a network *always* fails via HTTP, but works fine via FTP. I've tried both TUX 2.0 and IIS 5.0 as Web servers, both fail the same way. Using a browser, I can GET /path/RedHat/base/netstg1.img just fine, but I get an "FTP IO error" from the RH7 bootnet disk. Let me stress that FTP works fine with the same IP address and path, so networking is not the problem. The 3c59x driver is loaded and works correctly. Reproducible: Always Steps to Reproduce: 1. Create RH7 boot disk from bootnet.img on RH7 CD1 2. Boot a machine with that floppy (Dell Precision 410 in my case) 3. Choose HTTP network install, enter IP address and path of where files are on web server. Actual Results: Get a dialog box with the error "Failed to retrieve /RH7/RedHat/base/netstg1.img: FTP IO error" Then a second dialog box with title "HTTP" and body "Unable to retrieve the first install image" Expected Results: The network images should have been downloaded (as the FTP network install does) and installation should have proceeded. VC3 showed the 3c59x NIC was found, and I can ping this machine from the Web server. VC3 also shows "transferring http://126.96.36.199//RH7/RedHat/base/netstg1.img to a fd" for every failed attempt. I used a packet monitor on the network to determine that the GET request *does* come into the Web server, and it sends netstg1.img to the client without problems. I have no idea why the installer is giving an FTP IO error message (esp since it's HTTP).
Comment 1 Brent Fox 2001-04-11 18:23:00 UTC
HTTP installs *do* work with Red Hat Linux 7. Our QA dept. tests all of the installation methods, although our HTTP servers are all Red Hat Linux running Apache. I don't think TUX or IIS has been tested as an HTTP installation server. Having said that, I'm not sure why it's not working for you. Since the GET request is reaching the web server, it looks like the server isn't responding correctly to the request. Have you tried pointing a different machine at the web server and see if you can pull netstg1.img over via a web browser. That would take the installer completely out of the equation, so maybe we can narrow the problem down a little.
Comment 2 David Morse 2001-04-11 23:56:56 UTC
> Have you tried pointing a different machine > at the web server and see if you can pull > netstg1.img over via a web browser. Yes, in the original bug report above I said "Using a browser, I can GET /path/RedHat/base/netstg1.img just fine, but I get an "FTP IO error" from the RH7 bootnet disk." I will attempt to install tomorrow with Red Hat/Apache and let you know what happens.
Comment 3 David Morse 2001-04-13 22:18:08 UTC
I just tested with Red Hat/Apache 1.3.19 (from RH 7.1) and it works great. I just tested TUX 2.0 (also from RH 7.1) and it failed, although GETs with a browser again worked fine. I'm going to attach a tarball that shows a tcpdump of the Apache case and the TUX case. The Apache one is larger, obviously, since it successfully sends netstg1.img.
Comment 4 David Morse 2001-04-13 22:20:17 UTC
Created attachment 15347 [details] tcpdump of Apache and TUX GET requests during HTTP net install
Comment 5 Brent Fox 2001-04-13 23:49:54 UTC
Hmm. Thanks for your information. This is an interesting problem. I will look at your tcpdump info when I have more time. I wonder what is different about the other web servers that makes things not work. This very well could be an installer problem. I wonder if connecting to an Apache server running on a Windows box would work...
Comment 6 Brent Fox 2001-04-16 00:17:06 UTC
Actually, this problem has been reported before. Resolving as a duplicate. *** This bug has been marked as a duplicate of 23037 ***
Comment 7 Mark Tsombakos 2001-05-04 21:24:08 UTC
The problem seems to be in Anaconda, file loader/ftp.c Line 445 reads: sprintf(buf, "GET %s \"HTTP/1.0\"\r\n\r\n", remotename); This specifically includes quotes around HTTP/1.0. IIS and who knows what other web servers don't like this. Apache seems to ignore it. I don't see the quotes in the HTTP spec at www.w3c.org, FWIW.
Comment 8 David Morse 2001-05-04 22:51:27 UTC
This problem still exists in Seawolf, so the problem is not with old Python libs, as Brent suggested.
Comment 9 Brock Organ 2001-05-07 12:49:30 UTC
Hi Brent, Can we put the text of the solution of the other bug (23037) in this one also? The other bug is a non-public bug, so Mark (email@example.com) is unable to view it ... :)
Comment 10 Brent Fox 2001-05-07 19:40:27 UTC
Ok, we'll take another look at this one.
Comment 11 Brent Fox 2001-05-09 18:36:58 UTC
Here's an excerpt from the HTTP/1.1 spec (of course, we're using HTTP/1.0, so things may differ) The absoluteURI form is REQUIRED when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, and return the response. Note that the proxy MAY forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request loops, a proxy MUST be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example Request-Line would be: GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. The authority form is only used by the CONNECT method (section 9.9). The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (authority) MUST be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original URI, it MUST be given as "/" (the server root).
Comment 12 Brent Fox 2001-05-09 18:38:21 UTC
So, saying something like: GET /index.html HTTP/1.1 Host: www.microsoft.com works on IIS. It also works on Apache, for what it's worth. I don't know if it works on TUX or not.
Comment 13 Mark Tsombakos 2001-05-09 18:40:40 UTC
Yes, but saying GET /index.html "HTTP/1.1" (quotes intended, and included from Anaconda source code) does _not_ work on IIS.
Comment 14 Erik Troan 2001-06-28 20:33:14 UTC
We're doing this now in the loader: sprintf(buf, "GET %s HTTP/1.1\t\nHost: %s\r\n\r\n", remotename, hostname);