rbootd(8) [freebsd man page]

RBOOTD(8)						    BSD System Manager's Manual 						 RBOOTD(8)

NAME

     rbootd -- HP remote boot server

SYNOPSIS

     rbootd [-ad] [-i interface] [config_file]

DESCRIPTION

     The rbootd 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, rbootd 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 rbootd in debug mode.	Packets sent and received are displayed to the terminal.

     -i interface
	     Service boot requests on specified interface.  If unspecified, rbootd 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 rbootd 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 addr	 boot file(s)	     comments
     #
     08:00:09:0:66:ad	 SYSHPBSD	     # snake (4.3BSD)
     08:00:09:0:59:5b			     # vandy (anything)
     8::9:1:C6:75	 SYSHPBSD,SYSHPUX    # jaguar (either)

     The rbootd 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:

	     SIGHUP   Drop all active connections and reconfigure.

	     SIGUSR1  Turn on debugging, do nothing if already on.

	     SIGUSR2  Turn off debugging, do nothing if already off.

FILES

     /dev/bpf#		  packet-filter device
     /etc/rbootd.conf	  configuration file
     /tmp/rbootd.dbg	  debug output
     /usr/mdec/rbootd	  directory containing boot files
     /var/run/rbootd.pid  process id

SEE ALSO

     kill(1), socket(2), signal(3), syslog(3)

BUGS

     If multiple servers are started on the same interface, each will receive and respond to the same boot packets.

BSD
								 December 11, 1993							       BSD

NDBOOTD(8)						    BSD System Manager's Manual 						NDBOOTD(8)

NAME

     ndbootd -- Sun Network Disk (ND) Protocol server

SYNOPSIS

     ndbootd [-s boot2] [-i interface] [-w windowsize] [-d] boot1

DESCRIPTION

     ndbootd is a server which supports the Sun Network Disk (ND) Protocol.  This protocol was designed by Sun before they designed NFS.  ND sim-
     ply makes the raw blocks of a disk available to network clients.  Contrast this with the true namespace and file abstractions that NFS pro-
     vides.

     The only reason you're likely to encounter ND nowadays is if you have an old Sun 2 machine, like the 2/120 or 2/50.  The Sun 2 PROMs can only
     use ND to boot over the network.  (Later, the Sun 3 PROMs would use RARP and TFTP to boot over the network.)

     ndbootd is a very simple ND server that only supports client reads for booting.  It exports a disk that the clients consider to be /dev/ndp0
     (ND public unit zero).  The disk is available only to clients that are listed in /etc/ethers and have valid hostnames.  (Sun 2 PROMs don't do
     RARP, but they do learn their IP address from the first ND response they receive from the server.)

     boot1 is a file containing the mandatory first-stage network boot program, typically /usr/mdec/bootyy.  The layout of the exported disk is:

	   o   block 0: normally a Sun disklabel (but ignored by the PROM)

	   o   blocks 1-15: the first-stage network boot program

     With the -s boot2 option, ndbootd will also make a second-stage network boot program available to clients, typically /usr/mdec/netboot.  When
     boot2 is a filename, that file is the single second-stage network boot program to be served to all clients.

     When boot2 is a directory name, typically /tftpboot, ndbootd finds a client's second-stage network boot program by turning its IP address
     into a filename in that directory, in the same manner later Sun 3 PROMs do when TFTPing (i.e., if a client has IP address 192.168.1.10,
     ndbootd expects to find /tftpboot/C0A8010A.SUN2 ).

     When used in this last manner with an ND-aware first-stage boot program, ndbootd serves the same purpose in the Sun 2 netboot process as
     tftpd(8) serves in the Sun 3 netboot process.

     Any second-stage network boot program always begins at block 16 of the exported disk, regardless of the length of the first-stage network
     boot program.

     All first- and second-stage network boot programs must have all executable headers stripped off; they must be raw binary programs.

     The remaining options are:

     -i interface
		Only listen for ND clients on interface interface.  Normally ndbootd listens for clients on the first non-loopback IP interface
		that is up and running.

     -w windowsize
		This adjusts the window size of the ND protocol.  This is the number of 1-kilobyte packets that can be transmitted before waiting
		for an acknowledgement.  Defaults to 6.

     -d 	Run in debug mode.  Debugging output goes to standard error and the server will not fork.

FILES

     /etc/ethers
     /etc/hosts

SEE ALSO

     tftpd(8)

BUGS

     Whether or not there is a second-stage network boot program, the exported disk appears to all clients to have infinite length.  The content
     of all blocks not used by the first- or second-stage network boot programs is undefined.  All client reads of undefined blocks are silently
     allowed by the server.

BSD
								    May 9, 2001 							       BSD