<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffcc" text="#000000">
How would it work to make the simple class matching and then use
allow/deny to guide who gets what?<br>
<br>
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.<br>
<br>
Can a client match both classes at the same time? What happens if a
client is allowed to both environments? pick the first match.<br>
<br>
On 07/04/10 13:39, Glenn Satchell wrote:
<blockquote cite="mid:4BBC6EE7.6080801@uniq.com.au" type="cite">On
04/07/10 19:00, Stewart Walters wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
I'm trying to work out what's the best way to configure dhcpd using
some
<br>
form of evaluation to send different vendor encapsulated options to our
<br>
Sunray thin clients.
<br>
<br>
We currently have a server which provides a Production Sunray desktop
<br>
environment to our userbase.
<br>
<br>
If it helps - here is an example of how to set up dhcpd for passing a
<br>
single Sunray environment to 100% of Sunray clients
<br>
(<a class="moz-txt-link-freetext" href="http://blogs.sun.com/lewiz/entry/configuring_sun_ray_dhcp">http://blogs.sun.com/lewiz/entry/configuring_sun_ray_dhcp</a>)
<br>
<br>
As shown in that example, 100% of Sunray clients can be evaluated via
<br>
the vendor-class-identifier = "SUNW.NewT.SUNW"; statement.
<br>
</blockquote>
<br>
I did something similar many years ago with ISC dhcpd on Solaris.
<br>
<br>
<blockquote type="cite">But I want to create a Test Sunray desktop
evironment and move 10% of
<br>
our users (determined by MAC address) to a different Testing
<br>
environment. If the conditional evaluation doesn't qualify in the 10%,
I
<br>
want the remaining 90% of our Sunray clients to receive the Production
<br>
environment options.
<br>
<br>
I've been reading through dhcp-options(5), dhcpd.conf(5) and
<br>
dhcp-eval(5), as well as several online posts relating to this.
<br>
<br>
But I'm a little perplexed about what the best approach for this kind
of
<br>
setup would be.
<br>
<br>
Would it be better to go, for example:
<br>
<br>
--- snip ---
<br>
class "TestingSunray" {
<br>
match <some match criteria here>
<br>
<insert Testing vendor encapsulated options here>
<br>
}
<br>
<br>
subclass "TestingSunray" 1:xx:xx:xx:xx:xx:xx;
<br>
subclass "TestingSunray" 1:yy:yy:yy:yy:yy:yy;
<br>
subclass "TestingSunray" 1:zz:zz:zz:zz:zz:zz;
<br>
</blockquote>
<br>
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:
<br>
<br>
class "TestingSunray" {
<br>
match hardware;
<br>
option space ...
<br>
option ...
<br>
}
<br>
<br>
Then in the subclass you use the hardware address. This needs a leading
1 which represents ethernet.
<br>
<br>
subclass "TestingSunray" 1:xx:xx:xx:xx:xx:xx;
<br>
<br>
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.
<br>
<br>
<blockquote type="cite">class "ProductionSunray" {
<br>
match if vendor-class-identifier = "SUNW.NewT.SUNW";
<br>
<insert Production vendor encapsulated options here>
<br>
}
<br>
</blockquote>
<br>
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.
<br>
<br>
<blockquote type="cite">--- snip ---
<br>
<br>
Does dhcpd even process class matching in the order in which it's
listed
<br>
in dhcpd.conf? Am I guaranteed in that configuration that a Test Sunray
<br>
wont be classified as Production just because the Testing class is
<br>
defined first?
<br>
</blockquote>
<br>
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.
<br>
<br>
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:
<br>
<br>
When a client is to be booted, its boot parameters are
<br>
determined by consulting that client's host declaration (if
<br>
any), and then consulting any class declarations matching
<br>
the client, followed by the pool, subnet and shared-network
<br>
declarations for the IP address assigned to the client.
<br>
Each of these declarations itself appears within a lexical
<br>
scope, and all declarations at less specific lexical scopes
<br>
are also consulted for client option declarations. Scopes
<br>
are never considered twice, and if parameters are declared
<br>
in more than one scope, the parameter declared in the most
<br>
specific scope is the one that is used.
<br>
<br>
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.
<br>
<br>
# testing sunrays
<br>
group {
<br>
option ...
<br>
host "host1" { hardware ethernet xx:xx:xx:xx:xx:xx; }
<br>
host "host2" { hardware ethernet xx:xx:xx:xx:xx:xx; }
<br>
}
<br>
<br>
<blockquote type="cite">Or is it better to do this?
<br>
<br>
--- snip ---
<br>
class "Sunray" {
<br>
match if substring(hardware,1,3)=xx:xx:xx:xx:xx:xx or
<br>
elsif substring(hardware,1,3)=yy:yy:yy:yy:yy:yy or
<br>
elsif substring(hardware,1,3)=zz:zz:zz:zz:zz:zz;
<br>
<insert Testing vendor encapsulated options here>
<br>
else
<br>
match if option vendor-class-identifier = "SUNW.NewT.SUNW";
<br>
<insert Production vendor encapsulated options here>
<br>
}
<br>
--- snip ---
<br>
(I probably made a bunch of minor syntax errors above, but I can work
<br>
those out later)
<br>
</blockquote>
<br>
That doesn't scale very well and the logic is not quite right.
<br>
<br>
class "Sunray" {
<br>
match if option vendor-class-identifier = "SUNW.NewT.SUNW";
<br>
# default options for all
<br>
option ...
<br>
<br>
# option for testing sunrays
<br>
if hardware = xx:xx:xx:xx:xx:xx
<br>
or substring(hardware,1,3) = yy:yy:yy
<br>
or ... {
<br>
option ...
<br>
}
<br>
}
<br>
<br>
<blockquote type="cite">Or should I be doing some complicated if and
else statements as shown in
<br>
the example at
<br>
<a class="moz-txt-link-freetext" href="http://www.linuxforums.org/forum/servers/69851-dhcpd-conf-multiple-subnet-single-physical-network-configuration.html">http://www.linuxforums.org/forum/servers/69851-dhcpd-conf-multiple-subnet-single-physical-network-configuration.html</a>
<br>
</blockquote>
<br>
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.
<br>
<br>
<blockquote type="cite">As you can see, I'm not exactly sure to which
way might be best for me.
<br>
Let me say thanks in advance for any assistance you can provide on the
<br>
matter.
<br>
</blockquote>
<br>
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.
<br>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
</pre>
</body>
</html>