1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
|
.\" dhcpd.leases.5
.\"
.\" Copyright (c) 1997, 1998 The Internet Software Consortium.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\"
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. Neither the name of The Internet Software Consortium nor the names
.\" of its contributors may be used to endorse or promote products derived
.\" from this software without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE INTERNET SOFTWARE CONSORTIUM AND
.\" CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
.\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
.\" DISCLAIMED. IN NO EVENT SHALL THE INTERNET SOFTWARE CONSORTIUM OR
.\" CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
.\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
.\" LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
.\" USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
.\" ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
.\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
.\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" This software has been written for the Internet Software Consortium
.\" by Ted Lemon <mellon@fugue.com> in cooperation with Vixie
.\" Enterprises. To learn more about the Internet Software Consortium,
.\" see ``http://www.isc.org/isc''. To learn more about Vixie
.\" Enterprises, see ``http://www.vix.com''.
.TH dhcpd.leases 5
.SH NAME
dhcpd.leases - DHCP client lease database
.SH DESCRIPTION
The Internet Software Consortium DHCP Server keeps a persistent
database of leases that it has assigned. This database is a free-form
ASCII file containing a series of lease declarations. Every time a
lease is acquired, renewed or released, its new value is recorded at
the end of the lease file. So if more than one declaration appears
for a given lease, the last one in the file is the current one.
.PP
When dhcpd is first installed, there is no lease database. However,
dhcpd requires that a lease database be present before it will start.
To make the initial lease database, just create an empty file called
DBDIR/dhcpd.leases.
.PP
In order to prevent the lease database from growing without bound, the
file is rewritten from time to time. First, a temporary lease
database is created and all known leases are dumped to it. Then, the
old lease database is renamed DBDIR/dhcpd.leases~. Finally, the
newly written lease database is moved into place.
.PP
There is a window of vulnerability where if the dhcpd process is
killed or the system crashes after the old lease database has been
renamed but before the new one has been moved into place, there will
be no DBDIR/dhcpd.leases. In this case, dhcpd will refuse to start,
and will require manual intervention. \fBDO NOT\fR simply create a
new lease file when this happens - if you do, you will lose all your
old bindings, and chaos will ensue. Instead, rename
DBDIR/dhcpd.leases~ to DBDIR/dhcpd.leases, restoring the old, valid
lease file, and then start dhcpd. This guarantees that a valid lease
file will be restored.
.SH FORMAT
Lease descriptions are stored in a format that is parsed by the same
recursive descent parser used to read the
.B dhcpd.conf(5)
and
.B dhclient.conf(5)
files. Currently, the only declaration that is
used in the dhcpd.leases file is the
.B lease
declaration.
.PP
\fBlease \fIip-address\fB { \fIstatements...\fB }
.PP
Each lease declaration include the single IP address that has been
leased to the client. The statements within the braces define the
duration of the lease and to whom it is assigned.
.PP
The start and end time of a lease are recorded using the ``starts''
and ``ends'' statements:
.PP
\fB starts \fIdate\fB;\fR
\fB ends \fIdate\fB;\fR
.PP
Dates are specified as follows:
.PP
\fIweekday year\fB/\fImonth\fB/\fIday
hour\fB:\fIminute\fB:\fIsecond\fR
.PP
The weekday is present to make it easy for a human to tell when a
lease expires - it's specified as a number from zero to six, with zero
being Sunday. The day of week is ignored on input. The year is
specified with the century, so it should generally be four digits
except for really long leases. The month is specified as a number
starting with 1 for January. The day of the month is likewise
specified starting with 1. The hour is a number between 0 and 23, the
minute a number between 0 and 59, and the second also a number between
0 and 59.
.PP
Lease times are specified in Greenwich Mean Time (GMT), not in the
local time zone. Since Greenwich is actually on Daylight Savings
Time part of the year, there is probably nowhere in the world where
the times recorded on a lease are always the same as wall clock times.
On a unix machine, one can often figure out the current time in GMT by
typing \fBdate -u\fR.
.PP
The MAC address of the network interface that was used to acquire the
lease is recorded with the \fBhardware\fR statement:
.PP
\fBhardware \fIhardware-type mac-address\fB;\fR
.PP
The MAC address is specified as a series of hexadecimal octets,
separated by colons.
.PP
If the client used a client identifier to acquire its address, the
client identifier is recorded using the \fBuid\fR statement:
.PP
\fBuid \fIclient-identifier\fB;\fR
.PP
The client identifier is recorded as a series of hexadecimal octets,
regardless of whether the client specifies an ASCII string or uses the
newer hardware type/MAC address format.
.PP
If the client sends a hostname using the \fIClient Hostname\fR option,
as specified in some versions of the DHCP-DNS Interaction draft, that
hostname is recorded using the \fBclient-hostname\fR statement.
.PP
\fBclient-hostname "\fIhostname\fB";\fR
.PP
If the client sends its hostname using the \fIHostname\fR option, as
Windows 95 does, it is recorded using the \fBhostname\fR statement.
.PP
\fBhostname "\fIhostname\fB";\fR
.PP
The DHCP server may determine that a lease has been misused in some
way, either because a client that has been assigned a lease NAKs it,
or because the server's own attempt to see if an address is in use
prior to reusing it reveals that the address is in fact already in
use. In that case, the \fBabandoned\fR statement will be used to
indicate that the lease should not be reassigned.
.PP
\fBabandoned;\fR
.PP
Abandoned leases are reclaimed automatically. When a client asks for
a new address, and the server finds that there are no new addresses,
it checks to see if there are any abandoned leases, and allocates the
least recently abandoned lease. The standard mechanisms for checking
for lease address conflicts are still followed, so if the abandoned
lease's IP address is still in use, it will be reabandoned.
.PP
If a client \fBrequests\fR an abandoned address, the server assumes
that the reason the address was abandoned was that the lease file was
corrupted, and that the client is the machine that responded when the
lease was probed, causing it to be abandoned. In that case, the
address is immediately assigned to the client.
.SH FILES
.B DBDIR/dhcpd.leases
.SH SEE ALSO
dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132, RFC2131.
.SH AUTHOR
.B dhcpd(8)
was written by Ted Lemon <mellon@vix.com>
under a contract with Vixie Labs. Funding
for this project was provided by the Internet Software Corporation.
Information about the Internet Software Consortium can be found at
.B http://www.isc.org/isc.
|
