Updated for a 2018 Cognos 11 install
with 2013 updates for Cognos 10 installation
Intro
I tried to take a shortcut and get a 2nd Cognos gateway up and running by copying files, etc. rather than a proper install. At one time or another I feel I must have encountered just about every problem conceivable. I didn’t take great, systematic notes, but I’d like to mention some highlights while it is still fresh in my memory!
The Details
Note that I have a working gateway server running on the same version of Linux, SLES 11 SP1. So I thought I’d be clever and just copy all the files below /opt/cognos8 from the working server.
First Rookie Mistake
Let’s call our COGNOS_ROOT /opt/cognos8 for convenience.
Cognos 10 note: /opt/cognos10 would be a more sensible installation directory!
So you’re following along in the documentation and dutifully looking for /opt/cognos8/bin/cogconfig.sh, and not finding it? Me, neither. So I cleverly borrowed it from a working solaris installation. It’s all Java, right, no OS dependencies, what can go wrong? Ha, ha. You try:
./cogconfig.sh
and get:
Using /usr/lib64/jvm/jre/bin/java The java class is not found: CRConfig |
Long story short. Give up. Without telling anyone they moved it to /opt/cognos8/bin64. That’s assuming you’re on a 64-bit system like most of us are.
OK. Now you run it from the …bin64 directory, expecting better results, only to perhaps get something like:
./cogconfig.sh
Unable to locate a JRE. Please specify a valid JAVA_HOME environment variable. |
Long story short, java-1_4_2-ibm (java-1_6_0-ibm if installing a Cognos 10 gateway) is a good Java environment to install for Cognos Gateway. At least it is on SLES Linux. So you install that and set up environment variables like these:
export JAVA_BINDIR=/usr/lib64/jvm/jre/bin export JAVA_HOME=/usr/lib64/jvm/jre export JAVA_ROOT=/usr/lib64/jvm/jre |
Now you’re cooking. Run it yet again. You’re smart and know to set up your DISPLAY environment to a valid XServer you have access to. But even if the X application actually does launch and run (you may need some Motif or additional X packages, possibly even from the SDK DVD – see appendix A), if you try to export the configuration you’ll get an error like this:
java.lang.ClassNotFoundException: org.bouncycastle134.jce.provider.BouncyCastleProvider |
Cognos 10 note: I did not have this class missing in my Cognos 10 installation. Yeah!
Yes, you are missing the infamous bouncycastleprovider! This stuff is too good to make up, right? It’s a jar file that’s somewhere in the Cognos Gateway distribution, bcprov-jdk14-134.jar. In my case I need to put it here:
/etc/alternatives/jre/lib/ext
With that in place run it yet again. Now you may be unable to export the configuration with this error:
CAM-CRP-1057 Unable to generate the machine specific symmetric key. |
Does it ever end? Yes!
You may have old values of keys and what-not cryptography stuff from your copy of the other system. So you remove these directories and all their contents:
/opt/cognos8/{encryptkeypair,signkeypair}
And I even saw the following error:
02/03/2012,11:26:56,Err,com.cognos.crconfig.data.DataManagerException: CAM-CRP-1132 An error occurred while attempting to request a certificate from the Certificate Authority service. Unable to connect to the Certificate Authority service. Ensure that the Content Manager computer is configured and that the Cognos 8 services on it are currently running. Reason: java.net.ConnectException: Connection refused, com.cognos.crconfig.data.DataManager.generateCryptoKeys(DataManager.java:2730) |
I think it comes about if you save the default config without editing it and putting in a valid dispatcher URI, but I forget.
The main point towards the end was to start with a clean config by a:
cd /opt/cognos8/configuration;cp cogstartup.xml{.new,} |
, making sure there is no encryptkeypair and signkeypair directories, launching …bin64/cogconfig.sh, working with the GUI to define the dispatcher URIs to your working, running Cognos dispatcher, exporting it,
(Let me take a breath here. If that export succeeds, you’re home.)
and finally saving it, which also generates the system-specific keys.
That’s it! A bunch of green check marks are your reward. Hopefully.
Conclusion
In the end you will see that this “cheap method” of installing Cognos Gateway worked. We had a few bumps along the road, but we worked through them all. Now that we’ve seen just about every conceivable problem we have a treasure trove of documented errors and fixes should we ever find ourselves in this situation again.
There is one more Cognos Gateway problem we resolved, by the way, that was previously documented here.
Appendix A – Cognos 10 note
Yes, I referred to this document in my own installation of Cognos version 10 gateway component. The problems are very similar, and this was a big help, if I say so myself.
I notice I write a tight narrative. I have lots of tangential thoughts, but to list them all as I think of them would destroy the flow of the narrative. In this case I wanted to expand on the openmotif packages.
I got a missing libXm.so.4 message when launching issetup the first time. I determined this came from an openmotif package from my previous successful installation on another server. My new server had limited repositories.
> zypper search openmotif
produced these results:
S | Name | Summary | Type --+------------------------+----------------------------+----------- | openmotif21-demos | Open Motif 2.2.4 Libraries | package | openmotif21-libs | Open Motif 2.2.4 Libraries | package | openmotif21-libs | Open Motif 2.2.4 Libraries | srcpackage | openmotif21-libs-32bit | Open Motif 2.2.4 Libraries | package | openmotif22-libs | Open Motif 2.2.4 Libraries | package | openmotif22-libs | Open Motif 2.2.4 Libraries | srcpackage | openmotif22-libs-32bit | Open Motif 2.2.4 Libraries | package |
Well, I tried to install first openmotif21-libs-32bit then openmotif22-libs-32bit, but neither gave me the right version of libXm.so! I had versions 2, 3 and 6! So I simply did one of these numbers:
> cd /usr/lib; ln -s libXm.so.3.0.3 libXm.so.4
and, to my surprise, it worked!
More Errors Documented for completeness’ sake
At the risk of making this blog post a total mess, I’ll include a few more errors I encountered during the upgrade. Who knows who might find this useful.
Generating the cryptographic keys is always a hold-your-breath-and-pray operation. I had my upgrade files in place in a new install directory, /opt/cognos10. I ran bin64/cogconfig.sh like usual. It was suggested I could save the configuration even though the application gateway wasn’t running, so I tried that. No dice.
The cryptographic information cannot be encrypted. |
Fine. So probably the app server needs to be running before we save the config, right? So they got it running. I tried to save the config. Same error. The details were as follows:
[ ERROR ] CAM-CRP-1315 Current configuration points to a different Trust Domain than originally configured. [ ERROR ] The cryptography information was not generated. |
The remedy? Close the configuration and completely remove these directories beneath the /opt/cognos10/configuration directory:
– encryptkeypair
– signkeypair
– csk (actually I didn’t have this one. But I guess it should be removed if present)
I held my breath, re-ran cogconfig and saved. This time it worked!
I also had an error with my Java version:
./cogconfig.sh Using /usr/lib64/jvm/jre/bin/java The java class could not be loaded. java.lang.UnsupportedClassVersionError: (CRConfig) bad major version at offset=6 |
/usr/lib64/jvm/jre/bin/java -version |
showed
java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 2.3) IBM J9 VM (build 2.3, J2RE 1.4.2 IBM J9 2.3 Linux amd64-64 j9vmxa64142ifx-20110628 (JIT enabled) J9VM - 20110627_85693_LHdSMr JIT - 20090210_1447ifx5_r8 GC - 200902_24) |
I installed a newer Java:
zypper install java-1_6_0-ibm |
and got past this error.
April 20123 update
Just when you thought every possible error was covered, you encounter a new one. Cognos Mobile isn’t working so well on actual mobile devices so they wanted to try a Fixpack from IBM. No problem, right? They gave me
up_cogmob_linuxi38664h_10.2.1102.33_ml.rar
and I set to work. I don’t particularly like rar files for Linux, but I figured out there is an unrar command:
$ unrar e up_*rar
But after setting up my DISPLAY environment variable I get this new error running ./issetup:
X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 14 (X_GetGeometry) Resource id in failed request: 0x2 Serial number of failed request: 257 Current serial number in output stream: 257 IDS_MSG_PREFIXIDS_COPYRIGHT_LOGOIDS_MSG_PREFIXIDS_MSG_READ_ARCHIVE |
The solution? They downloaded a tar.gz version of the Fixpack. I unpacked that and had absolutely no problems with issetup! The really strange thing is that in both issetup are identical files. I use cksum to do a quick compare. Even setup.csp are identical files. I did an strace -f of the two cases but the salient difference didn’t pop out at me. The files present in the tar.gz seem to be fewer in number.
Another random error you will encounter sooner or later
You are doing a Save in cogconfig and you get:
13/05/2013,17:39:05,Err,CAM-CRP-1132 An error occurred while attempting to request a certificate from the Certificate Authority service. Unable to connect to the Certificate Authority service. Ensure that the Content Manager computer is configured and that the IBM Cognos services on it are currently running. Reason: java.net.ConnectException: Connection refused, com.cognos.crconfig.data.crypto.ConfiguringSession.configure(ConfiguringSession.java:35)com.cognos.crconfig.data.DataManager.generateCryptoKeys(DataManager.java:3037)com.cognos.crconfig.data.DataManager$4.run(DataManager.java:4169)com.cognos.crconfig.data.CnfgActionEngine$CnfgActionThread.run(CnfgActionEngine.java:394)com.cognos.crconfig.data.crypto.ConfiguringSession.configure(ConfiguringSession.java:35)com.cognos.crconfig.data.DataManager.generateCryptoKeys(DataManager.java:3037)com.cognos.crconfig.data.DataManager$4.run(DataManager.java:4169)com.cognos.crconfig.data.CnfgActionEngine$CnfgActionThread.run(CnfgActionEngine.java:394)com.cognos.crconfig.data.crypto.ConfiguringSession.configure(ConfiguringSession.java:35)com.cognos.crconfig.data.DataManager.generateCryptoKeys(DataManager.java:3037)com.cognos.crconfig.data.DataManager$4.run(DataManager.java:4169)com.cognos.crconfig.data.CnfgActionEngine$CnfgActionThread.run(CnfgActionEngine.java:394) |
This looks scary but has an easy fix. You aren’t communicating with the app server. Probably their dispatcher services are down. Bring them up and it should work fine – it did for me. This is assuming of course that you have your dispatcher URLs set up correctly.
I cloned my Cognos web gateway and got this error
I waited for a few weeks to examine the clone. I ran
$ ./cogconfig.sh
and got this error:
16/05/2013,15:57:35,Err,CAM-CRP-1280 An error occurred while trying to decrypt using the system protection key. Reason: javax.crypto.IllegalBlockSizeException: Input length (with padding) not multiple of 16 bytes |
Umm. I don’t have the solution yet. One thing is most highly suspect: in the meatime we re-generated the keys on the production web gateway. So I am hoping that is all we need to do here as well.
Resolved. Here is the process I followed – a sort of colonic for Cognos:
$ cd /opt/cognos10/configuration; rm csk/* signkeypair/* encryptkeypair/* cogstartup.xml
$ cd ../bin64; ./cogconfig.sh
Then in the GUI I re-defined the app servers in the dispatcher URI portion of the environment.
Then did a Save.
Worked like a champ – four green check marks.
cogconfig hangs
This happened to me on an older server. The IBM Cognos Configuration screen displays but it’s supposed to exit so you can get to the part where you edit the configuration and it never does.
Currently no known solution.
June 2018 update
Cognos 11 install problem
The Cognos 11 install was going pretty well. Until it came time to launch cogconfig. That generated this error:
cognos10:/web/cognos11/bin64> ./cogconfig.sh
Using /usr/lib64/jvm/jre/bin/java
Exception in thread "main" java.lang.UnsupportedClassVersionError: JVMCFRE003 bad major version; class=com/cognos/accman/jcam/crypto/CAMCryptoException, offset=6
at java.lang.ClassLoader.defineClass(ClassLoader.java:286)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:74)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:538)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$300(URLClassLoader.java:77)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:1041)
at java.security.AccessController.doPrivileged(AccessController.java:448)
at java.net.URLClassLoader.findClass(URLClassLoader.java:427)
at java.lang.ClassLoader.loadClass(ClassLoader.java:676)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:358)
at java.lang.ClassLoader.loadClass(ClassLoader.java:642)
at java.lang.J9VMInternals.verifyImpl(Native Method)
at java.lang.J9VMInternals.verify(J9VMInternals.java:73)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:133)
at com.cognos.cclcfgapi.CCLConfigurationFactory.getInstance(CCLConfigurationFactory.java:59)
at com.cognos.crconfig.CnfgPreferences.<init>(CnfgPreferences.java:51)
at com.cognos.crconfig.CnfgPreferences.<clinit>(CnfgPreferences.java:36)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:199)
at CRConfig.main(CRConfig.java:144) |
Note my system java version is woefully out-of-date:
$ /usr/lib64/jvm/jre/bin/java ‐version
java version "1.6.0" Java(TM) SE Runtime Environment (build pxa6460sr16fp15-20151106_01(SR16 FP15)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr16fp15-20151020_272943 (JIT enabled, AOT enabled) J9VM - 20151020_272943 JIT - r9_20151019_103450 GC - GA24_Java6_SR16_20151020_1627_B272943) JCL - 20151105_01 |
whereas the Cognos-supplied Java is two versions ahead:
cognos10:/web/cognos11> ./jre/bin/java ‐version
java version "1.8.0" Java(TM) SE Runtime Environment (build pxa6480sr4fp10-20170727_01(SR4 FP10)) IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20170722_357405 (JIT enabled, AOT enabled) J9VM - R28_20170722_0201_B357405 JIT - tr.r14.java_20170722_357405 GC - R28_20170722_0201_B357405_CMPRSS J9CL - 20170722_357405) JCL - 20170726_01 based on Oracle jdk8u144-b01 |
Instead of the previous approach which involved upgrading the system Java, I decided to just try the Java version Cognos itself had installed. In the following commands note that my installation directory was /web/cognos11.
$ cd /web/cognos11; export JAVA_HOME=`pwd`/jre
$ ./cogconfig.sh
Using /web/cognos11/jre/bin/java 06/06/2018,11:13:04,Dbg,Use Customized settings for font and color. SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/web/cognos11/bin/slf4j-nop-1.7.23.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/web/cognos11/configuration/utilities/config-util.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [org.slf4j.helpers.NOPLoggerFactory] 06/06/2018,11:13:10,Dbg,The original cogstartup.xml file is clear text. Don't back it up. |
That is to say, it worked! I’ve often seen software packages install their own versions of Java. This is the first time I thought to take advantage of that. Wish I had thought of this approach during the Cognos 10 install!