Configuring Java Node Manager

3 Configuring Java Node Manager

Learn how to configure the Java implementation of Oracle WebLogic Servers Node Manager.

This chapter includes the following topics:

Overview

The Java implementation of Node Manager is configured by default to control all server instances belonging to the same domain, a per domain Node Manager.

The server instances need not reside on the same machine. If a machine has multiple domains, using per domain Node Manager results in multiple Node Manager process instances. See Default Node Manager Configuration.

In previous versions of Oracle WebLogic Server, Node Manager was not associated with a specific WebLogic domain but only with a host machine. You used the same Node Manager process to control server instances in any WebLogic domain, as long as the server instances resided on the same machine, a machine-scoped, a per host Node Manager. While you can still use per host Node Manager, additional configuration is required. Typically, per host Node Manager is used to manage multiple domains with a single Node Manager instance. See Configuring Per Host Node Manager.

If you are using per domain Node Manager, Oracle WebLogic Server provides the option to have the Node Manager configuration in a custom location. Using the Configuration Wizard or WLST offline, you can select a PerDomain or CustomLocation Java-based Node Manager configuration. For any type of Node Manager configuration, you can provide unique Node Manager credentials, but NodeManagerHome is the default location, as described in Default Node Manager Configuration. If you want a unique location for NodeManagerHome, select CustomLocation and specify an empty directory or select to create one.

If upgrading Node Manager from Oracle WebLogic Server 12.1.1 or earlier to the current version or when upgrading from Oracle WebLogic Server 12.1.2 or later to the current version, see Determining Node Manager Upgrade Procedure in Upgrading Oracle WebLogic Server.

Default Node Manager Configuration

For each Oracle WebLogic Server domain you create, a domain-specific Node Manager instance is created by default. If you choose to use the default per domain Node Manager configuration, no additional steps are necessary to use Node Manager to start and stop server instances in your Oracle WebLogic Server domain.

Using the security credentials provided 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. With the default Node Manager configuration, you cannot edit the NodeManagerHome location, DOMAIN_HOME\nodemanager.

Domain-specific scripts to start, stop, install, and uninstall Node Manager as a Windows service, are located under DOMAIN_HOME\bin. To install Node Manager as a Windows service, you may need to edit the installNodeMgrSvc.cmd script to specify appropriate listen address and listen port values:

Navigate to your DOMAIN_HOME\bin directory.
Edit installNodeMgrSvc.cmd to specify Node Manager's listen address and listen port.

Make the same edits to uninstallNodeMgrSvc.cmd as you make to installNodeMgrSvc.cmd so that you can successfully uninstall the service in the future, as desired.
Run installNodeMgrSvc.cmd to reinstall Node Manager as a service, listening on the updated address and port.

Note:

When configuring multiple per domain Node Manager instances on the same machine, you must use a unique Node Manager address (hostname:port) for each domain, either by using unique ports or unique host names. For example, if you have three per domain Node Manager instances running on the machine, use address localhost:5556 for Domain 1, address localhost:5557 for Domain 2, and localhost:5558 for Domain 3.

Configuring Per Host Node Manager

If you want to use per host Node Manager, for which scripts are located in WL_HOME\server\bin, you must first perform certain prerequisite configuration steps.

Note:

For per host Node Manager configurations, do not set weblogic.RootDirectory in JAVA_OPTIONS to the domain home. If weblogic.RootDirectory points to an existing domain, then the default location for the security subsystem is the domain instead of the Node Manager specific location. Node Manager may then use the domain-specific security settings by default, which could cause the SSL handshake to fail if a second domain attempts to communicate with Node Manager.

Additionally, if you want to use SSL for a per host Node Manager configuration, you must build your own certificate files.

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 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 Oracle WebLogic Server releases.
Configure a machine definition for each machine that runs a Node Manager process. See Configuring a Machine to Use Node Manager.
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:
1. To properly set up the PATH and CLASSPATH variables, from a command prompt run WL_HOME\server\bin\setWLSEnv.cmd.
  
  Note:
  On UNIX operating systems, the setWLSEnv.sh command does not set the environment variables in all command shells. Oracle recommends that you execute this command using the Korn shell or bash shell.
2. 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
```
3. 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 -storetype jks
```
  The DemoIdentity.jks keystore now contains one private key and certificate entry. The other files can be deleted.
4. Copy the DemoIdentity.jks keystore to the NodeManagerHome\security directory.
For information about configuring SSL for Node Manager in production environments, see Using SSL With Java-based Node Manager.

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 3-1.

Configuring Node Manager on Multiple Machines

If you have a domain that has Managed Servers on multiple physical machines, you can use any type of Node Manager (per domain, per host, or custom) to configure Node Manager on multiple machines. However, you should use the same Node Manager type for all machines.

Ensure Node Manager is installed and configured on each machine.

Create the NodeManagerHome location and nodemanager.properties file. By default, NodeManagerHome is DOMAIN_HOME\nodemanager. In a production environment, you might want to customize the location of the Node Manager root directory. The nodemanager.properties file is created in the directory specified in NodeManagerHome and specifies Node Manager properties. See Reviewing nodemanager.properties.

Note:

The NodeManagerHome location should not be shared by multiple Node Manager instances.

Therefore, in a scenario when you are using a shared drive, the NodeManagerHome location on each machine should be unique. For example, create a host name subdirectory under NodeManagerHome, and copy all files to the host name subdirectory.
To enroll a domain with Node Manager, Oracle recommends using the pack and unpack commands to copy all of the required domain and configuration information from one machine to another. See Node Manager Configuration in Creating Templates and Domains Using the Pack and Unpack Commands. You can also use the WLST command nmEnroll to perform this action.
Create the corresponding MachineMBean in the Administration Server that points to each Node Manager instance, so that you can start Managed Servers using Node Manager from any machine.
When the Administration Server is involved in starting a Managed Server, it uses the information in the targeted MachineMBean to create a connection with the correct Node Manager instance. This occurs when using either the WebLogic Server Administration Console, FMWC, or WLST after running the nmConnect command. Creating a corresponding MachineMBean for each physical machine helps point to each Node Manager instance and associates your server instances with the appropriate MachineMBean.

To create a MachineMBean in the Administration Server, perform one of the following actions:
- In the WebLogic Server Administration Console or FMWC, select Environment and click Machines to create a new machine. Configure the information in the MachineMBean and its NodeManagerMBean to point to the Node Manager listen address and listen port. See Create and configure machines in Oracle WebLogic Server Administration Console Online Help.
- Using WLST, create the MachineMBean with the create command. Then, change the settings of the MachineMBean to point to the Node Manager listen address and listen port.
Optionally, repeat any configuration steps you performed if you created Node Manager locally.

See Accessing Node Manager and nmEnroll in WLST Command Reference for Oracle WebLogic Server.

Controlling and Configuring Node Manager Using WLST

The WebLogic Scripting Tool (WLST) is a command-line scripting interface that system administrators and operators use to monitor and manage Oracle WebLogic Server instances and domains. You can start, stop, and restart server instances remotely or locally, using WLST as a Node Manager client. In addition, WLST can obtain server status and retrieve the contents of the server output log and Node Manager log.

See WLST Command and Variable Reference in WLST Command Reference for Oracle WebLogic Server.

Configuring Node Manager Using WLST Offline

You can use WLST offline to configure Node Manager by performing the tasks such as setting the Node Manager user name and password, Node Manager properties, Node Manager type, and keystore properties.

Example 3-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 3-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')

