Conditional evaluation question.

[Sten Carlsen]

How would it work to make the simple class matching and then use
allow/deny to guide who gets what?

I.e. so that a client matching both classes will be allowed in the
test-environment but not in production and a client only matching the
normal class is denied in the test environment but allowed in the
production.

Can a client match both classes at the same time? What happens if a
client is allowed to both environments? pick the first match.

On 07/04/10 13:39, 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.
>

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100407/4edec698/attachment.html>