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 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, 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 WebLogic Server 12.1.1 or earlier to the current version or when upgrading from WebLogic Server 12.1.2 or greater to the current version, see Determining Node Manager Upgrade Procedure in Upgrading Oracle WebLogic Server.
For each 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 WebLogic Server domain.
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. 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:
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.
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 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:
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.
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 about 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 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.
See Accessing Node Manager and nmEnroll in WLST Command Reference for WebLogic Server.
The WebLogic Scripting Tool (WLST) is a command-line scripting interface that system administrators and operators use to monitor and manage 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 WebLogic Server.
You can use WLST offline to configure Node Manager by performing the tasks such as setting the Node Manager user name and password, setting Node Manager properties, and 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')
See setOption in WLST Command Reference for WebLogic Server.
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 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 domain_name > Security > General > Advanced Options page in the WebLogic Server Administration Console.
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:
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, in order 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:
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.
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.
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.
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 4-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.
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.
Make sure 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 Servers > Configuration > General page in the WebLogic Server Administration Console.
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.
Both the start and stop scripts should be placed in the following directory:
DOMAIN_HOME\bin
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:
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.
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:
nodemanager.properties file, set the weblogic.StopScriptEnabled property to true.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
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 only execute commands 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 only accessible 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 4-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
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.
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 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 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 4-1 describes Node Manager properties.
Table 4-1 Node Manager Properties
| Node Manager Property | Description | Default |
|---|---|---|
|
|
If set to |
true |
|
|
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 name of the cipher suite to use with the SSL listener. This property is deprecated in WebLogic Server 12.1.3.0 but remains fully supported in WebLogic Server 12.2.1. See |
The default value is JDK and platform dependent. |
|
|
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:
This property introduced in WebLogic Server 12.1.3 is not currently supported by WLST offline or by the |
The default value is JDK and platform dependent. |
|
|
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 WebLogic Server 12.1.3.0 but remains fully supported in WebLogic Server 12.2.1. See |
true |
|
|
Specifies the start script name or path used to start standalone Coherence servers when This property is deprecated in WebLogic Server 12.1.3.0 but remains fully supported in WebLogic Server 12.2.1. See |
none |
|
|
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 WebLogic Server 12.1.3 is not currently supported by WLST offline or by the |
true |
|
|
Specifies the start script name or path used to start standalone Coherence servers when This property introduced in WebLogic Server 12.1.3 is not currently supported by WLST offline or by the |
none |
|
|
Applies when This property introduced in WebLogic Server 12.1.3 is not currently supported by WLST offline or by the |
none |
|
|
Enables system crash recovery. Note: The |
false |
|
|
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 |
|
|
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 |
|
|
The name of the |
NodeManagerHome\nodemanager.domains |
|
|
If set to |
true |
|
|
This property is deprecated in WebLogic Server 12.1.3.0 and may be removed in a future release. To register multiple domain locations in the |
false |
|
|
This configuration property sets a different directory for the location of the This property is deprecated in WebLogic Server 12.1.3.0 but remains fully supported in WebLogic Server 12.2.1. See |
By default, this location is set appropriately, but you can use this property to modify the script location. |
|
|
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 This property is deprecated in WebLogic Server 12.1.3.0 but remains fully supported in WebLogic Server 12.2.1. See |
|
|
|
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. |
|
|
|
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 This property is deprecated in WebLogic Server 12.1.3.0 but remains fully supported in WebLogic Server 12.2.1. For more information and current support limitations for the replacement properties, see |
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
The TCP port number on which Node Manager listens for connection requests. This argument deprecates |
5556 |
|
|
If set to |
true |
|
|
Maximum number of log files to create when |
1 |
|
|
Location of the Node Manager log file. |
NodeManagerHome\nodemanager.log |
|
|
Name of formatter class to use for NM log messages. |
weblogic.nodemanager.server.LogFormatter |
|
|
Severity level of logging used for the Node Manager log. Node Manager uses the standard logging levels from the |
INFO |
|
|
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 |
|
|
If set to |
false |
|
|
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 |
|
|
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 This property is deprecated in WebLogic Server 12.1.3.0 but remains fully supported in WebLogic Server 12.2.1. See |
|
|
|
Node Manager root directory which contains the following configuration and log files:
See Node Manager Configuration and Log Files. Note: By default, Note: Oracle recommends not setting this property with the WLST |
NodeManagerHome |
|
|
Specifies the version of the |
none |
|
|
Specifies the time a NodeManager waits to check if the Managed Server that was started by the start script is stopped. If If the child process does not stop within the specified timeout value:
This property was introduced in WebLogic Server 12.1.2 and backported to 10.3.6.x. |
|
|
|
If set to WLST overrides the default value, |
false |
|
|
If set to |
true |
|
|
If true, use the start script specified by This property is deprecated in WebLogic Server 12.1.3.0 but remains fully supported in WebLogic Server 12.2.1. See |
true |
|
|
The name or path of the start script, located in the domain directory. This property is deprecated in WebLogic Server 12.1.3.0 but remains fully supported in WebLogic Server 12.2.1. See |
startWebLogic.sh (UNIX) or startWebLogic.cmd (Windows) |
|
|
Specifies the interval Node Manager waits to perform a check of the server state. |
500 milliseconds |
|
|
If This property is deprecated in WebLogic Server 12.1.3.0 but remains fully supported in WebLogic Server 12.2.1. See |
false |
|
|
The name of the script to be executed after server shutdown. This property is deprecated in WebLogic Server 12.1.3.0 but remains fully supported in WebLogic Server 12.2.1. See |
none |
|
|
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 This property is deprecated in WebLogic Server 12.1.3.0 but remains fully supported in WebLogic Server 12.2.1. See |
|
|
|
Root directory of the WebLogic Server installation. This is used as the default value of |
none |
|
|
This configuration property sets a different directory for the location of the This property introduced in WebLogic Server 12.1.3 is not currently supported by WLST offline or by the |
By default, this location is set appropriately, but you can use this property to modify the script location. |
|
|
If true, use the start script specified by This property introduced in WebLogic Server 12.1.3 is not currently supported by WLST offline or by the |
true |
|
|
The name or path of the start script, located in the domain directory. This property introduced in WebLogic Server 12.1.3 is not currently supported by WLST offline or by the |
startWebLogic.sh (UNIX) or startWebLogic.cmd (Windows) |
|
|
Applies when This property introduced in WebLogic Server 12.1.3 is not currently supported by WLST offline or by the |
none |
|
|
If This property introduced in WebLogic Server 12.1.3 is not currently supported by WLST offline or by the |
false |
|
|
The name of the script to be executed after server shutdown. This property introduced in WebLogic Server 12.1.3 is not currently supported by WLST offline or by the |
none |
|
|
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 This property introduced in WebLogic Server 12.1.3 is not currently supported by WLST offline or by the |
|
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 4-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 4-2 Machine-Level Node Manager Properties for a Group of Server Instances
| Property Name | Description |
|---|---|
|
|
The Java arguments to use when starting the server instance. These are the first arguments appended immediately after Separate arguments with a space. |
|
|
The Specifies the directory on the Node Manager machine under which all Oracle Middleware products are installed. For example, |
|
|
The Java arguments to use when starting the server instance. Node Manager passes this value to a start script using the |
|
|
Prepends flags to any arguments configured for the server instances. |
|
|
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 |
|
|
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 |
|
|
The Node Manager does not pass this value to start scripts. When issuing a Java command line to start the server instance, Node Manager specifies |
|
|
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, |
|
|
The group ID for the server instance. |
|
|
The user ID for the server instance. |
In the WebLogic Server Administration Console or FMWC, on the Server > Configuration > Server Start page for the Managed Server, specify the startup arguments that Node Manager will use to start a Managed Server. 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 will 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 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.
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.
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.
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.
The following server startup properties can be passed to a server instance when started using Node Manager.
Table 4-3 Server Startup Properties
| Property | Description |
|---|---|
|
|
The URL of the Administration Server. Note: This value should only be specified in the |
|
|
The arguments used when starting the server instance. |
|
|
When a server instance is started by Node Manager, this attribute signals that the |
|
|
Specifies whether Node Manager can automatically restart this server instance if it fails. Note: The |
|
|
The classpath to use when starting a server instance. |
|
|
Defines the Java home directory used when starting the server instance. |
|
|
The Oracle home directory to use when starting a server instance. |
|
|
The number of seconds Node Manager should wait before attempting to restart the server instance. |
|
|
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 |
|
|
The number of times Node Manager will attempt to restart a failed server within the interval defined by |
|
|
Specifies the security policy file to use when starting this server. |
|
|
The IP address of the server. |
|
|
These arguments are used when you have enabled the domain-wide administration port. |
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 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 4-4 Node Manager Environment Variables
| Environment Variable | Description |
|---|---|
CLASSPATH |
You can set the Node Manager 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 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 |
PATH |
Must include the WebLogic Server bin directory and path to your Java executable. For example: set PATH=%WL_HOME%\server\bin;%JAVA_HOME%\bin;%PATH% |
WL_HOME |
WebLogic Server installation directory. For example: set WL_HOME=c:\Oracle\Middleware\Oracle_Home\wlserver |
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:
#
# 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
}You can configure Node Manager as an init.d service using init startup scripts. This section includes the following topics:
init.d service, complete the following steps. Execute all actions as the root user.
Note:
When Node Manager runs as aninit.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 Domain > Environment > Machines > Configuration > General page. Then, restart Node Manager and the Administration Server before restarting the Managed Servers.Example 4-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 $RETVALTo 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.
Example 4-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