# Set the keystore properties
cd('/')
cd('NMProperties')
set('CustomIdentityKeyStoreFileName','identitykeystore.jks')
set('KeyStores','CustomIdentityAndCustomTrust')
set('CustomIdentityPrivateKeyPassPhrase','password')
set('CustomIdentityAlias','identitykeystore')

See setOption in WLST Command Reference for Oracle WebLogic Server.

Configuring Java-Based Node Manager Security

Java-based Node Manager security uses SSL by default and authenticates incoming connections against a set of credentials specific to each domain.

If you are establishing a command-line connection to the Java Node Manager using the Oracle 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.

Node Manager credentials are located on the Advanced Options page in the WebLogic Server Administration Console. To access this page, click domain_name, select Security, click General, and then click Advanced Options.

WebLogic Server 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.

This section includes the following topics:

Specifying Node Manager User Name and Password

The nm_password.properties file contains the encrypted Node Manager user name and password. These are used to authenticate connection between a client (for example, the Administration Server) and Node Manager.

Note:

This user name and password are only used to authenticate connections between Node Manager and clients. They are independent from the server administration ID and password.

This file is created for you when you use nmEnroll to copy the necessary configurations files from one machine to another when creating a domain or when using the Configuration Wizard. The file is located in DOMAIN_HOME/config/nodemanager, where DOMAIN_HOME is the location of your WebLogic domain, typically, ORACLE_HOME\user_projects\domains\domain_name.

The Configuration Wizard prompts for a Node Manager user name and password for the initial configuration. This value is populated in the required file locally. However, to get it distributed remotely, you must use the nmEnroll command.

After nm_password.properties is created, you can change the values for the Node Manager password and properties using the WebLogic Server Administration Console. Changes are propagated to the nm_password.properties file and are picked up by Node Manager.

You can use the following steps to alter Node Manager credentials:

Start the Administration Server.
Using the WebLogic Server Administration Console, update the Node Manager credentials using the Advanced options page. To access this page, click domain_name, select Security, click General, and then click Advanced Options.
Invoke WLST and connect to an Administration Server using the connect command. See Understanding the WebLogic Scripting Tool.
Run nmEnroll using the following syntax:
```
nmEnroll([domainDir], [nmHome])
```
For example,
```
nmEnroll('C:/oracle/user_projects/domains/prod_domain',
'C:/oracle/user_projects/domains/prod_domain/nodemanager')
```
Running nmEnroll ensures that the correct Node Manager user and password token are supplied to each Managed Server.

Note:

If it does not already exist, you must manually copy the SerializedSystemIni.dat file from the Administration Server domain directory or an existing server in the domain, to this location, ${DOMAIN_HOME}/security/SerializedSystemIni.dat, before running the nmEnroll command.

You must run nmEnroll on each machine that is running a Managed Server. Also run nmEnroll for each domain directory on each machine.

Note:

If you edit nm_password.properties manually (not recommended), you must restart Node Manager in order for the changes to take effect, whereas a restart is not required if you modify the values using the WebLogic Server Administration Console with Node Manager running.

The nm_password.properties file must exist in the domain directory for each physical machine that runs Node Manager. If you change the domain's Node Manager user name and password, you should run nmEnroll on each machine to synchronize the nm_password.properties file. If you configure multiple domains on a machine, each domain can use a different Node Manager user name and password.

In a typical development environment, you may not be prompted to specify the Node Manager user name and password when you create your domain. The Node Manager user name and password default to the administrator credentials, which you can change from the WebLogic Server Administration Console or WLST. However, in a production environment, you must explicitly set the Node Manager user name and password.

Remote Server Start Security for Java-Based Node Manager

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 following setting:
```
-Dweblogic.nodemanager.ServiceEnabled=true
```
  - Create the DOMAIN_HOME\servers\AdminServer\data\nodemanager directory.
  - Update any startup properties or the server's credentials while 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.

Using SSL With Java-Based Node Manager

Administration Servers and Managed Servers communicate with Java-based Node Manager using one-way SSL.

The default Oracle 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.

Configure the CustomIdentityKeyStoreFileName properties in nodemanager.properties to set up a certificate for Node Manager. Node Manager can have its own certificate or it can share a certificate with another aspect of the domain. However, in order to communicate with the Node Manager instance, clients must trust the Identity in the Node Manager certificate. You do not need a separate certificate for each Node Manager instance, but you can configure this option if desired. In production environments, Node Manager can use the same public certificate used for all server instances.

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 3-1. See Configuring SSL in Administering Security for Oracle WebLogic Server.

If Managed Server disables non SSL port, Node Manager needs to trust the certificate received from the server. To configure the trust store for Node Manager, add -Djavax.net.ssl.trustStore to the Node Manager start scripts. See Using Start Scripts.

Advanced Node Manager Configuration

Node Manager supports several advanced settings that you can configure, such as the use of start and stop scripts, the ability to control server instances in multiple domains, the properties for a Java-based Node Manager, the advanced startup properties for Managed Server instances, and more.

This section includes the following topics:

Defining the Administration Server Address

Ensure that a listen address is defined for each Administration Server that will connect to a Node Manager process. If the listen address for an Administration Server is not defined, when Node Manager starts a Managed Server it will direct the Managed Server to contact localhost for its configuration information.

Set the Listen Address using the General page. To access this page, click Servers, select Configuration, and then click General in the WebLogic Server Administration Console.

Configuring Node Manager to Use Start and Stop Scripts

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 instance 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 instance. In contrast, stop scripts are executed after the server instance has shutdown.

This section includes the following topics:

Script Location

Both the start and stop scripts should be placed in the following directory:

DOMAIN_HOME\bin

Script execution should occur relative to this directory.

Best Practices When Using Start and Stop Scripts

When using start and stop scripts to control server behavior, Oracle recommends that you edit only the top line of the scripts that are provided. This ensures that all of the necessary environment variables are used during script execution.

Using Start Scripts

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 weblogic.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 weblogic.StartScriptName property to the name or path of your script in the nodemanager.properties file.
Note:

When creating a custom start script, start the server instance in place instead of running startWebLogic.sh in the background. This way, while the server instance 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 WebLogic Server Administration Console or FMWC to start the server instance, or WLST connected to the WebLogic Server 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.

Using Stop Scripts

You can use a stop script to perform any tasks that are required after the server instance has failed or shut down.

To define a stop script:

In the nodemanager.properties file, set the weblogic.StopScriptEnabled property to true.
Set the weblogic.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

Configuring nodemanager.domains File

The nodemanager.domains file specifies the domains that a Node Manager instance controls. Thus, standalone clients do not need to specify the domain directory explicitly.

Note:

If using per domain Node Manager, you should not modify the nodemanager.domains file. However, if using per host Node Manager, or a custom Node Manager instance, you may need to edit the nodemanager.domains file to specify your domains.

This file must contain an entry specifying the domain directory for each domain a Node Manager instance controls, in this form:

domain-name=domain-directory

When a user issues a command for a domain, Node Manager looks up the domain directory from nodemanager.domains.

This file provides additional security by restricting Node Manager client access to the domains listed in this file. The client can execute commands only for the domains listed in nodemanager.domains.

For the Java-based Node Manager, this file is typically located under ORACLE_HOME\user_projects\domains\domain_name\nodemanager. If you created your domain with the Configuration Wizard, the nodemanager.domains file was created for you. If configuring a per host Node Manager instance, you must manually create or copy a nodemanager.domains file under ORACLE_HOME\oracle_common\common\nodemanager, the per host NodeManagerHome location. See Configuring Per Host Node Manager.

