.TP
.BI \-nw
Become a daemon immediately (nowait) rather than waiting until an
-an IP address has been acquired.
+IP address has been acquired.
.TP
.BI \-q
Be quiet at startup, this is the default.
.PP
.I Modifying default file locations:
The following options can be used to modify the locations a client uses
-for it's files. They can be particularly useful if, for example,
+for its files. They can be particularly useful if, for example,
.B DBDIR
or
.B RUNDIR
.PP
To make it work, you have to declare a key and zone as in the DHCP
server (see \fBdhcpd.conf\fR(5) for details). You also need to
-configure the fqdn option on the client, as follows:
+configure the \fIfqdn\fR option on the client, as follows:
.PP
.nf
send fqdn.fqdn "grosse.fugue.com.";
used for printing times in leases files. The \fIdefault\fR format provides
day-and-time in UTC, whereas \fIlocal\fR uses a seconds-since-epoch to store
the time value, and helpfully places a local timezone time in a comment on
-the same line. The formats are described in detail in this manpage, whithin
+the same line. The formats are described in detail in this manpage, within
the LEASE DECLARATIONS section.
.PP
\fBreject \fIcidr-ip-address\fR [\fB,\fR \fI...\fB \fIcidr-ip-address\fR ] \fB;\fR
specified in the numeric expression. For example, if the numeric
expression evaluates to four, and the data expression evaluates to
twelve bytes of data, then the reverse expression will evaluate to
-twelve bytes of data, consisting of the last four bytes of the the
+twelve bytes of data, consisting of the last four bytes of the
input data, followed by the middle four bytes, followed by the first
four bytes.
.RE
intended for use by agents in relaying DHCP responses back to the
proper circuit. The format of this option is currently defined to be
vendor-dependent, and will probably remain that way, although the
-current draft allows for for the possibility of standardizing the
+current draft allows for the possibility of standardizing the
format in the future.
.RE
.PP
is not on the same subnet as the client. When this option is present in
a packet from a relay agent, the DHCP server will use its contents to find
a subnet declared in configuration, and from here take one step further
-backwards to any shared-network the subnet may be defined within...the
+backwards to any shared-network the subnet may be defined within; the
client may be given any address within that shared network, as normally
appropriate.
.RE
all labels after the first label in the \fBfqdn.fqdn\fR suboption - for
example, if the value of \fBfqdn.fqdn\fR is "foo.example.com.",
then \fBfqdn.hostname\fR will be "example.com.". If this suboption value
-is not set, it means that an unqualified name was sent in the fqdn option,
-or that no fqdn option was sent at all.
+is not set, it means that an unqualified name was sent in the \fBfqdn\fR option,
+or that no \fBfqdn\fR option was sent at all.
.RE
.PP
If you wish to use any of these suboptions, we strongly recommend that you
.B option \fBdhcp6.nis-domain-name\fR \fIdomain-name\fR\fB;\fR
.RS 0.25i
.PP
-The \fBdhcp6.nis-domain-name\fR option specfies NIS domain name the
+The \fBdhcp6.nis-domain-name\fR option specifies NIS domain name the
client is expected to use, and is related to \fBdhcp6.nis-servers\fR option.
.RE
.PP
.B option \fBdhcp6.nisp-domain-name\fR \fIdomain-name\fR\fB;\fR
.RS 0.25i
.PP
-The \fBdhcp6.nis-domain-name\fR option specfies NIS+ domain name the
+The \fBdhcp6.nis-domain-name\fR option specifies NIS+ domain name the
client is expected to use, and is related to \fBdhcp6.nisp-servers\fR option.
.RE
.PP
compressed relative to the start of the option contents (not the packet
contents).
.PP
-When in doubt, omit the \fBcompressed\fR keyword. When the software recieves
+When in doubt, omit the \fBcompressed\fR keyword. When the software receives
an option that is compressed and the \fBcompressed\fR keyword is omitted, it
will still decompress the option (relative to the option contents field). The
keyword only controls whether or not transmitted packets are compressed.
DHCPv6 protocol defines the \fBVendor-specific Information Option\fR
("VSIO"). The format of all of these options is usually internally a
string of options, similarly to other normal DHCP options. The VIVSO
-and VSIO options differ in that that they contain options that correspond
+and VSIO options differ in that they contain options that correspond
to vendor Enterprise-ID numbers (assigned by IANA), which then contain
options according to each Vendor's specifications. You will need to refer
to your vendor's documentation in order to form options to their
.Pp
.Fn dhcpctl_object_update
function queues a request for
-all the changes made to the object handle be be sent to the remote
-for processing. The changes made to the atributes on the handle will be
+all the changes made to the object handle be sent to the remote
+for processing. The changes made to the attributes on the handle will be
applied to remote object if permitted.
.\"
.\"
.\"
.Pp
.Fn dhcpctl_new_object
-creates a local handle for an object on the the server. The
+creates a local handle for an object on the server. The
.Dq object_type
parameter is the ascii name of the type of object being accessed. e.g.
.Qq lease .
The following program will connect to the DHCP server running on the local
host and will get the details of the existing lease for IP address
10.0.0.101. It will then print out the time the lease is due to expire. Note
-that most error checking has been ommitted for brevity.
+that most error checking has been omitted for brevity.
.Bd -literal -offset indent
#include <sys/time.h>
#include <stdio.h>
.BI \-T
Test the lease file. The server tests the lease file
for correct syntax, but will not attempt to perform any network
-operations. This can be used to test a new leaes file
+operations. This can be used to test a new lease file
automatically before installing it.
.TP
.BI \-tf \ tracefile
.I Modifying default file locations:
The following options can be used to modify the locations
.B dhcpd
-uses for it's files. Because of the importance of using the same
+uses for its files. Because of the importance of using the same
lease database at all times when running dhcpd in production, these
options should be used \fBonly\fR for testing lease files or database
files in a non-production environment.
This version of the DHCP Server evaluates pool balance on a schedule,
rather than on demand as leases are allocated. The latter approach
proved to be slightly klunky when pool misbalanced reach total
-saturation...when any server ran out of leases to assign, it also lost
+saturation \(em when any server ran out of leases to assign, it also lost
its ability to notice it had run dry.
.PP
In order to understand pool balance, some elements of its operation
.PP
If the server is configured not to allow client updates, or if the
client doesn't want to do its own update, the server will simply
-choose a name for the client from either the fqdn option (if present)
+choose a name for the client from either the \fBfqdn\fR option (if present)
or the hostname option (if present). It will use its own
domain name for the client, just as in the ad-hoc update scheme.
It will then update both the A and PTR record, using the name that it
chose for the client. If the client sends a fully-qualified domain
-name in the fqdn option, the server uses only the leftmost part of the
+name in the \fBfqdn\fR option, the server uses only the leftmost part of the
domain name - in the example above, "jschmoe" instead of
"jschmoe.radish.org".
.PP
.B ddns-hostname \fIname\fB;\fR
.PP
The \fIname\fR parameter should be the hostname that will be used in
-setting up the client's A and PTR records. If no ddns-hostname is
+setting up the client's A and PTR records. If no \fIddns-hostname\fR is
specified in scope, then the server will derive the hostname
automatically, using an algorithm that varies for each of the
different update methods.
this statement is used to disable forward updates, the DHCP server
will never attempt to update the client's A record, and will only ever
attempt to update the client's PTR record if the client supplies an
-FQDN that should be placed in the PTR record using the fqdn option.
+FQDN that should be placed in the PTR record using the \fBfqdn\fR option.
If forward updates are enabled, the DHCP server will still honor the
setting of the \fBclient-updates\fR flag.
.RE
to the specified \fIaddress\fR, rather than requests sent to all addresses.
Since serving directly attached DHCP clients implies that the server must
respond to requests sent to the all-ones IP address, this option cannot be
-used if clients are on directly attached networks...it is only realistically
+used if clients are on directly attached networks; it is only realistically
useful for a server whose only clients are reached via unicasts, such as via
DHCP relay agents.
.PP
file, log messages printed while parsing the dhcpd.conf file or before
parsing it are logged to the default log facility. To prevent this,
see the README file included with this distribution, which describes
+BUG: where is that mentioned in README?
how to change the default log facility. When this parameter is used,
the DHCP server prints its startup message a second time after parsing
the configuration file, so that the log will be as complete as
.B The \fIddns-text\fB variable
.PP
The \fIddns-text\fR variable is used to record the value of the
-client's TXT identification record when the interim ddns update
+client's TXT identification record when the interim DDNS update
style has been used to update the DNS for a particular lease.
.PP
.B The \fIddns-fwd-name\fB variable
.PP
.B The \fIddns-client-fqdn\fB variable
.PP
-If the server is configured to use the interim ddns update style, and
-is also configured to allow clients to update their own fqdns, and the
-client did in fact update its own fqdn, then the
+If the server is configured to use the interim DDNS update style, and
+is also configured to allow clients to update their own FQDNs, and the
+client did in fact update its own FQDN, then the
\fIddns-client-fqdn\fR variable records the name that the client has
indicated it is using. This is the name that the server will have
used to update the client's PTR record in this case.