Conditional evaluation question.

Glenn Satchell glenn.satchell at uniq.com.au
Wed Apr 7 11:39:19 UTC 2010 

On 04/07/10 19:00, Stewart Walters wrote:
> Hi,
>
> I'm trying to work out what's the best way to configure dhcpd using some
> form of evaluation to send different vendor encapsulated options to our
> Sunray thin clients.
>
> We currently have a server which provides a Production Sunray desktop
> environment to our userbase.
>
> If it helps - here is an example of how to set up dhcpd for passing a
> single Sunray environment to 100% of Sunray clients
> (http://blogs.sun.com/lewiz/entry/configuring_sun_ray_dhcp)
>
> As shown in that example, 100% of Sunray clients can be evaluated via
> the vendor-class-identifier = "SUNW.NewT.SUNW"; statement.

I did something similar many years ago with ISC dhcpd on Solaris.

> But I want to create a Test Sunray desktop evironment and move 10% of
> our users (determined by MAC address) to a different Testing
> environment. If the conditional evaluation doesn't qualify in the 10%, I
> want the remaining 90% of our Sunray clients to receive the Production
> environment options.
>
> I've been reading through dhcp-options(5), dhcpd.conf(5) and
> dhcp-eval(5), as well as several online posts relating to this.
>
> But I'm a little perplexed about what the best approach for this kind of
> setup would be.
>
> Would it be better to go, for example:
>
> --- snip ---
> class "TestingSunray" {
> match <some match criteria here>
> <insert Testing vendor encapsulated options here>
> }
>
> subclass "TestingSunray" 1:xx:xx:xx:xx:xx:xx;
> subclass "TestingSunray" 1:yy:yy:yy:yy:yy:yy;
> subclass "TestingSunray" 1:zz:zz:zz:zz:zz:zz;

The syntax for whatever is in the match line of the class is what goes 
in the match portion of the subclass. So in the class if you said:

class "TestingSunray" {
	match hardware;
	option space ...
	option ...
}

Then in the subclass you use the hardware address. This needs a leading 
1 which represents ethernet.

subclass "TestingSunray" 1:xx:xx:xx:xx:xx:xx;

The sub-class uses a fast hashing algorithm to determine membership, so 
it's efficient even where there are lots of clients. See dhcpd.conf 
SUBCLASSES section.

> class "ProductionSunray" {
> match if vendor-class-identifier = "SUNW.NewT.SUNW";
> <insert Production vendor encapsulated options here>
> }

If you are going to be filling in the option space in different places, 
then you should put the option space definitions in the global scope, 
and assign the values in the classes or groups.

> --- snip ---
>
> Does dhcpd even process class matching in the order in which it's listed
> in dhcpd.conf? Am I guaranteed in that configuration that a Test Sunray
> wont be classified as Production just because the Testing class is
> defined first?

What happens here is that some clients will be in *both* classes. It's 
not about only matching the first class you come across. Unfortunately 
things are not clear about which class definition is the most specific, 
ie which one "wins" when both define the same options. If this point can 
be clearly defined then the subclass solution is the definite winner.

Now for some other ways to clearly use the most specific group. Consider 
this paragraph from the dhcpd.conf man page, which specifies the scoping 
order:

      When a client is to  be  booted,  its  boot  parameters  are
      determined  by consulting that client's host declaration (if
      any), and then consulting any  class  declarations  matching
      the  client, followed by the pool, subnet and shared-network
      declarations for the IP  address  assigned  to  the  client.
      Each  of  these declarations itself appears within a lexical
      scope, and all declarations at less specific lexical  scopes
      are  also consulted for client option declarations.   Scopes
      are never considered twice, and if parameters  are  declared
      in  more  than one scope, the parameter declared in the most
      specific scope is the one that is used.

We could use a group and host statements to make sure we are more 
specific than a class. For example this group, and the ProductionSunrays 
class above. You only need to put in the options that are different for 
testing, as these clients are still members of ProductionSunrays and 
will pick up other options from there.

# testing sunrays
group {
	option ...
	host "host1" { hardware ethernet xx:xx:xx:xx:xx:xx; }
	host "host2" { hardware ethernet xx:xx:xx:xx:xx:xx; }
}

> Or is it better to do this?
>
> --- snip ---
> class "Sunray" {
> match if substring(hardware,1,3)=xx:xx:xx:xx:xx:xx or
> elsif substring(hardware,1,3)=yy:yy:yy:yy:yy:yy or
> elsif substring(hardware,1,3)=zz:zz:zz:zz:zz:zz;
> <insert Testing vendor encapsulated options here>
> else
> match if option vendor-class-identifier = "SUNW.NewT.SUNW";
> <insert Production vendor encapsulated options here>
> }
> --- snip ---
> (I probably made a bunch of minor syntax errors above, but I can work
> those out later)

That doesn't scale very well and the logic is not quite right.

class "Sunray" {
	match if option vendor-class-identifier = "SUNW.NewT.SUNW";
	# default options for all
	option ...

	# option for testing sunrays
	if hardware = xx:xx:xx:xx:xx:xx
	or substring(hardware,1,3) = yy:yy:yy
	or ... {
		option ...
	}
}

> Or should I be doing some complicated if and else statements as shown in
> the example at
> http://www.linuxforums.org/forum/servers/69851-dhcpd-conf-multiple-subnet-single-physical-network-configuration.html

Having just looked at that page I would *not* recommend using those 
methods at all. That guy is deliberately trying to make things as 
difficult and complicated as possible. Difficult and complicated means 
hard to understand, hard to get working and hard to fix if things aren't 
quite right.

> As you can see, I'm not exactly sure to which way might be best for me.
> Let me say thanks in advance for any assistance you can provide on the
> matter.

Ah, it is a very interesting question, but the solution comes down to 
being able to define the subset of clients that are going to get 
different options. That's all.

-- 
regards,
-glenn
--
Glenn Satchell                            |  Miss 9: What do you
Uniq Advances Pty Ltd, Sydney Australia   |  do at work Dad?
mailto:glenn.satchell at uniq.com.au         |  Miss 6: He just
http://www.uniq.com.au tel:0409-458-580   |  types random stuff.

More information about the dhcp-users mailing list