Greetings,<br><br>I have a situation that is probably not unique to my company. In our enterprise, we have Solaris x86 and Linux systems that boot using grub, and via the magic dhcp option 150. We also have a Cisco Call Manager phone infrastructure deployed company-wide, on their own networks that rely on option 150 being defined differently.<br>
<br>Using ISC dhcpd version 3.0.x (specifically, version 3.0pl2, and 3.0.7), the following works:<br><br>option call-manager-addr code 150 = array of ip-address;<br>option grubmenu code 150 = text;<br><br>By defining two options we can deploy two variations on option 150. For hosts to be jumpstarted, for example, we can create a jumpstart class for them:<br>
<br>class "jumpstart-i386" {<br> ...<br> option grubmenu "/sun/boot/grub/menu.lst.HW200801";<br>}<br><br>and when this subclass is applied to a host option 150 is sent back as a test string pointing to the menu.lst that we want to use for this build (that is the HW200801 grub boot menu.<br>
<br>In the same configuration file, we can do this:<br><br> subnet <a href="http://10.0.8.128">10.0.8.128</a> netmask <a href="http://255.255.255.128">255.255.255.128</a> {<br> option routers <a href="http://10.0.8.129">10.0.8.129</a><br>
option call-manager-addr <a href="http://10.0.0.1">10.0.0.1</a>, <a href="http://10.0.1.1">10.0.1.1</a>, <a href="http://10.0.2.1">10.0.2.1</a>;<br> option subnet-mask <a href="http://255.255.255.128">255.255.255.128</a>;<br>
<br> pool {<br> range <a href="http://10.0.8.139">10.0.8.139</a> <a href="http://10.0.8.254">10.0.8.254</a>;<br> failover peer "PHONE";<br> deny dynamic bootp clients;<br>
}<br> }<br><br>However, with the newer versions of dhcpd (tested with 3.1.1, 4.0.1b1, and 4.1.0b1), the definition of the grubmenu option seems to override the definition of the call-manager-addr option, resulting in a parse failure.<br>
<br>I would like to ask two questions:<br><br>1) Is this an intentional change? Based on the overloading of the meaning of option 150 in grub, etherboot, and Call Manager (though etherboot uses it as a client->server option, and not as a server->client option) it seems clear that there needs to be a way to deal with this conflict, even if it is on a subnet-by-subnet or host-by-host basis. From the list of assigned tftp codes at <a href="http://www.iana.org/assignments/bootp-dhcp-parameters/">http://www.iana.org/assignments/bootp-dhcp-parameters/</a> it seems that currently this situation is known, but not "resolved" in any sensible way (eg. vendor-encapsulated options for grub).<br>
<br>2) Is there any way to vary the type and contents option 150 depending on known info from the client, eg. the vendor-class-identifier, in versions 3.1.1 and above? Am I doomed to doing something like this:<br><br>option opt-150-hack code 150 = string;<br>
<br>subnet ...1 netmask ... { # phone network<br> option opt-150-hack 0a:00:00:01:0a:00:01:01:0a:00:02:01; # Off the top of my head attempt to encode <a href="http://10.0.0.1">10.0.0.1</a>,<a href="http://10.0.1.1">10.0.1.1</a>,<a href="http://10.0.2.1">10.0.2.1</a><br>
...<br>}<br><br>subnet ...2 netmask ... { # non-phone network<br> option opt-150-hack "/sun/boot/grub/menu.lst.HW200801";<br> # or would the above need to be the result of passing it through od -t x2 plus some colons?<br>
# option opt-150-hack 73:2f:6e:75:62:2f:6f:6f:2f:74:72:67:62:75:6d:2f:6e:65:2e:75:73:6c:2e:74:57:48:30:32:38:30:31:30:00:0a; #Uggh?<br>}<br><br>Any insight, pointers, etc. would be appreciated. I haven't found a lot directly related to my question or the change in the parser in the documentation so far, and nothing about requiring a 1-to-1 mapping of user-defined option names to option numbers.<br>
<br>Thanks,<br><br>-Peter<br>