13 Common Configuration and Management Tasks for an Enterprise Deployment

The following procedure shows how to fail over the Administration Server to a different node (BIHOST2). Note that even after failover, the Administration Server will still use the same Oracle WebLogic Server machine (which is a logical machine, not a physical machine).

After you perform a manual failover of the Administation Server, it is important to verify that you can access the Administration Server, using the standard administration URLs.

After you have tested a manual Administration Server failover, and after you have validated that you can access the administration URLs after the failover, you can then migrate the Administration Server back to its original host.

1. Stop the Administration Server.
2. Stop the Node Manager in the Administration Server domain home onBIHOST2.
3. Run the following command as root on BIHOST2.

   /sbin/ifconfig ethZ:N down
   

4. Run the following command as root on BIHOST1:

   /sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
   

   Note:

   Ensure that the netmask and interface to be used match the available network configuration in BIHOST1

5. Update the routing tables using arping on BIHOST1:

   /sbin/arping -q -U -c 3 -I ethX 100.200.140.206
   

6. Start the Node Manager in the Administration Server domain home on BIHOST1.
7. Start the Administration Server on BIHOST1.
8. Test that you can access the Oracle WebLogic Server Administration Console using the following URL:

   http://ADMINVHN:7001/console
   

9. Check that you can access and verify the status of components in the Oracle Enterprise Manager using the following URL:

   http://ADMINVHN:7001/em
   

In an enterprise deployment, there are scenarios where the software running on the middle tier must access the front-end SSL address of the hardware load balancer. In these scenarios, an appropriate SSL handshake must take place between the load balancer and the invoking servers. This handshake is not possible unless the Administration Server and Managed Servers on the middle tier are started using the appropriate SSL configuration.

1. Set up your environment by running the WL_HOME/server/bin/setWLSEnv.sh script:
2. Verify that the CLASSPATH environment variable is set:

   echo $CLASSPATH
   

3. Verify that the shared configuration directory folder has been created and mounted to shared storage correctly as described in Preparing the File System for an Enterprise Deployment.

   For example, use the following command to verify that the shared configuration directory is available to each host:

   df -h | grep -B1 SHARED_CONFIG_DIR
   

   Replace SHARED_CONFIG_DIR with the actual path to your shared configuration directory.

   You can also do a listing of the directory to ensure it is available to the host:

   ls -al SHARED_CONFIG_DIR
   

4. Create the keystore home folder structure if does not already exist.

   For example:

   cd SHARED_CONFIG_DIR
   mkdir keystores
   chown oracle:oinstall keystores
   chmod 750 keystores 
   

5. Change directory to the keystore home:

   cd KEYSTORE_HOME
   

6. Run the utils.CertGen tool to create the certificates for both the physical host names and the virtual host names used by servers in the node.

   Syntax:

   java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [hostname]
   

   Examples:

   java utils.CertGen password ADMINVHN.example.com_cert \
         ADMINVHN.example.com_key domestic ADMINVHN.example.com
   
   java utils.CertGen password BIHOST1.example.com_cert \
         BIHOST1.example.com_key domestic BIHOST1.example.com
   

1. Import the certificate and private key for ADMINVHN and BIHOST1 into the Identity Store. Make sure that you use a different alias for each of the certificate/key pair imported.

   Syntax:

   java utils.ImportPrivateKey
         -certfile cert_file
         -keyfile private_key_file
         [-keyfilepass private_key_password]
         -keystore keystore
         -storepass storepass
         [-storetype storetype]
         -alias alias 
         [-keypass keypass]
   

   Note:

   Default keystore_type is jks.

   Examples:

   Java utils.ImportPrivateKey 
        -certfile KEYSTORE_HOME/ADMINVHN.example.com_cert.pem
        -keyfile KEYSTORE_HOME/ADMINVHN.example.com_key.pem
        -keyfilepass password
        -keystore appIdentityKeyStore.jks 
        -storepass password
        -alias ADMINVHN
        -keypass password
   
   java utils.ImportPrivateKey 
        -certfile KEYSTORE_HOME/BIHOST1.example.com_cert.pem
        -keyfile KEYSTORE_HOME/BIHOST1.example.com_key.pem
        -keyfilepass password
        -keystore appIdentityKeyStore.jks
        -storepass password 
        -alias BIHOST1
        -keypass password
   

2. Repeat the above step for all the remaining hosts used in the system (for example, BIHOST2).

