jdbmod(8)jdbmod(8)NAMEjdbmod - 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 infor‐
mation on client IP address leases and dynamic names. The jdbmod com‐
mand allows the user to load preassigned hardware-IP address combina‐
tions 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 sec‐
onds 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 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. 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 residual time
remaining on the lease until expiration. After this time has passed,
the client will receive an entirely new lease whose duration is deter‐
mined 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 ser‐
vice 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 net‐
work. 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 out‐
standing 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, dis‐
solving 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 concur‐
rency, 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.
FILESSEE ALSO
Commands: jdbdump(8), joind(8)
Files: bootptab(4)jdbmod(8)
