+

Search Tips   |   Advanced Search

addNode command

The addNode command incorporates an application server installation into a cell.

Depending on the size and location of the new node you incorporate into the cell, this command can take a few minutes to complete.

We must have Administrator privileges to use the addNode function.

The node agent server is automatically started as part of the addNode command unless it is specified with the -noagent option. If we restart the system hosting an application server node, and did not set up the node agent to act as an operating system daemon, issue a startNode command to start the node agent before starting any application servers.

addNode stops the running application server that it is incorporating into a cell. We can optionally stop the application server before running the addNode command.

Existing Windows services associated with servers before adding a node to a cell are removed. If we remove the node from the cell later, Windows services are not automatically created again for the base servers.

When we add a node, the product might generate ports. The following items apply to port generation:

Best practice: Use the -includeapps option for the addNode command to ensure that the environment starts with the same version of the application. If any custom policy set is created on the server before running the addNode command, then the custom policy set is not copied to the new cell after you run the addNode command. Therefore, when using the -installApps option, an application on the server that uses the custom policy set fails to load the policy set after you run the addNode command. We can export the custom policy set from the stand-alone server before running the addNode command, and import the custom policy set to the new cell after you run the addNode command.bprac

Read the topic on using command-line tools to determine whether to run the command from the profile or application server root directory.


Syntax

addNode dmgr_host \
        [dmgr_port] \
        [-conntype type] \
        [-includeapps] \
        [-includebuses]
        [-startingport portnumber] \
        [-portprops qualified_filename] \
        [-nodeagentshortname name] \
        [-nodegroupname name] \
        [-registerservice] \
        [-serviceusername name] \
        [-servicepassword password] \
        [-coregroupname name] \
        [-noagent] \
        [-statusport 1231] \
        [-quiet] \
        [-nowait] \
        [-logfile filename] \
        [-replacelog] \
        [-trace] \
        [-username uid] \
        [-password pwd]
        [-localusername localuid] \
        [-localpassword localpwd] \
        [-profileName profilename] \
        [-excludesecuritydomains true | false] \
        [-asExistingNode] \
        [-help]

The dmgr_host argument is required. All the other arguments are optional. The default port number is 8879 for the default SOAP port of the deployment manager. SOAP is the default JMX connector type for the command. If we have multiple product installations or multiple profiles, the SOAP port might be different from 8879. Examine the deployment manager SystemOut.log file to see the current ports in use.


Parameters

The following options are available for the addNode command:


Usage scenario

The following examples demonstrate correct syntax:

 addNode testhost 8879           (add an application server to the deployment manager)
 addNode deploymgr 8879 -trace   (produce the addNode.log file)
 addNode host25 8879 -nowait     (does not wait for a node agent process)

The value 8879 is the default port.

(iseries) Add profile, mynode, to the cell managed by profile mydmgr, which listens on SOAP port 11383.


Security considerations when adding an application server node to WAS ND cell

When adding a node to the cell, you automatically inherit both the user registry and the authentication mechanism of the cell.

For distributed security, all servers in the cell must use the same user registry and authentication mechanism. To recover from a user registry change, modify the applications so that the user and group-to-role mappings are correct for the new user registry.

Another important consideration is the SSL public-key infrastructure. Before running addNode with the deployment manager, verify that the addNode command can communicate as an SSL client with the deployment manager. This communication requires that the addNode truststore configured in the sas.client.props file contains the signer certificate of the deployment manager personal certificate, as found in the keystore and specified in the console. The following issues require consideration when running the addNode command with security:


Subtopics


Related concepts

Secure installation for client signer retrieval in SSL
  • Use command-line tools
  • Adding, managing, and removing nodes
  • Recovering or moving nodes with the addNode -asExistingNode command
  • Mapping modules to servers
  • Assigning users and groups to roles
  • Use High Performance Extensible Logging to troubleshoot applications
  • addNode command best practices
  • removeNode command
  • cleanupNode command