1. Copy the standard java keystore to create the new trust keystore since it already contains most of the root CA certificates needed.

   Oracle does not recommend modifying the standard Java trust key store directly. Copy the standard Java keystore CA certificates located under the WL_HOME/server/lib directory to the same directory as the certificates. For example:

   cp WL_HOME/server/lib/cacerts KEYSTORE_HOME/appTrustKeyStore.jks
   

2. Use the keytool utility to change the default password.

   The default password for the standard Java keystore is changeit. Oracle recommends always changing the default password, as follows:

   keytool -storepasswd -new NewPassword -keystore TrustKeyStore -storepass Original_Password
   

   For example:

   keytool -storepasswd -new password -keystore appTrustKeyStore.jks -storepass changeit
   

3. Import the CA certificate into the appTrustKeyStore using the keytool utility.

   The CA certificate CertGenCA.der is used to sign all certificates generated by the utils.CertGen tool and is located at WL_HOME/server/lib directory.

   Use the following syntax to import the certificate:

   keytool -import -v -noprompt -trustcacerts -alias AliasName -file CAFileLocation -keystore KeyStoreLocation -storepass KeyStore_Password
   

   For example:

   keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass password
   

1. Access the site on SSL with a browser (this add the server's certificate to the browser's repository).
2. From the browser's certificate management tool, export the certificate to a file that is on the server's file system (with a file name like bi.example.com).
3. Use the keytool to import the load balancer's certificate into the truststore:

   keytool -import -file bi.example.com -v -keystore appTrustKeyStore.jks
   

1. Log in to BIHOST1 and open the following file with a text editor:

   ASERVER_HOME/bin/setDomainEnv.sh
   

2. Replace reference to the existing DemoTrustStore entry with the location of the appTrustKeyStore.jks file.

   Note that all the values for EXTRA_JAVA_PROPERTIES must be on one line in the file, followed by the export command on a new line. For example:

   EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
            -Djavax.net.ssl.trustStore=KEYSTORE_HOME/appTrustKeyStore.jks..."
   export EXTRA_JAVA_PROPERTIES
   

3. Make the same change to the setDomainEnv.sh file in the MSERVER_HOME/bin directory on BIHOST1 and BIHOST2.

1. Log in to the Administration Console, and click Lock & Edit.
2. In the left pane, expand Environment, and select Servers.
3. Click the name of the server for which you want to configure the identity and trust keystores.
4. Select Configuration, and then Keystores.
5. In the Keystores field, click Change, and select Custom Identity and Custom Trust method for storing and managing private keys/digital certificate pairs and trusted CA certificates, and click Save.
6. In the Identity section, define attributes for the identity keystore.

   • Custom Identity Keystore: Enter the fully qualified path to the identity keystore:

     KEYSTORE_HOME/appIdentityKeyStore.jks 
     

   • Custom Identity Keystore Type: Leave this field blank, it defaults to JKS.

   • Custom Identity Keystore Passphrase: Enter the password Keystore_Password you provided in Creating an Identity Keystore Using the utils.ImportPrivateKey Utility

     This attribute may be optional or required depending on the type of keystore. All keystores require the passphrase in order to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server reads only from the keystore, so whether or not you define this property depends on the requirements of the keystore.

7. In the Trust section, define properties for the trust keystore:

   • Custom Trust Keystore: Enter the fully qualified path to the trust keystore:

     KEYSTORE_HOME/appTrustKeyStore.jks 
     

   • Custom Trust Keystore Type: Leave this field blank, it defaults to JKS.

   • Custom Trust Keystore Passphrase: The password you provided in as New_Password in "Creating a Trust Keystore Using the Keytool Utility."

     As mentioned in the previous step, this attribute may be optional or required depending on the type of keystore.

8. Click Save.
9. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
10. Click Lock & Edit.
11. Select Configuration, then SSL.
12. In the Private Key Alias field, enter the alias you used for the host name the managed server listens on.

    In the Private Key Passphrase and the Confirm Private Key Passphrase fields, enter the password for the keystore that you created in Creating an Identity Keystore Using the utils.ImportPrivateKey Utility

13. Click Save.
14. Click Activate Changes in the Administration Console's Change Center to make the changes take effect.
15. Restart the server for which the changes have been applied. The fact that servers can be restarted using the Administration Console/Node Manager is a good verification that the communication between Node Manager, Administration Server and the managed servers is correct.