Red Hat Bugzilla – Bug 442962
HTTP_X_RHN_PROVISIONING_MAC_0 missing when using kssendmac
Last modified: 2008-04-18 11:01:42 EDT
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):
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
3. verify that the field is not present
No field found in requests.
Field contains mac address as in earlier versions of Fedora/RHEL/etc
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
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:
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
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?
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?
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.
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
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!