IBM Installation Manager for dummies


IBM installation manager (IM) is a centralized solution managing WebSphere, rational and tivoli software on a machine. IM can perform installations, modify and update existing installation and un-installation of the products. IM also has a feature to manage the license of the software installed.
Note: There can only be one IM per machine
Installing IM is straight forward. However you need to be aware of few directories that IM will use.   Continue reading
Advertisements

mod_deflate – saves web server traffic by compression


  • The mod_deflate module provides the DEFLATE output filter that allows output from your server to be compressed before being sent to the client over the network.
  • mod_deflate allows Apache2 to compress files and deliver them to clients
  • With mod_deflate, you can compress HTML, text or XML files to approx. 20 – 30% of their original sizes, thus saving you server traffic.
  • Compressing files causes a slightly higher load on the server

How to use it?

1. Enable mod_deflate module

When we install apache2, mod_deflate should also already be installed on system
LoadModule deflate_module modules/mod_deflate.so Continue reading

Self signed certificates using OpenSSL


The openssl toolkit is used to generate an RSA Private Key and a CSR (Certificate Signing Request). It can also be used to generate self-signed certificates which can be used for testing purposes or internal usage.

Step 1: Generate a Private Key
The first step is to create your RSA Private Key. This key is a 1024 bit RSA key which is encrypted using Triple-DES and stored in a PEM format so that it is readable as ASCII text.

openssl genrsa -des3 -out josephamrithraj.key 1024

Step 2: Generate a CSR (Certificate Signing Request) Continue reading

The Enigma of WebSphere Application Server Plug-in, Part-2: Parameters that you can tune


In the first part of this series, we learned how the WebSphere application server plugin works and different components involved in its operation. In this second part, let us discuss different parameters that can affect the operation of the plugin and tuning options.

TCP timeout on operating system

This parameter controls when to drop a request when the client is not able to communicate with the server using TCP/IP. In case of the plugin, this parameter controls when the backend application server will be marked as down. For example, you have TCP/IP timeout on your linux operating system as 90sec and the plugin failed to communicate with an application server hosted on that machine, then it waits for the TCP/IP timeout setting and marks the server as down.

It is very important to know that since this parameter is set at operating system level, it will affect all other TCP/IP communications on that machine.

Connect timeout in plugin-cfg.xml

This setting allows plugin to perform a non-blocking connection with the backend server.

<Server CloneID=”abcd123x” LoadBalanceWeight=”2″ Name=”WASNClone1″ ConnectTimeout=”X”>

  • A value of ‘0’ allows plugin to perform non-blocking connection.
  • A value greater than 0 specifies the number of seconds you want the plug-in to wait for a successful connection. If a connection does not occur after that time interval, the plug-in marks the server unavailable and fails over to one of the other servers defined in the server group.
  • If no value is specified, the plugin wait until TCP/IP timeout occurs.

If no clone responds within the specified connect timeout, then a HTTP 500 error will be thrown.

When a clone is marked down, the plugin will retry for connection based on RetryInterval.

Plugin-log entry when connect timeout occurs

ERROR: ws_common: websphereGetStream: Connect timeout fired

ERROR: ws_common: websphereExecute: Failed to create the stream

ERROR: ws_server: serverSetFailoverStatus: Marking WASNClone1 down

ERROR: ws_common: websphereHandleRequest: Failed to execute the transaction to ‘WASNClone1’on host ‘test.josephamrithraj.com’; will try another one Continue reading

Configuring SSL for WebSphere and IBM Http Server, part-4 : Dmgr and Nodes


It is always good to spend some time on thinking how to do instead of start doing it and then thinking what to do. Also it is always advisable to draw picture to understand complex things in simple way.

Now Observe the below picture of WebSphere setup having one Web Server, one DMGR and 2 nodes. Write down all the possible communications among them. Also include a browser and its communication with DMGR.

  1. Browser to DMGR
  2. DMGR to Nodes
  3. Web Server to Application Servers… Through plug-in

Thats it, now we know where all we can configure SSL and secure our WebSphere environments.

Note:

  • Take back up of configuration using backupconfig
  • In a secure communication both end points need to exchange their certificates to establish the secure link.
  • Stop all process related to websphere

WEBSPHERE-SSL-2

 

1. DMGR certificate

Start Deployment Manager [DMGR]

