WebSphere Application Server Network Deployment, Version 6.0.x     Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

wasprofile command

The wasprofile command line tool creates all Application Server run-time environments in Version 6. The command creates a profile, which is the set of files that define the run-time environment for a deployment manager, a custom profile, or a stand-alone application server.

The wasprofile command is also referred to as the profile creation tool.




Related information
Using command line tools

Introduction to terms that describe Version 6 profiles

The wasprofile command creates the run-time environment for a WebSphere Application Server process in a set of files called a profile. The profile defines the run-time environment and includes all of the files that the server processes in the run-time environment can change.

The profile creation tool and its graphical user interface, the Profile creation wizard, are the only ways to create run-time environments in V6.

The Profile creation wizard is an InstallShield for Multiplatforms (ISMP) application. You can use the wizard to enter most of the parameters that are described in this topic. Some parameters, however, require you to use the wasprofile command. You must use the wasprofile command to delete a profile, for instance, because the Profile creation wizard does not provide a deletion function.

However, the Profile creation wizard also performs tasks that the wasprofile command does not. For instance, the wizard can create a Windows service for each profile that it creates. It can also assign non-conflicting ports based on previous Version 6 port assignments.

Core product files

The core product files are the shared product binaries, which are shared by all profiles.

The directory structure for V6 has two major divisions of files in the installation root directory for the product:
  • The core product files are shared product binary files in the product installation root directory, which is referred to throughout the information center as the app_server_root directory. The files in the app_server_root directory do not change unless you install a refresh pack, a fix pack, or an interim fix. Some log information is also updated.
  • The profile_root directory is the default directory for creating profiles.

The configuration for every defined Application Server process is within the profiles directory unless you specify a new directory when you create a profile. These files change as often as you create a new profile, reconfigure an existing profile, or delete a profile.

All of the folders except for the profiles directory and a few others such as the logs directory and the properties directory do not change unless you install service fixes. The profiles directory, however, changes each time you add, change, or delete a profile. The profiles directory is the default repository for profiles. However, you can put a profile anywhere on the machine or system provided there is enough available disk space.

If you put a profile in another existing folder in the installation root directory, a risk exists that the profile might be affected by the installation of a service fix that applies maintenance to the folder. Use a directory outside of the installation root directory when using a directory other than the profiles directory for creating profiles.

WebSphere Application Server profile

The wasprofile command line tool defines each application server profile in a Version 6 product.

Run the wizard or the command line tool each time that you want to create an application server. A need for more than one stand-alone application server on a machine is common.

Administration is greatly enhanced when using V6 profiles instead of multiple product installs. Not only is disk space saved, but updating the product is simplified when you only maintain a single set of product core files. Also, creating new profiles is faster and less prone to error than full product installs, allowing a developer to create separate profiles of the product for development and testing.

You can run the Profile creation wizard or the profile creation tool to create a new Application Server environment on the same machine as an existing one. Simply define unique characteristics (such as profile name and node name) for the new profile. Each profile has its own administrative console and administrative scripting interface. Each Application Server process shares all run-time scripts, libraries, the Software Development Kit, and other core product files.

Profile types

Templates for each profile are located in the app_server_root/profileTemplates directory.

Within this directory are various directories that correspond to different profile types and that vary with the type of product installed. The directories are the paths that you indicate while using the wasprofile command with the -templatePath option. You can also specify profile templates that lie outside the installation root, if you happen to have any.

See the -templatePath description in the Parameters section for more information.

The wasprofile command in the Network Deployment product can create the following types of profiles:
Deployment manager profile
The basic function of the deployment manager is to deploy applications to a cell of Application Servers, which it manages. Each Application Server that belongs to the cell is referred to as a managed node.

Specify dmgr or app_server_root/profileTemplates/dmgr for the -templatePath parameter to create this type of profile.

Application Server profile
The basic function of the Application Server is to serve applications to the Internet or to an intranet.

An important product feature for the Network Deployment product is the ability to scale up a stand-alone application server profile by adding the Application Server node into a deployment manager cell. Multiple Application Server processes in a cell can deploy an application that is in demand. You can also remove an Application Server node from a cell to return the node to the status of a stand-alone application server.

Each stand-alone application server has its own administrative console application, which you use to manage the Application Server. You can also use the wsadmin scripting facility to perform every function that is available in the administrative console application.

There is no node agent process for a stand-alone application server unless you decide to add the Application Server node to a deployment manager cell. Adding the Application Server to a cell is known as federation. Federation changes the stand-alone application server into a managed node. At that point, you use the administrative console of the deployment manager to manage the node. If you remove the node from the deployment manager cell, use the administrative console and the scripting interface of the stand-alone application server to manage the process.

Specify default or app_server_root/profileTemplates/default for the -templatePath parameter to create this type of profile.

Custom profile
The basic function of this profile that belongs to a deployment manager cell is to serve applications to the Internet or to an intranet under the management of the deployment manager.

The deployment manager changes a custom profile to a managed node by adding the node into the cell. This is also true when you add an Application Server into a cell. When either node is added to a cell, the node becomes a managed node. The nodeagent process is then instantiated on the managed node. The node agent acts on behalf of the deployment manager to control Application Server processes on the managed node. The node agent can start or stop Application Servers, for example.

