rpld(1M)
NAME
rpld - x86 Network Booting RPL (Remote Program Load) Server
SYNOPSIS
/usr/sbin/rpld [-fdDMblgz] interface
/usr/sbin/rpld -a [-fdDMblgz]
DESCRIPTION
The RPL server provides network booting functionality to x86
clients by listening to boot requests from them according to
the RPL protocol specifications. Boot requests can be gen-
erated by clients using the boot floppy supplied in the x86
distribution. Once the request has been received, the
server validates the client and adds it to its internal ser-
vice list. Subsequent requests from the client to download
bootfiles will result in the sending of data frames from the
server to the client specifying where to load the boot pro-
gram in memory. When all the bootfiles have been down-
loaded, the server specifies where to start execution to
initiate the boot process.
In the first synopsis, the interface parameter names the
network interface upon which rpld is to listen for requests.
For example:
/usr/sbin/rpld /dev/le0
/usr/sbin/rpld /dev/smc0
In the second synopsis, rpld locates all of the network
interfaces present on the system and starts a daemon process
for each one.
The server starts by reading the default configuration file,
or an alternate configuration file if one is specified. If
no configuration file can be found, internal default values
will be used. Alternatively, command line options are
available to override any of the values in the configuration
file. After the configuration options are set, it then
opens the network interface as specified in the command line
and starts listening to RPL boot requests.
Network boot x86 clients have to have information pre-
configured on a server for the RPL server to validate and
serve them. This involves putting configuration information
in both the ethers(4) and the bootparams(4) databases. The
ethers database contains a translation from the physical
node address to the IP address of the clients and is nor-
mally used by the RARP server. The bootparams database
stores all other information needed for booting off this
client, such as the number of bootfiles and the file names
of the various boot components. Both databases can be
looked up by the RPL server through NIS. See the sub-
section Client Configuration for information on how to set
up these databases.
To assist in the administration and maintenance of the net-
work boot activity, there are two run-time signals that the
server will accept to change some run-time parameters and
print out useful status information. See the sub-section
Signals for details.
The RPL server is not limited to the ability to boot only
x86 clients. If properly configured, the server should be
able to download any bootfiles to the clients.
Client Configuration
The following configuration information is specific to boot-
ing x86 clients.
In order to allow clients to boot x86 from across the net-
work, the client's information has to be pre-configured in
two databases: ethers(4) and bootparams(4). Both databases
can be accessed through NIS. Refer to Solaris 9 9/04 Ins-
tallation Guide for information on how to configure a disk-
less x86 client. The discussion contained in the rest of
this section is provided for your information only and
should not be performed manually.
The ethers database contains a translation table to convert
the physical node address to the IP address of the client.
Therefore, an IP address must be assigned to the client (if
this has not been done already), the node address of the
client must be obtained, and then this information needs to
be entered in the ethers database.
The bulk of the configuration is done in the bootparams
database. This is a free-format database that essentially
contains a number of keyword-value string pairs. A number
of keywords have been defined for specific purposes, like
the bootparams RPC in bootparamd(1M). Three more keywords
have been defined for the RPL server. They are numboot-
files, bootfile, and bootaddr. All three keywords must be
in lowercase letters with no spaces before or after the
equals symbol following the keyword.
numbootfiles
Specifies the number of files to be downloaded to the
network boot client. The format of this option is:
numbootfiles=n
Always use numbootfiles=3 to boot x86 across the
network.
bootfile
Specifies the path name of the bootfile to be down-
loaded and where in memory to start loading the boot-
file. A complete path name should be used. For exam-
ple, assuming the client's IP address is
129.181.32.15:
bootfile=/rplboot/129.181.32.15.hw.com:45000
bootfile=/rplboot/129.181.32.15.glue.com:35000
bootfile=/rplboot/129.181.32.15.inetboot=8000
The path name following the equals symbol specifies
the bootfile to be downloaded, and the hex address
following the colon (:) is the absolute address of the
memory location to start loading that bootfile. These
addresses should be in the range of 7c00 to a0000
(i.e., the base 640K range excluding the interrupt
vector and BIOS data areas). Address 45000 for this
hw.com bootfile is also a suggested value and if pos-
sible should not be changed. The address of 35000 for
glue.com is a suggested value that, if possible,
should not be changed. The address of 8000 for inet-
boot is an absolute requirement and should never be
changed.
These files, when created following the procedures in the
Solaris 9 9/04 Installation Guide are actually symbolic
links to to the real file to be downloaded to the client.
hw.com is linked to a special driver that corresponds to
the network interface card of the client. glue.com and inet-
boot are generic to all network boot clients.
The order of these bootfile lines is not significant, but
because problems have been found with certain boot PROMs, it
is highly recommended that the bootfile lines be ordered in
descending order of the load addresses.
bootaddr
The absolute address in memory to start executing
after all the bootfiles have been downloaded. This
address should always correspond to the address where
glue.com is being loaded. If possible, always use:
bootaddr=35000
OPTIONS
The following options are supported:
-b background_mode
Specify 1 to run the server in the background and
relinquish the controlling terminal, or 0 to run in
the foreground without relinquishing the controlling
terminal.
This option corresponds to the BackGround setting in
the configuration file. If you have specified that
the error or warning messages be sent to standard out-
put in the configuration file or by using the -D
option above, the server cannot be run in background
mode. Doing so will cause the server to exit after
announcing the error.
-d debug_level
Specify a level of 0 if you do not want any error or
warning messages to be generated, or a level from 1 to
9 for increasing amounts of messages.
This option corresponds to the DebugLevel setting in
the configuration file. The default value is 0. Note
that it is best to limit the level to 8 or below; use
of level 9 may generate so many debug messages that
the performance of the RPL server may be impacted.
-D debug_destination
Specify 0 to send error or warning messages to stan-
dard output, 1 to syslogd, and 2 to the log file.
This option corresponds to the DebugDest setting in
the configuration file. The default value is 2.
-f config_filename
Use this to specify a configuration file name other
than the system default /etc/rpld.conf file.
-g delay_granularity
This corresponds to the DelayGran setting in the con-
figuration file. If retransmission requests from
clients do occur, the delay granularity factor will be
used to adjust the delay count for this client upwards
or downwards. If the retransmission request is caused
by data overrun, the delay count will be incremented
by delay granularity units to increase the delay
between data frames. If the retransmission request is
caused by sending data too slowly, this will be used
to adjust the delay count downwards to shorten the
delay. Eventually the server will settle at the delay
count value that works best with the speed of the
client and no retransmission request will be needed.
The default value is 2.
-l log_filename
Specify an alternate log file name to hold the error
or warning messages in connection with the -D 2 option
or the configuration file DebugDest = 2 setting. This
option corresponds to the LogFile setting in the con-
figuration file. The default is /var/spool/rpld.log.
-M maximum_clients
Specify the maximum number of simultaneous network
boot clients to be served. This option corresponds to
the MaxClients setting in the configuration file. A
value of -1 means unlimited, and the actual number
will depend on available system resources. The
default value is -1.
-s start_delay_count
This option corresponds to the StartDelay setting in
the configuration file. Specify the number of delay
units between outgoing data frames sent to clients to
avoid retransmission requests from them. Using the
LLC type 1 protocol, data transfer is a one-way,
best-effort delivery mechanism. The server, without
any type of delay mechanism, can overrun the client by
sending data frames too quickly. Therefore, a vari-
able delay is built into the server to limit the speed
of sending data to the clients, thus avoiding the
clients sending back retransmission requests. This
value should be machine environment specific. If you
have a fast server machine but slow client machines,
you may want to set a large start delay count. If you
have comparable server and client machines, the delay
count may be set to 1. The delay is only approximate
and should not be taken as an accurate measure of
time. There is no specific correlation between the
delay unit and the actual time of delay. The default
value is 20.
-z frame_size
This option corresponds to the FrameSize setting in
the configuration file. This specifies the size of
the data frames used to send data to the clients.
This is limited by the underlying physical medium.
For ethernet/802.3, the maximum physical frame size
is 1500 octets. The default value is 1500. Note that
the protocol overhead of LLC1 and RPL is 32 octets,
resulting in a maximum data length of 1468 octets.
Signals
The RPL server accepts two signals to change run-time param-
eters and display status information, respectively:
HANGUP
This will cause the RPL server to reread the default
configuration file /etc/rpld.conf or an alternate con-
figuration file if one is specified when the server is
started. New values of certain parameters can be used
immediately, such as DebugLevel, DebugDest, LogFile,
DelayGran, and FrameSize. For MaxClients, if the
server is already serving more than the new value, the
server will not accept additional boot requests until
the number has fallen below the MaxClients parameter.
For StartDelay, this will only affect new boot
requests. All the existing delay counts for the vari-
ous clients in service will not be affected. Finally,
the BackGround parameter will have no effect once the
server has been running. You cannot change the mode
of service without first killing the server and then
restarting it.
USR1 This signal will cause the server to dump all the
parameter values and the status of each individual
boot client to the destination specified by DebugDest.
FILES
/usr/sbin/rpld
/etc/rpld.conf
/var/spool/rpld.log
/etc/ethers
/etc/bootparams
/rplboot
ATTRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| Architecture | x86 |
|_____________________________|_____________________________|
| Availability | SUNWbsu |
|_____________________________|_____________________________|
SEE ALSO
bootparamd(1M), in.rarpd(1M), bootparams(4), ethers(4),
nsswitch.conf(4), rpld.conf(4), attributes(5)
Solaris 9 9/04 Installation Guide
Man(1) output converted with
man2html