*** UNIX MANUAL PAGE BROWSER ***

A Nergahak database for man pages research.

Navigation

Directory Browser

1Browse 4.4BSD4.4BSD
1Browse Digital UNIXDigital UNIX 4.0e
1Browse FreeBSDFreeBSD 14.3
1Browse MINIXMINIX 3.4.0rc6-d5e4fc0
1Browse NetBSDNetBSD 10.1
1Browse OpenBSDOpenBSD 7.7
1Browse UNIX v7Version 7 UNIX
1Browse UNIX v10Version 10 UNIX

Manual Page Search

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)

Navigation Options