Category Archives: Virtualization

TIBCO EMS 8 Fault Tolerance + NFS4

Introduction

Starting with my “CentOS 6 + EMS” setup, I need to obtain a decent FT/HA demo setup for test purposes.

My clients are often trying to improve EMS availability in case of a disaster or simple software error. Not because EMS itself is unstable, but mostly to manage risk related to MOM RollOver(or FT), HA and DR. TIBCO does provides guidelines on the subject, but not precise recommendation on the combination of OS and distributed FS to use. Additionally, TIBCO experts usually push for file stores over DB stores. They state that DB stores should not be considered for performance reasons, even if it strikes me as the simplest possible FT setup.

Many clients are then encouraged to create a software or hardware filesharing system to allow multi-site FT. This article describe how to implement such a solution FOR TEST PURPOSES using a FREE SOFTWARE distributed filesystem (NFS4 on CentOS 6). The other popular option is to go with specialized HARDWARE SAN solutions. For budget consideration, I wonder if I could create a performing enough setup without going in that expensive direction.

According to the official EMS documentation, the requirements for a distributed EMS Fault tolerance back-end file system are:

  • Write Order
  • Synchronous Write Persistence
  • Distributed File Locking
  • Unique Write Ownership

Would CentosOS 6+ NFS4 complies to all these rules ? I honestly don’t know. TIBCO does not provide a precise list of free/software or hardware storage solutions that precisely follow these guidelines. They point out that NFS4 could in some instance comply if all of the above principles are respected.

DISCLAIMER : If TIBCO cannot certify a OS/FS pairing for EMS FT, I certainly can’t either. PLEASE CONSIDER THE FOLLOWING HOW-TO AS A SUGGESTION OF TESTING CONFIGURATION. PLEASE DO NOT APPLY THIS SOLUTION IN A PRODUCTION ENVIRONMENT WITHOUT PROPER TESTING.

Side-line editorial : I believe the future is full of easily distributed MOMs, and that this kind of difficult setup will disappear over time. Currently, some MOM (IBM MQ, Rabbit MQ)don’t make FT  that hard to implement (but do not support WAN connections). In contrast, some MOM FT setup are similar to EMS (Active MQ)

To summarize, I aim to create something like this:

EMS FT goal
Latency will be introduced for testing purposes

NFS4 setup

As written above, start by go through my CentOS/EMS how-to and my CentOS firewall how-to.

Then, I suggest following up an article like this one from cyberciti.biz to setup NF4 and this one from digitalocean.com.

On my VM image, here is what it looked like:

yum install nfs-utils nfs4-acl-tools portmap
yum  - all packages are there !
It seems my CentOS 6 VM already had all these

Ok, nothing to do then… moving along to the stores sharing.
Let’s edit /etc/exports and add this:

vim /etc/exports

#add this line, to allow all host in the VirtualBox subnet (assuming you address is in 10.0.2.*, like mine)
/opt/cfgtibco/tibco/cfgmgmt/ems 10.0.2.0/24(rw,sync,no_root_squash)

Turn on the relevant services:

chkconfig nfs on 
service rpcbind start
service nfs start

NFS service starts

Just to be on the safe side, I explicitly disable NFS2 and NFS3 like mentioned here. In file /etc/sysconfig/nfs, I added (uncommented):

MOUNTD_NFS_V2="no"
MOUNTD_NFS_V3="no"
RPCNFSDARGS="-N 2 -N 3"

…and restarted

Firewall and VirtualBox ports updates

Now, let’s open the pertinent ports. If you refer to my firewall how-to, you know I use the iptables-restore command. to load my config. Edit the /root/iptables-save.txt, and add a line like this one:

-A INPUT -p tcp -m tcp --dport 2049 -j ACCEPT

Then, we validate and save:

iptables-restore < /root/iptables-save.txt
iptables -L
/sbin/service iptables save

EMS primary instance setup

The “Primary” machine is almost ready… the EMS server is still working (just start it to validate), and it is using the file stores locally, without NFS. We must modify the configuration slightly to allow the “Secondary” machine to share the JSON configuration file.

Note : This is really the big revolution of the new EMS configuration file format (JSON), in the past, each machine in the cluster had an almost identical “tibemsd.conf” system of files (some could be shared, but usually not the main one)… This made no sense since the vast majority of the data was the same for every machine in the cluster. Now the configuration file is shared, and includes slight difference when using FT. (EMS user guide, “Configuring Fault Tolerance in Central Administration”, page 539)

I use the EMS CA interface to change the relevant configuration:

Server Props
Server properties – NOTE : The IPs are wrong, see the section below.
FT propos
Fault tolerance properties – NOTE : The IPs are wrong, see the section below.

EMS secondary instance setup

To create the EMS “Secondary” machine, I suggest (all steps detailed below):

  • Creating a new script for the second EMS instance
  • Cloning the “Primary” VM
  • Validate Virtual Box IP attribution.
    • Correct configuration if necessary.
  • Deleting the EMS data folder and NFS export configuration on “Secondary” VM (config and stores)
    • Create a nfs client at the same location.

EMS secondary script

Before cloning, I built this script (tibemsd64-2.sh in EMS “bin” folder), and exposed it as a shortcut on the desktop:

cd /opt/tibco/ems/8.1/bin
./tibemsd64 -config "/opt/cfgtibco/tibco/cfgmgmt/ems/data/tibemsd.json" -secondary

Here is the shortcut command:

gnome-terminal -e "gnome-terminal -e /opt/tibco/ems/8.1/bin/tibemsd64-2.sh"

Reference  : (EMS User Guide, “Starting Fault Tolerant Server Pairs”, page 109)

“Primary” VM cloning

Thanks VirtualBox !
Thanks VirtualBox !

“Secondary” VM IP validation

When I first started my VMs, I realized they had the SAME IP address (10.0.2.15)… this is where I realized that I needed to switch the networking mode in the VMs for “NAT” to “NAT network”.

Changed in VirtualBox main "preferences".
Changed in VirtualBox main “preferences”.
To be changed on each VMs
To be changed on each VMs

As simple as that, but now sadly the IPs have changed ! I end up with 10.0.2.4 and 10.0.2.5.

Another side-effect… The port-forwarding settings (tutorial here) for each separate VMs are lost, they have to be re-implemented on the group itself. As such:

New port forwarding for NAT network
New port forwarding for NAT network

I have to adjust the JSON file by hand, since the EMS server and EMSCA processes won’t start without proper listeners.

Here is my updated JSON file:

{
	"acls":	[],
	"bridges":	[],
	"channels":	[],
	"durables":	[],
	"emsca":	{
		"advanced":	[],
		"appliance_options":	{
			"store_paths":	[]
		},
		"emsca_listens":	[{
				"url":	"tcp://10.0.2.4:7222"
			}, {
				"url":	"tcp://10.0.2.5:7222"
			}]
	},
	"factories":	[{
			"jndinames":	[],
			"name":	"ConnectionFactory",
			"ssl":	{
				"ssl_issuer_list":	[],
				"ssl_trusted_list":	[]
			},
			"ssl_issuer_list":	[],
			"ssl_trusted_list":	[],
			"type":	"generic",
			"url":	"tcp://7222"
		}, {
			"jndinames":	[],
			"name":	"FTConnectionFactory",
			"ssl":	{
				"ssl_issuer_list":	[],
				"ssl_trusted_list":	[]
			},
			"ssl_issuer_list":	[],
			"ssl_trusted_list":	[],
			"type":	"generic",
			"url":	"tcp://localhost:7222,tcp://localhost:7224"
		}, {
			"jndinames":	[],
			"name":	"SSLConnectionFactory",
			"ssl":	{
				"ssl_issuer_list":	[],
				"ssl_trusted_list":	[],
				"ssl_verify_host":	false
			},
			"ssl_issuer_list":	[],
			"ssl_trusted_list":	[],
			"type":	"generic",
			"url":	"ssl://7243"
		}, {
			"jndinames":	[],
			"name":	"GenericConnectionFactory",
			"ssl":	{
				"ssl_issuer_list":	[],
				"ssl_trusted_list":	[]
			},
			"ssl_issuer_list":	[],
			"ssl_trusted_list":	[],
			"type":	"generic",
			"url":	"tcp://7222"
		}, {
			"jndinames":	[],
			"name":	"TopicConnectionFactory",
			"ssl":	{
				"ssl_issuer_list":	[],
				"ssl_trusted_list":	[]
			},
			"ssl_issuer_list":	[],
			"ssl_trusted_list":	[],
			"type":	"topic",
			"url":	"tcp://7222"
		}, {
			"jndinames":	[],
			"name":	"QueueConnectionFactory",
			"ssl":	{
				"ssl_issuer_list":	[],
				"ssl_trusted_list":	[]
			},
			"ssl_issuer_list":	[],
			"ssl_trusted_list":	[],
			"type":	"queue",
			"url":	"tcp://7222"
		}, {
			"jndinames":	[],
			"name":	"FTTopicConnectionFactory",
			"ssl":	{
				"ssl_issuer_list":	[],
				"ssl_trusted_list":	[]
			},
			"ssl_issuer_list":	[],
			"ssl_trusted_list":	[],
			"type":	"topic",
			"url":	"tcp://localhost:7222,tcp://localhost:7224"
		}, {
			"jndinames":	[],
			"name":	"FTQueueConnectionFactory",
			"ssl":	{
				"ssl_issuer_list":	[],
				"ssl_trusted_list":	[]
			},
			"ssl_issuer_list":	[],
			"ssl_trusted_list":	[],
			"type":	"queue",
			"url":	"tcp://localhost:7222,tcp://localhost:7224"
		}, {
			"jndinames":	[],
			"name":	"SSLQueueConnectionFactory",
			"ssl":	{
				"ssl_issuer_list":	[],
				"ssl_trusted_list":	[],
				"ssl_verify_host":	false
			},
			"ssl_issuer_list":	[],
			"ssl_trusted_list":	[],
			"type":	"queue",
			"url":	"ssl://7243"
		}, {
			"jndinames":	[],
			"name":	"SSLTopicConnectionFactory",
			"ssl":	{
				"ssl_issuer_list":	[],
				"ssl_trusted_list":	[],
				"ssl_verify_host":	false
			},
			"ssl_issuer_list":	[],
			"ssl_trusted_list":	[],
			"type":	"topic",
			"url":	"ssl://7243"
		}],
	"groups":	[{
			"description":	"Administrators",
			"members":	[{
					"name":	"admin"
				}],
			"name":	"$admin"
		}],
	"model_version":	"1.0",
	"queues":	[{
			"name":	">"
		}, {
			"name":	"sample"
		}, {
			"name":	"queue.sample"
		}],
	"routes":	[{
			"name":	"EMS-SERVER2",
			"selectors":	[],
			"url":	"tcp://7022"
		}],
	"stores":	[{
			"file":	"meta.db",
			"file_crc":	false,
			"mode":	"async",
			"name":	"$sys.meta",
			"type":	"file"
		}, {
			"file":	"async-msgs.db",
			"file_crc":	false,
			"mode":	"async",
			"name":	"$sys.nonfailsafe",
			"type":	"file"
		}, {
			"file":	"sync-msgs.db",
			"file_crc":	false,
			"mode":	"sync",
			"name":	"$sys.failsafe",
			"type":	"file"
		}],
	"tibemsd":	{
		"authorization":	false,
		"console_trace":	null,
		"detailed_statistics":	"NONE",
		"flow_control":	false,
		"ft_activation":	null,
		"ft_active":	null,
		"ft_heartbeat":	null,
		"ft_reconnect_timeout":	null,
		"ft_ssl":	{
			"ssl_ciphers":	null,
			"ssl_expected_hostname":	null,
			"ssl_identity":	null,
			"ssl_issuer_list":	[],
			"ssl_password":	null,
			"ssl_private_key":	null,
			"ssl_trusted_list":	[],
			"ssl_verify_host":	null,
			"ssl_verify_hostname":	null
		},
		"jre_options":	[],
		"log_trace":	null,
		"logfile":	"/opt/cfgtibco/tibco/cfgmgmt/ems/data/datastore/logfile",
		"logfile_max_size":	null,
		"max_connections":	0,
		"max_msg_memory":	"512MB",
		"max_stat_memory":	"64MB",
		"msg_swapping":	true,
		"multicast":	false,
		"password":	null,
		"primary_listens":	[{
				"ft_active":	true,
				"url":	"tcp://10.0.2.4:7222"
			}],
		"rate_interval":	3,
		"routing":	false,
		"secondary_listens":	[{
				"url":	"tcp://10.0.2.5:7222",
				"ft_active":	true
			}],
		"server":	"EMS-SERVER",
		"server_rate_interval":	1,
		"ssl":	{
			"ssl_cert_user_specname":	"CERTIFICATE_USER",
			"ssl_dh_size":	null,
			"ssl_issuer_list":	[],
			"ssl_password":	null,
			"ssl_rand_egd":	null,
			"ssl_require_client_cert":	null,
			"ssl_server_ciphers":	null,
			"ssl_server_identity":	null,
			"ssl_server_key":	null,
			"ssl_trusted_list":	[],
			"ssl_use_cert_username":	null
		},
		"statistics":	true,
		"statistics_cleanup_interval":	30,
		"store":	"/opt/cfgtibco/tibco/cfgmgmt/ems/data/datastore",
		"tibrv_transports":	null,
		"track_correlation_ids":	null,
		"track_message_ids":	null
	},
	"tibrvcm":	[],
	"topics":	[{
			"name":	">"
		}, {
			"exporttransport":	"RV",
			"name":	"topic.sample.exported"
		}, {
			"importtransport":	"RV",
			"name":	"topic.sample.imported"
		}, {
			"name":	"sample"
		}, {
			"name":	"topic.sample"
		}],
	"transports":	[{
			"daemon":	null,
			"name":	"RV",
			"network":	null,
			"service":	null,
			"type":	"tibrv"
		}],
	"users":	[{
			"description":	"Administrator",
			"name":	"admin",
			"password":	null
		}, {
			"description":	"Main Server",
			"name":	"EMS-SERVER",
			"password":	null
		}, {
			"description":	"Route Server",
			"name":	"EMS-SERVER2",
			"password":	null
		}]
}

