wasprofile command

The wasprofile command line tool creates all Application Server run-time environments in V6. The command creates a profile, which is the set of files that define the run-time environment for...

The wasprofile command creates the run-time environment for a WAS 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. 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 V6 port assignments.

Core product files

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

The directory structure for V6 has two major divisions of files in the installation root directory for the product:

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, one can put a profile anywhere on the machine 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.

WAS profile

The wasprofile command line tool defines each Application Server instance of a V6 product.

You must run the wizard or the command line tool each time that you want to create a stand-alone 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 new disposable profiles of the product for development and testing.

We 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

Within this directory are the default folder, the dmgr folder, and the managed folder. These are the paths that you indicate while using the wasprofile command with the -templatePath option.

The wasprofile command in the Network Deployment product can create the following types of profiles:

Installed file set

You decide where to install the files that define a profile. The default location is in the profiles directory in the installation root directory. But one can change the location on the Profile creation wizard or in a parameter when using the command line tool. For example, assume that you create two profiles on a Linux platform with host name devhost1. The profile directories resemble the following example if you do not relocate them

/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01     
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile02

Suppose that you specify a different directory, such as /opt/profiles, for the profile directory field in the wizard. The profile directories resemble the following example

/opt/profiles/devhost1Profile01     
/opt/profiles/devhost1Profile02

The following directories exist within a profile...

../profiles/profile/bin
                   /etc 
                   /firststeps 
                   /installableApps 
                   /installedApps 
                   /installedConnectors 
                   /installedFilters
                   /logs 
                   /properties 
                   /samples 
                   /temp 
                   /tranlog 
                   /wstemp

The profile repository

The profile repository is default location of profile-related metadata. The repository is the default location for new profiles, which is often referred to as the profiles installation root directory.

However, one can decide where to install a profile. The default location of the profile repository is...

install_root/profiles

In the earlier example, creating two profiles on a Linux platform with host name devhost1 results in the following example directories in the profile repository

/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01 
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile02

When you specify a directory, such as /opt/profiles, the profiles are no longer in the default repository, which is not a problem. For example, the following locations are valid

/opt/profiles/devhost1Profile01 
/opt/profiles/devhost1Profile02

Location of the command file

The wasprofile.sh|bat command file is located in...

install_root/bin

The Profile creation wizard is the graphical user interface to the command line tool.

Logging

The wasprofile command creates a log for every profile that it creates. The logs are in...

install_root/logs/wasprofile

The files are named in this pattern:

wasprofile_create_profile.log

The command also creates a log for every profile that it deletes. The logs are in...

install_root/logs/wasprofile

The files are named in this pattern:

wasprofile_delete_profile.log

Required disk space

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.

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

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, create one of the following profiles to have an operational run-time environment:

An application server
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. We can federate the application server or use it as a stand-alone application server.
A deployment manager.
Using the Profile creation wizard to create a deployment manager. The deployment manager provides a single administrative interface to a logical group of application servers on one or more machines.
A custom profile that federate to make operational.
A custom profile is an empty node that one 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.

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.

wasprofile.sh command syntax

Get help for the command

# ./wasprofile.sh -help
# ./wasprofile.sh -augment -help
# ./wasprofile.sh -create -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 | -profilePath profile_path 
               [-debug]

Create new profiles

wasprofile.sh -create 
              -profileName profile 
              -profilePath fully_qualified_profile_path 
              -templatePath template_path 
              -nodeName node 
              -cellName cell 
              -hostName host_name 
              -serverName  servername
             [-dmgrHost host_name] 
             [-dmgrPort SOAP port] 
             [-startingPort starting_port | -portsFile filepath]
              -winserviceCheck true | false
              -winserviceAccountType specifieduser | localsystem
              -winserviceUserName yourusername
              -winservicePassword yourpassword
              -winserviceStartupType manual | automatic | disabled
             [-debug]

Get name of existing profile from path

