155 lines
6.6 KiB
Groff
155 lines
6.6 KiB
Groff
.\" dhcpd.leases.5
|
|
.\"
|
|
.\" Copyright (c) 1996-1999 Internet Software Consortium.
|
|
.\" Use is subject to license terms which appear in the file named
|
|
.\" ISC-LICENSE that should have accompanied this file when you
|
|
.\" received it. If a file named ISC-LICENSE did not accompany this
|
|
.\" file, or you are not sure the one you have is correct, you may
|
|
.\" obtain an applicable copy of the license at:
|
|
.\"
|
|
.\" http://www.isc.org/isc-license-1.0.html.
|
|
.\"
|
|
.\" This file is part of the ISC DHCP distribution. The documentation
|
|
.\" associated with this file is listed in the file DOCUMENTATION,
|
|
.\" included in the top-level directory of this release.
|
|
.\"
|
|
.\" Support and other services are available for ISC products - see
|
|
.\" http://www.isc.org for more information.
|
|
.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
|
|
/var/db/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 /var/db/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 /var/db/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
|
|
/var/db/dhcpd.leases~ to /var/db/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,
|
|
seperated 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 /var/db/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.
|