Websphere directory structure within a profile

WebSphere uses profiles to determine the makeup of an application server. A WebSphere profile determines and controls the configuration of the actual application server. Most of the WebSphere Administration activities are centred on the profile and so understanding the underlying websphere directory structure within a profile is very important. The table below outlines the key folders and subfolders of a profile.
bin -> Contains the scripts used to administer your application server from a command line. Most of the scripts in the <was_profile_root> call other scripts located in the <was_root> folder.

config -> Contains the XML files which persist all the configurations made through the administrative console. We will cover these in detail later in this chapter.

firststeps-> As we have seen in Chapter 1, this folder contains the first steps console that is available when using graphical installations. Not important for post-install administration.

installableApps -> Contains default WebSphere applications which can be installed depending on the type of installation options used in the WebSphere install process. This is where defaultApplication.ear will be located which contains snoop

installedApps -> Contains the on-disk structure of the deployed applications as installed into WAS. This is a very important folder and is used extensively in administrative support of applications.
logs -> Contains the log files pertinent to WAS runtime. Most debugging of administrative and application issues are achieved through the help of the logs contained in this folder.
properties -> Contains key properties files which contain settings which can be used to change behaviours, for example, security for the wsadmin tool.
samples     -> Contains some portions of the sample applicationss required for runtime components—if samples have been installed.
temp  ->    Contains runtime temporary files. For example, if JSPs within applications are converted to Java classes at runtime, then the temp folder will contain these Java classes. tranlog    If an application contains distributed transactions then the tranlog folder will contain transactional logs which can be used for rollback.
wstemp -> Used by WebSphere during the deployment of applications as a temporary staging area and also contains in-transit configurations before console changes are saved.

XML configuration files
The entire WebSphere configuration is saved and persisted to XML files. When we use the Admin console to configure WebSphere, certain XML files are updated with the appropriate settings relating to each type of configuration. It is important that an administrator understands key XML files and understand what they are used for. When there are configuration or runtime issues, knowing these files and their locations can help with problem-solving. Below is a list of the most important configuration files that a WebSphere administrator should be aware of. It must be noted that some files exist more than once in different scopes, that is, cell level, node  level, and server level.

Cell level XML files

Below is a list of the key XML configuration files found at the scope of cell level.

•    resources.xml
°    Defines operating cell scope environmental resources, including JDBC, JMS, JavaMail, URL end point configuration, and so on.
•    security.xml
°    Contains security data , including all user ID and password information.
•    virtualhosts.xml
°    Contains virtual host and Multipurpose Internet Mail
Extensions (MIME)-type configurations.
•    variables.xml
°    Contains cell level WebSphere variables
•    admin-authz.xml
°    Contains the roles set for administration of the
Admin console.

°    /apps/was7/profiles/appsrv01/config/cells/<cell_name>/
•    wimconfig.xml
°    Contains the federated repository configurations for
global security
°    <was_profile_root>config/cells/<cell_name>/wim/config/
•    profileRegistry.xml
°    Contains a list of profiles and profile configuration data

Node level XML files
Below is a list of the key XML configuration files found at the scope of node level.

Located in:    /<was_profile_root>/config/cells/<cell_name>/nodes/<node_name>/

•    variables.xml
°    Contains node level WebSphere variables
•    resources.xml
°    Defines node scope environmental resources, including JDBC, JMS, JavaMail, URL end point configuration, and so on
•    namestore.xml
°    Provides persistent JNDI namespace binding data
•    serverindex.xml
°    Specifies all the ports used by servers on this node

Server level XML files
Below is a list of the key XML configuration files found at the scope of server level.

Located in: /<was_profile_root>/config/cells/<cell_name>nodes/<node_name>/servers/<server_name>/

•    variables.xml
°    Contains server level variables
•    server.xml
°    Contains application server configuration data
•    resources.xml
°    Contains the configuration of resources, such as, JDBC, JMS, JavaMail, and URL end points at server scope

Important properties files

