Интерактивная система просмотра системных руководств (man-ов)
rbootd (8)
>> rbootd (8) ( FreeBSD man: Команды системного администрирования )
BSD mandoc
NAME
rbootd
- HP remote boot server
SYNOPSIS
[-ad
]
[-i interface
]
[config_file]
DESCRIPTION
The
utility services boot requests from Hewlett-Packard workstations over a
local area network.
All boot files must reside in the boot file directory; further, if a
client supplies path information in its boot request, it will be silently
stripped away before processing.
By default,
only responds to requests from machines listed in its configuration file.
The options are as follows:
-a
Respond to boot requests from any machine.
The configuration file is ignored if this option is specified.
-d
Run
in debug mode.
Packets sent and received are displayed to the terminal.
-i interface
Service boot requests on specified interface.
If unspecified,
searches the system interface list for the lowest numbered, configured
``up'' interface (excluding loopback).
Ties are broken by choosing the earliest match.
Specifying
config_file
on the command line causes
to use a different configuration file from the default.
The configuration file is a text file where each line describes a particular
machine.
A line must start with a machine's Ethernet address followed by an optional
list of boot file names.
An Ethernet address is specified in hexadecimal with each of its six octets
separated by a colon.
The boot file names come from the boot file directory.
The ethernet address and boot file(s) must be separated by white-space
and/or comma characters.
A pound sign causes the remainder of a line to be ignored.
Here is a sample configuration file:
#
"# ethernet addrboot file(s)comments
#
"08:00:09:0:66:adSYSHPBSD# snake (4.3BSD)
"08:00:09:0:59:5b# vandy (anything)
"8::9:1:C6:75SYSHPBSD,SYSHPUX# jaguar (either)
The
utility logs status and error messages via
syslog(3).
A startup message is always logged, and in the case of fatal errors (or
deadly signals) a message is logged announcing the server's termination.
In general, a non-fatal error is handled by ignoring the event that caused
it (e.g. an invalid Ethernet address in the config file causes that line
to be invalidated).
The following signals have the specified effect when sent to the server
process using the
kill(1)
command:
