server.pcy - BOOTP and DHCP server policy
The server.pcy file is a text database that governs the
behavior of BOOTP and DHCP servers. If the joind daemon
is invoked to use text databases, it reads the server.pcy
file on startup. If the JOINCONFIG variable is present in
the joind environment, it specifies the directory for the
server.pcy file; otherwise, joind searches the /etc/join
directory. Defaults exist for all parameters and
switches, so it is not an error if the file does not
exist.
Format [Toc] [Back]
Blank lines are ignored. The number sign character (#)
introduces a comment, which continues to the next newline.
Each new policy option must begin and end on a separate
line. Policy options are introduced by a keyword, and may
be Boolean, or may take a value separated from the keyword
by whitespace (but not a newline). If an option is present
more than once, only the value attached to the last
occurrence is used; earlier value(s) are ignored.
Keywords and Values [Toc] [Back]
This Boolean tells the server that if a DHCP client needs
a boot file, send the name of that file in the BOOTP file
field and not as a DHCP option (option 67). BOOTP clients
always receive a boot file name in the file field. This
is disabled by default. This Boolean tells the server to
ignore the value of the broadcast bit and always broadcast
a reply, even when the client can receive a pseudo unicast
reply. This was needed by some Cabletron smart bridges.
This is disabled by default. This Boolean is for clients
that do not use DHCP client identifiers. The parameter
tells the server to use the client's hardware address as
its identifier, but to ignore the hadware type field. In
the JOIN database, the identifier is stored with a type
field of zero (which is also the type for those clients
that are using client idetfifiers). This is disabled by
default. For each subnet that the BOOTP and DHCP server
administers, two lists are maintained in memory: a "free"
list containing IP addresses available for allocation and
a "provisional" list containing addresses that have been
tentatively assigned, which are awaiting client approval
in the form of a DHCPREQUEST packet.
The value of seconds determines how long an address
will remain on the free list before the server
determines that the client does not want the
offered address. The free list does not contain
every address available to the server; instead it
acts as a cache of addresses which the server can
offer without reading the disk.
If a new client makes a DHCPDISCOVER, and no IP
address exists for the client in permanent store,
the server first goes to the free list for an
unused address. If the free list is exhausted, the
server first reclaims any addresses on the provisional
list which have expired. It then extends
this list to be free_list_size in length by reading
from the disk. This has a benefit in that
addresses are usually offered in numerically
increasing order. Making the ttl too short will not
give clients an opportunity to confirm offered
addresses; making it too long will waste memory.
Default: 60 See the explanation under provisional_ttl.
If this number is too low, server
response time will suffer. If it is too large it
has the undesirable effect of requiring the server
to reclaim expired leases before they are actually
needed for reallocation to new clients. Although
this is not an error, a desirable feature of server
operation is that, whenever possible, a client
requesting a new IP address should get back its old
address, unless that address has been leased to a
new client.
Default: 8 This option and the
"assign_name_by_ipaddr" option are mutually exclusive.
They govern how the server assigns names to
hosts. This option tells the server to bind a name
to the MAC address. That way, if the client moves
to a new address, it keeps the same name. This
tells the server that if a lookup to the name service
(gethostbyaddr(3)) succeeds, the client should
receive the name that was found at the IP address.
This Boolean option is compatible with previous
options. It instructs the server that if it is not
able to find a name for the client by application
of the two previous policies, it can accept the
name the client suggests for itself providing that
this is not in contradiction with values currently
in the name service. If a contradiction exists, or
this policy is not enabled, joind consults its
namepool or prefix. (See namepool(4)). This
Boolean tells joind to support BOOTP clients. When
replying to BOOTP clients, the server does not use
the DHCP extensions to the BOOTP protocol. This is
enabled by default. This Boolean is only valid if
the support_bootp option is enabled. When on support_bootp
permits the server to permanently assign
an IP address from its free pool to a BOOTP client
in the event that no permanent binding exists in
bootptab. Normally the BOOTP and DHCP server can
only service BOOTP clients for which such a binding
pre-exists. Before the server offers an IP address
to a client it may first check that the address is
not in use by sending an ICMP echo request. If an
echo is received, it means that the address is in
use, and the server selects another. This parameter
specifies the time (in milliseconds) that the
server waits for the echo. If this value is zero
or negative, the server does not perform this
check. Disabling this check may be necessary in
certain environments to decrease server response
time to an acceptable level; this release of joind
is not multithreaded, so the server idles while
awaiting the response.
Files: namepool(4)
Specifications: RFC 1541, RFC 1542 delim off
server.pcy(4)
[ Back ] |