NFS client setup

On the “Secondary” VM :

  • Disable the NFS server by removing the export entries in /etc/exports and restart the service
  • Remove the local configuration and stores
    • rm -Rf /opt/cfgtibco/tibco/cfgmgmt/ems
  • Create a (test) NFS client
    • mkdir /opt/cfgtibco/tibco/cfgmgmt/ems
      # as root, we mount the "root" 
      mount -t nfs4 -v 10.0.2.4:/opt/cfgtibco/tibco/cfgmgmt/ems /opt/cfgtibco/tibco/cfgmgmt/ems
  •  Once it is established to work successfully, umount the NFS partition and add this line to /etc/fstab:
  • 10.0.2.4:/opt/cfgtibco/tibco/cfgmgmt/ems /opt/cfgtibco/tibco/cfgmgmt/ems   nfs    defaults 0 0

GEMS update

One thing remaining is to update GEMS (see first tutorial) configuration:

We enter the URLs like typical java clients: tcp://host1:port1,tcp://host2:port2
We enter the URLs like typical java clients: tcp://host1:port1,tcp://host2:port2

Then, to be sure, let’s restart both VMs, validate the automatic NFS link, and start both servers before starting GEMS:

...bingo ! 2 EMS servers in FT via NFS sharing !
…bingo ! 2 EMS servers in FT via NFS sharing !

I hope this testing rig will be useful to you !

CentOS and VirtualBox NAT Port Forwarding

In my recent experiments, and while preparing for my next post, I stumbled on problems when trying to forward ports of my CentOS Guest VM to my Mac OS based browser. For some reason, even if Port forwarding was properly configured, like so :

Virtual Box Port NAT port forwarding on CentOS
Virtual Box Port NAT port forwarding on CentOS

…my Host system browser could not connect to services on my VM, with the exception of SSH. The solution was simple, CentOS comes with default netfilters rules built-in. These rules allow outgoing trafic, and incoming SSH requests only. The firewall configuration needed to be changed. The simplest way to do so is to disable the firewall completely:

# Run as root !
# Flush (discard) all rules
iptables -F
# Save configuration permanently
/sbin/service iptables save

While this may be very good for VM usage, I don’t like to disable a whole firewall (I feel unclean afterwards when I do). Here is a more sensible solution, that could be a starting point for a more solid security setup :

#Again... as root !
#See config
iptables -L
#save config
iptables-save > /root/iptables-save.txt
#edit config (see below for example)
vim /root/iptable-save.txt
# flush + load config
iptables-restore < /root/iptables-save.txt
# Validate
iptables -L
# Save for good
/sbin/service iptables save

For reference, here is my iptable-save.txt file:

# Generated by iptables-save v1.4.7 on Thu Jul 24 08:28:03 2014
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [471:1082248]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p icmp -j ACCEPT 
-A INPUT -i lo -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 7222 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 8777 -j ACCEPT 
-A INPUT -j REJECT --reject-with icmp-host-prohibited 
-A FORWARD -j REJECT --reject-with icmp-host-prohibited 
COMMIT
# Completed on Thu Jul 24 08:28:03 2014

It should work immediately, but to test the “iptables-restore”, you should reboot. Main reference: https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-iptables-saving.html http://wiki.centos.org/HowTos/Network/IPTables

TIBCO EMS 8 on CentOS 6 VM

I needed to create a Virtual Box VM for my TIBCO experiments.

Here is how I created my base system, a CentOS VM with EMS 8.1.

This tutorial include all relevant scripts, and associated Gnome launchers.

Prerequisites

  1. Install VirtualBox and extensions on my laptop
  2. Create a CentOS 6.5 VM on virtual box (I chose “Minimal Desktop”)
    • (follow only the first section, the guest additions are better explained at step 4).
  3. Update the packages on CentOS
  4. Install the virtual box guest additions. (Great How-to here)
  5. Install a modern Oracle JDK. I installed version 7 (yum localinstall jdk-7u60-linux-x64.rpm).

Note: You could also take an existing image from a site like this one, but I prefer making my own.

On the target VM, I created only one non-root user (name=”user”).

I use the shared folder feature of Virtual Box to share file between the host and guest systems. If you choose this path, please make sure that the user you are using is in the group vboxsf, like so:

/etc/group file in vim editor
/etc/group file in vim editor

Install EMS

Nothing difficult here… a simple wizard based java installer. In my case, the tibco home is /opt/tibco. I specified /opt/cfgtibco as the configuration folder. In both cases, I had to create the folder with root and change the rights.

# /bin/bash
# As root !

cd /opt
mkdir tibco
mkdir cfgtibco
chown user tibco
chown user cfgtibco
chgrp user tibco
chgrp user cfgtibco
chmod 770 -R tibco
chmod 770 -R cfgtibco
Installer command
Installer command
TIBCO HOME setup
TIBCO HOME setup
Configuration folder setup
Configuration folder setup
Installation validation - Done !
Installation validation – Done !

Note: The installer did not work at first with the OpenJDK provided by CentOS. Hence the Oracle JDK prerequisite.

Note 2 : DO NOT try to reorganize the configuration folder. As will be seen below, EMSCA can regenerate and deliver a configuration. When it does, it take into account the original configuration folder.

Converting the configuration

I used the provided utility to convert the old configuration fileS to the single JSON config file required for EMSCA:

cd /opt/cfgtibco/tibco/cfgmgmt/ems/data
/opt/tibco/ems/8.1/bin/tibemsconf2json -conf tibemsd.conf -json tibemsd.json

