bootptab - BOOTP and DHCP server database
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 [Toc] [Back]
There are three types of lines in this file: data, comments,
and whitespace (for readability).
Data lines can be logically continued onto the next physical
line by preceding the newline character with a backslash
(\), but the backslash-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 identifying 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
interpretation is used. The dhcptags file obviates the
need to use this syntax, but it is supported for backwardcompatibility.
SEMANTICS [Toc] [Back]
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 follow 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 implicitly; 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' indicating hexadecimal
data is also permissible. However, the common convention
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 identifier 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 configuration 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 identifier
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. Combinations
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 different is formed by a hash on the label. It
allows a convenient shorthand 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 pathname, 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 filename, 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 directory. 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 daemon 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 determine 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. Specifying 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 daemon looks up the IP addresses for that host
name using the gethostbyname routine. If the ip tag is
not specified, the joind daemon determines 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 specify the vm=rfc1048 tag in order to pass the
information to the client in an appropriate RFC 1048/RFC
1033-style reply.
BOOTP Semantics [Toc] [Back]
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 mechanism. 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
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=ethernet:gw=128.2.11.1:ha=0102030405bb:\
ip=128.2.11.115: keewee:tc=.ris71.alpha:ht=ether-
net: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 Network 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=delmonicoseggs.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=bantamYP:\
: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.
/etc/bootptab
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)
[ Back ] |
