joind man page on DigitalUNIX

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
DigitalUNIX logo
[printable version]

joind(8)							      joind(8)

       joind - BOOTP and DHCP server daemon

       /usr/sbin/joind [-f] [-dn] [-ln] [-t minutes]

       Sets  foreground	 mode.	 In this mode, joind will not run as a daemon.
       All messages are written to standard out (stdout)  and  standard	 error
       (stderr),  although  warnings and errors are still sent to syslog(3) as
       well.  Sets debug level to n.  If debug is turned on, log messages  are
       also  enabled.  Enables warning (n > 0) and log (n > 1) messages.  If n
       is not explicitly given, the value one (1)  is  assumed	(warnings  are
       turned on).  Terminates if minutes have passed and no packets have been
       received.  This option is valid only if joind was started from inetd.

       The joind server is the server that provides configurations to  clients
       on the network using the DHCP or BOOTP protocols; it normally runs as a
       daemon process, and may be started either from the shell	 command  line
       interface or by the inetd daemon.

       In  default  mode  of  operation,  joind reads configuration and policy
       information from files created by xjoin, the graphical  user  interface
       tool  for  administering	 these	databases.  It then listens on a well-
       known port for client hosts requesting configuration either by the DHCP
       protocol or by the BOOTP protocol.

       The  joind daemon looks in the /etc/services file to find the port num‐
       bers it should use.  Two entries are extracted: The BOOTP  server  lis‐
       tening port.  The destination port used to reply to clients.

       If  the	port  numbers  cannot  be  determined in this manner, they are
       assumed to be port 67 for the server and port 68 for the client.

       When a request is received from a client on a network that is  adminis‐
       tered  by a joind daemon, it responds with an Internet address that the
       client can use, and sufficient information to permit the client to boot
       and  configure  its  TCP/IP stack according to either the DHCP or BOOTP
       protocols as described in RFC1541 and RFC1497, respectively.

       The joind daemon rereads its configuration  file	 when  it  receives  a
       hangup  signal  (SIGHUP) or when it receives a BOOTP request packet and
       detects that the file has been updated.	Hosts can be  added,  deleted,
       or modified when the configuration file is reread.

       The  joind server writes informational and error messages in four cate‐
       gories: errors, warnings, information, and debug.  Errors  are  severe,
       usually	unrecoverable events within the server due to resource exhaus‐
       tion and other unexpected failure of system calls.  Warnings  are  less
       severe, do not terminate the server, and in most cases describe unusual
       or incorrect datagrams received from clients, or requests  for  service
       that  cannot be provided.  Informational messages provide a human read‐
       able transcription of (correct) actions	performed  by  the  server  on
       behalf of client hosts. Debug messages may be generated at various lev‐
       els 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‐
       mation, and  debug  messages  are  discarded:  errors  are  written  to
       /var/join/log  and  are sent to the system logger syslog(3) at priority
       LOG_ERR and with a facility identifier  LOG_DAEMON.  If	warnings  were
       enabled,	 they  are  also sent to syslog with the same facility, but at
       priority LOG_WARNING. The creation and disposition of messages is  con‐
       trolled by the -f, -d, and -l command line options, and the environment
       variable JOINLOG.

   BOOTP Information
       If you plan to use the joind daemon to support BOOTP requests only, you
       might  want  the	 inetd	daemon start joind automatically.  To do this,
       uncomment the following line in the /etc/inetd.conf file:

       bootps dgram udp wait root /usr/sbin/joind joind

       This causes joind to be started only when a boot request	 arrives.   If
       joind  does  not receive another boot request within fifteen minutes of
       the last one it received, it exits to conserve system resources.

       To run the joind daemon, you must also run the tftpd daemon.

       Upon startup, joind first reads its configuration file,	/etc/bootptab,
       and then begins listening for BOOTREQUEST packets.

       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 be  only  one  DHCP
       server  for  all	 the  cluster  members	using  a  common database with

       Do not terminate the server with SIGKILL. Doing so leads to data	 loss,
       and  frequently results in a corrupted database. Use SIGTERM, SIGINT or
       SIGQUIT instead.

       Nonstandard subnet masks for all networks administered  by  the	server
       must be available either through /etc/join/netmasks or NIS.

       The  database  used by the server does not support multiuser write con‐
       currency.  When the server is  in  operation  the  entire  database  is
       locked against other applications.  This means that you cannot use jdb‐
       mod or xjdbmod to modify records in the database while  the  server  is
       running.	 The converse is also true.

       If  the	naming	policy	is  to be changed (for example, from assigning
       names by MAC address to assigning names by IP address) you must	first,
       before  changing	 the server policy database, stop the server, dump the
       name data (using jdbdump), and then reload after the  policy  file  has

       SIGTERM,	 SIGINT,  SIGQUIT  and	SIGUSR2 terminate the server in a con‐
       trolled manner.	SIGHUP tells the server to  reread  its	 configuration
       databases.  SIGUSR1 dumps database internals.

       Never stop the server with SIGKILL. This leads to data loss and corrup‐
       tion of the lease and names databases.

       By default, joind reads its configuration  and  policy  databases  from
       files  in the /etc/join directory.  The environment variable JOINCONFIG
       may be used to select a different directory.  These  databases  may  be
       stored  as text or binary.  The text files are: Parameters and configu‐
       ration data for individual clients, client classes, and networks.  Net‐
       works  joind  controls,	and a pool of IP addresses which are available
       for the server to assign to clients.  A collection of  names  available
       on  a  per-join-server,	per  domain-name that the server can assign to
       clients.	 Parameters governing the behavior of joind, and general poli‐
       cies  concerning	 network administration and their binary counterparts:
       bootptab.hsh, nets.hsh, namepool.hsh, and server.hsh.

       During operation, the server creates dynamic database  bindings	of  IP
       addresses  and  names to MAC addresses.	The following files are stored
       under the /var/join directory, unless  overridden  by  the  environment
       variable JOINSPOOL.  B-trees Hash indexes.

       The joind daemon writes a startup message and other messages previously
       described in the $JOINSPOOL/log file unless  the	 environment  variable
       JOINLOG	is  set, in which case the file named by that variable is used
       (NOTE: this must be an absolute filename, not a directory, nor  a  path
       relative filename).  The (human readable) log.

       Commands: inetd(8), joinc(8), xjoin(8)

       System calls: syslog(3)

       Files: bootptab(4), namepool(4), nets(4), server.pcy(4)

       Information: DHCP(7)

       RFC1497, RFC1541, RFC1542, RFC1533, RFC1534


List of man pages available for DigitalUNIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net