Description of problem: When "kssendmac" is in the kernel parameters, the field HTTP_X_RHN_PROVISIONING_MAC_0 is send over in environment variables. In F9 Beta, this field is no longer being sent as far as I can tell, causing scripts that depend on it to not be able to detect the mac. So far this impacts Cobbler at least, and will probably impact RHN later. Version-Release number of selected component (if applicable): F9-Beta release How reproducible: Always Steps to Reproduce: 1. PXE with kssendmac in kernel args 2. have a CGI script that does something with the mac address field (such as logs it) 3. verify that the field is not present Actual results: No field found in requests. Expected results: Field contains mac address as in earlier versions of Fedora/RHEL/etc Additional info: I quickly grepped through the head of the anaconda git branch [root@mdehaan anaconda]# find . | xargs grep RHN ./loader2/urlinstall.c: q = asprintf(&tmpstr, "X-RHN-Provisioning-MAC-%d: %s %s\r\n", This only gives the lowercase version, though changing the CGI script to use this var also does not work, so I don't believe either are getting sent over in HTTP headers.
It has 'ks' in it, that means it gets assigned to Chris, right? :-)
Hm, I did a quick setup where anaconda prints the headers it's sending and apache on my laptop logs the value of any X-RHN-Provisioning-MAC-0 (only one interface in my test machine, after all) header and here's what I get. anaconda says it's sending: User-Agent: anaconda/11.4.0.73 X-Anaconda-Architecture: x86_64 X-Anaconda-System-Release: Fedora X-RHN-Provisioning-MAC-0: eth0 00:1A:A0:A0:AC:AC and apache logs the following: 10.34.39.31 - - [18/Apr/2008:05:07:09 -0400] "GET /ks.cfg HTTP/1.0" 404 281 "eth0 00:1A:A0:A0:CA:AC" So it's definitely sending the header, at least in my test case. Is there anything interesting about your setup there that might be important to know?
Sure. It's possible I screwed up my test on the later part (I'm not sure how), but I have some old code (and you can also google for it), that was looking for the HTTP_X_RHN_PROVISIONING_MAC_0 all uppercase version that was no longer working -- which was working fine previously on F8. I see this version of the header is mixed case. Do I have to look for both versions of the header now? That being said, I did test with the lowercase version, wget'ing to a CGI in %post, and that didn't log the mac. Also, my test is using a seperate CGI, so are you sure it's sending the header on all requests made from Anaconda and not just the ks.cfg one? See: http://git.fedorahosted.org/git/?p=cobbler;a=blob_plain;f=scripts/register_mac.cgi;hb=60e7b2048cb810082d9f5da189d827d0dec3747c http://git.fedorahosted.org/git/?p=cobbler;a=blob_plain;f=scripts/install_trigger.cgi;hb=devel I changed the last script (which is probably easier to test with) to the mixed case form and still no luck. (kssendmac was definitely set also). Not ruling out user error, but it seems strange. Thanks!
Also should add, this was F9 Beta from /mnt/engarchive2, so if this has changed since, then that could be related. If there's another initrd image I should be testing with, let me know, and I can do that.
Hm, as far back as RHEL3 the documentation references HTTP_X_RHN_PROVISIONING_MAC but the actual header being added is X-RHN-Provisioning-Mac. So I don't know what's going on there. It only sends this header for getting the kickstart file, updates images, and driver disks. Once you're out of the loader, this header is no longer sent. I think that's the way it's basically always been. Is it possible that you're testing on a machine with multiple NICs and the header being sent is X-RHN-Provisioning-Mac-1 or something similar instead?
Yeah, I think you're right. I apparently just got confused with the other stuff. (That being said, I think it would be neat if it was always sent) The first time I've seen this is when requesting a kickstart via CGI, so that explains much. I'm not sure what is translating between the two, but perhaps that's just how the environment variables are accessed via CGI. Might be RFC stuff. Perhaps my other scripts were working because they were matching on the IP, and I should have never expected the MACs to log. I definitely think we can close this and I can combine the CGI-fetcher with the registration bits to achieve the things I need to achieve. Sorry for the confusion, and thanks for the info!