10 Setting Up Node Manager for an Enterprise Deployment

This chapter describes how to configure Node Manager according to the Enterprise Deployment recommendations.

Important:

Oracle strongly recommends that you read the Oracle Fusion Middleware Release Notes for any additional installation and deployment considerations before starting the setup process.

This chapter contains the following topics:

10.1 About Setting Up Node Manager

Node Manager enables you to start and stop the Administration Server and the Managed Servers.

Oracle provides two main recommendations for Node Manager configuration in enterprise deployment topologies:

  1. Oracle recommends placing the Node Manager log file in a location that is different from the default one (which is inside the Middleware home where Node Manager resides). See Section 10.2, "Changing the Location of the Node Manager Log File" for further details.

  2. Oracle also recommends using host name verification for the communication between Node Manager and the servers in the domain. This verification requires the use of certificates for the different addresses that are used in the domain. This chapter explains the steps for configuring certificates in the hosts for host name verification. See Section 10.3, "Enabling Host Name Verification Certificates for Node Manager" for further details.

Note:

The passwords that are used in this guide are provided only as examples. Use secure passwords in a production environment. For example, use passwords that consist of random sequences of both uppercase and lowercase characters as well as numbers.

10.2 Changing the Location of the Node Manager Log File

Change the location of the Node Manager log file by editing the nodemanager.properties file, which is located in the MW_HOME/wlserver_10.3/common/nodemanager directory. Add the new location for the log file using the following line:

LogFile=ORACLE_BASE/admin/nodemanager.log

Oracle recommends that this location be outside the MW_HOME directory and inside the admin directory for the EDG.

Restart Node Manager for the change to take effect.

10.3 Enabling Host Name Verification Certificates for Node Manager

Configuring host name verification certificates for communication between Node Manager and the Administration Server consists of the following steps:

10.3.1 Generating Self-Signed Certificates Using the utils.CertGen Utility

The certificates that are added in this chapter (as an example) address a configuration in which Node Manager listens on a physical host name (APPHOSTn.mycompany.com) and a Managed Server listens on a virtual host name (APPHOSTnVHN1.mycompany.com). Whenever a Managed Server is using a virtual host name, it is implied that the Managed Server can be migrated from one node to another. Consequently, the directory where keystores and trust keystores are maintained ideally must reside on a shared storage that is accessible from the failover. If additional host names are used in the same or different nodes, then the steps in this example must be extended to:

  • Add the required host names to the certificate stores (if they are different from APPHOSTn.mycompany.com and APPHOSTnVHN1.mycompany.com).

  • Change the identity and trust store location information for Node Manager (if the additional host names are used by Node Manager) or for the servers (if the additional host names are used by Managed Servers).

Follow these steps to create self-signed certificates on APPHOSTn. These certificates are created using the network name or alias. For information on using trust CA certificates instead, see "Configuring Identity and Trust" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

The following examples configure certificates for APPHOSTn.mycompany.com and APPHOSTnVHN1.mycompany.com; that is, it is assumed that both a physical host name (APPHOSTn) and a virtual host name (APPHOSTnVHN1) are used in APPHOSTn. It is also assumed that APPHOSTn.mycompany.com is the address that is used by Node Manager, and APPHOSTnVHN1.mycompany.com is the address that is used by a Managed Server or the Administration Server. This is the common situation for nodes that host an Administration Server and an Oracle Fusion Middleware component, or for nodes on which two Managed Servers coexist with one server listening on the physical host name and one server using a virtual host name (which is the case for servers that use migration servers).

  1. Configure the environment by running the WL_HOME/server/bin/setWLSEnv.sh script. In the Bourne shell, run the following commands:

    APPHOSTn> cd WL_HOME/server/bin
    APPHOSTn> ../setWLSEnv.sh
    

    Verify that the CLASSPATH environment variable is set: by using the following command:

    APPHOSTn> echo $CLASSPATH
    
  2. Create a user-defined directory for the certificates. For example, create a directory called certs under the ORACLE_BASE/admin/domain_name/cluster_name directory. Note that certificates can be shared across WLS domains.

    APPHOSTn> cd ORACLE_BASE/admin/domain_name/cluster_name
    APPHOSTn> mkdir certs
    

    Note:

    The directory where keystores and trust keystores are maintained must be on shared storage that is accessible from all nodes so that when the servers fail over (manually or with server migration), the appropriate certificates can be accessed from the failover node. Oracle recommends using central or shared stores for the certificates that are used for different purposes (such as SSL configured for HTTP invocations).

  3. Change the directory to the directory that you just created:

    APPHOSTn> cd certs
    
  4. Run the utils.CertGen tool from the user-defined directory to create the certificates for both APPHOSTn.mycompany.com and APPHOSTnVHN1.mycompany.com.

    Syntax (all on a single line):

    java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name 
    [export | domestic] [Host_Name]
    

    Examples:

    APPHOSTn> java utils.CertGen password APPHOSTn.mycompany.com_cert 
    APPHOSTn.mycompany.com_key domestic APPHOSTn.mycompany.com
    
    APPHOSTn> java utils.CertGen password APPHOSTnVHN1.mycompany.com_cert 
    APPHOSTnVHN1.mycompany.com_key domestic APPHOSTnVHN1.mycompany.com
    

    Sample output for the command that is shown in the first example is:

    ...... Will generate certificate signed by CA from CertGenCA.der file
    ...... With Domestic Key Strength
    ...... Common Name will have Hostname APPHOSTn.mycompany.com
    ...... Issuer CA name is CN=CertGenCAB,OU=FOR TESTING ONLY,O=MyOrganization,
    L=MyTown,ST=MyState,C=US
    

