29 November 2013

So, this time something about powerful security tool from IBM - Tivoli Security Policy Manager 7.1. This software let's you manage your security policies (surprisingly :) on various servers from single point of authoring and distribution (PAP, PDP). It can manage multiple policy enforcement points (PEPs) on the online and offline basis (online means pushing policies to PEPs on-the-go, while offline means that you can author policies on PAP and distribute them asynchronously, or even over portable memory (when your PEP is in DMZ or something like that). Above features are very well described on IBM pages, so let's cut this here.

The problem I had with installation was a bit surprising (believe me, I overcame numerous problems with this product before, that included temporarily giving up on installing TSPM 7.1 on 64bit Linux - which is possible only after adding 32bit compatibility libraries), so when this time it went smooth, up to some point, I was very disappointed to see it failed again.

Why would it have problem with hostname when I'm installing locally? Of course! Quick glance on /etc/hosts revealed that only loopback address has been defined, so no hostname could be resolved to any ip address, except for localhost. What is this needed for? Behind the scenes of Installation Manager, there's some work done over wsadmin (WAS administrative client), which essentially needs network infrastructure working fine, that includes possibility to resolve system's own hostname. If that fails, wsadmin has no point to connect to.

Adding machine's own ip and hostname (both fully qualified and short) to /etc/hosts solved the issue.

Now, one interesting thing to add here is that problem can be seen even by looking oin WebSphere cell name. It is:

nullNode01Cell

and it is very wrong - it usually (by default, at least) should contain hostname - which in that case was missing and replaced by null. Of course you may fancy naming your machine "null" but that was not the case.

05 November 2013

I started some experiments with Android SDK recently, and came against the problem with creating virtual sdCard image for usage by the AVD (Android Virtal Device). Unfortunately mksdcard utility kept either returning errors or just doing nothing, I had to go some lengths and try to create sdcard image on linux 32bit. I did not find any relevant hits on google how to work around my issue (create virtual sd card on Windows 7 64bit with mksdcard).

Anyway, here it's - available for you to download, it has just 120Megs to be handy.

CRIMA5096821AE 'jar file com.ibm.was.backup.nsf_8.0.4.20120410_0000' not found in /var/tmp/IBM/IMShared.

In that case, you might start to worry, because most probably somebody deleted IMShared directory from your filesystem. And this is very bad thing, since Installation Manager needs this to operate on already installed packages. It stores vital data for IM operation, such as sychronization repos, libraries etc.
DO NOT REMOVE IT or you won't be able to use your IM with existing installation (to be precise: particular software packages for which this particular IMShared directory was chosen, as this may vary between packages, using the same always is a default).

There's nothing but one thing you can do about it - if you happen to work in multiple machine environment, you might have different machine with identical software set installed (like prod/dev/test systems). In that case, you might try to copy IMShared directory from other machine with identical set and in MIGHT work. Not guaranteed, but sometimes it's a last resort.

02 October 2013

