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

Using the bpeconfig.jacl script to configure Business ProcessChoreographer

Bpeconfig Script

Thread and Heap Dump

Thread and Heap Dump

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

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

Installing WAS Silently.

Environment:
Windows XP

Sample Syntax:

<WAS_Extract_Locaton>>install.exe -options "<Responsefile_Location>" -silent -log # !<LogFile_Location> @ALL

Example:

C:\Downloads\WAS7\WAS>install.exe -options "C:\Downloads\WAS7\WAS\tempresponsefile.txt" -silent -log # !C:\Downloads\WAS7\WAS\log.txt  @ALL

RESPONSE FILE SAMPLE

Using serviceDeploy

An alternate option for installing business integration applications uses the serviceDeploy command. This command prepares an EAR file from a JAR or zip file that contains service components. For example consider an application "sampleOrderBPELApp", the orderProcess business process (service component) is packaged in a JAR file called sampleOrderBPELApp.jar. The syntax for the command is as follows:

serviceDeploy sampleOrderBPELApp.jar -keep

The service components are taken from the JAR file and an installable EAR file named sampleOrderBPELApp.ear is generated. The EAR file is then deployed to the application server. The -keep option saves the temporary files generated during deployment, which may be useful for troubleshooting. There is another command-line option, -noJ2EEdeploy, which skips the deployment of the application to the application server. You should consider this option if you need to only generate the EAR file and do not wish to deploy the application immediately.

BusinessSpace related DB2 issue..

When trying to access "BusinessSpace" on process server,encountered the following error during log-on:

500: DB2 SQL Error: SQLCODE=-204, SQLSTATE=42704, SQLERRMC=IBMBUSSP.USER_DATA_T, DRIVER=3.52.110

Environment:

WPS 6.2.0.0
WAS 6.1.0.21
WINXP SP2


Even though couldn't find any solution (yet!) for my particular environment,Found this interesting bit for zOS.

Error description

    When an XA client connects to a DB2 for zOS server through a
    DB2 Connect Server that has the Concentrator turned on,
    sometimes the client will get the error SQL0204 ("<name>" is an
    undefined name). This happens because the DB2 Connect
    Concentrator tries to reuse an existing connection when
    switching applications, but uses the wrong schema to access
    database objects on the server.
    If this APAR fix is not installed, the XA aplications
    connecting to zOS through the DB2 Connect server may terminate
    abnormally with the SQL0204 error.
    For example, a JCC Type 4 client may see an error that looks
    like this:
    JDBC Driver = DB2 Universal JDBC Driver Provider Type 4 (JCC4)
    SQLException messages returned by JDBC/JCC drivers.
    SQLCODE = -204
    SQLSTATE = 42704
    Error Message = DB2 SQL Error: SQLCODE=-204, SQLSTATE=42704,
    SQLERRMC=ECOM_ROLE_
    ACCOUNT_MANAGER_XA.MVSDB, DRIVER=3.51.74
    SQLException messages returned by JCC drivers.
    --------------- SQLCA ---------------
    Error code: -204
    SQLERRMC: ECOM_ROLE_ACCOUNT_MANAGER_XA.MVSDB
    token 0: ECOM_ROLE_ACCOUNT_MANAGER_XA.MVSDB
    SQLERRP: DSNXOTL
    SQLERRD(1): -500
    SQLERRD(2): 0
    SQLERRD(3): 0
    SQLERRD(4): -1
    SQLERRD(5): 0
    SQLERRD(6): 0
    ... (etc.)

Local fix

    Turn off the Concentrator on the DB2 Connect server.

BTW:
To use the connection concentrator, the following APAR must be applied to DB2 for OS/390 and z/OS Version 6.1:

     APAR PQ33473

WSVR0009E: Unable to start the CoordinatorComponentImpl

Environment:
WPS 6.2.0.0
WAS 6.1.0.21
WINXP SP2


Application Server or Deployment manager may fail to start up with WSVR0009E: Unable to start the CoordinatorComponentImpl.

Problem(Abstract)

IBM® WebSphere® Application Server V6.0 is unable to start either Deployment Manager or Application Server with exception WSVR0009E: Error occurred during startup
com.ibm.ws.exception.RuntimeError: com.ibm.ws.exception.RuntimeError: Unable to start the CoordinatorComponentImpl

