Description of problem: Currently the dhcpclass option can be used to manually specify a DHCP VCI. This is very useful for many scenarios including using conditional logic in the DHCP server to send back different kickstart files. If would be very nice if the *default* VCI had information enough to distinguish which version and distro and arch anaconda is about to install. You could do this two ways. Directly specifying the distro and version, or indirectly. The direct approach might use the following: RHEL6 i686 FC7 ppc64 An indirect approach would be just to send the full kernel version+rel plus the arch. A very safe bet is that there will never be a Fedora and RHEL shipping with the exact same kernel version+rel. This indirect approach would mostly likely be easier to implement and less fragile to breaking (think CentOS). This indirect approach is what SUSE does, for example: SLES10 sends: Linux 2.6.16.21-0.25-default i686 and SUSE 10.1 sends: Linux 2.6.16.21-0.8-default i686
I've added support for this feature in anaconda HEAD CVS. I decided to go with the method that SuSE uses rather than hardcoding knowledge about releases. So now, unless you specify a dhcpclass, anaconda will call uname(2) and send a string built like this: struct utsname u; uname(&u); asprintf(&class, "%s %s %s", u.sysname, u.release, u.machine); On my laptop, this reports 'Linux 2.6.18-1.2869.fc6 i686'. This should be sufficient to distinguish between Fedora and RHEL releases. Thanks for the suggestion.
Very nice! But you just broke any DHCP servers that *already* new about anaconda. How about a compromise so the DHCP server still knows it's anaconda? asprintf(&dhcpclass, "anaconda-%s %s %s", kv.sysname,kv.release,kv.machine); Which on my test machine would have produced "anaconda-Linux 2.6.19-1.2912.fc7 x86_64" and prevented me from having to further mangle the DHCP server config.
Yeah, ok. Done.