dhclient.conf(5) dhclient.conf(5)
名称
dhclient.conf - DHCP クライアント設定ファイル
解説
dhclient.conf ファイルには Internet Software Consortium の DHCP クライ
アントである dhclient の設定情報が含まれます。
dhclient.conf は自由形式の ASCII テキストファイルです。このファイ ル は
dhclient に組み込まれた再帰下降パーザに解析されます。ファイルには、整形
の目的でタブや改行を余分に含めることもできます。ファイル中のキーワー ド
で は大文字小文字を区別しません。 (クォート内は除いて) ファイル中のどこ
でもコメントを置くことができます。コメントは文字 # で始まり、行末で終わ
ります。
dhclient.conf ファイルで、クライアントのさまざまな動作を設定できます。
それらには、プロトコルのタイミング、サーバに対して要求する情報、サー バ
に 対して必須とされる情報、サーバが情報を提供しなかった場合に用いるデフ
ォルト、サーバから提供された情報を上書きする値、サーバから提供された 情
報に前置や後置する値などがあります。また、DHCP サーバを持たないネットワ
ークで使うアドレスであっても、あらかじめ設定ファイルで初期化すること も
できます。
プロトコルのタイミング
ク ライアントのタイミング動作は、ユーザが設定する必要はありません。ユー
ザがタイミング設定を行わなければ、サーバに無秩序に負荷を与えたりせず 適
時 更新を行うような、充分に適切なタイミング動作がデフォルトで用いられま
す。
しかし、必要に応じて、次の文を指定して DHCP クライアントのタイミング 動
作を調節できます:
timeout 文
timeout time ;
timeout 文は、クライアントがアドレスを決める試みを開始してから、サーバ
にアクセスすることができないと判断するまでに経過すべき時間を決めます 。
デ フォルトではこのタイムアウト値は 60 秒です。このタイムアウト値が過ぎ
た後は、もし静的なリースが設定ファイルに定義されているか、リースデー タ
ベ ースにまだ期限切れになっていないリースが残っていれば、クライアントは
それらのリースをひとつずつ検証してみて、いずれかが有効なようであれば そ
の リースのアドレスを使います。もし静的なリースも、リースデータベース内
の期限の切れていないリースで有効なものも存在しなければ、クライアント は
定義された retry 間隔の後でプロトコルを再開させます。
retry 文
retry time;
retry 文 は、クライアントが DHCP サーバが存在しないと判断してから再び
DHCP サーバにアクセスを試みるまでの間に、経過するべき時間を決めます。デ
フォルトでは、これは 5 分です。
select-timeout 文
select-timeout time;
あ るネットワーク上で、複数の DHCP サーバがサービスを提供することもでき
ます (その方が望ましいという意見もあります)。その場合、最初のリース発見
メッセージ (lease discovery message) への応答として、クライアントが複数
のリース提供の申し出を受けることもあり得ます。それらのうち、ある提供 が
他 の提供よりも好ましいかもしれません (例えば、クライアントが以前使用し
ていたアドレスがある提供に含まれているが、他の提供には含まれないなど)。
select-timeout はクライアントが最初のリース発見要求を送信して、少なくと
も 1 つの提供申し出を受けた場合、サーバからの提供申し出待ちをやめるまで
の 時間です。もし select-timeout が切れるまでにどこからも提供申し出を受
け取れなければ、クライアントはそのあと最初に到着する提供申し出を受け 入
れます。
デ フォルトでは、select-timeout 値は 0 秒です。つまりクライアントは最初
に受け取る提供申し出を受け入れます。
reboot 文
reboot time;
クライアントは、再起動すると、最後に保持していたアドレスをまず取得し 直
そ うとします。これを INIT-REBOOT (初期リブート) 状態と呼びます。最後に
動作していたときと同じネットワークにクライアントがまだ接続していれば 、
こ れが最も素早い起動法となります。 reboot 文は、クライアントが最初に古
いアドレスの再取得を試みてから、あきらめて新しいアドレスを発見しよう と
するまでに、経過すべき時間を設定します。デフォルトでは、reboot タイムア
ウト値は 10 秒です。
backoff-cutoff 文
backoff-cutoff time;
クライアントは、指数的な一時退避 (backoff) アルゴリズムを、ある程度の乱
数 付きで使用します。これは、多くのクライアントが同時に自分を設定しよう
としたときでも、リクエストがロックしてしまうことがないようにするため で
す 。 backoff-cutoff 文は、一時退避に許された最大時間を決定します。デフ
ォルト値は 2 分です。
initial-interval 文
initial-interval time;
initial-interval 文は、サーバへの最初のアクセスの試みから次の試みまでの
間の時間を設定します。メッセージの間隔は、メッセージを 1 回送信するたび
に、現在の間隔に 0 から 1 の間の乱数値を乗じたものの 2 倍を、現在の間隔
に 加えたものになります。この値が backoff-cutoff 値より大きくなると、こ
の時間が設定されます。デフォルト値は 10 秒です。
リース要求とリクエスト
DHCP プロトコルでは、クライアントからサーバに対し、特定の情報を送るよう
要 求したり、受け入れ準備のできていない他の情報は送らないように要求した
りできます。また、サーバからの提供申し出にクライアントの必要とする情 報
が 含まれない場合や、提供された情報が充分でない場合、クライアントが提供
申し出を拒否することもできます。
DHCP サーバが DHCP クライアントに送る提供申し出に含まれるデータには、さ
まざまなものがあります。特に要求できるデータは DHCP オプション と呼ばれ
るものです。 DHCP オプションは
dhcp-options(5) に定義されています。
request 文
request [ option ] [, ... option ];
request 文を指定することで、クライアントは、サーバに対し、そのクライ ア
ン トに応答するならば、指定したオプションの値を送るよう要求するようにな
ります。 request 文にはオプション名だけを指定し、オプションパラメータは
指 定 し ません。デフォルトでは DHCP クライアントは subnet-mask, broad-
cast-address, time-offset, routers, domain-name, domain-name-servers,
host-name オプションを要求します。
場 合によっては要求リストを全く送らないことが望ましいこともあります。そ
うするためには、単純にパラメータを指定しない request 文を書いて下さい:
request;
require 文
require [ option ] [, ... option ];
require 文には、ある提供申し出をクライアントが受け入れるためにサーバ が
送 るべきオプションを列挙します。列挙されたオプションすべてを含まない提
供申し出は無視されます。
send 文
send { [ option declaration ] [, ... option declaration ]}
send 文を指定することで、クライアントは、指定したオプションを指定した値
で サーバに送信するようになります。ここで指定できるオプションは、 dhcp-
options(5) で説明されているオプション宣言すべてです。 DHCP プロトコルで
常 に 送 ら れ る オ プションはここに指定するべきではありません。但し、
requested-lease-time オプションをデフォルトのリース時間 (2 時間) 以外の
値 で指定することはできます。この文を使う他の場合として明らかなものは、
自分と別の種類のクライアントとを区別できるような情報を、サーバに対し 送
信する場合です。
動的 DNS
現在、リースが獲得された際に DNS の更新を行うための、非常に限定的なサポ
ートがクライアントにあります。これはプロトタイプ的なものであり、おそ ら
く あなたが思っているようには動きません。もし、あなたが偶然にも自分のと
ころの DNS サーバの管理者であるというなら、その場合に限っては動きます。
とてもありそうにないことですが。
これを動作させるためには、DHCP サーバの中で鍵とゾーンを宣言する必要があ
ります (詳細は dhcpd.conf(5) を参照)。また、次のようにクライア ン ト で
fqdn オプションを設定する必要があります:
send fqdn.fqdn "grosse.fugue.com.";
send fqdn.encoded on;
send fqdn.server-update off;
fqdn.fqdn オプションは 必ず 完全なドメイン名でなければなりません。更新
するゾーンに対するゾーン文を 必ず 定義 し な け れ ば な り ま せ ん 。
fqdn.encoded オプションは、使用している DHCP サーバによっては、 on か
off に設定する必要があるかもしれません。
no-client-updates 文
no-client-updates [ flag ] ;
DHCP クライアントが直接 DNS の更新を行うよりも、 DHCP クライアントス ク
リ プト (dhclient-script(8) 参照) の中で DNS の更新を行いたい場合 (例え
ば、DHCP クライアントが直接サポートしていない SIG(0) 認証を使用したい場
合) には、no-client-updates 文を使って、更新を行わないようにクライアン
トに教えることができます。 DHCP クライアントが更新することを望まない 場
合は flag を true にし、更新することを望む場合は flag を false にするこ
とになります。デフォルトでは DHCP クライアントは DNS の更新を行います。
オプション修飾子
そ のクライアントにとって実際には適切でないオプションデータを受け取った
り、必要な情報を受け取らなかったりする場合で、かつ、それらの情報に利 用
可 能なデフォルトの値がクライアント側に存在する場合があります。また、利
用可能ではあるがローカルの情報で補う必要のある情報をクライアントが受 け
と る場合もあります。こういう場合を扱うために、いくつかのオプション修飾
子が利用できます。
default 文
default [ option declaration ] ;
あるオプションについて、サーバから提供される値をクライアントが使わな け
れ ばならないが、もしサーバから値が提供されなければ何らかのデフォルト値
を使う必要がある場合、それらの値を default 文で定義することができます。
supersede 文
supersede [ option declaration ] ;
あ るオプションについて、どのような値がサーバから提供されても、常にロー
カルで設定された値を使わなければならない場合、それらの値を supersede 文
で定義することができます。
prepend 文
prepend [ option declaration ] ;
あ るオプションの集合について、まずユーザが提供する値を使い、その次にサ
ーバから提供された値があればそれを使う場合、それらの値を prepend 文で定
義することができます。 prepend 文は複数の値を取ることのできるオプション
にのみ用いることができます。この制約は強制されるものではありませんが 、
これを無視した場合、どのような挙動になるかは予想できません。
append 文
append [ option declaration ] ;
あ るオプションの集合について、まずサーバから提供された値を使い、その次
にユーザが提供する値があればそれも使う場合、それらの値を append 文で 定
義 することができます。 append 文は複数の値を取ることのできるオプション
にのみ用いることができます。この制約は強制されるものではありませんが 、
もし違反すると予期できない結果となります。
リース宣言
lease 宣言
lease { lease-declaration [ ... lease-declaration ] }
あ る時間 (プロトコルのタイミング 参照) の後、DHCP クライアントはサーバ
へのアクセスに成功しそうにないと判断する場合があります。その時点で、 ク
ラ イアントは自分が持っている、古いリースのデータベースを見て、時間切れ
になっていないリースを順に調べ、そこに挙がっているルータに ping を行 っ
て、それが利用可能なリースかどうかを調べます。 DHCP サービスや BOOTP サ
ービスが存在しないネットワークのために、 1 つ以上の 固定 リースをクライ
ア ント設定ファイルに定義しておいて、クライアントがアドレスを自動的に設
定できるようにすることもできます。これは lease 文で行います。
注意: lease 文は、DHCP サーバから受け取ったリースを記録する た め に 、
dhclient.leases ファイルでも使われます。以下に説明するリース用のシンタ
ックスには dhclient.leases ファイルでのみ必要なものもあります。説明を完
全なものにするため、そのようなシンタックスもここで記述します。
lease 文は、リースキーワード、左中括弧、1 つ以上のリース宣言文、右中括
弧が続いたもので構成されます。リース宣言として、次のものが可能です:
bootp;
bootp 文は、リースが DHCP プロトコルではなく、 BOOTP プロトコルを用いて
取 得されたことを示します。この文をクライアント設定ファイルに指定する必
要は全くありません。クライアントはこの構文をリースデータベースファイ ル
内で使います。
interface "string";
interface リース文は、そのリースを有効とするインタフェースを示します。
これが設定されている場合、このリースは、指定されたインタフェース上で の
み 使用されます。サーバからリースを受け取ったとき、クライアントは常にそ
のリースを受け取ったインタフェース番号を記録します。 dhclient.conf ファ
イ ルで事前にリースを定義している場合、要求されてないのですが、そのリー
スでインタフェースもあわせて指定しなければなりません。
fixed-address ip-address;
fixed-address 文は特定のリースの IP アドレスを指定する際に使います。 こ
れ はすべての lease 文に必要です。 IP アドレスは (12.34.56.78 のように)
ドット付き 4 つ組形式で指定しなければなりません。
filename "string";
filename 文は使用するブートファイル名を指定します。これは標準的なクライ
ア ント設定スクリプトでは使われませんが、説明の完全を期すためにここに含
めてあります。
server-name "string";
server-name 文は使用するブートサーバ名を指定します。これも標準的なク ラ
イアント設定スクリプトでは使われません。
option option-declaration;
option 文は、サーバから提供されるオプションの値を指定するのに使います。
あるいは、dhclient.conf で事前定義リースが宣言されている場合には、そ の
事 前定義リースが使われる際にクライアント設定スクリプトで使用して欲しい
値を指定します。
script "script-name";
script 文は dhcp クライアント設定スクリプトのパス名を指定するのに使いま
す 。このスクリプトは、アドレスを要求したり、以前に提供されたアドレスを
試したり、リースを取得してからインタフェースの最終設定を行ったりする 前
に 、 dhcp クライアントが各インタフェースの初期設定を行うのに使います。
リースが取得できなかった場合には、事前定義リースが存在する場合、それ ら
を 試すためにこのスクリプトが使われます。また、有効なリースがひとつも得
られなかった場合でも、このスクリプトは、 1 回は呼び出されます。より詳し
くは、 dhclient-script(8) を参照してください。
vendor option space "name";
vendor option space 文は、vendor-encapsulate-options オプションを受信し
た場合、復号化にどのオプション空間を使用するべきかを指定するために使 用
さ れます。サーバからのベンダオプションの特定のクラスを要求するために、
dhcp-vendor-identifier を使用することができます。詳細は dhcp-options(5)
を参照してください。
medium "media setup";
medium 文は、接続されているネットワークのタイプをネットワークインタフェ
ースが自動的に判断できないようなシステムで使うことができます。 文 字 列
media setup はシステム依存のパラメータで、インタフェース初期化の際に
dhcp クライアント設定スクリプトに渡されます。 Unix および Unix 風のシス
テ ムでは、この引数はインタフェースを設定するときに ifconfig コマンドラ
インに渡されます。
リースを得るためにインタフェースを設定する際に、dhcp クライアントがメデ
ィ アタイプ ( media 文を参照) を使用する場合、dhcp クライアントは、この
パラメータを自動的に宣言します。ネットワークインタフェースがメディア タ
イプの設定を必要とする場合は (する場合に限り)、この文を事前定義リースで
使用しなければなりません。
renew date;
rebind date;
expire date;
renew 文は、現在使用中のリースを更新 (renew) するために、 dhcp クライア
ン トが使用中のリースを提供してくれたサーバへのアクセスの試みを開始しな
ければならない日時を定義します。rebind 文は、リースを更新す る た め に
、dhcp クライアントが いずれかの dhcp サーバへのアクセスの試みを開始し
なければならない日時を定義します。 expire 文は、リースの更新のために サ
ー バにアクセスできなかった場合、 dhcp クライアントがそのリースの使用を
停止しなければならない日時を定義します。
これらの宣言は、DHCP クライアントが得たリース中では自動的に設定されます
。事前定義リースのうち、DHCP クライアントに有効期限が過ぎたものを使用し
て欲しくないものの中では、これらの宣言を設定しておく必要があります。
date は以下のように指定します。
dhclient.conf(5) dhclient.conf(5)
NAME
dhclient.conf - DHCP client configuration file
DESCRIPTION
The dhclient.conf file contains configuration information for dhclient,
the Internet Systems Consortium DHCP Client.
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.
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 configu-
ration file can also be preinitialized with addresses to use on net-
works that don’t have DHCP servers.
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.
The following statements can be used to adjust the timing behaviour of
the DHCP client if required, however:
The timeout statement
timeout time ;
The 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 con-
figuration 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.
The retry statement
retry time;
The 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.
The select-timeout statement
select-timeout time;
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 ini-
tial 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).
The 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 select-timeout has expired, the
client will accept the first offer that arrives.
By default, the select-timeout is zero seconds - that is, the client
will take the first offer it sees.
The reboot statement
reboot time;
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 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.
The backoff-cutoff statement
backoff-cutoff time;
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 backoff-cutoff
statement determines the maximum amount of time that the client is
allowed to back off, the actual value will be evaluated randomly
between 1/2 to 1 1/2 times the time specified. It defaults to two
minutes.
The initial-interval statement
initial-interval time;
The 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.
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.
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 DHCP Options. DHCP Options are defined in
dhcp-options(5).
The request statement
[ also ] request [ [ option-space . ] option ] [, ... ];
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 DHCPv4 client
requests the subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-search, domain-name-servers, host-name, nis-domain,
nis-servers, ntp-servers and interface-mtu options. The DHCPv6 client
requests by default name-servers and domain-search. Note that if you
enter a ’request’ statement, you over-ride this default and these
options will not be requested.
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:
request;
In most cases, it is desirable to simply add one option to the request
list which is of interest to the client in question. In this case, it
is best to ’also request’ the additional options:
also request domain-search, dhcp6.sip-servers-addresses;
The require statement
[ also ] require [ [ option-space . ] option ] [, ... ];
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. There is no default require list.
require name-servers;
interface eth0 {
also require domain-search;
}
The
send
statement
send { [ option declaration ]
[, ... option declaration ]}
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 dhcp-options(5). Options that are
always sent in the DHCP protocol should not be specified here, except
that the client can specify a requested dhcp-lease-time 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.
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.
Note that everything in this section is true whether you are using
DHCPv4 or DHCPv6. The exact same syntax is used for both.
To make it work, you have to declare a key and zone as in the DHCP
server (see dhcpd.conf(5) for details). You also need to configure
the fqdn option on the client, as follows:
send fqdn.fqdn "grosse.fugue.com.";
send fqdn.encoded on;
send fqdn.server-update off;
also request fqdn, dhcp6.fqdn;
The fqdn.fqdn option MUST be a fully-qualified domain name. You MUST
define a zone statement for the zone to be updated. The fqdn.encoded
option may need to be set to on or off, depending on the DHCP server
you are using.
The do-forward-updates statement
do-forward-updates [ flag ] ;
If you want to do DNS updates in the DHCP client script (see dhclient-
script(8)) 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 do-forward-updates statement. Flag should
be true if you want the DHCP client to do the update, and false if you
don’t want the DHCP client to do the update. By default, the DHCP
client will do the DNS update.
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 informa-
tion 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.
The default statement
default [ option declaration ] ;
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 default statement.
The supersede statement
supersede [ option declaration ] ;
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 supersede statement.
The prepend statement
prepend [ option declaration ] ;
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 prepend statement. The 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.
The append statement
append [ option declaration ] ;
If for some set of options the client should first use the values sup-
plied by the server, if any, and then use values you supply, these val-
ues can be defined in the append statement. The append 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.
LEASE DECLARATIONS
The lease declaration
lease { lease-declaration [ ... lease-declaration ] }
The DHCP client may decide after some period of time (see PROTOCOL TIM-
ING) that it is not going to succeed in contacting a server. At that
time, it consults its own database of old leases and tests each one
that has not yet timed out by pinging the listed router for that lease
to see if that lease could work. It is possible to define one or more
fixed leases in the client configuration file for networks where there
is no DHCP or BOOTP service, so that the client can still automatically
configure its address. This is done with the lease statement.
NOTE: the lease statement is also used in the dhclient.leases file in
order to record leases that have been received from DHCP servers. Some
of the syntax for leases as described below is only needed in the
dhclient.leases file. Such syntax is documented here for complete-
ness.
A lease statement consists of the lease keyword, followed by a left
curly brace, followed by one or more lease declaration statements, fol-
lowed by a right curly brace. The following lease declarations are
possible:
bootp;
The bootp statement is used to indicate that the lease was acquired
using the BOOTP protocol rather than the DHCP protocol. It is never
necessary to specify this in the client configuration file. The
client uses this syntax in its lease database file.
interface "string";
The interface lease statement is used to indicate the interface on
which the lease is valid. If set, this lease will only be tried on a
particular interface. When the client receives a lease from a server,
it always records the interface number on which it received that lease.
If predefined leases are specified in the dhclient.conf file, the
interface should also be specified, although this is not required.
fixed-address ip-address;
The fixed-address statement is used to set the ip address of a particu-
lar lease. This is required for all lease statements. The IP
address must be specified as a dotted quad (e.g., 12.34.56.78).
filename "string";
The filename statement specifies the name of the boot filename to use.
This is not used by the standard client configuration script, but is
included for completeness.
server-name "string";
The server-name statement specifies the name of the boot server name to
use. This is also not used by the standard client configuration
script.
option option-declaration;
The option statement is used to specify the value of an option supplied
by the server, or, in the case of predefined leases declared in
dhclient.conf, the value that the user wishes the client configuration
script to use if the predefined lease is used.
script "script-name";
The script statement is used to specify the pathname of the dhcp client
configuration script. This script is used by the dhcp client to set
each interface’s initial configuration prior to requesting an address,
to test the address once it has been offered, and to set the inter-
face’s final configuration once a lease has been acquired. If no
lease is acquired, the script is used to test predefined leases, if
any, and also called once if no valid lease can be identified. For
more information, see dhclient-script(8).
vendor option space "name";
The vendor option space statement is used to specify which option space
should be used for decoding the vendor-encapsulate-options option if
one is received. The dhcp-vendor-identifier can be used to request a
specific class of vendor options from the server. See dhcp-options(5)
for details.
medium "media setup";
The medium statement can be used on systems where network interfaces
cannot automatically determine the type of network to which they are
connected. The media setup string is a system-dependent parameter
which is passed to the dhcp client configuration script when initializ-
ing the interface. On Unix and Unix-like systems, the argument is
passed on the ifconfig command line when configuring the interface.
The dhcp client automatically declares this parameter if it uses a
media type (see the media statement) when configuring the interface in
order to obtain a lease. This statement should be used in predefined
leases only if the network interface requires media type configuration.
renew date;
rebind date;
expire date;
The renew statement defines the time at which the dhcp client should
begin trying to contact its server to renew a lease that it is using.
The rebind statement defines the time at which the dhcp client should
begin to try to contact any dhcp server in order to renew its lease.
The expire statement defines the time at which the dhcp client must
stop using a lease if it has not been able to contact a server in order
to renew it.
These declarations are automatically set in leases acquired by the DHCP
client, but must also be configured in predefined leases - a predefined
lease whose expiry time has passed will not be used by the DHCP client.
Dates are specified in one of two ways. The software will output times
in these two formats depending on if the db-time-format configuration
parameter has been set to default or local.
If it is set to default, then date values appear as follows:
Copyright(C) linux-cmd.com All Rights Reserved. Author Takayuki Yukawa