A deployment manager can create multiple Application Servers on a managed node so long as the node agent process is running. Processes on the managed node can include cluster members that the deployment manager uses to balance the work load for heavily used applications.

Use the administrative console of the deployment manger to control all of the nodes that the deployment manager manages. You can also use the wsadmin scripting facility of the deployment manager to control any of the managed nodes. A custom profile does not have its own administrative console or scripting interface. You cannot manage the node directly with the wsadmin scripting facility. You must use the administrative interface of the deployment manager to manage a managed node.

A custom profile does not include default applications or a default server as the Application Server profile does. A custom profile is an empty node. Add the node to the deployment manager cell. Then you can use the administrative interface of the deployment manager to customize the managed node by creating clusters and Application Servers.

Specify managed or app_server_root/profileTemplates/managed for the -templatePath parameter to create this type of profile.

Installed file set

You decide where to install the files that define a profile.

The default location is the default profile_root. But you can change the location on the Profile creation wizard or in a parameter when using the command line tool.

The following directories exist within a typical profile:

The profile repository

The profile repository is the default location of profile-related metadata. The repository is the default location for new profiles. The installation root directory for a profile is a directory with the same name as the profile within the repository. This directory is referred to throughout the information center as the profile_root.

However, you can decide where to install a profile. When you specify a directory, such as /opt/profiles, the profiles that you create are no longer in the default repository, which is not a problem.

Location of the wasprofile script

The command file is located in the app_server_root/bin directory.

The command file is a script named:
  • [Linux][UNIX]wasprofile.sh
  • [Windows]wasprofile.bat

The Profile creation wizard is the graphical user interface to the command line tool. The file name of the command that calls the Profile creation wizard varies per operating system platform. See Creating profiles through the graphical user interface for more information.

Logging

The wasprofile command creates a log for every profile that it creates. The logs are in the app_server_root/logs/wasprofile directory. The files are named in this pattern: wasprofile_create_profile_name.log.

The command also creates a log for every profile that it deletes. The logs are in the app_server_root/logs/wasprofile directory. The files are named in this pattern: wasprofile_delete_profile_name.log.

Required disk space

You must have 200 MB of available disk space in the directory where you create an Application Server profile.

Manually verify that the required space for creating a profile is available on AIX. A known problem in the underlying InstallShield for Multiplatforms (ISMP) code prevents proper space checking on AIX systems at the time that the product disc was created.

An error can occur when you have not provided enough system temporary space to create a profile. Verify that you have a minimum of 40 MB of temp space available before creating a profile.

Network Deployment
Note:

You must have 30 MB of available disk space in the directory where you create a deployment manager profile.

You must have 10 MB of available disk space in the directory where you create a custom profile.

After installing the core product files, you must create one of the following profiles to have an operational run-time environment:
  • An application server profile.

    See Creating an application server profile. An Application Server profile has a default server (which is server1), the default application that includes the snoop servlet and the hitcount servlet, and application Samples. You can federate the Application Server or use it as a stand-alone application server.

  • A deployment manager.

    See Creating a deployment manager profile. The deployment manager provides a single administrative interface to a logical group of application servers on one or more machines.

  • A custom profile that you must federate to make operational.

    See Creating a custom profile. A custom profile is an empty node that you can customize to include application servers, clusters, or other Java processes, such as a messaging server.

Concurrent profile creation

Important: Concurrent profile creation is not supported at this time for one set of core product files. Concurrent attempts to create profiles result in a warning about a profile creation already in progress.
[Linux][UNIX]

Entering lengthy commands on more than one line

The length of the wasprofile command can exceed the normal shell window limit for one line of 256 characters. If your command is longer than the limit, issue the command on multiple lines by ending a line with a backward slash, pressing Enter, and continuing the command on the next line.

For example, on a Solaris system, the following command requires input on multiple lines:
./wasprofile.sh \
-create -profileName bladetcb6profile \
-profilePath /usr/IBM/WebSphere/AppServer/profiles/bladetcb6profile \
-templatePath /usr/WebSphere/AppServer/profileTemplates/default \
-nodeName bladetcb6node \
-cellName bladetcb6Cell \
-hostName bladetcb6.rtp.raleigh.ibm.com

Omit the line continuation character from the last line to signal the end of the command to the operating system.

[Linux][UNIX]

wasprofile.sh command syntax

Get help for the command:
# ./wasprofile.sh -help

# ./wasprofile.sh -augment -help
                 
# ./wasprofile.sh -create -help
# ./wasprofile.sh -create -templatePath fully_qualified_path/dmgr -help
# ./wasprofile.sh -create -templatePath fully_qualified_path/default -help
# ./wasprofile.sh -create -templatePath fully_qualified_path/managed -help
                 
# ./wasprofile.sh -delete -help
                 
# ./wasprofile.sh -getName -help

# ./wasprofile.sh -getPath -help
                 
# ./wasprofile.sh -unaugment -help
                 
# ./wasprofile.sh -validateRegistry -help