If necessary, you can manually edit nodemanager.domains to add domains or register multiple domain locations under a single domain name.

To configure multiple domain registration, manually enter the alternate paths in the nodemanager.domains file, in this form:

domainName=primaryDomainPath;alternateDomainPath1;alternateDomainPath2

The primaryDomainPath is the path to the domain location where Managed Servers exist and from where they will run, as the Administration Server does not typically pass a path to Node Manager to access a domain. The domain is accessible only by name.

An alternateDomainPath is only accessible by name and path and is typically the location of the Administration Server. Clients connecting directly to Node Manager can access the alternate domain path with both a domain name value and a domain path value.

Note:

If you use the backslash character (\) in nodemanager.domains, you must escape it as (\\).

Example 3-2 nodemanager.domains File

#Domains and directories created by Configuration Wizard
#Mon Jan 07 10:57:18 EST 2013
base_domain=C\:\\Oracle\\Middleware\\Oracle_Home\\user_projects\\domains\\base_domain
prod_domain=C\:\\Oracle\\Middleware\\Oracle_Home\\user_projects\\domains\\prod_domain

Reviewing nodemanager.properties

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.

This section includes the following topics:

Node Manager Properties

Node Manager properties define various configuration settings for a Java-based Node Manager process depending on the server environment. You can specify these properties on the command line or define them in the nodemanager.properties file.

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 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 weblogic.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 3-1 describes Node Manager properties.

Table 3-1 Node Manager Properties

