Oracle WebLogic Server 12c: Administration I - 1Z0-133 - Part - 2

Node Manager

Oracle WebLogic Server Node Manager is an optional but recommended WebLogic Server utility.

Any domain configuration that defines at least one managed server will benefit from configuring and using Node Manager to control server start and shutdown, including automatic restart.

 common operations performed by Node Manager.

Oracle WebLogic Server Node Manager comes in two versions, 

1)  one Java-based 

2)  one script-based.

Both serve the same purposes but the Java-based version is, by far, the one used most commonly.  It is actually the default version in WebLogic Server 12c and has had its configuration significantly simplified.

Some of the recommended practices to managing Node Manager in previous WebLogic Server 

versions have now become the default practices, including the scope in which Node Manager is used.

A new screen is part of the WebLogic Server 12c configuration wizard that requires selecting the node manager type and credentials^[1]

------>  If administrators select per-domain Node Manager, as opposed to choosing manual setup, the wizard will create a default configuration that is ready for immediate use.

----->  This configuration is complete with security credentials, configuration properties, domain association and control scripts already in the right place, all of which and more was commonly manually performed by administrators of previous product versions

As indicated previously, the default Node Manager version is implemented in Java and runs as a JVM process just like servers do, although it is by default configured to have a much smaller foot print on the system. The main configuration of the Java Node Manager is kept in a properties file. It supports one-way SSL to secure its communications with other domain components.

The script-based Node Manager is implemented in UNIX/Linux shell scripts and depends on SSH for security and communications. This makes the Java-based Node Manager the only alternative in Windows environments.

Node Manager Interactions

Once configured, Node Manager can be used to start and control any of the servers in the same WebLogic machine in which it resides, including the Administration Server.

Node Manager will then also be able to receive requests from the Administration Server to perform control commands on the managed servers.

These requests may have originated in the Administration Console or come from other JMX clients.

The following interactions are displayed in the diagram:

1. An administrator connects to Node Manager using WebLogic Scripting Tool.
2. Node Manager may directly start, stop, and restart any WebLogic server instances in the same machine.
3. The Administration Server will contact Node Manager with control requests to be performed on managed servers.
4. The Administration Server will contact managed server instances directly, in order to perform graceful shutdown operations^[2].
5. The Administration Console can be used to request control operations on managed servers.
6. Custom JMX clients can connect to the Administration Server in order to request control operations on managed servers.

 Manual Node Manager configuration

---

cd ORACLE_HOME/oracle_common/common/bin
./wlst.sh

readDomain("/opt/oracle/domains/sample")[]
cd("/")
cd("NMProperties")
set("ListenAddress", "127.0.0.1")[]
set("ListenPort", 7001)
cd("/")
cd("SecurityConfiguration/sample")
set("NodeManagerUsername", "nodemanager")
set("NodeManagerPasswordEncrypted", "newPassw0rd")[]
setOption("NodeManagerType", "PerDomainNodeManager")
updateDomain()

-------------------------------------------------------------------

Structure and Properties

Oracle WebLogic Server Node Manager maintains its configuration in several files. It will also depend on several files created for each server instance it will control. Similarly, the Node Manager process will write in a dedicated log file and will also keep a log file for each server instance.

Configuration Files

Node Manager maintains the following configuration files:


nodemanager.properties – This is the main Node Manager configuration file


nm_password.properties – This file contains the encrypted node manager credentials


nodemanager.domains – This file contains the names and locations of the associated domains


nodemanager.process.id – This file contains Node Manager OS process ID


nodemanager.process.lck – This file represents an internal Node Manager lock



Node Manager will create or otherwise use the following files for each server instance:


boot.properties – This file contains user credentials used by Node Manager to start this server


startup.properties – This file maintains the server startup properties last passed to Node Manager by the Administration Server[]


SERVER_NAME.lck – This file contains an internal Node Manager lock ID


SERVER_NAME.pid – This file contains the corresponding server instance OS process ID


SERVER_NAME.state – This file contains a string describing the internal server state



Log Files

Node Manager maintains the following log files:


nodemanager.log – This file contains entries for events and operations made on server instances of the associated domains, such as when a server is started, stopped, or shut down. It also includes entries for other node manager events, such as when Node Manager detects that a server has failed.


SERVER_NAME.out – This file is created by Node Manager when it starts a server instance. It contains entries for both standard out and standard error messages.



The contents of these files are also accessible using the Administration Console or the WLST nmLog and nmServerLog commands. The default operation is for Node Manager to append to these files although configuring rotation is possible. Server instances create and maintain their own log files, in addition to those created by Node Manager.