Replace DMGR certificate

  • In the Administrative Console, go to Security > SSL certificate and key management > Key stores and certificates > CellDefaultKeyStore > Personal certificates > Create a self-signed certificate. Enter the required attributes.
  • image 

  • Click OK and Save the changes
  • Go back to Security > SSL certificate and key management > Key stores and certificates > CellDefaultKeyStore > Personal certificates
  • Select the old DMGR certificate and click Replace.
  • On the next screen, you are able to choose which certificate will replace the old certificate. Accept your new certificate. Do not select either Delete old certificate after replacement or Delete old signers. Accept your new certificate and any browser prompts.
  • On the next screen, select the old certificate and click Delete. Click OK and Save the changes.

Now you have your DMGR certificate replaced

As i pointed earlier, the certs needs to be exchanged for establishing secure communication. So add the DMGR cert to DefaultCellTrustStore

  • Go to SSL certificate and key management > Key stores and certificates.
  • Select CellDefaultKeyStore and CellDefaultTrustStore and click Exchange signers.
  • image

  • Select the certificate in CellDefaultKeyStore personal certificates created in previous step and click Add.
  • image

  • Click OK and Save the changes.

2. Node Certificates

  • Go to Security > SSL certificate and key management > Manage endpoint security configurations.
  • Under Inbound, click the link for the node, node_name(NodeDefaultSSLSettings,null).
  • Click the Manage certificates button.
  • image

  • Click Create a self-signed certificate and Enter the required attributes.
  • Click OK and Save the changes
  • Go back to Security > SSL certificate and key management > Manage endpoint security configurations, click node_name(NodeDefaultSSLSettings,null), click Manage certificates.
  • Select the old certificate and click Replace.
  • On the next screen, you are able to choose which certificate will replace the old certificate. Accept your new certificate. Do not select either Delete old certificate after replacement or Delete old signers.
  • On the next screen, select the old certificate and click Delete. Click OK and save the changes.

Now Exchange the Node Signer cert with DefaultCellTrustStore

  • Go to Security > SSL certificate and key management > Manage endpoint security configurations.
  • Under Inbound, click the link for the node, node_name(NodeDefaultSSLSettings,null) and select Key stores and certificates.
  • Select NodeDefaultKeyStore and CellDefaultTrustStore and then Click Exchange signers.
  • image

  • Select the certificate in NodeDefaultKeyStore personal certificates created in previous step and click Add.
  • image

  • Click OK and Save the changes.

Delete the old signer certificates and extract the new ones.

  • Go to SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates
  • Select all of the old signer certificates and click Delete. If you are not sure, you can compare the Fingerprint and/or the Expiration dates with the personal certificate in the keystores.
  • Select one of the new certificates. Click Extract.
  • Enter a File Name that corresponds to the certificate. For example, node1.arm. Click Ok.
  • for each of the new certificates making sure you have done this for the cell signer and all of the node signers. These files are saved to the profile_root/Dmgr/etc directory

Manually copy the trust store to each of the /etc directories.

  • Backup the trust.p12 in profile_root\Dmgr\etc
  • Copy the profile_root\Dmgr\config\cells\cell-name\trust.p12 to profile_root\Dmgr\etc
  • Backup the trust.p12 on each of the nodes profile_root\Appsrv\etc directories.
  • Copy the profile_root\Dmgr\config\cells\cell-name\trust.p12 to profile_root\Appsrv\etc

Note: If you have multiple nodes… You need to do the Node Certificate section for all nodes separately.

Now, Restart the DMGR and sync the nodes using ‘syncnode’ command. Then start Node Agents and Application Servers.

3. Plug-in

  • Go to Servers > Web servers. Click webserver_name, then under Additional Properties click Plug-in properties.
  • Click Manage keys and certificates under Additional Properties, click Signer certificates and then click AddEnter a unique Alias Name and then specify the File Name that you exported as .arm file
  • image

  • Repeat this for each of the new certificates making sure you have done this for the cell signer and all of the node signers.
  • Manually copy the plugin-key.kdb from the local configuration to the Web server. [ default locations: profile_root\Dmgr\config\cells\cell-name\nodes\node-name\servers\web-server-name\plugin-key.kdb to Web-server-root\Plugins\config\web-server-name\plugin-key.kdb]
  • Start the Web server

Note: If you have multiple web servers … you need to do the above steps for each web server separately

The steps and procedure are from IBM Websphere Infocenter and document Reference #: 1305596