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