10.3.2 Creating an Identity Keystore Using the utils.ImportPrivateKey Utility

Follow these steps to create an identity keystore on APPHOSTn:

  1. Create a new identity keystore called appIdentityKeyStore using the utils.ImportPrivateKey utility. Create this keystore under the same directory as the certificates (that is, ORACLE_BASE/admin/domain_name/cluster_name/certs).

    Note:

    The identity store is created (if none exists) when you import a certificate and the corresponding key into the identity store using the utils.ImportPrivateKey utility.

  2. Import the certificate and private key for both APPHOSTn.mycompany.com and APPHOSTnVHN1.mycompany.com into the identity store. Ensure that you use a different alias for each of the certificate/key pairs imported.

    Syntax (all on a single line):

    java utils.ImportPrivateKey Keystore_File Keystore_Password 
    Certificate_Alias_to_Use Private_Key_Passphrase 
    Certificate_File Private_Key_File [Keystore_Type]
    

    Examples:

    APPHOSTn> java utils.ImportPrivateKey appIdentityKeyStore.jks password 
    appIdentity1 password ORACLE_BASE/admin/domain_name/cluster_name/
    certs/APPHOSTn.mycompany.com_cert.pem ORACLE_BASE/admin/domain_name/
    cluster_name/certs/APPHOSTn.mycompany.com_key.pem
    
    APPHOSTn> java utils.ImportPrivateKey appIdentityKeyStore.jks password 
    appIdentity2 password ORACLE_BASE/admin/domain_name/
    cluster_name/certs/APPHOSTnVHN1.mycompany.com_cert.pem ORACLE_BASE/admin/
    domain_name/cluster_name/certs/APPHOSTnVHN1.mycompany.com_key.pem
    

10.3.3 Creating a Trust Keystore Using the Keytool Utility

You need to perform the steps in this section only for the first Managed Server.

Perform the following steps to create the trust keystore on APPHOST1:

  1. Copy the standard Java keystore to create the new trust keystore because it already contains most of the root CA certificates that are needed. Oracle does not recommend modifying the standard Java trust keystore directly. Copy the standard Java keystore CA certificates that are located in the WL_HOME/server/lib directory to the same directory as the certificates. For example:

    APPHOST1> cp WL_HOME/server/lib/cacerts ORACLE_BASE/admin/domain_name/cluster_name/certs/appTrustKeyStore.jks
    
  2. The default password for the standard Java keystore is "changeit". Oracle recommends always changing the default password. Use the keytool utility to do this. The syntax is (all on a single line):

    APPHOST1> keytool -storepasswd -new New_Password -keystore Trust_Keystore 
    -storepass Original_Password
    

    For example:

    APPHOST1> keytool -storepasswd -new password -keystore appTrustKeyStore.jks 
    -storepass changeit
    
  3. The CA certificate CertGenCA.der is used to sign all certificates that are generated by the utils.CertGen tool. It is located in the WL_HOME/server/lib directory. This CA certificate must be imported into the appTrustKeyStore using the keytool utility. The syntax is (all on a single line):

    APPHOST1> keytool -import -v -noprompt -trustcacerts -alias Alias_Name 
    -file CA_File_Location -keystore Keystore_Location -storepass Keystore_Password
    

    For example:

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

10.3.4 Configuring Node Manager to Use the Custom Keystores

To configure Node Manager to use the custom keystores, add the following lines to the end of the nodemanager.properties file located in the WL_HOME/common/nodemanager directory:

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity_Keystore
CustomIdentityKeyStorePassPhrase=Identity_Keystore_Password
CustomIdentityAlias=Identity_Keystore_Alias
CustomIdentityPrivateKeyPassPhrase=Private_Key_Used_When_Creating_Certificate

Ensure that you use the correct value for CustomIdentityAlias on each node. For example, on APPHOST2, use appIdentity2.

For example:

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/cluster_name/
certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=password
CustomIdentityAlias=appIdentity2
CustomIdentityPrivateKeyPassPhrase=password

