Posts Tagged TRA
Recently I got into the situation that somebody used some interface a way it was not designed for and so created an out-of-memory situation which couldn’t be handled by the engine itself. So now I got the case that one client block the complete service due to invalid requests which he shouldn’t do in the first place.
In the short term there seemed to be only one solution, block the client. So I began to search around how this could be done.
The easiest way to achieve this would be to change the authentication for this service. Unluckily this service is used by a lot of other clients, so I can’t change it out of the blue. Next thing that came to my mind was using the underlying tomcat to do some IP-based blocking. After some searching around I gave that one up. Tibco has a really complex deployment model for BusinessWorks so I wasn’t able to even find the process-specific section for the tomcat engine.
After some searching around in the documentation (actually several hours – hooray to a usable documentation) I found some parameter which allows you to block IPs with some TRA-file parameters. In case you want to look it up yourself it is in the BusinessWorks documentation under ‘Administration’ -> Chapter 8 ‘Custom Engine Properties’ -> ‘Available Custom Engine Properties’ (and another hooray to the excellent formatting – Note to Tibco: HTML has tags, so you can do more with the content then continuous text – even some breaks would enhance the experience).
So back to the point:
Both tags are rather self explanatory so you can use right away. Tibco says you can use it with a single IP, a list of IPs (comma-separated) or regular expression. As stated before this highlight of a documentation doesn’t say what reg-exp syntax means. I guess Tibco means they use the Tomcat engine for evaluation of these values an that means they use the Java syntax described here.
Recently I got a hardware upgrade so I could finally switch to a 64-bit environment. To fully use that machine I wanted to install TIBCO in 64-bit mode. After starting the installation I got this message:
TIBINS202527: Error: ERROR: You are running a 64-bit product installer on a 32-bit system.
This is not supported.
The Problem was I was running a 64-bit OS with a 64-bit Kernel:
uname -a Linux client1 18.104.22.168 #1 SMP PREEMPT Tue Feb 17 17:42:33 CET 2009 x86_64 GNU/Linux
So I tried to find the problem. First I needed some more output what the installer is actually doing. So I used the logging option to get all the debug output.
./TRA.5.6.0-suite_linux24gl23_x86.bin -console -is:log output
So when you look closer to this log you can see that the command which is running the installer looks like this:
Executing launch script command: “/tmp/isjI8lFYy/bin/java” -cp “”:”TRA.5.6.0-suite_linux24gl23_x86.jar”:”TRA.5.6.0-simple_linux24gl23_x86.jar”:”tibrv.8.1.1-simple_linux24gl23_x86.jar”:”jre.1.5.0-simple_linux24gl23_x86_64.jar”:”Designer.5.6.0-simple_linux24gl23_x86_64.jar”:”tpcl.5.6.0-simple_linux24gl23_x86.jar”:”hawk.4.8.1-simple_linux24gl23_x86_64.jar”:”/tmp/isjA5jEsB/TRA.5.6.0-suite_linux24gl23_x86.jar”:”” -Dtemp.dir=”/tmp” -Dis.jvm.home=”/tmp/isjI8lFYy” -Dis.jvm.temp=”1″ -Dis.media.home=”/tmp/isjA5jEsB/TRA.5.6.0-suite_linux24gl23_x86.jar” -Dis.launcher.file=”/home/jens/tmp/TIB_tra-suite_5.6.0_linux24gl23_x86_64/./TRA.5.6.0-suite_linux24gl23_x86.bin” -Dis.jvm.file=”/tmp/isjI8lFYy/jvm” -Dis.external.home=”/home/jens/tmp/TIB_tra-suite_5.6.0_linux24gl23_x86_64/.” -Xms20m -Xmx128m run -home TRA.5.6.0-suite_linux24gl23_x86.jar “-console”
Now that I had the command which is starting the installer I began to trace what this process is doing. To do a strace properly you just have to prepend ‘strace’ and than redirect the error output to a file (cause it is quiet a lot). So after doing this I found something interesting in the log.
[pid 32651] execve(“/bin/uname”, [0xffffffffdf47dc88, “-p”], [/* 1757 vars */]) = 0
As you can see it runs the command ‘uname -p’. This command returns ‘unknown’ for a default debian system. You also have this problem if you are running a self compiled kernel from kernel.org. As for the TIBCO supported systems (SUSE ans redhat) they return something different. After trying the same command on a openSUSE I found that ‘x86_64’ should be the correct string. After I bit of trial and error I found out that the result of this command is written to a file name ‘kernelbits_jens.txt’ in the temp directory.
So here the simple solution to the problem.
You just need to create the arch file manually and make it read-only so the installer can’t overwrite it. Here the command:
echo 'x86_64' > kernelbits_`whoami`.txt
Now the installer worked absolutely fine for me.
I already notified the TIBCO support about the problem. As for now there will be no fix. But I hope they will correct this behavior for future installer.