Symptom

The exception seen in the JVM logs is:
[1/11/08 15:53:18:450 CST] 0000000a WsServerImpl E WSVR0009E: Error occurred during startup
com.ibm.ws.exception.RuntimeError: com.ibm.ws.exception.RuntimeError: Unable to start the CoordinatorComponentImpl
at com.ibm.ws.runtime.WsServerImpl.bootServerContainer(WsServerImpl.java:194)
at com.ibm.ws.runtime.WsServerImpl.start(WsServerImpl.java:133)
at com.ibm.ws.runtime.WsServerImpl.main(WsServerImpl.java:387)
at com.ibm.ws.runtime.WsServer.main(WsServer.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Caused by: com.ibm.ws.exception.RuntimeError: Unable to start the CoordinatorComponentImpl
at com.ibm.ws.hamanager.runtime.CoordinatorComponentImpl.start(CoordinatorComponentImpl.java:245)
at com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:820)
at com.ibm.ws.runtime.component.ContainerImpl.start(ContainerImpl.java:649)
at com.ibm.ws.runtime.component.ServerImpl.start(ServerImpl.java:444)
Caused by: com.ibm.wsspi.hamanager.HAInternalStateException: failure creating the Coordinator
at com.ibm.ws.hamanager.coordinator.impl.CoordinatorImpl.<init>(CoordinatorImpl.java:314)
at com.ibm.ws.hamanager.coordinator.corestack.CoreStackFactoryImpl.createDefaultCoreStack(CoreStackFactoryImpl.java:82)
at com.ibm.ws.hamanager.runtime.CoordinatorComponentImpl.start(CoordinatorComponentImpl.java:221)
Caused by: java.lang.AbstractMethodError: com/ibm/rmm/ptl/tchan/transmitter/PTransmitter.init
at com.ibm.rmm.mtl.transmitter.MTransmitter.<init>(MTransmitter.java:268)
at com.ibm.rmm.mtl.transmitter.MTransmitter.getInstance(MTransmitter.java:374)
at com.ibm.rmm.mtl.transmitter.MTransmitter.getInstance(MTransmitter.java:315)
at com.ibm.htmt.rmm.RMM.getInstance(RMM.java:119)
at com.ibm.htmt.rmm.RMM.getInstance(RMM.java:177)
at com.ibm.ws.dcs.vri.transportAdapter.rmmImpl.rmmAdapter.RmmAdapter.<init>(RmmAdapter.java:216)
at com.ibm.ws.dcs.vri.transportAdapter.rmmImpl.rmmAdapter.MbuRmmAdapter.<init>(MbuRmmAdapter.java:69)
at com.ibm.ws.dcs.vri.transportAdapter.rmmImpl.rmmAdapter.CFRmmAdapter.<init>(CFRmmAdapter.java:40)
at com.ibm.ws.dcs.vri.transportAdapter.rmmImpl.rmmAdapter.RmmAdapter.getInstance(RmmAdapter.java:131)
at com.ibm.ws.dcs.vri.transportAdapter.TransportAdapter.getInstance(TransportAdapter.java:151)
at com.ibm.ws.dcs.common.impl.DCSCoreStackImpl.<init>(DCSCoreStackImpl.java:162)

Resolving the problem

This problem occurs if you replace the rmm jar file that comes with WebSphere Application Server. Please check if there are any duplicate RMM jar files in the <install_root>\lib directory. If RMM.jar from any other location is placed in the <install_root>\lib directory, this error might occur.

Check the <install_root>\lib directory for the problematic WebSphere install and remove any duplicate RMM.jar files that could have been copied over (either to achieve something or unintentionally). The rmm jar file shipped and used by WebSphere Application Server is: <installRoot>\lib\rmm-pgm.jar

Changes to this jar file may only be made by the updateInstaller as part of the ifix/fixpack install process. Overwriting this jar file with another can be highly problematic. Other products must not overwrite the WebSphere/lib jar and if another version is required (for other products like WebSphere MQSeries®), access must be managed through classpath/classloader mechanisms.

webserver

