server.pcy(4)server.pcy(4)NAMEserver.pcy - BOOTP and DHCP server policy
DESCRIPTION
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 direc‐
tory 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
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
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 iden‐
tifiers. 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 idetfi‐
fiers). 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 DHCPRE‐
QUEST 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 con‐
tain 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 possi‐
ble, 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 name‐
pool(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 perma‐
nently assign an IP address from its free pool to a BOOTP client
in the event that no permanent binding exists in bootptab. Nor‐
mally 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 mil‐
liseconds) that the server waits for the echo. If this value is
zero or negative, the server does not perform this check. Dis‐
abling 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.
RELATED INFORMATION
Files: namepool(4)
Specifications: RFC 1541, RFC 1542 delim off
server.pcy(4)