3 dhcpd, dhcpleases, rarpd, tftpd \- Internet booting
37 These programs support booting over the Internet.
38 They should all be run on the same server to
39 allow other systems to be booted.
43 are used to boot everything;
45 is an extra piece just for Suns.
53 Clients use these protocols to obtain configuration information.
54 This information comes from attribute/value pairs in the network database
59 DHCP requests are honored both for static addresses found in
60 the NDB and for dynamic addresses listed in the command line.
61 DHCP requests are honored if either:
63 \- there exists an NDB entry
64 containing both the ethernet address of the requester and
65 an IP address on the originating network or subnetwork.
67 \- a free dynamic address exists on the originating network or subnetwork.
69 A BOOTP request is honored if all of the following are true:
71 \- there exists an NDB entry
72 containing both the ethernet address of the requester and
73 an IP address on the originating network or subnetwork.
75 \- the entry contains a
81 attribute is readable.
83 Dynamic addresses are specified on the command line as a list
84 of addresses and number pairs.
87 ip/dhcpd 10.1.1.12 10 10.2.1.70 12
91 to return dynamic addresses 10.1.1.12 through 10.1.1.21 inclusive
92 and 10.2.1.70 through 10.2.1.81 inclusive.
95 maintains a record of all dynamic addresses in the directory
98 If multiple servers have access to this common directory,
99 they will correctly coordinate their actions.
101 Attributes come from either the NDB entry for the system, the entry for its
102 subnet, or the entry for its network. The system entry has precedence,
103 then the subnet, then the network.
104 The NDB attributes used are:
114 the default IP gateway
117 the domain name of the system
120 the default Plan 9 name server
123 the default Plan 9 authentication server
129 a network time protocol server
140 a World Wide Web proxy
149 the default boot file;
157 requests only if it has been specifically targeted or if it
158 has read access to the boot file for the requester. That means that the requester
159 must specify a boot file in the request or one has to exist in NDB for
165 requests for which it can associate an IP address with the
170 Print debugging to standard output.
173 Specify a file other than
175 as the network database.
178 Mute: don't reply to requests, just log them and what
185 as the minimum lease time for dynamic addresses.
200 Mute static addresses: don't reply to requests for static addresses,
201 just log them and what
206 Sleep 2 seconds before answering requests for static addresses.
207 This is used to make a server be a backup only.
210 Sleep 2 seconds before answering requests for dynamic addresses.
213 The IP stack to use is mounted at
221 as the minimum lease time for static addresses.
225 prints out the currently valid DHCP leases found in the
230 performs the Reverse Address Resolution Protocol, translating
231 Ethernet addresses into IP addresses.
235 Print debugging to standard output.
238 Use the Ethernet mounted at
239 .BI /net/ etherdev\f1.
242 The IP stack to use is mounted at
249 transfers files to systems that are booting.
252 and can only access files with global read permission.
256 Print debugging to standard output.
259 The IP stack to use is mounted at
269 All requests for files with non-rooted file names are served starting at this
270 directory with the exception of files of the form
272 These are Sparc kernel boot files where
274 is the hex IP address of the machine requesting the kernel and
276 is an architecture identifier.
278 looks up the file in the network database using
282 and responds with the boot file specified for that particular
284 If no boot file is specified, the transfer fails.
286 supports only octet mode.
289 Restricts access to only those files rooted in the
293 .BR /lib/ndb/dhcp " directory of dynamic address files