--- /dev/null
+.\" dhcpd.conf.5
+.\"
+.\" Copyright (c) 1995, 1996, 1997, 1998, 1998, 1999
+.\" 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''.
+.\"
+.\" Japanese Version Copyright (c) 2001 NAKANO Takeo all rights reserved.
+.\" Translated Sun Sep 9 2001 by NAKANO Takeo <nakano@apm.seikei.ac.jp>
+.\"
+.TH dhcpd.conf 5
+.\"O .SH NAME
+.\"O dhcpd.conf - dhcpd configuration file
+.SH ̾Á°
+dhcpd.conf \- dhcpd ¤ÎÀßÄê¥Õ¥¡¥¤¥ë
+.\"O .SH DESCRIPTION
+.SH ÀâÌÀ
+.\"O The dhcpd.conf file contains configuration information for
+.\"O .IR dhcpd,
+.\"O the Internet Software Consortium DHCP Server.
+dhcpd.conf ¤Ï¡¢Internet Software Consortium DHCP ¥µ¡¼¥Ð
+.I dhcpd
+¤ÎÀßÄê¾ðÊ󤬽ñ¤«¤ì¤¿¥Õ¥¡¥¤¥ë¤Ç¤¹¡£
+.PP
+.\"O The dhcpd.conf file is a free-form ASCII text file. It is parsed by
+.\"O the recursive-descent parser built into dhcpd. The file may contain
+.\"O extra tabs and newlines for formatting purposes. Keywords in the file
+.\"O are case-insensitive. Comments may be placed anywhere within the
+.\"O file (except within quotes). Comments begin with the # character and
+.\"O end at the end of the line.
+dhcpd.conf ¥Õ¥¡¥¤¥ë¤Ï¼«Í³·Á¼°¤Î ASCII ¥Æ¥¥¹¥È¥Õ¥¡¥¤¥ë¤Ç¤¹¡£
+dhcpd ¤ËÁȤ߹þ¤Þ¤ì¤¿ºÆµ¢²¼¹ß·¿¤Î¥Ñ¡¼¥¶¤Ë¤è¤Ã¤Æ²ò¼á¤µ¤ì¤Þ¤¹¡£
+¤³¤Î¥Õ¥¡¥¤¥ë¤Ë¤Ï¡¢À°·Á¤ÎÌÜŪ¤Ç;ʬ¤Ê¥¿¥Ö¤ä²þ¹Ô¤òÆþ¤ì¤Æ¤â¤«¤Þ¤¤¤Þ¤»¤ó¡£
+¤³¤Î¥Õ¥¡¥¤¥ë¤Ç¤Ï¡¢¥¡¼¥ï¡¼¥É¤ÎÂçʸ»ú¾®Ê¸»ú¤Ï¶èÊ̤µ¤ì¤Þ¤»¤ó¡£
+¥³¥á¥ó¥È¤Ï¥Õ¥¡¥¤¥ë¤Î¤É¤³¤Ë¤Ç¤âÆþ¤ì¤é¤ì¤Þ¤¹ (¥¯¥©¡¼¥È¤ÎÆâÉô¤ò½ü¤¯)¡£
+¥³¥á¥ó¥È¤Ï # ʸ»ú¤Ç»Ï¤Þ¤ê¡¢¹ÔËö¤Ç½ª¤ï¤ê¤Þ¤¹¡£
+.PP
+.\"O The file essentially consists of a list of statements. Statements
+.\"O fall into two broad categories - parameters and declarations.
+¤³¤Î¥Õ¥¡¥¤¥ë¤Ï´ðËÜŪ¤Ë¤Ïʸ (statement) ¤Î¥ê¥¹¥È¤«¤é¤Ê¤ê¤Þ¤¹¡£
+ʸ¤ÏÂ礤¯Æó¤Ä¤Î¥«¥Æ¥´¥ê¤Ëʬ¤±¤é¤ì¤Þ¤¹¡£¥Ñ¥é¥á¡¼¥¿Ê¸¤ÈÀë¸Àʸ¤Ç¤¹¡£
+.PP
+.\"O Parameter statements either say how to do something (e.g., how long a
+.\"O lease to offer), whether to do something (e.g., should dhcpd provide
+.\"O addresses to unknown clients), or what parameters to provide to the
+.\"O client (e.g., use gateway 220.177.244.7).
+¥Ñ¥é¥á¡¼¥¿Ê¸¤Ï¡¢
+¤Ê¤Ë¤«¤ò¤É¤ÎÍͤ˹Ԥ¦¤« (Î㤨¤ÐÄ󶡤¹¤ë¥ê¡¼¥¹¤ÎŤµ)¡¢
+¤Ê¤Ë¤«¤ò¹Ô¤¦¤«¤É¤¦¤«
+(Î㤨¤ÐÁÇÀ¤Î¤ï¤«¤é¤Ê¤¤¥¯¥é¥¤¥¢¥ó¥È¤Ë¤â¥¢¥É¥ì¥¹¤òÍ¿¤¨¤ë¤«¤É¤¦¤«)¡¢
+¥¯¥é¥¤¥¢¥ó¥È¤Ë¤É¤ÎÍͤʥѥé¥á¡¼¥¿¤òÍ¿¤¨¤ë¤«
+(Î㤨¤Ð¥²¡¼¥È¥¦¥§¥¤¤È¤·¤Æ 220.177.244.7)¡¢
+¤Ê¤É¤ò·è¤á¤Þ¤¹¡£
+.PP
+.\"O Declarations are used to describe the topology of the
+.\"O network, to describe clients on the network, to provide addresses that
+.\"O can be assigned to clients, or to apply a group of parameters to a
+.\"O group of declarations. In any group of parameters and declarations,
+.\"O all parameters must be specified before any declarations which depend
+.\"O on those parameters may be specified.
+Àë¸Àʸ¤Ï¡¢
+¥Í¥Ã¥È¥ï¡¼¥¯¤Î¥È¥Ý¥í¥¸¡¼¤òµ½Ò¤·¤¿¤ê¡¢
+¥Í¥Ã¥È¥ï¡¼¥¯¤Î¥¯¥é¥¤¥¢¥ó¥È¤òµ½Ò¤·¤¿¤ê¡¢
+¥¯¥é¥¤¥¢¥ó¥È¤Ë³ä¤êÅö¤Æ²Äǽ¤Ê¥¢¥É¥ì¥¹¤ò·è¤á¤¿¤ê¡¢
+¤Ò¤È¤Þ¤È¤Þ¤ê¤Î¥Ñ¥é¥á¡¼¥¿¤òÀë¸Àʸ¤Î¥°¥ë¡¼¥×¤ËÍ¿¤¨¤¿¤ê¤¹¤ë¤¿¤á¤ËÍѤ¤¤Þ¤¹¡£
+¥Ñ¥é¥á¡¼¥¿Ê¸¤äÀë¸Àʸ¤Î¥°¥ë¡¼¥×¤Ë¤ª¤¤¤Æ¤Ï¡¢
+¤¢¤ëÀë¸Àʸ¤¬°Í¸¤¹¤ë¥Ñ¥é¥á¡¼¥¿Ê¸¤Ï¡¢
+¤½¤ÎÀë¸Àʸ¤è¤ê¤âÁ°¤Ë»ØÄꤷ¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
+.PP
+.\"O Declarations about network topology include the
+.\"O \fIshared-network\fR and the \fIsubnet\fR
+.\"O declarations. If clients on a subnet are to be assigned addresses
+.\"O dynamically, a \fIrange\fR declaration must appear within the
+.\"O \fIsubnet\fR declaration. For clients with statically assigned
+.\"O addresses, or for installations where only known clients will be
+.\"O served, each such client must have a \fIhost\fR declaration. If
+.\"O parameters are to be applied to a group of declarations which are not
+.\"O related strictly on a per-subnet basis, the \fIgroup\fR declaration
+.\"O can be used.
+¥Í¥Ã¥È¥ï¡¼¥¯¥È¥Ý¥í¥¸¡¼¤Ë´Ø¤¹¤ëÀë¸À¤Ë¤Ï
+\fIshared-network\fR ʸ¤È \fIsubnet\fR ʸ¤¬¤¢¤ê¤Þ¤¹¡£
+¥µ¥Ö¥Í¥Ã¥È¤Ë¤¢¤ë¥¯¥é¥¤¥¢¥ó¥È¤¬¥¢¥É¥ì¥¹¤òưŪ¤Ë³ä¤êÅö¤Æ¤Æ¤â¤é¤¦¾ì¹ç¤Ï¡¢
+\fIsubnet\fR Àë¸À¤ÎÆâÉô¤Ë \fIrange\fR Àë¸Àʸ¤âɬÍפˤʤê¤Þ¤¹¡£
+ÀÅŪ¤Ë¥¢¥É¥ì¥¹¤¬³ä¤êÅö¤Æ¤é¤ì¤¿¥¯¥é¥¤¥¢¥ó¥È¤ä¡¢
+ÁÇÀ¤Î¤ï¤«¤Ã¤Æ¤¤¤ë¥¯¥é¥¤¥¢¥ó¥È¤Ë¤Î¤ß¥¢¥É¥ì¥¹¤òÄ󶡤¹¤ë¤è¤¦¤ÊÀßÄê¤Ç¤Ï¡¢
+¤³¤Î¤è¤¦¤Ê¥¯¥é¥¤¥¢¥ó¥È¤ËÂФ·¤Æ \fIhost\fR Àë¸Àʸ¤¬É¬ÍפǤ¹¡£
+Æä˥µ¥Ö¥Í¥Ã¥È¤Ë´ØÏ¢ÉÕ¤±¤é¤ì¤Æ¤¤¤Ê¤¤Àë¸À¥°¥ë¡¼¥×¤Ë
+²¿¤é¤«¤Î¥Ñ¥é¥á¡¼¥¿¤òÍ¿¤¨¤¿¤¤¾ì¹ç¤Ï¡¢
+\fIgroup\fR Àë¸Àʸ¤¬»È¤¨¤Þ¤¹¡£
+.PP
+.\"O For every subnet which will be served, and for every subnet
+.\"O to which the dhcp server is connected, there must be one \fIsubnet\fR
+.\"O declaration, which tells dhcpd how to recognize that an address is on
+.\"O that subnet. A \fIsubnet\fR declaration is required for each subnet
+.\"O even if no addresses will be dynamically allocated on that subnet.
+¥µ¡¼¥Ó¥¹¤ò¼õ¤±¤ë¥µ¥Ö¥Í¥Ã¥È¤ä¡¢dhcp ¥µ¡¼¥Ð¤¬Àܳ¤¹¤ë¥µ¥Ö¥Í¥Ã¥È¤Ë¤Ï¡¢
+¤¹¤Ù¤Æ \fIsubnet\fR Àë¸À¤¬É¬ÍפȤʤê¤Þ¤¹¡£¤³¤ì¤Ë¤è¤Ã¤Æ dhcpd ¤Ï¡¢
+¤¢¤ë¥¢¥É¥ì¥¹¤¬¤½¤Î¥µ¥Ö¥Í¥Ã¥È¤Ë¤¢¤ë¤³¤È¤òǧ¼±¤¹¤ë¤Î¤Ç¤¹¡£
+\fIsubnet\fR Àë¸À¤Ï¡¢
+¤½¤Î¥µ¥Ö¥Í¥Ã¥È¤ËưŪ³ä¤êÅö¤Æ¤ò¼õ¤±¤ë¥¢¥É¥ì¥¹¤¬¤Ê¤¯¤Æ¤âɬÍפǤ¹¡£
+.PP
+.\"O Some installations have physical networks on which more than one IP
+.\"O subnet operates. For example, if there is a site-wide requirement
+.\"O that 8-bit subnet masks be used, but a department with a single
+.\"O physical ethernet network expands to the point where it has more than
+.\"O 254 nodes, it may be necessary to run two 8-bit subnets on the same
+.\"O ethernet until such time as a new physical network can be added. In
+.\"O this case, the \fIsubnet\fR declarations for these two networks may be
+.\"O enclosed in a \fIshared-network\fR declaration.
+¾ì¹ç¤Ë¤è¤Ã¤Æ¤Ï¡¢°ì¤Ä¤ÎʪÍýŪ¤Ê¥Í¥Ã¥È¥ï¡¼¥¯¤Ë¾å¤Ç
+2 ¤Ä°Ê¾å¤Î IP ¥µ¥Ö¥Í¥Ã¥È¤¬Æ°ºî¤¹¤ë¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£
+Î㤨¤Ð¡¢ÁÈ¿¥¤Î¥ë¡¼¥ë¤Ç 8 ¥Ó¥Ã¥È¤Î¥µ¥Ö¥Í¥Ã¥È¥Þ¥¹¥¯¤ò»È¤Ã¤Æ¤¤¤ë¤È¤·¤Þ¤·¤ç¤¦¡£
+¤³¤Î¤È¤¤¢¤ëÉôÌç¤Ç¡¢
+°ì¤Ä¤ÎʪÍý¥¤¡¼¥µ¥Í¥Ã¥È¥Í¥Ã¥È¥ï¡¼¥¯¤ËÀܳ¤¹¤ë¥Î¡¼¥É¤¬ 254 ¤ò±Û¤¨¤Æ¤·¤Þ¤Ã¤¿¤é¡¢
+¿·¤·¤¤ÊªÍý¥Í¥Ã¥È¥ï¡¼¥¯¤¬ÄɲäǤ¤ë¤Þ¤Ç¤Ï¡¢
+¤½¤Î¥¤¡¼¥µ¥Í¥Ã¥È¤Ç 8 ¥Ó¥Ã¥È¤Î¥µ¥Ö¥Í¥Ã¥È¤ò 2 ¤ÄÁö¤é¤»¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¤Ç¤·¤ç¤¦¡£
+¤³¤Î¤è¤¦¤Ê¾ì¹ç¤Ë¤Ï¡¢
+¤³¤ì¤é¤Î 2 ¤Ä¤Î¥Í¥Ã¥È¥ï¡¼¥¯¤ËÂФ¹¤ë \fIsubnet\fR Àë¸À¤Ï¡¢
+\fIshared-network\fR (¶¦Í¥Í¥Ã¥È¥ï¡¼¥¯) Àë¸À¤Ç°Ï¤¦¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
+.PP
+.\"O Some sites may have departments which have clients on more than one
+.\"O subnet, but it may be desirable to offer those clients a uniform set
+.\"O of parameters which are different than what would be offered to
+.\"O clients from other departments on the same subnet. For clients which
+.\"O will be declared explicitly with \fIhost\fR declarations, these
+.\"O declarations can be enclosed in a \fIgroup\fR declaration along with
+.\"O the parameters which are common to that department. For clients
+.\"O whose addresses will be dynamically assigned, there is currently no
+.\"O way to group parameter assignments other than by network topology.
+¥µ¥¤¥È¤Ë¤è¤Ã¤Æ¤Ï¡¢
+¤¢¤ëÉôÌç¤Î¥¯¥é¥¤¥¢¥ó¥È¤¬ 2 ¤Ä°Ê¾å¤Î¥µ¥Ö¥Í¥Ã¥È¤ËÀܳ¤µ¤ì¤Æ¤¤¤ë¤³¤È¤â¤¢¤ë¤Ç¤·¤ç¤¦¡£
+¤³¤Î¤È¤¤³¤ì¤é¤Î¥¯¥é¥¤¥¢¥ó¥È¤Ë¶¦Ä̤Υѥé¥á¡¼¥¿¤òÍ¿¤¨¡¢
+¤«¤ÄƱ¤¸¥µ¥Ö¥Í¥Ã¥È¤Ë¤¤¤ëÊ̤ÎÉôÌç¤Î¥¯¥é¥¤¥¢¥ó¥È¤Ë¤Ï
+°ã¤¦¥Ñ¥é¥á¡¼¥¿¤òÍ¿¤¨¤¿¤¤¤È¤·¤Þ¤·¤ç¤¦¡£
+\fIhost\fR Àë¸À¤Ë¤è¤Ã¤ÆÌÀ¼¨Åª¤ËÀë¸À¤¹¤ë¥¯¥é¥¤¥¢¥ó¥È¤Ç¤Ï¡¢
+¤³¤ì¤é¤ò \fIgroup\fR Àë¸À¤Ë¤è¤Ã¤Æ°Ï¤Ã¤Æ¡¢
+¤½¤ÎÉôÌç¤Ë¶¦Ä̤Υѥé¥á¡¼¥¿¤òÍ¿¤¨¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
+¥¢¥É¥ì¥¹¤¬Æ°Åª¤Ë³ä¤êÅö¤Æ¤é¤ì¤ë¥¯¥é¥¤¥¢¥ó¥È¤Ç¤Ï¡¢
+º£¤Î¤È¤³¤í¥Í¥Ã¥È¥ï¡¼¥¯¥È¥Ý¥í¥¸¡¼¤Ë¤è¤ë¾¤Ë¤Ï¡¢
+¥°¥ë¡¼¥×ñ°Ì¤Ç¤Î¥Ñ¥é¥á¡¼¥¿³ä¤êÅö¤Æ¤ò¹Ô¤¦ÊýË¡¤Ï¤¢¤ê¤Þ¤»¤ó¡£
+.PP
+.\"O When a client is to be booted, its boot parameters are determined by
+.\"O first consulting that client's \fIhost\fR declaration (if any), then
+.\"O consulting the \fIgroup\fR declaration (if any) which enclosed that
+.\"O \fIhost\fR declaration, then consulting the \fIsubnet\fR declaration
+.\"O for the subnet on which the client is booting, then consulting the
+.\"O \fIshared-network\fR declaration (if any) containing that subnet, and
+.\"O finally consulting the top-level parameters which may be specified
+.\"O outside of any declaration.
+¤¢¤ë¥¯¥é¥¤¥¢¥ó¥È¤¬¥Ö¡¼¥È¤¹¤ë¾ì¹ç¡¢
+¤½¤Î¥Ö¡¼¥È¥Ñ¥é¥á¡¼¥¿¤ò·èÄꤹ¤ë¤Ë¤Ï¡¢
+¤Þ¤º¤½¤Î¥¯¥é¥¤¥¢¥ó¥È¤Î \fIhost\fR Àë¸À¤¬ (¸ºß¤¹¤ì¤Ð) »²¾È¤µ¤ì¤Þ¤¹¡£
+¼¡¤Ë¤½¤Î \fIhost\fR Àë¸À¤ò°Ï¤Ã¤Æ¤¤¤ë
+\fIgroup\fR Àë¸À¤¬ (¸ºß¤¹¤ì¤Ð) »²¾È¤µ¤ì¤Þ¤¹¡£
+¤½¤Î¼¡¤Ë¤Ï¥Ö¡¼¥È¤¹¤ë¥¯¥é¥¤¥¢¥ó¥È¤¬½ê°¤¹¤ë¥µ¥Ö¥Í¥Ã¥È¤Î
+\fIsubnet\fR Àë¸À¤¬»²¾È¤µ¤ì¡¢
+¤µ¤é¤Ë¤½¤Î¥µ¥Ö¥Í¥Ã¥È¤ò°Ï¤Ã¤Æ¤¤¤ë
+\fIshared-network\fR Àë¸À¤¬ (¸ºß¤¹¤ì¤Ð) »²¾È¤µ¤ì¤Þ¤¹¡£
+ºÇ¸å¤Ë¡¢¤¹¤Ù¤Æ¤ÎÀë¸À¤Î³°Éô¤ËÃÖ¤«¤ì¤Æ¤¤¤ë¡¢
+¥È¥Ã¥×¥ì¥Ù¥ë¤Î¥Ñ¥é¥á¡¼¥¿¤¬»²¾È¤µ¤ì¤Þ¤¹¡£
+.PP
+.\"O When dhcpd tries to find a \fIhost\fR declaration for a client, it
+.\"O first looks for a \fIhost\fR declaration which has a
+.\"O \fIfixed-address\fR parameter which matches the subnet or shared
+.\"O network on which the client is booting. If it doesn't find any such
+.\"O entry, it then tries to find an entry which has no \fIfixed-address\fR
+.\"O parameter. If no such entry is found, then dhcpd acts as if there is
+.\"O no entry in the dhcpd.conf file for that client, even if there is an
+.\"O entry for that client on a different subnet or shared network.
+dhcpd ¤¬¥¯¥é¥¤¥¢¥ó¥È¤ËÂбþ¤¹¤ë \fIhost\fR Àë¸À¤òõ¤¹¤È¤¤Ë¤Ï¡¢
+¤Þ¤º¤½¤Î¥¯¥é¥¤¥¢¥ó¥È¤¬¥Ö¡¼¥È¤·¤è¤¦¤È¤·¤Æ¤¤¤ë¥µ¥Ö¥Í¥Ã¥È (¤Þ¤¿¤Ï¶¦Í¥Í¥Ã¥È¥ï¡¼¥¯)
+¤Ë¥Þ¥Ã¥Á¤¹¤ë \fIfixed-address\fR ¥Ñ¥é¥á¡¼¥¿¤ò´Þ¤à \fIhost\fR Àë¸À¤òõ¤·¤Þ¤¹¡£
+¤½¤Î¤è¤¦¤Ê¥¨¥ó¥È¥ê¤¬¤Ê¤±¤ì¤Ð¡¢
+\fIfixed-address\fR ¥Ñ¥é¥á¡¼¥¿¤¬´Þ¤Þ¤ì¤Ê¤¤¥¨¥ó¥È¥ê¤òõ¤·¤Þ¤¹¡£
+¤½¤Î¤è¤¦¤Ê¥¨¥ó¥È¥ê¤â¤Ê¤±¤ì¤Ð¡¢
+¤¿¤È¤¨¤½¤Î¥¯¥é¥¤¥¢¥ó¥È¤Î¥¨¥ó¥È¥ê¤¬Ê̤Υµ¥Ö¥Í¥Ã¥È¤ä¶¦Í¥Í¥Ã¥È¥ï¡¼¥¯¤Ë¤¢¤Ã¤Æ¤â¡¢
+dhcpd ¤Ï¤½¤Î¥¯¥é¥¤¥¢¥ó¥È¤Î¥¨¥ó¥È¥ê¤¬
+dhcpd.conf ¥Õ¥¡¥¤¥ë¤Ë¤Ï¸ºß¤·¤Ê¤¤¤«¤Î¤è¤¦¤ËÆ°ºî¤·¤Þ¤¹¡£
+.\"O .SH EXAMPLES
+.SH Îã
+.PP
+.\"O A typical dhcpd.conf file will look something like this:
+¤è¤¯¤¢¤ë dhcpd.conf ¥Õ¥¡¥¤¥ë¤ÎÎã¤ò¼¨¤·¤Þ¤¹:
+.nf
+
+.I global parameters...
+
+shared-network ISC-BIGGIE {
+ \fIshared-network-specific parameters...\fR
+ subnet 204.254.239.0 netmask 255.255.255.224 {
+ \fIsubnet-specific parameters...\fR
+ range 204.254.239.10 204.254.239.30;
+ }
+ subnet 204.254.239.32 netmask 255.255.255.224 {
+ \fIsubnet-specific parameters...\fR
+ range 204.254.239.42 204.254.239.62;
+ }
+}
+
+subnet 204.254.239.64 netmask 255.255.255.224 {
+ \fIsubnet-specific parameters...\fR
+ range 204.254.239.74 204.254.239.94;
+}
+
+group {
+ \fIgroup-specific parameters...\fR
+ host zappo.test.isc.org {
+ \fIhost-specific parameters...\fR
+ }
+ host beppo.test.isc.org {
+ \fIhost-specific parameters...\fR
+ }
+ host harpo.test.isc.org {
+ \fIhost-specific parameters...\fR
+ }
+}
+
+.ce 1
+Figure 1
+
+.fi
+.PP
+.\"O Notice that at the beginning of the file, there's a place
+.\"O for global parameters. These might be things like the organization's
+.\"O domain name, the addresses of the name servers (if they are common to
+.\"O the entire organization), and so on. So, for example:
+¥Õ¥¡¥¤¥ë¤ÎÀèƬ¤Ë¤Ï¥°¥í¡¼¥Ð¥ë¤Ê¥Ñ¥é¥á¡¼¥¿¤Î¤¿¤á¤Î
+¾ì½ê¤¬¤¢¤ë¤³¤È¤Ë¤ªµ¤¤Å¤¤Ë¤Ê¤Ã¤¿¤«¤È»×¤¤¤Þ¤¹¡£
+¤³¤³¤Ç¤ÏÁÈ¿¥¤Î¥É¥á¥¤¥ó̾¡¢¥Í¡¼¥à¥µ¡¼¥Ð¤Î¥¢¥É¥ì¥¹
+(ÁÈ¿¥Á´ÂΤ˶¦Ä̤Τâ¤Î¤¬¤¢¤ì¤Ð) ¤Ê¤É¤ò»ØÄꤷ¤Þ¤¹¡£
+½¾¤Ã¤Æ¡¢Î㤨¤Ð¼¡¤Î¤è¤¦¤Ë¤Ê¤ë¤Ç¤·¤ç¤¦¡£
+.nf
+
+ option domain-name "isc.org";
+ option domain-name-servers ns1.isc.org, ns2.isc.org;
+
+.ce 1
+Figure 2
+.fi
+.PP
+.\"O As you can see in Figure 2, it's legal to specify host addresses in
+.\"O parameters as domain names rather than as numeric IP addresses. If a
+.\"O given hostname resolves to more than one IP address (for example, if
+.\"O that host has two ethernet interfaces), both addresses are supplied to
+.\"O the client.
+Figure 2 ¤Ë¤¢¤ë¤È¤ª¤ê¡¢¥Ñ¥é¥á¡¼¥¿¤ËÍ¿¤¨¤ë¥Û¥¹¥È¤Î¥¢¥É¥ì¥¹¤Ï¡¢
+¿ôÃÍ·Á¼°¤Î IP ¥¢¥É¥ì¥¹¤Ç¤Ï¤Ê¤¯¥É¥á¥¤¥ó̾¤ÇÍ¿¤¨¤Æ¤â¤«¤Þ¤¤¤Þ¤»¤ó¡£
+Í¿¤¨¤é¤ì¤¿¥Û¥¹¥È̾¤¬ 1 ¤Ä°Ê¾å¤Î IP ¥¢¥É¥ì¥¹¤Ë²ò·è¤µ¤ì¤ë
+(Î㤨¤Ð¥Û¥¹¥È¤¬¥¤¡¼¥µ¥Í¥Ã¥È¥¤¥ó¥¿¡¼¥Õ¥§¡¼¥¹¤ò 2 ¤Ä»ý¤Ã¤Æ¤¤¤ë¤Ê¤É)
+¾ì¹ç¤Ë¤Ï¡¢¥¯¥é¥¤¥¢¥ó¥È¤Ë¤Ï¤¹¤Ù¤Æ¤Î¥¢¥É¥ì¥¹¤¬ÅϤµ¤ì¤Þ¤¹¡£
+.PP
+.\"O In Figure 1, you can see that both the shared-network statement and
+.\"O the subnet statements can have parameters. Let us say that the
+.\"O shared network \fIISC-BIGGIE\fR supports an entire department -
+.\"O perhaps the accounting department. If accounting has its own domain,
+.\"O then a shared-network-specific parameter might be:
+Figure 1 ¤«¤é¤ï¤«¤ë¤È¤ª¤ê¡¢shared-network ʸ¤â
+subnet ʸ¤â¥Ñ¥é¥á¡¼¥¿¤ò¼è¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
+¤³¤³¤Ç¶¦Í¥Í¥Ã¥È¥ï¡¼¥¯ \fIISC-BIGGIE\fR ¤ÏÉôÌç (Î㤨¤Ð·ÐÍýÉôÌç)
+Á´ÂΤò¥µ¥Ý¡¼¥È¤·¤Æ¤¤¤ë¤È¤·¤Þ¤·¤ç¤¦¡£
+·ÐÍýÉôÌç¤Ë¤Ï¼«Á°¤Î¥É¥á¥¤¥ó¤¬¤¢¤ë¤È¤¹¤ë¤È¡¢
+shared-network ÀìÍѤΥѥé¥á¡¼¥¿¤È¤·¤Æ°Ê²¼¤òÍ¿¤¨¤ë¤Ù¤¤Ç¤·¤ç¤¦¡£
+.nf
+
+ option domain-name "accounting.isc.org";
+.fi
+.PP
+.\"O All subnet declarations appearing in the shared-network declaration
+.\"O would then have the domain-name option set to "accounting.isc.org"
+.\"O instead of just "isc.org".
+¤¹¤ë¤È shared-network Àë¸À¤ÎÆâÉô¤Ë¤¢¤ë subnet Àë¸À¤Ç¤Ï¡¢
+domain-name ¥ª¥×¥·¥ç¥ó¤Ïñ¤Ê¤ë "isc.org" ¤Ç¤Ï¤Ê¤¯ "accounting.isc.org"
+¤Ë¤Ê¤ê¤Þ¤¹¡£
+.PP
+.\"O The most obvious reason for having subnet-specific parameters as
+.\"O shown in Figure 1 is that each subnet, of necessity, has its own
+.\"O router. So for the first subnet, for example, there should be
+.\"O something like:
+Figure 1 ¤Î¤è¤¦¤Ë subnet ¤Ë¸ÇͤΥѥé¥á¡¼¥¿¤òÍ¿¤¨¤¿¤¤¤Î¤Ï¡¢
+ÅöÁ³¤Ê¤¬¤é¡¢¥µ¥Ö¥Í¥Ã¥È¤Ï¤½¤ì¤¾¤ì°ã¤Ã¤¿¥ë¡¼¥¿¤òɬÍפȤ¹¤ë¤«¤é¤Ç¤¹¡£
+¤·¤¿¤¬¤Ã¤ÆºÇ½é¤Î¥µ¥Ö¥Í¥Ã¥È¤Ë¤Ï¡¢
+Î㤨¤Ð°Ê²¼¤Î¤è¤¦¤Êʸ¤¬ÃÖ¤«¤ì¤ë¤³¤È¤Ë¤Ê¤ë¤Ç¤·¤ç¤¦¡£
+.nf
+
+ option routers 204.254.239.1;
+.fi
+.PP
+.\"O Note that the address here is specified numerically. This is not
+.\"O required - if you have a different domain name for each interface on
+.\"O your router, it's perfectly legitimate to use the domain name for that
+.\"O interface instead of the numeric address. However, in many cases
+.\"O there may be only one domain name for all of a router's IP addresses, and
+.\"O it would not be appropriate to use that name here.
+¤³¤³¤Ç¤Ï¥¢¥É¥ì¥¹¤Ï¿ôÃͤǻØÄꤵ¤ì¤Æ¤¤¤Þ¤¹¡£
+¤³¤ì¤Ïɬ¿Ü¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£
+¤â¤·¥ë¡¼¥¿¤Î³Æ¥¤¥ó¥¿¡¼¥Õ¥§¡¼¥¹¤¬ÊÌ¡¹¤Î¥É¥á¥¤¥ó̾¤ò»ý¤Ã¤Æ¤¤¤ë¤Ê¤é¡¢
+¤½¤Î¥¤¥ó¥¿¡¼¥Õ¥§¡¼¥¹¤Î»ØÄê¤Ë¤Ï¡¢¿ôÃͤǤʤ¯¥É¥á¥¤¥ó̾¤òÍѤ¤¤Æ¤âÁ´¤¯¤«¤Þ¤¤¤Þ¤»¤ó¡£
+¤·¤«¤·¤Ê¤¬¤é¡¢Â¿¤¯¤Î¾ì¹ç¥ë¡¼¥¿¤Î IP ¥¢¥É¥ì¥¹¤½¤ì¤¾¤ì¤Ë¤Ï
+°ì¤Ä¤ÎƱ¤¸¥É¥á¥¤¥ó̾¤¬¤Ä¤±¤é¤ì¤Æ¤¤¤ë¤Ç¤·¤ç¤¦¤«¤é¡¢
+¤³¤³¤Ç¤½¤Î̾Á°¤òÍѤ¤¤ë¤Î¤ÏŬÀڤǤϤʤ¤¤Ç¤·¤ç¤¦¡£
+.PP
+.\"O In Figure 1 there is also a \fIgroup\fR statement, which provides
+.\"O common parameters for a set of three hosts - zappo, beppo and harpo.
+.\"O As you can see, these hosts are all in the test.isc.org domain, so it
+.\"O might make sense for a group-specific parameter to override the domain
+.\"O name supplied to these hosts:
+Figure 1 ¤Ç¤Ï¡¢\fIgroup\fR ʸ¤â»È¤ï¤ì¤Æ¤ª¤ê¡¢
+3 ¤Ä¤Î¥Û¥¹¥È (zappo, beppo, harpo) ¤Ë¶¦Ä̤Υѥé¥á¡¼¥¿¤ò¤¢¤¿¤¨¤Æ¤¤¤Þ¤¹¡£
+¤ª¤ï¤«¤ê¤Î¤è¤¦¤Ë¡¢¤³¤ì¤é¤Î¥Û¥¹¥È¤Ï¤¹¤Ù¤Æ test.isc.org ¥É¥á¥¤¥ó¤Ë°¤·¤Æ¤¤¤Þ¤¹¡£
+¤·¤¿¤¬¤Ã¤Æ¤³¤ì¤é¤Î¥Û¥¹¥È¤Ë¤Ï¡¢
+¥°¥ë¡¼¥×¸ÇͤΥѥé¥á¡¼¥¿¤È¤·¤Æ¥É¥á¥¤¥ó̾¤ò¾å½ñ¤¤¹¤ë¤«¤¿¤Á¤Ç
+Í¿¤¨¤ë¤Î¤¬Îɤ¤¤Ç¤·¤ç¤¦¡£
+.nf
+
+ option domain-name "test.isc.org";
+.fi
+.PP
+.\"O Also, given the domain they're in, these are probably test machines.
+.\"O If we wanted to test the DHCP leasing mechanism, we might set the
+.\"O lease timeout somewhat shorter than the default:
+¤Þ¤¿¡¢½ê°¤¹¤ë¥É¥á¥¤¥ó̾¤«¤éÁÛÁü¤Ç¤¤ë¤è¤¦¤Ë¡¢
+¤³¤ì¤é¤Ï¤ª¤½¤é¤¯¥Æ¥¹¥ÈÍѤΥޥ·¥ó¤Ç¤·¤ç¤¦¡£
+DHCP Âߤ·½Ð¤·µ¡¹½¤ò¥Æ¥¹¥È¤¹¤ë¾ì¹ç¤Ë¤Ï¡¢
+Âߤ·½Ð¤·¤Î´ü¸Â¤ò¥Ç¥Õ¥©¥ë¥È¤è¤ê¤Ï¾¯¡¹Ã»¤¯¤·¤Æ¤ª¤¯¤Î¤¬Îɤ¤¤Ç¤·¤ç¤¦¡£
+.nf
+
+ max-lease-time 120;
+ default-lease-time 120;
+.fi
+.PP
+.\"O You may have noticed that while some parameters start with the
+.\"O \fIoption\fR keyword, some do not. Parameters starting with the
+.\"O \fIoption\fR keyword correspond to actual DHCP options, while
+.\"O parameters that do not start with the option keyword either control
+.\"O the behaviour of the DHCP server (e.g., how long a lease dhcpd will
+.\"O give out), or specify client parameters that are not optional in the
+.\"O DHCP protocol (for example, server-name and filename).
+¤³¤ì¤Þ¤Ç¤Î¤È¤³¤í¤Ç¡¢\fIoption\fR ¥¡¼¥ï¡¼¥É¤Ë¤è¤Ã¤Æ»Ï¤Þ¤ë¥Ñ¥é¥á¡¼¥¿¤È¡¢
+¤½¤¦¤Ç¤Ê¤¤¥Ñ¥é¥á¡¼¥¿¤È¤¬¤¢¤ë¤³¤È¤Ë¤ªµ¤¤Å¤¤Ë¤Ê¤Ã¤¿¤Ç¤·¤ç¤¦¤«¡£
+\fIoption\fR ¥¡¼¥ï¡¼¥É¤Ç»Ï¤Þ¤ë¥Ñ¥é¥á¡¼¥¿¤Ï¡¢
+¼ÂºÝ¤Î DHCP ¥ª¥×¥·¥ç¥ó¤Ë´ØÏ¢¤·¤¿¤â¤Î¤Ç¤¹¡£
+¤½¤¦¤Ç¤Ê¤¤¤â¤Î¤Ï¡¢
+DHCP ¥µ¡¼¥Ð¤ÎÆ°ºî¤òÀ©¸æ¤¹¤ë¤â¤Î (Î㤨¤Ð dhcpd ¤¬Ä󶡤¹¤ëÂߤ·½Ð¤·¤Î´ü¸Â¤Ê¤É) ¤«¡¢
+DHCP ¥×¥í¥È¥³¥ë¤Ç¤ÏÄ󶡤µ¤ì¤Æ¤¤¤Ê¤¤¥¯¥é¥¤¥¢¥ó¥ÈÍѤΥѥé¥á¡¼¥¿
+(Î㤨¤Ð¥µ¡¼¥Ð̾¤ä¥Õ¥¡¥¤¥ë̾) ¤Ç¤¹¡£
+.PP
+.\"O In Figure 1, each host had \fIhost-specific parameters\fR. These
+.\"O could include such things as the \fIhostname\fR option, the name of a
+.\"O file to upload (the \fIfilename parameter) and the address of the
+.\"O server from which to upload the file (the \fInext-server\fR
+.\"O parameter). In general, any parameter can appear anywhere that
+.\"O parameters are allowed, and will be applied according to the scope in
+.\"O which the parameter appears.
+Figure 1 ¤Ç¤Ï¡¢³Æ¥Û¥¹¥È¤Ï¡Ö¥Û¥¹¥È¸ÇͤΥѥé¥á¡¼¥¿¡×¤ò»ý¤Ã¤Æ¤¤¤Þ¤·¤¿¡£
+¤³¤ì¤é¤Ë¤ÏÎ㤨¤Ð¡¢\fIhostname\fR ¥ª¥×¥·¥ç¥ó¡¢
+¼èÆÀ¤¹¤ë¤¹¤ë¥Õ¥¡¥¤¥ë (\fIfilename\fR ¥Ñ¥é¥á¡¼¥¿)¡¢
+¥Õ¥¡¥¤¥ë¤ò¼èÆÀ¤¹¤ë¥Û¥¹¥È (\fInext-server\fR ¥Ñ¥é¥á¡¼¥¿)
+¤Ê¤É¤¬´Þ¤Þ¤ì¤Þ¤¹¡£
+°ìÈÌŪ¤Ë¤Ï¡¢¥Ñ¥é¥á¡¼¥¿¤ò»ØÄê¤Ç¤¤ë¾ì½ê¤Ë¤Ï¤É¤ó¤Ê¥Ñ¥é¥á¡¼¥¿¤Ç¤â»ØÄê¤Ç¤¡¢
+¤½¤Î¥Ñ¥é¥á¡¼¥¿¤ÏÃÖ¤«¤ì¤¿¾ì½ê¤Î¥¹¥³¡¼¥×¤Ë¤·¤¿¤¬¤Ã¤ÆŬÍѤµ¤ì¤Þ¤¹¡£
+.PP
+.\"O Imagine that you have a site with a lot of NCD X-Terminals. These
+.\"O terminals come in a variety of models, and you want to specify the
+.\"O boot files for each models. One way to do this would be to have host
+.\"O declarations for each server and group them by model:
+NCD ¤Î X üËö¤¬¤¿¤¯¤µ¤ó¤¢¤ë¤è¤¦¤Ê¥µ¥¤¥È¤òÁÛÁü¤·¤Æ¤¯¤À¤µ¤¤¡£
+¤³¤ì¤é¤ÎüËö¤Ë¤Ï¤µ¤Þ¤¶¤Þ¤Ê¥â¥Ç¥ë¤¬¤¢¤ë¤Î¤Ç¡¢
+¤½¤ì¤¾¤ì¤Î¥â¥Ç¥ë¤ËÂФ·¤ÆÊÌ¡¹¤Î¥Ö¡¼¥È¥Õ¥¡¥¤¥ë¤ò»ØÄꤷ¤¿¤¤¤È¤·¤Þ¤¹¡£
+¤³¤ì¤ò¹Ô¤¦°ì¤Ä¤ÎÊýË¡¤Ï¡¢
+³ÆüËö¤Ë host Àë¸À¤ò¤µ¤»¡¢¤½¤ì¤é¤ò¥â¥Ç¥ë¤´¤È¤Ë group ²½¤¹¤ë¤³¤È¤Ç¤¹¡£
+.nf
+
+group {
+ filename "Xncd19r";
+ next-server ncd-booter;
+
+ host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }
+ host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }
+ host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }
+}
+
+group {
+ filename "Xncd19c";
+ next-server ncd-booter;
+
+ host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }
+ host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }
+}
+
+group {
+ filename "XncdHMX";
+ next-server ncd-booter;
+
+ host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }
+ host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }
+ host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }
+}
+.fi
+.\"O .SH REFERENCE: DECLARATIONS
+.SH ¥ê¥Õ¥¡¥ì¥ó¥¹: Àë¸Àʸ
+.PP
+.\"O .B The
+.I shared-network
+.\"O .B statement
+.B ʸ
+.PP
+.nf
+ \fBshared-network\fR \fIname\fR \fB{\fR
+ [ \fIparameters\fR ]
+ [ \fIdeclarations\fR ]
+ \fB}\fR
+.fi
+.PP
+.\"O The \fIshared-network\fR statement is used to inform the DHCP server
+.\"O that some IP subnets actually share the same physical network. Any
+.\"O subnets in a shared network should be declared within a
+.\"O \fIshared-network\fR statement. Parameters specified in the
+.\"O \fIshared-network\fR statement will be used when booting clients on
+.\"O those subnets unless parameters provided at the subnet or host level
+.\"O override them. If any subnet in a shared network has addresses
+.\"O available for dynamic allocation, those addresses are collected into a
+.\"O common pool for that shared network and assigned to clients as needed.
+.\"O There is no way to distinguish on which subnet of a shared network a
+.\"O client should boot.
+\fIshared-network\fR ʸ¤Ï¡¢Ê£¿ô¤Î IP ¥µ¥Ö¥Í¥Ã¥È¤¬¼ÂºÝ¤Ë¤Ï
+°ì¤Ä¤ÎʪÍý¥Í¥Ã¥È¥ï¡¼¥¯¤ò¶¦Í¤·¤Æ¤¤¤ë¤³¤È¤ò DHCP ¥µ¡¼¥Ð¤ËÅÁ¤¨¤ë¤¿¤á¤ËÍѤ¤¤Þ¤¹¡£
+¶¦Í¥Í¥Ã¥È¥ï¡¼¥¯Æâ¤Ë¤¢¤ë¥µ¥Ö¥Í¥Ã¥È¤Ï¡¢
+\fIshared-network\fR ʸ¤ÎÆâÉô¤ÇÀë¸À¤¹¤ë¤è¤¦¤Ë¤¹¤Ù¤¤Ç¤¹¡£
+\fIshared-network\fR ʸ¤ÎÆâÉô¤Ç»ØÄꤵ¤ì¤¿¥Ñ¥é¥á¡¼¥¿¤Ï¡¢
+¤½¤ì¤é¤Î¥µ¥Ö¥Í¥Ã¥È¤Ç¥Ö¡¼¥È¤·¤¿¥¯¥é¥¤¥¢¥ó¥È¤Ë¤è¤Ã¤ÆÍѤ¤¤é¤ì¤Þ¤¹
+(¤¿¤À¤·¤½¤Î¥Ñ¥é¥á¡¼¥¿¤¬¥µ¥Ö¥Í¥Ã¥È¤ä¥Û¥¹¥È¥ì¥Ù¥ë¤Ç¾å½ñ¤¤µ¤ì¤¿¾ì¹ç¤ò½ü¤¯)¡£
+¶¦Í¥Í¥Ã¥È¥ï¡¼¥¯¤Ë°¤¹¤ë¥µ¥Ö¥Í¥Ã¥È¤ËưŪ³ä¤êÅö¤Æ²Äǽ¤Ê¥¢¥É¥ì¥¹¤¬¤¢¤ë¤È¡¢
+¤³¤ì¤é¤Î¥¢¥É¥ì¥¹¤Ï¶¦Í¥Í¥Ã¥È¥ï¡¼¥¯ÍѤξì½ê¤Ë¶¦Ä̤˥ס¼¥ë¤µ¤ì¡¢
+ɬÍפ˱þ¤¸¤Æ¥¯¥é¥¤¥¢¥ó¥È¤ËÄ󶡤µ¤ì¤Þ¤¹¡£
+¤¢¤ë¥¯¥é¥¤¥¢¥ó¥È¤¬¡¢(¶¦Í¥Í¥Ã¥È¥ï¡¼¥¯¤Ë°¤¹¤ë)
+¤É¤Î¥µ¥Ö¥Í¥Ã¥È¤«¤é¥Ö¡¼¥È¤µ¤»¤ë¤Ù¤¤«¤ò¼±Ê̤¹¤ëÊýË¡¤Ï¤¢¤ê¤Þ¤»¤ó¡£
+.PP
+.\"O .I Name
+.\"O should be the name of the shared network. This name is used when
+.\"O printing debugging messages, so it should be descriptive for the
+.\"O shared network. The name may have the syntax of a valid domain name
+.\"O (although it will never be used as such), or it may be any arbitrary
+.\"O name, enclosed in quotes.
+.I name
+¤Ë¤Ï¶¦Ḁ̈ͥåȥ¥¯¤Î̾Á°¤ò»ØÄꤷ¤Æ¤ª¤¤Þ¤·¤ç¤¦¡£
+¤³¤Î̾Á°¤Ï¥Ç¥Ð¥Ã¥°¥á¥Ã¥»¡¼¥¸¤Î½ÐÎÏ»þ¤ËÍѤ¤¤é¤ì¤ë¤Î¤Ç¡¢
+¤½¤Î¶¦Ḁ̈ͥåȥ¥¯¤Îǧ¼±¤ËÌòΩ¤Á¤Þ¤¹¡£
+̾Á°¤Ë¤Ï¥É¥á¥¤¥ó̾¤È¤·¤Æ͸ú¤Ê½ñ¼° (¤¿¤À¤·¥É¥á¥¤¥ó̾¤È¤·¤Æ¤ÏÍѤ¤¤é¤ì¤Ê¤¤)
+¤¬»È¤¨¤Þ¤¹¡£
+¤¢¤ë¤¤¤Ï¥¯¥©¡¼¥È¤¹¤ì¤Ð¤É¤ó¤Ê̾Á°¤Ç¤â»È¤¨¤Þ¤¹¡£
+.PP
+.\"O .B The
+.I subnet
+.\"O .B statement
+.B ʸ
+.PP
+.nf
+ \fBsubnet\fR \fIsubnet-number\fR \fBnetmask\fR \fInetmask\fR \fB{\fR
+ [ \fIparameters\fR ]
+ [ \fIdeclarations\fR ]
+ \fB}\fR
+.fi
+.PP
+.\"O The \fIsubnet\fR statement is used to provide dhcpd with enough
+.\"O information to tell whether or not an IP address is on that subnet.
+.\"O It may also be used to provide subnet-specific parameters and to
+.\"O specify what addresses may be dynamically allocated to clients booting
+.\"O on that subnet. Such addresses are specified using the \fIrange\fR
+.\"O declaration.
+\fIsubnet\fR ʸ¤Ï¡¢
+¤¢¤ë IP ¥¢¥É¥ì¥¹¤¬ÆÃÄê¤Î¥µ¥Ö¥Í¥Ã¥È¤Ë°¤·¤Æ¤¤¤ë¤«¤É¤¦¤«È½ÃǤ¹¤ë¤¿¤á¤Î¾ðÊó¤ò
+dhcpd ¤ËÍ¿¤¨¤ë¤¿¤á¤ËÍѤ¤¤Þ¤¹¡£
+¤Þ¤¿¥µ¥Ö¥Í¥Ã¥È¸ÇͤΥѥé¥á¡¼¥¿¤ò»ØÄꤷ¤¿¤ê¡¢
+¤½¤Î¥µ¥Ö¥Í¥Ã¥È¤Ç¥Ö¡¼¥È¤·¤¿¥¯¥é¥¤¥¢¥ó¥È¤Ë
+ưŪ³ä¤êÅö¤Æ²Äǽ¤Ê¥¢¥É¥ì¥¹¤ò»ØÄꤹ¤ë¤¿¤á¤Ë¤âÍøÍѤµ¤ì¤Þ¤¹¡£
+¸å¼Ô¤Î¤è¤¦¤Ê¥¢¥É¥ì¥¹¤Ï \fIrange\fR Àë¸À¤Ç»ØÄꤵ¤ì¤Þ¤¹¡£
+.PP
+.\"O The
+.\"O .I subnet-number
+.\"O should be an IP address or domain name which resolves to the subnet
+.\"O number of the subnet being described. The
+.\"O .I netmask
+.\"O should be an IP address or domain name which resolves to the subnet mask
+.\"O of the subnet being described. The subnet number, together with the
+.\"O netmask, are sufficient to determine whether any given IP address is
+.\"O on the specified subnet.
+.I subnet-number
+¤Ë¤Ï IP ¥¢¥É¥ì¥¹¤«¡¢
+¤¢¤ë¤¤¤ÏÀë¸À¤¹¤ë¥µ¥Ö¥Í¥Ã¥È¤Î IP ÈÖ¹æ¤Ë²ò·è¤µ¤ì¤ë¥É¥á¥¤¥ó̾¤òÍ¿¤¨¤Þ¤¹¡£
+.I netmask
+¤Ë¤Ï IP ¥¢¥É¥ì¥¹¤«¡¢
+¤¢¤ë¤¤¤ÏÀë¸À¤¹¤ë¥µ¥Ö¥Í¥Ã¥È¤Î¥µ¥Ö¥Í¥Ã¥È¥Þ¥¹¥¯¤Ë²ò·è¤µ¤ì¤ë¥É¥á¥¤¥ó̾¤òÍ¿¤¨¤Þ¤¹¡£
+¥µ¥Ö¥Í¥Ã¥ÈÈÖ¹æ¤È¥Í¥Ã¥È¥Þ¥¹¥¯¤È¤òÍ¿¤¨¤ë¤È¡¢
+¤¢¤ëÍ¿¤¨¤é¤ì¤¿ IP Èֹ椬
+¤½¤Î¥µ¥Ö¥Í¥Ã¥È¤Ë°¤·¤Æ¤¤¤ë¤«¤É¤¦¤«¤òȽÃǤǤ¤ë¤è¤¦¤Ë¤Ê¤ê¤Þ¤¹¡£
+.PP
+.\"O Although a netmask must be given with every subnet declaration, it is
+.\"O recommended that if there is any variance in subnet masks at a site, a
+.\"O subnet-mask option statement be used in each subnet declaration to set
+.\"O the desired subnet mask, since any subnet-mask option statement will
+.\"O override the subnet mask declared in the subnet statement.
+¥Í¥Ã¥È¥Þ¥¹¥¯¤Ï¤¹¤Ù¤Æ¤Î subnet Àë¸À¤ËɬÍפǤ¹¤¬¡¢
+¤¢¤ë¥µ¥¤¥È¤ÎÆâÉô¤ÇÍѤ¤¤Æ¤¤¤ë¥µ¥Ö¥Í¥Ã¥È¥Þ¥¹¥¯¤ËÊ£¿ô¤Î¼ïÎब¤¢¤ë¾ì¹ç¤Ï¡¢
+subnet-mask ¥ª¥×¥·¥ç¥óʸ¤ò³Æ subnet Àë¸À¤ÎÆâÉô¤ÇÍѤ¤¤Æ¡¢
+ŬÀڤʥµ¥Ö¥Í¥Ã¥È¥Þ¥¹¥¯¤òÀßÄꤹ¤ë¤³¤È¤â¤·¤Æ¤ª¤¯¤Ù¤¤Ç¤¹¡£
+¤Ê¤¼¤«¤È¤¤¤¦¤È¡¢subnet-mask ¥ª¥×¥·¥ç¥óʸ¤Ï¡¢
+subnet ʸ¤ÇÀë¸À¤µ¤ì¤¿¥µ¥Ö¥Í¥Ã¥È¥Þ¥¹¥¯¤è¤êÍ¥À褵¤ì¤ë¤«¤é¤Ç¤¹¡£
+.PP
+.\"O .B The
+.I range
+.\"O .B statement
+.B ʸ
+.PP
+.nf
+ \fBrange\fR [ \fBdynamic-bootp\fR ] \fIlow-address\fR [ \fIhigh-address\fR]\fB;\fR
+.fi
+.PP
+.\"O For any subnet on which addresses will be assigned dynamically, there
+.\"O must be at least one \fIrange\fR statement. The range statement
+.\"O gives the lowest and highest IP addresses in a range. All IP
+.\"O addresses in the range should be in the subnet in which the
+.\"O \fIrange\fR statement is declared. The \fIdynamic-bootp\fR flag may
+.\"O be specified if addresses in the specified range may be dynamically
+.\"O assigned to BOOTP clients as well as DHCP clients. When specifying a
+.\"O single address, \fIhigh-address\fR can be omitted.
+ưŪ¤Ë³ä¤êÅö¤Æ¤é¤ì¤ë¥¢¥É¥ì¥¹¤ò´Þ¤à¥µ¥Ö¥Í¥Ã¥È¤Ç¤Ï¡¢
+¾¯¤Ê¤¯¤È¤â \fIrange\fR ʸ¤ò°ì¤Ä»ØÄꤷ¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
+range ʸ¤Ë¤Ï IP ¥¢¥É¥ì¥¹¤ÎÈϰϤκǾ®ÃÍ¡¦ºÇÂçÃͤòÍ¿¤¨¤Þ¤¹¡£
+¤½¤ÎÈϰϤËÆþ¤ë IP ¥¢¥É¥ì¥¹¤Î¤¹¤Ù¤Æ¤Ï¡¢
+\fIrange\fR ʸ¤¬Àë¸À¤µ¤ì¤¿¥µ¥Ö¥Í¥Ã¥È¤ÎÃæ¤ËÆþ¤Ã¤Æ¤¤¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£
+»ØÄꤷ¤¿ÈϰϤΥ¢¥É¥ì¥¹¤ò DHCP ¥¯¥é¥¤¥¢¥ó¥È¤È
+BOOTP ¥¯¥é¥¤¥¢¥ó¥È¤ÎξÊý¤Ë³ä¤êÅö¤Æ¤ÆÎɤ¤¾ì¹ç¤Ï¡¢
+\fIdynamic-bootp\fR ¥Õ¥é¥°¤ò»ØÄꤷ¤Þ¤¹¡£
+¥¢¥É¥ì¥¹ 1 ¤Ä¤À¤±¤ò³ä¤êÅö¤Æ¤ë¾ì¹ç¤Ï¡¢
+\fIhigh-address\fR ¤Ï¾Êά¤Ç¤¤Þ¤¹¡£
+.PP
+.\"O .B The
+.I host
+.\"O .B statement
+.B ʸ
+.PP
+.nf
+ \fBhost\fR \fIhostname\fR {
+ [ \fIparameters\fR ]
+ [ \fIdeclarations\fR ]
+ \fB}\fR
+.fi
+.PP
+.\"O There must be at least one
+.\"O .B host
+.\"O statement for every BOOTP client that is to be served.
+.\"O .B host
+.\"O statements may also be specified for DHCP clients, although this is
+.\"O not required unless booting is only enabled for known hosts.
+¥µ¡¼¥Ó¥¹ÂоݤȤʤë BOOTP ¥¯¥é¥¤¥¢¥ó¥È¤Ë¤Ï¡¢¤½¤ì¤¾¤ì
+.B host
+¤¬ºÇÄã¤Ò¤È¤Ä¤Å¤ÄɬÍפˤʤê¤Þ¤¹¡£
+DHCP ¥¯¥é¥¤¥¢¥ó¥È¤ËÂФ·¤Æ¤â
+.B host
+ʸ¤Ï»ØÄê¤Ç¤¤Þ¤¹¤¬¡¢
+ÁÇÀ¤Î¤ï¤«¤é¤Ê¤¤¥Û¥¹¥È¤Ë¤Ï¥Ö¡¼¥È¤òµö²Ä¤·¤Ê¤¤¤è¤¦¤ÊÀßÄê¤Ç¤Ê¤±¤ì¤Ð¡¢
+»ØÄꤷ¤Ê¤¯¤Æ¤â¤«¤Þ¤¤¤Þ¤»¤ó¡£
+.PP
+.\"O If it is desirable to be able to boot a DHCP or BOOTP
+.\"O client on more than one subnet with fixed addresses, more than one
+.\"O address may be specified in the
+.\"O .I fixed-address
+.\"O parameter, or more than one
+.\"O .B host
+.\"O statement may be specified.
+¤¢¤ë DHCP ¥¯¥é¥¤¥¢¥ó¥È¤ä BOOTP ¥¯¥é¥¤¥¢¥ó¥È¤ò¡¢
+Ê£¿ô¤Î¥µ¥Ö¥Í¥Ã¥È¤Ë¤ª¤¤¤Æ¸ÇÄꥢ¥É¥ì¥¹¤Ç¥Ö¡¼¥È¤µ¤»¤¿¤¤¾ì¹ç¤Ë¤Ï¡¢
+.I fixed-address
+¥Ñ¥é¥á¡¼¥¿¤ËÊ£¿ô¤Î¥¢¥É¥ì¥¹¤ò»ØÄꤹ¤ë¤«¡¢
+¤¢¤ë¤¤¤Ï
+.B host
+ʸ¤òÊ£¿ô»ØÄꤷ¤Þ¤¹¡£
+.PP
+.\"O If client-specific boot parameters must change based on the network
+.\"O to which the client is attached, then multiple
+.\"O .B host
+.\"O statements should
+.\"O be used.
+¥¯¥é¥¤¥¢¥ó¥È¸ÇͤΥ֡¼¥È¥Ñ¥é¥á¡¼¥¿¤ò¡¢
+Àܳ¤µ¤ì¤¿¥Í¥Ã¥È¥ï¡¼¥¯¤Ë¤è¤Ã¤ÆÂ夨¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¾ì¹ç¤Ë¤Ï¡¢
+.B host
+ʸ¤òÊ£¿ôÍѤ¤¤ë¤Ù¤¤Ç¤¹¡£
+.PP
+.\"O If a client is to be booted using a fixed address if it's
+.\"O possible, but should be allocated a dynamic address otherwise, then a
+.\"O .B host
+.\"O statement must be specified without a
+.\"O .B fixed-address
+.\"O clause.
+.\"O .I hostname
+.\"O should be a name identifying the host. If a \fIhostname\fR option is
+.\"O not specified for the host, \fIhostname\fR is used.
+²Äǽ¤Ê¾ì¹ç¤Ë¤Ï¥¯¥é¥¤¥¢¥ó¥È¤ò¸ÇÄꥢ¥É¥ì¥¹¤Ç¥Ö¡¼¥È¤µ¤»¤¿¤¤¤¬¡¢
+¤½¤ì¤¬¤Ç¤¤Ê¤±¤ì¤ÐưŪ¤Ê¥¢¥É¥ì¥¹¤ò³ä¤êÅö¤Æ¤¿¤¤¡¢¤È¤¤¤¦¾ì¹ç¤Ë¤Ï¡¢
+.B host
+ʸ¤ÎÆâÉô¤Ç¤Ï
+.B fixed-address
+ʸ¤ò»ØÄꤷ¤Ê¤¤¤è¤¦¤Ë¤·¤Þ¤¹¡£
+.PP
+.\"O \fIHost\fR declarations are matched to actual DHCP or BOOTP clients
+.\"O by matching the \fRdhcp-client-identifier\fR option specified in the
+.\"O \fIhost\fR declaration to the one supplied by the client, or, if the
+.\"O \fIhost\fR declaration or the client does not provide a
+.\"O \fRdhcp-client-identifier\fR option, by matching the \fIhardware\fR
+.\"O parameter in the \fIhost\fR declaration to the network hardware
+.\"O address supplied by the client. BOOTP clients do not normally
+.\"O provide a \fIdhcp-client-identifier\fR, so the hardware address must
+.\"O be used for all clients that may boot using the BOOTP protocol.
+\fIhost\fR Àë¸À¤ò¼ÂºÝ¤Î DHCP ¥¯¥é¥¤¥¢¥ó¥È¤ä
+BOOTP ¥¯¥é¥¤¥¢¥ó¥È¤Ë¥Þ¥Ã¥Á¤µ¤»¤ëºÝ¤Ë¤Ï¡¢
+\fIhost\fR Àë¸À¤ÎÆâÉô¤Ç»ØÄꤵ¤ì¤¿
+\fIdhcp-client-identifier\fR ¥ª¥×¥·¥ç¥ó¤¬¡¢
+¥¯¥é¥¤¥¢¥ó¥È¤¬ÅϤ·¤Æ¤¤¿¼±Ê̻ҤȥޥåÁ¤¹¤ë¤«¤ò³Îǧ¤·¤Þ¤¹¡£
+¤â¤· \fIhost\fR Àë¸À¤ÎÆâÉô¤Ë \fIdhcp-client-identifier\fR ¤¬¤Ê¤«¤Ã¤¿¤ê¡¢
+¥¯¥é¥¤¥¢¥ó¥È¤¬¤³¤Î¼±Ê̻ҤòÅϤ·¤Æ¤³¤Ê¤«¤Ã¤¿¾ì¹ç¤Ë¤Ï¡¢
+\fIhost\fR Àë¸À¤ÎÆâÉô¤Ç»ØÄꤵ¤ì¤¿
+\fIhardware\fR ¥Ñ¥é¥á¡¼¥¿¤¬¡¢
+¥¯¥é¥¤¥¢¥ó¥È¤¬ÅϤ·¤Æ¤¤¿¥Ï¡¼¥É¥¦¥§¥¢¥¢¥É¥ì¥¹¤È¥Þ¥Ã¥Á¤¹¤ë¤«¤ò³Îǧ¤·¤Þ¤¹¡£
+BOOTP ¥¯¥é¥¤¥¢¥ó¥È¤ÏÄ̾ï
+\fIdhcp-client-identifier\fR ¤òÅϤµ¤Ê¤¤¤Î¤Ç¡¢
+BOOTP ¥×¥í¥È¥³¥ë¤Ç¥Ö¡¼¥È¤µ¤»¤ë¥¯¥é¥¤¥¢¥ó¥È¤ËÂФ·¤Æ¤Ï¡¢
+ɬ¤º¥Ï¡¼¥É¥¦¥§¥¢¥¢¥É¥ì¥¹¤òÍѤ¤¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
+.PP
+.\"O .B The
+.I group
+.\"O .B statement
+.B ʸ
+.PP
+.nf
+ \fBgroup\fR {
+ [ \fIparameters\fR ]
+ [ \fIdeclarations\fR ]
+ \fB}\fR
+.fi
+.PP
+.\"O The group statement is used simply to apply one or more parameters to
+.\"O a group of declarations. It can be used to group hosts, shared
+.\"O networks, subnets, or even other groups.
+.B group
+ʸ¤Ï¡¢¤Ê¤ó¤é¤«¤Î¥Ñ¥é¥á¡¼¥¿¤òÀë¸À¤Î¥°¥ë¡¼¥×¤ËŬÍѤ¹¤ë¤¿¤á¤ËÍѤ¤¤Þ¤¹¡£
+¥Û¥¹¥È¡¢¶¦Í¥Í¥Ã¥È¥ï¡¼¥¯¡¢¥µ¥Ö¥Í¥Ã¥ÈÅù¤ò¤Þ¤È¤á¤¿¤ê¡¢
+¤¢¤ë¤¤¤Ï¾¤Î¥°¥ë¡¼¥×¤ò¤Þ¤È¤á¤ë¤³¤È¤â¤Ç¤¤Þ¤¹¡£
+.\"O .SH REFERENCE: ALLOW and DENY
+.SH ¥ê¥Õ¥¡¥ì¥ó¥¹: ALLOW ¤È DENY
+.PP
+.\"O The
+.\"O .I allow
+.\"O and
+.\"O .I deny
+.\"O statements can be used to control the behaviour of dhcpd to various
+.\"O sorts of requests.
+.I allow
+ʸ¤È
+.I deny
+ʸ¤ò»È¤¦¤È¡¢
+¤¤¤í¤¤¤í¤ÊÍ×µá¤ËÂФ¹¤ë dhcpd ¤Î¿¶¤ëÉñ¤¤¤òÀ©¸æ¤Ç¤¤Þ¤¹¡£
+.PP
+.PP
+.\"O .B The
+.I unknown-clients
+.\"O .B keyword
+.B ¥¡¼¥ï¡¼¥É
+.PP
+ \fBallow unknown-clients;\fR
+ \fBdeny unknown-clients;\fR
+.PP
+.\"O The \fBunknown-clients\fR flag is used to tell dhcpd whether
+.\"O or not to dynamically assign addresses to unknown clients. Dynamic
+.\"O address assignment to unknown clients is \fBallow\fRed by default.
+.\fBunkown-clients\fR ¥Õ¥é¥°¤Ï¡¢
+ÁÇÀ¤Î¤ï¤«¤é¤Ê¤¤ (unkown ¤Ê) ¥¯¥é¥¤¥¢¥ó¥È¤ËưŪ¤Ë¥¢¥É¥ì¥¹¤ò³ä¤êÅö¤Æ¤ë¤«¤É¤¦¤«¤ò
+dhcpd ¤Ë»Ø¼¨¤·¤Þ¤¹¡£
+¥Ç¥Õ¥©¥ë¥È¤Ç¤Ï unkown ¤Ê¥¯¥é¥¤¥¢¥ó¥È¤Ø¤ÎưŪ¥¢¥É¥ì¥¹³ä¤êÅö¤Æ¤Ï
+\fBallow\fR (µö²Ä) ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
+.PP
+.\"O .B The
+.I bootp
+.\"O .B keyword
+.B ¥¡¼¥ï¡¼¥É
+.PP
+ \fBallow bootp;\fR
+ \fBdeny bootp;\fR
+.PP
+.\"O The \fBbootp\fR flag is used to tell dhcpd whether
+.\"O or not to respond to bootp queries. Bootp queries are \fBallow\fRed
+.\"O by default.
+\fBbootp\fR ¥Õ¥é¥°¤Ï¡¢
+bootp ¥¯¥¨¥ê (Ì䤤¹ç¤ï¤») ¤ËÅú¤¨¤ë¤«¤É¤¦¤«¤ò
+dhcpd ¤Ë»Ø¼¨¤·¤Þ¤¹¡£
+¥Ç¥Õ¥©¥ë¥È¤Ç¤Ï bootp ¥¯¥¨¥ê¤Ï
+\fBallow\fR (µö²Ä) ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
+.PP
+.\"O .B The
+.I booting
+.\"O .B keyword
+.B ¥¡¼¥ï¡¼¥É
+.PP
+ \fBallow booting;\fR
+ \fBdeny booting;\fR
+.PP
+.\"O The \fBbooting\fR flag is used to tell dhcpd whether or not to respond
+.\"O to queries from a particular client. This keyword only has meaning
+.\"O when it appears in a host declaration. By default, booting is
+.\"O \fBallow\fRed, but if it is disabled for a particular client, then
+.\"O that client will not be able to get and address from the DHCP server.
+\fBbooting\fR ¥Õ¥é¥°¤Ï¡¢
+ÆÃÄê¤Î¥¯¥é¥¤¥¢¥ó¥È¤«¤é¤Î¥¯¥¨¥ê¤ËÅú¤¨¤ë¤«¤É¤¦¤«¤ò
+dhcpd ¤Ë»Ø¼¨¤·¤Þ¤¹¡£
+¤³¤Î¥¡¼¥ï¡¼¥É¤Ï¡¢host Àë¸À¤ÎÆâÉô¤ËÃÖ¤«¤ì¤¿¾ì¹ç¤Ë¤Î¤ß°ÕÌ£¤ò»ý¤Á¤Þ¤¹¡£
+¥Ç¥Õ¥©¥ë¥È¤Ç¤Ï booting ¤Ï
+\fBallow\fR (µö²Ä) ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
+¤·¤«¤·¤³¤ì¤òÆÃÄê¤Î¥¯¥é¥¤¥¢¥ó¥È¤ËÂФ·¤Æ̵¸ú¤Ë¤¹¤ë¤È¡¢
+¤½¤Î¥¯¥é¥¤¥¢¥ó¥È¤Ï¤³¤Î DHCP ¥µ¡¼¥Ð¤«¤é¤Ï¥¢¥É¥ì¥¹¤ò¼èÆÀ¤Ç¤¤Ê¤¯¤Ê¤ê¤Þ¤¹¡£
+.\"O .SH REFERENCE: PARAMETERS
+.SH ¥ê¥Õ¥¡¥ì¥ó¥¹: ¥Ñ¥é¥á¡¼¥¿
+.PP
+.\"O .B The
+.I default-lease-time
+.\"O .B statement
+.B ʸ
+.PP
+ \fBdefault-lease-time\fR \fItime\fR\fB;\fR
+.PP
+.\"O .I Time
+.\"O should be the length in seconds that will be assigned to a lease if
+.\"O the client requesting the lease does not ask for a specific expiration
+.\"O time.
+.I time
+¤ÏÉÃñ°Ì¤Î»þ´Ö¤Ç¡¢
+Âߤ·½Ð¤·¤òÍ׵ᤷ¤Æ¤¤¤ë¥¯¥é¥¤¥¢¥ó¥È¤¬Æä˴ü¸Â¤òµá¤á¤Ê¤±¤ì¤Ð¡¢
+¤³¤Î»þ´Ö¤¬Âߤ·½Ð¤·»þ´Ö¤Ë¤Ê¤ê¤Þ¤¹¡£
+.PP
+.\"O .B The
+.I max-lease-time
+.\"O .B statement
+.B ʸ
+.PP
+ \fBmax-lease-time\fR \fItime\fR\fB;\fR
+.PP
+.\"O .I Time
+.\"O should be the maximum length in seconds that will be assigned to a
+.\"O lease if the client requesting the lease asks for a specific
+.\"O expiration time.
+.I time
+¤ÏÉÃñ°Ì¤Î»þ´Ö¤Ç¡¢
+Âߤ·½Ð¤·¤òÍ׵ᤷ¤Æ¤¤¤ë¥¯¥é¥¤¥¢¥ó¥È¤¬´ü¸Â¤òµá¤á¤¿¾ì¹ç¤Ë¡¢
+³ä¤êÅö¤Æ²Äǽ¤ÊºÇÂç¤ÎÂ߽лþ´Ö¤Ç¤¹¡£
+.PP
+.\"O .B The
+.I hardware
+.\"O .B statement
+.B ʸ
+.PP
+ \fBhardware\fR \fIhardware-type\fR \fIhardware-address\fR\fB;\fR
+.PP
+.\"O In order for a BOOTP client to be recognized, its network hardware
+.\"O address must be declared using a \fIhardware\fR clause in the
+.\"O .I host
+.\"O statement.
+.\"O .I hardware-type
+.\"O must be the name of a physical hardware interface type. Currently,
+.\"O only the
+.\"O .B ethernet
+.\"O and
+.\"O .B token-ring
+.\"O types are recognized, although support for a
+.\"O .B fddi
+.\"O hardware type (and others) would also be desirable.
+.\"O The
+.\"O .I hardware-address
+.\"O should be a set of hexadecimal octets (numbers from 0 through ff)
+.\"O seperated by colons. The \fIhardware\fR statement may also be used
+.\"O for DHCP clients.
+BOOTP ¥¯¥é¥¤¥¢¥ó¥È¤¬Ç§¼±¤µ¤ì¤ë¤¿¤á¤Ë¤Ï¡¢
+.I host
+ʸ¤ÎÆâÉô¤Ç
+.I hardware
+»ØÄê¤Ë¤è¤Ã¤Æ¤½¤Î¥Í¥Ã¥È¥ï¡¼¥¯¥Ï¡¼¥É¥¦¥§¥¢¥¢¥É¥ì¥¹¤¬
+»ØÄꤵ¤ì¤Æ¤¤¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
+.I hardware-type
+¤ÏʪÍý¥Ï¡¼¥É¥¦¥§¥¢¥¤¥ó¥¿¡¼¥Õ¥§¡¼¥¹¤Î·Á¼°Ì¾¤Ç¤¹¡£
+¸½ºß¤Î¤È¤³¤í¤Ï
+.B ethernet
+¤È
+.B token-ring
+¤À¤±¤¬Ç§¼±¤µ¤ì¤Þ¤¹
+.RB ( fddi
+¤Ê¤É¤Î¥Ï¡¼¥É¥¦¥§¥¢·¿¤âǧ¼±¤µ¤ì¤ë¤ÈÎɤ¤¤Î¤Ç¤·¤ç¤¦¤¬)¡£
+.I hardware-address
+¤Ï 16 ¿Ê¥ª¥¯¥Æ¥Ã¥È (0 ¤«¤é ff ¤Þ¤Ç¤Î¿ôÃÍ) ¤Î¥»¥Ã¥È¤Ç¡¢
+¶èÀÚ¤ê¤Ï¥³¥í¥ó¤Ç¤¹¡£
+.I hardware
+ʸ¤Ï DHCP ¥¯¥é¥¤¥¢¥ó¥È¤Ë¤âÍѤ¤¤ë¤³¤È¤¬¤Ç¤¤Þ¤¹¡£
+.PP
+.\"O .B The
+.I filename
+.\"O .B statement
+.B ʸ
+.PP
+ \fBfilename\fR \fB"\fR\fIfilename\fR\fB";\fR
+.PP
+.\"O The \fIfilename\fR statement can be used to specify the name of the
+.\"O initial boot file which is to be loaded by a client. The
+.\"O .I filename
+.\"O should be a filename recognizable to whatever file transfer protocol
+.\"O the client can be expected to use to load the file.
+.B filename
+ʸ¤Ï¥¯¥é¥¤¥¢¥ó¥È¤Ë¥í¡¼¥É¤µ¤»¤ë½é´ü¥Ö¡¼¥È¥Õ¥¡¥¤¥ë¤Î»ØÄê¤Ë»È¤¤¤Þ¤¹¡£
+.I filename
+¤Ï¥¯¥é¥¤¥¢¥ó¥È¤¬»È¤¦¤Ç¤¢¤í¤¦¥Õ¥¡¥¤¥ëžÁ÷¥×¥í¥È¥³¥ë¤Ç
+ǧ¼±¤µ¤ì¤ë¥Õ¥¡¥¤¥ë̾¤Ç¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
+.PP
+.\"O .B The
+.I server-name
+.\"O .B statement
+.B ʸ
+.PP
+ \fBserver-name\fR \fB"\fR\fIname\fR\fB";\fR
+.PP
+.\"O The \fIserver-name\fR statement can be used to inform the client of
+.\"O the name of the server from which it is booting. \fIName\fR should
+.\"O be the name that will be provided to the client.
+.B server-name
+ʸ¤Ï¥¯¥é¥¤¥¢¥ó¥È¤ËÀܳÃæ¤Î¥µ¡¼¥Ð¤Î̾Á°¤òÅÁ¤¨¤ë¤¿¤á¤ËÍѤ¤¤Þ¤¹¡£
+.I name
+¤Ï¥¯¥é¥¤¥¢¥ó¥È¤ËÅϤµ¤ì¤ë̾Á°¤Ç¤¹¡£
+.PP
+.\"O .B The
+.I next-server
+.\"O .B statement
+.B ʸ
+.PP
+ \fBnext-server\fR \fIserver-name\fR\fB;\fR
+.PP
+.\"O The \fInext-server\fR statement is used to specify the host address of
+.\"O the server from which the initial boot file (specified in the
+.\"O \fIfilename\fR statement) is to be loaded. \fIServer-name\fR should
+.\"O be a numeric IP address or a domain name. If no \fInext-server\fR
+.\"O parameter applies to a given client, the DHCP server's IP address is
+.\"O used.
+.B next-server
+ʸ¤Ï½é´ü¥Ö¡¼¥È¥Õ¥¡¥¤¥ë
+.RI ( filename
+ʸ¤Ç»ØÄꤷ¤¿¤â¤Î) ¤ò¥í¡¼¥É¤¹¤ë¥µ¡¼¥Ð¤Î¥Û¥¹¥È¥¢¥É¥ì¥¹¤ò»ØÄꤹ¤ë¤¿¤á¤Ë»È¤¤¤Þ¤¹¡£
+.I server-name
+¤Ï¿ôÃͤΠIP ¥¢¥É¥ì¥¹¤«¥É¥á¥¤¥ó̾¤Ç¤¹¡£
+Àܳ¤·¤Æ¤¤¿¥¯¥é¥¤¥¢¥ó¥È¤ËÂФ·¤ÆÍ¿¤¨¤ë¤Ù¤
+.B next-server
+¥Ñ¥é¥á¡¼¥¿¤¬¤Ê¤±¤ì¤Ð¡¢DHCP ¥µ¡¼¥Ð¤Î IP ¥¢¥É¥ì¥¹¤¬ÍѤ¤¤é¤ì¤Þ¤¹¡£
+.PP
+.\"O .B The
+.I fixed-address
+.\"O .B statement
+.B ʸ
+.PP
+ \fBfixed-address\fR \fIaddress\fR [\fB,\fR \fIaddress\fR ... ]\fB;\fR
+.PP
+.\"O The \fIfixed-address\fR statement is used to assign one or more fixed
+.\"O IP addresses to a client. It should only appear in a \fIhost\fR
+.\"O declaration. If more than one address is supplied, then when the
+.\"O client boots, it will be assigned the address which corresponds to the
+.\"O network on which it is booting. If none of the addresses in the
+.\"O \fIfixed-address\fR statement are on the network on which the client
+.\"O is booting, that client will not match the \fIhost\fR declaration
+.\"O containing that \fIfixed-address\fR statement. Each \fIaddress\fR
+.\"O should be either an IP address or a domain name which resolves to one
+.\"O or more IP addresses.
+.B fixed-address
+ʸ¤Ï¡¢¤¢¤ë¥¯¥é¥¤¥¢¥ó¥È¤ËÂФ·¤Æ°ì¤Ä¤Þ¤¿¤ÏÊ£¿ô¤Î
+IP ¥¢¥É¥ì¥¹¤ò³ä¤êÅö¤Æ¤ë¤¿¤á¤ËÍѤ¤¤Þ¤¹¡£
+.I host
+Àë¸À¤ÎÆâÉô¤Ç¤Î¤ßÍѤ¤¤é¤ì¤Þ¤¹¡£
+Ê£¿ô¤Î¥¢¥É¥ì¥¹¤¬»ØÄꤵ¤ì¤¿¾ì¹ç¤Ë¤Ï¡¢
+¤½¤Î¥¯¥é¥¤¥¢¥ó¥È¤¬¥Ö¡¼¥È¤¹¤ë¥Í¥Ã¥È¥ï¡¼¥¯¤Ë½ê°¤¹¤ë¥¢¥É¥ì¥¹¤¬³ä¤êÅö¤Æ¤é¤ì¤Þ¤¹¡£
+¥¯¥é¥¤¥¢¥ó¥È¤¬¥Ö¡¼¥È¤¹¤ë¥Í¥Ã¥È¥ï¡¼¥¯¤Ë°¤¹¤ë¥¢¥É¥ì¥¹¤¬
+.B fixed-address
+ʸ¤Ë¤Ê¤¤¾ì¹ç¤Ï¡¢¤½¤Î¥¯¥é¥¤¥¢¥ó¥È¤Ï¤½¤Î
+.B fixed-address
+ʸ¤¬´Þ¤Þ¤ì¤ë
+.I host
+Àë¸À¤Ë¥Þ¥Ã¥Á¤·¤Ê¤¤¤³¤È¤Ë¤Ê¤ê¤Þ¤¹¡£³Æ
+.I address
+¤Ï IP ¥¢¥É¥ì¥¹¤«¡¢
+°ì¤Ä (¤Þ¤¿¤ÏÊ£¿ô) ¤Î IP ¥¢¥É¥ì¥¹¤Ë²ò·è¤µ¤ì¤ë¥É¥á¥¤¥ó̾¤Ç¤¹¡£
+.PP
+.\"O .B The
+.I dynamic-bootp-lease-cutoff
+.\"O .B statement
+.B ʸ
+.PP
+ \fBdynamic-bootp-lease-cutoff\fR \fIdate\fR\fB;\fR
+.PP
+.\"O The \fIdynamic-bootp-lease-cutoff\fR statement sets the ending time
+.\"O for all leases assigned dynamically to BOOTP clients. Because BOOTP
+.\"O clients do not have any way of renewing leases, and don't know that
+.\"O their leases could expire, by default dhcpd assignes infinite leases
+.\"O to all BOOTP clients. However, it may make sense in some situations
+.\"O to set a cutoff date for all BOOTP leases - for example, the end of a
+.\"O school term, or the time at night when a facility is closed and all
+.\"O machines are required to be powered off.
+.I dynamic-bootp-lease-cutoff
+ʸ¤Ï¡¢Æ°Åª¤Ë³ä¤êÅö¤Æ¤¿
+BOOTP ¥¯¥é¥¤¥¢¥ó¥È¤Ø¤Î¤¹¤Ù¤Æ¤ÎÂߤ·½Ð¤·¤ò½ªÎ»¤µ¤»¤ë»þ¹ï¤òÀßÄꤷ¤Þ¤¹¡£
+BOOTP ¥¯¥é¥¤¥¢¥ó¥È¤ÏÂߤ·½Ð¤·¤ò¹¹¿·¤¹¤ëµ¡¹½¤ò»ý¤¿¤º¡¢
+¤Þ¤¿Âߤ·½Ð¤·¤¬¤¤¤Ä´ü¸ÂÀÚ¤ì¤Ë¤Ê¤ë¤«¤òÃΤé¤Ê¤¤¤Î¤Ç¡¢
+¥Ç¥Õ¥©¥ë¥È¤Ç¤Ï dhcpd ¤Ï BOOTP ¥¯¥é¥¤¥¢¥ó¥È¤Ø¤Ï̵´ü¸Â¤ÎÂߤ·½Ð¤·¤ò¹Ô¤¤¤Þ¤¹¡£
+¤·¤«¤·¡¢¤¢¤ë¾ì¹ç¤Ë¤Ï BOOTP ¤ÎÂߤ·½Ð¤·Ää»ß¤Ë°ÕÌ£¤¬¤¢¤ë¤«¤â¤·¤ì¤Þ¤»¤ó¡£
+Î㤨¤Ð³Ø´ü¤ÎºÇ¸å¤ä¡¢ÌëÃæ¤Î¤¢¤ë»þ´Ö¤Ë¤Ê¤ë¤È»ÜÀߤ¬ÊĤޤäơ¢
+¤¹¤Ù¤Æ¤Î¥Þ¥·¥ó¤¬ÅŸ»Ää»ß¤Ë¤Ê¤ë¤è¤¦¤Ê¾ì¹ç¤Ê¤É¤Ç¤¹¡£
+.PP
+.\"O .I Date
+.\"O should be the date on which all assigned BOOTP leases will end. The
+.\"O date is specified in the form:
+.I date
+¤Ï³ä¤êÅö¤Æ¤é¤ì¤¿ BOOTP Âߤ·½Ð¤·¤Î¤¹¤Ù¤Æ¤¬½ªÎ»¤¹¤ë»þ¹ï¤Ç¤¹¡£
+date ¤Ï°Ê²¼¤Î½ñ¼°¤Ç»ØÄꤷ¤Þ¤¹¡£
+.PP
+.ce 1
+W YYYY/MM/DD HH:MM:SS
+.PP
+.\"O W is the day of the week expressed as a number
+.\"O from zero (Sunday) to six (Saturday). YYYY is the year, including the
+.\"O century. MM is the month expressed as a number from 1 to 12. DD is
+.\"O the day of the month, counting from 1. HH is the hour, from zero to
+.\"O 23. MM is the minute and SS is the second. The time is always in
+.\"O Universal Coordinated Time (UTC), not local time.
+W ¤ÏÍËÆü¤ò¿ôÃͤǻØÄꤷ¤¿¤â¤Î¤Ç¡¢0 (ÆüÍËÆü) ¤«¤é 6 (ÅÚÍËÆü) ¤Þ¤Ç¤Ç¤¹¡£
+YYYY ¤Ïǯ¤Ç¡¢À¤µª¤Î·å¤â»ØÄꤷ¤Þ¤¹¡£
+MM ¤Ï·î¤ò¿ôÃͤǻØÄꤷ¤¿¤â¤Î¤Ç¡¢ 1 ¤«¤é 12 ¥Þ¥Ç¤Ç¤¹¡£
+DD ¤Ï·îÆâÆü¤ò¿ôÃͤǻØÄꤷ¤¿¤â¤Î¤Ç¡¢ 1 ¤«¤é¿ô¤¨¤Þ¤¹¡£
+HH ¤Ï»þ´Ö¤Ç¡¢0 ¤«¤é 23 ¤Þ¤Ç¤Ç¤¹¡£
+¼¡¤Î MM ¤Ïʬ¤Ç¡¢SS ¤ÏÉäǤ¹¡£
+»þ¹ï¤Ï¾ï¤Ë¶¨ÄêÀ¤³¦»þ (UTC) ¤Ç»ØÄꤷ¤Þ¤¹ (ÃÏÊý»þ¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó)¡£
+.PP
+.\"O .B The
+.I dynamic-bootp-lease-length
+.\"O .B statement
+.B ʸ
+.PP
+ \fBdynamic-bootp-lease-length\fR \fIlength\fR\fB;\fR
+.PP
+.\"O The \fIdynamic-bootp-lease-length\fR statement is used to set the
+.\"O length of leases dynamically assigned to BOOTP clients. At some
+.\"O sites, it may be possible to assume that a lease is no longer in
+.\"O use if its holder has not used BOOTP or DHCP to get its address within
+.\"O a certain time period. The period is specified in \fIlength\fR as a
+.\"O number of seconds. If a client reboots using BOOTP during the
+.\"O timeout period, the lease duration is reset to \fIlength\fR, so a
+.\"O BOOTP client that boots frequently enough will never lose its lease.
+.\"O Needless to say, this parameter should be adjusted with extreme
+.\"O caution.
+.B dynamic-bootp-lease-length
+ʸ¤Ï BOOTP ¥¯¥é¥¤¥¢¥ó¥È¤Ø¤ÎưŪ³ä¤êÅö¤Æ¤ÎÂߤ·½Ð¤·´ü´Ö¤ÎÀßÄê¤ËÍѤ¤¤Þ¤¹¡£
+¥µ¥¤¥È¤Ë¤è¤Ã¤Æ¤Ï¡¢°ìÅÙ¥¢¥É¥ì¥¹¤òÂߤ·½Ð¤·¤¿¥¯¥é¥¤¥¢¥ó¥È¤«¤é
+°ìÄê¤Î´Ö BOOTP ¤ä DHCP ¤Ç¤ÎºÆ³ä¤êÅö¤ÆÍ׵᤬¤Ê¤±¤ì¤Ð¡¢
+¤½¤Î¥¢¥É¥ì¥¹¤Ï¤â¤¦»È¤ï¤ì¤Ê¤¤¡¢¤È¤ß¤Ê¤¹¤³¤È¤¬²Äǽ¤«¤â¤·¤ì¤Þ¤»¤ó¡£
+Â߽е¡´Ø¤Ï
+.I length
+¤ËÉÃñ°Ì¤Ç»ØÄꤷ¤Þ¤¹¡£
+¤½¤Î´ü´Ö¤Î¤¦¤Á¤Ë¥¯¥é¥¤¥¢¥ó¥È¤¬ BOOTP ¤òÍѤ¤¤ÆºÆ¥Ö¡¼¥È¤¹¤ë¤È¡¢
+Âߤ·½Ð¤·´ü´Ö¤â
+.I length
+¤Ë¥ê¥»¥Ã¥È¤µ¤ì¤Þ¤¹¡£
+¤·¤¿¤¬¤Ã¤ÆÉÑÈˤ˥֡¼¥È¤¹¤ë BOOTP ¥¯¥é¥¤¥¢¥ó¥È¤Ï¡¢
+³ä¤êÅö¤Æ¤é¤ì¤¿¥¢¥É¥ì¥¹¤ò¤º¤Ã¤ÈÊÝ»ý¤·Â³¤±¤Þ¤¹¡£
+¸À¤¦¤Þ¤Ç¤â¤¢¤ê¤Þ¤»¤ó¤¬¡¢¤³¤Î¥Ñ¥é¥á¡¼¥¿¤ÏºÙ¿´¤ÎÃí°Õ¤òʧ¤Ã¤Æ·è¤á¤Æ¤¯¤À¤µ¤¤¡£
+.PP
+.\"O .B The
+.I get-lease-hostnames
+.\"O .B statement
+.B ʸ
+.PP
+ \fBget-lease-hostnames\fR \fIflag\fR\fB;\fR
+.PP
+.\"O The \fIget-lease-hostnames\fR statement is used to tell dhcpd whether
+.\"O or not to look up the domain name corresponding to the IP address of
+.\"O each address in the lease pool and use that address for the DHCP
+.\"O \fIhostname\fR option. If \fIflag\fR is true, then this lookup is
+.\"O done for all addresses in the current scope. By default, or if
+.\"O \fIflag\fR is false, no lookups are done.
+.B get-lease-hostnames
+ʸ¤Ï¡¢Âߤ·½Ð¤·ÍѤ˥ס¼¥ë¤µ¤ì¤Æ¤¤¤ë
+IP ¥¢¥É¥ì¥¹¤Î¥É¥á¥¤¥ó̾¤ò°ú¤¡¢
+¤½¤Î¥¢¥É¥ì¥¹¤ò DHCP
+.I hostname
+¥ª¥×¥·¥ç¥ó¤ËÍѤ¤¤ë¤«¤É¤¦¤«¤ò dhcpd ¤ËÅÁ¤¨¤ë¤¿¤á¤ËÍѤ¤¤Þ¤¹¡£
+.I flag
+¤¬¿¿¤Ê¤é¤Ð¡¢¸½ºß¤Î¥¹¥³¡¼¥×¤Ë¤¢¤ë¤¹¤Ù¤Æ¤Î¥¢¥É¥ì¥¹¤ËÂФ·¤Æ
+¤³¤Î̾Á°°ú¤¤¬¼Â¹Ô¤µ¤ì¤Þ¤¹¡£
+¥Ç¥Õ¥©¥ë¥È¤Ç¤Ï
+.I flag
+¤Ïµ¶¤Ç¡¢Ì¾Á°°ú¤¤Ï¹Ô¤ï¤ì¤Þ¤»¤ó¡£
+.PP
+.\"O .B The
+.I use-host-decl-names
+.\"O .B statement
+.B ʸ
+.PP
+ \fBuse-host-decl-names\fR \fIflag\fR\fB;\fR
+.PP
+.\"O If the \fIuse-host-decl-names\fR parameter is true in a given scope,
+.\"O then for every host declaration within that scope, the name provided
+.\"O for the host declaration will be supplied to the client as its
+.\"O hostname. So, for example,
+.I use-host-decl-names
+¥Ñ¥é¥á¡¼¥¿¤¬¤½¤ÎÃÖ¤«¤ì¤¿¥¹¥³¡¼¥×¤Ç¿¿ (true) ¤À¤È¡¢
+¤½¤Î¥¹¥³¡¼¥×¤ËÃÖ¤«¤ì¤¿¤¹¤Ù¤Æ¤Î host Àë¸À¤Ë¤ª¤¤¤Æ¡¢
+Àë¸À¤Ë»È¤ï¤ì¤¿Ì¾Á°¤¬¥Û¥¹¥È̾¤È¤·¤Æ¥¯¥é¥¤¥¢¥ó¥È¤ËÅϤµ¤ì¤Þ¤¹¡£
+¤·¤¿¤¬¤Ã¤ÆÎ㤨¤Ð¡¢
+.PP
+.nf
+ group {
+ use-host-decl-names on;
+
+ host joe {
+ hardware ethernet 08:00:2b:4c:29:32;
+ fixed-address joe.fugue.com;
+ }
+ }
+
+.\"O is equivalent to
+¤Ï¼¡¤ÈÁ´¤¯Æ±¤¸¤Ë¤Ê¤ê¤Þ¤¹¡£
+
+ host joe {
+ hardware ethernet 08:00:2b:4c:29:32;
+ fixed-address joe.fugue.com;
+ option host-name "joe";
+ }
+.fi
+.PP
+.\"O An \fIoption host-name\fR statement within a host declaration will
+.\"O override the use of the name in the host declaration.
+host Àë¸À¤ÎÆâÉô¤ËÃÖ¤«¤ì¤¿
+.I option host-name
+ʸ¤Ï¡¢Àë¸À¤ËÍѤ¤¤é¤ì¤¿Ì¾Á°¤è¤ê¤âÍ¥À褵¤ì¤Þ¤¹¡£
+.PP
+.\"HERE GOES
+.\"O .B The
+.I authoritative
+.\"O .B statement
+.B ʸ
+.PP
+ \fBauthoritative;\fR
+.PP
+ \fBnot authoritative;\fR
+.PP
+.\"O The DHCP server will normally assume that the configuration
+.\"O information about a given network segment is known to be correct and
+.\"O is authoritative. So if a client requests an IP address on a given
+.\"O network segment that the server knows is not valid for that segment,
+.\"O the server will respond with a DHCPNAK message, causing the client to
+.\"O forget its IP address and try to get a new one.
+Ä̾ï DHCP ¥µ¡¼¥Ð¤Ï¡¢¤¢¤ë¥Í¥Ã¥È¥ï¡¼¥¯¥»¥°¥á¥ó¥È¤ÎÀßÄê¾ðÊó¤Ï
+Àµ¤·¤¯¤«¤Ä¿®Íê¤Ç¤¤ë¤È¤ß¤Ê¤·¤Æ¤¤¤Þ¤¹¡£
+¤è¤Ã¤Æ¥¯¥é¥¤¥¢¥ó¥È¤¬¤¢¤ë¥Í¥Ã¥È¥ï¡¼¥¯¥»¥°¥á¥ó¥È¤Î IP ¥¢¥É¥ì¥¹¤òÍ׵ᤷ¤¿¤È¤¡¢
+¥µ¡¼¥Ð¤¬¤½¤ì¤¬¤½¤Î¥»¥°¥á¥ó¥È¤Ç¤ÏÀµ¤·¤¯¤Ê¤¤¤³¤È¤òÃΤäƤ¤¤ë¤È¡¢
+¥µ¡¼¥Ð¤Ï DHCPNAK ¥á¥Ã¥»¡¼¥¸¤òÊÖ¤·¤Þ¤¹¡£
+¤¹¤ë¤È¥¯¥é¥¤¥¢¥ó¥È¤Ï¤½¤Î IP ¥¢¥É¥ì¥¹¤ò˺¤ì¡¢
+¿·¤·¤¤¥¢¥É¥ì¥¹¤ò¼èÆÀ¤·¤è¤¦¤È¤·¤Þ¤¹¡£
+.PP
+.\"O If a DHCP server is being configured by somebody who is not the
+.\"O network administrator and who therefore does not wish to assert this
+.\"O level of authority, then the statement "not authoritative" should be
+.\"O written in the appropriate scope in the configuration file.
+DHCP ¥µ¡¼¥Ð¤¬¥Í¥Ã¥È¥ï¡¼¥¯´ÉÍý¼Ô¤Ç¤Ï¤Ê¤¤¿Í´Ö¤Ë¤è¤Ã¤ÆÀßÄꤵ¤ì¡¢
+¤è¤Ã¤Æ¤³¤Î¥ì¥Ù¥ë¤Î¸¢°Ò¤ò»ý¤¿¤»¤¿¤¯¤Ê¤¤¾ì¹ç¤Ë¤Ï¡¢
+ÀßÄê¥Õ¥¡¥¤¥ë¤ÎŬÀڤʥ¹¥³¡¼¥×¤Ë "not authoritative"
+¤È¤¤¤¦Ê¸¤òÆþ¤ì¤Æ¤ª¤¯¤ÈÎɤ¤¤Ç¤·¤ç¤¦¡£
+.PP
+.\"O Usually, writing \fBnot authoritative;\fR at the top level of the file
+.\"O should be sufficient. However, if a DHCP server is to be set up so
+.\"O that it is aware of some networks for which it is authoritative and
+.\"O some networks for which it is not, it may be more appropriate to
+.\"O declare authority on a per-network-segment basis.
+Ä̾ï¤Ï¡¢
+.B not authoritative
+¤ò¥Õ¥¡¥¤¥ë¤Î¥È¥Ã¥×¥ì¥Ù¥ë¤Ë½ñ¤¤¤Æ¤ª¤±¤Ð½½Ê¬¤Ç¤¹¡£
+¤·¤«¤·¡¢¤¢¤ë¥Í¥Ã¥È¥ï¡¼¥¯¤ËÂФ·¤Æ¤Ï¸¢°Ò¤ò»ý¤¿¤»¡¢
+Ê̤Υͥåȥ¥¯¤ËÂФ·¤Æ¤Ï»ý¤¿¤»¤Ê¤¤¤è¤¦¤Ë DHCP ¥µ¡¼¥Ð¤òÀßÄꤷ¤¿¤¤¾ì¹ç¤Ë¤Ï¡¢
+¥Í¥Ã¥È¥ï¡¼¥¯¥»¥°¥á¥ó¥Èñ°Ì¤Ç authority ¤òÀë¸À¤¹¤ë¤Û¤¦¤¬Îɤ¤¤Ç¤·¤ç¤¦¡£
+.PP
+.\"O Note that the most specific scope for which the concept of authority
+.\"O makes any sense is the physical network segment - either a
+.\"O shared-network statement or a subnet statement that is not contained
+.\"O within a shared-network statement. It is not meaningful to specify
+.\"O that the server is authoritative for some subnets within a shared
+.\"O network, but not authoritative for others, nor is it meaningful to
+.\"O specify that the server is authoritative for some host declarations
+.\"O and not others.
+authority ¤¬°ÕÌ£¤ò»ý¤Ä¥¹¥³¡¼¥×¤Ï¡¢ÊªÍý¥Í¥Ã¥È¥ï¡¼¥¯¥»¥°¥á¥ó¥È¤Îñ°Ì¤Ç¤¹¡£
+¤¹¤Ê¤ï¤Á shared-network ʸ¤«¡¢
+shared-network ʸ¤ÎÆâÉô¤Ë¤Ï¤Ê¤¤ subnet ʸ¤Ç¤¹¡£
+¶¦Í¥Í¥Ã¥È¥ï¡¼¥¯¤Ë°¤·¤Æ¤¤¤ë¥µ¥Ö¥Í¥Ã¥È¤Î°ìÉô¤Î¤ß¤ËÂФ·¤Æ
+¥µ¡¼¥Ð¤Ë¸¢°Ò¤ò»ý¤¿¤»¤Æ¤â°ÕÌ£¤Ï¤¢¤ê¤Þ¤»¤ó¡£
+¤Þ¤¿°ìÉô¤Î host Àë¸À¤ËÂФ·¤Æ¤Î¤ß¥µ¡¼¥Ð¤Ë¸¢°Ò¤ò»ý¤¿¤»¤Æ¤â¡¢
+Ʊ¤¸¤¯°ÕÌ£¤Ï¤¢¤ê¤Þ¤»¤ó¡£
+.PP
+.\"O .B The
+.I use-lease-addr-for-default-route
+.\"O .B statement
+.B ʸ
+.PP
+ \fBuse-lease-addr-for-default-route\fR \fIflag\fR\fB;\fR
+.PP
+.\"O If the \fIuse-lease-addr-for-default-route\fR parameter is true in a
+.\"O given scope, then instead of sending the value specified in the
+.\"O routers option (or sending no value at all), the IP address of the
+.\"O lease being assigned is sent to the client. This supposedly causes
+.\"O Win95 machines to ARP for all IP addresses, which can be helpful if
+.\"O your router is configured for proxy ARP.
+.B use-lease-addr-for-default-route
+¥Ñ¥é¥á¡¼¥¿¤¬¤½¤ÎÃÖ¤«¤ì¤¿¥¹¥³¡¼¥×¤Ç¿¿¤À¤È¡¢
+routers ¥ª¥×¥·¥ç¥ó¤Ç»ØÄꤷ¤¿ÃͤòÁ÷¤ë (¤¢¤ë¤¤¤ÏÃͤòÁ´¤¯Á÷¤é¤Ê¤¤)
+Âå¤ï¤ê¤Ë¡¢³ä¤êÅö¤Æ¤è¤¦¤È¤·¤Æ¤¤¤ë IP ¥¢¥É¥ì¥¹¤ò¥¯¥é¥¤¥¢¥ó¥È¤ËÁ÷¤ê¤Þ¤¹¡£
+¤³¤¦¤¹¤ë¤È Win95 ¥Þ¥·¥ó¤Ï¤¹¤Ù¤Æ¤Î IP ¥¢¥É¥ì¥¹¤ò ARP ¤¹¤ë¤è¤¦¤Ë¤Ê¤ê¡¢
+»È¤Ã¤Æ¤¤¤ë¥ë¡¼¥¿¤¬ proxy ARP ¤ËÀßÄꤵ¤ì¤Æ¤¤¤ë¾ì¹ç¤Ë¤ÏÌò¤ËΩ¤Á¤Þ¤¹¡£
+.PP
+.\"O If use-lease-addr-for-default-route is enabled and an option routers
+.\"O statement are both in scope, the routers option will be preferred.
+.\"O The rationale for this is that in situations where you want to use
+.\"O this feature, you probably want it enabled for a whole bunch of
+.\"O Windows 95 machines, and you want to override it for a few other
+.\"O machines. Unfortunately, if the opposite happens to be true for you
+.\"O site, you are probably better off not trying to use this flag.
+use-lease-addr-for-default-route ¤¬Í¸ú¤Ë¤Ê¤Ã¤Æ¤¤¤Æ¡¢
+option routes ʸ¤âƱ¤¸¥¹¥³¡¼¥×¤Ë¤¢¤ë¾ì¹ç¤Ë¤Ï¡¢
+routes ¥ª¥×¥·¥ç¥ó¤¬Í¥À褵¤ì¤Þ¤¹¡£
+¤³¤ÎÍýͳ¤Ï¡¢¤³¤Îµ¡Ç½¤ò»È¤¤¤¿¤¤¶ÉÌ̤Ǥϡ¢
+¤¿¤¯¤µ¤ó¤¢¤ë Windows 95 ¥Þ¥·¥ó¤¹¤Ù¤Æ¤Ë¤Ï¤³¤Îµ¡Ç½¤ò͸ú¤Ë¤·¡¢
+¤½¤Î¾¿ôÂæ¤Î¥Þ¥·¥ó¤Ç¤Ï¤³¤ì¤ò̵¸ú¤Ë¤·¤¿¤¯¤Ê¤ë¤À¤í¤¦¤«¤é¤Ç¤¹¡£
+ÉÔ¹¬¤Ë¤·¤Æ¾õ¶·¤¬µÕ¤Î¾ì¹ç¤Ï¡¢
+¤³¤Î¥Õ¥é¥°¤ÏÍѤ¤¤Ê¤¤¤Û¤¦¤¬¤¿¤Ö¤óÎɤ¤¤Ç¤·¤ç¤¦¡£
+.PP
+.\"O .B The
+.I always-reply-rfc1048
+.\"O .B statement
+.B ʸ
+.PP
+ \fBalways-reply-rfc1048\fR \fIflag\fR\fB;\fR
+.PP
+.\"O Some BOOTP clients expect RFC1048-style responses, but do not follow
+.\"O RFC1048 when sending their requests. You can tell that a client is
+.\"O having this problem if it is not getting the options you have
+.\"O configured for it and if you see in the server log the message
+.\"O "(non-rfc1048)" printed with each BOOTREQUEST that is logged.
+BOOTP ¥¯¥é¥¤¥¢¥ó¥È¤ÎÃæ¤Ë¤Ï¡¢¼õ¿®¤Ë¤Ï RFC1048 ·Á¼°¤Î¤â¤Î¤ò´üÂÔ¤¹¤ë¤Î¤Ë¡¢
+Á÷¿®¤Ç¤Ï RFC1048 ¤ò¼é¤é¤Ê¤¤¤â¤Î¤¬¤¢¤ê¤Þ¤¹¡£
+¤¢¤ë¥¯¥é¥¤¥¢¥ó¥È¤¬¤³¤ÎÌäÂê¤òÊú¤¨¤Æ¤¤¤ë¾ì¹ç¤Ë¤Ï¡¢
+¤½¤Î¥¯¥é¥¤¥¢¥ó¥È¤ÏÀßÄꤷ¤¿¥ª¥×¥·¥ç¥ó¤ò¼èÆÀ¤»¤º¡¢
+¤Þ¤¿ BOOTREQUEST ¤¹¤ë¤¿¤Ó¤Ë
+¥µ¡¼¥Ð¤Î¥í¥°¤Ë "(non-rfc1048)" ¤È¤¤¤¦¥á¥Ã¥»¡¼¥¸¤¬¸½¤ì¤Þ¤¹¡£
+.PP
+.\"O If you want to send rfc1048 options to such a client, you can set the
+.\"O .B always-reply-rfc1048
+.\"O option in that client's host declaration, and the DHCP server will
+.\"O respond with an RFC-1048-style vendor options field. This flag can
+.\"O be set in any scope, and will affect all clients covered by that
+.\"O scope.
+¤³¤Î¤è¤¦¤Ê¥¯¥é¥¤¥¢¥ó¥È¤Ë rfc1048 ¥ª¥×¥·¥ç¥ó¤òÁ÷¿®¤·¤¿¤¤¾ì¹ç¤Ï¡¢
+¤½¤Î¥¯¥é¥¤¥¢¥ó¥È¤Î host Àë¸À¤Ë
+.B always-reply-rfc1048
+¤òÀßÄꤷ¤Þ¤¹¡£¤¹¤ë¤È DHCP ¥µ¡¼¥Ð¤Ï
+RFC-1048 ·Á¼°¤Î¥Ù¥ó¥À¡¼¥ª¥×¥·¥ç¥ó¥Õ¥£¡¼¥ë¥É¤òÍѤ¤¤Æ±þÅú¤·¤Þ¤¹¡£
+¤³¤Î¥Õ¥é¥°¤Ï¤É¤Î¥¹¥³¡¼¥×¤Ë¤âÀßÄê¤Ç¤¡¢
+¤½¤Î¥¹¥³¡¼¥×¤Ç¥«¥Ð¡¼¤µ¤ì¤ë¤¹¤Ù¤Æ¤Î¥¯¥é¥¤¥¢¥ó¥È¤ËŬÍѤµ¤ì¤Þ¤¹¡£
+.PP
+.\"O .B The
+.I server-identifier
+.\"O .B statement
+.B ʸ
+.PP
+ \fBserver-identifier \fIhostname\fR\fB;\fR
+.PP
+.\"O The server-identifier statement can be used to define the value that
+.\"O is sent in the DHCP Server Identifier option for a given scope. The
+.\"O value specified \fBmust\fR be an IP address for the DHCP server, and
+.\"O must be reachable by all clients served by a particular scope.
+.B server-identifier
+ʸ¤Ï¡¢¤½¤ì¤¬ÃÖ¤«¤ì¤¿¥¹¥³¡¼¥×Æâ¤Ë¤ª¤¤¤Æ¡¢
+DHCP ¥µ¡¼¥Ð¼±Ê̻ҥª¥×¥·¥ç¥ó¤ÇÁ÷¤é¤ì¤ëÃͤòÄêµÁ¤¹¤ë¤¿¤á¤ËÍѤ¤¤Þ¤¹¡£
+»ØÄꤹ¤ëÃÍ¤Ï DHCP ¥µ¡¼¥Ð¤Î IP ¥¢¥É¥ì¥¹¤Ç¤Ê¤±¤ì¤Ð¤Ê¤é¤º¡¢
+¤½¤Î¥¹¥³¡¼¥×¤Ë¤ª¤¤¤Æ¥µ¡¼¥Ó¥¹¤ò¼õ¤±¤ë¤¹¤Ù¤Æ¤Î¥¯¥é¥¤¥¢¥ó¥È¤«¤é
+Åþã²Äǽ¤Ç¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£
+.PP
+.\"O The use of the server-identifier statement is not recommended - the only
+.\"O reason to use it is to force a value other than the default value to be
+.\"O sent on occasions where the default value would be incorrect. The default
+.\"O value is the first IP address associated with the physical network interface
+.\"O on which the request arrived.
+server-identifier ʸ¤Î»ÈÍѤϴ«¤á¤é¤ì¤Þ¤»¤ó¡£
+Í£°ì¤ÎÍøÍѶÉÌ̤ϡ¢¥Ç¥Õ¥©¥ë¥È¤ÇÁ÷¤é¤ì¤ëÃͤ¬´Ö°ã¤Ã¤Æ¤¤¤ë¾ì¹ç¤Ë¡¢
+¤½¤ÎÃͤòÊ̤Τâ¤Î¤ËÊѹ¹¤¹¤ë¾ì¹ç¤À¤±¤Ç¤¹¡£
+¥Ç¥Õ¥©¥ë¥È¤ÎÃͤϡ¢Í׵᤬Åþ㤷¤¿ÊªÍý¥Í¥Ã¥È¥ï¡¼¥¯¥¤¥ó¥¿¡¼¥Õ¥§¡¼¥¹¤Ë
+´ØÏ¢ÉÕ¤±¤é¤ì¤¿ºÇ½é¤Î IP ¥¢¥É¥ì¥¹¤Ç¤¹¡£
+.PP
+.\"O The usual case where the
+.\"O \fIserver-identifier\fR statement needs to be sent is when a physical
+.\"O interface has more than one IP address, and the one being sent by default
+.\"O isn't appropriate for some or all clients served by that interface.
+.\"O Another common case is when an alias is defined for the purpose of
+.\"O having a consistent IP address for the DHCP server, and it is desired
+.\"O that the clients use this IP address when contacting the server.
+.I server-identifier
+ʸ¤¬É¬Íפˤʤë¤Î¤Ï¡¢ÊªÍý¥¤¥ó¥¿¡¼¥Õ¥§¡¼¥¹¤ËÊ£¿ô¤Î IP ¥¢¥É¥ì¥¹¤¬¤Ä¤¤¤Æ¤¤¤Æ¡¢
+¥Ç¥Õ¥©¥ë¥È¤ÇÁ÷¤é¤ì¤ë¥¢¥É¥ì¥¹¤¬¡¢
+¥µ¡¼¥Ó¥¹¤ò¼õ¤±¤ë°ìÉô¤Þ¤¿¤ÏÁ´Éô¤Î¥¯¥é¥¤¥¢¥ó¥È¤Ë¤È¤Ã¤ÆŬÀڤǤϤʤ¤¾ì¹ç¤Ç¤¹¡£
+¾¤Ë¤¢¤êÆÀ¤ëÎã¤È¤·¤Æ¤Ï¡¢
+DHCP ¥µ¡¼¥Ð¤Î IP ¥¢¥É¥ì¥¹¤ò°ì´Ó¤µ¤»¤ë¤¿¤á¤Ë IP ¥¨¥¤¥ê¥¢¥¹¤¬ÄêµÁ¤µ¤ì¤Æ¤ª¤ê¡¢
+¥¯¥é¥¤¥¢¥ó¥È¤¬¥µ¡¼¥Ð¤¤¤óÀܳ¤¹¤ëºÝ¤Ë¤Ï¤³¤Î
+IP ¥¢¥É¥ì¥¹¤òÍѤ¤¤ë¤Î¤¬Ë¾¤Þ¤·¤¤¾ì¹ç¤¬¤¢¤ê¤Þ¤¹¡£
+.PP
+.\"O Supplying a value for the dhcp-server-identifier option is equivalent
+.\"O to using the server-identifier statement.
+.\"O .SH REFERENCE: OPTION STATEMENTS
+.SH ¥ê¥Õ¥¡¥ì¥ó¥¹: ¥ª¥×¥·¥ç¥óʸ
+.PP
+.\"O DHCP option statements are documented in the
+.\"O .B dhcp-options(5)
+.\"O manual page.
+DHCP ¥ª¥×¥·¥ç¥óʸ¤Ï¥Þ¥Ë¥å¥¢¥ë¥Ú¡¼¥¸
+.BR dhcp-options (5)
+¤ÇÀâÌÀ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£
+.\"O .SH SEE ALSO
+.SH ´ØÏ¢¹àÌÜ
+dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.
+.\"O .SH AUTHOR
+.SH Ãø¼Ô
+.\"O .B dhcpd(8)
+.\"O was written by Ted Lemon <mellon@vix.com>
+.\"O under a contract with Vixie Labs. Funding
+.\"O for this project was provided by the Internet Software Corporation.
+.\"O Information about the Internet Software Consortium can be found at
+.\"O .B http://www.isc.org/isc.
+.BR dhcpd (8)
+¤Ï Ted Lemon <mellon@vix.com>
+¤¬ Vixie Labs ¤È¤Î·ÀÌó¤Î¤â¤È¤Ë½ñ¤¤Þ¤·¤¿¡£
+¤³¤Î¥×¥í¥¸¥§¥¯¥È¤Î»ñ¶â¤Ï¡¢
+Internet Software Corporation ¤Ë¤è¤Ã¤ÆÄ󶡤µ¤ì¤Þ¤·¤¿¡£
+Internet Software Consortium ¤Î¾ðÊó¤Ï
+.B http://www.isc.org/isc
+¤Ë¤¢¤ê¤Þ¤¹¡£
OSDN Git Service
