Square Bubble Version 2 Operating Guide

Start

rpm

Square Bubble Version 2 rpm package ships with System V init.d and systemd scripts for RHEL 6 & 7 respectively, to control the running state of the program. To start, issue the following command as root or more preferably using sudo to restrict the user to only run a limited set of commands in such a privileged mode:

  • For RHEL 6:
    [...] # service sqrbbl start
  • For RHEL 7:
    [...] # systemctl start sqrbbl

tar

From the installation directory, using the user that untarred the package, edit the sqrbbl-setup file if java is not on the local PATH then use the following command:

[...sqrbbl-...] $ bin/start-sqrbbl

This command will return immediately as it launches square bubble in the background. To check for errors look at the files in the log directory (especially sqrbbl-stdouterr.log).


Stop

The stop process will attempt to perform a graceful shutdown, to disconnect where appropriate. You need to install and configure a JDK to achieve this, however, we have found the IBM JDK does not support this action. In all cases, should this operation not be possible, or if it fails, the process will be terminated (using a kill command).

rpm

To stop, issue the following command as root (or via sudo):

  • For RHEL6:

    [...] # service sqrbbl stop

  • For RHEL7:

    [...] # systemctl stop sqrbbl


tar

From the installation directory, using the user that untarred the package, edit the sqrbbl-setup file to set up the JAVA_HOME variable, then use the following command:

[...sqrbbl-...] $ bin/stop-sqrbbl

If you are using the IBM JDK or have not set up the JAVA_HOME variable to point to a jdk where ${JAVA_HOME}/lib/tools.jar is present you can kill the process. From the command terminal used to start square bubble, discover the pid of the running agent by use of the following command:

[...sqrbbl-...] $ ps -H

This command will return the process hierarchy from the current shell. One such process should be java. You can kill this process using the kill <pid> command.

If you are not in the same shell, use the following command

[...] $ ps -ef | grep java | grep sqrbbl

No return means that square bubble is not running. More than 1 return would suggest multiple instance are running.

A further alternative is to use Jolokia as a deployed javaagent at startup (configure in the sqrbbl-setup script) then use the configured URL to stop, such as http://localhost:7777/jolokia/exec/com.syntegrity.innovations.sqrbbl:type=Main/stop. Change the host and port as appropriate to your deployment.


Status

rpm

To query the running status, issue the following command as root (or via sudo):

  • For RHEL6:

    [...] # service sqrbbl status

  • For RHEL7:

    [...] # systemctl status sqrbbl


tar

From the command terminal used to start square bubble, discover the pid of the running agent by use the following command:

[...sqrbbl-...] $ ps -H

This command will return the process hierarchy from the current shell. One such process should be java. If this is so, square bubble is running, if not square bubble is not.

If you are not running from the command terminal that square bubble was started from, try the following command:

[...] $ ps -ef | grep java | grep sqrbbl

No return means that square bubble is not running. More than 1 return would suggest multiple instance are running.

In addition, square bubble supports the JMX ethos to allow greater details of what is happening within the JVM. This is available using any of the following:

There are many more options to access JMX.


Logs

Viewing

rpm

To view the logs, issue the following command (as any user, unless your system administrator has altered the permissions):

[...] $ cat /var/log/sqrbbl/sqrbbl.log

Or to see lines being added:

[...] $ tail -f /var/log/sqrbbl/sqrbbl.log

On RHEL7 you can also query the systemd journal by using the command:

[...] $ journalctl _UID=`id -u sqrbbl`
tar

From the installation directory, you can cat or tail the log files in the log directory. e.g.

[...sqrbbl-...] $ cat log/sqrbbl-stdouterr.log
[...sqrbbl-...] $ tail -f log/sqrbbl.log

The sqrbbl-stdouterr.log is for start up messages directed to STDOUT and all messages directed to STDERR.

The sqrbbl.log file is the main agent log where activity is reported.

Editing

The Square Bubble agent uses logback to control logging and ships with a config that reports INFO and above messages, uses a daily log rotate and keeps messages for up to 30 days. You can change this behaviour by extracting the logback.xml from the main jar file (sqrbbl.jar), modifying it (refer to logback configuration for more details) and finally overriding the config using the options in sqrbbl-setup script. Note this will also override the logging for the validation script (which has config to report to the console), so do this only when you are comfortable that the square bubble main configuration is correct.