Node Manager Property	Description	Default
`AuthenticationEnabled`	If set to `true`, Node Manager authenticates the credentials against the domain.	`true`
`certificateFile`	Specifies the path to the certificate file used for SSL authentication. Note: This property is used only in the process of upgrading from Oracle WebLogic Server, version 7.x to version 9.x.	`none`
`CipherSuite`	The name of the cipher suite to use with the SSL listener. This property is deprecated in Oracle WebLogic Server 12.1.3.0 but remains fully supported in Oracle WebLogic Server 14.1.1.0.0. See `CipherSuites` for more information and current support limitations for the replacement property.	The default value is JDK and platform dependent.
`CipherSuites`	The name of the cipher suites to use with the SSL listener. You can specify multiple cipher suite values separated by a comma, for example: `CipherSuites=SUITE_A, SUITE_B, SUITE_C` This property introduced in Oracle WebLogic Server 12.1.3 is not currently supported by WLST offline or by the `pack` and `unpack` commands. When using those utilities, use `CipherSuite` instead.	The default value is JDK and platform dependent.
`CoherenceStartScriptEnabled`	When starting standalone Coherence servers, this property specifies whether Node Manager should use a start script for the Coherence instance or a direct Java invocation. This property is deprecated in Oracle WebLogic Server 12.1.3.0 but remains fully supported in Oracle WebLogic Server 14.1.1.0.0. See `coherence.StartScriptEnabled` for more information and current support limitations for the replacement property.	`true`
`CoherenceStartScriptName`	Specifies the start script name or path used to start standalone Coherence servers when `coherence.StartScriptEnabled=true`. This property is deprecated in Oracle WebLogic Server 12.1.3.0 but remains fully supported in Oracle WebLogic Server 14.1.1.0.0. See `coherence.StartScriptName` for more information and current support limitations for the replacement property.	`none`
`coherence.StartScriptEnabled`	When starting standalone Coherence servers, this property specifies whether Node Manager should use a start script for the Coherence instance or a direct Java invocation. This property introduced in Oracle WebLogic Server 12.1.3 is not currently supported by WLST offline or by the `pack` and `unpack` commands. When using those utilities, use `CoherenceStartScriptEnabled` instead.	`true`
`coherence.StartScriptName`	Specifies the start script name or path used to start standalone Coherence servers when `coherence.StartScriptEnabled=true`. This property introduced in Oracle WebLogic Server 12.1.3 is not currently supported by WLST offline or by the `pack` and `unpack` commands. When using those utilities, use `CoherenceStartScriptName` instead.	`none`
`coherence.startup.JavaHome`	Applies when `coherence.StartScriptEnabled=false` and Node Manager invokes Java directly. It is 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. This property introduced in Oracle WebLogic Server 12.1.3 is not currently supported by WLST offline or by the `pack` and `unpack` commands. When using those utilities, use `JavaHome` instead.	`none`
`CrashRecoveryEnabled`	Enables system crash recovery. Note: The `CrashRecoveryEnabled` property takes precedence over the `AutoRestart` server startup property in a crash recovery scenario. For example, if a server instance has `AutoRestart=false` but `CrashRecoveryEnabled=true`, when Node Manager restarts, Node Manager tries to recover the server instance if the server failed when Node Manager was not running.	`false`
`CustomIdentityAlias`	Specifies the alias when loading the private key into the keystore. This property is required when the `Keystores` property is set as `CustomIdentityandCustomTrust` or `CustomIdentityAndJavaStandardTrust`.	`none`
`CustomIdentityKeyStoreFileName`	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 `Keystores` property is set as `CustomIdentity` and `CustomTrust` or `CustomIdentityAndJavaStandardTrust`.	`none`
`CustomIdentityKeyStorePassPhrase`	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 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 or not you define this property depends on the requirements of the keystore.	`none`
`CustomIdentityKeyStoreType`	Specifies the type of the Identity keystore. Generally, this is JKS or PKCS12. This property is optional. If not specified, the JDK default keystore type in the `java.security` file is used.	The default keystore type from `java.security`
`CustomIdentityPrivateKeyPassPhrase`	Specifies the password used to retrieve the private key for Oracle WebLogic Server from the Identity keystore. This property is required when the `Keystores` property is set as `CustomIdentityandCustomTrust` or `CustomIdentityAndJavaStandardTrust`.	`none`
`DomainsDirRemoteSharingEnabled`	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 `true` to indicate that you have a shared domain directory (mounted directory or Windows NFS) that multiple nodes will be sharing. Enabling this property allows multiple Node Managers to share the domain without affecting each other.	`false`
`DomainsFile`	The name of the `nodemanager.domains` file.	`NodeManagerHome\nodemanager.domains`
`DomainsFileEnabled`	If set to `true`, use the file specified in `DomainsFile`. If `false`, assumes the domain of the current directory or of `WL_HOME`.	`true`
`DomainRegistrationEnabled`	This property is deprecated in Oracle WebLogic Server 12.1.3.0 and may be removed in a future release. To register multiple domain locations in the `nodemanager.domains` file, see Configuring nodemanager.domains File.	`false`
`IfConfigDir`	This configuration property sets a different directory for the location of the `wlsifconfig.sh/.cmd` script. This property is deprecated in Oracle WebLogic Server 12.1.3.0 but remains fully supported in Oracle WebLogic Server 14.1.1.0.0. See `weblogic.IfConfigDir` for more information and current support limitations for the replacement property.	By default, this location is set appropriately, but you can use this property to modify the script location.
`Interface`	The primary interface names used by migratable servers. For server migration, the primary interface names used by migratable servers must be the same. See the `<InterfaceName>` property for more flexibility specifying multiple interfaces and a corresponding range of IP addresses that should be bound to a specific interface. This property is deprecated in Oracle WebLogic Server 12.1.3.0 but remains fully supported in Oracle WebLogic Server 14.1.1.0.0. See `<InterfaceName>` for more information.	`none`
`<InterfaceName>`	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: `<InterfaceName>=<IP_RANGE_MIN>-<IP_RANGE_MAX>,`(optional) `NetMask=<NETMASK_ADDRESS>` For example, the syntax for binding addresses 1 - 4 to interface `eth0` and addresses 5 - 8 to `bond0` is: eth0=1-4,NetMask=255.255.255.0 bond0=5-8,NetMask=255.255.248.0 You can leave out the `NetMask` value, if desired, and simply enter: eth0=200.10.10.1-200.10.10.255 bond0=199.0.0.1-199.0.0.255 The original `NetMask` and `Interface` properties are still supported and when specified, would apply to any address that is not already defined in an IP range. For example, specifying these properties in the original format would be the same as specifying this in the new format, as shown below: Original Format: Interface=oldEth0 NetMask=255.255.255.0 New Format: oldEth0=,Netmask=255.255.255.0 An asterisk () can be used to represent all IPs.	`none`
`JavaHome`	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. Note: Oracle recommends not setting this property with the WLST `set` command. If set through WLST, this property reverts to its default value in the `nodemanager.properties` file. This property is deprecated in Oracle WebLogic Server 12.1.3.0 but remains fully supported in Oracle WebLogic Server 14.1.1.0.0. For more information and current support limitations for the replacement properties, see `weblogic.startup.JavaHome` for Oracle WebLogic Server processes and `coherence.startup.JavaHome` for Coherence processes.	`none`
`JavaStandardTrustKeyStorePassPhrase`	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. Oracle WebLogic Server reads only from the keystore, so whether or not you define this property depends on the requirements of the keystore. This property is required when the `Keystores` property is set as `CustomIdentityandJavaStandard` Trust or `DemoIdentityAndDemoTrust`.	`none`
`keyFile`	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 Oracle WebLogic Server, Version 7.x to Version 9.x.	`none`
`keyPassword`	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 Oracle WebLogic Server, version 7.x to version 9.x.	`none`
`KeyStores`	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` - Uses the demonstration Identity and Trust keystores located in the `DOMAIN_HOME\security` and `WL_HOME\server\lib` directories that are configured by default. The demonstration Trust keystore trusts all the certificate authorities in the Java Standard Trust keystore (`JAVA_HOME\jre\lib\security\cacerts`) `CustomIdentityAndJavaStandardTrust` - Uses a keystore you create, and the trusted CAs defined in the `cacerts` file in the `JAVA_HOME\jre\lib\security\cacerts` directory. `CustomIdentityAndCustomTrust` - Uses the Identity and Trust keystores you create.	`DemoIdentityAndDemoTrust`
`ListenAddress`	Any address upon which the machine running Node Manager can listen for connection requests. This argument deprecates `weblogic.nodemanager.listenAddress`.	`null` With this setting, Node Manager will listen on any IP address on the machine
`ListenBacklog`	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`
`ListenPort`	The TCP port number on which Node Manager listens for connection requests. This argument deprecates `weblogic.nodemanager.listenPort`.	`5556`
`LogAppend`	If set to `true`, then a new log file is not created when Node Manager restarts; the existing log is appended instead.	`true`
`LogCount`	Maximum number of log files to create when `LogLimit` exceeds.	`1`
`LogFile`	Location of the Node Manager log file.	`NodeManagerHome\nodemanager.log`
`LogFormatter`	Name of formatter class to use for Node Manager log messages.	`weblogic.nodemanager.server.LogFormatter`
`LogLevel`	Severity level of logging used for the Node Manager log. Node Manager uses the standard logging levels from the `java.util.logging.level` package, `http://docs.oracle.com/javase/8/docs/api/java/util/logging/Level.html`.	`INFO`
`LogLimit`	Maximum size of the Node Manager log specified as an integer in bytes. When this limit is reached, a new log file is started.	`unlimited`
`LogToStderr`	If set to `true`, the log output is also sent to the standard error output.	`false`
`NativeVersionEnabled`	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 `weblogic.StartScriptEnabled` property to start Managed Servers. Note: When `NativeVersionEnabled=false`: Node Manager cannot query if a PID is alive nor kill a particular process. Node Manager does not have the ability to determine if there are existing processes that need to be monitored and crash recovery is not fully implemented. `nmKill` is not supported when `NativeVersionEnabled=false` and `weblogic.StartScriptEnabled=true`.	`true`
`NetMask`	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 the `<InterfaceName>` property for more flexibility entering multiple interfaces and corresponding netmask values. This property is deprecated in Oracle WebLogic Server 12.1.3.0 but remains fully supported in Oracle WebLogic Server 14.1.1.0.0. See `<InterfaceName>` for more information.	`none`
`NodeManagerHome`	Node Manager root directory which contains the following configuration and log files: `nodemanager.domains` `nodemanager.log` `nodemanager.properties` See Node Manager Configuration and Log Files. Note: By default, `NodeManagerHome` is `DOMAIN_HOME\nodemanager`. In a production environment, you might want to customize the location of the Node Manager root directory. Oracle recommends not setting this property with the WLST `set` command. If set through WLST, this property reverts to its default value in the `nodemanager.properties` file.	`NodeManagerHome`
`PropertiesVersion`	Specifies the version of the `nodemanager.properties` file. Do not change this value.	`none`
`ProcessDestroyTimeout`	Specifies the time a NodeManager waits to check if the Managed Server that was started by the start script is stopped. If `NativeVersionEnabled` is set to `false` (default value is `true`) and `weblogic.StartScriptEnabled` is set to `true` (default value is `true`), a start script starts the monitored Managed Server and that will be a child process. In this case, the `ProcessDestroyTimeout` value (by default 20 seconds) determines how long the Node Manager should wait to check if the Managed Server is stopped. If the child process does not stop within the specified timeout value: Connect to the Administration Server to request a shutdown for the Managed Server. When the shutdown fails, use `nmKill` to kill the specified server instance. If there is no option to stop the Managed Server, use Operating System (OS) level process kill to terminate the server instance and related OS processes. This property was introduced in Oracle WebLogic Server 12.1.2 and backported to 10.3.6.x.	`20 seconds`
`QuitEnabled`	If set to `true`, allows you to remotely stop Node Manager. WLST overrides the default value, `false`, when stopping Node Manager using the `stopNodeManager()` command.	`false`
`SecureListener`	If set to `true`, use the SSL listener, otherwise use the plain socket.	`true`
`StartScriptEnabled`	If set to `true`, use the start script specified by `StartScriptName` to start a server instance. See Configuring Node Manager to Use Start and Stop Scripts. This property is deprecated in Oracle WebLogic Server 12.1.3.0 but remains fully supported in Oracle WebLogic Server 14.1.1.0.0. See `weblogic.StartScriptEnabled` for more information on the replacement property.	`true`
`StartScriptName`	The name or path of the start script, located in the domain directory. This property is deprecated in Oracle WebLogic Server 12.1.3.0 but remains fully supported in Oracle WebLogic Server 14.1.1.0.0. See `weblogic.StartScriptName` for more information on the replacement property.	`startWebLogic.sh (UNIX)` or `startWebLogic.cmd (Windows)`
`StateCheckInterval`	Specifies the interval Node Manager waits to perform a check of the server state.	`500 milliseconds`
`StopScriptEnabled`	If set to `true`, execute the stop script specified by `StopScriptName` after the server instance has shutdown. See Configuring Node Manager to Use Start and Stop Scripts. This property is deprecated in Oracle WebLogic Server 12.1.3.0 but remains fully supported in Oracle WebLogic Server 14.1.1.0.0. See `weblogic.StopScriptEnabled` for more information and current support limitations for the replacement property.	`false`
`StopScriptName`	The name of the script to be executed after server shutdown. This property is deprecated in Oracle WebLogic Server 12.1.3.0 but remains fully supported in Oracle WebLogic Server 14.1.1.0.0. See `weblogic.StopScriptName` for more information and current support limitations for the replacement property.	`none`
`UseMACBroadcast`	Specifies whether or not to use a node's MAC address when sending ARP packets, that is, whether or not to use the -b flag in the `arping` command. When Node Manager binds IP addresses for automatic server migration, it also uses the `arping` command to attempt to notify nodes in the network that the machine is now using the virtual IP address. When `weblogic.UseMACBroadcast=true`, Node Manager uses the `arping` command with the -b flag. This property is deprecated in Oracle WebLogic Server 12.1.3.0 but remains fully supported in Oracle WebLogic Server 14.1.1.0.0. See `weblogic.UseMACBroadcast` for more information and current support limitations for the replacement property.	`false`
`WebLogicHome`	Root directory of the Oracle WebLogic Server installation. This is used as the default value of `-Dweblogic.RootDirectory` for a Managed Server that does not have a root directory configured in its Remote Start page. If not specified in either place, Node Manager starts the Managed Server in the directory where Node Manager runs.	`none`
`weblogic.IfConfigDir`	This configuration property sets a different directory for the location of the `wlsifconfig.sh/.cmd` script. This property introduced in Oracle WebLogic Server 12.1.3 is not currently supported by WLST offline or by the `pack` and `unpack` commands. When using those utilities, use `IfConfigDir` instead.	By default, this location is set appropriately, but you can use this property to modify the script location.
`weblogic.StartScriptEnabled`	If set to `true`, use the start script specified by `weblogic.StartScriptName` to start a server instance. See Configuring Node Manager to Use Start and Stop Scripts.	`true`
`weblogic.StartScriptName`	The name or path of the start script, located in the domain directory.	`startWebLogic.sh (UNIX)` or `startWebLogic.cmd (Windows)`
`weblogic.startup.JavaHome`	Applies when `weblogic.StartScriptEnabled=false` and Node Manager invokes Java directly. Specifies 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. This property introduced in Oracle WebLogic Server 12.1.3 is not currently supported by WLST offline or by the `pack` and `unpack` commands. When using those utilities, use `JavaHome` instead.	`none`
`weblogic.StopScriptEnabled`	If set to `true`, execute the stop script specified by `weblogic.StopScriptName` after the server instance has shutdown. See Configuring Node Manager to Use Start and Stop Scripts. This property introduced in Oracle WebLogic Server 12.1.3 is not currently supported by WLST offline or by the `pack` and `unpack` commands. When using those utilities, use `StopScriptEnabled` instead.	`false`
`weblogic.StopScriptName`	The name of the script to be executed after server shutdown. This property introduced in Oracle WebLogic Server 12.1.3 is not currently supported by WLST offline or by the `pack` and `unpack` commands. When using those utilities, use `StopScriptName` instead.	`none`
`weblogic.UseMACBroadcast`	Specifies whether or not to use a node's MAC address when sending ARP packets, that is, whether or not to use the -b flag in the `arping` command. When Node Manager binds IP addresses for automatic server migration, it also uses the `arping` command to attempt to notify nodes in the network that the machine is now using the virtual IP address. When `weblogic.UseMACBroadcast=true`, Node Manager uses the `arping` command with the -b flag. This property introduced in Oracle WebLogic Server 12.1.3 is not currently supported by WLST offline or by the `pack` and `unpack` commands. When using those utilities, use `UseMACBroadcast` instead.	`false`

