App Connect

App Connect

Join this online user group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

Running IIB version 10 as a shared Install when you aren’t a root user 

Mon July 13, 2020 10:27 AM

We’ve had a few customers who want to run an IIB v10 shared install but who have limited root access. The good news is, as long as you can persuade a friendly admin to do some setup for you it is possible to get a non-root install working. You can follow the basic recipe below:

These steps are starting from a completely fresh machine so I have included creating the users and used sudo su - as a shorthand for switching users. I am assuming that on a real system there will probably already be users with home dirs already existing and will use pwd based authentication to log in. You can therefore skip the steps that deal only with create users etc. This sequence was tested on Ubuntu 16.04, where commands vary across unix versions the same principle should apply.

Steps need as root (one off)
============================

1.) Add mqbrkrs group

sudo addgroup --group mqbrks

2.) Create 2 users in this group brokerId1 and brokerId2

sudo useradd -g mqbrkrs brokerId1
sudo useradd -g mqbrkrs brokerId2

3.) Create a directory to untar into under /opt and allow mqbrkrs to modify it

sudo mkdir /opt/ibm
sudo mkdir /opt/ibm/mqsi
sudo chown brokerId1:mqbrkrs /opt/ibm/mqsi
sudo chmod 775 /opt/ibm/mqsi

4.) Create home dirs for the users and chown them to the right userId

sudo mkdir /home/brokerId1
sudo mkdir /home/brokerId2
sudo chown brokerId1:mqbrkrs /home/brokerId1
sudo chown brokerId2:mqbrkrs /home/brokerId2

5.) Create /var/mqsi and associated directories and set them writable by the broker users
sudo mkdir /var/mqsi
sudo mkdir /var/mqsi/common
sudo mkdir /var/mqsi/common/locks
sudo mkdir /var/mqsi/common/log
sudo mkdir /var/mqsi/common/errors
sudo mkdir /var/mqsi/common/wsrr
sudo mkdir /var/mqsi/components
sudo mkdir /var/mqsi/config
sudo mkdir /var/mqsi/odbc
sudo mkdir /var/mqsi/registry
sudo mkdir /var/mqsi/shared-classes
sudo mkdir /var/mqsi/XML
sudo mkdir /var/mqsi/XML/external
sudo mkdir /var/mqsi/XSL
sudo mkdir /var/mqsi/XSL/external
sudo chmod -R 775 /var/mqsi
sudo chown -R brokerId1:mqbrkrs /var/mqsi

6.) Switch to broker user
sudo - brokerId1

Steps needed as mqbrkrs member (do this per fixpack)
======================================================

7.) Copy install image to /opt/ibm/mqsi and untar it
cp /home/davicrig/Downloads/iib-10.0.0.5.tar.gz /opt/ibm/mqsi
cd /opt/ibm/mqsi
tar -xvf iib-10.0.0.5.tar.gz
cd iib-10.0.0.5

8.) As brokerId1 accept the license
unset DISPLAY (#NB: this is a workaround for a ubuntu issue)
./iib accept license

9.) chown the install so it is readable by the mqbrkrs group
chown brokerId1:mqbrkrs .

10.) Modify mqsiprofile (vi server/bin/mqsiprofile) adding the following 2 lines immediately after the comments:
export MQSI_WORKPATH=/var/mqsi
export MQSI_REGISTRY=/var/mqsi

11.) Create the global reg file (this tells mqsiprofile to allow MQSI_WORKPATH to be overridden)
echo "/var/mqsi" > common/GLOBAL_REG

12.) As brokerId1 run the profile
. server/bin/mqsiprofile

Try some mqsicommands to verify it works

mqsicreatebroker broker1

13.) Login as brokerId2 and run the profile
sudo su – brokerId2
. /opt/ibm/mqsi/iib-10.0.0.5/bin/mqsiprofile

14.) Create a broker and start it

mqsicreatebroker broker2
mqsistartbroker broker2

15.) Verify both brokers were created in /var/mqsi
ls -la /var/mqsi/components

You should see lines like this:

drwxrwx--- 8 brokerId1 mqbrkrs 4096 Jul 4 14:36 broker1
drwxrwx--- 8 brokerId2 mqbrkrs 4096 Jul 4 14:37 broker2

If you have an existing /var/mqsi structure create by a previous install, for example if you are migrating from version 9 then you can skip step 5.

5 comments on"Running IIB version 10 as a shared Install when you aren’t a root user"

  1. Joao December 13, 2016

    Hi, thanks for this post. Is this a setup supported by IBM, this is: when asking support via a pmr (for example) will it be supported?

    Reply (Edit)
    • DaveCrighton December 13, 2016

      Hi Joao,

      We can’t guarantee that these instructions are complete for all functionality as we don’t run our tests this way currently. So while we will accept a PMR on this configuration you should be prepared that the resolution might be to go in and manually apply some permissions changes or create a directory etc. and you may need root privileges to execute these steps. We’ll keep this document up to date if we do find anything along those lines.

      Clearly if you found a functional problem in an unrelated area of the product this configuration would not stop us from looking at the PMR.

      I can say that on my own Ubuntu machine I run with this configuration and haven’t hit any additional problems so far.

      Reply (Edit)
  2. DaveCrighton July 08, 2016

    Hi Frederick,

    So for the install file path you would obviously need to run 2 different directories, we recommend naming them after the fixpack levels for example /opt/ibm/mqsi/8.0.0.3 /opt/ibm/mqsi/10.0.0.5 etc.

    For the workpath and registry path it is perfectly acceptable to use /var/mqsi for both v8 and v10 installations. In fact if you want to do a migration of a v8 broker on to v10 using mqsimigratecomponents then using the same workpath and registry is a requirement.

    While using a separate workpath / registry for each version is possible I’m not sure that is the approach I would recommend. While you are correct that is makes deleting all data associated with the v8 install easier it also has some disadvantages. For example the common directories such as /var/mqsi/common/log and /var/mqsi/common/errors are often located on a separate file system that has more space than the rest of /var/mqsi because the trace files generated when you are diagnosing a problem can be very larger. Setting up 2 filesystems is just added administrative overhead.

    Generally you will find that if data is specific to a particular broker it will be located in a subdirectory named after that broker for example /var/mqsi/components/ or /var/mqsi/registry/ so the approach I would probably use is to use mqsideletebroker to clean up and v8 brokers prior to uninstalling v8, then uninstalling the product using the installer and then finally double checking the components and registry directories to make sure that broker specific data has been cleared up.

    Reply (Edit)
  3. Frederick July 07, 2016

    Hi Dave – I have question about a similar but different situation. Let’s say you are upgrading from WMBv8 to IIBv10 and you need to run both in parallel for an extended amount of time (months). Can/should you use the same /var/mqsi work path or should v8 be separated from v10? Meaning can you specify an alternate work path when you install v10? After we successfully migrate to v10 our intention is to ‘delete’ v8 and we think having separate directories would make this easier. Thanks in advance.

    Reply (Edit)
    • DaveCrighton March 08, 2017

      Hi Frederick,

      You would need to run a separate MQSI_WORKPATH and MQSI_REGISTRY to get what you are looking for, this does prevent migration (as in mqsimigratecomponents) of a broker from WMBv8 to IIBv10 though.

      Running multiple installations from the same /var/mqsi should work just fine (I do this on my machine) of course you will need unique broker names across all your installs in this configuration.

      Reply (Edit)

Statistics
0 Favorited
14 Views
0 Files
0 Shares
0 Downloads
Global message icon