Here is a sample (taken from the rpm package) which reports only warnings and above and only keeps 5 days of logs

<?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/var/log/sqrbbl/sqrbbl.log</file> <append>true</append> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <!-- daily rollover --> <fileNamePattern>/var/log/sqrbbl/sqrbbl.%d.log</fileNamePattern> <maxHistory>5</maxHistory> </rollingPolicy> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{5} - %msg%n </pattern> </encoder> </appender> <appender name="MQTRACE-FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/var/log/sqrbbl/sqrbbl-mqtrace.log</file> <append>true</append> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <!-- daily rollover --> <fileNamePattern>/var/log/sqrbbl/sqrbbl-mqtrace.%d.log</fileNamePattern> <maxHistory>5</maxHistory> </rollingPolicy> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{5} - %msg%n </pattern> </encoder> </appender> <appender name="SYSLOGTRACE-FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/var/log/sqrbbl/sqrbbl-syslogtrace.log</file> <append>true</append> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <!-- daily rollover --> <fileNamePattern>/var/log/sqrbbl/sqrbbl-syslogtrace.%d.log</fileNamePattern> <maxHistory>5</maxHistory> </rollingPolicy> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{5} - %msg%n </pattern> </encoder> </appender> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{5} - %msg%n </pattern> </encoder> </appender> <logger name="com.syntegrity.innovations.sqrbbl" level="WARN" additivity="false"> <appender-ref ref="FILE" /> </logger> <logger name="MQTRACE" level="WARN" additivity="false"> <appender-ref ref="MQTRACE-FILE"/> </logger> <logger name="SYSLOGTRACE" level="WARN" additivity="false"> <appender-ref ref="SYSLOGTRACE-FILE"/> </logger> <root level="WARN"> <appender-ref ref="FILE" /> </root> </configuration>
rpm

To extract the logback.xml, use the following command

[...]$ jar -xf /opt/syntegrityinnovations/sqrbbl/bin/sqrbbl.jar logback.xml
tar

To extract the logback.xml, use the following command

[...]$ jar -xf <installdir>/bin/sqrbbl.jar logback.xml

Finally, to override add the following to the sqrbbl-setup script (located in /etc/sqrbbl for rpm installs and the install dir for tar installs), we have assumed the logback.xml has been extracted and modified in /etc/sqrbbl:

...
# and set any additional java options required, as follows
START_JAVA_OPTS="-server -Xmx128m -Dlogback.configurationFile=/etc/sqrbbl/logback.xml"
...

Validation

rpm

To validate the configuration, you need to have java installed and available on the PATH for user sqrbbl. This can also be achieved by modifying the /etc/sqrbbl/sqrbbl-setup file.

You can test this from root using the command:

[...] # su -c ". /etc/sqrbbl/sqrbbl-setup;java -version" -s /bin/bash sqrbbl

If you see something like "bash: java: command not found" then java has not been set up.

To run the validation script, from root, use the following command:

[...] # su -c "/opt/syntegrityinnovations/sqrbbl/bin/validate" -s /bin/bash sqrbbl

All messages will be displayed in the console.


tar

To validate the configuration, you need to have java installed and available on the PATH for user that installed square bubble . This can also be achieved by modifying the <install dir>/sqrbbl-setup file.

You can test this from the install dir using the command:

[...] $ . sqrbbl-setup;java -version

If you see something like "bash: java: command not found" then java has not been set up.

To run the validation script, use the following command:

[...] $ bin/validate

All messages will be displayed in the console.

There are some additional switches that can be added to the validate command to modify the behaviour, which includes:


Additional jars

If you need to have additional jar files available to square bubble, as is required for the use of MQ security exits, you can now simply place them in the lib directory. For the rpm install, this is in /etc/sqrbbl/lib, for .tar.gz or .zip install, the lib directory should be created in the installation directory.

Additional jars are loaded after the Square Bubble jar.


Command Line Options

This section provides details of the command line options available to square bubble. These are typically defined in the SQRBBL_OPTS variable within the sqrbbl-setup file located in /etc/sqrbbl for rpm installs and the installation directory for tar installs. The options include


Licensing

You need a valid license to run this software. Licenses can be purchased here and are to be copied into the directory /etc/sqrbbl/license.d either before the software is started or whilst it is running should additional license be acquired.

