*** UNIX MANUAL PAGE BROWSER ***

server.pcy(4) Kernel Interfaces Manual server.pcy(4) NAME server.pcy - BOOTP and DHCP server policy DESCRIPTION server.pcy is a text database which governs the behavior of BOOTP and DHCP servers. If joind is invoked to use text databases, it expects to read server.pcy on startup. If the variable JOINCONFIG is present in joind's environment, it is taken to be the directory where server.pcy is housed; otherwise /etc/join is searched. Defaults exist for all pa- rameters and switches, so it is not an error if the file does not ex- ist. FORMAT Blank lines are ignored. The character '#' introduces a comment which continue 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 will be take effect - earlier value(s) will be forgotten. KEYWORDS AND VALUES provisional_ttl seconds For each sub- net that the BOOTP and DHCP server ad- min- is- ters two lists are main- tained in mem- ory: a "free" list con- tain- ing IP ad- dresses avail- able for al- lo- ca- tion, and a "pro- vi- sional" list con- tain ad- dresses which have been ten- ta- tively as- signed, which are await- ing client ap- proval in the form of a DHCPRE- QUEST packet. The value sec- onds de- ter- mines how long an ad- dress will re- main on the free list be- fore the server de- ter- mines that the client does not want the of- fered ad- dress. The free list does not con- tain every ad- dress avail- able to the server; in- stead it acts as a cache of ad- dresses which the server can of- fer with- out read- ing the disk. If a new client makes a DHCPDIS- COVER, and no IP ad- dress ex- ists for the client in per- ma- nent store, the server will first go to the free list for an un- used ad- dress. If the free list is ex- hausted, the server will first re- claim any ad- dresses on the pro- vi- sional list which have ex- pired. It will then ex- tend this list to be free_list_size(qv.) in length by read- ing from the disk. This has a ben- e- fit in that ad- dresses are usu- ally of- fered in nu- mer- i- cally in- creas- ing or- der. Mak- ing the ttl too short will not give clients an op- por- tu- nity to con- firm of- fered ad- dresses; mak- ing it too long will waste mem- ory. De- fault: 60 free_list_size integer See the ex- pla- na- tion un- der pro- vi- sional_ttl. If this num- ber is too low, server re- sponse time will suf- fer. If it is too large it has the un- de- sir- able ef- fect of re- quir- ing the server to re- claim ex- pired leases be- fore they are ac- tu- ally needed for re- al- lo- ca- tion to new clients. Al- though this is not an er- ror, a de- sir- able fea- ture of server op- er- a- tion is that, when- ever pos- si- ble, a client re- quest- ing a new IP ad- dress should get back its old ad- dress, un- less that ad- dress has been leases to a new client. De- fault: 8 assign_name_by_hwaddr This and the next op- tion are mu- tu- ally ex- clu- sive. They gov- ern how the server as- signs names to hosts. This op- tion tells the server to make a name "move with" the MAC ad- dress. I.e. if the client moves to a new ad- dress, it keeps the same name. assign_name_by_ipaddr This tells the server that if a lookup to the name ser- vice ( geth- ost- byaddr(3) suc- ceeds, the client should re- ceive the name that was found at the IP ad- dress. accept_client_name This boolean op- tion is not in- com- pat- i- ble with pre- vi- ous op- tions. It es- sen- tially tells the server that, if it has not be able to find a name for the client by ap- pli- ca- tion of the two pre- vi- ous poli- cies, then it can ac- cept the name the client sug- gests for it- self pro- vid- ing that this would not be in con- tra- dic- tion with val- ues cur- rently in the name ser- vice. If a con- tra- dic- tion ex- ists, or this pol- icy is not en- abled, then joind would con- sult its name- pool or pre- fix. (See name- pool(4)). support_bootp This boolean tells joind to sup- port BOOTP clients. When re- ply- ing to BOOTP clients, the server does not use the DHCP ex- ten- sions to the BOOTP pro- to- col. This is dis- abled by de- fault. bootp_addr_from_pool This boolean is only valid if sup- port_bootp op- tion is en- abled. When on it per- mits the server to per- ma- nently as- sign an IP ad- dress from its free pool to a BOOTP client in the event that no per- ma- nent bind- ing ex- ists in dhcp- cap. Nor- mally the BOOTP and DHCP server can only ser- vice BOOTP clients for which such a bind- ing pre- ex- ists. ping_timeout Be- fore the server of- fers an IP ad- dress to a client it may first check that the ad- dress is not in use by send- ing an ICMP echo re- quest. If an echo is re- ceived it means that the ad- dress is in use, and the server will se- lect an- other. This pa- ra- me- ter spec- i- fies the time (in mil- lisec- onds) that the server will wait for the echo. If this value is zero or neg- a- tive the server will not per- form this check. Dis- abling this check may be nec- es- sary in cer- tain en- vi- ron- ments to de- crease server re- sponse time to an ac- cept- able level - this re- lease of joind is not multi- threaded, so the server idles while await- ing the re- sponse. RELATED INFORMATION namepool(4), DARPA Internet Request For Comments RFC1541, RFC1542. delim off server.pcy(4)