 |
Index for
Section 8 |
|
 |
Alphabetical
listing for J |
|
 |
Bottom of
page |
|
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
-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 (|)
character.
-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
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
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:
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
software.
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
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.
Client IP
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.
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
positive 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
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.
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
0.0.0.0 it means that the lease will become owned by this server.
Hostname
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.
Domain
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
/var/join/*.hsh
/var/join/*.btr
SEE ALSO
Commands: jdbdump(8), joind(8)
Files: bootptab(4)
|
Index for
Section 8 |
|
|
Alphabetical
listing for J |
|
 |
Top of
page |
|