Each license file has attributes for:

Servers in this context are running OS images which are distinguished by IP address (or the DNS resolved IP address). All loopback addresses (localhost etc) are treated as the same server. This is irrespective of the number of services (DataPower devices, IIB Integration nodes, servers etc and MQ Queue Managers) that are running. Should the configuration exceed the number of servers licensed, the software will not start. You can then either purchase another license or reduce the servers being monitored in your configuration (sources).

We use the inotify watcher to receive notifications whenever the directory, or its contents are modified. There are a number of events that we watch for:

The software will not start or perform any validation unless a valid license is made available. It will also stop once all current licenses expire, or there are insufficient licensed servers at the current time. This may also result from inadvertently removing one or more current license files.

There is another case where the entire license directory may be removed inadvertently. In this case the software will continue as if nothing happened however once the directory is restored, it will attempt to reload licenses as if started anew. Therefore, if this situation does arise, make sure you have all the required licenses in the directory before you restore or rename it.

Licenses may be deployed in more than one running instances but only if the total instances that use the same license maintain the limit on the overall number of servers being monitored. Should a license for 1 server exist, it MUST only be used in a single instance at any given point in time.

License usage is reported in the output destinations (files, splunk etc), and we can detect if they are being used incorrectly. If you are unsure whether you are operating within the license terms, please contact us at innovations@syntegrity.com.au immediately, for assistance.


DataPower settings

We provide recommendations in this section in order to get the most out of your DataPower deployments.

To connect, you need to enable either the:

For either option, you will also need to acquire the certificate used by the DataPower device and add to a truststore (see also Use of SSL/TLS). Ask your DataPower administrator for the certificate or extract using a tool such as openssl s_client.

In addition we recommend you create a user principal with only sufficient authorisations required to acquire the data required. Use of an all powerful admin account is not advised in a production environment.

The datapower and syslog configured sources can be combined to provide optimal data for DataPower. It is recommended that you use the same network (IP) address for both to reduce license costs. The interface used to provide data via the REST or XML management interfaces should be used as the local address for your log targets when used with Square Bubble. See Log Targets below for more details. You could use an alternative IP address however that will require a further license, which should not be required.

Enable Statistics

Statistics needs to be enabled in order to allow Square Bubble the ability to query CPU usage data. To switch this on see Enabling statistics.

Time Zone setting

We recommend you set the local time zone on the device to UTC. There is an issue with the use of syslog in that the time stamp used by syslog does not include a time zone. We therefore recommend using UTC as the time zone to provide a consistent reference. Our many colleagues suggest this is best practice to avoid confusion. If this is set to a different time zone, data may not be visible in Splunk and/or Elastic.

Log Targets

We can provide additional value by processing and forwarding log messages from DataPower using the syslog source. You need to provide the following settings:

Object Classes

Some of the data we collect is provided via a generic object query interface. Each object is associated with an object class. These are the main object classes we use in the Square Bubble dashboards. They include the Domain Application service types:

Filtering for these Class field values will reduce the data being emitted by Square Bubble, considerably.


MQ required authorisations

We have developed recommended scripts to make this easier and without compromising the integrity of your trusted MQ service.

Synchronous requests

We have identified the minimal authorisations needed to enable Square Bubble to extract the data required by the dashboards. They include the following :

setmqaut -m $1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p $3 +browse +dsp +get +inq +put +set
setmqaut -m $1 -n SYSTEM.DEFAULT.MODEL.QUEUE -t q -p $3 +browse +dsp +get +inq +put +set
setmqaut -m $1 -t qmgr -p $3 +connect +dsp +inq
setmqaut -m $1 -n '**' -t listener -p $3 +dsp
setmqaut -m $1 -n '**' -t service -p $3 +dsp
setmqaut -m $1 -n '**' -t clntconn -p $3 +dsp
setmqaut -m $1 -n '**' -t q -p $3 +dsp +inq
setmqaut -m $1 -n '**' -t chl -p $3 +dsp

Where $1 is the Queue Manager name and $3 is the user principal.

The user principal can be either a local user (non-privileged) or a signed certificate which could also be registered in an LDAP server.

