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.
Blank lines are ignored. The number sign character (#) introduces a com-
ment, which continues to the next newline. Each new policy option must
begin and end on a separate line. Policy options are introduced by a key-
word, 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)
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 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 data-
base, 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 avail-
able 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.
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
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 (gethost-
byaddr(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.
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 per-
manent 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.
Specifications: RFC 1541, RFC 1542