Manual Page Result
0
Command: joinc | Section: 8 | Source: Digital UNIX | File: joinc.8.gz
joinc(8) System Manager's Manual joinc(8)
NAME
joinc - daemon for DHCP client configuration
SYNOPSIS
/usr/sbin/joinc [-f] [-d n] [-l n]
FLAGS
Sets debug level to n. If debug is turned on, log messages are also en-
abled. Runs in the foreground instead of as a daemon process. Enables
warning (n > 0) and log (n > 1) messages. If n is not explicitly given,
the value one is assumed (warnings are turned on).
DESCRIPTION
The joinc daemon implements the client half of the Dynamic Host Config-
uration Protocol (DHCP) and with hardware extensions.
(JOIN is a trademark of Competitive Automation.)
The DHCP protocol, among other things, permits a client to establish an
endpoint for communication with a network by delivering an IP address
for each of the client's network interfaces, and a "lease" on that ad-
dress. The lease specifies the interval that the address remains valid:
it may be infinite or of fixed duration. If it appears that the client
wishes to continue using the IP address after its expiration the DHCP
protocol must negotiate an extension. For this reason the DHCP client
code must run as a daemon, only terminating when the client powers
down.
Communication with joinc daemon is effected through the agency of an
auxiliary program dhcpconf. The joinc daemon may be invoked as a user
process (albeit one requiring root privileges), but this is not neces-
sary as dhcpconf will start it implicitly.
When started, joinc reads its startup file, /etc/join/client.pcy and
either proceeds to act on the instruction(s) passed to it by dhcpconf,
or enters a passive state while awaiting a new command. When a com-
mand is received to configure an interface the DHCP protocol is
started. If successful the interface is configured and brought up. The
configuration received is stored in a file named interface.dhc located
(by default) under the directory /etc/join. The client daemon will
then sleep until it needs to renew the lease, which will happen well
before the lease expires. Upon wakeup, if the interface is found to be
down or has a different IP address, joinc considers that the interface
is no longer under its control and will drop it from future considera-
tion, until an explicit request arrives from dhcpconf. If the lease
cannot be renewed joinc will take the interface down when it expires as
required by the DHCP protocol. The user should consult RFC1541 for de-
tails.
The DHCP protocol also acts as a mechanism to configure other informa-
tion needed by the client (for example, name domain and addresses of
routers). The joinc daemon does not configure this information but in-
stead acts as a database which may be interrogated by other programs,
and in particular by dhcpconf. This approach is more flexible: it al-
lows third party software access to the data through a published API,
and allows system administrators more control over client configuration
by customizing startup scripts to permit various aspects of the client
and its software to be customized in a specific order. On clients with
a single interface this is quite straightforward. Clients with multi-
ple interfaces may present difficulties, as there exists the possibil-
ity that some information arriving on different interfaces may need to
be merged, or indeed that it may be inconsistent. Furthermore, the
configuration of the interfaces is asynchronous, so requests may arrive
while some or all of the interfaces are still unconfigured. The joinc
daemon resolves these problems as follows. When a request for a global
parameter arrives, it searches all interfaces that it has successfully
configured, and returns to the requester the name of the first one it
finds which contains the pertinent data. The client program may then
access the data by an API which reads the appropriate interface.dhc
file. If no interfaces have successfully configured when the request is
received, or if the none of those which are configured have the data,
the request fails. The dhcpconf program allows this behavior to be
overridden by insisting that the global data sought be associated with
a particular interface. See the dhcpconf(8) for details.
The joinc daemon writes informational and error messages in four cate-
gories: errors, warnings, information, and debug. Errors are severe,
usually unrecoverable, events due to resource exhaustion and other un-
expected failure of system calls. An error is also generated if the
client's lease on an IP address is in imminent danger of expiring.
Warnings are less severe, and in most cases describe unusual or incor-
rect datagrams received from clients, or requests for service than can-
not be provided. Information messages simply provide a human readable
transcription of (correct) actions performed by the server on behalf of
client hosts. Debug messages may be generated at various levels of
verbosity from zero (not at all) through nine, as controlled by the -d
option.
The disposition of messages is (by default) as follows: warning, infor-
matory and debug messages are discarded: errors are written to
/dev/console and are sent to the system logger syslog(3) at priority
LOG_ERR and with a facility identifier LOG_DAEMON. If warnings have
been enabled they also are written to the system console and syslog
with the same facility, but at priority LOG_WARNING. The creation and
disposition of messages is controlled by the -f, -d, and -l command
line flags (q.v.), and the environment variable JOINLOG. When present,
JOINLOG should name a file to which messages are sent in preference to
the system console. Note that until the root file system is mounted
read-write no ordinary file can be used for this purpose.
RESTRICTIONS
A cluster member should never be a DHCP client. It should always use
static addressing.
If a cluster is to support a DHCP server, there can only be one DHCP
server for all the cluster members using a common database with
failover.
The joinc daemon can configure clients with two or more interfaces giv-
ing each an IP address. However, each interface so configured must be
on a different physical network and subnet.
DIAGNOSTICS
Upon receipt of SIGUSR1 signals, joinc dumps the contents of its sched-
uling table and the status of each of the interfaces under its control.
FILES
By default, joinc expects to read its policy file and read and write
its configuration databases in the directory /etc/join. The environ-
ment variable JOINCONFIG may be used to select a different directory.
Contains parameters governing the behavior of joinc, and general poli-
cies concerning network administration. Contains the configuration for
interface. The mere existence of this file does not imply that the
configuration is correct, since the lease may have expired.
RELATED INFORMATION
Commands: dhcpconf(8), dhcpparm(8), joind(8), showdhc(8), shleases(8).
Files: client.pcy(4).
RFC1541 delim off
joinc(8)