It's been quite long since I posted here. Yet I have one new tip for you today:
The problem was that WebSphere 8.5 server did not recognize components to trace after application deployment, and after finally appearing in the traceable components tree did not log all expected output to trace log. As a result we wasn't able to troubleshoot the installation, not to mention that some of the log output was required by defined use cases of the designed solution.
After some search, asking here and there, a colleague of mine (thanks, Agnieszka!) noticed the following entries in the SystemOut.log file of the server when the troublesome application was deployed:10/2/13 13:42:10:331 CEST] 00000042 SystemErr R SLF4J: Class path contains multiple SLF4J bindings.[10/2/13 13:42:10:331 CEST] 00000042 SystemErr R SLF4J: Found binding in [bundleresource://243.fwk-1319487885:1/org/slf4j/impl/StaticLoggerBinder.class][10/2/13 13:42:10:331 CEST] 00000042 SystemErr R SLF4J: Found binding in [wsjar:file:/opt/ibm/WebSphere/AppServer/profiles/AppSrv01/installedApps/localhostNode01Cell/xxxxx/lib/slf4j-jdk14-1.6.6.jar!/org/slf4j/impl/StaticLoggerBinder.class][10/2/13 13:42:10:332 CEST] 00000042 SystemErr R SLF4J: Found binding in [wsjar:file:/opt/ibm/WebSphere/AppServer/profiles/AppSrv01/installedApps/localhostNode01Cell/xxxxx/lib/slf4j-log4j12-1.7.2.jar!/org/slf4j/impl/StaticLoggerBinder.class][10/2/13 13:42:10:332 CEST] 00000042 SystemErr R SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.[10/2/13 13:42:10:357 CEST] 00000042 SystemErr R SLF4J: Actual binding is of type [org.slf4j.impl.JDK14LoggerFactory]
and apparently this was causing the server to make wrong class pickup the logging (and hence missing output as that class missed appropriate configuration).
I came up with the idea of removing one of the conflicting classes from ear with console option "Remove file" and selecting whole jar (lib/slf4j-log4j12-1.7.2.jar). After application restart logging started to work as expected!
Good luck!Env: WebSphere 8.5.0.2 ND, Linux rhel 6 64bit, application build with Maven (some predefined class includes defined).

21 May 2013

If you happen to have problem running your build in RTC and your builds end up with:

2013-05-21 10:29:15 [Jazz build engine] Deleting fetch destination "/db2data/BuildWorkspace" before fetching ...com.ibm.team.build.common.TeamBuildException: CRRTC3505E: The following fetch destination cannot be deleted: "/db2data/BuildWorkspace". For more details, open the help system and search for CRRTC3505E.at com.ibm.team.build.internal.engine.JazzScmPreBuildParticipant.preBuild(JazzScmPreBuildParticipant.java:218)at com.ibm.team.build.internal.engine.BuildLoop.invokePreBuildParticipants(BuildLoop.java:881)at com.ibm.team.build.internal.engine.BuildLoop$2.run(BuildLoop.java:685)at java.lang.Thread.run(Thread.java:738)

15 May 2013

Just today I wanted to install Rational Reporting for Development Intelligence (RRDI) 2.0.1 on 64bit SuSE 11. I got my repository, I got Installation Manager 1.6 (it's a must!) uznipped and started the ride.

The first error IM thrown at me was "Installation failed with code status =127" and investigation in the IM log files (/var/ibm/InstallationManager/logs/native/...) shown:

/opt/IBM/RRDI/install/cognos_bi/linuxi38664h/issetup: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory
So, I looked google up and found that I'm missing some libraries for my system, namely:

Open Motif 2.2.4 Libraries (openmotif22-libs-2.2.4-189.1.i586.rpm)After getting and installing it (for 64bit) I rerun the installation....and failed again. I found then some tip to link libraries from /usr/lib64 into /usr/lib and during next installation attempt I ran into:/opt/IBM/RRDI/install/cognos_bi/linuxi38664h/issetup: error while loading shared libraries: libXm.so.3: wrong ELF class: ELFCLASS64So, fine, some progress but different error :) Searched again, and found that this means wrong bitness of the libraries, so I went back to RPM search and got 32bit libraries, unlinked those 64bit from /usr/lib, installed the package and...this time success! I'm no Linux expert, but that occured a bit strange to me, that I eventually solved it by installing 32bit libs on 64bit system. Anyway, should you run into the same problem, perhaps this helps you.Good luck, comments welcome!

05 March 2013

I looked over the net for sample response files for profile creation in WAS 8.5, but I found none. Well, I didn't expect much of a revolution in comparison to V7 or V8, but still, better be safe than sorry :)

So I ended up converting possible listed manageprofiles flags into response file entries, in a traditional manner. The result was as follows and you can safely use it as a starting point for your profile management automation.

#profile name and capabilitiesprofileName=P01DevprofilePath=/opt/IBM/WebSphere/AppServer85/profiles/P01DevtemplatePath=/opt/IBM/WebSphere/AppServer85/profileTemplates/default#location and nameshostName=chronos.warszawa.pl.ibm.comnodeName=P01DevNodecellName=P01DevCellserverName=P01DevS01#starting portstartingPort=4000#certificatespersonalCertDN=cn=P01DevS01\\,ou=Root=Certificate\\,ou=P01DevNode\\,ou=P01DevCell\\,o=IBM\\,c=PLsigningCertDN=cn=P01DevRoot\\,ou=Root=Certificate\\,ou=P01DevNode\\,ou=P01DevCell\\,o=IBM\\,c=PL#standard WAS keystore/truststore passwordkeyStorePassword=WebAS#admin securityenableAdminSecurity=trueadminUserName=devadminadminPassword=<yourpassword>

18 February 2013

If you happen to deploy CLM 4.0.1 (formerly known as Jazz Team Server/Requirements Composer/Requirements Management etc.) and when you further try to customize it (in my case customization was attempt to deploy BuildForge Connect Adapter for CLM) you may run inot some CLM dashboard pages unresponsive. Particularly, admin.war application stops responding and seems to have some sort of authentication issues. In my case, when I tried to go to Home->Collaborative Lifecycle Project Management page, I received the follwing error in the browser:

I wondered what to do about it, and finally I saw that all troublesome pages are in /admin context. As my CLM was deployed to WAS 8 server, I simply redeployed (by Update) admin.war application from the console. It worked as a wonder!

to do this go to Websphere applications -> tick admin.war, click Update and find original file in

<CLMInstallDir>/server/webapps, proceed through Nexts, and save configuration afterwards. Then restart application and it should be working.

This trick also works with jts.war application, if you happen to have any trouble with it (with similar errors). Of course, I assume that your previous configuration was in general ok, because war Update does not fix any database content issues and so on. (for db/config problems you should use repotools but that's another story)

22 January 2013

I have just ran into this problem today, when configuring my test instance of TAMeSSO (lately known as ISAM - IBM Security Access Manager for Enterprise Single Sign-on).

After installing WAS7 and IMS server package, I tried to configure my IMS server. But it failed with error SQL06013N on WAS side, when attempting to create DB tables (on the screen you can see below, procedure dropped with error at ~6%)

After a quick search and a conversation with a colleague I found solution: to increase pagesize in your database to at least 8K. Actually, it is listed as requirement here:

but there is a slight chance you might omit that :) (I did...)

So, be sure that your database have been created with pagesize of 8K. If not, drop it and recreate it with a proper setting. The reason for it being necessary is a requirement for an index tablespace to be large enough to house an indexes for a colums of a specified size. Here it was 1024 VARCHAR + 128 bit for index, which gives over 1024, and hence requires 8K Pagesize. Details can be found here

02 January 2013

A colleague of mine run today into a problem while trying to attach ACL to a protected object seen in the objectspace tree. Although being "seen" by both WPM console and pdadmin client via

object show /xxx/yyy/subcat

command, trying to use

acl attach /xxx/yyy/subcat ACL_name

resulted in getting below error:

Error: HPDAC0457E The
protected object name is invalid. (status 0x1005b1c9)

At the same time attaching ACLs to parent and child objects was just fine.

We checked initial loading scripts, and we found that there were only entries for super- and sub- items, like:

/xxx/yyy/ and then for /xxx/yyy/subcat/subsubcat/ but not for the middle one

So what was happening was that /xxx/yyy/subcat wasn't really created before, but only was visible as a tree level, because TAM had to show something in that place. Then the fix was easy, we just created the missing object with