| WAS Version | SOAP PORT |
| Version 8 Deployment Manager | 8879 |
| Version 8 AppServer | 8880 |
| Version 8 Node agent | 8878 |
| Version 7 Deployment Manager | 8879 |
| Version 7 AppServer | 8880 |
| Version 7 Node agent | 8878 |
| Version 6.1 Deployment Manager | 8879 |
| Version 6.1 AppServer | 8880 |
| Version 6.1 Node agent | 8879 |
| Version 6.0 Deployment Manager | 8879 |
| Version 6.0 AppServer | 8880 |
| Version 6.0 Node Agent | 8878 |
| Version 5.0 Deployment Manager | 8879 |
| Version 5.0 Node Agent | 8880 |
| Version 5.0 AppServer | 8878 |
SOAP PORT Details of WebSphere Application Server
Baisc construct for MQ messaging - A Practical Approach.
This example is a simple demonstration for understanding how MQ transfer messages between two queue managers and the minimum required MQ components for the same.
Kindly Share/Like/Follow the page if you like this article.
Below are the steps involved in this example.Source queue manager
------------------------------
1.) Create source queue manager.
2.) Start source queue manager.
3.) Connect to source queue manager using runmqsc command.
4.) Create a listener in source queue manager.
5.) Create transmission queue in source queue manager.
6.) Create a remote queue in source queue manager.
7.) Create a sender channel in source queue manager.
8.) Quit MQSC
Destination queue manager
-------------------------------------
1.) Create destination queue manager.
2.) Start destination queue manager.
3.) Connect to destination queue manager using runmqsc command.
4.) Create a listener in destination queue manager.
5.) Create a receiver channel in destination queue manager.
6.) Create a local queue in destination queue manager.
7.) Quit MQSC.
Restart Source & Destination Queue Managers.
-------------------------------------------------------------
1.) Stop source queue manager.
2.) Stop destination queue manager.
3.) Start source queue manager.
3.a.) Make sure that the listener started for source queue manager , if not start the listener.
4.) start destination queue manager.
4.a.) Make sure that the listener started for destination queue manager, if not start the listener.
5.) Connect to source queue manager using runmqsc command.
6.) Start sender channel on source queue manager.
7.) Check the channel status of both queue managers and make sure that both channels are running..
8.) Quit MQSC.
Testing
----------
1.) Put a message in remote queue of source queue manager.
2.) browse/get messages from local queue of destination queue manager.
Now let us implement above steps in a test server.
A.) Source queue manager (MqM1)
---------------------------------------------
1.) Create source queue manager MqM1
[root@myhost mqm]# crtmqm MqM1
WebSphere MQ queue manager created.
Directory '/var/mqm/qmgrs/MqM1' created.
Creating or replacing default objects for MqM1.
Default objects statistics : 65 created. 0 replaced. 0 failed.
Completing setup.
Setup completed.
2.) Start source queue manager MqM1
[root@myhost mqm]# strmqm MqM1
WebSphere MQ queue manager 'MqM1' starting.
5 log records accessed on queue manager 'MqM1' during the log replay phase.
Log replay for queue manager 'MqM1' complete.
Transaction manager state recovered for queue manager 'MqM1'.
WebSphere MQ queue manager 'MqM1' started.
3.) Connect to source queue manager MqM1 using runmqsc command.
[root@myhost mqm]# runmqsc MqM1
5724-H72 (C) Copyright IBM Corp. 1994, 2009. ALL RIGHTS RESERVED.
Starting MQSC for queue manager MqM1.
4.) Create a listener in source queue manager MqM1.
define listener ('MqM1.LSNR') TRPTYPE( TCP ) PORT (1486)
1 : define listener ('MqM1.LSNR') TRPTYPE( TCP ) PORT (1486)
AMQ8626: WebSphere MQ listener created.
5.) Create transmition queue in source queue manager.
define qlocal ('TR1.MqM1.Q1') USAGE (XMITQ)
2 : define qlocal ('TR1.MqM1.Q1') USAGE (XMITQ)
AMQ8006: WebSphere MQ queue created.
6.) Create a remote queue in source queue manager.
define qremote ('RMT.MqM1.Q1') XMITQ ('TR1.MqM1.Q1') RQMNAME('MqM2') RNAME('LOC.MqM2.Q1')
3 : define qremote ('RMT.MqM1.Q1') XMITQ ('TR1.MqM1.Q1') RQMNAME(MqM2) RNAME('LOC.MqM2.Q1')
AMQ8006: WebSphere MQ queue created.
Points to be noted:-
XMITQ :- Should be the same name mentioned while creating transmission queue in step A.5
RQMNAME :- Specify the same name mentioned while creating destination queue manager B.1
7.) Create a sender channel in source queue manager.
define channel ('MqM1.SNDR') CHLTYPE(SDR) CONNAME('localhost(1487)') XMITQ('TR1.MqM1.Q1')
4 : define channel ('MqM1.SNDR') CHLTYPE(SDR) CONNAME('localhost(1487)') XMITQ('TR1.MqM1.Q1')
AMQ8014: WebSphere MQ channel created.
Points to be noted:-
XMITQ :- Should be the same name mentioned while creating transmission queue in step A.5
CONNAME:- Specify the hostname/ipaddress and port number of the remote queue manager
8.) Quit MQSC
end
B.) Destination queue manager (MqM2)
----------------------------------------------------
1.) Create destination queue manager MqM2
[root@myhost mqm]# crtmqm MqM2
WebSphere MQ queue manager created.
Directory '/var/mqm/qmgrs/MqM2' created.
Creating or replacing default objects for MqM2.
Default objects statistics : 65 created. 0 replaced. 0 failed.
Completing setup.
Setup completed.
2.) Start destination queue manager MqM2
[root@myhost mqm]# strmqm MqM2
WebSphere MQ queue manager 'MqM2' starting.
5 log records accessed on queue manager 'MqM2' during the log replay phase.
Log replay for queue manager 'MqM2' complete.
Transaction manager state recovered for queue manager 'MqM2'.
WebSphere MQ queue manager 'MqM2' started.
3.) Connect to destination queue manager MqM2 using runmqsc command.
[root@myhost mqm]# runmqsc MqM2
5724-H72 (C) Copyright IBM Corp. 1994, 2009. ALL RIGHTS RESERVED.
Starting MQSC for queue manager MqM2.
4.) Create a listener in destination queue manager.
define listener ('MqM2.LSNR') TRPTYPE( TCP ) PORT (1487)
1 : define listener ('MqM2.LSNR') TRPTYPE( TCP ) PORT (1487)
AMQ8626: WebSphere MQ listener created.
5.) Create a receiver channel in destination queue manager.
define channel ('MqM1.SNDR') CHLTYPE(RCVR)
2 : define channel ('MqM1.SNDR') CHLTYPE(RCVR)
AMQ8014: WebSphere MQ channel created.
Points to be noted:-
Channel name should be the same name mentioned while creating channel in step A.7
6.) Create a local queue in destination queue manager.
define qlocal ('LOC.MqM2.Q1')
3 : define qlocal ('LOC.MqM2.Q1')
AMQ8006: WebSphere MQ queue created.
7.) Quit MQSC
end
C.) Restart Source and Destination Queue Managers
--------------------------------------------------------------------
1.) Stop source queue manager MqM1.
[root@myhost mqm]# endmqm MqM1
Quiesce request accepted. The queue manager will stop when all outstanding work is complete.
2.) Stop destination queue manager MqM2.
[root@myhost mqm]# endmqm MqM2
Quiesce request accepted. The queue manager will stop when all outstanding work is complete.
3.) Start source queue manager MqM1.
[root@myhost mqm]# strmqm MqM1
WebSphere MQ queue manager 'MqM1' starting.
5 log records accessed on queue manager 'MqM1' during the log replay phase.
Log replay for queue manager 'MqM1' complete.
Transaction manager state recovered for queue manager 'MqM1'.
WebSphere MQ queue manager 'MqM1' started.
4.) Start destination queue manager MqM2
[root@myhost mqm]# strmqm MqM2
WebSphere MQ queue manager 'MqM2' starting.
5 log records accessed on queue manager 'MqM2' during the log replay phase.
Log replay for queue manager 'MqM2' complete.
Transaction manager state recovered for queue manager 'MqM2'.
WebSphere MQ queue manager 'MqM2' started.
5.) Connect to source queue manager MqM1 using runmqsc command.
[root@myhost mqm]# runmqsc MqM1
5724-H72 (C) Copyright IBM Corp. 1994, 2009. ALL RIGHTS RESERVED.
Starting MQSC for queue manager MqM1.
6.) Start sender channel on source queue manager.
start channel ('MqM1.SNDR')
1 : start channel ('MqM1.SNDR')
AMQ8018: Start WebSphere MQ channel accepted.
Points to be noted:- Starting sender channel will start the receiver channel automatically.
Step D contains the steps to check channel status.
NOTE:-
Make sure that listeners are started, if not started use below steps to start listeners
1.) Connect to source queue manager MqM1 using runmqsc command.
[root@myhost mqm]# runmqsc MqM1
2.) Verify Listener 'MqM1.LSNR' is running in source queue manager MqM1
display lsstatus ('MqM1.LSNR')
2.a.) If the listener 'MqM1.LSNR' is not running start it by using below mqsc command
start listener ('MqM1.LSNR')
1 : start listener ('MqM1.LSNR')
AMQ8021: Request to start WebSphere MQ Listener accepted.
3.) Quit MQSC
end
4.) Connect to destination queue manager MqM2 using runmqsc command.
[root@myhost mqm]# runmqsc MqM2
5.) Verify listener 'MqM2.LSNR' is running in destination queue manager MqM2
5.a.) If the listener 'MqM2.LSNR' is not running start it by using below mqsc command
1 : start listener ('MqM1.LSNR')
AMQ8021: Request to start WebSphere MQ Listener accepted.
3.) Quit MQSC
end
4.) Connect to destination queue manager MqM2 using runmqsc command.
[root@myhost mqm]# runmqsc MqM2
5.) Verify listener 'MqM2.LSNR' is running in destination queue manager MqM2
5.a.) If the listener 'MqM2.LSNR' is not running start it by using below mqsc command
start listener ('MqM2.LSNR')
1 : start listener ('MqM2.LSNR')
AMQ8021: Request to start WebSphere MQ Listener accepted.
D.) Checking channel status of both Qmgr
------------------------------------------------------
1.)Connect to source queue manager MqM1 using runmqsc command.
[root@myhost mqm]# runmqsc MqM1
2.) Verify the channel 'MqM1.SNDR' status
display chstatus ('MqM1.SNDR')
1 : start listener ('MqM2.LSNR')
AMQ8021: Request to start WebSphere MQ Listener accepted.
D.) Checking channel status of both Qmgr
------------------------------------------------------
1.)Connect to source queue manager MqM1 using runmqsc command.
[root@myhost mqm]# runmqsc MqM1
2.) Verify the channel 'MqM1.SNDR' status
display chstatus ('MqM1.SNDR')
3.) Quit MQSC
4.) Connect to destination queue manager MqM2 using runmqsc command.
[root@myhost mqm]# runmqsc MqM2
5.) Verify the channel 'MqM1.SNDR' status
display chstatus ('MqM1.SNDR')
4.) Connect to destination queue manager MqM2 using runmqsc command.
[root@myhost mqm]# runmqsc MqM2
5.) Verify the channel 'MqM1.SNDR' status
display chstatus ('MqM1.SNDR')
E.) Testing the setup
---------------------------
Note:- If not already installed, Install the samples before proceeding with below test.
1.) Put a message in remote Queue of MqM1
/opt/mqm/samp/bin/amqsput RMT.MqM1.Q1 MqM1
Type below text
This is a test message from RMT.MqM1.Q1 (remote Queue) of MqM1 to LOC.MqM2.Q1 (Local Queue) of MqM2
Press ctrl+z
Eg:-
[root@myhost bin]# /opt/mqm/samp/bin/amqsput RMT.MqM1.Q1 MqM1
Sample AMQSPUT0 start
target queue is RMT.MqM1.Q1
This is a test message from RMT.MqM1.Q1 (remote Queue) of MqM1 to LOC.MqM2.Q1 (Local Queue) of MqM2
[2]+ Stopped /opt/mqm/samp/bin/amqsput RMT.MqM1.Q1 MqM1
[root@myhost bin]#
2.) Browse/get the message from Local Queue of MqM2.
Note:- If not already installed, Install the samples before proceeding with below test.
1.) Put a message in remote Queue of MqM1
/opt/mqm/samp/bin/amqsput RMT.MqM1.Q1 MqM1
Type below text
This is a test message from RMT.MqM1.Q1 (remote Queue) of MqM1 to LOC.MqM2.Q1 (Local Queue) of MqM2
Press ctrl+z
Eg:-
[root@myhost bin]# /opt/mqm/samp/bin/amqsput RMT.MqM1.Q1 MqM1
Sample AMQSPUT0 start
target queue is RMT.MqM1.Q1
This is a test message from RMT.MqM1.Q1 (remote Queue) of MqM1 to LOC.MqM2.Q1 (Local Queue) of MqM2
[2]+ Stopped /opt/mqm/samp/bin/amqsput RMT.MqM1.Q1 MqM1
[root@myhost bin]#
2.) Browse/get the message from Local Queue of MqM2.
------------------------------------------------------------------------
/opt/mqm/samp/bin/amqsget LOC.MqM2.Q1 MqM2
[root@myhost bin]# /opt/mqm/samp/bin/amqsget LOC.MqM2.Q1 MqM2
Sample AMQSGET0 start
message <This is a test message from RMT.MqM1.Q1 (remote Queue) of MqM1 to LOC.MqM2.Q1 (Local Queue) of MqM2>
/opt/mqm/samp/bin/amqsget LOC.MqM2.Q1 MqM2
[root@myhost bin]# /opt/mqm/samp/bin/amqsget LOC.MqM2.Q1 MqM2
Sample AMQSGET0 start
message <This is a test message from RMT.MqM1.Q1 (remote Queue) of MqM1 to LOC.MqM2.Q1 (Local Queue) of MqM2>
no more messages
Sample AMQSGET0 end
[root@myhost bin]#
Sample AMQSGET0 end
[root@myhost bin]#
Kindly Like/Follow the page if you like this article.
Request you to post your comments so that I can improve the content.
JVM heap size/properties by using wsadmin utillity
How to get JVM heap size/properties by using wsadmin utillity
------------------------------
1.)Type below command from wsadmin prompt
------------------------------
wsadmin>$AdminTask showJVMProperties {-serverName server1 -nodeName myhostNode01}
Output
--------
{classpath {}} {bootClasspath {}} {verboseModeClass false} {verboseModeGarbageCollection false} {verboseModeJNI false} {initialHeapSize 258} {maximumHeapSize 512} {runHProf false} {hprofArguments {}} {debugMode false} {debugArgs -agentlib:jdwp=transport=dt_so
OR
2.)Type below command from the OS prompt
------------------------------
[root@myhost bin]# ./wsadmin.sh -c '$AdminTask showJVMProperties {-serverName server1 -nodeName
myhostNode01}'
Output
--------
Realm/Cell Name: <default>
Username: root
Password:
WASX7209I: Connected to process "dmgr" on node myhostCellManager01 using SOAP connector; The type of process is: DeploymentManager
{classpath {}} {bootClasspath {}} {verboseModeClass false} {verboseModeGarbageCollection false} {verboseModeJNI false} {initialHeapSize 258} {maximumHeapSize 512} {runHProf false} {hprofArguments {}} {debugMode false} {debugArgs -agentlib:jdwp=transport=dt_so
OR
3.)Type below command from the OS prompt
------------------------------
[root@myhost bin]# ./wsadmin.sh -c "\$AdminTask showJVMProperties {-serverName server1 -nodeName
myhostNode01}"
Output
---------
Realm/Cell Name: <default>
Username: root
Password:
WASX7209I: Connected to process "dmgr" on node
myhostCellManager01 using SOAP connector; The type of process is: DeploymentManager
{classpath {}} {bootClasspath {}} {verboseModeClass false} {verboseModeGarbageCollection false} {verboseModeJNI false} {initialHeapSize 258} {maximumHeapSize 512} {runHProf false} {hprofArguments {}} {debugMode false} {debugArgs -agentlib:jdwp=transport=dt_so
Note:- Kindly note that the difference between second and third command is only the quotes,Commands
inside a double quotes require \ prefix for $ symbol.
------------------------------
1.)Type below command from wsadmin prompt
------------------------------
wsadmin>$AdminTask showJVMProperties {-serverName server1 -nodeName myhostNode01}
Output
--------
{classpath {}} {bootClasspath {}} {verboseModeClass false} {verboseModeGarbageCollection false} {verboseModeJNI false} {initialHeapSize 258} {maximumHeapSize 512} {runHProf false} {hprofArguments {}} {debugMode false} {debugArgs -agentlib:jdwp=transport=dt_so
OR
2.)Type below command from the OS prompt
------------------------------
[root@myhost bin]# ./wsadmin.sh -c '$AdminTask showJVMProperties {-serverName server1 -nodeName
myhostNode01}'
Output
--------
Realm/Cell Name: <default>
Username: root
Password:
WASX7209I: Connected to process "dmgr" on node myhostCellManager01 using SOAP connector; The type of process is: DeploymentManager
{classpath {}} {bootClasspath {}} {verboseModeClass false} {verboseModeGarbageCollection false} {verboseModeJNI false} {initialHeapSize 258} {maximumHeapSize 512} {runHProf false} {hprofArguments {}} {debugMode false} {debugArgs -agentlib:jdwp=transport=dt_so
OR
3.)Type below command from the OS prompt
------------------------------
[root@myhost bin]# ./wsadmin.sh -c "\$AdminTask showJVMProperties {-serverName server1 -nodeName
myhostNode01}"
Output
---------
Realm/Cell Name: <default>
Username: root
Password:
WASX7209I: Connected to process "dmgr" on node
myhostCellManager01 using SOAP connector; The type of process is: DeploymentManager
{classpath {}} {bootClasspath {}} {verboseModeClass false} {verboseModeGarbageCollection false} {verboseModeJNI false} {initialHeapSize 258} {maximumHeapSize 512} {runHProf false} {hprofArguments {}} {debugMode false} {debugArgs -agentlib:jdwp=transport=dt_so
Note:- Kindly note that the difference between second and third command is only the quotes,Commands
inside a double quotes require \ prefix for $ symbol.
WAS,IHS and Plugin log Details
Kindly post your comments and likes.
IBM Http Server Logs.
=================
Default log Directory
--------------------------
<IHS_Install_Root>/logs
access.log --> Contains the logs of all requests process by IBM Http Server.
error.log ----> Contains the errors and diagnostics information while processing the requests.
Plugin Logs.
========
Default Log Directory.
---------------------------
<Plugin_Install_Root>/logs
http_plugin.log ---> Contains the logs of plugin errors.
WebSphere Application Server Logs.
===========================
Default log Location.
--------------------------
<LOG_ROOT> = <WAS_Profile_Root>/logs/
<SERVER_LOG_ROOT> = <WAS_Profile_Root>/logs/
for Eg: If the WAS profile location is "/usr/IBM/WebSphere/AppSever/
<LOG_ROOT> = "/usr/IBM/WebSphere/AppSever/
<SERVER_LOG_ROOT> = "/usr/IBM/WebSphere/AppSever/
Trace Logs.
-------------
<SERVER_LOG_ROOT>/trace.log ---> Contains the trace information if the trace is enabled.
JVM Logs.
-----------
These logs are created by redirecting output and error streams of JVM into independent log files. The SystemOut.log file contains the logs used to monitor the health of running application server. SystemErr.log contains the exceptions. Every application servers and all of its application will have these two sets of files.
<SERVER_LOG_ROOT>\SystemOut.lo
<SERVER_LOG_ROOT>/
Process Logs.
----------------
The application server writes output and error streams of native processes into these logs.This may also contain the information related to problemes in native codes.
If the Verbose GC is enabled, GC informations are written into these logs.
<SERVER_LOG_ROOT>/
<SERVER_LOG_ROOT>/
IBM Service Logs.
--------------------
This is a binary log and it need Log Analyzer tool to analyze. There will be only one activity log for a single node ( for all JVMs and nodeagents).
IBM Service Log contains the information written to System.out by the Application Server run time as well as special messages that contain extended service information. These logs are mainly used by IBM service team for solving complex issues.
<LOG_ROOT>/activity.log
IBM Http Server Logs.
=================
Default log Directory
--------------------------
<IHS_Install_Root>/logs
access.log --> Contains the logs of all requests process by IBM Http Server.
error.log ----> Contains the errors and diagnostics information while processing the requests.
Plugin Logs.
========
Default Log Directory.
---------------------------
<Plugin_Install_Root>/logs
http_plugin.log ---> Contains the logs of plugin errors.
WebSphere Application Server Logs.
===========================
Default log Location.
--------------------------
<LOG_ROOT> = <WAS_Profile_Root>/logs/
<SERVER_LOG_ROOT> = <WAS_Profile_Root>/logs/
for Eg: If the WAS profile location is "/usr/IBM/WebSphere/AppSever/
<LOG_ROOT> = "/usr/IBM/WebSphere/AppSever/
<SERVER_LOG_ROOT> = "/usr/IBM/WebSphere/AppSever/
Trace Logs.
-------------
<SERVER_LOG_ROOT>/trace.log ---> Contains the trace information if the trace is enabled.
JVM Logs.
-----------
These logs are created by redirecting output and error streams of JVM into independent log files. The SystemOut.log file contains the logs used to monitor the health of running application server. SystemErr.log contains the exceptions. Every application servers and all of its application will have these two sets of files.
<SERVER_LOG_ROOT>\SystemOut.lo
<SERVER_LOG_ROOT>/
Process Logs.
----------------
The application server writes output and error streams of native processes into these logs.This may also contain the information related to problemes in native codes.
If the Verbose GC is enabled, GC informations are written into these logs.
<SERVER_LOG_ROOT>/
<SERVER_LOG_ROOT>/
IBM Service Logs.
--------------------
This is a binary log and it need Log Analyzer tool to analyze. There will be only one activity log for a single node ( for all JVMs and nodeagents).
IBM Service Log contains the information written to System.out by the Application Server run time as well as special messages that contain extended service information. These logs are mainly used by IBM service team for solving complex issues.
<LOG_ROOT>/activity.log
WAS Version Details
WAS Version Details
--------------------------
Let us check how a version number is formed..
For example: Let us take version 6.0.2.13
----6--------- 0 ------------2 -----------13---
version | release | refresh pack | fixpack
--------------------------
Let us check how a version number is formed..
For example: Let us take version 6.0.2.13
----6--------- 0 ------------2 -----------13---
version | release | refresh pack | fixpack
Encoding password value in soap.client.props file
Encoding password value in soap.client.props file
------------------------------
Change directory to 'properties' and then issue below command
../bin/
------------------------------
Change directory to 'properties' and then issue below command
../bin/
Certificate Management The ikeyman way ..
ikeyman Utility
The "ikeyman" is a GUI utility for certificate management. You might be already familiar with this utility but this is a gentle effort from my side to provide an insight about this utility for the folks who are not aware of it. normally this utility will be there in the ..../jre/bin directory of Java installed location.
The figures below are self explainable hence i am not giving a detailed explanation.
Note:- Kindly post your comments, Add ons and offcourse the "likes" in this blog
Creating a new key database
Open ikeyman and then select "New" from "Key Database File" Menu. |
| Figure 1 |
 |
| Figure 1a |
2.) Enter a filename for new DB
3.) Type the location to store the Key DB file.
4.) Press Ok
 |