Properties

As indicated before, the properties that control how Node Manager performs its work are found in the nodemanager.properties file. 



These properties may also be overridden at the command line when creating the Node Manager process. 



A listing of the core properties and an explanation of their purpose follow:


ListenAddress – DNS name or IP address on which the Node Manager process will listen for requests, default value: localhost


ListenPort – Port number on which the Node Manager process will listen for requests, default value: 5556


LogFile – Location and name of the file where the Node Manager process will write its messages, default value: DOMAIN_HOME/nodemanager/nodemanager.log


LogLimit – Maximum size of the log file when using log rotation, default value: 0


LogCount – Maximum number of log files to keep when using log rotation, default value: 1


LogAppend – Whether to append to an existing log file when the Node Manager process starts, default value: true


LogLevel – Verbosity of the messages written by log manager, default value: INFO


CrashRecoveryEnabled – Whether or not attempt to restart a failed server instance, default value: false


StartScriptEnabled – Whether to use a specific script to start server instances, default value: true


StartScriptName – Name of the script that will be used to start server instances, default value: startWebLogic.sh


StopScriptEnabled – Whether to use a specific script to stop server instances, default value: false


DomainsFile – Location and name of the file that contains the associated domain names and locations


DomainRegistrationEnabled – Whether to accept dynamic domain associations from node manager clients, default value: false


AuthenticationEnabled – Whether to authenticate clients against the domain, default value: true


NativeVersionEnabled – Whether to use native libraries in the Node Manager process, default value: true[]


StateCheckInterval – The length of time that Node Manager will wait to check the state of server instances it started, default value: 500 (milliseconds)


NodeManagerHome – Location and name of the directory where the configuration and log files are stored


JavaHome – Location and name of the directory where the JDK is installed


SecureListener – Whether to use SSL/TLS on the network channel, default value: true


Keystores – Indicates the type of keystore configuration that Node Manager will use, available values are the same of a server instance:




DemoIdentityAndDemoTrust, 



 



CustomIdentityAndJavaStandardTrust, 



CustomIdentityAndCustomTrust


JavaStandardTrustKeyStorePassPhrase – The password required, if any, by the underlying Java trust keystore. Required when the SSL keystores configuration is set to CustomIdentityAndJavaStandardTrust


CustomIdentityKeyStoreFileName – Location and file name of the Node Manager identity certificate that contains its private key. Required when the SSL keystores configuration is set to CustomIdentityAndJavaStandardTrust or CustomIdentityAndCustomTrust


CustomIdentityKeyStorePassPhrase – Password to the keystore that contains the identity certificate private key. Required when the SSL keystores configuration is set to CustomIdentityAndJavaStandardTrust or CustomIdentityAndCustomTrust


CustomIdentityPrivateKeyPassPhrase – Password to access the private key from the identity certificate. Required when the SSL keystores configuration is set to CustomIdentityAndJavaStandardTrust or CustomIdentityAndCustomTrust


CustomIdentityAlias – String used to refer to the private key in the identity keystore, defined when the private key was first loaded into the keystore

SSL Configuration

The automatic configuration installs and configures SSL demo certificates to encrypt Node Manager traffic. 

In general terms, SSL uses public key encryption, which requires a key pair, a private key, and a public key.    Data encrypted using the public key can only be decrypted using the private key.  In this scenario, a key pair must be generated and configured for Node Manager. 




The public key contains information about the owner, such as its DNS name or IP address in the CN field. The public key is embedded in a digital certificate, and the private key along with the digital certificate comprise the server identity. The data embedded in the digital certificate is verified and signed by a certification authority that is commonly well known and trusted. Anyone who trusts the certificate authority will also trust the digital identity of Node Manager.

As indicated before, Node Manager is configured with one-way SSL, meaning that Node Manager will present its digital certificate to clients, but clients will not be required to present their digital identity in a certificate. 




The Node Manager digital identity will be used to encrypt Node Manager traffic. At this point, it should be fairly obvious that maintaining the demonstration SSL certificates configured by default should be replaced with a custom digital identity for Node Manager.

Obtaining digital certificates in established corporations is usually as simple as requesting them from the group that is in charge of generating them. When this is not available, it is also possible to generate the digital identity certificates and also sign them. 



In terms of the technologies involved, this can be just as secure as having a well-known and trusted certificate authority sign them, but the certificates thus signed will not be trusted by anyone. 



For training purposes, this should be enough. also can learn and configure  the details of creating a CA, generating the digital identity, and signing it, but we will assume that the digital certificate is already available. 



