DB2 and ConfigEngine : Security mechanism not supported

I try to post really random solutions here, and this one’s a doozy ! I was updating a production machine from Portal 6.1.0 to 6.1.0.2. I always run the ConfigEngine tasks validate-standalone-ldap and validate-database-connection before I run any Portal update to make sure that the update won’t fail from something silly like a missing password. I’d highly recommend this practice on your Portal systems.
This time when running validate-database-connection, I ran into this error:

It looked like the problem I’d seen on Ubuntu, where the database password was hashed with an unsupported scheme, but it couldn’t be, because this was on a plain old RHEL system. The difference was that I’d recently changed DB2’s database manager settings from AUTHENTICATION = SERVER to AUTHENTICATION = DATA_ENCRYPT . DATA_ENCRYPT is good because it will send your sql data and your authentication details encrypted across the wire.

Anyway, to make the validation work on a system where you have enabled the DATA_ENCRYPT parameter, just add securityMechanism=13; to the end of the database url. So mine becomes:

So how would the system work in any case, if the database url was wrong?!? The answer is clear after delving into the WebSphere admin console a little bit. I’d configured the custom properties of each Portal datasource post database transfer to work with DATA_ENCRYPT, but not the database urls in wkplc_comp.properties. Here’s where you would set it.

It is important to emphasize that the wkplc*.properties file in ConfigEngine are templates only, and don’t affect the running of the system, until you run a ConfigEngine task against them. Only then do their values get copied to the actual Portal server.

Checking the version of the Oracle JDBC driver jar

I’m working on a problem now where we need to use the Oracle 10g driver against a 9i database. There’s a note in the infocenter about it .But how to do you check which version of the driver you are using ? The filename of the driver is the same between each version of Oracle (ojdbc14.jar), so that’s not going to do it.

To check it out, unzip the driver and read the META-INF/MANIFEST.MF file. Here’s mine:

Also Portal (and regular ol’ Appserver) will tell you as they initialize in the SystemOut.log, just try this trusty command :

cat SystemOut.log | grep -A 2 “Oracle JDBC”

and you get back something like :

What! 9.2.0.8! Looks like I’ve got the wrong one on there.