Install DS for Evaluation
More information
To set up the server, use the setup command-line tool.
When used without options, the command is interactive.
The following setup
options are mandatory.
When performing a non-interactive, silent installation, specify at least all mandatory options as part of the command.
If you use only these options, the command sets up a server listening only on an administration port.
The administration port is protected by a key pair specified or generated at setup time:
-
--adminConnectorPort {port}
(conventional port number:4444
) -
--hostname {hostname}
-
--rootUserDN {rootUserDN}
(default:uid=admin
) -
--rootUserPassword {rootUserPassword}
-
Before proceeding, install the server files.
For details, see Unpack Files. -
Generate a deployment key unless you already have one:
$ dskeymgr create-deployment-key --deploymentKeyPassword password your-deployment-key
Save the deployment key and its deployment password. Keep the key and the password safe, and keep the password secret. Use the same deployment key and password for all the servers in the same environment.
More about deployment keys
A deployment key is a random string generated by DS software. A deployment key password is a secret string at least 8 characters long that you choose. The two are a pair. You must have a deployment key’s password to use the key.
Each deployment requires a single, unique deployment key 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 key and password in a safe place, and reuse them when configuring other servers in the same deployment.
The DS
setup
anddskeymgr
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 key 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 keys and passwords.
DS software uses the deployment key and its password to generate key pairs without storing the CA private key.
For additional details, see Deployment Keys.
-
-
Set the deployment key as the value of the environment variable,
DEPLOYMENT_KEY
:$ export DEPLOYMENT_KEY=your-deployment-key
Examples in the documentation show this environment variable as a reminder to use your own key. Other options are available, as described by the
setup --help
command. -
Run the
setup
command to install a directory server replica with the evaluation profile:# Set up a directory server for evaluation. $ /path/to/opendj/setup \ --serverId evaluation-only \ --deploymentKey $DEPLOYMENT_KEY \ --deploymentKeyPassword password \ --rootUserDN uid=admin \ --rootUserPassword password \ --monitorUserPassword password \ --hostname localhost \ --adminConnectorPort 4444 \ --ldapPort 1389 \ --enableStartTls \ --ldapsPort 1636 \ --httpsPort 8443 \ --replicationPort 8989 \ --bootstrapReplicationServer localhost:8989 \ --profile ds-evaluation \ --start \ --acceptLicense
More information
-
The
setup
command is located where you installed the files. -
The setup process uses the deployment key you generated, and its password.
If you specify only a deployment password, and no deployment key, the
setup
command generates a deployment key and displays it in the output. -
This example prepares a single server for evaluation, so the hostname is
localhost
.In production, use fully qualified domain names, such as
ds.example.com
. -
The server is ready to replicate sample data with other servers, but there are no other replicas, yet.
For now, the server points to itself as a bootstrap replication server. To get started with replication, see Learn Replication.
-
It sets a password for the default monitoring user account,
uid=Monitor
. -
The server listens for requests on the ports used in examples throughout the documentation.
-
For evaluation purposes, no further configuration is required.
The
--start
option forces the server to start as part of the setup process.
-
Learn About the Evaluation Setup Profile
The evaluation setup profile helps you learn and demonstrate directory services. Unlike other setup profiles, which use secure, production-ready access control settings, the evaluation setup profile provides easy access to sample data with the following features:
-
Sample Example.com data.
The sample data has the base DN
dc=example,dc=com
. It includes more than 100 hand-written entries for users, groups, and devices.By default, it also includes 100,000 generated users, with DNs from
uid=user.0,ou=people,dc=example.dc=com
touid=user.99999,ou=people,dc=example.dc=com
.Use the
--set ds-evaluation/generatedUsers:number
option to generate a different number of additional entries. Each generated user has the same password, which ispassword
.The hand-written sample Example.com data includes a group of directory administrators,
cn=Directory Administrators,ou=Groups,dc=example,dc=com
. Members of this group, such askvaughan
, have full access to directory data.Examples throughout the documentation demonstrate features using this sample data.
-
Global permission to perform operations over insecure connections.
-
REST to LDAP enabled by default.
-
Additional schema for examples demonstrating class of service and JSON attributes.
-
Custom matching rule providers for JSON attributes.
-
Many permissions, such as anonymous read and search access, listed in the table that follows.
The evaluation setup profile lets you learn and demonstrate most directory features without adding any ACIs.
Name | Description | ACI Definition |
---|---|---|
Anonymous extended operation access |
Anonymous and authenticated users can request the LDAP extended operations that are specified by OID or alias. Modification or removal may affect applications. |
|
Anonymous extended operation access |
Anonymous and authenticated users can request the LDAP extended operations that are specified by OID or alias. Modification or removal may affect applications. |
|
Anonymous read and search access |
Anonymous and authenticated Example.com users can read the user data attributes that are specified by their names. |
|
Authenticated control use |
Authenticated Example.com users can proxy and examine CSNs. |
|
Authenticated users extended operation access |
Authenticated users can request the LDAP extended operations that are specified by OID or alias. Modification or removal may affect applications. |
|
Authenticated users extended operation access |
Authenticated users can request the LDAP extended operations that are specified by OID or alias. Modification or removal may affect applications. |
|
Directory administrator full access |
Example.com directory administrators have access to read and write Example.com directory data, rename and move entries, and use proxied authorization. |
|
Proxied authorization for apps |
Example.com applications can make requests on behalf of other users. |
|
Self entry modification |
Authenticated users can modify the specified attributes on their own entries. |
|
Self entry read for passwords |
Authenticated users can read the password values on their own entries. By default, the server applies a one-way hash algorithm to the password value before writing it to the entry, so it is computationally difficult to recover the plaintext version of the password from the stored value. |
|
Self service group creation |
Authenticated Example.com users can create self service groups. |
|
Self service group deletion |
The authenticated owner of a self service group can delete the group. |
|
Self service group registration |
Authenticated Example.com users can sign themselves up as members of self service groups. |
|
User-Visible Monitor Attributes |
Authenticated users can read monitoring information if they have the monitor read privilege. Modification or removal may affect applications. |
|
User-visible operational attributes |
Anonymous and authenticated users can read attributes that identify entries and that contain information about modifications to entries. |
|
User-Visible Root DSE Operational Attributes |
Anonymous and authenticated users can read attributes that describe what the server supports. Modification or removal may affect applications. |
|
User-Visible Schema Operational Attributes |
Authenticated users can read LDAP schema definitions. Modification or removal may affect applications. |
|