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

Steve Rikli sr at genyosha.net
Thu Nov 7 13:42:40 UTC 2013


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.


More information about the dhcp-users mailing list