3 Configuring Java 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:
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, underORACLE_HOME
\oracle_common\common\nodemanager
, the per hostNodeManagerHome
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
andCLASSPATH
variables, from a command prompt runWL_HOME
\server\bin\setWLSEnv.cmd
.Note:
On UNIX operating systems, thesetWLSEnv.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 theNodeManagerHome
\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 toSecureListener=false
in thenodemanager.properties
file. To review the SSL-related properties innodemanager.properties
, see Table 3-1. - To properly set up the
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.
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 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:
Note:
If you editnm_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 thestartup.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.
- Start the Administration Server with the following
setting:
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:
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 theweblogic.StopScriptEnabled
property totrue
. - Set the
weblogic.StopScriptName
property to the name of your script in thenodemanager.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 thenodemanager.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 (\) innodemanager.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 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
andNativeVersionEnabled
properties. - If Node Manager runs on a multihomed system, and you want to control which address
and port it uses, define
ListenAddress
andListenPort
.
Table 3-1 describes Node Manager properties.
Table 3-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 Oracle 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 Oracle WebLogic Server 12.1.3.0 but remains fully
supported in Oracle WebLogic Server 12.2.1.4.0. 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 Oracle 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 Oracle WebLogic Server 12.1.3.0 but remains fully
supported in Oracle WebLogic Server 12.2.1.4.0. See
|
true |
|
Specifies the start script name or path used to start standalone Coherence servers when This property is deprecated in Oracle WebLogic Server 12.1.3.0 but remains fully
supported in Oracle WebLogic Server 12.2.1.4.0. 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 Oracle 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 Oracle WebLogic Server 12.1.3 is not currently supported
by WLST offline or by the |
none |
|
Applies when This property introduced in Oracle 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 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 |
|
Specifies the type of the Identity keystore. Generally, this is JKS. This property is optional. |
The default keystore type from |
|
Specifies the password used to retrieve the private key for Oracle 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 Oracle 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 Oracle WebLogic Server 12.1.3.0 but remains fully
supported in Oracle WebLogic Server 12.2.1.4.0. 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 Oracle WebLogic Server 12.1.3.0 but remains fully
supported in Oracle WebLogic Server 12.2.1.4.0. 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 Oracle WebLogic Server 12.1.3.0 but remains fully
supported in Oracle WebLogic Server 12.2.1.4.0. For more information and current support
limitations for the replacement properties, see
|
|
|
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
|
|
|
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. |
|
|
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. |
|
|
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 the formatter class to use for Node Manager 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 Oracle WebLogic Server 12.1.3.0 but remains fully
supported in Oracle WebLogic Server 12.2.1.4.0. See |
|
|
Node Manager root directory which contains the following configuration and log files:
See Node Manager Configuration and Log Files. Note:
|
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 Oracle 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 Oracle WebLogic Server 12.1.3.0 but remains fully
supported in Oracle WebLogic Server 12.2.1.4.0. See
|
true |
|
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 12.2.1.4.0. 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 Oracle WebLogic Server 12.1.3.0 but remains fully
supported in Oracle WebLogic Server 12.2.1.4.0. See
|
false |
|
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 12.2.1.4.0. 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 Oracle WebLogic Server 12.1.3.0 but remains fully
supported in Oracle WebLogic Server 12.2.1.4.0. See |
|
|
Root directory of the Oracle 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 Oracle 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 Oracle 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 Oracle 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 Oracle WebLogic Server 12.1.3 is not currently supported
by WLST offline or by the |
none |
|
If This property introduced in Oracle 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 Oracle 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 Oracle WebLogic Server 12.1.3 is not currently supported
by WLST offline or by the |
|
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 |
---|---|
|
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. |
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 |
---|---|
|
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. |
Set 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 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 theLISTEN_PORT
variable to<
port
>
before calling thestartNodeManager
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 toLISTEN_ADDRESS
andLISTEN_PORT
when entered on the command line.For example, enter this command to start Node Manager on host
llama
and port7777
: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 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:
|
WL_HOME |
WebLogic Server installation directory. For example:
|
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 withlibwrap
, you should add theNOLIBWRAP
flag. - Ensure that the
hosts.deny
andhosts.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
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 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.
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.
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.
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.