Conditional evaluation question.

Stewart Walters stw at bgc.com.au
Thu Apr 8 00:37:34 UTC 2010


Hi Glenn, Mailinglist,

Thanks for the reply.

Do you know at all if it's possible to do multiple match statements?

e.g.

class "TestingSunray" {
match vendor-class-identifier = "SUNW.NewT.SUNW" and hardware;
option space...
option...
}

Or even like this?

class "ProductionSunray {
if not match class "TestingSunray" and match vendor-class-identifier = 
"SUNW.NewT.SUNW";
option space...
option...
}

I'm just spitballing ideas here, not really sure if dhcpd is capable in 
this regard.

Regards,

Stewart



Glenn Satchell wrote:
> 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.
>



More information about the dhcp-users mailing list