The passphrase entries in the nodemanager.properties file get encrypted when you start Node Manager as described in Section 10.4, "Starting Node Manager." For security reasons, you want to minimize the time that the entries in the nodemanager.properties file are left unencrypted. After you edit the file, start Node Manager as soon as possible so that the entries get encrypted.

10.3.5 Configuring Managed Servers to Use the Custom Keystores

You must perform the steps in this section for the Administration Server and all Managed Servers.

Perform the following steps to configure the identity and trust keystores:

  1. Log in to the Oracle WebLogic Server Administration Console.

  2. In the Change Center, click Lock & Edit.

  3. Expand the Environment node in the Domain Structure window.

  4. Click Servers. The Summary of Servers page is displayed.

  5. Click the name of the server for which you want to configure the identity and trust keystores (bi_servern). The settings page for the selected server is displayed.

  6. Select Configuration and Keystores.

  7. In the Keystores field, change to the Custom Identity and Custom Trust method for storing and managing private keys/digital certificate pairs and trusted CA certificates.

  8. In the Identity section, define attributes for the identity keystore using the following steps:

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

      ORACLE_BASE/admin/domain_name/aserver/cluster_name/certs/
      appIdentityKeyStore.jks
      
    2. Custom Identity Keystore Type: Ensure that this field is blank. Do not keep the default value of JKS.

    3. Custom Identity Keystore Passphrase: Enter the keystore password (Keystore_Password) you provided in Section 10.3.2, "Creating an Identity Keystore Using the utils.ImportPrivateKey Utility."

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

  9. In the Trust section, define properties for the trust keystore using the following steps:

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

      ORACLE_BASE/admin/domain_name/cluster_name/certs/
      appTrustKeyStore.jks
      
    2. Custom Trust Keystore Type: This field defaults to JKS. You must explicitly remove the default value so that the field is blank.

    3. Custom Trust Keystore Passphrase: Enter the password that you provided for New_Password in Section 10.3.3, "Creating a Trust Keystore Using the Keytool Utility."

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

  10. Click Save.

  11. In the Change Center, click Activate Changes.

  12. Select Configuration and SSL.

  13. In the Change Center, click Lock & Edit.

  14. In the Private Key Alias field, enter the alias that you used for the host name on which the Managed Server listens.

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

  15. Click Save.

  16. In the Change Center, click Activate Changes.

10.3.6 Changing the Host Name Verification Setting for the Managed Servers

After you perform the steps in the previous sections, you set host name verification for the affected Managed Servers to Bea Host Name Verifier. Perform the following steps to change the host name verification setting for all Managed Servers:

  1. Log in to the Administration Console.

  2. In the Change Center, click Lock & Edit.

  3. Expand the Environment node in the Domain Structure window.

  4. Click Servers. The Summary of Servers page is displayed.

  5. Select the Managed Server in the Names column of the table. The settings page for the server is displayed.

  6. Open the SSL tab.

  7. Expand the Advanced section of the page.

  8. Set Hostname Verification to BEA Hostname Verifier.

  9. Click Save.

  10. In the Change Center, click Activate Changes.

  11. Restart the Managed Server for which the changes have been applied.

10.4 Starting Node Manager

When using a common/shared storage installation for MW_HOME, Node Manager is started from different nodes using the same base configuration (the nodemanager.properties file). In that case, you must add the certificate for all the nodes that share the binaries to the appIdentityKeyStore.jks identity store. To do this, create the certificate for the new node and import it to appIdentityKeyStore.jks as described in Section 10.3.2, "Creating an Identity Keystore Using the utils.ImportPrivateKey Utility." After the certificates are available in the store, each Node Manager must point to a different identity alias to send the correct certificate to the Administration Server. To do this, set different environment variables before starting Node Manager in the different nodes:

APPHOSTn> cd WL_HOME/server/bin
APPHOSTn> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityn

Ensure that you specify the custom identity alias that is specifically assigned to each host. For example, specify appIdentity1 for APPHOST1 and appIdentity2 for APPHOST2.

Note:

Verify that Node Manager is using the appropriate stores and alias from the Node Manager output. Node Manager output is displayed as follows:

CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/cluster_name/certs/appIdentityKeyStore.jks
CustomIdentityAlias=appIdentityn

where n is 1, 2, ...

If you are not using a common/shared storage installation for MW_HOME, then perform the following steps to run commands to restart Node Manager on APPHOSTn:

  1. Stop the Node Manager process by pressing CTRL-C in the shell in which it was started, or by process identification and kill in the operating system.

  2. Start Node Manager, as follows:

    APPHOSTn> cd WL_HOME/server/bin
    APPHOSTn> ./startNodeManager.sh
    

    Note:

    If you have not configured and started Node Manager for the first time, then run the ORACLE_COMMON_HOME/common/bin/setNMProps.sh script. This script enables the use of the start script, which is required for Oracle Business Intelligence.