bootptab(4)bootptab(4)NAMEbootptab - BOOTP and DHCP server database
DESCRIPTION
The bootptab file is one of several text database files employed by
joind, the BOOTP and DHCP server. The file's format is similar to that
of the termcap(4) file.
Format
There are three types of lines in this file: data, comments, and white‐
space (for readability).
Data lines can be logically continued onto the next physical line by
preceding the newline character with a backslash (\), but the back‐
slash-newline pair is ignored elsewhere.
A comment has the number sign (#) as the first nonwhitespace character
on a line that is not a logical continuation of a data line; in no
other context is the number sign treated specially. Comments and blank
lines are ignored when the file is parsed by joind but are preserved
when editing with the xjoin GUI.
Data is organized into groups, the end of a group being identified by a
newline. A data group begins with a label, an optional printable string
and one or more colon-separated fields, each of which carries an iden‐
tifying tag used to represent configuration parameters and the clients
to which they apply.
label:tg=value. . . :tg:. . . :tg=value. . . .
The tags currently recognized by bootptab are listed in dhcptags(4).
The tg is a two-character tag symbol. If tg refers to a Boolean data
type, it may stand alone to indicate the Boolean is on or true; it may
also take the (case-insensitive) values true, false, on, or off. Other
types require a value set off from the tag by an equals sign. Leading
or trailing whitespace surrounding a text value is removed, but is
retained if the string is enclosed in double quotes (the quotes are
stripped internally). The following special syntax is also acceptable:
There is also a generic tag, Tn, where n is an integer in the range
1-254. The value may be represented as either a stream of hexadecimal
numbers or as a string of ASCII characters. If the numeric option is
not found in the dhcptags file, the former interpretation is tried
first; if an invalid hexadecimal digit is found, the second interpreta‐
tion is used. The dhcptags file obviates the need to use this syntax,
but it is supported for backward-compatibility.
SEMANTICS
In this section, when a reference is made to a specific option, that
option is described by its standard two character identifier in the
dhcptags file. These tags are identical to those in the Carnegie Mellon
implementation of BOOTP, though DHCP defines wholly new options as
well.
The label is a printable string that groups together the tags that fol‐
low the label and that can be referenced by the tc tag in other
entries. It may be interpreted as a client host name in the following
circumstances only: The data group refers to a specific BOOTP client
The hostname ho tag is not explicitly used The string is a valid host
name
Tags may appear in any order with one exception: the hardware type (ht)
must precede the hardware address (ha) (either explicitly or implic‐
itly; see the tc description). The ht tag specifies the hardware type
code as either an unsigned decimal, octal, or hexadecimal integer or
one of the following symbolic names:
────────────────────────────────────────────────
Value Symbol Hardware Type
────────────────────────────────────────────────
0 Client Identifier
1 ethernet 10MB Ethernet
ether
2 ethernet3 3 MB experimental Ethernet
ether3
3 ax.25
4 pronet Proteon ProNET Token Ring
5 chaos
6 token-ring IEEE 802 networks
ieee802
tr
7 arcnet
────────────────────────────────────────────────
The ha tag takes a value that (except when the type field is zero) is a
hardware address specified in hexadecimal; optional periods, dashes, or
colons may separate the octets for readability; a leading '0x' indicat‐
ing hexadecimal data is also permissible. However, the common conven‐
tion of using colons as octet delimiters conflicts with the use of that
symbol as a field separator and requires that the address be enclosed
in quotes.
When the type field is zero, it implies that the ha field will be used
to match against a client identifier, a DHCP concept. The client iden‐
tifier is an opaque object of arbitrary length, but may be a printable
string. Therefore, in the case of ha, the value is first scanned as
hexadecimal; if this scan does not succeed, the value is assumed to be
a literal string and is used as such.
Within each data group, certain tags and the label determine how the
database will be constructed and searched to resolve a particular
client query. When the server starts, each data group is internally
assigned to exactly one of 5 hash tables according to the presence of
one or more of the following tags: network IP address vendor class
hardware address/client identifier hardware type
The valid combinations are as follows:
The keys to the hash tables correspond to the values assumed by the tag
or tags. A particular configuration for a client (both DHCP and BOOTP)
is synthesized by searching these tables, in the order given, for a
match that corresponds to data explicit or implied in the client's
BOOTPREQUEST packet. Client parameters resolved earlier in the search
take precedence over those resolved later. Thus, a client configura‐
tion is assembled by searching for parameters starting from most
restrictive match to least. To support BOOTP clients in the manner to
which they are accustomed, you can omit any data groups with the other
keys. Any pre-existing bootptab file fulfills this requirement.
When the server tries to match a data group (partially) keyed by ht -
ha to a specific client, it normally uses the client's hardware type
and hardware address as sent in the htype and chaddr fields. DHCP
clients may choose to identify themselves by the so-called client iden‐
tifier option, which they explicitly send to the server. In this
instance, the server tries to match to a key in the database by using
the client identifier in place of the hardware address and using zero
for the type. DHCP clients that choose to use this mechanism must do
so consistently, and the data sent must constitute a unique identifier.
The client class (ct) is typically a string categorizing clients having
attributes in common, such as the CPU architecture/operating system
pair. Clients identify themselves as belonging to a particular class
by sending this data to the server. A data group in the dhcpcap file
is considered keyed with the class in either of the following ways:
Explicitly by the presence of ct and its value Implicitly by the data
group containing data items that are specific to a particular vendor
It is illegal for a data group to contain data items for two or more
vendors (though it is permissible for standard tags to be combined with
vendor tags). It is also illegal for a data group keyed to a specific
class to refer to a data group of a different class with tc. Combina‐
tions missing in the list are redundant: for instance, the client ID
always implies a particular vendor class, so there is no need for a
hash having that pair as its key. If the data group contains tags that
over-determine the key, the extraneous tags are ignored.
In addition to the internal tables, another table whose purpose is dif‐
ferent is formed by a hash on the label. It allows a convenient short‐
hand by grouping subsets of parameters together and referencing them as
an ensemble with the reference tag, tc. There may be more than one tc
tag in a data group, and when encountered they are resolved. However,
parameters that are explicitly named always take precedence over those
implied by tc, regardless of their order within an entry. If two or
more continuation tags are found, values resolved from the first named
entity take precedence. The converse is true for other tags: if the
same parameter is tagged twice, the last value is chosen.
Sometimes it is necessary to delete a specific tag after it has been
implied by tc. This can be done using the construction tag @, which
removes the effect of tag. For example, to completely undo an IEN-116
name server specification, use :ns@: at an appropriate place in the
configuration entry. After removal with @, a tag can be set again
through the tc mechanism.
The remaining tags that imply special logic are described as follows:
The hd (home directory) and bf (bootfile) tags are ASCII strings. The
client's request and the values of the hd and bf symbols determine how
the server fills in the file field of the DHCP/BOOTP reply packet.
If the client specifies an absolute pathname and the file exists on the
server machine, that pathname is returned in the reply packet. If the
file cannot be found, no value is returned. If the client specifies a
relative pathname, a full pathname is formed by prepending the value of
the hd tag. If the hd tag is not supplied in the configuration file,
no value is returned.
If the client sends a null value in the file field, the exact reply
depends upon the hd and bf tags. If the bf tag gives an absolute path‐
name, that pathname is returned. Otherwise, if the hd and bf tags
together specify an accessible file, that filename is returned in the
reply. If a complete filename cannot be determined or the file does
not exist, the file field in the reply contains zeroes.
All filenames are first tried as filename.hostname and then as file‐
name, providing for individual per-host bootfiles. The following table
summarizes these possibilities:
────────────────────────────────────────────────
hd tag bf tag Received File Returned File
────────────────────────────────────────────────
any any /c /c
/a any /c /a/c
any /b null /b
/a /b null /a/b
In all these cases, existence of the file means that, in addition to
actually being present, the file must have its public read access bit
set, since this is required by tftpd(8) to permit the file transfer.
(For other tftpd file access restrictions, see tftp(1).)
Some versions of tftpd provide a security feature to change the root
directory using the chroot(2) system call. You can use the td tag to
inform the joind daemon of this special root directory used by the
tftpd daemon. The hd tag is specified relative to any such root direc‐
tory. For example, if the real absolute path to the client's bootfile
is /tftpboot/bootfiles/bootimage, and tftpd uses /tftpboot as its
secure directory, specify the following line in the bootptab file:
:td=ftpboot:hd=/bootfiles:bf=bootimage:
If the bootfile is located in the /tftpboot directory, use following
line in the bootptab file:
:td=/tftpboot:hd=/:bf=bootimage:
You can use the sa tag to specify the IP address of the particular TFTP
server the client is to use. In the absence of this tag, joind tells
the client to perform TFTP to the same machine on which the joind dae‐
mon is running.
Three options, bs, to, and vm, permit the special string auto to be
used as their value string.
The bootfile size (bs) is a decimal, octal, or hexadecimal integer
specifying the size of the bootfile in 512-octet blocks. If the keyword
auto is specified, the server should consult the file system to deter‐
mine the size of the boot image. This assumes that the server is also
the TFTP host for the client's boot image. As with the time offset,
specifying the bs tag as a Boolean has the same effect as specifying
auto as its value.
The time offset (to) is a signed decimal integer specifying the
client's time zone offset in seconds from UTC. If the keyword auto is
specified, the client should use the server's time zone offset. Speci‐
fying the to symbol as a Boolean has the same effect as specifying auto
as its value.
The vendor magic cookie selector (vm) tells the server the style of
option-encoding that the client wishes to receive. The tag can take
one of the following keywords: Indicates that vendor information is
determined by the client's request. Always forces an RFC 1048/RFC
1033-style reply. DHCP clients must always send the rfc1048 cookie or
they will be treated as BOOTP clients. Always forces a CMU-style
reply.
The encoding chosen is based primarily on the value of the magic cookie
in the options field of the BOOTPREQUEST from the client. If it is
present, the magic cookie must be either the rfc1048 cookie or the cmu
cookie. If this cookie is not present, the server determines the
encoding from the value of vm.
The following table summarizes the possibilities. None means that
although the vendor field is empty, the file and sname fields are
returned with the client's IP address.
bootptab file
bootprequest none rfc1048 cmu auto
-------------------------------------------
unrecognized none rfc1048 cmu none
rfc1048 rfc1048 rfc1048 rfc1048 rfc1048
cmu cmu cmu cmu cmu
The remaining tags describe actual client configuration data. The bw,
bx, cs, ds, gw, im, lg, lp, ns, nt, ra, rl, sr, ts, xd, and xs tags
take a whitespace-separated list of IP addresses or hostnames, while
the ba, ip, sa, si, sm, and sw tags each take a single IP address. The
legal formats that may be used for character string representations of
IP addresses are described in join.ipaddresses(4).
When a host name is specified instead of an IP address, the joind dae‐
mon looks up the IP addresses for that host name using the gethostby‐
name routine. If the ip tag is not specified, the joind daemon deter‐
mines the IP address using the entry name as the host name. (Dummy
entries use an invalid host name to avoid automatic IP lookup.)
Since the gw tag is an extendible tagged subfield, you must also spec‐
ify the vm=rfc1048 tag in order to pass the information to the client
in an appropriate RFC 1048/RFC 1033-style reply.
BOOTP Semantics
For BOOTP usage, the label in the general file format is hostname, the
name of a BOOTP client. Dummy entries have an invalid host name (one
with a period (.) as the first character) and are used to provide
default values used by other entries through the tc=.dummy-entry mecha‐
nism. The recognized BOOTP tags are as follows: Boot file Boot file
size (512 octet blocks) Cookie servers Dump file DNS domain name Domain
name servers Encapsulate flavor Gateways (IP rosters) Hardware address
Home directory Send host name Hardware type Impress servers Host or
network IP address Log servers LPR servers IEN-116 name servers Reply
address override Resource location protocol servers Root path TFTP
server address (used by clients) Subnet mask (host) Swap server address
Template host (points to similar host entry) TFTP root directory (used
by secure TFTP server) Time offset (seconds) Time servers Vendor magic
cookie selector
EXAMPLES
The following bootptab example is for a BOOTP server that supports
remote installation service (RIS) clients:
.ris.dec:hn:vm=rfc1048:sm=255.255.0.0
.ris9.alpha:tc=.ris.dec:bf=/ris/r9k1:rp="unixris:/ris/r9p1":
.ris71.alpha:tc=.ris.dec:bf=/ris/r71k1:rp="unixris:/ris/r71p1":
pumba:tc=.ris71.alpha:ht=ethernet:gw=128.2.11.1:ha=0102030405aa:\
ip=128.2.11.108: chance:tc=.ris9.alpha:ht=ether‐
net:gw=128.2.11.1:ha=0102030405bb:\ ip=128.2.11.115: kee‐
wee:tc=.ris71.alpha:ht=ethernet:gw=128.2.11.1:ha=0102030405cc:\
ip=128.2.11.117: turtle:tc=.ris71.alpha:ht=ether‐
net:gw=128.2.11.1:ha=0102030405dd:\ ip=128.2.11.118:
ethel:tc=.ris9.alpha:ht=ethernet:gw=128.2.11.1:ha=0102030405ee:\
ip=128.2.11.121: isaiah:tc=.ris71.alpha:ht=ether‐
net:gw=128.2.11.1:ha=0102030405ff:\ ip=128.2.11.122: You can use the
/usr/sbin/ris utility to install software subsets onto a RIS server and
also to manage the clients that can load software from the RIS server.
The ris utility automatically adds, modifies, or deletes entries in the
bootptab file as necessary. See Sharing Software on a Local Area Net‐
work and the Installation Guide — Advanced Topics for more information
about configuring RIS.
The following bootptab example is for a DHCP server: admin:\
:tc=coop:\ :sm=255.255.255.0:\ :sl:\ :lt=86400:
legal:\ :tc=coop:\ :sl:\ :lt=21600:\
:sm=255.255.255.0: egghead:\ :ha=0203040506aa:\
:tc=admin:\ :lt=12600: coop:\ :sm=255.252.0.0:\
:hn:\ :ms:\ :lt=43200: bantam2dhcp:\
:nw=18.143.152.0:\ :dn=delmonicos-eggs.com:\
:ds=18.139.160.106 18.139.0.12:\ :gw=18.143.152.100
18.143.152.101:\ :sm=255.255.255.0:\ :yd=bantamYP:\
:ys=18.139.160.106 18.139.0.12:\ :bw=18.103.131.246
18.103.131.247 17.52.136.16:\ bantamdhcp:\ :nw=18.143.88.0:\
:dn=delmonicos-eggs.com:\ :ds=18.139.160.106 18.139.0.12:\
:gw=18.143.88.100 18.143.88.101:\ :sm=255.255.255.0:\
:bw=18.103.131.246 18.103.131.247 17.52.136.16:\ :yd=ban‐
tamYP:\ :ys=18.139.160.106 18.139.0.12:\ You can configure a DHCP
server and manage its associated clients with the xjoin utility, which
automatically adds, modifies, or deletes entries in the bootptab file
as necessary. See xjoin(8) and Network Administration: Connections for
more information.
FILES
/etc/bootptab
RELATED INFORMATION
Daemons: joind(8), tftpd(8)
Files: dhcptags(4)
DARPA Internet Request For Comments: DHCP Options and BOOTP Vendor
Extensions (RFC 1533), Dynamic Host Configuration Protocol (RFC 1541)
delim off
bootptab(4)