| Figure 1b |
 |
| Figure 1c |
This shows the filename and location of the DB and the certificate types. Confirm the filename and location of above screen (Figure 1c) with figure1a.
Receiving a personal certificate
You can receive your personal certificate from CA by using this option, This can be done only if you have raised the certificate request from current key DB file.
 |
| Figure 2a |
2.) Press receive button from right panel
 |
| Figure 2b |
 |
| Figure 2c |
You can see the personal certificate label here. This label would be the one which you have entered while creating the certificate request and it can be changed by using the option "Rename" at the right pannel.
Importing a certificate
This option is useful if you want import a certificate from another key DB file. Suppose you have created a certificate request from one of the key DB file and once after receiving the certificate from CA you want to add this to another key DB file, Here you can't use "Receive" option because you created the request from another Key DB file.
In this scenario you can use "Receive" option from the Key DB where you originally created the certificate request to receive the personal certificate and then import this certificate from any of the Key DB file.
 |
| Figure 4a |
Select "New" from "Key Database File" menu option
 |
| Figure 4b |
1.) Select the "Key Database File Type" value, This is the format of the key DB file. The available types are JKS, JCEKS and PKCS12.
2.) Enter a filename for new DB
3.) Type the location to store the Key DB file.
4.) Press OK
 |
| Figure 4c |
Enter password for new Key DB file.
 |
