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

Sten Carlsen stenc at s-carlsen.dk
Thu Nov 7 15:39:18 UTC 2013



On 07/11/13 16.28, Steve Rikli wrote:
> On Thu, Nov 07, 2013 at 04:08:35PM +0100, Sten Carlsen wrote:
>>
>>
>> On 07/11/13 15:14, Steve Rikli wrote:
>>> Interesting.  If I follow your method, every host{} definition also has
>>> a corresponding subclass?  Maybe I'm not understanding properly how
>>> subclasses are applied.
>>
>> The subclass goes instead of the host.
> 
> Ah; so then how do you apply fixed-address and other host-specific
> parameters?
In my use I don't, and it is not accepted in the subclass statement, so
maybe you need a host statement with the fixed-address and the
subclass/class for the other parameters?

I have not tried, might be worth a try?

> 
> Cheers,
> sr.
> 
> 
>>> On Thu, Nov 07, 2013 at 02:57:52PM +0100, Sten Carlsen wrote:
>>>> 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!!!"


More information about the dhcp-users mailing list