Moving servers When you change where OpenDJ is deployed, you must take host names, port numbers, and certificates into account. The changes can also affect your replication configuration. This chapter shows what to do when moving a server. Replication Moving servers

From time to time you might change server hardware, file system layout, or host names. At those times you move the services running on the system. You can move OpenDJ data between servers and operating systems. Most of the configuration is also portable. Two aspects of the configuration are not portable. Certificates Server certificates contain the host name of the system. Even if you did not set up secure communications when you installed the server, the server still has a certificate used for secure communications on the administrative port. To resolve the issue with server certificates, you can change the server certificates during the move as described in this chapter. Replication configuration includes the host name and administrative port numbers. You can work around the issue with replication configuration by disabling replication for the server before the move, and then enabling and initializing replication again after the move.

Take a moment to determine whether you find it quicker and easier to move your server, or instead to recreate a copy. To recreate a copy, install a new server, set up the new server configuration to match the old, and then copy only the data from the old server to the new server, initializing replication from existing data, or even from LDIF if your database is not too large. After you decide to move a server, start by taking it out of service. Taking it out of service means directing client applications elsewhere, and then preventing updates from client applications, and finally disabling replication, too. Directing client applications elsewhere depends on your network configuration and possibly on your client application configuration. The other two steps can be completed with the dsconfig and dsreplication commands. Direct client applications to other servers. How you do this depends on your network and client application configurations. Prevent the server from accepting updates from client applications. $ dsconfig set-global-configuration-prop --port 5444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --set writability-mode:internal-only --trustAll --no-prompt Disable replication for the server. $ dsreplication disable --disableAll --port 5444 --hostname opendj.example.com --adminUID admin --adminPassword password --trustAll --no-prompt Establishing connections ..... Done. Disabling replication on base DN dc=example,dc=com of server opendj.example.com:5444 ..... Done. Disabling replication on base DN cn=admin data of server opendj.example.com:5444 ..... Done. Disabling replication on base DN cn=schema of server opendj.example.com:5444 ..... Done. Disabling replication port 9989 of server opendj.example.com:5444 ..... Done. Removing registration information ..... Done. Removing truststore information ..... Done. See /var/.../opends-replication-3173475478874782719.log for a detailed log of this operation. With the server no longer receiving traffic or accepting updates from clients, and no longer replicating to other servers, you can shut it down in preparation for the move. $ stop-ds Stopping Server... ... msg=The Directory Server is now stopped You might also choose to remove extra log files from the server logs/ directory before moving the server.

