jdbmod(8)						      System Manager's Manual							 jdbmod(8)

NAME

       jdbmod - Adds, modifies, or deletes data in the DHCP dynamic databases.

SYNOPSIS

       /usr/sbin/jdbmod [-d] [-e] [-f character] [-i] [-l  | -n] [-o] [-w] filename...

OPTIONS

       Loads  the  data  of a particular record even though the lease has expired.  The default is not to load such records.  Use this option with
       care; the server may have released the expired addresses to a new client since the data was dumped.  Deletes the  records  whose  keys  are
       implied	by  the input file(s).	The key fields are the hardware type and address and the subnet containing the IP address.  Uses character
       as the field separator.	The default is the pipe (|) character.	Allows an existing IP address assignment to be overridden.  By default, an
       attempt	to  assign  an	IP  address will fail if that address already exists and is bound to a different client.  This differs from the -w
       option, which controls whether a pre-existing MAC-address/client-id pairing may be updated.  Loads lease information  only.   Do  not  load
       names.  The default is to load both.  Loads name information only.  Loads only records owned by this server.  Allows existing records to be
       overwritten.  The default mode is to forbid the update if the record already exists in the database.

	      The jbdmod command keys its data entry from the MAC address and subnet IP address tuple replacing the record in overwrite mode if it
	      already exists, or adding the record if not. It also checks whether the IP address has already been taken by another client.

DESCRIPTION

       The jdbmod command modifies the databases used by joind to store information on client IP address leases and dynamic names. The jdbmod com-
       mand allows the user to load preassigned hardware-IP address combinations for those clients requiring infinite leases.  Each record  to	be
       loaded is terminated by a newline, and the fields within each record delimited by default with the pipe (|) character, although this may be
       changed with the -f command line option.  Date fields may be expressed either in Universal Coordinated Time (UCT), which is the	number	of
       seconds	since  00:00 01/01/1970 GMT, or in a variety of formats more easily understood by liveware (for example, Mon Jan 09 1995 10:00 and
       01/09/1995 10:00:00).

       The fields within the data file(s) to be loaded are as follows: This is the identifier which uniquely identifies the client.  It may be the
       client's  MAC  address  or an opaque object, uninterpreted by the JOIN software.  If non-zero, then the client id is the MAC address of the
       client corresponding to this type.  If zero, then the client id may be any byte array which serves uniquely to identify	the  client.   The
       length  of the identifier in 8-bit bytes. Note that if the client id corresponds to a MAC address then the value of this field must be con-
       sistent with the length implied by client id type. But in the more general case, it may be needed in order to determine whether the  client
       id  is to be interpreted as a literal or as a decimal or hexadecimal encoding of a byte string.	The IP address assigned to the client.	If
       this value is null or 0.0.0.0 it means "none". This is possible if jdbmod is being used to load client id/name combinations in  advance	of
       the  client  being  bound to a specific IP address. This has the effect of reserving a name as belonging to that client.  The time at which
       this lease began.  A value of zero (or null) is taken to mean now.  The time at which this lease will expire.  A negative value is taken to
       mean  no  expiration.  This is stored in the database as the maximum positive signed 32 bit value which translates to Jan 18 19:14:07 2038.
       The time at which this lease may be renewed. Requests to renew the lease prior to this will be answered by a reply determined by the resid-
       ual  time remaining on the lease until expiration. After this time has passed, the client will receive an entirely new lease whose duration
       is determined by the bootptab database.	Time when the client last acquired or renewed this lease.  Unless this	value  is  known  from	an
       invocation  of  jdbdump	it is best to set it to -1 or null, which has the conventional significance of now.  IP address of server "owning"
       the lease.  If this value is null or 0.0.0.0 it means that the lease will become owned by this server.	The  client's  name  (without  the
       domain  name).  This name must obey the rules set forth in RFC952 as amended by RFC1123. It must be accompanied by a valid domain and it is
       converted to lowercase before being stored in the database.  The client's domain (without the leaf name).  This domain must obey the  rules
       set  forth  in RFC952 as amended by RFC1123 and it must not have any trailing period. The name domain combination is stored in the database
       as a single entity after being converted to lowercase.

NOTES

       The jdbmod command loads name-address bindings into the JOIN databases.	 It  does  not	modify	existing  name	services  (NIS,  NIS+,	or
       BIND/DNS).   The intent is exactly contrary; the name and address bindings should have been determined from an authoritative source, either
       the name service in use or a previous backup of the database made by jdbdump.

       The JOIN database does not permit a client, as identified by the client id field, to have a lease on more than one IP address on  the  same
       network.  But, a client is permitted to have leases on IP addresses on different networks.  If you attempt to load a lease binding a client
       to an IP address, jdbmod first checks that the client holds no other outstanding lease on the same network.  If it  does,  the  binding	is
       rejected.  The  -w  option  allows  this  behavior  to  be overridden.  The binding of the old IP address to the client is dissolved and is
       replaced by the new binding.

       The behavior of the -i option is different. An attempt to bind an IP address to a client is forbidden if the address is already bound to  a
       different  client.   The  -i option explicitly permits this behavior, dissolving the binding of the old IP address and rebinding to the new
       client.	In the most general case, if you are sure that the data you are loading is authoritative, both options are needed.

RESTRICTIONS

       Because the database used by join does not support multiuser concurrency, applications that write to it lock  the  entire  database.   This
       means that you cannot use the jdbmod command while the joind daemon is running.	The converse is also true.

       The  jdbmod command keys its data entry from the MAC address/ subnet IP address tuple, replacing the record in overwrite mode if it already
       exists, or adding the record if it does not.  However, it does not check whether the resulting IP address has already been taken by another
       client.	 Before  loading  a file, you must ensure that no IP address conflicts exist either internal to the file itself or to the existing
       database.

FILES

SEE ALSO

       Commands: jdbdump(8), joind(8)

       Files: bootptab(4)

																	 jdbmod(8)