| Figure 4d |
1.) Select "Personal Certificate" from the drop down list
2.) Press import button from the right panel
 |
| Figure 4e |
1.) Select the key DB type of the file from where you want to import the certificate.
2.) Browse/Type the Key DB filename from where you want to import the certificate.
3.) Confirm/Type the location
4.) Press OK
 |
| Figure 4f |
Enter password of the Key DB file from where you want to import the certificate and then press OK
 |
| Figure 4g |
This will list the labels of available certificates.
1.) Select label of the certificate which you want to import.
2.) Press OK
 |
| Figure 4h |
Here you can change the label if you want. You can skip this if you done want a label change.
1.) Select the label
2.) Enter New Label
3.) Press Apply (after this the label testca will get changed to personalCert
4.) Press OK
 |
| Figure 4i |
This screen shows the label of the certificate which you imported just now. If you want you can select the label and press view/Edit to view the details of the certificate.
Creating a Self Signed Certificate
 |
| Figure 5a |
 |
| Figure 5b |
2.) Browse/Type the filename.
3.) Confirm/Type the location.
4.) Press OK
 |
| Figure 5c |
Enter the password of the Key DB file which you selected in Figure 5b
 |
| Figure 5d |
2.) Press "New Self Signed Certificate" Button in the right panel
3.) Enter the certificate details, I have marked certain key points here for you attention.
4.) Press OK
 |
