Hide Forgot
Description of Problem: The anaconda loader isues an HTTP/1.1 request for an http provided kickstart, yet the loader cannot understand HTTP/1.1 responses. Under certain circumstances (i.e. scripted db-backended kickstarts) this causes grbage characters to appear in the ks.cfg file, which causes tracebacks in anaconda. Version-Release number of selected component (if applicable): 7.2-7 How Reproducible: always Steps to Reproduce: 1. use PHP or Python to produce dynamic kickstart file through Apache 1.3.19 web server 2. attempt to ks=http from that script 3. anaconda complains about a KeyError Actual Results: (see attachments) Expected Results: normal install Additional Information: see attachments
Created attachment 38804 [details] kickstart config as retrieved through links
Created attachment 38805 [details] kickstart config as saved by anaconda installer
Created attachment 38806 [details] patch that makes an HTTP/1.0 request instead of HTTP/1.1
Hmm... but then we break with some HTTP server (though I don't remember which). Erik, do you have any opinions on this?
I'm getting almost exactly the same results as johnw@berningeronline.net reported. Same anaconda version, same apache version. I use Perl on apache- 3.1.19 (a RH7.1 box) to generate the kickstart file, and pull it over with ks=http...
I have a testbed where I pull ks files from an apache server (with a python CGI backend) and have not seen this problem. How do we setup a machine to reproduce this issue?
I used a stock RHL 7.1 install (with updates) with the Apache, PHP, and MySQL packages installed (all either stock 7.1 or 7.1 updates from Red Hat). If necessary, I can bundle the scripts I'm using into a tarball and attach it to this bug, but the scripts are very simple.
What I found to be the problem, is that Apache (running my CGI) sends back a Transfer-Encoding: chunked header, as part of the response (since anaconda told the server it could speak HTTP 1.1). So, Apache will then send back a number, which the HTTP 1.1 client should read as a number of bytes to read. The client then reads this number of bytes, and then one more line, which contains the next number of bytes to read, and so on until the document is completely served (This is all probably in an rfc somewhere...) From what I can see, Anaconda just slurps back what Apache sends without regards to the transfer-encoding and puts it in place as the kickstart document. The mysterious numbers/characters that are showing up in the kickstart files are these transfer numbers indicating how many bytes are supposed to be read next. From what I can see in the Anaconda code, no measures are taken to interpret this style of encoding, so the real solution would be to make sure if Anaconda says it can speak HTTP 1.1, it should mean it :-). The patch given previously to change HTTP/1.1 to HTTP/1.0 works for me, but the real change should probably be to make Anaconda HTTP/1.1 compliant. Hopefully my description above will help in that effort.
Switched back to using HTTP/1.0 in CVS
Verified.