As an administrator, it is important that you understand the soap.client.props and sas.client.props files located in the <was_profile_root>/properties folder. These files are required to be edited when you enable global security. If you enable security for a WebSphere Application Server cell, you will have to manually enter in the username and password every time you run the wsadmin tool. By editing the sas. client.props and the soap.client.props files, you can specify the username and password you have configured for global security so you are not prompted to enter the username and password every time you run administrative scripts.

The soap.client.props file
When global security is enabled in the cell and you use the wsadmin tool with the SOAP protocol (SOAP is the default connector protocol, more soap examples can be found here), you will need to update the following properties in the soap.client.props file with the appropriate values as shown below so that the wsadmin tool does not prompt for a username and password.

com.ibm.SOAP.securityEnabled=<true> com.ibm.SOAP.loginUserid=<username> com.ibm.SOAP.loginPassword=<password> Optionally, set the following property: com.ibm.SOAP.loginSource=none

The sas.client.props file
When global security is enabled in the cell and you change wsadmin to use a Remote Method Invocation (RMI) connector when using wsadmin (RMI is not the default protocol), you need to set the following properties in the sas.client.props file with the appropriate values as shown below so that the wsadmin tool does not prompt for a username and password.

com.ibm.CORBA.loginUserid=
com.ibm.CORBA.loginPassword=
Also, set the following property:
com.ibm.CORBA.loginSource=properties

The default value for this property is prompt in the sas.client.props file.

Logs
The WebSphere application server uses logs to log what is happening during server runtime. Administrators can use the logs to determine application server runtime status. Logs are also very useful during problem determination when there are problems with WebSphere. The main log folder is the application server’s logs directory which is found in the <was_profile_root> folder. Below is a screenshot of a typical logs directory.

In the screenshot above, you will see that the application server is located in a profile named appsrv01, which is located in the profiles directory. The logs folder is located in the /apps/was7/profiles/appsrv01 folder which is referred to as <was_profile_root>. The logs folder will always be here unless you override log locations in the Administrative console.

JVM logs
The main logs for a WebSphere Application Server are contained in a folder with the same name as the application server. In our example, our application is called server1, so the log files are contained in the server1 directory located within the logs directory, which is within the <was_profile_root> folder. Below is an example of the logs that are typically generated by a WebSphere Application Server.

You can see in the screenshot above that it is typical for a running server to have generated several logs during server runtime. Not all the logs will exist immediately; some are spawned when certain conditions occur. The table below explains what each log is for and what you might expect to find in the log

native_stderr.log,
native_stdout.log
stdout and stderr streams are redirected to log files at application server startup, which contain text written to the stdout and stderr streams by native modules, that is, Linux Modules, and so on. In normal error-free operations, these logs files are typically empty.

startServer.log    This log file is named startServer.log and is created in your logs directory when the server starts up. This log is very useful to determine JVM parameters used in the start-up process, the server’s process id, and also the date and time in which the server was started. If there are errors experienced during the start-up (for example, security configuration errors where the application server cannot start), then log information will exist for problem determination.
stopServer.log    This file logs the fact that the server was stopped via a command line. If the server has trouble stopping, then Java stack traces will be written to the log which can be used in determining why a given application server failed to stop.
SystemErr.log    This log file contains Java exceptions and stack traces.

An empty SystemErr.log file does not necessarily indicate a successfully running application server JVM. You may need to consult the other logs in this directory.

SystemOut.log    This log file contains messages as generated by the JVM during runtime. Some messages are informational, some are warnings or status updates. Applications can be configured to write to the log and so it is very common for the SystemOut.log to be your first port of call in application debugging.
Both this log file and the SystemErr.log file should be checked after starting an application server to confirm that both the server and applications have started correctly.

SystemOut_<date_time_stamp>. log

This filename style is an example of a log file roll-over due to the log being full. WebSphere can be configured to roll over in different style and will be covered later in the chapter.

<server_name>.pid    This file contains the process id of the server. In Linux, this is the actual process id assigned to the JVM process.

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.