Setup hints
The following table provides extensive hints for using setup
command options
in the order they are presented in interactive mode, when you run the command without options.
For reference information, refer to setup:
Parameter | Description | Option(s) |
---|---|---|
Instance path |
Server setup uses tools and templates installed with the software to generate the instance files required to run an instance of a server. By default, all the files are co-located. This parameter lets you separate the files. Set the instance path to place generated files in a different location from the tools, templates, and libraries you installed. Interactive setup suggests co-locating the software with the instance files. You cannot use a single software installation for multiple servers. Tools for starting and stopping the server process, for example, work with a single configured server. They do not have a mechanism to specify an alternate server location. If you want to set up another server, install another copy of the software,
and run that copy’s |
|
Unique server ID |
A server identifier string that is unique for your deployment. Choose a relatively short string, as the value is recorded repeatedly in replicated historical data. |
|
Deployment ID |
The deployment ID is a random string generated using the Together, the deployment ID and password serve to generate the shared master key that DS servers in the deployment require for protecting shared encryption secrets. By default, they also serve to generate a private CA and keys for TLS to protect communication between DS servers. When you deploy multiple servers together, reuse the same deployment ID and password for each server installation. For details, refer to Deployment IDs. |
|
Deployment ID password |
This is a random string that you choose, and that you must keep secret. It is paired with the deployment ID. |
|
Root user DN |
The root user DN identifies the initial directory superuser. This user has privileges to perform any and all administrative operations, and is not subject to access control. It is called the root user due to the similarity to the Linux root user. The default name is: For additional security in production environments, use a different name. |
|
Root user password |
The root user authenticates with simple, password-based authentication. Use a strong password here unless this server is only for evaluation. |
|
Monitor user DN |
The monitor user DN identifies a user with the privilege to read monitoring data ( The account is replicated by default, so use the same DN on each server. The name used in the documentation is the default name: |
|
Monitor user password |
The monitor user authenticates with simple, password-based authentication. The account is replicated by default, so use the same password on each server. |
|
Fully qualified directory server domain name |
The server uses the fully qualified domain name (FQDN) for identification between replicated servers. Interactive setup suggests the hostname of the local host. If this server is only for evaluation, then you can use Otherwise, use an FQDN that other hosts can resolve to reach your server, and that matches the FQDN in the server certificate. |
|
Administration port |
This is the service port used to configure the server and to run tasks. The port used in the documentation is If the suggested port is not free, interactive setup adds 1000 to the port number and tries again, repeatedly adding 1000 until a free port is found. Configure the firewall to allow access to this port from all connecting DS servers. |
|
Securing the deployment |
Setup requires a keystore with the keys for securing connections to the administration port, and to any other secure ports you configure during setup. You can choose to use the private PKI derived from the deployment ID and passwords. For details, refer to Deployment IDs. You can also choose to use an existing keystore supported by the JVM,
which can be either a file-based keystore or a PKCS#11 token.
The existing keystore must protect the keystore and all private keys with the same PIN or password.
If you choose a PKCS#11 token, you must first configure access through the JVM,
as the only input to the Public key security is often misunderstood. Before making security choices for production systems, read Cryptographic keys. |
|
Start the server |
By default, the If no further configuration is required, use the |
|
LDAP and LDAPS port |
The reserved port for LDAP is Examples in the documentation use If you install the server with access to privileged ports (< The LDAP StartTLS extended operation negotiates a secure connection starting on the insecure LDAP port. |
|
HTTP and HTTPS ports |
The reserved port for HTTP is If the initially suggested port is not free or cannot be used due to lack of privileges, interactive setup adds 1000 to the port number and tries again, repeatedly adding 1000 until a free port is found. Examples in the documentation use HTTPS on port |
|
Replication port |
Port used for data replication messages. This port must be accessible externally from other DS servers. If this port is configured, the server acts as a replication server. It maintains a replication change log, which it exposes as an external change log by default. If the initially suggested port is not free or cannot be used due to lack of privileges, interactive setup adds 1000 to the port number and tries again, repeatedly adding 1000 until a free port is found. Examples in the documentation use |
|
Bootstrap replication servers |
Specify bootstrap server Specify the same list of bootstrap servers each time you set up a replica or standalone replication server. This option interacts with the
|
|
Configure the server for use with other applications |
For details, refer to Setup profiles. |
|