In order to replace the demonstration certificate with a custom identity certificate, the following steps should be followed:


Set the Keystores property to one of the custom options: CustomIdentityAndJavaStandardTrust or CustomIdentityAndCustomTrust.


Set the values of the CustomIdentityKeyStoreFileName and CustomIdentityKeyStorePassPhrase properties to the name and location of the keystore that contains the private key as well as its corresponding password.


Set the value of the CustomIdentityPrivateKeyPassPhrase and CustomIdentityAlias properties to the password to the private key and the alias name which was used when populating the keystore with the private key.



Choosing Java standard trust over custom trust essentially means that we will use the trust keystore that was provided as part of the Java SDK that we are using. This keystore has been populated with the identity certificates of many well-known certificate authorities. It is however not very relevant to the Node Manager SSL configuration as we do not need to use these certificates to authenticate and trust client certificates.

If we choose to customize trust as well, we will need to provide a keystore location and file name that must be populated with the identity certificates of the certificate authorities whose signed certificates we choose to trust.

If we choose to use the Java standard trust, we must set the corresponding password in the JavaStandardTrustKeystorePassPhrase property. The well-known password of the cacertskeystore is, not surprisingly: changeit.


These properties correspond to the server startup attributes found in the ServerStartMBean managed bean.



It is strongly advisable to maintain the value of NativeVersionEnabled set to true as changing it will limit the ability of Node Manager to recognize the status of a server instance process and to recover crashed instances.




The Java standard trust keystore of the Oracle JDK 1.7.0+ is located at JAVA_HOME/jre/lib/security/cacerts.

NODE MANAGER OPERATIONS

Start the Administration Server

---

cd DOMAIN_HOME/bin
./startNodeManager.sh &

cd ORACLE_HOME/oracle_common/common/bin
./wlst.sh

nmConnect("nodemanager", "newPassw0rd", "127.0.0.1", "5556", "sample", "/
opt/oracle/domains/sample", "ssl")
nmStart("AdminServer")

Start Managed Servers

Once the Administration Server has started, it is a trivial step to start the managed servers configured to run on the same WebLogic Server machine as the command is the same that was used to start the Administration Server, just passing the name of a managed server instead. Before creating a managed server instance, Node Manager will obtain the corresponding startup properties from the Administration server.

Managed servers will be started using the same root directory as Node Manager. When no root directory is explicitly specified, the domain root directory is used by default in a path such as: DOMAIN_HOME/servers/SERVER_NAME.

Automatic JVM Restart

Node Manager is able to restart crashed server instances as long as both of the following conditions are met:

1. They must have been started using Node Manager
2. The CrashRecoveryEnabled property in Node Manager or the AutoRestart attribute in the server instance are enabled

The need to restart a server instance is determined by checking the JVM process exit code or its last known state, both of which are tracked by Node Manager. Managed server instances contact the Administration server to obtain a copy of the latest domain configuration. If the managed server is unable to contact the Administration server for this purpose, it will start in Managed Server Independence mode if enabled in the domain, which as the name suggests, will cause the server to continue operating independently of the Administration server, using the last copy it received of the domain configuration.

Crash Recovery

Crash recovery is different from automatic JVM restart in that the Node Manager process will attempt certain recovery actions immediately upon starting, including:

1. Check for any lock files created
2. If lock files exist but a process with the corresponding ID does not, Node Manager will attempt to restart the required server instances
3. If the process ID exists, Node Manager will attempt to verify if it belongs to a WebLogic Server JVM by attempting to access an internal management servlet that is available in each server instance; if it is not able to, Node Manager will attempt to restart the required server instance

The StartScriptEnabled and NativeVersionEnabled properties of the Java-based Node Manager are not supported on Microsoft Windows.

Recommended Exercises

1. Run the Domain Configuration Wizard and select the manual node manager setup option, then configure Node Manager manually using WLST.
2. Configure Node Manager timed log rotation with a short duration and verify that new log files are created.
3. Configure Node Manager on a non-default listen address and port.
4. Enable server restart in the Node Manager configuration and kill a managed server instance to force Node Manager to restart the JVM.
5. Customize the Node Manager SSL configuration using custom identity certificates.
6. Create init scripts to configure Node Manager to run as a service on UNIX/Linux.

CERTIFICATION QUESTIONS

5. 

what is the WLST command to configure Node Manager on multiple WebLogic Server machines?

1. configure()
2. createConfig()
3. nmAuthorize()
4. nmEnroll()

Answer   :  d  -  nmEnroll()