This will work for all MQ only data types except QSTATS. To enable QSTATS (which is no longer recommended and you can get this data from either Statistics Messages or from MQ V9 System Topics) you need to add another definition for the queues you wish to allow Square Bubble to run the RESET QUEUE STATISTICS against, such as:

setmqaut -m $1 -n 'MYQUEUE*' -t q -p $3 +dsp +inq +chq

If your square bubble config is not limited to those which have the +chq authorisation, you will receive an authorisation error, and no data. We would recommend you limit this authorisation to maintain system integrity.

IIB published data

If you collect flowstats and/or resources IIB data from MQ, you will need to enable access to the topic as follows:

setmqaut -m $1 -n 'SYSTEM.BROKER.MB.TOPIC' -t top -p $3 +sub

MQ Events

To receive MQ Events, you can either:

  1. Provide get access to the appropriate SYSTEM.ADMIN.*.EVENT queues, as follows:
    setmqaut -m $1 -n 'SYSTEM.ADMIN.*.EVENT' -t q -p $3 +get
    or
  2. Use pub/sub as described here with an administrative (durable) subscription. We have a subtle variation on this which can be deployed using the following runmqsc script (for all events):
    DELETE QLOCAL (SYSTEM.ADMIN.CHANNEL.EVENT)
    DELETE QLOCAL (SYSTEM.ADMIN.COMMAND.EVENT)
    DELETE QLOCAL (SYSTEM.ADMIN.CONFIG.EVENT)
    DELETE QLOCAL (SYSTEM.ADMIN.PERFM.EVENT)
    DELETE QLOCAL (SYSTEM.ADMIN.LOGGER.EVENT)
    DELETE QLOCAL (SYSTEM.ADMIN.PUBSUB.EVENT)
    DELETE QLOCAL (SYSTEM.ADMIN.QMGR.EVENT)
    DEFINE TOPIC(SYSTEM.ADMIN.CHANNEL.EVENT) TOPICSTR('system/admin/event/channel')
    DEFINE TOPIC(SYSTEM.ADMIN.COMMAND.EVENT) TOPICSTR('system/admin/event/command')
    DEFINE TOPIC(SYSTEM.ADMIN.CONFIG.EVENT) TOPICSTR('system/admin/event/config')
    DEFINE TOPIC(SYSTEM.ADMIN.LOGGER.EVENT) TOPICSTR('system/admin/event/logger')
    DEFINE TOPIC(SYSTEM.ADMIN.PERFM.EVENT) TOPICSTR('system/admin/event/perfm')
    DEFINE TOPIC(SYSTEM.ADMIN.PUBSUB.EVENT) TOPICSTR('system/admin/event/pubsub')
    DEFINE TOPIC(SYSTEM.ADMIN.QMGR.EVENT) TOPICSTR('system/admin/event/qmgr')
    DEFINE QALIAS(SYSTEM.ADMIN.CHANNEL.EVENT) TARGTYPE(TOPIC) TARGET(SYSTEM.ADMIN.CHANNEL.EVENT)
    DEFINE QALIAS(SYSTEM.ADMIN.COMMAND.EVENT) TARGTYPE(TOPIC) TARGET(SYSTEM.ADMIN.COMMAND.EVENT)
    DEFINE QALIAS(SYSTEM.ADMIN.CONFIG.EVENT) TARGTYPE(TOPIC) TARGET(SYSTEM.ADMIN.CONFIG.EVENT)
    DEFINE QALIAS(SYSTEM.ADMIN.LOGGER.EVENT) TARGTYPE(TOPIC) TARGET(SYSTEM.ADMIN.LOGGER.EVENT)
    DEFINE QALIAS(SYSTEM.ADMIN.PERFM.EVENT) TARGTYPE(TOPIC) TARGET(SYSTEM.ADMIN.PERFM.EVENT)
    DEFINE QALIAS(SYSTEM.ADMIN.PUBSUB.EVENT) TARGTYPE(TOPIC) TARGET(SYSTEM.ADMIN.PUBSUB.EVENT)
    DEFINE QALIAS(SYSTEM.ADMIN.QMGR.EVENT) TARGTYPE(TOPIC) TARGET(SYSTEM.ADMIN.QMGR.EVENT)
    DEFINE QLOCAL(SQRBBL.ADMIN.QUEUE)
    DEFINE SUB(SQRBBL.ADMIN.ALL) TOPICSTR('system/admin/#') PSPROP(NONE) DESTCLAS(PROVIDED) DEST(SQRBBL.ADMIN.QUEUE)
    We then need to give the square bubble user get access to this queue as follows:
    setmqaut -m $1 -n 'SQRBBL.ADMIN.QUEUE' -t q -p $3 +get

