Red Hat Bugzilla – Bug 56790
ks=http kickstarts cause anaconda tracebacks with http 1.1 server
Last modified: 2007-04-18 12:38:27 EDT
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
Version-Release number of selected component (if applicable):
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
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 email@example.com
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
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
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 :-).
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
Switched back to using HTTP/1.0 in CVS