Updated 28th October, 2010
Newer versions of DB2 address this problem. Read about it here.
Two posts in one day, wow. It’s all part of our special series: how to install and configure WebSphere Portal 6.1 on Ubuntu. This isn’t a Portal only issue, rather it’s a DB2+Ubuntu issue.
After getting Portal installed on this Ubuntu machine, you’re probably going to want to transfer the default Derby database to something more robust like DB2. So you edit wkplc_comp.properties and wkplc_dbtype.properties, and start to run:
And you get this in the ConfigTrace.log
[sqlproc] Database autocommit parameter true
[sqlproc] No delimiter has been specified, using [;] to separate the SQL statements.
[sqlproc] Reading file /opt/WebSphere/wp_profile/ConfigEngine/config/database/work/db2/createBufferpools.run
[sqlproc] Could not connect to database
[sqlproc] com.ibm.db2.jcc.b.ao: [jcc][t4][3.53.70] Connection authorization failure occurred. Reason: Local security service non-retryable error. ERRORCODE=-4214, SQLSTATE=28000
Hmm, ok, I thought db2 was working. A good habit when debugging these things is to take the piece that ConfigEngine is trying run and run it independently. So right now I want ConfigEngine to create an empty db2 database that I can run database-transfer against. Try this:
db2 create db WP610 using codeset UTF8 territory au pagesize 8192
And that comes back successfully. However, that command sequence is not an accurate representation of what ConfigEngine is actually doing. We’re running ConfigEngine as root. But the ConfigEngine script is using the “user db2inst1 using
SQL30082N Security processing failed with reason "15" ("PROCESSING FAILURE").
Ah ha, a failure. In the first example, DB2 already trusts the user that we’re logged is as (db2inst1), so it doesn’t need to go back to the operating system and authenticate it. In the second example, we are logged in as root, so db2 needs to go to the operating system and authenticate the user. Ubuntu uses the tried and true passwd + shadow file combo to store usernames and their associated passwords. The trouble is since Ubuntu 8.10, it uses the newer and more secure SHA512 hashing function to store the passwords, and DB2 doesn’t understand SHA512. So the workaround is to change the hashing function in use on the machine, reset the password and then we should be able to use the “user db2inst1 using
Open /etc/pam.d/common-password in a text editor and change this line:
Then run passwd db2inst1 and put the same or a new password. If you look at the shadow file , the hash will change from something like this:
(The unencrypted password here is ‘password’ – don’t get too excited!) .
Now try running ConfigEngine.sh create-database again. It should work. Make sure you change the system /etc/pam.d/common-password back to sha512, as you want the rest of your users to use this hashing function as it is more secure than md5sum . Hopefully DB2 should address this in a fixpack.
I’ve also recently seen this problem on Fedora 10 as well. The only change to note is that the file to edit is /etc/pam.d/system-auth , not /etc/pam.d/common-password .
Well that saved. Thx!
Graham, thanks for this – saved my bacon yet again – http://portal2portal.blogspot.com/2010/06/problems-with-db2-udb-passwords-on.html
Cheers Dave, thanks for the link!
I found using the
command on CentOS would set an MD5 password hash without requiring you to change any system files. I think that’s important on an active system.
Hi Fondfire – thanks so much for the tip, that’s a much better way to do it.
I would also check the case of the user id being used to connect to the DB. Using the proper case (for eg. all lower case or upper case) worked for me for this issue.
Thanks! Worked like a charm.