/etc/bootptab

Name:

Description:

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:

bf

Bootfile.

bs

Bootfile size. This can be:

a decimal, octal, or hexadecimal integer (specifying the size of the bootfile in 512-octet blocks)

Or:

the keyword auto, which causes the server to
automatically calculate the bootfile size at each request.

Host hardware address.
This 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).

hd

Bootfile home directory.

hn

Send hostname.
This 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's specified in the configuration file. If
the name doesn't fit into the reply packet, it's
shortened to just the host field (up to the first
period, if present) and then tried. The server never
sends an arbitrarily truncated hostname (if nothing
reasonable fits, nothing is sent).

ht

Host hardware type (see Assigned Numbers RFC).
This tag specifies the hardware type code as
either an unsigned decimal, octal, or hexadecimal integer or
as one of the following symbolic names:

Vendor magic cookie selector.
This can be one of the following keywords:

auto (indicating that vendor information is determined by the client's request)

rfc1048 (which always forces an RFC 1048-style reply)

cmu (which always forces a CMU-style reply)

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.

Note:
In all these cases, the file must have its public read access bit set, since this is required by
tftpd.

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.

The bootpd daemon looks in /etc/services to find the port numbers it
should use. Two entries are extracted:

bootps — the bootp server listening port

bootpc — the destination port used to reply to clients

If the port numbers can't be determined this way, they're
assumed to be 67 for the server and 68 for the client.

Caveats:

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.