how to set class attributes for a host or group instead of a pool?

[Sten Carlsen]

You may want to consider using a construct with subclasses. I do that
for a slightly different purpose.

I want to be able to switch each of my hosts between gateways, so I have
3 classes, each with its own gateway and a long list of hosts connecting
each MAC to a specific class. Using this concept, I should think you
might use something like:

class "pxe" {
match hardware;
next-server <tftp server>;
filename "pxelinux.0";
}

class "norm" {
match hardware;
}

subnet xx{
...
}

subclass "pxe2 1:00:01:02:03:04:05;
subclass "norm" 1:00:01:02:03:12:32;


I place the subclass declarations in a file that is included, all you
would have to do to change from pxe boot to normal boot is to change the
name of the subclass from "pxe" to "norm" and restart dhcpd.



On 07/11/13 14:42, Steve Rikli wrote:
> Sure, we could just define the global class and let it apply to the
> known hosts/groups we already define, but without being able to
> selectively turn it off in the config (what I was hoping for with
> allow/deny functions) then we'd have to change the hosts' BIOS every
> time to enable/disable PXE.  We're hoping to avoid that and instead
> control whether or not to PXE boot via DHCP.
> 
> I was guessing we'd end up with something like your 2nd idea, which is
> workable.  It's still a bit more repeating of multiple if-then etc.
> statements in each group than we would prefer, and we'll need to
> (un)comment those blocks of code (instead of 1 allow/deny line) to flip
> the on/off switch for PXE booting, but it's better than the alternative.
> 
> Definitely worth trying in any case -- since we have no other solution
> at the moment.  :-)
> 
> Thanks,
> sr.
> 
> 
> the global class today and let it naturally apply 
> On Thu, Nov 07, 2013 at 05:25:40PM +1100, Glenn Satchell wrote:
>> Your example below will work fine (as long as the syntax is ok). A
>> fixed-address host can still be a member of a class and obtain all the
>> class attributes.
>>
>> The allow/deny bit does not allow or deny the attributes of the class,
>> rather it allows or denies access to a pool based on membership of the
>> class.
>>
>> So, in your case *if* the host is booted as PXE it will have the
>> vendor-class-identifier set to PXEClient and so be a member of the
>> pxeclients class, and therefore have those class attributes (next-server,
>> etc) added to it. It gets its IP address in the same fixed-address way as
>> normal and everything should be fine.
>>
>> If it is booted normally, then it doesn't have the vendor-class-identifier
>> set to PXEClient and so it won't be a member of that class and won't have
>> those attributes (next-server, etc) set.
>>
>> If the above doesn't work for you, then put a group {} statement around
>> the host statements and add something like this in the group. You can make
>> the if statement as complex as you need to.
>>
>> group {
>> if substring(option vendor-class-identifier, 0, 9) = "PXEClient" {
>>       next-server <tftp server>;
>>       filename "pxelinux.0";
>> }
>> host ... { ... }
>> host ... { ... }
>> }
>>
>> regards,
>> -glenn
>>
>> On Thu, November 7, 2013 2:54 am, Steve Rikli wrote:
>>> Our DHCP is composed of groups of known hosts in multiple subnets,
>>> with fixed-address assignments based on hardware ethernet addresses.
>>>
>>> I'd like to use functionality similar to this typical example:
>>>
>>>   class "pxeclients" {
>>>      match if substring(option vendor-class-identifier, 0, 9) =
>>> "PXEClient";
>>>      next-server <tftp server>;
>>>      filename "pxelinux.0";
>>>   }
>>>
>>> with allow/deny as needed; but it seems that global class can only be
>>> applied to pools with ranges, rather than a host or group of hosts.
>>>
>>> So today to enable pxebooting we usually add next-server & filename to a
>>> host{} (e.g. for a re-install situation) or to a group{} (e.g. when
>>> bringing up a new subnet or installing a new batch of clients, etc.).
>>> This works well enough, but gets cumbersome.
>>>
>>> Recently, we've added a new batch of hosts with UEFI as well as a legacy
>>> BIOS mode, so we're likely to need something more complex, e.g.:
>>>
>>>   match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
>>>      next-server <tftp server>;
>>>      if option arch = 00:06 {
>>>        filename "bootia32.efi";
>>>        }
>>>      else if option arch = 00:07 {
>>>        filename "bootx64.efi";
>>>        }
>>>      else {
>>>        filename "pxelinux.0";
>>>      }
>>>
>>> which seems unwieldy to replicate in groups and individual hosts.
>>>
>>> Is there a more elegant way to define a global "class"-like function,
>>> potentially with multiple matches and if-then conditions, yet still be
>>> able to selectively enable/disable it for given groups and individual
>>> hosts, without replicating the whole block of code everywhere?
>>>
>>> Cheers,
>>> sr.
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
> 

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"