Machine-Level Node Manager Settings for a Group of Server Instances

If you have a group of server instances started by the same Node Manager instance, you can configure certain machine-level settings once in the nodemanager.properties file and these settings will apply to all server instances in that group. Setting machine-level attributes simplifies configuration, as you do not have to configure common settings in the ServerStartMBean for each server instance.

If you configure specific settings for a server instance directly in the ServerStartMBean, that value takes precedence over any values configured in the nodemanager.properties file.

Table 3-2 describes the machine-level settings you can configure in nodemanager.properties for a group of server instances started by the same Node Manager instance.

Table 3-2 Machine-Level Node Manager Properties for a Group of Server Instances

Property Name	Description
`coherence.startup.Arguments`	The Java arguments to use when starting the server instance. These are the first arguments appended immediately after `java` portion of the startup command. For example, you can set Java heap memory or specify any `weblogic.nodemanager.server.provider.WeblogicCacheServer` option. Separate arguments with a space.
`coherence.startup.MW_Home`	The `MW_HOME` directory (the path on the machine running Node Manager) to use when starting this server instance. Specifies the directory on the Node Manager machine under which all Oracle Middleware products are installed. For example, `C:\Oracle\Middleware`.
`weblogic.startup.Arguments`	The Java arguments to use when starting the server instance. Node Manager passes this value to a start script using the `JAVA_OPTIONS` environment variable. When issuing a Java command line to start the server instance, Node Manager passes the arguments as options.
`weblogic.startup.Arguments.prepend`	Prepends flags to any arguments configured for the server instances.
`weblogic.startup.ClassPath`	The classpath (the path on the machine running Node Manager) to use when starting this server instance. Node Manager passes this value to a start script using the `CLASSPATH` environment variable. When issuing a Java command line to start the server instance, Node Manager defines the classpath with `-Djava.class.path=`.
`weblogic.startup.JavaVendor`	The Java vendor value to use when starting the server instance. Node Manager does not pass this value when invoking a Java command line to start the server instance. It does pass this value in the environment variable `JAVA_VENDOR` to the start script.
`weblogic.startup.MW_Home`	The `MW_HOME` directory (the path on the machine running Node Manager) to use when starting this server instance. Node Manager does not pass this value to start scripts. When issuing a Java command line to start the server instance, Node Manager specifies `MW_HOME` with `-Dbea.home=`.
`weblogic.startup.SecurityPolicyFile`	The security policy file (the directory and file name on the machine running Node Manager) to use when starting this server instance. When Node Manager uses a start script, the security policy file is defined in an environment variable, `SECURITY_POLICY`. When issuing a Java command line to start the server instance, Node Manager defines the security policy with `-Djava.security.policy=`.
`weblogic.startup.ServerGID`	The group ID for the server instance.
`weblogic.startup.ServerUID`	The user ID for the server instance.

Configuring Remote Startup Arguments

In the WebLogic Server Administration Console or FMWC, use the Server Start page for the Managed Server to specify the startup arguments that Node Manager will use to start a Managed Server. To access this page, click Server, select Configuration, and then click Server Start. If you do not specify startup arguments for a Managed Server, default values are used, as appropriate for the Managed Server. If using the Java-based implementation, Node Manager uses its own properties as defaults to start the Managed Server. If using the script-based implementation, the start script sets the default values. See Reviewing nodemanager.properties.

Although these defaults are sufficient to boot a Managed Server, to ensure a consistent and reliable boot process, configure startup arguments for each Managed Server instance. The specified startup arguments are used for starting Managed Servers only. They will not be used by an Administration Server instance that is started by Node Manager.

If you run Node Manager as a Windows service, as described in Running Node Manager as a Startup Service, you must configure the -Xrs JVM property for each Managed Server that will be under the Node Manager control.

