Bug 442962 - HTTP_X_RHN_PROVISIONING_MAC_0 missing when using kssendmac
HTTP_X_RHN_PROVISIONING_MAC_0 missing when using kssendmac
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
high Severity low
: ---
: ---
Assigned To: Chris Lumens
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-04-17 17:21 EDT by Michael DeHaan
Modified: 2008-04-18 11:01 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-18 11:01:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael DeHaan 2008-04-17 17:21:19 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):

F9-Beta release

How reproducible:


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.
Comment 1 Jeremy Katz 2008-04-17 17:34:58 EDT
It has 'ks' in it, that means it gets assigned to Chris, right? :-)
Comment 2 Chris Lumens 2008-04-18 05:11:24 EDT
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/
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: - - [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?
Comment 3 Michael DeHaan 2008-04-18 09:17:47 EDT

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.

Comment 4 Michael DeHaan 2008-04-18 09:28:14 EDT
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.

Comment 5 Chris Lumens 2008-04-18 09:30:52 EDT
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?
Comment 6 Michael DeHaan 2008-04-18 11:01:42 EDT
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!

Note You need to log in before you can comment on or make changes to this bug.