WebSphere MQ & IIB on Ubuntu

I found that more and more people like Linux and this is a great things.

IBM Integration Bus for developers (free of charge !!!) is available for Linux distribution.

That's cool... however I find out that the installation may be always straightforward especially on the last Linux 64 bit distribution.

You will find in this small post what are the steps that I followed to install the package.

First I would recommend to install each component separately:

• WebSphere MQ
• IBM Integration Bus
• IIB Explorer

Download the IBM Integration Bus for developers package.

https://www14.software.ibm.com/webapp/iwm/web/pick.do?source=swg-wmbfd&S_TACT=109KA7GW&S_CMP=1586-0-120057

I have used the single package download.

WebSphere MQ

Installation

Installing software on Ubuntu usually entails using Synaptic or by using an apt-get command from the terminal. 

Unfortunately, there are still a number of packages out there that are only distributed in RPM format.

Ubuntu is Debian based and therefore uses.deb packages to install. If you want to install .rpm packages, you first should convert them into .deb packages with a conversion software such as alien. Then you can use gdebi or dpkg to install them.

Despite the large version number, alien is still (and will probably always be) rather experimental software. It has been used by many people for many years, but there are still many bugs and limitations

IBM distribute MQ as a set of RPMs and with what I just said, I recommend to use "rpm" and hence install the rpm package: ‘rpm’, ‘pax’ and ‘default-jre’ packages.

Detailed information can be found in the following technote:

http://www-01.ibm.com/support/docview.wss?uid=swg21656068 

In my installation I have made first 

1. Install the i386 libraries

sudo apt-get install libc6-i386
sudo apt-get install libgcc1:i386
sudo apt-get update 

2. Define the system configuration (provided here after)

3. Install the different rpm package as explaine at the previous link (for ubuntu 14.04 I had to use the --prefix /opt/mqm).

4. Define the WMQ configuration

System configuration

I would recommend to change the system configuration for Linux when using WebSphere MQ. I provide the information here after but detailed information can be found in the knowledge center ( Linux System requirements).

create /etc/sysctl.d/50-webspheremq.conf with the following:

kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.shmmax = 268435456
kernel.sem = 500 256000 250 1024
fs.file-max = 524288

Make these changes live by running

sudo sysctl -p

These information can be found in the knowledge center
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.ins.doc/q008550_.htm 

Check that this has been correctly updated

cat /proc/sys/kernel/shmmni 

WMQ Configuration

You can use the setmqinst command to change the installation description of an installation, or to set or unset an installation as the primary installation.

Before executing the command, you would have to create the following directory “/usr/lib64”. 

Create this directory with the following command:

sudo mkdir /usr/lib64

This command sets the installation with an installation path of /opt/mqm as the primary installation:

sudo /opt/mqm/bin/setmqinst -i -p /opt/mqm

Add the user to the group mqm in order to be administrator:

sudo addgroup $USER mqm

IIBExplorer installation

Before doing any installation, you should first install the prereqs librairies (see corresponding chapter).

Install IBExplorer. Go to the folder “/extractedfolder/messagebroker_ia_developer/IBExplorer”.

If the installer is not executable, you would have to change using the following command:

chmod +x install.bin

launch the installation:

sudo ./install.bin

And start the IBM Integration Toolkit with the following command:

sudo strmqcfg -clean

IBM Integration Toolkit

Before doing any installation, you should first install the prereqs librairies (see corresponding chapter).

The installation is then straightforward, just launch the installToolkit.

sudo ./installToolkit.sh

IBM Integration Bus

The runtime is installed in a very straightforward way.
Just go in the directory where the tar has been unzipped and launch the setup.

Intalling Eclipse prereqs

The installation manager, the IBM Integration Toolkit and IBM Integration Exporer requires to have 32bit libraries. I have found issues to run the installation without installing the "ia32-libs".
In order to install this library I have used the following command:
 

sudo -i
cd /etc/apt/sources.list.d
echo "deb http://old-releases.ubuntu.com/ubuntu/ raring main restricted universe multiverse" >ia32-libs-raring.list
apt-get update
apt-get install ia32-libs
rm /etc/apt/sources.list.d/ia32-libs-raring.list
apt-get update
exit
sudo apt-get install gcc-multilib

And the following libs:

apt-get install libc6-i386
apt-get install libgcc1:i386

Working with WMQ Authentication Record

It's not the first time that I have been asked to secure a WMQ Server using the out-of-the-box security feature of WMQ.

WMQ provides from V7.1 enhanced security capabilities with the channel authentication records.

There are a lot of information available out there, I have however figure out that it may be not trivial to understand the principle.

I found very useful information from very knowledge persons at the following link:
Channel Auth Record by Morag Hudson
WMQ Security deep dive with T.Rob.

I provide here after a short description of what the feature provides and examples to help understanding the principle.

Before beginnin, the channel authentication records have to be enabled  in order to be applied by the queue manager. This is a Queue Manager property.

The security feature

So what does this feature provides?
How to define it?

Channel authentication records (CHLAUT) are defined using the MQ Explorer under the channel topic (same level as client channel) or using the scripting interface.

The aim of this feature is to allow or block access to someone. It comes from the former BlockIP  MQ support pack. It gives also the ability to map a user provided by the client application to another user.
This setting is made of rules that are defined using channel authentication records.

The principle

A client application use a client channel to connect to a queue manager. On the server a server connection channel is associated to this client channel.
It is possible to define a client authentication record that block any incomming connection from an or a range of IP address at the listener level.
If the connection is allowed, queue manager performs the following based on the CHLAUT defines:
1. resolves a rule to be applied on the connection
2. identifies what channel identity information is used for the rule
3. perform an action on the connection: allow, map a user, block