# ./wasprofile.sh -validateAndUpdateRegistry -help

List existing profiles:
# ./wasprofile.sh -listProfiles 
                 [-debug]
                 
Delete profiles:
# ./wasprofile.sh -delete 
                -profileName profile_name | -profilePath profile_path 
               [-debug]
                
Create new profiles:
wasprofile.sh -create 
              -profileName profile_name 
              -profilePath fully_qualified_profile_path 
              -templatePath template_path 
              -nodeName node_name 
              -cellName cell_name 
              -hostName host_name 
              -serverName  server_name
             [-isDefault]
             [-dmgrHost host_name] 
             [-dmgrPort SOAP port] 
             [-startingPort starting_port | -portsFile file_path]
             [-debug] 
             
Get the name of an existing profile from its path:
# ./wasprofile.sh -getName 
                 -profilePath profile_path 
                [-debug] 
                
Get the path of an existing profile from its name:
# ./wasprofile.sh -getPath 
                 -profileName profile_name 
                [-debug] 
                
Check the integrity of the profile registry:
# ./wasprofile.sh -validateRegistry 
                [-debug] 
                
Check the integrity of the profile registry, removing profiles that are not found:
# ./wasprofile.sh -validateAndUpdateRegistry 
                 [-backup file_name] 
                 [-debug] 
                
Refresh a profile from an updated template file:
wasprofile.sh -augment 
              -profileName  profile_name 
              -templatePath fully_qualified_template_path
Remove the most recent augmentation for a profile:
wasprofile.sh -unaugment 
              -profileName profile_name 
[Windows]

wasprofile.bat command syntax

Get help for the command:
wasprofile.bat -help

wasprofile.bat -augment -help
                 
wasprofile.bat -create -help
wasprofile.bat -create -templatePath fully_qualified_path\dmgr -help
wasprofile.bat -create -templatePath fully_qualified_path\default -help
wasprofile.bat -create -templatePath fully_qualified_path\managed -help
                 
wasprofile.bat -delete -help
                 
wasprofile.bat -getName -help

wasprofile.bat -getPath -help

wasprofile.bat -unaugment -help
                 
wasprofile.bat -validateRegistry -help

wasprofile.bat -validateAndUpdateRegistry -help

List existing profiles:
wasprofile.bat -listProfiles 
             [-debug]
             
Delete profiles:
wasprofile.bat -delete 
              -profileName profile_name | -profilePath profile_path 
             [-debug] 
             
Create new profiles:
wasprofile.bat -create 
              -profileName profile_name 
              -profilePath fully_qualified_profile_path 
              -templatePath template_path 
              -nodeName node_name 
              -cellName cell_name 
              -hostName host_name 
              -serverName  server_name
             [-isDefault]
             [-dmgrHost host_name] 
             [-dmgrPort SOAP port] 
             [-startingPort starting_port | -portsFile file_path]
             [-winserviceCheck true | false]
             [-winserviceAccountType specified_user | localsystem]
             [-winserviceUserName your_user_name]
             [-winservicePassword your_password]
             [-winserviceStartupType manual | automatic | disabled]
             [-debug] 
             

When the -startingPort parameter is not used, the profile creation tool uses the default port settings specified in the serverindex.xml file.

Get the name of an existing profile from its path:
wasprofile.bat -getName 
               -profilePath fully_qualified_profile_path 
              [-debug] 
             
Get the path of an existing profile from its name:
wasprofile.bat -getPath 
               -profileName profile_name 
              [-debug] 
             
Check the integrity of the profile registry:
wasprofile.bat -validateRegistry 
             [-debug] 
             
Check the integrity of the profile registry, removing any unfound profiles:
wasprofile.bat -validateAndUpdateRegistry 
             [-backup file_name] 
             [-debug] 
             
Refresh a profile from an updated template file:
wasprofile.bat -augment 
               -profileName  profile_name 
               -templatePath fully_qualified_template_path
Remove the most recent augmentation for a profile:
wasprofile.bat -unaugment 
               -profileName  profile_name 

For specific examples of creating a profile, see the Example: Using commands to create profiles section.

Parameters

Supported arguments include:
-augment
Augmentation is the ability to apply a changed template to an existing profile. The augment parameter causes wasprofile to refresh or augment the profile identified in the profileName parameter using the template in the templatePath parameter.

When the augment action is invoked, the wasprofile command attempts to access the actionRegistry.xml file in the specified template path. The operations defined in the Config Actions stanza in the action registry file are then applied against the specified profile.

Specify the fully qualified file path for -templatePath. Specifying a relative file path for the -templatePath parameter results in the specified profile not being fully augmented.

See also the unaugment parameter.

-backup file_name
Backs up the profile registry file to the specified file.
-cellname cell_name
Specifies the cell name of the profile. Use a unique cell name for each profile.

Use a unique name even though you plan to federate the custom profile or stand-alone profile into a deployment manager cell. Federation requires unique cell names before it can make the node part of the deployment manager cell. A cell name must be unique in any circumstance in which the product is running on the same physical machine or cluster of machines, such as a sysplex. Additionally, a cell name must be unique in any circumstance in which network connectivity between entities is required either between the cells or from a client that must communicate with each of the cells. Cell names also must be unique if their name spaces are going to be federated. Otherwise, you might encounter symptoms such as a javax.naming.NameNotFoundException exception, in which case, you need to create uniquely named cells.

