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 220.127.116.11. 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:
[echo] domain 'jcr'
[echo] DbtDbDriver 'com.ibm.db2.jcc.DB2Driver'
[echo] DbtDbLibrary '/home/db2inst1/sqllib/java/db2jcc.jar:/home/db2inst1/sqllib/java/db2jcc_license_cu.jar'
[echo] DbtDbUser 'db2inst1'
[echo] DbtDbUrl 'jdbc:db2://localhost:50000/WPS6TCP'
[echo] DbtDbName 'WPS6TCP'
[java] [06/28/09 13:47:09.620 EST] Attempting to make connection using: jdbc:db2://localhost:50000/WPS6TCP :: db2inst1 :: PASSWORD_REMOVED
[java] [06/28/09 13:47:09.875 EST] ERROR: Error obtaining connecting for jdbc:db2://localhost:50000/WPS6TCP
[java] com.ibm.db2.jcc.b.SqlException: [ibm][db2][jcc][t4] Connection authorization failure occurred. Reason: Security mechanism not supported.
[java] at com.ibm.db2.jcc.a.b.m(b.java:1981)
[java] at com.ibm.db2.jcc.a.b.a(b.java:1565)
[java] at com.ibm.db2.jcc.a.bb.b(bb.java:3386)
[java] at com.ibm.db2.jcc.a.bb.a(bb.java:332)
[java] at com.ibm.db2.jcc.a.bb.a(bb.java:112)
[java] at com.ibm.db2.jcc.a.b.j(b.java:1259)
[java] at com.ibm.db2.jcc.a.b.b(b.java:1132)
[java] at com.ibm.db2.jcc.a.b.b(b.java:715)
[java] at com.ibm.db2.jcc.a.b.a(b.java:701)
[java] at com.ibm.db2.jcc.a.b.a(b.java:378)
[java] at com.ibm.db2.jcc.a.b.
[java] at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:166)
[java] at java.sql.DriverManager.getConnection(DriverManager.java:572)
[java] at java.sql.DriverManager.getConnection(DriverManager.java:165)
[java] at com.ibm.wps.config.db.Database.init(Database.java:139)
[java] at com.ibm.wps.config.db.validation.ValidationDriver.main(ValidationDriver.java:209)
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.