Converting from Solaris's DHCPd?

[David W. Hankins]

On Sun, Sep 12, 2010 at 10:56:24AM -0400, Kyle McDonald wrote:
...

My inclination is to identify the "root macros" and define them as
classes, using whatever match or subclass match criteria you define
(probably using subclasses to match individual clients), and then to
build the hierarchy above the "root macros" as nested groups (people
often don't understand that 'group' statements are literally explicit
groupings around any arbitrary configuration language statement in
the config file: the config file is a tree that is walked from the
leaf node to the root), so this:

> INST_Solaris_s10u8_X64_b
>   {
>     GrubMenu   /tftp/Solaris_S10u8_X64_b  # This menu uses port B kernel
> console
>     include INST_Solaris_s10u8_X64        # note no _b
>   }
> 
> INST_Solaris_s10u8_X64
>   {
>     ...Sun Options specific to s10u8 for X64
>     include INST_Solaris_s10u8            # note no _X64
>   }
> 
> INST_Solaris_s10u8
>   {
>     ...Sun Options specific to s10u8 for all Archs.
>     include INST_Solaris_s10              # note no u8
>   }
> 
> INST_Solaris_s10
>   {
>     ...Sun Options specific to s10 for all updates... None of these at
> the moment.
>     include INST_Solaris_Common
>   }
> 
> INST_Solaris_Common
>   {
>     ...Sun Options common to all Solaris installs
>     include INST_Common
>   }
> 
> INST_Common
>   {
>     ... PXE and other options common to all installs
>   }

Becomes;

# Global configuration for all nodes.

group "Solaris" {
    # All solaris options.

    group "Solaris 10" {
	# Options for all 10.

	group "Solaris 10u8" {
	    # options for all 10u8.

	    group "Solaris 10u8_x64" {
		# Options for all 10u8_x64.

		class "Solaris 10u8_x64_b" {
		    match on hardware;

		    # Options for 10u8_x64_b specific.
		}

		class "Solaris 10u8_x64_b" 01:11:22:33:44:55:66;
		class "Solaris 10u8_x64_b" 01:77:88:99:aa:bb:cc {
		    # Client-specific configuration options if required.
		}
	    }
	}
    }
}

More specific configuration options (options closer to the class
statements which are the leaves of the tree) take precedence over
less specific groups (closer to the global, root group).

Host records can be maintained separately from the subclasses above
for fixed-address allocations.

The only real downside is that classes are searched linearly (one
check on the subclass hash table for each class searched), whereas
host records are in one hash lookup together.  But you probably
don't have so much DHCP traffic you care.

NOTE: Subclasses do not follow group semantics.  They artificially
inherit the parent class' group, and thus the parent' class' position
in the group inheritance tree.  For this reason, to reduce confusion
of the readers of the config file, you should include the subclass
statements in the same group as the parent class.

> In ISC DHCP, can whole config files be included at any level? I mean can
> I do this:
> 
> host foo {
>   hardware ethernet xx:xx:xx:xx:xx:xx;
>   fixed-address 192.168.x.y;
>   include /some/dir/Linux/RHEL5/u3/X64-a
> }

No.  In fact, the include command is fairly annoying in that it is
not implemented in the lexer, it is implemented in the parser...a
new configuration parse session is started (from the root group),
instead of simply inserting lexical streams to the current position
in the file.

I agree that would be more useful.  It isn't how it works currently
unfortunately.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100922/236cbdcd/attachment.bin>