Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Apropos / Subsearch:
optional field

jdbmod(8)							    jdbmod(8)


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


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


  -e  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.

  -d  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.

  -f character
      Uses character as	the field separator.  The default is the pipe (|)

  -i  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.

  -l  Loads lease information only.  Do	not load names.	 The default is	to
      load both.

  -n  Loads name information only.

  -o  Loads only records owned by this server.

  -w  Allows existing records to be overwritten.  The default mode is to for-
      bid 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.


  The jdbmod command modifies the databases used by joind to store informa-
  tion on client IP address leases and dynamic names. The jdbmod command
  allows the user to load preassigned hardware-IP address combinations for
  those	clients	requiring infinite leases.  Each record	to be loaded is	ter-
  minated 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:

  Client id
      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

  Client id type
      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.

  Client id length
      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 gen-
      eral 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 encod-
      ing of a byte string.

  Client IP
      The IP address assigned to the client.  If this value is null or 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.

  Lease	start
      The time at which	this lease began.  A value of zero (or null) is	taken
      to mean now.

  Lease	expiration
      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	posi-
      tive signed 32 bit value which translates	to Jan 18 19:14:07 2038.

  Lease	renewal
      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	resi-
      dual 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.

  Last renewal
      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.

  Server IP
      IP address of server "owning" the	lease.	If this	value is null or 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	data-
      base as a	single entity after being converted to lowercase.


  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 net-
  works.  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	dif-
  ferent 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 author-
  itative, both	options	are needed.


  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.





  Commands: jdbdump(8),	joind(8)

  Files: bootptab(4)