Chris Lumens wrote:
As far as stage 1/2, I guess I was confused. My plan is to build in support
for http proxy for ftp/http/s network installation. I was focusing on the
python side of things assuming it was stage 1. In reality I think there
will need to be http proxy support on both stage 1(C) and stage 2(python)
since stage 1 must download stage2.img. Does this sound correct? The good
thing is that proxy support on the python side is very easy. Probably C
will not be so forgiving.
Yeah, this will require work in both stage1 and in stage2. stage1 needs
to be able to download various files via the proxy, so it's not just
going to be things to do in python. It'll probably be significantly
more work to do the stage1 portion because we have our own URL fetching
code in there. Also note that stage1 does not currently support HTTPS,
so adding that will be a fair amount as well.
Since this seems like as good a time as any to bring it up- I don't think I
ever filed a bug when moving from FC5->FC6 support for retrieving the kickstart
file via non-default http port broke.
I.e.
ks=http://10.0.2.2:1234/ks.cfg
worked in FC5, but hasn't since. I looked in the code at the time, but gave up
as I figured another way to pull the kickstart in a qemu install
(i.e. ks=hd:hdb1:/ks.cfg after a -hdb vfat:ro:/path/to/kickstart)
But, it would be nice if the URL fetching code you spoke of would bring back
support for non-port80 http kickstart retrieval. It can be useful.
-dmc