-create
Creates the profile.
Specify wasprofile -create -templatePath fully_qualified_file_path_to_template -help for specific information about creating a profile. Available templates include:
  • dmgr - Deployment manager
  • default - Stand-alone application server
  • managed - Custom node
-debug
Turns on the debug function of the Ant utility, which the wasprofile command uses.
-delete
Deletes the profile. Deleting a profile does not delete the profile directory. For example, suppose that you create a profile in the /usr/WebSphere/AppServer/profiles/managedProfile directory. The directory remains after you delete the profile.

Unaugment any augmentations that you have made before deleting the profile.

You can delete or leave the directory. However, the profile_dir/logs directory contains information about uninstalling the profile. For example, you might retain the _nodeuninst.log file to determine the cause of any problem during the uninstall procedure.

The delete parameter does not perform an unaugment automatically. You must perform an unaugment manually before deleting the profile.

-dmgrHost host_name
Identifies the machine where the deployment manager is running. Specify this parameter and the dmgrPort parameter to federate a custom profile as it is created.

The host name can be the long or short DNS name or the IP address of the deployment manager machine.

Specifying this optional parameter directs the wasprofile command to attempt to federate the custom node into the deployment manager cell as it creates the custom profile. This parameter is ignored when creating a deployment manager profile or an Application Server profile.

Federating when the deployment manager is not available

If you federate a custom node when the deployment manager is not running or is not available because of security being enabled or for other reasons, the installation indicator in the logs is INSTCONFFAIL to indicate a complete failure. The resulting custom profile is unusable. You must move the custom profile directory out of the profile repository (the profiles installation root directory) before creating another custom profile with the same profile name.

If you have enabled security or changed the default JMX connector type, you cannot federate with the wasprofile command. Use the addNode command instead.

-dmgrPort port_number
Identifies the SOAP port of the deployment manager. Specify this parameter and the dmgrHost parameter to federate a custom profile as it is created. The deployment manager must be running and accessible.

If you have enabled security or changed the default JMX connector type, you cannot federate with the wasprofile command. Use the addNode command instead.

-getName
Gets the name for a profile registered at a given -profilePath parameter.
-getPath
Gets the file system location for a profile of a given name. Requires the –profileName parameter.
-help
Displays command syntax.
-hostName host_name
Specifies the host name where you are creating the profile. This should match the host name that you specified during installation of the initial product.
-isDefault
Specifies that the profile identified by the accompanying -profileName parameter is to be the default profile once it is registered. When issuing commands that address the default profile, it is not necessary to use the -profileName attribute of the command.
-listProfiles
Llists all defined profiles.
-nodeName node_name
Specifies the node name for the node that is created with the new profile. Use a unique value within the cell or on the machine. Each profile that shares the same set of product binaries must have a unique node name.
-portsFile file_path
An optional parameter that specifies the path to a file that defines port settings for the new profile. When omitted, the wasprofile tool looks for the app_server_root/profileTemplates/profile_type /actions/portsUpdate/bin/portdef.props file.

Do not use this parameter when using the -startingPort parameter.

-profileName profile_name
Specifies the name of the profile. Use a unique value when creating a profile. Each profile that shares the same set of product binaries must have a unique name.
-profilePath profile_path
Specifies the fully qualified path to the profile.
[Windows]Specify the full path to avoid an ANT scripting limitation that can cause a failure when federating the profile into a cell. For example:
-profilePath C:\IBM\WebSphere\AppServer\profiles\profile01

[Windows]If the fully qualified path contains spaces, enclose the value in quotation marks.

-serverName server_name
Specifies the name of the application server. If not specified, the default application server name is server1. This parameter is supported only on the OS/400 operating system.
-startingPort startingPort
Specifies the starting port number for generating all ports for the profile. If not specified, the wasprofile command uses default ports specified in the serverindex.xml file.

Do not use this parameter with the -portsFile parameter.

-templatePath template_path
Specifies the directory path to the template files in the installation root directory.

Within the profileTemplates directory are various directories that correspond to different profile types and that vary with the type of product installed.

The profile directories are the paths that you indicate while using the -templatePath option.

You can specify profile templates that lie outside the installation root, if you happen to have any.

If you specify a relative path, the specified template location defaults to the app_server_root/profileTemplates directory.

For example, the following paired specifications each point to the same template path:

[AIX]
-templatePath /usr/WebSphere/AppServer/profileTemplates/default
-templatePath default
[Linux][HP-UX][Solaris]
-templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/default
-templatePath default
[Windows]
-templatePath C:\Program Files\IBM\WebSphere\AppServer\profileTemplates\default
-templatePath default
-unaugment
Augmentation is the ability to apply a changed template to an existing profile. When you unaugment an existing profile that has been augmented, the changes are backed out according to the previously specified profile template. If a series of wasprofile augmentations were performed, then the unaugment action will undo the last augment action first.