| Figure 5e |
2.) Press View/Edit to view the newly created self singed certificate.
 |
| Figure 5f |
This screen shows the details of newly created self signed certificate.
Adding Signers
Open a Key DB file for adding the signers
 |
| Figure 6a |
 |
| Figure 6b |
1.) Enter/Browse the filename of the signer certificate which you want to add.
2.) Confirm the location of the file.
3.) Press OK.
 |
| Figure 6c |
Enter Label for the Signer certificate.
 |
| Figure 6d |
Extracting a Certificate
Open the Key DB File
 |
| Figure 6e |
1.) Select "Signer Certificate" from drop down list.
2.) Select the label of the certificate which you want to extract
3.) Press "Extract" from the right panel.
4a.) Select the Data type.
4b.) Enter a filename to store the extracted certificate.
4c.) Type the location of the file.
4d.) Press OK
This will create a file with the name testSignerExtract in the specified location and stores the signer certificate with the label "testSigner" in it.
Synchronization Simplified
Synchronization Simplified
Synchronization is a process of updating the nodes with master configuration repository changes.The network deployment scenario of WebSphere application server contains multiple nodes managed by a Dmgr and Dmgr holds the master repository of configurations. Any updates or changes through Dmr will be saved in the master configuration and the nodes will be aware of these changes only after the synchronization.
The synchronization is always from Dmgr to Nodes and it never happens vise versa. If you made any changes from the node side it will be cleared during next synchronization process.
A Simple example
Consider below scenario.
OS ----- Linux
HostA ----- Dmgr
HostB ------Node1 --- AppSrv01
Suggest to stop the Nodeagent process in Node1
Autosync should be disabled (figure1)
Now let us set the heap size min value to 256 and max to 512 as below (Figure 4)
Make sure that you are not selecting "synchronize changes with nodes" option (Figure 5) and then save the changes to master repository
Now let us examine the master configuration repository (Dmgr) for the chnages we made. There you can see the newly created heap size entries (Figure 6)
As we disabled synchronization the jvm configuration file of Node1 will not be having that entry (Figure 7)
Now synchronize the master configuration repository changes with nodes by either a syncNode.sh/bat or by starting the nodes and then synching it from console, This updates the JVM configuration file of Node1 with the latest updates of master configuration (Figure 8).
Another simple and practical test for better understanding of synchronization
Test #1
Go under the config directory of dmgr (master repository) and create a file
Perform a full synchronization
Navigate to the config directory of node, It will be having the file which you created in master configuration.
The reason for this is during the full sync process it found a file in the master repository and which is not there in the nodes so full sync process transfer this file to nodes
Test #2
Go under the node config directory, create a file.
Perform a full synchrinization from dmgr
Navigate to the config directory of the node and check for the file which you created, the file will not be there.
The reason for this is, During the full synchronization process it found a file in the node repository (which you created) and which is not there in the master repository so full sync process removes the file from node to make the configuration in sync with master repository.
Types of Synchronization
There are two types of Synchronization
1.) Partial Synchronization : Here only the configuraion file(s) which has changed at the Dmgr level will be Synchronized with nodes.
2.) Full Synchronization: This will Synchronize the entire master repository with the nodes.
Possible ways of Synchronization
1. syncNode.sh /syncNode.bat command from the nodes.
2. from the admin console or wsadmin
3. When node agent starts
4. During federationn process.(addNode.sh)
5. Auto/scheduled sync.
syncNode.sh /syncNode.bat command from the nodes.
Usage: syncNode dmgr_host [dmgr_port] [-conntype] [-stopservers]
[-restart] [-quiet] [-nowait] [-logfile] [-replacelog]
[-trace] [-username] [-password ]
[-localusername] [-localpassword ]
[-profileName] [-help]
Normally use it as: syncNode.sh-username -password
Note:- The node agent should be down to execute syncNode and this is always a full synchronization.
From the admin console or wsadmin
This can be either a partial synchronization or full synchronization, It depends on the option selected.
When node agent starts
If this option is enabled node agent will synchronize with master repository during the startup process. The very first synchronization after startup will be a Full Synchronization and the consicutive synchronization will be Partial Synchronization.
During federationn process
This is always a full synchronization
Auto/scheduled sync
Synchronization is a process of updating the nodes with master configuration repository changes.The network deployment scenario of WebSphere application server contains multiple nodes managed by a Dmgr and Dmgr holds the master repository of configurations. Any updates or changes through Dmr will be saved in the master configuration and the nodes will be aware of these changes only after the synchronization.
The synchronization is always from Dmgr to Nodes and it never happens vise versa. If you made any changes from the node side it will be cleared during next synchronization process.
A Simple example
Consider below scenario.
OS ----- Linux
HostA ----- Dmgr
HostB ------Node1 --- AppSrv01
Suggest to stop the Nodeagent process in Node1
Autosync should be disabled (figure1)
 |