If you do not set this option, Node Manager will not be able to restart a Managed Server after a system reboot, due to this sequence of events:

A reboot causes a running Managed Server to be killed before Node Manager and Administration Server operating system services are shut down.
During the interval between the Managed Server being killed, and a Node Manager service being shut down, Node Manager continues to monitor the Managed Server, detects that it was killed, and attempts to restart it.
The operating system does not allow restart of the Managed Server because the machine is shutting down.
Node Manager marks the Managed Server as failed, and it will not start this server when the machine comes up again.

Starting a Managed Server with the -Xrs or -Xnohup option avoids this sequence of events by preventing the immediate shutdown of the Managed Server during machine shutdown.

Setting Server Startup Properties

You can use Node Manager to set the startup properties for a server instance. These properties can be defined in startup.properties or passed as an object using administrative utilities such as WLST. The methods of setting startup properties and their valid values are outlined in the sections below.

This section includes the following topics:

startup.properties

Node Manager uses the startup.properties file to determine the startup configuration when starting a server instance. This file is defined for each server instance and is located in DOMAIN_HOME/servers/server_name/data/nodemanager/startup.properties.

The contents of startup.properties are derived from the Server MBean, or the Cluster MBean if the server instance is part of a cluster. See the MBean Reference for Oracle WebLogic Server.

Setting Startup Properties Using WLST

When using the WLST nmStart command, the server configuration cannot be determined directly. Therefore, you must pass the server start properties as a WLST properties object to the nmStart command.

Server Startup Properties

The following server startup properties can be passed to a server instance when started using Node Manager.

Table 3-3 Server Startup Properties

Property	Description
`AdminURL`	The URL of the Administration Server. Note: This value should only be specified in the `startup.properties` file for a Managed Server.
`Arguments`	The arguments used when starting the server instance.
`AutoKillIfFailed`	When a server instance is started by Node Manager, this attribute signals that the `OverloadProtectionMBean` settings will be changed to `FailureAction == FORCE_SHUTDOWN` and `PanicAction == SYSTEM_EXIT`. For more information about `FailureAction` and `PanicAction`, see `OverloadProtectionMBean` in MBean Reference for Oracle WebLogic Server.
`AutoRestart`	Specifies whether Node Manager can automatically restart this server instance if it fails. Note: The `CrashRecoveryEnabled` configuration property takes precedence over the `AutoRestart` property in a crash recovery scenario. For example, if a server instance has `AutoRestart=false` but `CrashRecoveryEnabled=true`, when Node Manager restarts, Node Manager tries to recover the server instance if the server failed when Node Manager was not running.
`ClassPath`	The classpath to use when starting a server instance.
`JavaHome`	Defines the Java home directory used when starting the server instance.
`OracleHome`	The Oracle home directory to use when starting a server instance.
`RestartDelaySeconds`	The number of seconds Node Manager should wait before attempting to restart the server instance.
`RestartInterval`	The amount of time Node Manager will spend attempting to restart a failed server instance. Within this period of time Node Manager will attempt to restart the failed server up to the number defined by `RestartMax`. By default, Node Manager will attempt to restart a server instance indefinitely until the `FAILED_NOT_RESTARTABLE` state is reached.
`RestartMax`	The number of times Node Manager will attempt to restart a failed server within the interval defined by `RestartInterval`. `RestarMax` is recognized only if `RestartInterval` is defined.
`SecurityPolicyFile`	Specifies the security policy file to use when starting this server.
`ServerIP`	The IP address of the server.
`SSLArguments`	These arguments are used when you have enabled the domain-wide administration port.

Setting the Node Manager Environment Variables

By default, you need not set any additional environment variables before starting Node Manager. The sample Node Manager start scripts and install service scripts provided with Oracle WebLogic Server set the required variables and start Node Manager listening on the default address, localhost.

To start Node Manager listening on a non-default address, you can use one of the following methods:

Edit the nodemanager.properties file.

Set the LISTEN_ADDRESS variable to <host> and the LISTEN_PORT variable to <port> before calling the startNodeManager script. See Reviewing nodemanager.properties.
Set the values when executing the WL_HOME\server\bin\startNodeManager for a per host Node Manager.

Note:

You cannot change the listen address or listen port using the startNodeManager script for the per domain Node Manager (DOMAIN_HOME/bin/startNodeManager). This method works only for the per host Node Manager.

The startNodeManager scripts will set the first two positional parameters to LISTEN_ADDRESS and LISTEN_PORT when entered on the command line.

For example, enter this command to start Node Manager on host llama and port 7777:
```
startNodeManager.cmd llama 7777 (Windows)
sh startNodeManager.sh llama 7777 (UNIX)
```
Enter this command to start Node Manager on host llama:
```
startNodeManager.cmd llama (Windows)
sh startNodeManager.sh llama (UNIX)
```

Configuring a non-default listening address for Node Manager is most useful in production environments so that traffic from other machines can potentially reach it. Also, if you have a multihomed machine or a machine with multiple network interface cards, Node Manager can be listening on any one of the addresses on the machine.

Table 3-4 Node Manager Environment Variables

Environment Variable	Description
`CLASSPATH`	You can set the Node Manager `CLASSPATH` either as an option on the `java` command line used to start Node Manager, or as an environment variable. Windows NT example: `set CLASSPATH=.;%WL_HOME%\server\lib\weblogic_sp.jar;%WL_HOME%\server\lib\ weblogic.jar`
`JAVA_HOME`	JDK root directory used by Node Manager. For example: `set JAVA_HOME=c:\jdk1.7.0_06` Node Manager has the same JDK version requirements as Oracle WebLogic Server.
`LD_LIBRARY_PATH` (UNIX and Linux)	For Solaris systems, you must include the path to the native Node Manager libraries. Solaris example: `LD_LIBRARY_PATH:$WL_HOME/server/lib/solaris:$WL_HOME/server/lib/solaris/oci816_8` Linux example: `LD_LIBRARY_PATH:$WL_HOME/server/native/linux:$WL_HOME/server/native/linux/i686` Note: Linux can be `i686`, `ia64`, or `x86_64` architecture. The path would change to correspond with the appropriate architecture.
`PATH`	Must include the Oracle WebLogic Server bin directory and path to your Java executable. For example: `set PATH=%WL_HOME%\server\bin;%JAVA_HOME%\bin;%PATH%`
`WL_HOME`	Oracle WebLogic Server installation directory. For example: `set WL_HOME=c:\Oracle\Middleware\Oracle_Home\wlserver`

Configuring Node Manager as an xinetd Service

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, perform additional configurations if necessary.

The following example shows how Node Manager can be configured within xinetd:

#
# Create the $domaindir/bin/startNMService.sh script or the
# $WL_HOME/server/bin/startNMService.sh script to produce output to a file.
#

#!/bin/sh
 
$domaindir/bin/startNodeManager.sh >> $NM_HOME/nmservice.out 2>&1

#
# The service can now take advantage of the startNMService script.
#

# default: off
# description:nodemanager as a service

service nodemanager-svc
{
   type            = UNLISTED
   disable         = yes
   socket_type     = stream
   protocol        = tcp
   wait            = yes
   user            = <username>
   port            = 5556
   flags           = NOLIBWRAP 
   log_on_success += DURATION HOST USERID
   server          = /scratch/jdorr/dom1213/bin/startNMService.sh
   env             = MW_HOME=/Oracle/Middleware/Oracle_Home_WLS_12.2.1 JAVA_HOME=/Java/jdk1.7.0_51LD_LIBRARY_PATH=/Oracle/Middleware/Oracle_Home_WLS_12.2.1/bea/wlserver/server/native/linux/x86_64:/usr/lib:/lib:/usr/X11R6/lib
}