When the unaugment action is invoked, wasprofile attempts to access the deleteRegistry.xml file in the template path that was specified in the augment command. The operations defined in the Config Actions stanza in the delete registry file are then applied against the specified profile.

Specify the fully qualified file path for -templatePath.

See also the augment parameter.

-validateAndUpdateRegistry registry_file backup_file
Checks all of the profiles that are listed in the profile registry to see if the profiles are present on the file system. Removes any missing profiles from the registry. Returns a list of the missing profiles that were deleted from the registry.
-validateRegistry registry_file
Checks all of the profiles that are listed in the profile registry to see if the profiles are present on the file system. Returns a list of missing profiles.
[Windows]-winserviceAccountType type_of_owner_account
The type of the owner account of the Windows service created for the profile can be either a specified user name or the value, localsystem. The localsystem value runs the Windows service under the local account of the user who creates the profile.
[Windows]-winserviceCheck value
The value can be either true or false. Specify true to create a Windows service for the server process that is created within the profile. Specify false to not create the Windows service.
[Windows]-winservicePassword your_password
Specify the password for the specified user or the local account that is to own the Windows service.
[Windows]-winserviceStartupType startup_type
Possible startup_type values are:
  • manual
  • automatic
  • disabled

See WASService command for more information about Windows services.

[Windows]-winserviceUserName user_ID
Specify your user ID so that Windows can verify you as an ID that is capable of creating a Windows service. Your user ID must belong to the administrator group and have the following advanced user rights:
  • Act as part of the operating system
  • Log on as a service

Use case scenarios

Use cases are a description of common tasks for which the tool is used.

[Linux][UNIX]

Scenario: Creating a deployment manager profile

To create a deployment manager profile for user shasti:

wasprofile.sh -create
              -profileName shasti 
              -profilePath ~/shasti/WebSphere 
              -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/dmgr 
              -cellName shaix1  
              -hostName planetaix 
              -nodeName dmgr1

On an Express product or a base product installation, the command does not create anything because the deployment manager template is not present.

On a Network Deployment product installation, the command creates a deployment manager profile named shasti in a cell named shaix1 in location ~/shasti/WebSphere with a node name of dmgr1.

[Windows]

Scenario: Creating a deployment manager profile

To create a deployment manager profile for user shasti:

wasprofile.sh -create
              -profileName shasti 
              -profilePath G:\shasti\WebSphere
              -templatePath C:\IBM\WebSphere\AppServer\profileTemplates\dmgr 
              -cellName shwindows1  
              -hostName planetnt 
              -nodeName dmgr1

On a Network Deployment product installation, the command creates a deployment manager profile named shasti in a cell named shwindows1 in location G:\shasti\WebSphere with a node name of dmgr1.

[Linux][UNIX]

Scenario: Creating a deployment manager profile in a multiuser environment

Example

Follow these steps to create a deployment manager profile for user shasti in a multiuser environment:
  1. Create the profile:
    
    wasprofile.sh -create
                  -profileName shasti 
                  -profilePath ~/shasti/WebSphere 
                  -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/dmgr 
                  -cellName shaix1  
                  -hostName myhost 
                  -nodeName dmgr1
                  -startingPort 12000
    
  2. Change the owner of the folder:
    chown -R shasti ~/shasti/WebSphere
    
  3. As a convenience, add a call to script ~shasti/WebSphere/bin/setupCmdLine.sh in the profile of user shasti to set the environment when user shasti logs in.
  4. Give these folder permissions to user shasti:
    app_server_root/bin         --- rx (read and execute)
    app_server_root/java        --- rx 
    app_server_root/properties  ----r  (read)
    app_server_root/deploytool  ----r 
    app_server_root/config      ----r 
    app_server_root/lib         ----r 
    app_server_root/classes     ----r 
    app_server_root/null        ----r 
    app_server_root/samples     ----r 
    app_server_root/Web         ----r 
    

Scenario: Deleting a profile

The following command is on more than one line for clarity. Enter the command on one line to delete the profile named shasti:

wasprofile.sh -delete
                     -profileName shasti 

Scenario: Using predefined port numbers

When you use the wasprofile tool without the -startingPort parameter, the tool uses the app_server_root/profileTemplates/profile_type /actions/portsUpdate/bin/portdef.props file to set the initial ports.

Example of using the -portsFile parameter

Copy the file, edit the port settings, and use your copy by using the -portsFile parameter as shown in the following example:
wasprofile.bat 
   -create
   -profileName Wow_Profile 
   -profilePath 
       profile_root 
   -templatePath 
       app_server_root\profileTemplates\default 
   -nodeName Wow_node 
   -cellName Wow_cell
   -hostName lorriemb 
   -portsFile C:\temp\ports\portdef.props 