The resolution of the rule is performed using a channel profile.
The rules that are applied are those having the most specific match only. For example if there are two rules with the match criteria "SYSTEM.*" and "SYSTEM.ADMIN.*, then the SYSTEM.ADMIN.* rule will be applied for a client application using a channel "SYSTEM.ADMIN.SVRCONN". It is possible to further filter the rules to be applied by using IP address when the match criteria was SSL, Client User ID or Remote queue manager.

When the rule has been resolved, the queue manager uses the CHLAUTH definition to identify the identity information from the client connection to be used.
The identity information can be one of the following:

• SSL Distinguished Name
• Client user ID (user Id provided by the clientapplication)
• Remote queue manager
• IP Address

A special extra rule is available for blocking a connection: "Final user Id".
This rule is applied after that all other rules have been applied and after that any security Id has been called.
A typical usage of this rule is to block any user that has administration rights.

If the channel profile match multiple rules then the rules that the rule precedence order are provided here after:

1. SSL DN
2. Client User ID
3. Remote queue manager
4. IP Address

If the value of the identity information match the value defined in the CHLAUTH definition then the action of the CHLAUTH is executed: the resulting of the rule would be either to map the incoming user to another user, to block the connection or to allow the connection.
If the rule didn't block the connection, the queue manager checks if there is a special rule "block final user Id". If such rule is resolved, the rule is executed to find out if the resolved user is allowed to connect or not. The resolved user may be the incoming user provided with the connection, a user that would have been maped by a previous rule or modified by any security exit called.

Examples

I find out that it is easies to understand the principle with some example.

Example 1

Lets take the asumption that the queue manager have the following server connection channel defined:

• SYSTEM.DEF.SVRCONN
• SYSTEM.ADMIN.SVRCONN

And the client application is connecting using the client channel "SYSTEM.DEF.SVRCONN" with the user "userX".

If the following CHLAUTH is defined
SET CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP) ADDRLIST(*) USERSRC(NOACCESS)

This rule would be applied to all server connection channel beginning with "SYSTEM." that a client application would use.
The identity information used by the queue manager to apply this rule is the IP address (type ADDRESSMAP) and the it match all the IP addresses (ADDRLIST=*).
The action of this rule is to block the connection.

This means that all client application will be rejected if it tries to connect using a client channel that begins with "SYSTEM." and therefore the application connection using "SYSTEM.DEF.SVRCONN" will be refused.

Now if an MQ administrator add the following rule
SET CHLAUTH(SYSTEM.DEF.SVRCONN) TYPE(ADDRESSMAP) ADDRLIST(*) USERSRC(CHANNEL)

It match the server connection channnel "SYSTEM.DEF.SVRCONN".
As the client application is using this channel, this rule will overwrite the first one for this connection because it is a more specific matching than "SYSTEM.*".
The rule is using the IP address identity and it match all IP addressses (all client connection with this channel name).
The action is telling use the channel user as final user.
The result will be that the connection will be allowed and the user provided by the client application will be used to get the queue manager authorization.

Now if the following CHLAUT is defined:
SET CHLAUTH(SYSTEM.DEF.SVRCONN) TYPE(USERMAP) CLNTUSER(userX) USERSRC(userY)

When the client application connects, the two rules above matches.
The table provided upper shows that the client userId takes precedence on IP Address, therefore the new rule is executed.
If the client application is using the userX then the rule would map this user to userY. If this user has no access authorization to the queue manager then the connection would be refused.


Finally, if the mq adminstrator creates the following CHLAUT:
SET CHLAUTH(SYSTEM.*) TYPE(BLOCKUSER) USERLIST(*MQADMIN)

As this rule is the special extra rule that is applied after the other rules or security exit, this rule is executed after those defined above.
This rule block all user that have MQ administration right. And this rule is applied for all channels that match "SYSTEM.*". Hence if the client application is connecting with a user that has administration right or if the userY (mapped user for userX) has administration rights, the connection will be refused.

Default Configuration

From WMQ 7.1, when a new queue manager is created, the following authentication records are created:

SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST(*MQADMIN)
SET CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(NOACCESS)
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(CHANNEL)

With the first rule, any user that try to connect using a user having mq administration right will be blocked.

With the second rule, if the user doesn't have administration right, the user will be blocked if it is connecting using a channel that begins with "SYSTEM." other than "SYSTEM.ADMIN.SVRCONN".

The last rule allows a user to connect to the queue manager using the channel "SYSTEM.ADMIN.SVRCONN" if the user doesn't have the MQ administration right.

Built-in HA solution for WebSphere Message Broker/Message Queue

WebSphere Message Queue

WebSphere MQ V7 introduced an HA software support with the multi-instance feature.

The multi-instance capability provides an Active/Passive or Hot/Standby solution.
The queue manager in standby mode is not started but a daemon is monitoring a shared file system for lock file release.
When the active queue manager dies it frees the lock on the log files that allows the standby queue manager to start.

The file system has to support the necessary requirements:
Testing and support statement for WebSphere MQ multi-instance queue managers

General requirements for WebSphere Message Queue provides also information for the multi-instance support:
WebSphere Message Queue Support Requirements

Support on ritualized environment
http://www-01.ibm.com/support/docview.wss?uid=swg21392025

WebSphere Message Broker

WebSphere Message Broker leverages this WMQ capability and provides also a solution for Hot/Standby HA solution.


Here after you can find references that provides a very good introduction:

Configuring A Multi-Instance Message Broker For High Availability Support
Checklist for Implementing High Availability using Multi-Instances in Message Broker V7

To know more about

If you want to investigate in more details the HA solution please have a look to the following redbook:

High Availability in WebSphere Messaging Solutions