Configuring Node Manager as an init.d Service

You can configure Node Manager as an init.d service using init startup scripts. This section includes the following topics:

Configuring Per Domain Node Manager as an init.d Service

To install and configure a per domain Node Manager as an init.d service, complete the following steps. Execute all actions as the root user.

Note:

When Node Manager runs as an init.d service, the launched Managed Servers are owned by the root user. To start Managed Servers as non-root user, first use the Administration Console to enable the Post-Bind UID and Post-Bind GID attributes on the General page. To access this page, click Domain, select Environment, select Machines, and then click Configuration. Then, restart the Node Manager and the Administration Server before restarting the Managed Servers.

Determine the service name, referred to as <service name> in the following steps.

Oracle recommends using the naming pattern DOMAIN_NAME-nodemanager, for example, base_domain-nodemanager.
Copy the sample script in Example 3-3 to /etc/init.d/<service name>.
Edit /etc/init.d/<service name> and change the following variables according to your environment and installation:
- The Provides setting in the ###BEGIN INIT INFO section in Example 3-3
- The DOMAIN_HOME setting in the ###BEGIN CUSTOM ENV section in Example 3-3
Make /etc/init.d/<service name> executable by using the chmod +x command.
Add your init.d service: sudo /sbin/chkconfig --add <service name>

To start, stop, restart, or show the status of your service, use the following commands:

Task	Command
To start the service	`sudo /sbin/service <service name> start`
To stop the service	`sudo /sbin/service <service name> stop`
To restart the service	`sudo /sbin/service <service name> restart`
To show the status of the service	`sudo /sbin/service <service name> status`

Example 3-3 Configuring a Per Domain Node Manager as an init.d Service

#!/bin/sh
#
# chkconfig:   345 85 15
# description: per domain Oracle Weblogic Node Manager service init script
 
### BEGIN INIT INFO
# Provides: jtest-dom1213-nodemanager
# Required-Start: $network $local_fs
# Required-Stop:
# Should-Start:
# Should-Stop:
# Default-Start: 3 4 5
# Default-Stop: 0 1 2 6
# Short-Description: per domain Oracle Weblogic Node Manager service.
# Description: Starts and stops per domain Oracle Weblogic Node Manager.
### END INIT INFO
 
. /etc/rc.d/init.d/functions
 
#### BEGIN CUSTOM ENV
DOMAIN_HOME="/scratch/jdorr/dom1213"
MW_HOME=/Oracle/Middleware/Oracle_Home_WLS_12.2.1
JAVA_HOME=/Java/jdk1.7.0_51
LD_LIBRARY_PATH=/Oracle/Middleware/Oracle_Home_WLS_12.2.1/bea/wlserver/server/native/linux/x86_64:/usr/lib:/lib:/usr/X11R6/lib
#### END CUSTOM ENV
 
PROCESS_STRING="^.*$DOMAIN_HOME.*weblogic.NodeManager.*"
PROGRAM_START="$DOMAIN_HOME/bin/startNodeManager.sh"
NODEMANAGER_DIR=$DOMAIN_HOME/nodemanager
NODEMANAGER_LOCKFILE="$NODEMANAGER_DIR/nodemanager.log.lck"
OUT_FILE="$NODEMANAGER_DIR/nodemanager.out"
 
SERVICE_NAME=`/bin/basename $0`
LOCKFILE="/var/lock/subsys/$SERVICE_NAME"
 
RETVAL=0
 
start() {
        OLDPID=`/usr/bin/pgrep -f $PROCESS_STRING`
        if [ ! -z "$OLDPID" ]; then
            echo "$SERVICE_NAME is already running (pid $OLDPID) !"
            echo
            exit
        fi
        echo -n $"Starting $SERVICE_NAME ... "
        echo "`date` Starting $SERVICE_NAME ... " > $OUT_FILE 2>&1 
        export MW_HOME
        export JAVA_HOME
export LD_LIBRARY_PATH
$PROGRAM_START >> $OUT_FILE 2>&1  &
 
        RETVAL=$?
        if [ $RETVAL -eq 0 ] ; then
          wait_for "socket listener started on port"
        else
          echo "FAILED: $RETVAL. Please check $OUT_FILE for more information."
        fi
        echo
}
 
wait_for() {
    res=$(cat "$OUT_FILE" | fgrep -c "$1")
    count=60
    while [[ ! $res -gt 0 ]] && [[ $count -gt 0 ]]
    do
        sleep 1
        count=$(($count - 1))
        res=$(cat "$OUT_FILE" | fgrep -c "$1")
    done
    res=$(cat "$OUT_FILE" | fgrep -c "$1")
    if [ ! $res -gt 0 ]; then
        echo "FAILED or took too long time to start. Please check $OUT_FILE for more information."
    else
        echo "OK"
        touch $LOCKFILE
    fi
}
 
stop() {
        echo -n $"Stopping $SERVICE_NAME ... "
        OLDPID=`/usr/bin/pgrep -f $PROCESS_STRING`
        if [ "$OLDPID" != "" ]; then
            echo -n "(pid $OLDPID) "
            /bin/kill -TERM $OLDPID
 
            RETVAL=$?
            echo "OK"
            /bin/rm -f $NODEMANAGER_LOCKFILE
            [ $RETVAL -eq 0 ] && rm -f $LOCKFILE
        else
            /bin/echo "$SERVICE_NAME is stopped"
        fi
        echo
}
 
restart() {
        stop
        sleep 10
        start
}
 
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart|force-reload|reload)
        restart
        ;;
  condrestart|try-restart)
        [ -f $LOCKFILE ] && restart
        ;;
  status)
        OLDPID=`/usr/bin/pgrep -f $PROCESS_STRING`
        if [ "$OLDPID" != "" ]; then
            /bin/echo "$SERVICE_NAME is running (pid: $OLDPID)"
        else
            /bin/echo "$SERVICE_NAME is stopped"
        fi
        echo
        RETVAL=$?
        ;;
  *)
        echo $"Usage: $0 {start|stop|status|restart|reload|force-reload|condrestart}"
        exit 1
esac
 
exit $RETVAL

Configuring Per Host Node Manager as an init.d Service

To install and configure a per host Node Manager as an init.d service, complete the following steps. Execute all actions as the root user.

Before you begin, ensure the per host Node Manager is correctly configured in your domain before using this script. See Configuring Per Host Node Manager.

Determine the service name, referred to as <service name> in the following steps.

Oracle recommends using the naming pattern <a brief name for MW_HOME>-nodemanager, for example, wls12.2.1-nodemanager.
Copy the sample script in Example 3-4 to /etc/init.d/<service name>.
Edit /etc/init.d/<service name> and change the following variables according to your environment and installation:
- the Provides setting in the ###BEGIN INIT INFO section in Example 3-4
- the MW_HOME setting in the ###BEGIN CUSTOM ENV section in Example 3-4
Make /etc/init.d/<service name> executable by using the chmod +x command.
Add your init.d service: sudo /sbin/chkconfig --add <service name>

To start, stop, restart, or show the status of your service, use the following commands:

Task	Command
To start the service:	`sudo /sbin/service <service name> start`
To stop the service:	`sudo /sbin/service <service name> stop`
To restart the service:	`sudo /sbin/service <service name> restart`
To show the status of the service:	`sudo /sbin/service <service name> status`

