Maintenance tools
Server commands
-
Add DS server command-line tools to your PATH:
-
Bash
-
PowerShell
$ export PATH=/path/to/opendj/bin:${PATH}
PS C:\path\to> $env:PATH += ";C:\path\to\opendj\bat"
-
-
For reference information, use the
--help
option with any DS tool. -
All commands call Java programs. This means every command starts a JVM, so it takes longer to start than a native binary.
-
The DS
bash-completion
command generates a completion script for the Bash shell that makes it easier to write other DS commands.The completion script depends on support for
bash-completion
, which is not included by default on macOS.To set up Bash completion for DS commands, source the output of the script:
-
Bash 4
-
Bash 3.2 macOS
source <(/path/to/opendj/bin/bash-completion)
# First, install bash-completion support. # Next: eval "$( /path/to/opendj/bin/bash-completion )"
You can make completion available in any new interactive shell by adding it to your
~/.bash_profile
file, or~/.bashrc
file if it is loaded by the new shell. -
DS running on… | DS installed from… | Default path to tools… |
---|---|---|
Linux distributions |
.zip |
|
Linux distributions |
.deb, .rpm |
|
Microsoft Windows |
.zip |
|
The installation and upgrade tools, setup
,
and upgrade
, are found in the parent directory of the other tools.
These tools are not used for everyday administration.
Commands | Constraints |
---|---|
|
When the server is offline, or when running commands in offline mode, these commands can modify server files. They must, therefore, access server files as a user who has the same filesystem permissions as the user who installs and runs the server. For most systems, the simplest way to achieve this is to run the command as the same user who installs and runs the server. When following best practices for auditing and separation of duty, provision administrative and server user accounts with compatible group or access control list permissions. |
|
These commands must be used with the local DS server in the same installation as the tools. These commands are not useful with non-DS servers. |
|
These commands must be used with DS servers having the same version as the command. These commands are not useful with non-DS servers. |
|
This command depends on template files.
The template files can make use of configuration files installed with DS servers
under The LDIF output can be used with any directory server. |
|
These commands can be used independently of DS servers, and are not tied to a specific version. |
Command(1) | Description |
---|---|
Measure add and delete throughput and response time. |
|
Measure bind throughput and response time. |
|
Debug databases for pluggable backends. |
|
Encode and decode data in base64 format. Base64-encoding represents binary data in ASCII, and can be used to encode character strings in LDIF, for example. |
|
|
Generate a completion script for use with Bash shell.
Requires |
Debug file-based changelog databases. |
|
|
Generate a script you can use to start, stop, and restart the server, either directly,
or at system boot and shutdown. Use This lets you register and manage DS servers as services on UNIX and Linux systems. |
Back up or restore directory data. |
|
Generate a deployment ID, a shared master key, a private CA certificate based on a deployment ID and password, or a key pair with the certificate signed by the private CA. |
|
The To edit the configuration when the server is not running, use the Some advanced properties are not visible by default when you run the When you pass connection information, subcommands, and additional options to You can prepare Alternatively, you can read commands from standard input with the |
|
Manage data replication between directory servers to keep their contents in sync. |
|
Encode a plaintext password according to one of the available storage schemes. |
|
Export directory data to LDIF, the standard, portable, text-based representation of directory content. |
|
Load LDIF content into the directory, which overwrites existing data. It cannot be used to append data to the backend database. |
|
Compare the attribute values you specify with those stored on entries in the directory. |
|
Delete one entry or an entire branch of subordinate entries in the directory. |
|
Modify the specified attribute values for the specified entries. |
|
Modify user passwords. |
|
Search a branch of directory data for entries that match the LDAP filter you specify. |
|
Display differences between two LDIF files. The output is LDIF. |
|
Similar to the |
|
Similar to the |
|
Generate directory data in LDIF based on templates that define how the data should appear. The |
|
Lock and unlock user accounts, and view and manipulate password policy state information. |
|
View information about tasks scheduled to run in the server, and cancel specified tasks. |
|
Measure modification throughput and response time. |
|
Rebuild an index stored in an indexed backend. |
|
Measure search throughput and response time. |
|
Configure a setup profile after initial installation. |
|
Start one DS server. |
|
Display information about the server. |
|
Stop one DS server. |
|
Collect troubleshooting information for technical support purposes. |
|
Verify that an index stored in an indexed backend is not corrupt. |
|
|
Register and manage one DS server as a Windows service. |
(1) UNIX names for the commands. Equivalent Windows commands have .bat extensions.
Trusted certificates
When a client tool initiates a secure connection to a server, the server presents its digital certificate.
The tool must determine whether it trusts the server certificate and continues to negotiate a secure connection, or does not trust the server certificate and drops the connection. To trust the server certificate, the tool’s truststore must contain the trusted certificate. The trusted certificate is a CA certificate, or the self-signed server certificate.
The following table explains how the tools locate the truststore.
Truststore Option | Truststore Used |
---|---|
None |
The default truststore,
|
|
Only the specified truststore is used. The <Type> in the option name reflects the trust store type. The tool fails with an error if it cannot trust the server certificate. |
Default settings
You can set defaults in the ~/.opendj/tools.properties
file, as in the following example:
hostname=localhost
port=4444
bindDN=uid=admin
bindPassword\:file=/path/to/.pwd
useSsl=true
trustAll=true
When you use an option with a colon, such as bindPassword:file
,
escape the colon with a backslash ('\:') in the properties file.
The file location on Windows is %UserProfile%\.opendj\tools.properties
.