| Figure 1 |
As part of the tuning process you wants to set the JVM heap size of Node1/AppSrv01 to Min 256/ Max 512. Let us look at the Dmgr (Figure 2) and Node1 (Figure 3) configurations before setting the values.
Both these configuration files does not have an entry for jvm heap size (Linux OS) as there is no value set for it currently
 |
| Figure 2 |
 |
| Figure 3 |
 |
| Figure 4 |
 |
| Figure 5 |
 |
| Figure 6 |
 |
| Figure 7 |
 |
| Figure 8 |
Another simple and practical test for better understanding of synchronization
Test #1
Go under the config directory of dmgr (master repository) and create a file
Navigate to the config directory of node, It will be having the file which you created in master configuration.
The reason for this is during the full sync process it found a file in the master repository and which is not there in the nodes so full sync process transfer this file to nodes
Test #2
Go under the node config directory, create a file.
Perform a full synchrinization from dmgr
Navigate to the config directory of the node and check for the file which you created, the file will not be there.
The reason for this is, During the full synchronization process it found a file in the node repository (which you created) and which is not there in the master repository so full sync process removes the file from node to make the configuration in sync with master repository.
Types of Synchronization
There are two types of Synchronization
1.) Partial Synchronization : Here only the configuraion file(s) which has changed at the Dmgr level will be Synchronized with nodes.
2.) Full Synchronization: This will Synchronize the entire master repository with the nodes.
Possible ways of Synchronization
1. syncNode.sh /syncNode.bat command from the nodes.
2. from the admin console or wsadmin
3. When node agent starts
4. During federationn process.(addNode.sh)
5. Auto/scheduled sync.
syncNode.sh /syncNode.bat command from the nodes.
Usage: syncNode dmgr_host [dmgr_port] [-conntype
[-restart] [-quiet] [-nowait] [-logfile
[-trace] [-username
[-localusername
[-profileName
Normally use it as: syncNode.sh
Note:- The node agent should be down to execute syncNode and this is always a full synchronization.
From the admin console or wsadmin
This can be either a partial synchronization or full synchronization, It depends on the option selected.
When node agent starts
If this option is enabled node agent will synchronize with master repository during the startup process. The very first synchronization after startup will be a Full Synchronization and the consicutive synchronization will be Partial Synchronization.
During federationn process
This is always a full synchronization
Auto/scheduled sync
This is normally a partial synchronization but the very first synchronization after the node agent start will be a full synchronization.
Certificate Management by using gsk7cmd command
Command: gsk7cmd
Purpose: gsk7cmd is a command line tool for certificate management.
Prerequisite: set JAVA_HOME varriable.
Example: export JAVA_HOME=/usr/IBM/WebSphere/AppServer/java (this depends on your environment)
Parameters for below examples:
keystore Name: testcacerts.jks / test.kdb
password: changeit / testit
NOTE:- If you are practicing below examples kindly practice it in the sequence because there might be a dependancy.
Command usage
# gsk7cmd -help
Object Action Description
------ ------ -----------
-keydb
-changepw Change the password for a key database
-convert Convert the format of a key database
-create Create a key database
-delete Delete a key database
-expiry Display password expiry
-list Currently supported types of key database.
-stashpw Stash the password of a key database into a file
-cert
-add Add a CA Certificate
-create Create a self-signed certificate
-delete Delete a certificate
-details Show the details of a specific certificate
-export Export a personal certificate and associated private key into a PKCS12 file or a key
database
-extract Extract a certificate from a key database
-getdefault Show the default personal certificate
-import Import a certificate from a key database or a PKCS12 file
-list List certificates in a key database
-listsigners List signer certificates delivered with ikeyman
-modify Modify a certificate (NOTE: the only field that may be modified is the trust field)
-populate Populate with included CA Certificates
-receive Receive a certificate
-rename Rename a certificate
-setdefault Set the default personal certificate
-sign Sign a certificate
-certreq
-create Create a certificate request
-delete Delete a certificate request from a certificate request database
-details Show the details of a specific certificate request
-extract Extract a certificate from a certificate request database
-list List all certificate requests in a certificate request database
-recreate Recreate a certificate request
-seckey
-create Create a secret key
-delete Delete a secret key
-details Show the details of a specific secret key
-export Export secret keys to a file
-import Import secret keys from a file
-list List all secret keys in a key database
-rename Rename a secret key
-version Display iKeyman version information
-help Display this help text
Keystore Management (-keydb)
Creating keystore by specifying password expiry
Example 1
#gsk7cmd -keydb -create -db test.kdb -pw changeit -type kdb -expire 7300
The above command creates a keystore file (test.kdb) of kdb type and keep the password expiry to 7300 days
Example 2
# gsk7cmd -keydb -expiry -db test.kdb -pw changeit
This will list the password expiry of keystore test.kdb
Output:
Password expiry time: Aug 9, 2032 2:05:51 AM
Deleting the keystore
Example 3
#gsk7cmd -keydb -delete -db test.kdb -pw changeit
This deletes the keystore file test.kdb
Creating a default keystore
Example 4Purpose: gsk7cmd is a command line tool for certificate management.
Prerequisite: set JAVA_HOME varriable.
Example: export JAVA_HOME=/usr/IBM/WebSphere/AppServer/java (this depends on your environment)
Parameters for below examples:
keystore Name: testcacerts.jks / test.kdb
password: changeit / testit
NOTE:- If you are practicing below examples kindly practice it in the sequence because there might be a dependancy.
Command usage
# gsk7cmd -help
Object Action Description
------ ------ -----------
-keydb
-changepw Change the password for a key database
-convert Convert the format of a key database
-create Create a key database
-delete Delete a key database
-expiry Display password expiry
-list Currently supported types of key database.
-stashpw Stash the password of a key database into a file
-cert
-add Add a CA Certificate
-create Create a self-signed certificate
-delete Delete a certificate
-details Show the details of a specific certificate
-export Export a personal certificate and associated private key into a PKCS12 file or a key
database
-extract Extract a certificate from a key database
-getdefault Show the default personal certificate
-import Import a certificate from a key database or a PKCS12 file
-list List certificates in a key database
-listsigners List signer certificates delivered with ikeyman
-modify Modify a certificate (NOTE: the only field that may be modified is the trust field)
-populate Populate with included CA Certificates
-receive Receive a certificate
-rename Rename a certificate
-setdefault Set the default personal certificate
-sign Sign a certificate
-certreq
-create Create a certificate request
-delete Delete a certificate request from a certificate request database
-details Show the details of a specific certificate request
-extract Extract a certificate from a certificate request database
-list List all certificate requests in a certificate request database
-recreate Recreate a certificate request
-seckey
-create Create a secret key
-delete Delete a secret key
-details Show the details of a specific secret key
-export Export secret keys to a file
-import Import secret keys from a file
-list List all secret keys in a key database
-rename Rename a secret key
-version Display iKeyman version information
-help Display this help text
Keystore Management (-keydb)
Creating keystore by specifying password expiry
Example 1
#gsk7cmd -keydb -create -db test.kdb -pw changeit -type kdb -expire 7300
The above command creates a keystore file (test.kdb) of kdb type and keep the password expiry to 7300 days
Example 2
# gsk7cmd -keydb -expiry -db test.kdb -pw changeit
This will list the password expiry of keystore test.kdb
Output:
Password expiry time: Aug 9, 2032 2:05:51 AM
Deleting the keystore
Example 3
#gsk7cmd -keydb -delete -db test.kdb -pw changeit
This deletes the keystore file test.kdb
Creating a default keystore
#gsk7cmd -keydb -create -db testcacerts.jks -pw testit
The above command creates a keystore file with the name testcacerts.jks and the password testit in the current directory
Changing the keystore password
Example 5
#gsk7cmd -keydb -changepw -db testcacerts.jks -pw testit -new_pw changeit
This changes the password from testit to changeit
Certificate Management (-cert)
Adding certificate to a keystore with out specifying label
Example 6
#gsk7cmd -cert -add -file test.cer -db testcacerts.jks -pw changeit
This adds the certificate file test.cer in testcacerts.jks keystore, If label is not specified it will generate a label (kindly note the label details in example 7).
Example 7
#gsk7cmd -cert -details -label "cn=TESTCERT, o=IBM, c=us" -db testcacerts.jks -pw changeit
This command will list the details of certificate with label "cn=TESTCERT, o=IBM, c=us" (The certificate which was added in example 6)
Output
Label: cn=TESTCERT, o=IBM, c=us
Key Size: 1024
Version: X509 V3
Serial Number: 12 57 4F 87 1B F8 69 DD
Issued by: CN=TESTCERT, O=IBM, C=US
Subject: CN=TESTCERT, O=IBM, C=US
Valid: From: Wednesday, May 12, 2010 2:01:04 AM IST To: Wednesday, May 8, 2030 2:01:04 AM IST
Fingerprint: BE:87:67:14:AD:FD:64:B9:CC:08:CF:3E:76:05:2A:DC:BB:EB:DF:69
Signature Algorithm: MD5withRSA (1.2.840.113549.1.1.4)
Trust Status: enabled
Deleting a certificate from the keystore
Example 8
#gsk7cmd -cert -delete -label "cn=TESTCERT, o=IBM, c=us" -db testcacerts.jks -pw changeit
This command deletes the certificate with the label "cn=TESTCERT, o=IBM, c=us" (the certificate which was added in example 6)
Example 9
#gsk7cmd -cert -details -label "cn=TESTCERT, o=IBM, c=us" -db testcacerts.jks -pw changeit
This commands confirms the delete operation in example 8, The below output says the certificate with the label 'cn=TESTCERT, o=IBM, c=us' does not exists
Output
The database doesn't contain an entry with label 'cn=TESTCERT, o=IBM, c=us'.
Check the label and try again.
Adding certificate to a keystore with the label
Example 10
#gsk7cmd -cert -add -file test.cer -label "This is a cert" -db testcacerts.jks -pw changeit
This adds the certificate 'test.cer' with the label "This is a cert". (in example 6 we have added the certificate without specifying the label)
Example 11
#gsk7cmd -cert -details -label "This is a cert" -db testcacerts.jks -pw changeit
This confirms that the certificate test.cer has been added with the label "This is a cert", check the output below/
Output
Label: this is a cert
Key Size: 1024
Version: X509 V3
Serial Number: 12 57 4F 87 1B F8 69 DD
Issued by: CN=TESTCERT, O=IBM, C=US
Subject: CN=TESTCERT, O=IBM, C=US
Valid: From: Wednesday, May 12, 2010 2:01:04 AM IST To: Wednesday, May 8, 2030 2:01:04 AM IST
Fingerprint: BE:87:67:14:AD:FD:64:B9:CC:08:CF:3E:76:05:2A:DC:BB:EB:DF:69
Signature Algorithm: MD5withRSA (1.2.840.113549.1.1.4)
Trust Status: enabled
Renaming the label of a certificate
Example 12
#gsk7cmd -cert -rename -label "This is a cert" -new_label "The_new_label" -db testcacerts.jks -pw changeit
This renames the lable "This is a cert" with new name "The_new_label".
Example 13
#gsk7cmd -cert -details -label "The_new_label" -db testcacerts.jks -pw changeit
Example 13 and Example 14 confirms example 12,Check the output below.
Output
Label: the_new_label
Key Size: 1024
Version: X509 V3
Serial Number: 12 57 4F 87 1B F8 69 DD
Issued by: CN=TESTCERT, O=IBM, C=US
Subject: CN=TESTCERT, O=IBM, C=US
Valid: From: Wednesday, May 12, 2010 2:01:04 AM IST To: Wednesday, May 8, 2030 2:01:04 AM IST
Fingerprint: BE:87:67:14:AD:FD:64:B9:CC:08:CF:3E:76:05:2A:DC:BB:EB:DF:69
Signature Algorithm: MD5withRSA (1.2.840.113549.1.1.4)
Trust Status: enabled
Example 14
#gsk7cmd -cert -details -label "This is a cert" -db testcacerts.jks -pw changeit
Example 14 and Example 13 confirms example 12, because in the output of example 13 testcacerts.jks keystore contains a certificate with the label "The_new_label" and the output of example 14 says the testcacerts.jks keystore does not have an with the label "This is a cert" (label name before rename).
Output
The database doesn't contain an entry with label 'This is a cert'.
Check the label and try again.
Extracting a certificate from the keyfile
Example 15
#gsk7cmd -cert -extract -label "The_new_label" -target "this_is_extracted_cert.cer" -db testcacerts.jks -pw changeit
This will extracrt the certificate with label "The_new_label" into a file this_is_extracted_cert.cer, check the below output for file confirmation
#ls this_is_extracted_cert.cer
this_is_extracted_cert.cer
Creating a self signed certificate
Example 16
gsk7cmd -cert -create -db testcacerts.jks -pw changeit -label 'New_Self_Signed' -dn CN=testSELFSIGN,O=ibm,C=in -expire 7300 -size 1024 -x509version 3
This creates a self signed certificate with the label 'New_Self_Signed'
Example 17
# gsk7cmd -cert -details -label 'New_Self_Signed' -db testcacerts.jks -pw changeit
This confirms the self signed certificate creation ,Verify the certificate in the below output
Output
Label: new_self_signed
Key Size: 1024
Version: X509 V3
Serial Number: 50 29 68 22
Issued by: CN=testSELFSIGN, O=ibm, C=in
Subject: CN=testSELFSIGN, O=ibm, C=in
Valid: From: Tuesday, August 14, 2012 2:18:34 AM IST To: Monday, August 9, 2032 2:18:34 AM IST
Fingerprint: 0C:D5:A0:6A:54:76:6B:3E:D0:3E:2E:42:1C:D0:32:43:66:82:FE:70
Signature Algorithm: SHA1withRSA (1.2.840.113549.1.1.5)
Trust Status: enabled
Subscribe to:
Posts (Atom)