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

Thu Nov 7 14:14:39 UTC 2013

Interesting.  If I follow your method, every host{} definition also has
a corresponding subclass?  Maybe I'm not understanding properly how
subclasses are applied.

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!!!"
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users