Override class configuration in subnet

[Patrik Lundin]

Hello,

I have been struggling with a problem where I would like to override an option
set by a class by configuring it in a subnet scope. This of course goes
against the standard ordering where class configuration wins over subnet
configuration.

The class in question is used by Mac clients (BSDP) and looks like this:

 class "AppleNBI-i386" {
        # BSDP clients identifies themselves by setting a string like
        # "AAPLBSDPC/i386/iMac11,2" in the vendor-class-identifier field.
        match if substring (option vendor-class-identifier, 0, 9) = "AAPLBSDPC";

        # It appears "root-path" is not in the client parameter request list
        # (option 55) so we need to set the returned options specifically.
        # Make sure we send options needed by BSDP:
        # root-path (17)
        # vendor-encapsulated-options (43)
        # vendor-class-identifier (60)
        #
        # There are some additional options needed by older clients:
        # subnet mask (1)
        # router (3)
        option dhcp-parameter-request-list 1,3,17,43,60;

        if (option dhcp-message-type = 1) {
          # Older mac clients set the vendor-class-identifier in the initial
          # DHCPDISCOVER (type 1) message, in this case we need to identify ourselves
          # as a BSDP server in the DHCPOFFER:
          option vendor-class-identifier "AAPLBSDPC";
        } elsif (option dhcp-message-type = 8) {
          # BSDP sends DHCPINFORM messages (type 8) and expects the server to
          # respond with DHCPACK contaning the requested information.
          option vendor-class-identifier "AAPLBSDPC";
          option vendor-encapsulated-options
            01:01:02:               # bsdp_msgtype_select
            08:04:81:00:00:01;      # bsdptag_selected_boot_image
        }
        filename "/netboot/i386_macnbi/booter";
        option root-path "http://XX.XX.XX.XX/path/to/NetInstall.dmg";
}

The problem is that a specific subnet needs a different "root-path" option.

I have been browsing the archive of this list for similar discussions and have
found at least two threads, the first one being:
https://lists.isc.org/pipermail/dhcp-users/2007-April/003415.html

That thread uses name spaces which is different from my situation, so I do not
think it helps me solve my problem.

Looking a bit more I found another thread which looked promising at first:
https://lists.isc.org/pipermail/dhcp-users/2009-January/007754.html

I am having problems grasping the solution described though, specifically the
following:

===
You can also use an executable statement scoped inside the subnet;
this is approximately equivalent in workload for the server to using
a class match (because this statement is scoped inside the subnet,
it alone is found to execute when processing a reply).

  if (substring(option vendor-class-identifier, 0, 3) = "PXE") {
    next-server foo;
  }
===

This made me believe i could pretty much take the configuration seen above,
remove the class-stuff and add the resulting configuration inside the subnet
configuration (because the if-statement would somehow make dhcpd ignore
the class).

The resulting lines placed in the subnet scope looked like this (everything is
the same, except the first line, the lack of comments and the root-path
destination):

if (substring (option vendor-class-identifier, 0, 9) = "AAPLBSDPC") {
    option dhcp-parameter-request-list 1,3,17,43,60;
    if (option dhcp-message-type = 1) {
        option vendor-class-identifier "AAPLBSDPC";
    } elsif (option dhcp-message-type = 8) {
        option vendor-class-identifier "AAPLBSDPC";
        option vendor-encapsulated-options
        01:01:02:               # bsdp_msgtype_select
        08:04:81:00:00:01;      # bsdptag_selected_boot_image
    }
        filename "/netboot/i386_macnbi/booter";
        option root-path "http://YY.YY.YY.YY/path/to/NetInstall.dmg";
}

While the subnet configuration loaded successfully, the root-path option was
unchanged in the packets being sent. I currently believe I have misinterpreted
the suggestion above. It probably means that I should remove the class and then
add those lines to all subnet declarations.

Is this my only option? The main problem is that I have quite a few subnets,
and replacing the class with configuration in all of them is kind of
cumbersome. I am just trying to verify I am not missing something obvious.

Thankful for any input I can get!

Regards,
Patrik Lundin