Less silly configuration syntax for infinite lease-time marking reservations.

Documentation++. [ISC-Bugs #16166]

diff --git a/server/confpars.c b/server/confpars.c
index 81914ba91aecfb05b6a1c0967805a350b4813e12..f4969f9da2c71a5018bf981cb454892351f13cb0 100644 (file)
--- a/server/confpars.c
+++ b/server/confpars.c
@@ -34,7 +34,7 @@
 
 #ifndef lint
 static char copyright[] =
-"$Id: confpars.c,v 1.155 2006/06/02 17:11:49 dhankins Exp $ Copyright (c) 2004-2006 Internet Systems Consortium.  All rights reserved.\n";
+"$Id: confpars.c,v 1.156 2006/06/15 17:49:49 dhankins Exp $ Copyright (c) 2004-2006 Internet Systems Consortium.  All rights reserved.\n";
 #endif /* not lint */
 
 #include "dhcpd.h"
@@ -3337,8 +3337,7 @@ void parse_address_range (cfile, group, type, inpool, lpchain)
 /* allow-deny-keyword :== BOOTP
                        | BOOTING
                        | DYNAMIC_BOOTP
-                       | UNKNOWN_CLIENTS
-                       | INFINITE IS RESERVED */
+                       | UNKNOWN_CLIENTS */
 
 int parse_allow_deny (oc, cfile, flag)
        struct option_cache **oc;
@@ -3386,21 +3385,6 @@ int parse_allow_deny (oc, cfile, flag)
                code = SV_CLIENT_UPDATES;
                break;
 
-             case INFINITE:
-               token = next_token(&val, NULL, cfile);
-               if (token != IS) {
-                       parse_warn(cfile, "Expecting 'is reserved'.");
-                       return 0;
-               }
-               token = next_token(&val, NULL, cfile);
-               if (token != TOKEN_RESERVED) {
-                       parse_warn(cfile, "Expecting 'reserved'.");
-                       return 0;
-               }
-
-               code = SV_RESERVE_INFINITE;
-               break;
-
              default:
                parse_warn (cfile, "expecting allow/deny key");
                skip_to_semi (cfile);

diff --git a/server/dhcpd.conf.5 b/server/dhcpd.conf.5
index c30cb3596d192cd4baf800ee1d6b8ebfcee74791..4d766724ba1f50d9b12fc6b0ff6250ea157dcbbf 100644 (file)
--- a/server/dhcpd.conf.5
+++ b/server/dhcpd.conf.5
@@ -28,7 +28,7 @@
 .\" see ``http://www.vix.com''.   To learn more about Nominum, Inc., see
 .\" ``http://www.nominum.com''.
 .\"
-.\" $Id: dhcpd.conf.5,v 1.71 2006/05/05 20:32:30 dhankins Exp $
+.\" $Id: dhcpd.conf.5,v 1.72 2006/06/15 17:49:49 dhankins Exp $
 .\"
 .TH dhcpd.conf 5
 .SH NAME
@@ -1952,6 +1952,20 @@ for DHCP clients.
 .RE
 .PP
 The
+.I infinite-is-reserved
+statement
+.RS 0.25i
+.PP
+.B infinite-is-reserved \fIflag\fB;\fR
+.PP
+ISC DHCP now supports 'reserved' leases.  See the section on RESERVED LEASES
+below.  If this \fIflag\fR is on, the server will automatically reserve leases
+allocated to clients which requested an infinite (0xffffffff) lease-time.
+.PP
+The default is off.
+.RE
+.PP
+The
 .I lease-file-name
 statement
 .RS 0.25i
@@ -2424,6 +2438,39 @@ For example:
   ddns-hostname = binary-to-ascii (16, 8, "-",
                                    substring (hardware, 1, 6));
 .fi
+.RE
+.SH RESERVED LEASES
+It's often useful to allocate a single address to a single client, in
+approximate perpetuity.  Host statements with \fBfixed-address\fR clauses
+exist to a certain extent to serve this purpose, but because host statements
+are intended to approximate 'static configuration', they suffer from not being
+referenced in a littany of other Server Services, such as dynamic DNS,
+failover, 'on events' and so forth.
+.PP
+If a standard dynamic lease, as from any range statement, is marked 'reserved',
+then the server will only allocate this lease to the client it is identified
+by (be that by client identifier or hardware address).
+.PP
+In practice, this means that the lease follows the normal state engine, enters
+ACTIVE state when the client is bound to it, expires, or is released, and any
+events or services that would normally be supplied during these events are
+processed normally, as with any other dynamic lease.  The only difference
+is that failover servers treat reserved leases as special when they enter
+the FREE or BACKUP states - each server applies the lease into the state it
+may allocate from - and the leases are not placed on the queue for allocation
+to other clients.  Instead they may only be 'found' by client identity.  The
+result is that the lease is only offered to the returning client.
+.PP
+Care should probably be taken to ensure that the client only has one lease
+within a given subnet that it is identified by.
+.PP
+Leases may be set 'reserved' either through OMAPI, or through the
+'infinite-is-reserved' configuration option (if this is applicable to your
+environment and mixture of clients).
+.PP
+It should also be noted that leases marked 'reserved' are effectively treated
+the same as leases marked 'bootp'.
+.RE
 .SH REFERENCE: OPTION STATEMENTS
 DHCP option statements are documented in the
 .B dhcp-options(5)

diff --git a/server/dhcpd.leases.5 b/server/dhcpd.leases.5
index 52e8dcdc0510c88c2ff453ba6358d641a56f7a80..c62f75710bb12ff522d19aa308f57996351b8809 100644 (file)
--- a/server/dhcpd.leases.5
+++ b/server/dhcpd.leases.5
@@ -28,7 +28,7 @@
 .\" see ``http://www.vix.com''.   To learn more about Nominum, Inc., see
 .\" ``http://www.nominum.com''.
 .\"
-.\" $Id: dhcpd.leases.5,v 1.10 2005/03/17 20:15:28 dhankins Exp $
+.\" $Id: dhcpd.leases.5,v 1.11 2006/06/15 17:49:49 dhankins Exp $
 .\"
 .TH dhcpd.leases 5
 .SH NAME
@@ -226,6 +226,14 @@ The \fBon\fI statement records a list of statements to execute if a
 certain event occurs.   The possible events that can occur for an
 active lease are \fBrelease\fR and \fBexpiry\fR.   More than one event
 can be specified - if so, the events are separated by '|' characters.
+.PP
+.B bootp;
+.B reserved;
+These two statements are effectively flags.  If present, they indicate that
+the BOOTP and RESERVED failover flags, respectively, should be set.  BOOTP
+and RESERVED dynamic leases are treated differently than normal dynamic leases,
+as they may only be used by the client to which they are currently allocated.
+.RE
 .SH THE FAILOVER PEER STATE DECLARATION
 The state of any failover peering arrangements is also recorded in the
 lease file, using the \fBfailover peer\fR statement:

diff --git a/server/stables.c b/server/stables.c
index 88567f690381d83b23756a4a22bcb2e566be18e4..5f83df49791dc1a8514debbc1fc79f8117d4e596 100644 (file)
--- a/server/stables.c
+++ b/server/stables.c
@@ -34,7 +34,7 @@
 
 #ifndef lint
 static char copyright[] =
-"$Id: stables.c,v 1.29 2006/06/01 20:23:18 dhankins Exp $ Copyright (c) 2004 Internet Systems Consortium.  All rights reserved.\n";
+"$Id: stables.c,v 1.30 2006/06/15 17:49:49 dhankins Exp $ Copyright (c) 2004 Internet Systems Consortium.  All rights reserved.\n";
 #endif /* not lint */
 
 #include "dhcpd.h"
@@ -231,6 +231,7 @@ static struct option server_options[] = {
                                                &server_universe,  44, 1 },
        { "do-forward-updates", "f",            &server_universe,  45, 1 },
        { "ping-timeout", "T",                  &server_universe,  46, 1 },
+       { "infinite-is-reserved", "f",          &server_universe,  47, 1 },
        { NULL, NULL, NULL, 0, 0 }
 };