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

[Steve Rikli]

On Thu, Nov 07, 2013 at 04:39:18PM +0100, Sten Carlsen wrote:
> 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?

Could be; I've tried a couple permutations so far without much success,
and between your ideas and Glenn's, I've at least got some promising
ideas again.

Thanks,
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?
> >>>>>>>