This chapter describes how to configure the Java version of Node Manager.
This chapter includes the following sections:
In this release, WebLogic Server is moving to a per domain model for Node Manager. For each domain you create, a domain-specific version of Node Manager is created by default. Using the security credentials supplied for the Administration Server, nm_password.properties is created in DOMAIN_HOME\config\nodemanager, where DOMAIN_HOME is typically located at ORACLE_HOME\user_projects\domains\domain_name. The nodemanager.properties and nodemanager.domains files are created for you under DOMAIN_HOME\nodemanager and domain-specific scripts to start, stop, install and uninstall Node Manager as a Windows service, are located under DOMAIN_HOME\bin. With the default Node Manager configuration, you cannot edit the NodeManagerHome location, DOMAIN_HOME\nodemanager.
Using the Configuration Wizard or WLST offline, you can select a PerDomain or CustomLocation Java-based Node Manager configuration. The PerDomain configuration is exactly as described for the default configuration, except that it allows you to provide unique Node Manager credentials. If you want a unique location for NodeManagerHome, select CustomLocation and specify an empty directory or select to create one. The resulting Node Manager also runs as a per domain process.
If you want to continue with a per host Node Manager, for which scripts are located in WL_HOME\server\bin, you must first perform the following prerequisite configuration steps:
Create a nodemanager.domains file that specifies the domains that you want this Node Manager instance to control, under ORACLE_HOME\oracle_common\common\nodemanager, the per host NodeManagerHome location.
You can manually create or copy this file. See Step 4: Configuring nodemanager.domains File.
Alternatively, you can register WebLogic domains with Node Manager using the WLST command, nmEnroll.
By specifying multiple domains in the nodemanager.domains file, you can configure a single, machine-scoped Node Manager process which manages server instances belonging to multiple WebLogic domains, similar to Node Manager functionality from prior WebLogic Server releases.
If you want to use the demonstration Identity and Trust keystores, recommended for development or testing purposes only, you can create them using the CertGen and ImportPrivateKey Java utilities as shown in the following examples:
To properly set up the PATH and CLASSPATH variables, from a command prompt run WL_HOME\server\bin\setWLSEnv.cmd.
Generate a certificate and private key.
java utils.CertGen -keyfilepass DemoIdentityPassPhrase -certfile democert -keyfile demokey
By default utils.CertGen will use the short host name as the owner CN value in the generated certificate. To use the fully-qualified DN host name, add the -cn option to the above command. For example:
java utils.CertGen -keyfilepass DemoIdentityPassPhrase -certfile democert -keyfile demokey -cn abc.oracle.com
Import the private key and certificate.
java utils.ImportPrivateKey -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -keyfile demokey -keyfilepass DemoIdentityPassPhrase -certfile democert.pem -keyfile demokey.pem -alias demoidentity
The DemoIdentity.jks keystore now contains one private key and certificate entry. The other files can be deleted.
Copy the DemoIdentity.jks keystore to the NodeManagerHome \security directory.
For information on configuring SSL for Node Manager in production environments, see Using SSL With Java-based Node Manager.
For domains that include Oracle JRF, you can configure Node Manager to use the Oracle Platform Security Services Keystore Service (OPSS). See "Configuring Node Manager to Use the OPSS Keystore Service" in Administering Oracle Fusion Middleware.
Note:
By default, using SSL with Node Manager is enabled. If not needed, you can disable it by changing to SecureListener=false in the nodemanager.properties file. To review the SSL-related properties in nodemanager.properties, see Table 4-1.
If needed, you can use WLST offline to perform the following Node Manager configuration tasks:
Set the Node Manager user name and password
Set Node Manager properties
Set the Node Manager type
Example 4-1 shows how to set a domain's Node Manager listen address and listen port, the Node Manager user name and password, and the Node Manager type.
Note:
If the Node Manager type is ManualNodeManagerSetup, you cannot use WLST offline to edit Node Manager properties.
Example 4-1 Configuring Node Manager
# set the Node Manager listen address and listen port.
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
# Set the Node Manager user name and password.
cd('/')
cd('SecurityConfiguration/domain_name')
set('NodeManagerUsername','username')
set('NodeManagerPasswordEncrypted','password')
# Set the Node Manager type to custom location type and set the custom location Node Manager home.
setOption('NodeManagerType','CustomLocationNodeManager')
setOption('NodeManagerHome','C:/mydomains/nodemanager')
For more information see "setOption" in WLST Command Reference for WebLogic Server.
Node Manager security relies on a one-way SSL connection between the client and server.
If you are establishing a command-line connection to the Java Node Manager using the WebLogic Server Scripting Tool (WLST) nmConnect command, you provide the Node Manager user name and password. Node Manager verifies the user name and password against the domain nm_password.properties file. For more information on nm_password.properties, see Step 2: Specify Node Manager User Name and Password.
Node Manager credentials are located on the domain_name > Security > General > Advanced Options page in the Administration Console.
Administration Console users do not need to explicitly provide credentials to connect to Node Manager—the Node Manager user name and password are available in the domain configuration and are provided automatically.
A remote start user name and password is required to start a server instance with Node Manager. These credentials are provided differently for Administration Servers and Managed Servers.
Credentials for Managed Servers—When you invoke Node Manager to start a Managed Server it obtains its remote start user name and password from the Administration Server.
Credentials for Administration Servers—When you invoke Node Manager to start an Administration Server, the remote start user name and password can be provided in the following ways:
On the command line. See How Node Manager Starts an Administration Server.
From the Administration Server boot.properties file.
The Configuration Wizard initializes the boot.properties file and the startup.properties file for an Administration Server when you create the domain.
Generated for you in a secure, encrypted way with the following steps:
Start the Administration Server with the flag -Dweblogic.nodemanager.ServiceEnabled=true.
Create the DOMAIN_HOME\servers\AdminServer\data\nodemanager directory.
Update any startup properties or the server's credentials while the both the Administration Server and Node Manager are running.
Any server instance started by Node Manager encrypts and saves the credentials with which it started in a server-specific boot.properties file, for use in automatic restarts.
Node Manager properties define a variety of configuration settings for a Java-based Node Manager process. You can specify Node Manager properties on the command line or define them in the nodemanager.properties file. Values supplied on the command line override the values in nodemanager.properties.
nodemanager.properties is created in the directory specified in NodeManagerHome, where NodeManagerHome typically is ORACLE_HOME\user_projects\domains\domain_name\nodemanager. If NodeManagerHome is not defined, nodemanager.properties is created in the current directory.
Each time you start Node Manager, it looks for nodemanager.properties in the current directory, and creates the file if it does not exist in that directory. You cannot access the file until Node Manager has started up once.
Table 4-1 describes Node Manager properties.
In many environments, the SSL-related properties in nodemanager.properties may be the only Node Manager properties that you must explicitly define. However, nodemanager.properties also contains non-SSL properties in that you might need to specify, depending on your environment and preferences. For example:
For a non-Windows installation, it might be appropriate to specify the StartScriptEnabled and NativeVersionEnabled properties.
If Node Manager runs on a multihomed system, and you want to control which address and port it uses, define ListenAddress and ListenPort.
Table 4-1 Node Manager Properties
| Node Manager Property | Description | Default |
|---|---|---|
|
|
Specifies the version of the |
none |
|
|
If set to |
true |
|
|
Location of the Node Manager log file. |
NodeManagerHome\nodemanager.log
|
|
|
Maximum size of the Node Manager Log specified as an integer. When this limit is reached, a new log file is started. |
unlimited |
|
|
Maximum number of log files to create when |
1 |
|
|
If set to |
true |
|
|
If set to |
false |
|
|
Severity level of logging used for the Node Manager log. Node Manager uses the standard logging levels from the |
INFO |
|
|
Name of formatter class to use for NM log messages. |
weblogic.nodemanager.server.LogFormatter |
|
|
Maximum number of Node Manager backlog requests that the listener will accept. Additional incoming requests will be dropped until the backlogged requests are handled. Typically, you need not adjust this property. |
50 |
|
|
Enables system crash recovery. Note: The |
false |
|
|
If set to |
true |
|
|
The name of the cipher suite to use with the SSL listener. |
The default value is JDK and platform dependent. |
|
|
If true, use the start script specified by |
true |
|
|
The name of the start script, located in the domain directory. |
startWebLogic.sh (UNIX) or startWebLogic.cmd (Windows) |
|
|
If |
false |
|
|
The name of the script to be executed after server shutdown. |
none |
|
|
If set to WLST overrides the default value, |
false |
|
|
The name of the |
NodeManagerHome\nodemanager.domains
|
|
|
If set to |
true |
|
|
Specifies the interval Node Manager waits to perform a check of the server state. |
500 milliseconds |
|
|
Specifies the alias when loading the private key into the keystore. This property is required when the |
none |
|
|
Specifies the file name of the Identity keystore (meaning the keystore that contains the private key for a Node Manager). This property is required when the |
none |
|
|
Specifies the password defined when creating the Identity keystore. This field is 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 only reads from the keystore, so whether or not you define this property depends on the requirements of the keystore. |
none |
|
|
Specifies the type of the Identity keystore. Generally, this is JKS. This property is optional. |
default keystore type from |
|
|
Specifies the password used to retrieve the private key for WebLogic Server from the Identity keystore. This property is required when the |
none |
|
|
The Java home directory that Node Manager uses to start Managed Servers on this machine, if the Managed Server does not have a Java home configured in its Remote Start page. If not specified in either place, Node Manager uses the Java home defined for a Node Manager process. |
none |
|
|
Specifies the password defined when creating the Trust keystore. This field is 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 only reads from the keystore, so whether or not you define this property depends on the requirements of the keystore.This property is required when the |
none |
|
|
Indicates the keystore configuration Node Manager uses to find its identity (private key and digital certificate) and trust (trusted CA certificates). Possible values are:
|
DemoIdentityAndDemoTrust |
|
|
Any address upon which the machine running Node Manager can listen for connection requests. This argument deprecates |
null With this setting, Node Manager will listen on any IP address on the machine |
|
|
The TCP port number on which Node Manager listens for connection requests. This argument deprecates |
5556 |
|
|
A value of true causes native libraries for the operating system to be used. For UNIX systems other than Solaris or Linux, set this property to false to run Node Manager in non-native mode. This will cause Node Manager to use the start script specified by the Note that when
|
true |
|
|
Node Manager root directory which contains the following configuration and log files:
For more information on these files, see Node Manager Configuration and Log Files. Note: By default, |
NodeManagerHome
|
|
|
Root directory of the WebLogic Server installation. This is used as the default value of |
none |
|
|
The path to the private key file to use for SSL communication with the Administration Server. Note: This property is used only in the process of upgrading from WebLogic Server, Version 7.x to Version 9.x. |
none |
|
|
The password used to access the encrypted private key in the key file. Note: This property is used only in the process of upgrading from WebLogic Server, Version 7.x to Version 9.x. |
none |
|
|
Specifies the path to the certificate file used for SSL authentication. Note: This property is used only in the process of upgrading from WebLogic Server, Version 7.x to Version 9.x. |
none |
|
|
The subnet mask for your network. For server migration, each Managed Server must use the same subnet mask to enable unicast and multicast communication among servers. See also, the |
none |
|
|
The primary interface names used by migratable servers. For server migration, the primary interface names used by migratable servers must be the same. See also, the |
none |
|
|
An interface name along with a corresponding range of IP addresses and optional netmask value that should be bound to this specific network interface when migratable servers are started. Syntax: For example, the syntax for binding addresses 1 - 4 to interface eth0=1-4,NetMask=255.255.255.0 bond0=5-8,NetMask=255.255.248.0 You can leave out the eth0=200.10.10.1-200.10.10.255 bond0=199.0.0.1-199.0.0.255 The original For example, specifying these properties in the original format: Interface=oldEth0 NetMask=255.255.255.0 Would be the same as specifying this in the new format: oldEth0=*,Netmask=255.255.255.0 An asterisk (*) can be represent all IPs. |
|
|
|
Specifies whether Node Manager is monitoring a shared domain directory. As such, more than one Node Manager may be monitoring the shared directory from different machines. Set to |
false |
|
|
By default, clients cannot dynamically register a new domain; domains must be configured during the domain creation process or before starting Node Manager. If set to |
false |
You can configure Node Manager to use a script to start a Managed Server or to execute a script after server shutdown has completed. These scripts can be used to perform tasks that need to be performed before a server is started or after it is shutdown. Mounting and unmounting remote disks is one example of a task that can be performed using scripts.
Note:
Node Manager uses startup scripts to perform any required configuration, then start the server. In contrast, stop scripts are executed after the server has shutdown.
Both the start and stop scripts should be placed in the following directory:
DOMAIN_HOME\bin\service_migration
Script execution should occur relative to this directory.
When using start and stop scripts to control server behavior, Oracle recommends that you only edit the top line of the scripts that are provided. This ensures that all of the necessary environment variables are used during script execution.
You can use a start script to specify required startup properties and perform any other work you need performed at start up. To define a start script:
In the nodemanager.properties file, set the StartScriptEnabled property to true. (The default is true.) If your start script is named startWebLogic.sh or startWebLogic.cmd, Node Manager uses one of those scripts as the default.
If you want to specify a custom start script, set the StartScriptName property to the name of your script in the nodemanager.properties file.
Note:
When creating a custom start script, start the server in place instead of running startWebLogic.sh in the background. This way, while the server is running, the custom script process is also running. For example:
# custom stuff # custom stuff startWebLogic.sh
Node Manager sets the JAVA_VENDOR, JAVA_HOME, JAVA_OPTIONS, SECURITY_POLICY, CLASSPATH, and ADMIN_URL. It retrieves these values from the ServerMBean, ServerStartMBean, and SSLMBean when you use the Administration Console to start the server, or WLST connected to the Administration Server. When you use WLST connected directly to Node Manager, you can specify the values; otherwise, they are left empty.
Node Manager combines all of the command line startup options (-D flags) that are specified in the ServerStartMBean Arguments attribute, as well as the SSLArguments into a single environmental variable called JAVA_OPTIONS. SSLArguments are retrieved from the values in the SSLMBean. The SSLMBean is inspected for ignoreHostnameVerification, HostnameVerifier, and ReverseDNSAllowed values, then those values are appended to the -D flags. All of those flags comprise the SSLArguments parameter. All of the values for SSLArguments as well as Arguments in the ServerStartMBean comprise the JAVA_OPTIONS environment variable that is defined for the start script. In addition, the script will append any of its own defined values onto this environment variable.
If there are resulting overlaps in this set of values, it will appear to the Java command line like this:
java -Dflag1=value1 -Dflag1=value2 weblogic.Server
The Java invocation will resolve the duplicate values.
You can use a stop script to perform any tasks that are required after the server has failed.
Note:
Stop scripts are used only to execute a script after a server fails and must be migrated.
In the nodemanager.properties file, set the StopScriptEnabled property to true.
Set the StopScriptName property to the name of your script in the nodemanager.properties file.
The following example shows a stop script that can be used to unmount a disk on UNIX systems:
#!/bin/sh
FS=/cluster/d2
if grep $FS /etc/mnttab > /dev/null 2>&1 ; then
sync
PIDS=`/usr/local/bin/lsof $FS | awk
'{if ($2 ~/[0-9]+/) { print $2} }' | sort -u`
kill -9 $PIDS
sleep 1
sync
/usr/sbin/umount -f $FS
fi
Administration Servers and Managed Servers communicate with Java-based Node Manager using one-way SSL.
The default WebLogic Server installation includes demonstration Identity and Trust keystores that allow you to use SSL out of the box. DemoIdentity.jks is installed in the DOMAIN_HOME\security directory and DemoTrust.jks is in WL_HOME\server\lib . For testing and development purposes, the keystore configuration is complete.
Configuring SSL for a production environment involves obtaining identity for Node Manager and then configuring both identity and trust for each Administration Server and Managed Server with which Node Manager will be communicating. In addition, the use of host name verification and the Administration port must be taken into consideration. To review the SSL-related properties in nodemanager.properties, see Table 4-1. To configure production SSL components, see "Configuring SSL" in Administering Security for Oracle WebLogic Server.
If you have a domain that has Managed Servers on multiple physical machines, you must ensure that Node Manager is installed and configured on each machine. You can use the WLST command nmEnroll to copy all of the required domain and configuration information from one machine to another. For more information, see Accessing Node Manager and nmEnroll in WLST Command Reference for WebLogic Server.
When configuring Node Manager to run as an inetd or xinetd service, the following considerations apply:
Ensure that NodeManagerHome and other system properties are defined.
If xinetd is configured with libwrap, you should add the NOLIBWRAP flag.
Ensure that the hosts.deny and hosts.allow files are configured correctly.
Depending on your network environment, additional configuration may be necessary.
The following example shows how Node Manager can be configured within xinetd:
# default: off
# description:nodemanager as a service
service nodemgrsvc
{
type = UNLISTED
disable = no
socket_type = stream
protocol = tcp
wait = yes
user = <username>
port = 5556
flags = NOLIBWRAP
log_on_success += DURATION HOST USERID
server = <path-to-java>/java
env = CLASSPATH=<cp> LD_LIBRARY_PATH=<ldpath>
server_args = -client -DNodeManagerHome=<NMHome> <java options>
<nodemanager options> weblogic.NodeManager -v
}