Cleanup of old configuration (optional)

As they will not be used anymore, I like to move the “old-style” EMS configuration to another folder:

cd /opt/cfgtibco/tibco/cfgmgmt/ems/data
mkdir OLD_CONFIG
mv *.conf OLD_CONFIG/
mv *.txt OLD_CONFIG/
mv *.conf_template OLD_CONFIG/

Creation of “EMS JSON” launcher

To use the new configuration, the lauching script (in my case EMS_HOME/bin/tibemsd64.sh) must be adjusted:

cd /opt/tibco/ems/8.1/bin
./tibemsd64 -config "/opt/cfgtibco/tibco/cfgmgmt/ems/data/tibemsd.json"

Then, I create a launcher for the script :

gnome-terminal -e "gnome-terminal -e /opt/tibco/ems/8.1/bin/tibemsd64.sh"
Properties view of the desktop launcher
Properties view of the desktop launcher

Install EMSCA

EMSCA is better managed with a simple initiator properties files, such as this one:

com.tibco.emsca.data.dir=/opt/cfgtibco/tibco/cfgmgmt/ems/emsca_data
com.tibco.emsca.http.hostport=*:8080

Don’t forget to create the esmca_data folder:

cd /opt/cfgtibco/tibco/cfgmgmt/ems
mkdir emsca_data

The final setup should look like this:

EMS configuration directory structure
EMS configuration directory structure

The self contained web server can then be started with this command, which I decide to include in a launcher script on the desktop:

/opt/tibco/ems/8.1/bin/tibemsca --config /opt/cfgtibco/tibco/cfgmgmt/ems/data/emsca.properties

OR, as a Gnome shortcut:

gnome-terminal -e “/opt/tibco/ems/8.1/bin/tibemsca –config /opt/cfgtibco/tibco/cfgmgmt/ems/data/emsca.properties”

We then use the browser to connect…

Empty EMSCA
Empty EMSCA

At first, EMSCA is empty of any servers. We must “create” a server (connection)

9 localhost server creation

Then, it it a simple matter of following the server hyperlink to get in the main screen

NICE !
NICE !

Use EMSCA from your host system

To use EMSCA (or any other guest OS service) from your host system, follow this tutorial on port redirection with CentOS and VirtualBox.

EMS is nicer on Chrome in Mac OS !
EMS is nicer on Chrome in Mac OS !

Install Hermes JMS

1. Install a fresh Hermes with root (on Linux in my case)

Hermes as a simple Java installer wizard
Hermes as a simple Java installer wizard
Hermes installer is a simple "next,next,next" installer.
Hermes installer is a simple “next,next,next” installer.

2. Create a /home/USER/.hermes or /home/USER/hermes directory and copy the files from the /usr/local/HermesJMS/SOMETHING/cfg directory (again, only important on Linux)