V9 System Topics

To receive data from the V9 System Topics, you will need to provide subscription permissions to the sqrbbl user, such as:

setmqaut -m $1 -n 'SYSTEM.ADMIN.TOPIC' -t top -p $3 +sub

This is required to harvest the meta data which is used when processing the data messages.

There are 2 styles of subscription supported for accessing the data messages, which are:

  1. Unmanaged Subscriptions (the default option), which requires a queue to be predefined for Square Bubble to use as a destination for subscriptions. Subscriptions are only active when square bubble is running. This may result in data loss but it prevents the destination becoming full. The predefined queue must allow the square bubble user (e.g. sqrbbl) get permission. The queue should be identified in the mqmonQueue child element in the mq source. Only the first element is used, if others are defined, they will be ignored.
  2. Managed subscriptions (enabled by setting the mqmonManaged attribute of the mq source to true), here the user will create one or more destination queues and subscriptions without any involvement of square bubble. This option reduces the risk of data loss however has the increased risk of filling up the destination qeueus and as such needs to be more carefully managed. The destination queues are defined using the mqmonQueue child element in the mq source. Multiple destination queues can be defined.

Destination queues can be created using a runmqsc script such as:

DEFINE QLOCAL(SQRBBL.MQMON.QUEUE)

The Square Bubble user (e.g. sqrbbl) should be given get permission on the queue, such as:

setmqaut -m $1 -n 'SQRBBL.MQMON.QUEUE' -t q -p $3 +get

Resources

We have also provided sample scripts based on a standard 8.0.0.4 installation of MQ that will create a Queue Manager that has these authorisations included so you can start testing right away. These scripts are not intended to run in a production environment and as such will require modification to suit the needs of your environment. The scripts take 3 parameters:

  1. Queue Manager name, to be created e.g. QM_SQRBBL
  2. Listener port e.g. 1414
  3. User principal (local user name) e.g. sqrbbl_user (which needs to be created on the local host and the password made available to square bubble)

They are available for:


Use of SSL/TLS

We support the use of secure sockets layer which will encrypt data passing between the agent and the output destination or source. We support only the latest protocols from TLS V1 onwards, as is common with browsers and of course JVMs.

As we use Java, this is a relatively straightforward affair however if you are not familiar with the use of certificates and private/public key pairs, we would suggest you read the following:

Trust

To trust certificates from a source or destination you will need the CA or CA chain in either the cacerts or another trust store. Assemble the collection of trusted CA certificates that you want to deploy. The trusted CA certificates can be obtained from public CAs or private CAs. The trusted CA certificates can be in any format that is compatible with the Java keystore utility, such as PEM format. All you need are the certificates themselves, the private keys and passwords are not required.

Given a CA certificate, cacert.pem, in PEM format, you can add the certificate to a JKS truststore (or create a new truststore) by entering the following command:

keytool -import -file cacert.pem -alias CAAlias -keystore truststore.ts -storepass StorePass

Where CAAlias is a convenient tag that enables you to access this particular CA certificate using the keytool utility. The file, truststore.ts, is a keystore file containing CA certificates. If this file does not already exist, the keytool utility will create it. The StorePass password provides access to the keystore file, truststore.ts.

This process can be used for all required CA certificates or self signed certificates (the latter is not recommended for production purposes).

To configure Square Bubble to use the truststore, which enables 1-way authentication, you need to add the appropriate switches to the sqrbbl-setup file, located in /etc/sqrbbl for rpm install or the <Install dir> for other installs:

#!/bin/sh
# run time config for sqrbbl
# use this config script to set PATH to point to the correct version of java, example below
JAVA_HOME=/usr/java/jre1.7.0_80
export JAVA_HOME
export PATH=${JAVA_HOME}/bin:${PATH}
...
# and set any additional java options required, as follows
START_JAVA_OPTS="-server -Xmx256m -Djavax.net.ssl.trustStore=<path>/truststore.jks -Djavax.net.ssl.trustStorePassword=<password>"
...

