 |
Index for
Section 4 |
|
 |
Alphabetical
listing for B |
|
 |
Bottom of
page |
|
bootptab(4)
NAME
bootptab - 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 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:
. . . :tg@:. . . .
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
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 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:
nw
network IP address
ct
vendor class
ha
hardware address/client identifier
ht
hardware type
The valid combinations are as follows:
ht - ha - nw
ht - ha
nw - ct
nw
ct
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:
auto
Indicates that vendor information is determined by the client's
request.
rfc1048
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.
cmu 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
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:
bf Boot file
bs Boot file size (512 octet blocks)
cs Cookie servers
df Dump file
dn DNS domain name
ds Domain name servers
ef Encapsulate flavor
gw Gateways (IP rosters)
ha Hardware address
hd Home directory
hn Send host name
ht Hardware type
im Impress servers
ip Host or network IP address
lg Log servers
lp LPR servers
ns IEN-116 name servers
ra Reply address override
rl Resource location protocol servers
rp Root path
sa TFTP server address (used by clients)
sm Subnet mask (host)
sw Swap server address
tc Template host (points to similar host entry)
td TFTP root directory (used by secure TFTP server)
to Time offset (seconds)
ts Time servers
vm 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=ethernet:gw=128.2.11.1:ha=0102030405bb:\
ip=128.2.11.115:
keewee:tc=.ris71.alpha:ht=ethernet:gw=128.2.11.1:ha=0102030405cc:\
ip=128.2.11.117:
turtle:tc=.ris71.alpha:ht=ethernet: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=ethernet: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=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=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.
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)
|
Index for
Section 4 |
|
|
Alphabetical
listing for B |
|
 |
Top of
page |
|