Tuesday, February 14, 2012

DB2 on zOS issues:

Issue:

When you have a websphere cluster which uses DB2 on z/OS as its datastore and due to a machine upgrade happening the subsystem ID for this DB2 needs to be changed (say for example DB1P to DBP1.)

Issue Fix:

Change the following files,

wkplc_comp.properties
wkplc_dbtype.properties
icm.properties

on all nodes in the cluster and then change the data source for the cluster in the deployment manager.

Tuesday, January 31, 2012

Data Source Configuration Issue:

Environment:
WPS6.2
WAS6.1

Issue:
While trying 'test connection' on a data source,it results in following error:

The test connection operation failed for data source SCA Application Bus ME data source on server nodeagent at node localhostNode01 with the following exception: java.sql.SQLException: [jcc][t4][10205][11234][3.52.110] Null userid is not supported. ERRORCODE=-4461, SQLSTATE=42815DSRA0010E: SQL State = 42815, Error Code = -4,461. View JVM logs for further details.

Solution:
Set the Component Managed Authentication Alias to the proper level.
This alias is used for database authentication at run time.
The Component-managed Authentication Alias is only used when the application resource reference is using res-auth = Application.

If your database (for example, Cloudscape) does not support user ID and password, then do not set the alias in the component-managed authentication alias or container-managed authentication alias fields. Otherwise, you see the warning message in the system log to indicate that the user and password are not valid properties. (This message is only a warning message; the data source is still created successfully.)

If you do not set an alias (component-managed or otherwise), and your database requires the user ID and password to get a connection, then you receive an exception during run time.

Thursday, November 24, 2011

SSL ERRORS WITH SAMPLE TRACE.

GSK_ERROR_BAD_CERT error configuring SSL between Plug-in and WebSphere Application Server V6.1:

Gsk Error Bad Cert

SAMPLE SCENARIO:

IHS Plugin SSL Trace

Tuesday, November 15, 2011

Using the bpeconfig.jacl script to configure Business ProcessChoreographer

Bpeconfig Script

Monday, November 14, 2011

Thread and Heap Dump


Thread and Heap Dump



Monday, September 26, 2011

WAS Admin Security Tips..

Verifying and testing administrative security

After your server is restarted in secure mode, you can test that security is
properly enabled. There are basic tests that you can perform:
_ Verify the form login. When using the Web-based Administrative Console, the
Web-based form login page that is displayed forces you to enter a user ID and
password. Only a user ID with administrative roles must be able to log in.
_ Verify that the Java Client Basic Authentication works by executing the
<WebSphere_home>\bin\dumpNameSpace.bat file.
A challenge login window must open. Although you might be able to click
Cancel, you must type any correct user ID and password that is defined in the
user account repository to test the security.
Be aware that the login panel for the Java client only opens if the
com.ibm.CORBA.loginSource property is set to prompt in the
sas.client.props file. Clicking Cancel works only if CosNaming security (see
3.4, “Naming service security: CosNaming roles” on page 64) allows read
access to everyone. These values are the default values when you installed
WebSphere.
Successfully running these basic tests indicates that the administrative security
is working correctly.

Stopping the application server
While the command to start the application server is still the same when
administrative security is enabled, stopping the server requires extra information.
You must specify a user ID with administrator role rights, or the primary
administrative user name specified in the user account repository and its
password, in the stopServer command:

<WebSphere_home>\bin\stopServer.bat <server_name> -username <userID>
-password <password>

For WebSphere Application Server running under a UNIX-based operating
system (OS), the previously mentioned command (the UNIX equivalent) carries a
serious security problem. Anyone who uses the ps -ef command while the
stopServer process is running can see the user ID and the password.
To avoid this problem:
1. If you are using the SOAP connection type (default) to stop the server, edit the
<WebSphere_home>\profiles\<profilePath>\properties\soap.client.props
file. Then, change the values of the following properties:

com.ibm.SOAP.securityEnabled=true
com.ibm.SOAP.loginUserid=<user ID>
com.ibm.SOAP.loginPassword=<password>

 
Again, the user ID <user ID>, with its password <password>, is the user ID
with administrator role rights or the primary administrative user name defined
in the user account repository.

2. Encode the com.ibm.SOAP.loginPassword property value as follows:
<WebSphere_home>\bin\PropFilePasswordEncoder.bat soap.client.props
com.ibm.SOAP.loginPassword


Examine the result and remove the soap.client.props.bak backup file, that
was created by the previous command. This file contains the unencrypted
password.

3. Make sure that proper file access rights for sensitive WebSphere Application
Server files, such as properties files and executable files, are set. At a
minimum, ensure that permissions prevent general users from accessing
these files. WebSphere administrators must be the only users that are
granted access to these files.

For optimal security, access to the entire
WebSphere directory tree must be removed for general users.
Whether administrative security is enabled or disabled, stop the WebSphere
Application Server as follows:
<WebSphere_home>\bin\stopServer.bat <server_name>



Disabling administrative security

Disable administrative security by using the command line.

To disable administrative security:

1.    At the command prompt, type the following command:

<WebSphere_home>\bin\wsadmin.bat -conntype NONE

2.    When the system command prompt redisplays, type the following command:

Securityoff

3. Type quit and restart the application server.

                                    OR

You can disable administrative security by directly editing the security.xml file in



<WebSphere_home>\profiles\<profilePath>\config\cells\<cell_name>\.

Change the security attribute enabled="true" to enabled="false".

#############################################################################################