Enabling SSL between browser and webserver.
(Self-signed certificate)

 
1) Open iKeyman 

2) Create Keydatabase 

3) create a self signed certificate
4)Open the httpd.conf configuration file from the /opt/IBM/HTTPServer/conf directory, and then edit it as follows:

    

    LoadModule  ibm_ssl_module   modules/mod_ibm_ssl.so
    Listen 0.0.0.0:443
    <VirtualHost  *:443>
    ServerName  <server_name>
    #DocumentRoot C:\IBM\HTTPServer\htdocs
    SSLEnable
    #SSLClientAuth  required
    </VirtualHost>
    SSLDisable
    Keyfile "<path_to_key_file>"
    SSLStashFile "<path_to_stash_file>"

    
where <path_to_key_file> represents the file path to the KDB file and <path_to_stash_file> represents the file path to associated stash file.

For example, the paths may look like this:

         Keyfile "C:\IBM\HTTPServer\Plugins\config\<web_server>\plugin-key.kdb"
    SSLStashFile "C:\IBM\HTTPServer\Plugins\config\<web_server>\plugin-key.sth"

WPS TOPOLOGY DEPLYOMENT ISSUE(S) ...Cont...

Environment:

WPS 6.2.0
WAS 6.1.0.21
Win XP SP3

DB2v9.7

Problem(Abstract)

A second deployment environment cannot be generated through the Network Deployment wizard in the administrative console or command line scripting.

Cause

The error occurs because one of the deployment environment components (CEI) requires its own database. If the database is already being used by another CEI component in a previously generated deployment environment, the second deployment environment will not be generated.

 

 

 

 

 

 

 

 

 

 

Diagnosing the problem

This following error is displayed in the log and shown in the administrative console:

CWLDB9014E: The configuration of component WBI_CEI failed. Reason java.lang.Exception: java.lang.Exception: com.ibm.db2.jcc.b.SqlException:
DB2 SQL error: SQLCODE: -601, SQLSTATE: 42710, SQLERRMC: EVENT_BP_4K_DATA;BUFFERPOOL.
CWLDB9016E: The generation for deployment environment drs_esb2 failed.
Reason: CWLDB9014E: The configuration of component WBI_CEI failed. Reason java.lang.Exception: java.lang.Exception: com.ibm.db2.jcc.b.SqlException:
DB2 SQL error: SQLCODE: -601, SQLSTATE: 42710, SQLERRMC: EVENT_BP_4K_DATA;BUFFERPOOL.. If in doubt, discard the changes and do not save the failed configuration to the master repository.

 

Tried Doing..

We'd tried to re-install the whole DB2 database on the system.But even after the DB2 was reinstalled the same issue persisted.The issue was not with the deployment generation it was with the database.Now here is what happened in our particular case.Once a successful deployment is generated the database schema's and tables are created as per the scripts.On windows platform they are reflected on the local file system C:\DB2\...If you(mostly in development environment ) decide to altogether remove the(successfully generated) deployment environment and delete the corresponding DB2 tables in the database,Apart from 'dropping' the tables also manually delete the DB2 folder in the file system(eg C:\DB2\..).This will make sure that the database is in the 'consistent' state.

Resolving the problem

Do not generate a second deployment environment with the same database used by the existing deployment environment. 

If you need to re-install the Database make sure all the references of that database are manually deleted from the file system.

 

WPS TOPOLOGY DEPLYOMENT ISSUE(S)

Environment

WPS 6.2.0
WAS 6.1.0.21
Win XP SP3

 

Problem(Abstract)

A second deployment environment cannot be generated through the Network Deployment wizard in the administrative console or command line scripting.

Cause

The error occurs because one of the deployment environment components (CEI) requires its own database. If the database is already being used by another CEI component in a previously generated deployment environment, the second deployment environment will not be generated.

Diagnosing the problem

This following error is displayed in the log and shown in the administrative console:

