IBM InfoSphere Server (WebSphere) not connecting to xmeta

Recently we were not able to connect to xmeta database when starting IBM InfoSphere Server.

WebSphere was not able connect to xmeta DB2 database which was running on the same machine, however you could manually connect to the xmeta database using db2 connect.

Snippets of WebSphere logs:

[7/8/11 2:24:09:496 EDT] 00000000 JMSRegistrati A WMSG1611I: The installed level of the WebSphere MQ messaging provider is

7.0.1.2.

[7/8/11 2:24:09:499 EDT] 00000000 JMSRegistrati I WMSG1703I: RAR implementation version 7.0.1.2-k701-102-100504

[7/8/11 2:24:09:517 EDT] 00000000 ObjectPoolSer I OBPL0010I: The Object Pool service started successfully.

[7/8/11 2:24:12:468 EDT] 00000000 SystemOut O [org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl] ERROR: Error

getting Connection from DriverManager with url (jdbc:db2://idmdmndev:50000/xmeta) and driver (com.ibm.db2.jcc.DB2Driver)

[7/8/11 2:24:12:470 EDT] 00000000 SystemOut O DB2 SQL Error: SQLCODE=-30082, SQLSTATE=08001, SQLERRMC=42;ROOT CAPABILITY

REQUIRED;, DRIVER=3.58.135

[7/8/11 2:24:12:493 EDT] 00000000 OjbPersistent E

org.apache.ojb.broker.PersistenceBrokerException: Can't lookup a connection

at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localBegin(Unknown Source)

at org.apache.ojb.broker.core.PersistenceBrokerImpl.beginTransaction(Unknown Source)

at org.apache.ojb.broker.core.DelegatingPersistenceBroker.beginTransaction(Unknown Source)

at org.apache.ojb.broker.core.DelegatingPersistenceBroker.beginTransaction(Unknown Source)

at com.ascential.xmeta.persistence.orm.impl.ojb.OjbPersistentEObjectPersistenceRegistry.loadPackageCache

(OjbPersistentEObjectPersistenceRegistry.java:437)

atcom.ascential.xmeta.persistence.orm.impl.ojb.OjbPersistentEObjectPersistenceRegistry.initialize

(OjbPersistentEObjectPersistenceRegistry.java:134)

After working thru all possible scenario, and gooling all around.

We found that the db2inst1/sqllib/security security is messed up.

When we moved db2inst1 from /home to /db2home

we did recursive chown to db2inst1 which basically screwed up the xmeta login permission

https://www-304.ibm.com/support/docview.wss?uid=swg21428687

Here is the error:

db2inst1@mdc1pr009 /db2home/db2inst1(12)$ db2start

07/08/2011 03:10:07 0 0 SQL1026N The database manager is already active.

SQL1026N The database manager is already active.

db2inst1@mdc1pr009 /db2home/db2inst1(1)$ db2 -t

(c) Copyright IBM Corporation 1993,2007

Command Line Processor for DB2 Client 9.7.0

You can issue database manager commands and SQL statements from the command

prompt. For example:

db2 => connect to sample

db2 => bind sample.bnd

For general help, type: ?.

For command help, type: ? command, where command can be

the first few keywords of a database manager command. For example:

? CATALOG DATABASE for help on the CATALOG DATABASE command

? CATALOG for help on all of the CATALOG commands.

To exit db2 interactive mode, type QUIT at the command prompt. Outside

interactive mode, all commands must be prefixed with 'db2'.

To list the current command option settings, type LIST COMMAND OPTIONS.

For more detailed help, refer to the Online Reference Manual.

db2 => connect to xmeta user xmeta using xmetadev;

SQL30082N Security processing failed with reason "42" ("ROOT CAPABILITY

REQUIRED"). SQLSTATE=08001

Solution:
1.) cd to sqllib/security
2.) run: ls -l
3.) Check the permission's on the db2chpw and db2ckpw they should be:

-r-s--x--x 1 root inst1 51195 Dec 1 15:33 db2chpw
-r-s--x--x 1 root inst1 3534773 Dec 1 15:33 db2ckpw

4.) Also check to see if they are owned by root.
5.) If not owned by root, log in as root and run:

db2iupdt -k

and then check if db2ckpw is now owned by root.

6.) If you need to change the permission's of those files run the following commands (this needs to be done as root, since the files are owned by root):

chmod 4511 db2chpw
chmod 4511 db2ckpw

Also,
Log in as root and locate your db2rfe.cfg found in DB2DIR/instance.
Check the file to make sure it has:

RESERVE_REMOTE_CONNECTION=YE