boot protocol server configuration file
/etc/bootptab
The bootptab file is used by the bootpd daemon.
The configuration file has a format similar to that of termcap, in which two-character case-sensitive tag symbols are used to represent host parameters. These parameter declarations are separated by colons (:). The general format is:
hostname:tg=value. . . :tg=value. . . :tg=value. . . .
where hostname is the actual name of a bootp client and tg is a two-character tag symbol. Most tags must be followed by an equals sign (=) and a value as above. Some may also appear in a Boolean form with no value (e.g. :tg:). The currently recognized tags are:
There's also a generic tag, Tn, where n is an RFC 1048 vendor field tag number. This lets you take advantage of future extensions to RFC 1048 without being forced to modify bootpd first. 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 1048-style bootp reply.
The following tags take a whitespace-separated list of IP addresses:
The ip and sm tags each take a single IP address. All IP addresses are specified in standard Internet ``dot'' notation and may use decimal, octal, or hexadecimal numbers (octal numbers begin with 0, hexadecimal numbers begin with 0x or 0X).
The ht tag specifies the hardware type code as either an unsigned decimal, octal, or hexadecimal integer or as one of the following symbolic names:
The ha tag takes a hardware address that must be specified in hexadecimal (optional periods and/or a leading 0x may be included for readability). The ha tag must follow the ht tag (either explicitly or implicitly; see tc below).
The hostname, home directory, and bootfile are ASCII strings that may be optionally surrounded by double quotes ("). The client's request and the values of the hd and bf symbols determine how the server fills in the bootfile field of the bootp reply packet.
If the client specifies an absolute pathname and that file exists on the server machine, then that pathname is returned in the reply packet. If the file can't be found, the request is discarded and no reply is sent. If the client specifies a relative pathname, a full pathname is formed by prepending the value of the hd tag and testing for existence of the file. If the hd tag isn't supplied in the configuration file or if the resulting boot file can't be found, then the request is discarded.
Clients that specify null boot files will always elicit a reply from the server. The exact reply will again depend on the hd and bf tags. If the bf tag gives an absolute pathname and the file exists, then that pathname is returned in the reply packet. If the hd and bf tags together specify an accessible file, then that filename is returned in the reply. If a complete filename can't be determined or if the file doesn't exist, then the reply will contain a zeroed-out bootfile field.
|
In all these cases, the file must have its public read access bit set, since this is required by tftpd. |
The time offset to may be either:
Or
The bootfile size bs may be either:
Or
As with the time offset, specifying bs as a boolean has the same effect as specifying auto as its value.
The vendor magic cookie selector (the vm tag) may take one of the following keywords:
The hn tag is strictly a boolean tag; it doesn't take the usual equals sign and value. Its presence indicates that the hostname should be sent to RFC 1048 clients. The bootpd daemon attempts to send the entire hostname as it is specified in the configuration file. If the name won't fit into the reply packet, it will be shortened to just the host field (up to the first period, if present) and then tried. The server will never send an arbitrarily truncated hostname (if nothing reasonable will fit, nothing is sent).
Many host entries often share common values for certain tags (such as name servers, etc.). Rather than repeatedly specify these tags, you can use the tc (table continuation) mechanism to list a full specification for one host entry that can be shared by others. The template entry is often a dummy host that doesn't actually exist and never sends bootp requests. This feature is similar to the tc feature of termcap for similar terminals.
Note that bootpd allows the tc tag symbol to appear anywhere in the host entry, unlike termcap, which requires it to be the last tag. Information explicitly specified for a host always overrides information implied by a tc tag symbol, regardless of its location within the entry. The value of the tc tag may be the hostname or IP address of any host entry previously listed in the configuration file.
Sometimes it's necessary to delete a specific tag after it's been inferred via tc. This can be done using the construction tag @, which removes the effect of the tag as in termcap.
For example, to completely undo an IEN-116 name server specification, you would put the following at an appropriate place in the configuration entry:
:ns@:
After removal with @, a tag is eligible to be set again through the tc mechanism.
Blank lines and lines beginning with a pound sign (#) are ignored in the configuration file. Host entries are separated from one another by newlines; a single host entry may be extended over multiple lines if the lines end with a backslash (\). Lines can be longer than 80 characters.
Tags may appear in any order, with the following exceptions:
Here's an example /etc/bootptab file:
# Sample bootptab file
default1:\
:hd=/usr/boot:bf=null:\
:ds=128.2.35.50 128.2.13.21:\
:ns=0x80020b4d 0x80020ffd:\
:ts=0x80020b4d 0x80020ffd:\
:sm=255.255.0.0:gw=0x8002fe24:\
:hn:vm=auto:to=-18000:\
:T37=0x12345927AD3BCF:T99="Special ASCII string":
carnegie:ht=6:ha=7FF8100000AF:ip=128.2.11.1:tc=default1:
baldwin:ht=1:ha=0800200159C3:ip=128.2.11.10:tc=default1:
wylie:ht=1:ha=00DD00CADF00:ip=128.2.11.100:tc=default1:
arnold:ht=1:ha=0800200102AD:ip=128.2.11.102:tc=default1:
bairdford:ht=1:ha=08002B02A2F9:ip=128.2.11.103:tc=default1:
bakerstown:ht=1:ha=08002B0287C8:ip=128.2.11.104:tc=default1:
# Special domain name server for next host
butlerjct:ht=1:ha=08002001560D:ip=128.2.11.108:ds=128.2.13.42:tc=default1:
gastonville:ht=6:ha=7FFF81000A47:ip=128.2.11.115:tc=default1:
hahntown:ht=6:ha=7FFF81000434:ip=128.2.11.117:tc=default1:
hickman:ht=6:ha=7FFF810001BA:ip=128.2.11.118:tc=default1:
lowber:ht=1:ha=00DD00CAF000:ip=128.2.11.121:tc=default1:
mtoliver:ht=1:ha=00DD00FE1600:ip=128.2.11.122:tc=default1:
The bootpd daemon looks in /etc/services to find the port numbers it should use. Two entries are extracted:
If the port numbers can't be determined this way, they're assumed to be 67 for the server and 68 for the client.
As a QNX extension, the argument to the bf tag can start with an ``or bar'' character (|). If it does, then the following is taken to be a command to spawn in order to get a boot image:
bf=|cd /boot; buildqnx build/node1:
If you use this QNX extension, tftpd must not be started as root. One choice is to create the user tftp and start tftpd as that user. You could also create and use the user ftp, but that will open up your machine to anonymous ftp. See /etc/inetd.conf for information on how to change the user that tftpd starts as. See also the section ``The build file for network booting'' in bootpd.