Example 3-4 Configuring a Per Host Node Manager as an init.d Service

#!/bin/sh
#
# chkconfig:   345 85 15
# description: global (per host) Oracle Weblogic Node Manager service init script
 
### BEGIN INIT INFO
# Provides: jjjnm 
# Required-Start: $network $local_fs
# Required-Stop:
# Should-Start:
# Should-Stop:
# Default-Start: 3 4 5
# Default-Stop: 0 1 2 6
# Short-Description: per host Oracle Weblogic Node Manager service
# Description: Starts and stops per host Oracle Weblogic Node Manager
### END INIT INFO
 
. /etc/rc.d/init.d/functions
 
#### BEGIN CUSTOM ENV
MW_HOME=/Oracle/Middleware/Oracle_Home_WLS_12.2.1
JAVA_HOME=/Java/jdk1.7.0_51
LD_LIBRARY_PATH=/Oracle/Middleware/Oracle_Home_WLS_12.2.1/bea/wlserver/server/native/linux/x86_64:/usr/lib:/lib:/usr/X11R6/lib
#### END CUSTOM ENV
 
PROGRAM_START="$MW_HOME/wlserver/server/bin/startNodeManager.sh"
NODEMANAGER_DIR="$MW_HOME/wlserver/../oracle_common/common/nodemanager"
NODEMANAGER_LOCKFILE="$NODEMANAGER_DIR/nodemanager.log.lck"
OUT_FILE="$NODEMANAGER_DIR/nodemanager.out"
PROCESS_STRING="^.*\-Dweblogic.RootDirectory=$NODEMANAGER_DIR.*weblogic.NodeManager.*"
 
SERVICE_NAME=`/bin/basename $0`
LOCKFILE="/var/lock/subsys/$SERVICE_NAME"
 
RETVAL=0
 
start() {
        OLDPID=`ps -e -o pid,command:1000 | grep "$PROCESS_STRING" | grep -v " grep " | awk '{print $1}'`
        if [ ! -z "$OLDPID" ]; then
            echo "$SERVICE_NAME is already running (pid $OLDPID) !"
            echo
            exit
        fi
        
        if [ ! -e "$NODEMANAGER_DIR" ]; then
            echo "$NODEMANAGER_DIR does not exist. The per host Node Manager is not configured correctly."
            echo "Please follow steps in Pre-Condition section before using this script."
            echo
            exit
        fi
        
        echo -n $"Starting $SERVICE_NAME ... "
        echo "`date` Starting $SERVICE_NAME ... " > $OUT_FILE 2>&1 
        export MW_HOME
export JAVA_HOME
export LD_LIBRARY_PATH
  $PROGRAM_START >> $OUT_FILE 2>&1  &
 
        RETVAL=$?
        if [ $RETVAL -eq 0 ] ; then
          wait_for "socket listener started on port"
        else
          echo "FAILED: $RETVAL. Please check $OUT_FILE for more information."
        fi
        echo
}
 
wait_for() {
    res=$(cat "$OUT_FILE" | fgrep -c "$1")
    count=60
    while [[ ! $res -gt 0 ]] && [[ $count -gt 0 ]]
    do
        sleep 1
        count=$(($count - 1))
        res=$(cat "$OUT_FILE" | fgrep -c "$1")
    done
    res=$(cat "$OUT_FILE" | fgrep -c "$1")
    if [ ! $res -gt 0 ]; then
        echo "FAILED or took too long time to start. Please check $OUT_FILE for more information."
    else
        echo "OK"
        touch $LOCKFILE
    fi
}
 
stop() {
        echo -n $"Stopping $SERVICE_NAME ... "
        OLDPID=`ps -e -o pid,command:1000 | grep "$PROCESS_STRING" | grep -v " grep " | awk '{print $1}'`
        if [ "$OLDPID" != "" ]; then
            echo -n "(pid $OLDPID) "
            /bin/kill -TERM $OLDPID
 
            RETVAL=$?
            echo "OK"
            /bin/rm -f $NODEMANAGER_LOCKFILE
            [ $RETVAL -eq 0 ] && rm -f $LOCKFILE
        else
            /bin/echo "$SERVICE_NAME is stopped"
        fi
        echo
}
 
restart() {
        stop
        sleep 10
        start
}
 
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart|force-reload|reload)
        restart
        ;;
  condrestart|try-restart)
        [ -f $LOCKFILE ] && restart
        ;;
  status)
        OLDPID=`ps -e -o pid,command:1000 | grep "$PROCESS_STRING" |grep -v " grep " | awk '{print $1}'`
        if [ "$OLDPID" != "" ]; then
            /bin/echo "$SERVICE_NAME is running (pid: $OLDPID)"
        else
            /bin/echo "$SERVICE_NAME is stopped"
        fi
        echo
        RETVAL=$?
        ;;
  *)
        echo $"Usage: $0 {start|stop|status|restart|reload|force-reload|condrestart}"
        exit 1
esac
 
exit $RETVAL

Enabling FIPS 140-2 Mode From java.security

Learn how to enable FIPS 140-2 mode in Oracle WebLogic Server using Node Manager.

The Federal Information Processing Standards (FIPS) 140-2 is a standard that describes U.S. Federal government requirements for sensitive but unclassified use. WebLogic Server supports the use of the RSA FIPS-compliant (FIPS 140-2) crypto module.

See Enabling FIPS Mode in Administering Security for Oracle WebLogic Server for more information.

You can enable FIPS 140-2 mode from the installed JDK java.security file.

Using the following URL, download and install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files that correspond to the version of your JDK. These Java policy JAR files affect cipher key sizes greater than 128 bits.
```
https://www.oracle.com/java/technologies/javase-jce-all-downloads.html
```
Open the .ZIP distribution and update local_policy.jar and US_export_policy.jar in JAVA_HOME/jre/lib/security. See the README.txt file in the .ZIP distribution for more information and installation instructions.

Note:
You can skip this step if you are running WebLogic Server on JDK 8u161 or later. On JDK 8u161 and later, stronger cryptographic algorithms are available by default.
Edit the java.security file. Add both the RSA JCE provider and the RSA JSSE provider as the first two Java security providers listed in the java.security properties file:
```
#
security.provider.1=com.rsa.jsafe.provider.JsafeJCE
security.provider.2=com.rsa.jsse.JsseProvider
 
security.provider.3=sun.security.provider.Sun
:
```
Put the jcmFIPS.jar and sslj.jar JAR files (both are in WL_HOME/server/lib/) at the head of the classpath for Node Manager. You can use the PRE_CLASSPATH environment variable to do this.
(The RSA JCE provider Crypto-J is located in cryptoj.jar and is in the classpath by default.)

For example, you can set jcmFIPS.jar and sslj.jar in the PRE_CLASSPATH variable within the startNodeManager.sh file immediately after WL_HOME is set:
```
if [ "${PRE_CLASSPATH}" != "" ] ; then
        PRE_CLASSPATH="${WL_HOME}/server/lib/sslj.jar;${WL_HOME}/server/lib/jcmFIPS.jar:${PRE_CLASSPATH}"
        export PRE_CLASSPATH
else
        PRE_CLASSPATH="${WL_HOME}/server/lib/sslj.jar;${WL_HOME}/server/lib/jcmFIPS.jar"
        export PRE_CLASSPATH
fi
```
Start WebLogic Server.