mkdir ~/hermes
cp /usr/local/HermesJMS/cfg/* ~/hermes

Then I was able to start Hermes with /usr/local/HermesJMS/bin/hermes.sh

You can even a nice Gnome desktop launcher.
You can even a nice Gnome desktop launcher.

3. In Hermes, the first step is to get into the “Options-> Configuration…->Providers” section
4. Then, you can right-click to create a new provider. I named mine “EMS8.1”, but the value can be anything.

Pictured above : Not orignal naming.
Pictured above : Not orignal naming.

5. Again, use the right-click to select “add jars” and select EVERY JARS in the EMS_HOME/lib directory (use *.jar in the textbox to clean other files). Select the “Scan” option when asked.  Click “Apply” and close the configuration window with “OK”.

Use "*.jar" in the filename textbox to make it easier.
Use “*.jar” in the filename textbox to make it easier.
Hermes-Config-2
The end result should look like this.

6. The last step is to create a new Tibco EMS session (by right clicking on sessions in the main screen or using the menu bar). This usually looks a lot like this:

Could not be more simple...
Could not be more simple…

Everything is important here:

  • The first important selection is the “Loader”, which should match the provider we just created. This is critical for the rest of the form to work.
  • The TibjmsConnectionFactory is selected (see image above for complete class name), so Queues and Topics connections are possible.
  • The “Plug in” selection is also mandatory : choose “Tibco EMS”
  • Then, create the 3 required parameters in the Connection Factory section:
    • serverURL = tcp://HOST:PORT
    • userName = admin
    • userPassword = [empty in my case]

You can now right click on the session and try to discover the destinations (Topics & Queues). They will be added automagically if the connection is successful.

HermesJMS

Note: There may be a way to do some of this with JNDI, but I have not played with than yet.

Install GEMS

GEMS is a “native(TIBCO EMS APIs) and JMS based” administration and debugging tool. It is rough on the edges and unsupported by TIBCO, but it can also be more powerful than Hermes.
It is available for download here.(Original Article)

The installation is not complex. It consist of:

  • Unziping the file (I chose ~/Gems as the destination directory)
  • Slight adjustment of the startup script, like so:
#!/bin/sh

#Edit 1 : to allow script to be executed from anywhere
cd ~/Gems

#Edit 2 : Adjust EMS location
TIBEMS_ROOT=/opt/tibco/ems/8.1

TIBEMS_JAVA=${TIBEMS_ROOT}/lib
#Edit 3 : Change to jms-2.0.jar for EMS8 or higher
CLASSPATH=${TIBEMS_JAVA}/jms-2.0.jar:${TIBEMS_JAVA}/jndi.jar
CLASSPATH=Gems.jar:looks-2.3.1.jar:jcommon-1.0.16.jar:jfreechart-1.0.13.jar:${TIBEMS_JAVA}/tibjms.jar:${TIBEMS_JAVA}/tibcrypt.jar:${TIBEMS_JAVA}/tibjmsadmin.jar:${CLASSPATH}
CLASSPATH=${CLASSPATH}:${TIBEMS_JAVA}/slf4j-api-1.4.2.jar:${TIBEMS_JAVA}/slf4j-simple-1.4.2.jar
# echo ${CLASSPATH}
java -classpath ${CLASSPATH} -Xmx128m -DPlastic.defaultTheme=DesertBluer com.tibco.gems.Gems gems.props

Please note:

  • The “cd” in the beginning
  • The modification of TIBEMS_ROOT
  • The modification from jms.jar to jms-2.0.jar (EMS > 8.0 only)

The script can now be executed directly, or via launcher:

The cool icon is called gnome-gemsvt.png
The cool icon is called gnome-gemsvt.png
GEMS
GEMS just may be the most powerful graphical tool to configure and test EMS

TIBCO EMS Admin CLI

Last, but certainly not least, we add a launcher to the TIBCO EMS admin tool.

Note the "Application in terminal" option
Note the “Application in terminal” option
tibemsadmin(64) is crude, but powerful
tibemsadmin(64) is crude, but powerful

Conclusion

We now have a great testing VM, with administrative tools included !

The next steps could be to play with multiple instances of EMS and/or with SSL settings, or to explore EMSCA…

…then I’ll install more TIBCO products : BusinessWorks 6, BusinessEvents or others, and write more articles !

Done ! For now.
Done ! For now.

 

Convert VMware ESX .ova file for use in a VMware Player or Virtual Box VM

.ova Conversion to .vmk and .vmdk

Today I learned that the “.ova” packages provided by some vendor for VMWare ESX are from an open standard (OVF).

There is an existing VMWare tool (OVFTool) that can be used to convert any such “.ova” file to easily runable “.vmk” files.

The usage is simple enough :

ovftool.exe SOME_OVA_FILE.ova NEW_VMKNAME.vmk

I found the original information in this simple how-to.

Virtual box image creation

Note : For some reason, a “direct import” of the .ova file in Virtual Box would always fail… hence this very manual tutorial.

To create a virtual box image:

  • Create a new Virtual Machine.
  • Add all the “VMDKs” (Virtual Disk exported from in the previous section) as virtual disks in the new VM.
  • Boot & Pray™