Convert to mdoc. Header -> Id. Typo.
This commit is contained in:
Philippe Charnier
parent
e736cd05cb
commit
81389de071
@ -1,305 +1,290 @@
|
||||
.\" Copyright (c) 1988, 1989, 1991 Carnegie Mellon University
|
||||
.\"
|
||||
.\" $Header: /home/ncvs/src/libexec/bootpd/bootpd.8,v 1.6 1997/08/24 18:21:34 joerg Exp $
|
||||
.\" $Id$
|
||||
.\"
|
||||
.TH BOOTPD 8 "November 06, 1993" "Carnegie Mellon University"
|
||||
.SH NAME
|
||||
bootpd, bootpgw \- Internet Boot Protocol server/gateway
|
||||
.SH SYNOPSIS
|
||||
.B bootpd
|
||||
[
|
||||
.B \-i
|
||||
.B \-s
|
||||
.B \-t
|
||||
timeout
|
||||
.B \-d
|
||||
level
|
||||
.B \-c
|
||||
chdir\-path
|
||||
]
|
||||
[
|
||||
.I bootptab
|
||||
[
|
||||
.I dumpfile
|
||||
] ]
|
||||
.br
|
||||
.B bootpgw
|
||||
[
|
||||
.B \-i
|
||||
.B \-s
|
||||
.B \-t
|
||||
timeout
|
||||
.B \-d
|
||||
level
|
||||
] server
|
||||
.SH DESCRIPTION
|
||||
.I Bootpd
|
||||
.Dd November 06, 1993
|
||||
.Dt BOOTPD 8
|
||||
.Os "Carnegie Mellon University"
|
||||
.Sh NAME
|
||||
.Nm bootpd , bootpgw
|
||||
.Nd Internet Boot Protocol server/gateway
|
||||
.Sh SYNOPSIS
|
||||
.Nm bootpd
|
||||
.Op Fl i
|
||||
.Op Fl s
|
||||
.Op Fl t Ar timeout
|
||||
.Op Fl d Ar level
|
||||
.Op Fl c Ar chdir-path
|
||||
.Oo
|
||||
.Ar bootptab
|
||||
.Op Ar dumpfile
|
||||
.Oc
|
||||
.Nm bootpgw
|
||||
.Op Fl i
|
||||
.Op Fl s
|
||||
.Op Fl t Ar timeout
|
||||
.Op Fl d Ar level
|
||||
.Ar server
|
||||
.Sh DESCRIPTION
|
||||
.Nm Bootpd
|
||||
implements an Internet Bootstrap Protocol (BOOTP) server as defined in
|
||||
RFC951, RFC1532, and RFC1533.
|
||||
.I Bootpgw
|
||||
.Nm Bootpgw
|
||||
implements a simple BOOTP gateway which can be used to forward
|
||||
requests and responses between clients on one subnet and a
|
||||
BOOTP server (i.e.
|
||||
.IR bootpd )
|
||||
.Nm Ns )
|
||||
on another subnet. While either
|
||||
.I bootpd
|
||||
.Nm
|
||||
or
|
||||
.I bootpgw
|
||||
.Nm bootpgw
|
||||
will forward BOOTREPLY packets, only
|
||||
.I bootpgw
|
||||
.Nm bootpgw
|
||||
will forward BOOTREQUEST packets.
|
||||
.PP
|
||||
.Pp
|
||||
One host on each network segment is normally configured to run either
|
||||
.I bootpd
|
||||
.Nm
|
||||
or
|
||||
.I bootpgw
|
||||
.Nm bootpgw
|
||||
from
|
||||
.I inetd
|
||||
.Xr inetd 8
|
||||
by including one of the following lines in the file
|
||||
.IR /etc/inetd.conf :
|
||||
.IP
|
||||
bootps dgram udp wait root /usr/libexec/bootpd bootpd /etc/bootptab
|
||||
.br
|
||||
bootps dgram udp wait root /usr/libexec/bootpgw bootpgw server
|
||||
.PP
|
||||
.Pa /etc/inetd.conf :
|
||||
.Pp
|
||||
.Dl bootps dgram udp wait root /usr/libexec/bootpd bootpd /etc/bootptab
|
||||
.Dl bootps dgram udp wait root /usr/libexec/bootpgw bootpgw server
|
||||
.Pp
|
||||
This mode of operation is referred to as "inetd mode" and causes
|
||||
.I bootpd
|
||||
.Nm
|
||||
(or
|
||||
.IR bootpgw )
|
||||
.Nm bootpgw )
|
||||
to be started only when a boot request arrives. If it does not
|
||||
receive another packet within fifteen minutes of the last one
|
||||
it received, it will exit to conserve system resources. The
|
||||
.B \-t
|
||||
.Fl t
|
||||
option controls this timeout (see OPTIONS).
|
||||
.PP
|
||||
.Pp
|
||||
It is also possible to run
|
||||
.I bootpd
|
||||
.Nm
|
||||
(or
|
||||
.IR bootpgw )
|
||||
.Nm bootpgw )
|
||||
in "standalone mode" (without
|
||||
.IR inetd )
|
||||
.Xr inetd 8 )
|
||||
by simply invoking it from a shell like any other regular command.
|
||||
Standalone mode is particularly useful when
|
||||
.I bootpd
|
||||
.Nm
|
||||
is used with a large configuration database, where the start up
|
||||
delay might otherwise prevent timely response to client requests.
|
||||
(Automatic start up in standalone mode can be done by invoking
|
||||
.I bootpd
|
||||
.Nm
|
||||
from within
|
||||
.IR /etc/rc.local ,
|
||||
.Pa /etc/rc.local ,
|
||||
for example.)
|
||||
Standalone mode is less useful for
|
||||
.I bootpgw
|
||||
.Nm bootpgw
|
||||
which
|
||||
has very little start up delay because
|
||||
it does not read a configuration file.
|
||||
.PP
|
||||
.Pp
|
||||
Either program automatically detects whether it was invoked from inetd
|
||||
or from a shell and automatically selects the appropriate mode.
|
||||
The
|
||||
.B \-s
|
||||
.Fl s
|
||||
or
|
||||
.B \-i
|
||||
.Fl i
|
||||
option may be used to force standalone or inetd mode respectively
|
||||
(see OPTIONS).
|
||||
.SH OPTIONS
|
||||
.TP
|
||||
.BI \-t \ timeout
|
||||
Specifies the
|
||||
.I timeout
|
||||
.Sh OPTIONS
|
||||
The following options are available:
|
||||
.Bl -tag -width indent
|
||||
.It Fl t Ar timeout
|
||||
Specify the
|
||||
.Ar timeout
|
||||
value (in minutes) that a
|
||||
.I bootpd
|
||||
.Nm
|
||||
or
|
||||
.I bootpgw
|
||||
.Nm bootpgw
|
||||
process will wait for a BOOTP packet before exiting.
|
||||
If no packets are recieved for
|
||||
.I timeout
|
||||
.Ar timeout
|
||||
minutes, then the program will exit.
|
||||
A timeout value of zero means "run forever".
|
||||
In standalone mode, this option is forced to zero.
|
||||
.TP
|
||||
.BI \-d \ debug\-level
|
||||
Sets the
|
||||
.I debug\-level
|
||||
.It Fl d Ar debug-level
|
||||
Set the
|
||||
.Ar debug-level
|
||||
variable that controls the amount of debugging messages generated.
|
||||
For example, -d4 or -d 4 will set the debugging level to 4.
|
||||
For example,
|
||||
.Fl d Ns 4
|
||||
or
|
||||
.Fl d
|
||||
4 will set the debugging level to 4.
|
||||
For compatibility with older versions of
|
||||
.IR bootpd ,
|
||||
omitting the numeric parameter (i.e. just -d) will
|
||||
simply increment the debug level by one.
|
||||
.TP
|
||||
.BI \-c \ chdir\-path
|
||||
Sets the current directory used by
|
||||
.I bootpd
|
||||
.Nm Ns ,
|
||||
omitting the numeric parameter (i.e. just
|
||||
.Fl d Ns )
|
||||
will simply increment the debug level by one.
|
||||
.It Fl c Ar chdir-path
|
||||
Set the current directory used by
|
||||
.Nm
|
||||
while checking the existence and size of client boot files. This is
|
||||
useful when client boot files are specified as relative pathnames, and
|
||||
.I bootpd
|
||||
.Nm
|
||||
needs to use the same current directory as the TFTP server
|
||||
(typically /tftpboot). This option is not recoginzed by
|
||||
.IR bootpgw .
|
||||
.TP
|
||||
.B \-i
|
||||
(typically
|
||||
.Pa /tftpboot Ns ).
|
||||
This option is not recognized by
|
||||
.Nm bootpgw .
|
||||
.It Fl i
|
||||
Force inetd mode. This option is obsolete, but remains for
|
||||
compatibility with older versions of
|
||||
.IR bootpd .
|
||||
.TP
|
||||
.B \-s
|
||||
.Nm Ns .
|
||||
.It Fl s
|
||||
Force standalone mode. This option is obsolete, but remains for
|
||||
compatibility with older versions of
|
||||
.IR bootpd .
|
||||
.TP
|
||||
.I bootptab
|
||||
Specifies the name of the configuration file from which
|
||||
.I bootpd
|
||||
.Nm Ns .
|
||||
.It Ar bootptab
|
||||
Specify the name of the configuration file from which
|
||||
.Nm
|
||||
loads its database of known clients and client options
|
||||
.RI ( bootpd
|
||||
.Pf ( Nm bootpd
|
||||
only).
|
||||
.TP
|
||||
.I dumpfile
|
||||
Specifies the name of the file that
|
||||
.I bootpd
|
||||
.It Ar dumpfile
|
||||
Specify the name of the file that
|
||||
.Nm
|
||||
will dump its internal database into when it receives a
|
||||
SIGUSR1 signal
|
||||
.RI ( bootpd
|
||||
only). This option is only recognized if
|
||||
.I bootpd
|
||||
.Pf ( Nm bootpd
|
||||
only). This option is only recognized if
|
||||
.Nm
|
||||
was compiled with the -DDEBUG flag.
|
||||
.TP
|
||||
.I server
|
||||
Specifies the name of a BOOTP server to which
|
||||
.I bootpgw
|
||||
.It Ar server
|
||||
Specify the name of a BOOTP server to which
|
||||
.Nm bootpgw
|
||||
will forward all BOOTREQUEST packets it receives
|
||||
.RI ( bootpgw
|
||||
.Pf ( Nm bootpgw
|
||||
only).
|
||||
.SH OPERATION
|
||||
.PP
|
||||
.El
|
||||
.Sh OPERATION
|
||||
Both
|
||||
.I bootpd
|
||||
.Nm
|
||||
and
|
||||
.I bootpgw
|
||||
.Nm bootpgw
|
||||
operate similarly in that both listen for any packets sent to the
|
||||
.I bootps
|
||||
.Em bootps
|
||||
port, and both simply forward any BOOTREPLY packets.
|
||||
They differ in their handling of BOOTREQUEST packets.
|
||||
.PP
|
||||
.Pp
|
||||
When
|
||||
.I bootpgw
|
||||
.Nm bootpgw
|
||||
is started, it determines the address of a BOOTP server
|
||||
whose name is provided as a command line parameter. When
|
||||
.I bootpgw
|
||||
.Nm bootpgw
|
||||
receives a BOOTREQUEST packet, it sets the "gateway address"
|
||||
and "hop count" fields in the packet and forwards the packet
|
||||
to the BOOTP server at the address determined earlier.
|
||||
Requests are forwarded only if they indicate that
|
||||
the client has been waiting for at least three seconds.
|
||||
.PP
|
||||
.Pp
|
||||
When
|
||||
.I bootpd
|
||||
.Nm
|
||||
is started it reads a configuration file, (normally
|
||||
.IR /etc/bootptab )
|
||||
.Pa /etc/bootptab Ns )
|
||||
that initializes the internal database of known clients and client
|
||||
options. This internal database is reloaded
|
||||
from the configuration file when
|
||||
.I bootpd
|
||||
.Nm
|
||||
receives a hangup signal (SIGHUP) or when it discovers that the
|
||||
configuration file has changed.
|
||||
.PP
|
||||
.Pp
|
||||
When
|
||||
.I bootpd
|
||||
.Nm
|
||||
receives a BOOTREQUEST packet, it
|
||||
.\" checks the modification time of the
|
||||
.\" configuration file and reloads the database if necessary. Then it
|
||||
looks for a database entry matching the client request.
|
||||
If the client is known,
|
||||
.I bootpd
|
||||
.Nm
|
||||
composes a BOOTREPLY packet using the database entry found above,
|
||||
and sends the reply to the client (possibly using a gateway).
|
||||
If the client is unknown, the request is discarded
|
||||
(with a notice if debug > 0).
|
||||
.PP
|
||||
.Pp
|
||||
If
|
||||
.I bootpd
|
||||
.Nm
|
||||
is compiled with the -DDEBUG option, receipt of a SIGUSR1 signal causes
|
||||
it to dump its internal database to the file
|
||||
.I /tmp/bootpd.dump
|
||||
.Pa /tmp/bootpd.dump
|
||||
or the dumpfile specified as a command line parameter.
|
||||
.PP
|
||||
.Pp
|
||||
During initialization, both programs
|
||||
determine the UDP port numbers to be used by calling
|
||||
.I getservbyname
|
||||
.Xr getservbyname 3
|
||||
(which nomally uses
|
||||
.IR /etc/services).
|
||||
.Pa /etc/services Ns ).
|
||||
Two service names (and port numbers) are used:
|
||||
.IP
|
||||
bootps \- BOOTP Server listening port
|
||||
.br
|
||||
bootpc \- BOOTP Client destination port
|
||||
.LP
|
||||
If the port numbers cannot
|
||||
be determined using
|
||||
.I getservbyname
|
||||
.Pp
|
||||
.Dl bootps BOOTP Server listening port
|
||||
.Dl bootpc BOOTP Client destination port
|
||||
.Pp
|
||||
If the port numbers cannot be determined using
|
||||
.Xr getservbyname 3
|
||||
then the values default to bootps=67 and bootpc=68.
|
||||
.SH FILES
|
||||
.TP 20
|
||||
/etc/bootptab
|
||||
.Sh FILES
|
||||
.Bl -tag -width /tmp/bootpd.dump -compact
|
||||
.It Pa /etc/bootptab
|
||||
Database file read by
|
||||
.IR bootpd .
|
||||
.TP
|
||||
/tmp/bootpd.dump
|
||||
.Nm Ns .
|
||||
.It Pa /tmp/bootpd.dump
|
||||
Debugging dump file created by
|
||||
.IR bootpd .
|
||||
.TP
|
||||
/etc/services
|
||||
.Nm Ns .
|
||||
.It Pa /etc/services
|
||||
Internet service numbers.
|
||||
.TP
|
||||
/tftpboot
|
||||
.It Pa /tftpboot
|
||||
Current directory typically used by the TFTP server and
|
||||
.IR bootpd .
|
||||
|
||||
.SH BUGS
|
||||
.Nm Ns .
|
||||
.El
|
||||
.Sh BUGS
|
||||
Individual host entries must not exceed 1024 characters.
|
||||
|
||||
.SH CREDITS
|
||||
.PP
|
||||
.Sh CREDITS
|
||||
This distribution is currently maintained by
|
||||
Walter L. Wimer <walt+@cmu.edu>.
|
||||
.PP
|
||||
.An Walter L. Wimer Aq walt+@cmu.edu .
|
||||
.Pp
|
||||
The original BOOTP server was created by
|
||||
Bill Croft at Stanford University in January 1986.
|
||||
.PP
|
||||
.An Bill Croft
|
||||
at Stanford University in January 1986.
|
||||
.Pp
|
||||
The current version of
|
||||
.I bootpd
|
||||
is primarily the work of David Kovar,
|
||||
Drew D. Perkins, and Walter L. Wimer,
|
||||
.Nm
|
||||
is primarily the work of
|
||||
.An David Kovar ,
|
||||
.An Drew D. Perkins ,
|
||||
and
|
||||
.An Walter L. Wimer ,
|
||||
at Carnegie Mellon University.
|
||||
.TP
|
||||
Enhancements and bug\-fixes have been contributed by:
|
||||
.Pp
|
||||
Enhancements and bug-fixes have been contributed by:
|
||||
.Pp
|
||||
(in alphabetical order)
|
||||
.br
|
||||
Danny Backx <db@sunbim.be>
|
||||
.br
|
||||
John Brezak <brezak@ch.hp.com>
|
||||
.br
|
||||
Frank da Cruz <fdc@cc.columbia.edu>
|
||||
.br
|
||||
David R. Linn <drl@vuse.vanderbilt.edu>
|
||||
.br
|
||||
Jim McKim <mckim@lerc.nasa.gov>
|
||||
.br
|
||||
Gordon W. Ross <gwr@mc.com>
|
||||
.br
|
||||
Jason Zions <jazz@hal.com>
|
||||
.SH "SEE ALSO"
|
||||
.LP
|
||||
bootptab(5), inetd(8), tftpd(8)
|
||||
.LP
|
||||
.Pp
|
||||
.An Danny Backx Aq db@sunbim.be
|
||||
.An John Brezak Aq brezak@ch.hp.com
|
||||
.An Frank da Cruz Aq fdc@cc.columbia.edu
|
||||
.An David R. Linn Aq drl@vuse.vanderbilt.edu
|
||||
.An Jim McKim Aq mckim@lerc.nasa.gov
|
||||
.An Gordon W. Ross Aq gwr@mc.com
|
||||
.An Jason Zions Aq jazz@hal.com .
|
||||
.Sh "SEE ALSO"
|
||||
.Xr bootptab 5 ,
|
||||
.Xr inetd 8 ,
|
||||
.Xr tftpd 8
|
||||
.Pp
|
||||
DARPA Internet Request For Comments:
|
||||
.TP 10
|
||||
RFC951
|
||||
.Bl -tag -width RFC1533 -compact
|
||||
.It RFC951
|
||||
Bootstrap Protocol
|
||||
.TP 10
|
||||
RFC1532
|
||||
.It RFC1532
|
||||
Clarifications and Extensions for the Bootstrap Protocol
|
||||
.TP 10
|
||||
RFC1533
|
||||
.It RFC1533
|
||||
DHCP Options and BOOTP Vendor Extensions
|
||||
.El
|
||||
|
||||
@ -1,346 +1,359 @@
|
||||
.\" Copyright (c) 1988, 1989, 1991 Carnegie Mellon University
|
||||
.\"
|
||||
.\" $Header: $
|
||||
.\" $Id$
|
||||
.\"
|
||||
.TH BOOTPTAB 5 "October 31, 1991" "Carnegie Mellon University"
|
||||
.UC 6
|
||||
|
||||
.SH NAME
|
||||
bootptab \- Internet Bootstrap Protocol server database
|
||||
.SH DESCRIPTION
|
||||
.Dd October 31, 1991
|
||||
.Dt BOOTPTAB 5
|
||||
.Os "Carnegie Mellon University"
|
||||
.Sh NAME
|
||||
.Nm bootptab
|
||||
.Nd Internet Bootstrap Protocol server database
|
||||
.Sh DESCRIPTION
|
||||
The
|
||||
.I bootptab
|
||||
.Nm
|
||||
file is the configuration database file for
|
||||
.IR bootpd ,
|
||||
.Xr bootpd 8 ,
|
||||
the Internet Bootstrap Protocol server.
|
||||
It's format is similar to that of
|
||||
.IR termcap (5)
|
||||
.Xr termcap 5
|
||||
in which two-character case-sensitive tag symbols are used to
|
||||
represent host parameters. These parameter declarations are separated by
|
||||
colons (:), with a general format of:
|
||||
.PP
|
||||
.I " hostname:tg=value. . . :tg=value. . . :tg=value. . . ."
|
||||
.PP
|
||||
.Pp
|
||||
.Dl "hostname:tg=value. . . :tg=value. . . :tg=value. . . ."
|
||||
.Pp
|
||||
where
|
||||
.I hostname
|
||||
.Em hostname
|
||||
is the actual name of a bootp client (or a "dummy entry"), and
|
||||
.I tg
|
||||
.Em tg
|
||||
is a two-character tag symbol. Dummy entries have an invalid hostname
|
||||
(one with a "." as the first character) and are used to provide
|
||||
default values used by other entries via the
|
||||
.B tc=.dummy-entry
|
||||
.Em tc=.dummy-entry
|
||||
mechanism. 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 (i.e.
|
||||
.RI : tg :).
|
||||
.Em :tg: Ns ).
|
||||
The currently recognized tags are:
|
||||
.PP
|
||||
.br
|
||||
bf Bootfile
|
||||
.br
|
||||
bs Bootfile size in 512-octet blocks
|
||||
.br
|
||||
cs Cookie server address list
|
||||
.br
|
||||
df Merit dump file
|
||||
.br
|
||||
dn Domain name
|
||||
.br
|
||||
ds Domain name server address list
|
||||
.br
|
||||
ef Extension file
|
||||
.br
|
||||
gw Gateway address list
|
||||
.br
|
||||
ha Host hardware address
|
||||
.br
|
||||
hd Bootfile home directory
|
||||
.br
|
||||
hn Send client's hostname to client
|
||||
.br
|
||||
ht Host hardware type (see Assigned Numbers RFC)
|
||||
.br
|
||||
im Impress server address list
|
||||
.br
|
||||
ip Host IP address
|
||||
.br
|
||||
lg Log server address list
|
||||
.br
|
||||
lp LPR server address list
|
||||
.br
|
||||
ns IEN-116 name server address list
|
||||
.br
|
||||
nt NTP (time) Server (RFC 1129)
|
||||
.br
|
||||
ra Reply address override
|
||||
.br
|
||||
rl Resource location protocol server address list
|
||||
.br
|
||||
rp Root path to mount as root
|
||||
.br
|
||||
sa TFTP server address client should use
|
||||
.br
|
||||
sm Host subnet mask
|
||||
.br
|
||||
sw Swap server address
|
||||
.br
|
||||
tc Table continuation (points to similar "template" host entry)
|
||||
.br
|
||||
td TFTP root directory used by "secure" TFTP servers
|
||||
.br
|
||||
to Time offset in seconds from UTC
|
||||
.br
|
||||
ts Time server address list
|
||||
.br
|
||||
vm Vendor magic cookie selector
|
||||
.br
|
||||
yd YP (NIS) domain name
|
||||
.br
|
||||
ys YP (NIS) server address
|
||||
|
||||
.PP
|
||||
.Pp
|
||||
.Bl -tag -width xxx -compact
|
||||
.It bf
|
||||
Bootfile
|
||||
.It bs
|
||||
Bootfile size in 512-octet blocks
|
||||
.It cs
|
||||
Cookie server address list
|
||||
.It df
|
||||
Merit dump file
|
||||
.It dn
|
||||
Domain name
|
||||
.It ds
|
||||
Domain name server address list
|
||||
.It ef
|
||||
Extension file
|
||||
.It gw
|
||||
Gateway address list
|
||||
.It ha
|
||||
Host hardware address
|
||||
.It hd
|
||||
Bootfile home directory
|
||||
.It hn
|
||||
Send client's hostname to client
|
||||
.It ht
|
||||
Host hardware type (see Assigned Numbers RFC)
|
||||
.It im
|
||||
Impress server address list
|
||||
.It ip
|
||||
Host IP address
|
||||
.It lg
|
||||
Log server address list
|
||||
.It lp
|
||||
LPR server address list
|
||||
.It ns
|
||||
IEN-116 name server address list
|
||||
.It nt
|
||||
NTP (time) Server (RFC 1129)
|
||||
.It ra
|
||||
Reply address override
|
||||
.It rl
|
||||
Resource location protocol server address list
|
||||
.It rp
|
||||
Root path to mount as root
|
||||
.It sa
|
||||
TFTP server address client should use
|
||||
.It sm
|
||||
Host subnet mask
|
||||
.It sw
|
||||
Swap server address
|
||||
.It tc
|
||||
Table continuation (points to similar "template" host entry)
|
||||
.It td
|
||||
TFTP root directory used by "secure" TFTP servers
|
||||
.It to
|
||||
Time offset in seconds from UTC
|
||||
.It ts
|
||||
Time server address list
|
||||
.It vm
|
||||
Vendor magic cookie selector
|
||||
.It yd
|
||||
YP (NIS) domain name
|
||||
.It ys
|
||||
YP (NIS) server address
|
||||
.El
|
||||
.Pp
|
||||
There is also a generic tag,
|
||||
.RI T n ,
|
||||
.Pf T Em n ,
|
||||
where
|
||||
.I n
|
||||
.Em n
|
||||
is an RFC1084 vendor field tag number. Thus it is possible to immediately
|
||||
take advantage of future extensions to RFC1084 without being forced to modify
|
||||
.I bootpd
|
||||
.Nm 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
|
||||
numbers or as a quoted string of
|
||||
.Tn ASCII
|
||||
characters. The length of the generic
|
||||
data is automatically determined and inserted into the proper field(s) of the
|
||||
RFC1084-style bootp reply.
|
||||
.PP
|
||||
.Pp
|
||||
The following tags take a whitespace-separated list of IP addresses:
|
||||
.BR cs ,
|
||||
.BR ds ,
|
||||
.BR gw ,
|
||||
.BR im ,
|
||||
.BR lg ,
|
||||
.BR lp ,
|
||||
.BR ns ,
|
||||
.BR nt ,
|
||||
.BR ra ,
|
||||
.BR rl ,
|
||||
.Em cs ,
|
||||
.Em ds ,
|
||||
.Em gw ,
|
||||
.Em im ,
|
||||
.Em lg ,
|
||||
.Em lp ,
|
||||
.Em ns ,
|
||||
.Em nt ,
|
||||
.Em ra ,
|
||||
.Em rl ,
|
||||
and
|
||||
.BR ts .
|
||||
.Em ts .
|
||||
The
|
||||
.BR ip ,
|
||||
.BR sa ,
|
||||
.BR sw ,
|
||||
.BR sm ,
|
||||
.Em ip ,
|
||||
.Em sa ,
|
||||
.Em sw ,
|
||||
.Em sm ,
|
||||
and
|
||||
.B ys
|
||||
.Em ys
|
||||
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').
|
||||
Any IP addresses may alternatively be specified as a hostname, causing
|
||||
.I bootpd
|
||||
to lookup the IP address for that host name using gethostbyname(3).
|
||||
.Nm bootpd
|
||||
to lookup the IP address for that host name using
|
||||
.Xr gethostbyname 3 .
|
||||
If the
|
||||
.B ip
|
||||
.Em ip
|
||||
tag is not specified,
|
||||
.I bootpd
|
||||
.Nm bootpd
|
||||
will determine the IP address using the entry name as the host name.
|
||||
(Dummy entries use an invalid host name to avoid automatic IP lookup.)
|
||||
.PP
|
||||
.Pp
|
||||
The
|
||||
.B ht
|
||||
.Em ht
|
||||
tag specifies the hardware type code as either an unsigned decimal, octal, or
|
||||
hexadecimal integer or one of the following symbolic names:
|
||||
.B ethernet
|
||||
.Em ethernet
|
||||
or
|
||||
.B ether
|
||||
.Em ether
|
||||
for 10Mb Ethernet,
|
||||
.B ethernet3
|
||||
.Em ethernet3
|
||||
or
|
||||
.B ether3
|
||||
.Em ether3
|
||||
for 3Mb experimental Ethernet,
|
||||
.BR ieee802 ,
|
||||
.BR tr ,
|
||||
.Em ieee802 ,
|
||||
.Em tr ,
|
||||
or
|
||||
.B token-ring
|
||||
.Em token-ring
|
||||
for IEEE 802 networks,
|
||||
.B pronet
|
||||
.Em pronet
|
||||
for Proteon ProNET Token Ring, or
|
||||
.BR chaos ,
|
||||
.BR arcnet ,
|
||||
.Em chaos ,
|
||||
.Em arcnet ,
|
||||
or
|
||||
.B ax.25
|
||||
.Em ax.25
|
||||
for Chaos, ARCNET, and AX.25 Amateur Radio networks, respectively.
|
||||
The
|
||||
.B ha
|
||||
.Em ha
|
||||
tag takes a hardware address which may be specified as a host name
|
||||
or in numeric form. Note that the numeric form
|
||||
.I must
|
||||
.Em must
|
||||
be specified in hexadecimal; optional periods and/or a leading '0x' may be
|
||||
included for readability. The
|
||||
.B ha
|
||||
.Em ha
|
||||
tag must be preceded by the
|
||||
.B ht
|
||||
.Em ht
|
||||
tag (either explicitly or implicitly; see
|
||||
.B tc
|
||||
.Em tc
|
||||
below).
|
||||
If the hardware address is not specified and the type is specified
|
||||
as either "ethernet" or "ieee802", then
|
||||
.I bootpd
|
||||
will try to determine the hardware address using ether_hton(3).
|
||||
.PP
|
||||
The hostname, home directory, and bootfile are ASCII strings which may be
|
||||
.Nm bootpd
|
||||
will try to determine the hardware address using
|
||||
.Xr ether_hostton 3 .
|
||||
.Pp
|
||||
The hostname, home directory, and bootfile are
|
||||
.Tn ASCII
|
||||
strings which may be
|
||||
optionally surrounded by double quotes ("). The client's request and the
|
||||
values of the
|
||||
.B hd
|
||||
.Em hd
|
||||
and
|
||||
.B bf
|
||||
.Em bf
|
||||
symbols determine how the server fills in the bootfile field of the bootp
|
||||
reply packet.
|
||||
.PP
|
||||
.Pp
|
||||
If the client provides a file name it is left as is.
|
||||
Otherwise, if the
|
||||
.B bf
|
||||
.Em bf
|
||||
option is specified its value is copied into the reply packet.
|
||||
If the
|
||||
.B hd
|
||||
.Em hd
|
||||
option is specified as well, its value is prepended to the
|
||||
boot file copied into the reply packet.
|
||||
The existence of the boot file is checked only if the
|
||||
.BR bs =auto
|
||||
.Em bs Ns =auto
|
||||
option is used (to determine the boot file size).
|
||||
A reply may be sent whether or not the boot file exists.
|
||||
.PP
|
||||
.Pp
|
||||
Some newer versions of
|
||||
.I tftpd
|
||||
.Xr tftpd 8
|
||||
provide a security feature to change their root directory using
|
||||
the
|
||||
.IR chroot (2)
|
||||
.Xr chroot 2
|
||||
system call.
|
||||
The
|
||||
.B td
|
||||
.Em td
|
||||
tag may be used to inform
|
||||
.I bootpd
|
||||
.Nm bootpd
|
||||
of this special root directory used by
|
||||
.IR tftpd .
|
||||
.Nm tftpd .
|
||||
(One may alternatively use the
|
||||
.I bootpd
|
||||
"-c chdir" option.)
|
||||
.Nm bootpd
|
||||
.Fl c Ar chdir
|
||||
option.)
|
||||
The
|
||||
.B hd
|
||||
.Em hd
|
||||
tag is actually relative to the root directory specified by the
|
||||
.B td
|
||||
.Em td
|
||||
tag.
|
||||
For example, if the real absolute path to your BOOTP client bootfile is
|
||||
/tftpboot/bootfiles/bootimage, and
|
||||
.IR tftpd
|
||||
uses /tftpboot as its "secure" directory, then specify the following in
|
||||
.IR bootptab :
|
||||
.PP
|
||||
.br
|
||||
:td=/tftpboot:hd=/bootfiles:bf=bootimage:
|
||||
.PP
|
||||
If your bootfiles are located directly in /tftpboot, use:
|
||||
.PP
|
||||
.br
|
||||
:td=/tftpboot:hd=/:bf=bootimage:
|
||||
.PP
|
||||
.Pa /tftpboot/bootfiles/bootimage ,
|
||||
and
|
||||
.Nm tftpd
|
||||
uses
|
||||
.Pa /tftpboot
|
||||
as its "secure" directory, then specify the following in
|
||||
.Pa bootptab :
|
||||
.Pp
|
||||
.Dl :td=/tftpboot:hd=/bootfiles:bf=bootimage:
|
||||
.Pp
|
||||
If your bootfiles are located directly in
|
||||
.Pa /tftpboot ,
|
||||
use:
|
||||
.Pp
|
||||
.Dl :td=/tftpboot:hd=/:bf=bootimage:
|
||||
.Pp
|
||||
The
|
||||
.B sa
|
||||
.Em sa
|
||||
tag may be used to specify the IP address of the particular TFTP server
|
||||
you wish the client to use. In the absence of this tag,
|
||||
.I bootpd
|
||||
.Nm bootpd
|
||||
will tell the client to perform TFTP to the same machine
|
||||
.I bootpd
|
||||
.Nm bootpd
|
||||
is running on.
|
||||
.PP
|
||||
.Pp
|
||||
The time offset
|
||||
.B to
|
||||
.Em to
|
||||
may be either a signed decimal integer specifying the client's
|
||||
time zone offset in seconds from UTC, or the keyword
|
||||
.B auto
|
||||
.Em auto
|
||||
which uses the server's time zone offset. Specifying the
|
||||
.B to
|
||||
.Em to
|
||||
symbol as a boolean has the same effect as specifying
|
||||
.B auto
|
||||
.Em auto
|
||||
as its value.
|
||||
.PP
|
||||
.Pp
|
||||
The bootfile size
|
||||
.B bs
|
||||
.Em bs
|
||||
may be either a decimal, octal, or hexadecimal integer specifying the size of
|
||||
the bootfile in 512-octet blocks, or the keyword
|
||||
.B auto
|
||||
.Em auto
|
||||
which causes the server to automatically calculate the bootfile size at each
|
||||
request. As with the time offset, specifying the
|
||||
.B bs
|
||||
.Em bs
|
||||
symbol as a boolean has the same effect as specifying
|
||||
.B auto
|
||||
.Em auto
|
||||
as its value.
|
||||
.PP
|
||||
.Pp
|
||||
The vendor magic cookie selector (the
|
||||
.B vm
|
||||
.Em vm
|
||||
tag) may take one of the following keywords:
|
||||
.B auto
|
||||
.Em auto
|
||||
(indicating that vendor information is determined by the client's request),
|
||||
.B rfc1048
|
||||
.Em rfc1048
|
||||
or
|
||||
.B rfc1084
|
||||
.Em rfc1084
|
||||
(which always forces an RFC1084-style reply), or
|
||||
.B cmu
|
||||
.Em cmu
|
||||
(which always forces a CMU-style reply).
|
||||
.PP
|
||||
.Pp
|
||||
The
|
||||
.B hn
|
||||
.Em hn
|
||||
tag is strictly a boolean tag; it does not take the usual equals-sign and
|
||||
value. It's presence indicates that the hostname should be sent to RFC1084
|
||||
clients.
|
||||
.I Bootpd
|
||||
.Nm Bootpd
|
||||
attempts to send the entire hostname as it is specified in the configuration
|
||||
file; if this will not fit into the reply packet, the name is shortened to
|
||||
just the host field (up to the first period, if present) and then tried.
|
||||
In no case is an arbitrarily-truncated hostname sent (if nothing reasonable
|
||||
will fit, nothing is sent).
|
||||
.PP
|
||||
.Pp
|
||||
Often, many host entries share common values for certain tags (such as name
|
||||
servers, etc.). Rather than repeatedly specifying these tags, a full
|
||||
specification can be listed for one host entry and shared by others via the
|
||||
.B tc
|
||||
.Em tc
|
||||
(table continuation) mechanism.
|
||||
Often, the template entry is a dummy host which doesn't actually exist and
|
||||
never sends bootp requests. This feature is similar to the
|
||||
.B tc
|
||||
.Em tc
|
||||
feature of
|
||||
.IR termcap (5)
|
||||
.Xr termcap 5
|
||||
for similar terminals. Note that
|
||||
.I bootpd
|
||||
.Nm bootpd
|
||||
allows the
|
||||
.B tc
|
||||
.Em tc
|
||||
tag symbol to appear anywhere in the host entry, unlike
|
||||
.I termcap
|
||||
.Pa termcap
|
||||
which requires it to be the last tag. Information explicitly specified for a
|
||||
host always overrides information implied by a
|
||||
.B tc
|
||||
.Em tc
|
||||
tag symbol, regardless of its location within the entry. The
|
||||
value of the
|
||||
.B tc
|
||||
.Em tc
|
||||
tag may be the hostname or IP address of any host entry
|
||||
previously listed in the configuration file.
|
||||
.PP
|
||||
.Pp
|
||||
Sometimes it is necessary to delete a specific tag after it has been inferred
|
||||
via
|
||||
.BR tc .
|
||||
.Em tc .
|
||||
This can be done using the construction
|
||||
.IB tag @
|
||||
.Em tag Ns @
|
||||
which removes the effect of
|
||||
.I tag
|
||||
.Em tag
|
||||
as in
|
||||
.IR termcap (5).
|
||||
.Xr termcap 5 .
|
||||
For example, to completely undo an IEN-116 name server specification, use
|
||||
":ns@:" at an appropriate place in the configuration entry. After removal
|
||||
.Em :ns@:
|
||||
at an appropriate place in the configuration entry. After removal
|
||||
with
|
||||
.BR @ ,
|
||||
.Em @ ,
|
||||
a tag is eligible to be set again through the
|
||||
.B tc
|
||||
.Em tc
|
||||
mechanism.
|
||||
.PP
|
||||
.Pp
|
||||
Blank lines and lines beginning with "#" 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
|
||||
@ -348,11 +361,11 @@ entry may be extended over multiple lines if the lines end with a backslash
|
||||
may appear in any order, with the following exceptions: the hostname must be
|
||||
the very first field in an entry, and the hardware type must precede the
|
||||
hardware address.
|
||||
.PP
|
||||
.Pp
|
||||
An example
|
||||
.I /etc/bootptab
|
||||
.Pa /etc/bootptab
|
||||
file follows:
|
||||
.PP
|
||||
.Pp
|
||||
.nf
|
||||
# Sample bootptab file (domain=andrew.cmu.edu)
|
||||
|
||||
@ -385,11 +398,12 @@ file follows:
|
||||
mtoliver:ht=1:ha=00DD00FE1600:tc=.default:
|
||||
|
||||
.fi
|
||||
.SH FILES
|
||||
/etc/bootptab
|
||||
|
||||
.SH "SEE ALSO"
|
||||
.br
|
||||
bootpd(8), tftpd(8),
|
||||
.br
|
||||
.Sh FILES
|
||||
.Bl -tag -width /etc/bootptab -compact
|
||||
.It /etc/bootptab
|
||||
.El
|
||||
.Sh "SEE ALSO"
|
||||
.Xr bootpd 8 ,
|
||||
.Xr tftpd 8
|
||||
.Pp
|
||||
DARPA Internet Request For Comments RFC951, RFC1048, RFC1084, Assigned Numbers
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user