Boot protocol server configuration file
/etc/bootptab
The /etc/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:
Or:
If bs is specified as a boolean, auto is assumed.
Or:
If to is specified as a boolean, auto is assumed.
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.
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 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 always elicit a reply from the server. The exact reply again depends 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 contains a zeroed-out bootfile field.
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. You can do this by 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, 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 a sample /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 Neutrino 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; mkifs build/node1:
If you use this 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 opens up your machine to anonymous ftp. For information on how to change the user as which tftpd starts, see /etc/inetd.conf.