Suppose that the portdef.props file has the following values:
WC_defaulthost=39080
WC_adminhost=39060
WC_defaulthost_secure=39443
WC_adminhost_secure=39043
BOOTSTRAP_ADDRESS=32809
SOAP_CONNECTOR_ADDRESS=38880
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=39401
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=39403
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=39402
ORB_LISTENER_ADDRESS=39100
DCS_UNICAST_ADDRESS=39353
SIB_ENDPOINT_ADDRESS=37276
SIB_ENDPOINT_SECURE_ADDRESS=37286
SIB_MQ_ENDPOINT_ADDRESS=35558
SIB_MQ_ENDPOINT_SECURE_ADDRESS=35578
As you run the command, messages similar to the following appear in the output stream:
replaceRegExpAllInstancesOfGivenTokenWithGivenValueForTheGivenFile:
  [echo] File C:\ExpressV6\IBM\WebSphere\AppServer\profiles\
  Wow_Profile/config/templates/default/serverentry-template.xml:  
  setting CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS to 39403

...
replaceRegExpAllInstancesOfGivenTokenWithGivenValueForTheGivenFile:
   [echo] File C:\ExpressV6\IBM\WebSphere\AppServer\profiles\
   Wow_Profile/config/templates/default/serverentry-template.xml:  
   setting CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS to 39402
...
The resulting serverindex.xml file looks similar to the following example:
<?xml version="1.0" encoding="UTF-8"?>
<serverindex:ServerIndex xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" 
...
   <specialEndpoints xmi:id="NamedEndPoint_..." 
                                         endPointName="BOOTSTRAP_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="lorriemb" port="32809"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                                   endPointName="SOAP_CONNECTOR_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="lorriemb" port="38880"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                   endPointName="SAS_SSL_SERVERAUTH_LISTENER_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="lorriemb" port="39401"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                  endPointName="CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="lorriemb" port="39403"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                 endPointName="CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="lorriemb" port="39402"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                                      endPointName="WC_adminhost">
      <endPoint xmi:id="EndPoint_..." host="*" port="39060"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                                    endPointName="WC_defaulthost">
      <endPoint xmi:id="EndPoint_..." host="*" port="39080"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                                  endPointName="DCS_UNICAST_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="lorriemb" port="39353"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                                endPointName="WC_adminhost_secure">
      <endPoint xmi:id="EndPoint_..." host="*" port="39043"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                                endPointName="WC_defaulthost_secure">
      <endPoint xmi:id="EndPoint_..." host="*" port="39443"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                               endPointName="SIB_ENDPOINT_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="*" port="37276"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                         endPointName="SIB_ENDPOINT_SECURE_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="*" port="37286"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                              endPointName="SIB_MQ_ENDPOINT_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="*" port="35558"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                       endPointName="SIB_MQ_ENDPOINT_SECURE_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="*" port="35578"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                                endPointName="ORB_LISTENER_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="lorriemb" port="39100"/>
    </specialEndpoints>
  </serverEntries>
</serverindex:ServerIndex>

The wasprofile command creates a copy of the current portdefs.props file in the profile_root\logs directory.

Do not use the portsFile parameter when using the startingPort parameter. The two parameters are mutually exclusive.

Scenario: Incrementing default port numbers from a starting point

The wasprofile command can assign port numbers based on a starting port value that you give on the command line, using the -startingPort parameter. The tool assigns port numbers sequentially from the starting port number value.

The order of port assignments is arbitrary. Predicting assignments is not possible.

For example, ports created with -startingPort 20002 would appear similar to the following example:

Assigned ports for an Application Server profile

WC_defaulthost=20002
WC_adminhost=20003
WC_defaulthost_secure=20004
WC_adminhost_secure=20005
BOOTSTRAP_ADDRESS=20006
SOAP_CONNECTOR_ADDRESS=20007
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=20008
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=20009
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=20010
ORB_LISTENER_ADDRESS=20011 
DCS_UNICAST_ADDRESS=20012
SIB_ENDPOINT_ADDRESS=20013
SIB_ENDPOINT_SECURE_ADDRESS=20014
SIB_MQ_ENDPOINT_ADDRESS=20015
SIB_MQ_ENDPOINT_SECURE_ADDRESS=20016

Assigned ports for a custom profile

WC_defaulthost=20002
WC_adminhost=20003
WC_defaulthost_secure=20004
WC_adminhost_secure=20005
BOOTSTRAP_ADDRESS=20006
SOAP_CONNECTOR_ADDRESS=20007
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=20008
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=20009
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=20010
ORB_LISTENER_ADDRESS=20011
CELL_DISCOVERY_ADDRESS=20012
DCS_UNICAST_ADDRESS=20013
Assigned ports for a deployment manager profile
CELL_DISCOVERY_ADDRESS=20010
BOOTSTRAP_ADDRESS=20004
DRS_CLIENT_ADDRESS=7989
SOAP_CONNECTOR_ADDRESS=20005
ORB_LISTENER_ADDRESS=20009
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=20006
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=20008 
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=20007
WC_adminhost=20002
DCS_UNICAST_ADDRESS=20011
WC_adminhost_secure=20003

Example of startingPort parameter use

The following example of using the wasprofile command creates ports from an initial value of 20002, with the content shown in the previous example:
wasprofile.bat -create
               -profileName shasti 
               -profilePath profile_root 
               -templatePath template_path 
               -nodeName W2K03 
               -cellName W2K03_Cell01
               -hostName planetnt 
               -startingPort 20002 
                            