CWLDB9014E: The configuration of component WBI_CEI failed. Reason java.lang.Exception: java.lang.Exception: com.ibm.db2.jcc.b.SqlException:
DB2 SQL error: SQLCODE: -601, SQLSTATE: 42710, SQLERRMC: EVENT_BP_4K_DATA;BUFFERPOOL.
CWLDB9016E: The generation for deployment environment drs_esb2 failed.
Reason: CWLDB9014E: The configuration of component WBI_CEI failed. Reason java.lang.Exception: java.lang.Exception: com.ibm.db2.jcc.b.SqlException:
DB2 SQL error: SQLCODE: -601, SQLSTATE: 42710, SQLERRMC: EVENT_BP_4K_DATA;BUFFERPOOL.. If in doubt, discard the changes and do not save the failed configuration to the master repository.

Resolving the problem

Do not generate a second deployment environment with the same database used by the existing deployment environment.

Unable to start/stop webserver from Dmgr console.

Problem: Unable to start/stop webserver from Dmgr console.



Environment:

Windows XP professional sp3
WASv7.0 ND
HTTPServer6.0



Scenario : While trying to start or stop the webserver from the dmgr console exception was encountered:

"unable to start adminnode04/webserver1" 
"look under nodeagent logs"


Systemout log displayed something like:

"exception thrown while starting webserver..launchprocess failed...modelmbean not found"

 

While playing around the console while trying to access the configuration file at:
Web servers > webserver1 > ${WEB_INSTALL_ROOT}/conf/httpd.conf

it was unable to be found.

Ultimately a more detailed analysis proved that the entire "conf" and "bin" directories were missing from the {WEB_INSTALL_ROOT} dir.

After making sure that the {WEB_INSTALL_ROOT}  has these three directories:
1.Plugins
2.conf
3.bin

The problem was fixed.

WebSphere Addnode fails with connection timeout during federation

Environment:
1.)StandAlone App server on Windows
2.)DMGR on Linux
3.)WAS 7.0

While trying to federate a standalone node from Windows to Linux using 'Addnode' command from the appsrv profile of Windows,It was failing with the following error:

ADMU0009I: Successfully connected to Deployment Manager Server:
node.name.extension:8879
ADMU0505I: Servers found in configuration:
ADMU0506I: Server name: server1
ADMU2010I: Stopping all server processes for node serverNameNode01
ADMU0512I: Server server1 cannot be reached. It appears to be stopped.
ADMU0512I: Server server1 cannot be reached. It appears to be stopped.
ADMU0024I: Deleting the old backup directory.
ADMU0015I: Backing up the original cell repository.
ADMU0012I: Creating Node Agent configuration for node: serverNameNode01
ADMU0014I: Adding node serverNameNode01 configuration to cell:serverNameCell01
ADMU0027E: An error occurred during federation Connection timed out: connect;
rolling back to original configuration.
ADMU0211I: Error details may be seen in the file:
C:\IBM\WebSphere\AppServer\profiles\AppSrv03\logs\addNode.log
ADMU0026I: An error occurred during federation; rolling back to original
configuration.
ADMU0113E: Program exiting with error:
com.ibm.websphere.management.exception.AdminException:
com.ibm.websphere.management.filetransfer.client.TransferFailedException:
Upload retry limit exceeded for file
C:\DOCUME~1\Admin\LOCALS~1\Temp\2\serverNameNode01__1751832905898309717.car
Exception: java.net.ConnectException: Connection timed out: connect,
resulting from: java.net.ConnectException: Connection timed out:
connect
ADMU1211I: To obtain a full trace of the failure, use the -trace option.
ADMU0211I: Error details may be seen in the file:
C:\IBM\WebSphere\wp_profile\logs\addNode.log
Target finished: action-cluster-node-federation
Target finished: cluster-node-config-pre-federation

How did I resolve?:
---------------------
While googling found a useful link,
http://www-01.ibm.com/support/docview.wss?uid=swg21395448

Based on that made sure,There are'nt multiple IP addresses on the Linux box (Where my DMGR is hosted)

So far,I was trying to federate using IP address,Something like,
addnode 192.168.1.7 8879 -includeapps

That was the mistake,With addnode use only 'hostname' when DMGR resides on another physical mistake.
Added '192.168.1.7' to my hosts file on windows.Something like:

192.168.1.7 fedex   (File located: C:\WINDOWS\system32\drivers\etc\hosts)

That was it,This time I started using hostname Instead of IP

addnode fedex 8879 -includeapps