dhclient.conf.5

DHCP服务器源码

.\"	$Id: dhclient.conf.5,v 1.12.2.10 2004/06/10 17:59:13 dhankins Exp $
.\"
.\" Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (c) 1996-2003 by Internet Software Consortium
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR
.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
.\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\"
.\"   Internet Systems Consortium, Inc.
.\"   950 Charter Street
.\"   Redwood City, CA 94063
.\"   <[e-mail]>
.\"   http://www.isc.org/
.\"
.\" This software has been written for Internet Software Consortium
.\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc.
.\" To learn more about Internet Software Consortium, see
.\" ``http://www.isc.org/''.  To learn more about Vixie Enterprises,
.\" see ``http://www.vix.com''.   To learn more about Nominum, Inc., see
.\" ``http://www.nominum.com''.
.TH dhclient.conf 5
.SH NAME
dhclient.conf - DHCP client configuration file
.SH DESCRIPTION
The dhclient.conf file contains configuration information for
.IR dhclient,
the Internet Systems Consortium DHCP Client.
.PP
The dhclient.conf file is a free-form ASCII text file.   It is parsed by
the recursive-descent parser built into dhclient.   The file may contain
extra tabs and newlines for formatting purposes.  Keywords in the file
are case-insensitive.   Comments may be placed anywhere within the
file (except within quotes).   Comments begin with the # character and
end at the end of the line.
.PP
The dhclient.conf file can be used to configure the behaviour of the
client in a wide variety of ways: protocol timing, information
requested from the server, information required of the server,
defaults to use if the server does not provide certain information,
values with which to override information provided by the server, or
values to prepend or append to information provided by the server.
The configuration file can also be preinitialized with addresses to
use on networks that don't have DHCP servers.
.SH PROTOCOL TIMING
The timing behaviour of the client need not be configured by the user.
If no timing configuration is provided by the user, a fairly
reasonable timing behaviour will be used by default - one which
results in fairly timely updates without placing an inordinate load on
the server.
.PP
The following statements can be used to adjust the timing behaviour of
the DHCP client if required, however:
.PP
.I The
.B timeout
.I statement
.PP
.B timeout
.I time
.B ;
.PP
The
.I timeout
statement determines the amount of time that must pass between the
time that the client begins to try to determine its address and the
time that it decides that it's not going to be able to contact a
server.   By default, this timeout is sixty seconds.   After the
timeout has passed, if there are any static leases defined in the
configuration file, or any leases remaining in the lease database that
have not yet expired, the client will loop through these leases
attempting to validate them, and if it finds one that appears to be
valid, it will use that lease's address.   If there are no valid
static leases or unexpired leases in the lease database, the client
will restart the protocol after the defined retry interval.
.PP
.I The
.B retry
.I statement
.PP
 \fBretry \fItime\fR\fB;\fR
.PP
The
.I retry
statement determines the time that must pass after the client has
determined that there is no DHCP server present before it tries again
to contact a DHCP server.   By default, this is five minutes.
.PP
.I The
.B select-timeout
.I statement
.PP
 \fBselect-timeout \fItime\fR\fB;\fR
.PP
It is possible (some might say desirable) for there to be more than
one DHCP server serving any given network.   In this case, it is
possible that a client may be sent more than one offer in response to
its initial lease discovery message.   It may be that one of these
offers is preferable to the other (e.g., one offer may have the
address the client previously used, and the other may not).
.PP
The
.I select-timeout
is the time after the client sends its first lease discovery request
at which it stops waiting for offers from servers, assuming that it
has received at least one such offer.   If no offers have been
received by the time the
.I select-timeout
has expired, the client will accept the first offer that arrives.
.PP
By default, the select-timeout is zero seconds - that is, the client
will take the first offer it sees.
.PP
.I The
.B reboot
.I statement
.PP
 \fBreboot \fItime\fR\fB;\fR
.PP
When the client is restarted, it first tries to reacquire the last
address it had.   This is called the INIT-REBOOT state.   If it is
still attached to the same network it was attached to when it last
ran, this is the quickest way to get started.   The
.I reboot
statement sets the time that must elapse after the client first tries
to reacquire its old address before it gives up and tries to discover
a new address.   By default, the reboot timeout is ten seconds.
.PP
.I The
.B backoff-cutoff
.I statement
.PP
 \fBbackoff-cutoff \fItime\fR\fB;\fR
.PP
The client uses an exponential backoff algorithm with some randomness,
so that if many clients try to configure themselves at the same time,
they will not make their requests in lockstep.   The
.I backoff-cutoff
statement determines the maximum amount of time that the client is
allowed to back off.   It defaults to two minutes.
.PP
.I The
.B initial-interval
.I statement
.PP
 \fBinitial-interval \fItime\fR\fB;\fR