Scenario: Setting up and using the profile environment

Most tasks that you perform in a profile are done using the -profileName attribute on the command line tools that you use. Such a scenario might be:
  1. Create the server process using the app_server_root/bin/wasprofile.sh (or wasprofile.bat) script from the original installation. Assume that you create the Profile02 profile.
  2. In that command window or in another, change directories to the /bin directory of the new server process.
  3. Establish a temporary override for the normal WebSphere Application Server environment by using the -profileName attribute on a command you issue. In the same window, start server1 by changing directories to the app_server_root/bin directory of the original installation and issuing the command. There is no such command in the /bin directory of the server process:
    startServer.sh server1 -profileName Profile02
  4. Notice the changes in the environment. Display all of the ports for the machine to see the ports that you set for the server process. For example, in a Linux bash shell or in the command window on a Windows platform, type:
    netstat -a 
  5. Open a browser window and point it at the port defined for the HTTP_TRANSPORT_ADMIN port of the new process. For example, suppose the setting is HTTP_TRANSPORT_ADMIN=20003. Open the administrative console for server1 by pointing your browser at:
    http://hostname_or_IP_address:20003/ibm/console/
[Linux][UNIX]

Scenario: Profile creation for a non-root user

Two methods exist for a non-root user to create a profile:
  • The root user creates the profile and assigns ownership to the non-root user.
  • A non-root user creates a profile after getting write permission to the appropriate directories.
In addition, once a profile is owned by a non-root user, installing a maintenance package that contains service for the profile can create files owned by the user who installs the maintenance package. For example, if root updates a profile, certain files in the profile are owned by the root user instead of the non-root user. This scenario is described as the last one in this group:
  • The root user updates an existing non-root profile and changes the ownership of some files.
Remember: An ease-of-use limitation exists for non-root users who create profiles. Mechanisms within the Profile creation wizard that suggest unique names and port values are disabled for non-root users. The non-root user must change the default field values in the Profile creation wizard for the profile name, node name, cell name, and port assignments. Consider assigning non-root users a range of values for each of the fields. You can assign responsibility to the non-root profilers for adhering to their proper value ranges and for maintaining the integrity of their own definitions.
[Linux][UNIX]

Root creates the profile and assigns ownership to a non-root user

The root user can create a profile and assign ownership of the profile directory to a non-root user.
  1. The root user creates the profile with the following command:
    ./wasprofile.sh -create -profileName profile01 -profilePath profile_root
  2. The root user changes ownership of the directory for the profile to the non-root user with the following command:
    chown -R user1 profile_root
  3. The root user also changes the ownership of the logs directory for the profile to prevent displaying log messages to the console:
    chown -R user1 app_server_root/logs/wasprofile
[Linux][UNIX]

A non-root user creates the profile (advanced option)

The root user can grant write permission to the appropriate files and directories to a non-root user. The non-root user can then create the profile. You can create a group for users who are authorized to create profiles. Or you can give everyone the ability to create profiles. The following example shows how to create a group that is authorized to create profiles.
  1. Log on to the Application Server system as root.
  2. Create the profilers group that you can use to create profiles.
  3. Create a user named user1 to create profiles.
  4. Add users root and user1 to the profilers group.
  5. Log off and back on as root to pick up the new group.
  6. As root, create the app_server_root/logs/wasprofile directory if the directory does not yet exist:
    mkdir app_server_root/logs/wasprofile
    
  7. As root, use operating system tools to change file permissions.
    The following example assumes that the installation root directory is app_server_root:
    chgrp profilers app_server_root/logs/wasprofile
    chmod g+wr  app_server_root/logs/wasprofile
    chgrp profilers app_server_root/properties
    chmod g+wr  app_server_root/properties
    chgrp profilers app_server_root/properties/fsdb
    chmod g+wr  app_server_root/properties/fsdb
    chgrp profilers app_server_root/properties/profileRegistry.xml
    chmod g+wr  app_server_root/properties/profileRegistry.xml
    
    Some of the files in the preceding list are created when creating the profile. So it is impossible to assign ownership of the files. However, assigning ownership of the directories allows the non-root user to create the file. Such files include:
    app_server_root/properties/fsdb
    app_server_root/properties/profileRegistry.xml
    You might have to change the permissions on additional directories if you encounter permission problems. For example, if you allow a non-root user to delete a profile, the user might have to delete the app_server_root/properties/profileRegistry.xml_LOCK file:
    Another wasprofile process is running or a lock file exists.
    If no process is running, delete the following file:
    app_server_root/properties/profileRegistry.xml_LOCK
    

    Give write access to the non-root user for the file to allow the user to delete the file. If the non-root user still cannot delete the profile, the root user can delete the profile.

  8. The non-root user who belongs to the profilers group can then create a profile in any directory to which the non-root user has write permission.

    If the non-root user does not have write access to any directories, it is up to the root user to change that situation. If the non-root user does not have write access to the /tmp directory, it is up to the root user to change that as well.

    The commands listed in step 6 give users assigned to the profilers group the ability to write to the app_server_root/logs/wasprofile directory and to the app_server_root/properties directory. It is not necessary to write to any other directories in the installation root directory of your WebSphere Application Server Network Deployment product.

    Have non-root users create a profiles directory in their own area, not in the installation root directory of the product. If a root user creates profiles for a non-root user, change permissions for the app_server_root/profiles directory.
    chmod -R 777  app_server_root/profiles
