[ipxe-devel] Confirm Possible mishandling of http port when http auth is used.

[Andrew Stuart]

On 5/4/2011 10:26 AM, Andrew Stuart wrote:
> On 4/26/2011 5:58 PM, Andrew Stuart wrote:
>> Using ipxe dated Apr 19th 17:51 (according to filesystem.. I haven't
>> figured out how to tell which git revision I am at yet)
>>
>> I can successfully boot http://my.boot.server:8081/myfile.img,
>> when I try the authmenus example from etherboot's site the download
>> fails, unfortunately I have been unable to capture the output, but as it
>> flashes by, it appears :8081 has been stripped from the url.
>>
>> I setup the same site on port 80 as a temporary trial, and confirmed it
>> works as expected, initial handoff is 8081 for boot.php / vesamenu.c32,
>> then after it authenticates everything else goes to port 80.
>>
>> I reverted my setup to be identical to the setup used for authmenus to
>> have a working example for anyone else.
>> (http://etherboot.org/wiki/appnotes/authmenus)
> -snip-
>
> I have confirmed it was something with my setup, although at this time I
> am not sure what. I do know I was having issues with vmware workstation
> 7 and ipxe/vesamenu, but that is/should be unrelated.
>
> -A

Is there a way to compile with more (debug) information for http.c and 
associated files?

I did finally figure out what I did differently. Gene's modifcation to 
boot.php on http://etherboot.org/wiki/appnotes/authmenus to return the 
http port the request was sent to appears to be ignored by iPXE.

To clarify loading http://boot.myserver.com:9090/boot.php in a browser 
results in:

#!gpxe
imgfree
login
set 209:string bootcfg.php
set 210:string 
http://${username:uristring}:${password:uristring}@boot.myserver.com:9090/
chain ${210:string}pxelinux.0

Which is the expected result.

However, booting with iPXE I see the request going to the webserver on 
port 9090, and /boot.php is retrieved as expected, all other requests 
fail, as they go to port 80.

Modifying boot.php from:
$_SERVER["HTTP_HOST"].$dir."\n";
to:
$_SERVER["HTTP_HOST"] .":9090".$dir."\n";

Does give the expected results as long as you remember to change the 
port # if you are using different port #'s for different tasks.


Additionally, I am having an issue with having authentication being 
passed reliably, and was hoping to try and track it down.

Example from webserver log:
66.92.0.186 - - [05/May/2011:15:04:55 -0700] "GET /boot.php HTTP/1.1" 
200 165 "-" "iPXE/1.0.0+"
66.92.0.186 - - [05/May/2011:15:05:22 -0700] "GET /pxelinux.0 HTTP/1.1" 
200 26442 "-" "iPXE/1.0.0+"
66.92.0.186 - andrew [05/May/2011:15:05:23 -0700] "GET /bootcfg.php 
HTTP/1.1" 200 75 "-" "iPXE/1.0.0+"
66.92.0.186 - - [05/May/2011:15:05:23 -0700] "GET /devel/vesamenu404.c32 
HTTP/1.1" 200 155792 "-" "iPXE/1.0.0+"
66.92.0.186 - andrew [05/May/2011:15:05:24 -0700] "GET /menu/menu.php 
HTTP/1.1" 200 1055 "-" "iPXE/1.0.0+"
66.92.0.186 - - [05/May/2011:15:05:25 -0700] "GET 
/menu/backgrounds/test.png HTTP/1.1" 200 66962 "-" "iPXE/1.0.0+"
66.92.0.186 - - [05/May/2011:15:05:35 -0700] "GET /memtest HTTP/1.1" 200 
164504 "-" "iPXE/1.0.0+"

notice only bootcfg.php and menu.php have authentication, all other 
requests have none.

This is also repeatable without the use of pxelinux.0 calling menu.c32 
from syslinux 3.86. The initial menu load has authentication, subsequent 
requests do not.

This is an issue for me, for two reasons:
A) Ideally I want to call a premenu.php, similar to netboot.me which 
acts as a failsafe for machines that don't boot vesamenu.c32, giving you 
the option of using menu.c32.. But once you call a second file menu.php 
in this example, the authentication information does not exist.
(Using only iPXE/(vesa)menu.c32, does work via pxelinux.0 so far, as log 
above indicates)

One might suggest moving authentication to premenu.php and call it a 
day, which solves my authentication complaint, but removes the dynamic 
menu.php capabilities (unless I get really creative?)


B) While I am getting this setup I have it firewalled to allow my home 
and work ip addresses, but I envision having it open to the world so 
that I can go to any computer, boot off my thumb drive and access my 
boot system. Some of what I intend to boot, includes WinPE images, which 
I could imagine Microsoft coming after me for if someone figures out the 
path to my file, and downloads it manually.

There are at least a few ways to obscure this information to make it 
difficult, but it would be ideal to turn on http authentication for the 
entire directory, requiring a valid user which should solve the problem 
completely.

Looking through http.c, it appears if I did turn on http auth in the 
webserver, that iPXE would respond accordingly?

- Andrew