From: Ted Lemon <source@isc.org>
Date: Wed, 5 Jan 2000 18:20:30 +0000 (+0000)
Subject: - Fix up the blurb that talks about how scoping works.
X-Git-Tag: V3-BETA-2-PATCH-1~464
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=49f6028f64e981aa19b0d83e4950a79fca9adf9b;p=thirdparty%2Fdhcp.git

- Fix up the blurb that talks about how scoping works.
- Correct erroneous class example.
---

diff --git a/server/dhcpd.conf.5 b/server/dhcpd.conf.5
index ac6e5bd7c..fc40b5aed 100644
--- a/server/dhcpd.conf.5
+++ b/server/dhcpd.conf.5
@@ -78,17 +78,21 @@ clients from other departments on the same subnet.   For clients which
 will be declared explicitly with \fIhost\fR declarations, these
 declarations can be enclosed in a \fIgroup\fR declaration along with
 the parameters which are common to that department.   For clients
-whose addresses will be dynamically assigned, there is currently no
-way to group parameter assignments other than by network topology.
+whose addresses will be dynamically assigned, class declarations and
+conditional declarations may be used to group parameter assignments
+based on information the client sends.
 .PP
 When a client is to be booted, its boot parameters are determined by
-first consulting that client's \fIhost\fR declaration (if any), then
-consulting the \fIgroup\fR declaration (if any) which enclosed that
-\fIhost\fR declaration, then consulting the \fIsubnet\fR declaration
-for the subnet on which the client is booting, then consulting the
-\fIshared-network\fR declaration (if any) containing that subnet, and
-finally consulting the top-level parameters which may be specified
-outside of any declaration.
+consulting that client's \fIhost\fR declaration (if any), and then
+consulting the any \fIclass\fR declarations matching the client,
+followed by the \fIpool\fR, \fIsubnet\fR and \fIshared-network\fR
+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 as well.   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.
 .PP
 When dhcpd tries to find a \fIhost\fR declaration for a client, it
 first looks for a \fIhost\fR declaration which has a
@@ -497,7 +501,6 @@ of this, you can write a class declaration as follows:
 .PP
 .nf
 class "customer" {
-  match if exists agent.circuit-id;
   spawn with option agent.circuit-id;
   lease limit 4;
 }