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
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.
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.
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.
Specify dmgr or app_server_root/profileTemplates/dmgr for the -templatePath parameter to create this type of profile.
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.
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.
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 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.
The command file is located in the app_server_root/bin directory.
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.
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.
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.
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.
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.
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.
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.
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.
./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 -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
# ./wasprofile.sh -listProfiles [-debug]
# ./wasprofile.sh -delete -profileName profile_name | -profilePath profile_path [-debug]
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]
# ./wasprofile.sh -getName -profilePath profile_path [-debug]
# ./wasprofile.sh -getPath -profileName profile_name [-debug]
# ./wasprofile.sh -validateRegistry [-debug]
# ./wasprofile.sh -validateAndUpdateRegistry [-backup file_name] [-debug]
wasprofile.sh -augment -profileName profile_name -templatePath fully_qualified_template_path
wasprofile.sh -unaugment -profileName profile_name
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
wasprofile.bat -listProfiles [-debug]
wasprofile.bat -delete -profileName profile_name | -profilePath profile_path [-debug]
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.
wasprofile.bat -getName -profilePath fully_qualified_profile_path [-debug]
wasprofile.bat -getPath -profileName profile_name [-debug]
wasprofile.bat -validateRegistry [-debug]
wasprofile.bat -validateAndUpdateRegistry [-backup file_name] [-debug]
wasprofile.bat -augment -profileName profile_name -templatePath fully_qualified_template_path
wasprofile.bat -unaugment -profileName profile_name
For specific examples of creating a profile, see the Example: Using commands to create profiles section.
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.
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.
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.
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.
If you have enabled security or changed the default JMX connector type, you cannot federate with the wasprofile command. Use the addNode command instead.
Do not use this parameter when using the -startingPort parameter.
-profilePath C:\IBM\WebSphere\AppServer\profiles\profile01
If the fully qualified path contains spaces, enclose
the value in quotation marks.
Do not use this parameter with the -portsFile parameter.
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:
-templatePath /usr/WebSphere/AppServer/profileTemplates/default -templatePath default
-templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/default -templatePath default
-templatePath C:\Program Files\IBM\WebSphere\AppServer\profileTemplates\default -templatePath default
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.
See WASService command for more information about Windows services.
Use cases are a description of common tasks for which the tool is used.
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.
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.
Example
wasprofile.sh -create
-profileName shasti
-profilePath ~/shasti/WebSphere
-templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/dmgr
-cellName shaix1
-hostName myhost
-nodeName dmgr1
-startingPort 12000
chown -R shasti ~/shasti/WebSphere
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
wasprofile.sh -delete
-profileName shasti
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
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
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
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 ...
<?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.
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
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
wasprofile.bat -create -profileName shasti -profilePath profile_root -templatePath template_path -nodeName W2K03 -cellName W2K03_Cell01 -hostName planetnt -startingPort 20002
startServer.sh server1 -profileName Profile02
netstat -a
http://hostname_or_IP_address:20003/ibm/console/
./wasprofile.sh -create -profileName profile01 -profilePath profile_root
chown -R user1 profile_root
chown -R user1 app_server_root/logs/wasprofile
mkdir app_server_root/logs/wasprofile
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
app_server_root/properties/fsdb app_server_root/properties/profileRegistry.xml
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.
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.
chmod -R 777 app_server_root/profiles
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.
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.
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.
chown -R wsdemo profile_root
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.
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
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
Federate a custom profile to customize the profile with the deployment manager.
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
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
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
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