Now that you have decided to move your server, and prepared for the move, you must not only move the files but also fix the configuration and the server certificates, and then enable replication. Move the contents of the server installation directory to the new location. If you must change port numbers, edit the port numbers in config/config.ldif, carefully avoiding to change any whitespace or other lines in the file. Change server certificates as described in the separate procedure below. Start the server. $ start-ds ... The Directory Server has started successfully Enable and initialize replication. $ dsreplication enable --adminUID admin --bindPassword password --baseDN dc=example,dc=com --host1 opendj.example.com --port1 4444 --bindDN1 "cn=Directory Manager" --bindPassword1 password --replicationPort1 8989 --host2 opendj2.example.com --port2 4444 --bindDN2 "cn=Directory Manager" --bindPassword2 password --replicationPort2 8989 --trustAll --no-prompt Establishing connections ..... Done. Checking registration information ..... Done. Configuring Replication port on server opendj.example.com:4444 ..... Done. Updating remote references on server opendj2.example.com:4444 ..... Done. Updating replication configuration for baseDN dc=example,dc=com on server opendj.example.com:4444 ..... Done. Updating replication configuration for baseDN dc=example,dc=com on server opendj2.example.com:4444 ..... Done. Updating registration configuration on server opendj.example.com:4444 ..... Done. Updating registration configuration on server opendj2.example.com:4444 ..... Done. Updating replication configuration for baseDN cn=schema on server opendj.example.com:4444 ..... Done. Updating replication configuration for baseDN cn=schema on server opendj2.example.com:4444 ..... Done. Initializing registration information on server opendj.example.com:4444 with the contents of server opendj2.example.com:4444 ..... Done. Initializing schema on server opendj2.example.com:4444 with the contents of server opendj.example.com:4444 ..... Done. Replication has been successfully enabled. Note that for replication to work you must initialize the contents of the base DN's that are being replicated (use dsreplication initialize to do so). See /tmp/opends-replication-1476402020764482023.log for a detailed log of this operation. $ dsreplication pre-external-initialization --adminUID admin --bindPassword password --port 4444 --baseDN dc=example,dc=com --trustAll --no-prompt Preparing base DN dc=example,dc=com to be initialized externally ..... Done. Now you can proceed to the initialization of the contents of the base DN's on all the replicated servers. You can use the command import-ldif or the binary copy to do so. You must use the same LDIF file or binary copy on each server. When the initialization is completed you must use the subcommand 'post-external-initialization' for replication to work with the new base DN's contents. $ dsreplication post-external-initialization --adminUID admin --bindPassword password --port 4444 --baseDN dc=example,dc=com --trustAll --no-prompt Updating replication information on base DN dc=example,dc=com ..... Done. Post initialization procedure completed successfully. Accept updates from client applications. $ dsconfig set-global-configuration-prop --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --set writability-mode:enabled --trustAll --no-prompt Direct client applications to the server. Certificates This procedure demonstrates using a new self-signed certificate to replace the existing certificate in the admin-truststore and corresponding private key in the admin-keystore. Use CA-signed certificates to protect communications with client applications in production deployments. To hold certificates for StartTLS/SSL, and for communication between servers, OpenDJ uses key stores (for private keys) and trust stores (for public, signed certificates), all located by default in the config/ directory. The default files are as follows. admin-keystore This Java Key Store holds the private key corresponding to the administrative certificate, admin-cert, used to protect communications on the administration port, and for replication. The password is stored in admin-keystore.pin. admin-truststore This Java Key Store holds the public administrative certificate, admin-cert, corresponding to the private key having the same alias in the admin-keystore. The password is the same as for the admin-keystore, in other words the string in admin-keystore.pin. ads-truststore This Java Key Store holds public keys of all servers participating in the replication topology including the current server, and also holds the private key of the current server. The password is stored in ads-truststore.pin. keystore This Java Key Store holds the private key corresponding to the server certificate used to protect TLS/SSL communications with client applications. The password is stored in keystore.pin. truststore This Java Key Store holds the public server certificate corresponding to the private key having the same alias in the keystore. The password is the same as for the keystore, in other words the string in keystore.pin. List information about the contents of the keystore and truststore whose contents you want to replace. $ cd /path/to/OpenDJ/config $ keytool -list -v -keystore admin-keystore -storepass `cat admin-keystore.pin` Remove the certificate to replace from the keystore and from the truststore. $ keytool -delete -alias admin-cert -keystore admin-keystore -storepass `cat admin-keystore.pin` $ keytool -delete -alias admin-cert -keystore admin-truststore -storepass `cat admin-keystore.pin` Generate the private key, storing it in the keystore. $ keytool -genkey -alias admin-cert -keyalg RSA -dname "CN=opendj.example.com, O=Administration Connector Self-Signed Certificate" -keystore admin-keystore -storepass `cat admin-keystore.pin` -keypass `cat admin-keystore.pin` You might choose to make the key valid for two years with -validity 730. Self-sign what you generated. $ keytool -selfcert -alias admin-cert -keystore admin-keystore -storepass `cat admin-keystore.pin` Export the certificate from the keystore. $ keytool -export -alias admin-cert -keystore admin-keystore -storepass `cat admin-keystore.pin` -file admin-cert.crt Certificate stored in file <admin-cert.crt> Import the certificate into the truststore. $ keytool -import -alias admin-cert -keystore admin-truststore -storepass `cat admin-keystore.pin` -file admin-cert.crt Owner: CN=opendj.example.com, O=Administration Connector Self-Signed Certificate Issuer: CN=opendj.example.com, O=Administration Connector Self-Signed Certificate Serial number: 4e0321c6 Valid from: Thu Jun 23 13:21:42 CEST 2011 until: Wed Sep 21 13:21:42 CEST 2011 Certificate fingerprints: MD5: 5C:4B:CC:9A:37:E2:71:BD:C4:86:8E:FC:D4:37:39:57 SHA1: 70:D0:36:0D:EB:0D:AC:45:6D:A4:EF:8A:8E:CB:C7:04:7D:3A:EE:6E Signature algorithm name: SHA1withRSA Version: 3 Trust this certificate? [no]: yes Certificate was added to keystore