[Linux][UNIX]

The root user updates an existing non-root profile and changes the ownership of certain files

The root user runs the Update Installer wizard to install maintenance packages for WebSphere Application Server Version 6.x products. Some maintenance packages include required service for existing profiles.

Non-root users can own profiles on Linux and UNIX systems. If the root user updates an existing non-root profile, any new files that the maintenance package creates are owned by the root user instead of the non-root user.

When an application server in a non-root profile starts, it attempts to load the new files. Because the new files belong to the root user, the application server encounters an error and issues a message that is similar to the following example:
ADMR0104E: 
The system is unable to read document 
cells/express1Cell/nodes/express1/node-metadata.properties: 
java.io.IOException: No such file or directory

Installing a maintenance package that contains service for a non-root profile changes the ownership of any new files that the maintenance package creates. The user that installs the maintenance becomes the owner of the new files. The root user is required to install maintenance for Version 6.x. Therefore, after installing the maintenance, root owns any new files in the profile.

For example, Refresh Pack 2 has required service for the JDBC resource provider templates. The required service backs up some existing files and creates new versions of the files. The new files are owned by the user who installed the maintenance package. When the root user installs Refresh Pack 2, the root user owns the following JDBC-related files:
  • profile_root/logs/updateProfileJdbcTemplate.log
  • profile_root/config/templates/system/jdbc-resource-provider-only-templates.xml
  • profile_root/config/templates/system/jdbc-resource-provider-templates.xml

To fix the problem, reassign ownership of the entire profile directory to the non-root user (wsdemo in the following example). The profile_root directory is owned by the non-root user.

The root user can make the wsdemo user the owner of the profile directory with the following command:
chown -R wsdemo profile_root

Example: Using commands to create profiles

The following examples show how to create profiles using the wasprofile command.

Issue the command in any of the following examples on one line. Each example shows the command on more than one line to increase clarity.

Creating a deployment manager profile

The following example uses the dmgr template to create a deployment manager profile named Dmgr001. The root directory for the profile is the profile_root directory. The deployment manager ports start at port 20000.[Linux][UNIX]
app_server_root/bin/manageprofiles.sh -create 
   -profileName Dmgr001
   -profilePath profile_root
   -templatePath app_server_root/profileTemplates/dmgr
   -nodeName Dmgr001Node
   -cellName Dmgr001NodeCell
   -hostName localhost
   -isDefault
   -startingPort 20000
[Windows]
app_server_root\bin\manageprofiles.bat -create 
   -profileName Dmgr001
   -profilePath profile_root
   -templatePath app_server_root\profileTemplates\dmgr
   -nodeName Dmgr001Node
   -cellName Dmgr001NodeCell
   -hostName localhost
   -isDefault
   -startingPort 20000

Creating a custom profile

Federate a custom profile to customize the profile with the deployment manager.

Create a custom profile for federating into a deployment manager cell with the following command:[Windows]
c:\WebSphere\AppServer\bin wasprofile -create
				-profileName Custom01
				-profilePath profile_root
				-templateParh app_server_root\profileTemplates\managed
				-nodeName CustomNode01
				-cellName CustomNodeCell01
				-hostName myhost.mycity.mycompany.com
				-isDefault 
				-dmgrHost myhost.mycity.mycompany.com
				-dmgrPort 8879
				-startingPort 22000
[Linux][UNIX]
app_server_root/bin/manageprofiles.sh -create 
   -profileName Custom01
   -profilePath profile_root
   -templatePath app_server_root/profileTemplates/managed
   -nodeName Custom01Node
   -cellName Custom01Cell
   -hostName myhost.mycity.mycompany.com
   -isDefault
   -startingPort 22000

Creating a stand-alone application server profile

Create an application server profile named Default01 with the following command:[Windows]
app_server_root\bin wasprofile -create 
				-profileName Default01 
				-profilePath profile_root
				-templatePath app_server_root\profileTemplates\default 
				-nodeName Default01Node
				-cellName Default01Cell
				-hostName myhost.mycity.mycompany.com
				-isDefault false
				-winserviceCheck true
				-winserviceAccountType user
				-winserviceUserName my_user_id
				-winservicePassword my_password
				-winserviceStartupType manual
				-startingPort 21000
[Linux][UNIX]
app_server_root/bin/manageprofiles.sh -create 
   -profileName Default01
   -profilePath profile_root
   -templatePath app_server_root/profileTemplates/default
   -nodeName Default01Node
   -cellName Default01Cell
   -hostName myhost.mycity.mycompany.com
   -isDefault
   -startingPort 21000
Reference topic    

Terms of Use | Feedback

Last updated: Dec 11, 2005 4:07:15 PM CST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rxml_wasprofile.html

© Copyright IBM Corporation 2004, 2005. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)