how to set class attributes for a host or group instead of a pool?
Glenn Satchell
glenn.satchell at uniq.com.au
Thu Nov 7 06:25:40 UTC 2013
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
>
More information about the dhcp-users
mailing list