Bug 113260

Reporter writes
> Can you please advise me if this is fixed, or how to
> get a bugfix integrated, in Fedora/Redhat XXX ? 

making it so the dhclient also sends "Red Hat Enterprise Linux/Fedora
Core Linux" as the vendor class identifier would also be use full(or
something like it).

I've been telling my users to type this as root: 

echo "send vendor-class-identifier \"Red Hat Linux\"" >>
/etc/dhclient-eth0.conf

But getting it added by default would be a very nice addition to both
RedHat Enterprise and Fedora Core (As both are used here).  

Same bug in Fedora Core3 test3, same workaround applies.

All users have to do is set the DHCP_HOSTNAME variable in the network scripts
environment, and then the dhclient-${interface}.conf script will be set up
correctly to send the host-name dhcp option.
Yes, it would be nice if system-config-network could configure this with the GUI -
but the mechanism is in place for it to work.
NOTE: correctly set up dhcp servers should be set up to do the DDNS update 
      themselves automatically, not requiring clients to send the host-name
      option.

Perhaps this bug should be closed - it is possible to set up.

The original point of the bug was that dhclient does not send a dhclient
identifier with a '1' byte preceding it - sorry I misread it initially.

This also can be easily set up in the network scripts, now that dhclient 
supports a -I 'dhcp-client-identifier' option - you could make this setting
in /etc/sysconfig/network-scripts/ifcfg-ethX :

DHCLIENTARGS=-I' 01:'`ip link show $interface | sed -n '/link\/ether/{s/^.*ether
//;s/\ .*$//;p}'
 
Then dhclient would send the dhclient identifier of 01: followed by the
ethernet address. 

This is purely a peculiarity of Windows DHCP servers that contravenes the 
DHCP RFCs that they need the 01: byte preceding a dhcp-client-identifier
option to use the ethernet address - RFC conformant dhcp servers simply
use the ethernet address if no dhcp-client-identifier option is specified.

Using a 'vendor-class-identifier' is entirely dependant on the site
specific dhcp server configuration , but also can be easily set up
in dhclient-${interface}.conf .

dhclient also now uses a global 'dhclient.conf', which will take effect
if no 'dhclient-${interface}.conf' exists - the 'vendor-class-identifier'
setting could go in there.

In short, I think we provide enough mechanisms to enable users to customize
dhclient operation; it is up to users to use them to implement site specific
policy. So I think this bug can probably be closed.

(Just a small note: writing shell constructs like that in ifcfg-* will probably
break badly once s-c-network or other tools attempt to edit the files.)

Moving this to target from Blocker.

Workaround exists for this as noted in comment #7 using the -I switch for
dhclient.  It's Windows-specific, so it shouldn't be the default for all systems.

Regarding vendor-class-identifier and anaconda, we now send the string
'anaconda-SYSNAME RELEASE MACHINE' as obtained from uname(2).  An example string
is: anaconda-Linux 2.6.19-1.2895.fc6 i686

Closing this bug.