.PP
The
.I initial-interval
statement sets the amount of time between the first attempt to reach a
server and the second attempt to reach a server.  Each time a message
is sent, the interval between messages is incremented by twice the
current interval multiplied by a random number between zero and one.
If it is greater than the backoff-cutoff amount, it is set to that
amount.  It defaults to ten seconds.
.SH LEASE REQUIREMENTS AND REQUESTS
The DHCP protocol allows the client to request that the server send it
specific information, and not send it other information that it is not
prepared to accept.   The protocol also allows the client to reject
offers from servers if they don't contain information the client
needs, or if the information provided is not satisfactory.
.PP
There is a variety of data contained in offers that DHCP servers send
to DHCP clients.  The data that can be specifically requested is what
are called \fIDHCP Options\fR.  DHCP Options are defined in
 \fBdhcp-options(5)\fR.
.PP
.I The
.B request
.I statement
.PP
 \fBrequest [ \fIoption\fR ] [\fB,\fI ... \fIoption\fR ]\fB;\fR
.PP
The request statement causes the client to request that any server
responding to the client send the client its values for the specified
options.   Only the option names should be specified in the request
statement - not option parameters.   By default, the DHCP server
requests the subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers and host-name options. 
.PP
In some cases, it may be desirable to send no parameter request list
at all.   To do this, simply write the request statement but specify
no parameters:
.PP
.nf
	request;
.fi
.PP
.I The
.B require
.I statement
.PP
 \fBrequire [ \fIoption\fR ] [\fB,\fI ... \fIoption ]\fB;\fR
.PP
The require statement lists options that must be sent in order for an
offer to be accepted.   Offers that do not contain all the listed
options will be ignored.
.PP
.I The
.B send
.I statement
.PP
 \fBsend { [ \fIoption declaration\fR ]
[\fB,\fI ... \fIoption declaration\fR ]\fB}\fR
.PP
The send statement causes the client to send the specified options to
the server with the specified values.  These are full option
declarations as described in \fBdhcp-options(5)\fR.  Options that are
always sent in the DHCP protocol should not be specified here, except
that the client can specify a \fBrequested-lease-time\fR option other
than the default requested lease time, which is two hours.  The other
obvious use for this statement is to send information to the server
that will allow it to differentiate between this client and other
clients or kinds of clients.
.SH DYNAMIC DNS
The client now has some very limited support for doing DNS updates
when a lease is acquired.   This is prototypical, and probably doesn't
do what you want.   It also only works if you happen to have control
over your DNS server, which isn't very likely.
.PP
To make it work, you have to declare a key and zone as in the DHCP
server (see \fBdhcpd.conf\fR(5) for details).   You also need to
configure the fqdn option on the client, as follows:
.PP
.nf
  send fqdn.fqdn "grosse.fugue.com.";
  send fqdn.encoded on;
  send fqdn.server-update off;
.fi
.PP
The \fIfqdn.fqdn\fR option \fBMUST\fR be a fully-qualified domain
name.   You \fBMUST\fR define a zone statement for the zone to be
updated.   The \fIfqdn.encoded\fR option may need to be set to
\fIon\fR or \fIoff\fR, depending on the DHCP server you are using.
.PP
.I The
.B do-forward-updates
.I statement
.PP
 \fBdo-forward-updates [ \fIflag\fR ] \fB;\fR
.PP
If you want to do DNS updates in the DHCP client
script (see \fBdhclient-script(8)\fR) rather than having the
DHCP client do the update directly (for example, if you want to
use SIG(0) authentication, which is not supported directly by the
DHCP client, you can instruct the client not to do the update using
the \fBdo-forward-updates\fR statement.   \fIFlag\fR should be \fBtrue\fR
if you want the DHCP client to do the update, and \fBfalse\fR if
you don't want the DHCP client to do the update.   By default, the DHCP
client will do the DNS update.
.SH OPTION MODIFIERS
In some cases, a client may receive option data from the server which
is not really appropriate for that client, or may not receive
information that it needs, and for which a useful default value
exists.   It may also receive information which is useful, but which
needs to be supplemented with local information.   To handle these
needs, several option modifiers are available.
.PP
.I The
.B default
.I statement
.PP
 \fBdefault [ \fIoption declaration\fR ] \fB;\fR
.PP
If for some option the client should use the value supplied by
the server, but needs to use some default value if no value was supplied
by the server, these values can be defined in the
.B default
statement.
.PP
.I The
.B supersede
.I statement
.PP
 \fBsupersede [ \fIoption declaration\fR ] \fB;\fR
.PP
If for some option the client should always use a locally-configured
value or values rather than whatever is supplied by the server, these
values can be defined in the 
.B supersede
statement.
.PP
.I The
.B prepend
.I statement
.PP
 \fBprepend [ \fIoption declaration\fR ] \fB;\fR
.PP
If for some set of options the client should use a value you
supply, and then use the values supplied by
the server, if any, these values can be defined in the
.B prepend
statement.   The
.B prepend
statement can only be used for options which
allow more than one value to be given.   This restriction is not
enforced - if you ignore it, the behaviour will be unpredictable.
.PP
.I The
.B append
.I statement
.PP
 \fBappend [ \fIoption declaration\fR ] \fB;\fR
.PP