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...
The wasprofile command is also referred to as the profile creation tool. The profile creation tool is the only way to create run-time environments in V6.
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 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:
Note: If you put a profile in an installation root directory (anything that starts with /QIBM/ProdData), there is a risk that the profile might be damaged or destroyed by routine system maintenance
The wasprofile command line tool defines each Application Server profile of a Version 6 product.
You must run the command line tool each time that you want to create a stand-alone Application Server.
You can run 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.
Templates for each profile are located in the install_root/profileTemplates directory.
Within this directory are various directories that correspond to different profile types and vary with the type of product installed. These 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. If -templatePath is specified as a relative path, it is assumed that the specified template is in install_root/profileTemplates, where install_root is:
For example: -templatePath install_root/profileTemplates/default or -templatePath default
Templates included with WebSphere Application Server are listed here with a brief description. Unless a product designation is noted, the template exists in Express/Base/ND:
In WebSphere Application Server and WebSphere Application Server Express, you can use the wasprofile command to create stand-alone application server profiles. The basic function of the Application Server is to serve applications to the Internet or to an intranet. 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.
The wasprofile command in the Network Deployment product can create the following types of profiles:
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 one of the profile templates beginning with default (for example, defaultnosamp) or the full path to the template (for example, /QIBM/ProdData/WebSphere/AppServer/V6/ND/profileTemplates/defaultnosamp) for the -templatePath parameter if you want this type of profile. If you do not specify the -templatePath parameter, the default template is used.
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 /QIBM/ProdData/WebSphere/AppServer/V6/ND/profileTemplates/managed for the -templatePath parameter if you want this type of profile.
You can change the location in a parameter when using the command line tool. For example, assume that you create two profiles on an iSeries with host name devhost1 in the Base product. The profile directories resemble the following example if you do not relocate them:
/QIBM/UserData/WebSphere/AppServer/V6/Base/profiles/devhost1Profile01 /QIBM/UserData/WebSphere/AppServer/V6/Base/profiles/devhost1Profile02Here's an example of specifying a different directory, such as /home/QEJBSVR/profiles/myprofile, using the -profilePath parameter of the wasprofile tool:
wasprofile -profileName myprofile -profilePath /home/QEJBSVR/profiles/myprofileThe following directories exist within a typical profile. This example assumes that a Base profile named devhost1Profile01 exists:
Note: Different profile types may include different subdirectories. This list is not intended to be exhaustive or exclusive.
The script is located in the following directory:
The wasprofile command creates a log for every profile that it creates. The logs are in the profile_root/profileRegistry/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 profile_root/profileRegistry/logs/wasprofile directory. The files are named in this pattern: wasprofile_delete_profile_name.log.
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.
For ND 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.
During installation of the product, a profile is created named "default". In Network Deployment, another profile named "dmgr" is created, and is a deployment manager. The "default" profile in Network Deployment is a standalone Application Server. The "default" profile is initially set to be the default profile for scripts.
Most scripts support the -profileName parameter which enables the script to act on a profile other than the default one.
wasprofile -listProfiles
[-debug]
Delete profiles:wasprofile -delete
-profileName profile_name | -profilePath profile_path
[-debug]
Create new profiles:wasprofile -create
-profileName profile_name
[-profilePath fully_qualified_profile_path]
[-templatePath template_path]
[-nodeName node]
[-cellName cell_name]
[-hostName host_name]
[-serverName server_name]
[-dmgrHost host_name]
[-dmgrPort SOAP port]
[-startingPort starting_port | -portsFile filepath]
[-isDefault]
[-exthttp http_server_port]
[-os400passwords]
[-validationlist os400_password_validation_list]
[-debug]
Get the name of an existing profile from its path:wasprofile -getName
-profilePath profile_path
[-debug]
Get the path of an existing profile from its name:wasprofile -getPath
-profileName profile_name
[-debug]
Check the integrity of the profile registry:wasprofile -validateRegistry
[-debug]
Check the integrity of the profile registry, removing profiles that are not found:wasprofile -validateAndUpdateRegistry
[-backup file_name]
[-debug]
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 remove the profile root directory before attempting to create another profile at the same directory.
If you have enabled
security or changed the default JMX connector type, you cannot federate with the wasprofile command. Use the addNode command instead.
Note: Do not use this parameter when using the startingPort parameter.
The format of the ports file is as follows. The default values for the default Base template are depicted:
WC_defaulthost=9080 WC_adminhost=9060 WC_defaulthost_secure=9443 WC_adminhost_secure=9043 BOOTSTRAP_ADDRESS=2809 SOAP_CONNECTOR_ADDRESS=8880 SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=9501 CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=9503 CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=9502 ORB_LISTENER_ADDRESS=9100 DCS_UNICAST_ADDRESS=9353 SIB_ENDPOINT_ADDRESS=7276 SIB_ENDPOINT_SECURE_ADDRESS=7286 SIB_MQ_ENDPOINT_ADDRESS=5558 SIB_MQ_ENDPOINT_SECURE_ADDRESS=5578
Related tasks
Create a new profile