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

[Steve Rikli]

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?

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.