jdbmod - Adds, modifies, or deletes data in the DHCP
dynamic databases.
/usr/sbin/jdbmod [-d] [-e] [-f character] [-i] [-l | -n]
[-o] [-w] filename...
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 preexisting
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.
The jdbmod command modifies the databases used by joind to
store information 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
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
consistent 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 residual 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.
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.
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.
SEE ALSO
Commands: jdbdump(8), joind(8)
Files: bootptab(4)
jdbmod(8)
[ Back ] |
