"unsetting" global options for a host

[Glenn Satchell]

Hi Rick

Something else to try, but I think this will work...

Define a class for the subset of clients, eg:

class "special" {
	match hardware;
}
subclass "special" 1:aa:bb:cc:dd:ee:ff;
subclass "special" ...

subnet 192.168.1.0 netmask 255.255.255.0 {
   option routers 192.168.1.1;
}
subnet 192.168.2.0 netmask 255.255.255.0 {
   option routers 192.168.2.1;
}
subnet 192.168.3.0 netmask 255.255.255.0 {
   option routes 192.168.3.1;
}
pool {
   allow members of "special";
   range 192.168.1.200 192.168.1.249;
   range 192.168.2.200 192.168.2.249;
   range 192.168.3.200 192.168.3.249;
}
pool {
   deny members of "special";
   range 192.168.1.100 192.168.1.199;
   range 192.168.2.100 192.168.2.199;
   range 192.168.3.100 192.168.3.199;
   option ...
   option ...
}

This relies on a little-known feature where a pool does not have to be 
defined within a subnet. So we have one pool for the special devices 
(allow special), and one pool for everything else (deny special).

Options defined in the global scope are valid for both, however options 
defined in a pool are only valid for that pool.

If necessary the pool could be split for each of the ranges if you 
needed specific options for each range.

I haven't tested this recently, but many years ago we had a similar pool 
configuration due to a bug in the way the default gateway was evaluated. 
This was back in something like 3.0.1 :)

regards,
-glenn

On 02/01/12 07:09, Rick Coloccia wrote:
> Glenn, I'm working on a test scenario to find out if what you suggest
> will work. I suspect it's up to the client whether it treats an option
> with a null value the same way as an undelivered option. Thanks!
>
> -Rick
>
> On 1/31/2012 6:26 AM, Glenn Satchell wrote:
>> On 01/31/12 20:39, Simon Hobson wrote:
>>> Christian Kratzer wrote:
>>>
>>>> why don't you just put the hosts in different groups depending on the
>>>> options they need. Sounds like you know the specific hosts you need
>>>> to exluded so why not just list them in a group.
>>>
>>> Not sure about the OP, but in the general case it's more likely to be a
>>> case of "all clients whether specified by host statements or not get
>>> option X - except for ..."
>>>
>>> So it makes sense to specify the option in the global scope so it
>>> applies to all dynamic clients, in all subnets & pools, as well as
>>> defined hosts. The problem then is unsetting an option for a small
>>> number of clients - which might not have fixed addresses. So it would be
>>> ideal if the following were possible :
>>>
>>> option X blah ;
>>>
>>> subnet ...
>>> range ...
>>> }
>>>
>>> group ...
>>> unset option X
>>> host ...
>>> hardware ...
>>> host ...
>>> hardware ...
>>> }
>>
>> I haven't tried this myself, but what about setting the value to
>> either a null string, or a null byte? I think there is a difference
>> between an option that is not defined, vs an option with a null value,
>> but it might just work. For example:
>>
>> option X \000;
>>
>> Plug this into Simon's example above and see how you go. The client
>> might just decide that a null value is the same as not set. Or it
>> might not :(
>>
>