namepool(4) Kernel Interfaces Manual namepool(4)NAME
namepool - DHCP server database
DESCRIPTION
The namepool database provides joind with names that are available for dynamic assignment to clients of the DHCP protocol. For each DHCP
server and domain name (NIS or DNS), the database contains a collection of names available for allocation to DHCP clients within those
domains. One name plays a distinguished role - it is used as a prefix when the pool has been exhausted. Names are generated from the pre-
fix by appending a number, 1,2.., and a trailing 'd'. The namepool file is read whenever joind starts. Names within the database must not
be allocated to hosts which are not DHCP clients, and if the administration of a domain is shared between several DHCP servers, the name-
pools that each has must be disjoint. Names may be added and removed from the namepool file. If a name is removed from the file it remains
bound to the client to which it was allocated; if no such binding is in effect the name is excised from the server's pool the next time the
server starts. Once a name is dynamically bound to a host it will never be reused even if that host subsequently acquires a new name, but
there is no need to remove it from namepool.
FORMAT
Blank lines and lines beginning with a number sign (#) are ignored. A new entry must begin in column one and has one of the following for-
mats:
domain server
domain server name_prefix
The domain variable is the domain in which the names which follow are assigned.
The server variable is the name or IP address of the server in charge of allocating these names to clients.
The prefix variable is the prefix that will be used when the pool is exhausted.
Succeeding lines contain one or more names for domains that are to be allocated by the server. Each of these succeeding lines must begin
with at least one white space character.
FILES
/etc/join/namepool
RELATED INFORMATION joind(8), join.ipaddresses(4) delim off
namepool(4)
Check Out this Related Man Page
dhcptags(4) Kernel Interfaces Manual dhcptags(4)NAME
dhcptags - DHCP and BOOTP server database
DESCRIPTION
Parameters (or options) returned to the client by the DHCP/BOOTP protocol are encoded in the so-called vendor field of the BOOTP packet.
Each option is identified numerically, and also carries a length specifier. The dhcptags file identifies the type of each option, labels
each with a short mnemonic text string for use in the dhcpcap database, and provides a description of each for use in the xjoin program.
Options defined by DHCP are of three general types: The semantics of which all client and server DHCP implementations agree upon. These
are administered by the Internet Assigned Numbers Authority (IANA). These options are numbered from 1 to 127 and 255. Within a specific
site all client and server implementations agree as to the semantics, but at another site the type and meaning of an option may be quite
different. These options are numbered from 128 to 254. Each vendor may define 256 options unique to that vendor. The vendor is identi-
fied within a DHCP packet by the "Vendor Class" option (#60). An option with a specific numeric identifier belonging to one vendor will,
in general, have a type and semantics different from those of another vendor. Vendor options are "super-encapsulated" into the vendor
field (#43): within a specific DHCP packet there may be several instances of option #43.
As well as these, the DHCP implementation defines certain "pseudo" options, numbered from 512 upward. These are used by the server to
identify items in its database which either correspond to fixed fields in the BOOTP packet (such as the "siaddr" field) or which though not
options themselves are used in constructing valid options. For example, the "home directory" used in constructing the exact path to a boot
image.
In general, the joind server knows little about the semantics of any of the first three types of options. Its only duty is to deliver
those values to clients that need them. The responsibility for understanding and using the data rests with the client. Pseudo-tags, on
the contrary, have a meaning specific to joind, and consequently are not added to this list. The only useful edit that can be performed on
the pseudo-tags is to change the description or the mnemonic.
FORMAT
Blank lines and those whose first nonwhitespace character is '#' are ignored. Data entries are written one per line and have seven fields.
An individual entry cannot be continued onto another line.
The fields are (in order): The tag number Identifier as used in bootptab file Grouping in GUI Vendor class Data type. Choose from the fol-
lowing (case insensitive) list: A 1-byte value A 2-byte value A 4-byte value A printable character string An IP address A list of IP
addresses A list of 2-byte values A array of 1-byte values Either true or false Column grouping in GUI Long name
Tag List
The currently recognized /etc/join/dhcptags tags are: Maximum reassembly size Arp timeout Broadcast address of network Boot file Be a
router Boot file size (512 octet blocks) Netbios name servers Netbios datagram distribution servers Netbios node type Netbios scope Path to
join client binary Cookie servers Class type Dump file DNS domain name Domain name servers Encapsulate flavor Path of the extensions file
Forward nonlocal datagrams Gateways (IP rosters) Hardware address Home directory Send host name Host name Hardware type Client id Impress
servers Host or network IP address IP TTL Keep alive interval Keep alive octet Log servers LPR servers Lease time Perform mask discovery
Publicly mountable file systems Supply masks IEN-116 name servers NTP (network time protocol) servers Policy filters PMTU plateaus Printcap
setup SVR4 printer setup PMTU timeout Reply address override Do route discovery Resource location protocol servers Root path Solicit routes
TFTP server address (used by clients) Boot server address Subnets are local Subnet mask (host) Static routes Name service switch Swap
server address DHCP T1 DHCP T2 Template host (points to similar host entry) TFTP root directory (used by secure TFTP server) Time offset
(seconds) Trailers Time servers TCP TTL MTU Vendor magic cookie selector Netware domain name Netware options X display managers X font
servers NIS domain NIS map servers NIS+ domain NIS+ map servers
There is also a generic tag, Tn, where n is an RFC 1533 vendor field tag number. Thus it is possible to immediately take advantage of
future extensions to RFC 1533 without being required to modify the DHCP server (joind). Generic data may be represented as either a stream
of hexadecimal numbers or as a quoted string of ASCII characters. The length of the generic data is automatically determined and inserted
into the proper field(s) of the RFC 1533-style BOOTP and DHCP reply.
FILES
DHCP server database
RELATED INFORMATION
Commands: dhcpparm(8), joind(8).
Files: bootptab(4),
DARPA Internet Request For Comments RFC 1533, RFC 1541, Assigned Numbers delim off
dhcptags(4)