PingDS

Install standalone servers (advanced)

This information applies to advanced deployments.

Standalone replication servers have no application data backends. They store only changes to directory data. They are dedicated to transmitting replication messages, and to maintaining a replication change log.

Standalone directory servers store replicated copies of application data. These replicas send updates to and receive updates from replication servers. They connect to one replication server at a time, and do not maintain a replication change log.

Each replication server in a deployment connects to all other replication servers. The total number of replication connections, Totalconn, increases like the number of replication servers squared. Large deployments that span slow, high-latency links can benefit from having fewer replication servers.

Totalconn = (NRS * (NRS-1))/2 + NDS

Here, NRS is the number of replication servers (standalone or running in a directory server), and NDS is the number of standalone directory servers.

A deployment with only a few standalone replication servers and many standalone directory servers, significantly limits the number of connections for replication over slow links:

Dedicated servers are suited to advanced deployments with many replicas.
Figure 1. Deployment for multiple data centers

The deployment ID for installing the server is stored in the environment variable DEPLOYMENT_ID. Install all servers in the same deployment with the same deployment ID and deployment ID password. For details, read Deployment IDs.

Set up standalone replication servers

  1. Install the server files.

  2. Generate a deployment ID unless you already have one:

    $ /path/to/opendj/bin/dskeymgr create-deployment-id --deploymentIdPassword password
your-deployment-id

    Save the deployment ID and its deployment password. Keep the ID and the password safe, and keep the password secret. Use the same deployment ID and password for all the servers in the same environment.

    About deployment IDs

    A deployment ID is a random string generated using the dskeymgr command. It is a deployment identifier, not a key, but it is used with a password to generate keys.

    A deployment ID password is a secret string at least 8 characters long that you choose.

    The two are a pair. You must have the deployment ID password to use the deployment ID.

    Each deployment requires a single, unique deployment ID and its password. DS uses the pair to:

    • Protect the keys to encrypt and decrypt backup files and directory data.

    • Generate the TLS key pairs to protect secure connections, unless you provide your own.

    Store your deployment ID and password in a safe place, and reuse them when configuring other servers in the same deployment.

    The DS setup and dskeymgr commands use the pair to generate the following:

    • (Required) A shared master key for the deployment.

      DS replicas share secret keys for data encryption and decryption. DS servers encrypt backend data, backup files, and passwords, and each replica must be able to decrypt data encrypted on another peer replica.

      To avoid exposing secret keys, DS servers encrypt secret keys with a shared master key. DS software uses a deployment ID and its password to derive the master key.

    • (Optional) A private PKI for trusted, secure connections.

      A PKI serves to secure network connections from clients and other DS servers. The PKI is a trust network, requiring trust in the CA that signs public key certificates.

      Building a PKI can be complex. You can use self-signed certificates, but you must distribute each certificate to each server and client application. You can pay an existing CA to sign certificates, but that has a cost, and leaves control of trust with a third party. You can set up a CA or certificate management software, but that can be a significant effort and cost. As a shortcut to setting up a private CA, DS software uses deployment IDs and passwords.

      DS software uses the deployment ID and its password to generate key pairs without storing the CA private key.

    Learn more in Deployment IDs.

  3. Set the deployment ID as the value of the environment variable, DEPLOYMENT_ID:

    $ export DEPLOYMENT_ID=your-deployment-id

    Examples in the documentation show this environment variable as a reminder to use your own deployment ID.

  4. Set up a server as a standalone replication server:

    $ /path/to/opendj/setup \
 --deploymentId $DEPLOYMENT_ID \
 --deploymentIdPassword password \
 --rootUserDN uid=admin \
 --rootUserPassword password \
 --hostname rs-only.example.com \
 --adminConnectorPort 4444 \
 --replicationPort 8989 \
 --bootstrapReplicationServer rs-only.example.com:8989 \
 --bootstrapReplicationServer rs-only2.example.com:8989 \
 --acceptLicense

    The standalone replication server has no application data.

    It does have LDAP schema and changelog data. If you plan to add any additional schema to the replicas as part of the setup process, also add the schema to this server before starting it.

  5. Start the server:

    $ /path/to/opendj/bin/start-ds

  6. Repeat the previous steps on additional systems until you have sufficient replication servers to meet your availability requirements.

    To ensure availability, add at least one additional replication server per location. The following example adds a second standalone replication server:

    $ /path/to/opendj/setup \
 --deploymentId $DEPLOYMENT_ID \
 --deploymentIdPassword password \
 --rootUserDN uid=admin \
 --rootUserPassword password \
 --hostname rs-only2.example.com \
 --adminConnectorPort 4444 \
 --replicationPort 8989 \
 --bootstrapReplicationServer rs-only.example.com:8989 \
 --bootstrapReplicationServer rs-only2.example.com:8989 \
 --acceptLicense

    The standalone replication servers use each other as bootstrap servers to discover other servers in the deployment.

Set up standalone directory servers

  1. Before proceeding, install the server files.
    For details, refer to Unpack files.

  2. Set up the server as a directory server.

    Notice that the --bootstrapReplicationServer references the replication servers set up according to the steps in Set up standalone replication servers.

    The --replicationPort option is not used, because this is a standalone directory server:

    $ /path/to/opendj/setup \
 --serverId evaluation-only \
 --deploymentId $DEPLOYMENT_ID \
 --deploymentIdPassword password \
 --rootUserDN uid=admin \
 --rootUserPassword password \
 --adminConnectorPort 4444 \
 --hostname ds-only.example.com \
 --ldapPort 1389 \
 --enableStartTls \
 --ldapsPort 1636 \
 --httpsPort 8443 \
 --bootstrapReplicationServer rs-only.example.com:8989 \
 --bootstrapReplicationServer rs-only2.example.com:8989 \
 --profile ds-evaluation \
 --acceptLicense

  3. Finish configuring the server before you start it.

    For a list of optional steps at this stage, refer to Install DS for custom cases.

  4. Start the server:

    $ /path/to/opendj/bin/start-ds

  5. Repeat the previous steps on additional systems until you have sufficient directory servers to meet your availability and performance requirements.

    To ensure availability, add at least one additional directory server per location.