See also section Hiding passwords from command line below.

Client Authentication

To enable client, or mutual (two-way), certificate-based authentication, you need to enable the trust (as documented in the previous section) and add (or generate) private keys for each client identity. In a corporate environment or other large organisations, this may be created for you, in which case you will need to import the private key. This can be done by using openssl to generate a keystore and then import that to a java keystore. For example from a provided certificate (provided.crt):

openssl pkcs12 -export -name myservercert -in provided.crt -inkey mykey -out keystore.p12

Followed by:

keytool -importkeystore -destkeystore mykeystore.jks -srckeystore keystore.p12 -srcstoretype pkcs12 -alias mycert

To use the generated keystore and trustore, you need to modify the sqrbbl-setup file in /etc/sqrbbl/ to identify where these files are. The following is a complete example:

#!/bin/sh
# run time config for sqrbbl
# use this config script to set PATH to point to the correct version of java, example below
JAVA_HOME=/usr/java/jre1.7.0_80
export JAVA_HOME
export PATH=${JAVA_HOME}/bin:${PATH}
...
# and set any additional java options required, as follows
START_JAVA_OPTS="-server -Xmx256m -Djavax.net.ssl.trustStore=/home/user/mqssl/mytruststore.jks -Djavax.net.ssl.trustStorePassword=p@ssw0rd -Djavax.net.ssl.keyStore=/home/user/mqssl/mykeystore.jks -Djavax.net.ssl.keyStorePassword=p@ssw0rd"
...

If you have imported the required CA certificates into the cacert, you can omit the truststore options.

See also section Hiding passwords from command line below.

MQ setup

MQ can be a little tricky to get working with SSL/TLS however the following resources should help you:

The videos make extensive use of the IBM Websphere MQ Explorer which we would recommend you use to help setup your MQ environment.


Hiding passwords from command line

The examples above are not recommended in a production environment that may be shared with other applications or users. To prevent the passwords being visible, from the command line, we have added an option to include additional properties from a file. This is done by adding the -props option to the SQRBBL_OPTS var in sqrbbl_setup. So using the example the the Client Authentications section above, the sqrbbl-setup file will include:

#!/bin/sh
# run time config for sqrbbl
# use this config script to set PATH to point to the correct version of java, example below
JAVA_HOME=/usr/java/jre1.7.0_80
export JAVA_HOME
export PATH=${JAVA_HOME}/bin:${PATH}

# set square bubble options (other than config & licensedir)
SQRBBL_OPTS="-startsec 0 -props /etc/sqrbbl/sqrbbl-props"

# and set any additional java options required, as follows
START_JAVA_OPTS="-server -Xmx256m"
...

The additional properties file (/etc/sqrbbl/sqrbbl-props) should then have appropriate permissions and contents as follows:

# Additional system properties required by Square Bubble
javax.net.ssl.trustStore=/home/user/mqssl/mytruststore.jks
javax.net.ssl.trustStorePassword=p@ssw0rd
javax.net.ssl.keyStore=/home/user/mqssl/mykeystore.jks
javax.net.ssl.keyStorePassword=p@ssw0rd

The properties should conform to the java properties file standard, as documented in the Java Properties load method.

Each property is added to or overrides the system properties.


MQ CCDT

This is currently experimental

We have shipped a script which simplifies the creation of MQ Client Channel Definition Table, used to simplify and control client connections into MQ. More details about MQ CCDT can be found here.

The script requires the MQ client to be installed on the local machine and that the profile is initialized to make the MQ client tools available on the path of the shell being used. This can be done by running the command:

[...] $ . setmqenv -s

The script can be found /opt/syntegrityinnovations/sqrbbl/bin/sbDefQmgr. This script takes the following command line arguments:

Switch Description Default
-m QMgrName No default - required
-c ConnectionName No default - required
-n ChannelName "SQRBBL.QMgrName"
-t TLS cipher Suite name TLS_RSA_WITH_AES_128_CBC_SHA256
-x X509 certificate file name /etc/sqrbbl/sqrbbl.cer
-b Channel Table name AMQCLCHL.TAB
-l Channel Library name (directory) /etc/sqrbbl
-q QueueManager Certificate DN or file name empty (allow any queue manager DN)
-u User on QMgr for SquareBubble to use (should not be mqm) sqrbbl