# ./wasprofile.sh -getName 
                 -profilePath profile_path 
                [-debug]

Get path of existing profile from name

# ./wasprofile.sh -getPath 
                 -profileName profile 
                [-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  fully_qualified_profile 
              -templatePath fully_qualified_template_path

Remove the most recent augmentation for a profile

wasprofile.sh -unaugment 
              -profileName fully_qualified_profile

wasprofile.bat command syntax

Get help for the command

# ./wasprofile.bat -help
# ./wasprofile.bat -augment -help
# ./wasprofile.bat -create -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 | -profilePath profile_path 
             [-debug]

Create new profiles

wasprofile.bat -create 
              -profileName profile 
              -profilePath fully_qualified_profile_path 
              -templatePath template_path 
              -nodeName node 
              -cellName cell 
              -hostName host_name 
              -serverName  servername
             [-dmgrHost host_name] 
             [-dmgrPort SOAP port] 
             [-startingPort starting_port | -portsFile filepath]
              -winserviceCheck true | false
              -winserviceAccountType specifieduser | localsystem
              -winserviceUserName yourusername
              -winservicePassword yourpassword
              -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 name of existing profile from path

wasprofile.bat -getName 
              -profilePath fully_qualified_profile_path 
             [-debug]

Get path of existing profile from name

wasprofile.bat -getPath 
              -profileName profile 
             [-debug]

Check integrity of profile registry

wasprofile.bat -validateRegistry 
             [-debug]

Check integrity of profile registry, removing unfound profiles

wasprofile.bat -validateAndUpdateRegistry 
             [-backup file_name] 
             [-debug]

Refresh a profile from an updated template file

wasprofile.bat -augment 
               -profileName  fully_qualified_profile 
               -templatePath fully_qualified_template_path

Remove the most recent augmentation for a profile

wasprofile.bat -unaugment 
               -profileName  fully_qualified_profile

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, wasprofile 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.

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.

-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, one cannot federate with the wasprofile command. Use the addNode command instead.

-getName

Gets the name for a profile registered at a given file system path. Requires the –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.

-listProfiles

Lists all defined profiles.

-nodeName node

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 file...

install_root/profileTemplates/profile_type /actions/portsUpdate/bin/portdef.props

Do not use this parameter when using the startingPort parameter.

-profileName profile

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.

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

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

serverName servername

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.

-templatePath template_path

Specifies the path to the templates in the shared binaries.

-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.

Use case scenarios

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

Scenario: Create a deployment manager profile on a Linux or UNIX platform

To create a deployment manager profile for user skyway

wasprofile.sh -create
              -profileName skyway 
              -profilePath ~/skyway/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 skyway in a cell named shaix1 in location...

~/skyway/WebSphere

...with a node name of dmgr1.

Scenario: Create a deployment manager profile on a Windows platform

To create a server process for user skyway

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

On an Express installation or on a base WAS product installation, the command does not create a deployment manager profile because the dmgr template does not exist in either product.

On a Network Deployment product installation, the command creates a deployment manager profile named skyway in a cell named shwindows1 in location...

G:\skyway\WebSphere

...with a node name of dmgr1.

Scenario: Create a deployment manager profile in a multiuser environment on a Linux or UNIX platform

Follow these steps to create a server process for user skyway in a multiuser environment:

Create the server process

wasprofile.sh -create
              -profileName skyway 
              -profilePath ~/skyway/WebSphere 
              -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/dmgr 
              -cellName shaix1  
              -hostName myhost 
              -nodeName dmgr1
              -startingPort 12000

Change the owner of the folder
```
chown -R skyway ~skyway2/WebSphere 
```
As a convenience, add a call to script...
~skyway/WebSphere/bin/setupCmdLine.sh

...in the profile of user skyway to set the environment when user skyway logs in.

Give these folder permissions to user skyway

install_root/bin         --- rx (read and execute)
install_root/java        --- rx 
install_root/properties  ----r  (read)
install_root/deploytool  ----r 
install_root/config      ----r 
install_root/lib         ----r 
install_root/classes     ----r 
install_root/null        ----r 
install_root/samples     ----r 
install_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 skyway

wasprofile.sh -delete
              -profileName skyway

Scenario: Using predefined port numbers

When you use the wasprofile tool without the -startingPort parameter, the tool uses...

/profileTemplates/profile_type/actions/portsUpdate/bin/portdef.props

...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 
       C:\ExpressV6\IBM\WebSphere\AppServer\profiles\Wow_Profile 
   -templatePath 
       C:\ExpressV6\IBM\WebSphere\AppServer\profileTemplates\default 
   -nodeName Wow_node 
   -cellName Wow_cell
   -hostName loyAllen 
   -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="IBMmachine" port="32809"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                                   endPointName="SOAP_CONNECTOR_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="IBMmachine" port="38880"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                   endPointName="SAS_SSL_SERVERAUTH_LISTENER_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="IBMmachine" port="39401"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                  endPointName="CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="IBMmachine" port="39403"/>
    </specialEndpoints>
    <specialEndpoints xmi:id="NamedEndPoint_..." 
                 endPointName="CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS">
      <endPoint xmi:id="EndPoint_..." host="IBMmachine" 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="IBMmachine" 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="IBMmachine" port="39100"/>
    </specialEndpoints>
  </serverEntries>
</serverindex:ServerIndex>

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

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

Scenario: Increment 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 skyway 
               -profilePath G:\skyway\WebSphere 
               -templatePath template_path 
               -nodeName W2K03 
               -cellName W2K03_Cell01
               -hostName amsterdam 
               -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:

Create the server process using...
install_root/bin/wasprofile.sh|bat

...from the original installation. Assume that you create the Profile02 profile.
In that command window or in another, change directories to the /bin directory of the new server process.
Establish a temporary override for the normal WAS environment by using the -profileName attribute on a command you issue. In the same window, start server1 by changing directories to the install_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
```
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 
```
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_orIP_address:20003/ibm/console/
```

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.

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. We can assign responsibility to the non-root profilers for adhering to their proper value ranges and for maintaining the integrity of their own definitions.

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

The root user can create a profile and assigns ownership of the profile directory to a non-root user.

The root user creates the profile with the following command:

./wasprofile.sh -create -profileName profile01 -profilePath install_root/profiles/profile01

The root user changes ownership of the directory for the profile to the non-root user with the following command
```
chown -R user1 install_root/profiles/profile01
```

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. We can create a group for users who are authorized to create profiles. Or one can give everyone the ability to create profiles. The following example shows how to create a group that is authorized to create profiles.

Log on to the Application Server system as root.
Create the profilers group that use to create profiles.
Create a user named user1 to create profiles.
Add users root and user1 to the profilers group.
Log off and back on as root to pick up the new group.

As root, use operating system tools to change file permissions.

The following example assumes that the installation root directory is /opt/IBM/WebSphere/AppServer

mkdir /opt/IBM/WebSphere/AppServer/logs/wasprofile
chgrp profilers /opt/IBM/WebSphere/AppServer/logs/wasprofile
chmod g+wr  /opt/IBM/WebSphere/AppServer/logs/wasprofile
chgrp profilers /opt/IBM/WebSphere/AppServer/properties
chmod g+wr  /opt/IBM/WebSphere/AppServer/properties
chmod g+wr  /opt/IBM/WebSphere/AppServer/properties/profileRegistry.xml

You might have to change the permissions on additional /opt/IBM/WebSphere/AppServer directories if you encounter permission problems.

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...
/opt/IBM/WebSphere/AppServer/logs/wasprofile

...and to...
/opt/IBM/WebSphere/AppServer/properties

It is not necessary to write to any other directories in the installation root of your WAS product.
Have non-root users create a profiles directory in their own area, not in the installation root directory of the product.

Related Tasks

Delete a profile