Trouble Again with "set statements =" in Dynamic Groups

[Martin McCormick]

Randall C Grimshaw writes:
> My approach is to use class definitions - so using your data it would 
> look like this:
> 
> class "PXECLIENT" {
>   match concat(pick-first-value(option 
> vendor-class-identifier,"no-identifier"),"=",binary-to-ascii(10, 8, "-", 
> option dhcp-parameter-request-list));
> }
> subclass "PXECLIENT" "PXEClient=1-3-6-12-15-60-66-67" {
>     next-server = "192.168.9.7";
>     filename = "x1970.0";
> }
> 
> you can aim these devices at specific pools with logic such as:
> allow members of "PXECLIENT";

	Thank you. This is a good fallback approach which I
hadn't thought of.

	The syntax worked so many thanks.

	I actually solved the original problem which is what I
call vintage omshell fun.

	I discovered, by taking various components out of the
group declaration, that it was the next-server statement that
was putting out the campfire every time. I could move the
statement around and get more or less of the group entered until
the next-server statement. At that point, omshell would act as
if all was well but the DHCP server went deaf to anything else.

	When I removed the double quotes around the string
containing the IP address of the server, the birds started
singing. The Sun came out and the DHCP server took every
statement.

	The fastest way to determine whether or not the group
actually was entered as hoped is to go to the dhcp server and
read dhcpd.leases. Go to the end of the file and look back for
your group. It will be in a format that dhcpd understands best
such as all the IP addresses being in hex and lines of text
looking rather bizarre, but one can tell if all the statements
that should be there truly are there.