One of the great things about how DB2 releases fixpacks is that they are installable. What I mean by this is that you don’t have to install the first version of the software and apply patches to it, you can just apply the patch at the outset.

When testing out DB2 9.7 fixpack 2 on Linux, I hit a weird error:

It was a bit more like a major error. The DB2 installer could not create the instance user and so could not create the instance. Which means the system is pretty much useless. The following turned up in the db2setup.log:

What was interesting was the installer would breeze through creating the groups, but baulk on creating the users. The problem turned out to be a mismatch between the algorithm used to encrypt and read back the passwords in the response file. Something changed in the algorithm in DB2 9.7 FP2 and I was using an old response file from the GA version of the code . Both versions are incompatible with each other. You can clearly see the differences below.

9.7 GA, 9.7 FP1 (also works with 9.5) .

9.7 FP2

Obviously security has been increased in FP2 because the password hash is so much longer. Please note that it’s not forwards compatible either. What I mean by this is that the newer version of the response file will not work with older versions of the code either.

To conclude, the solution in this case is simple. Rerun the installer that comes with DB2 9.7 FP2 and generate a new response file for use with this version. I looked through the DB2 APARs list trying to find the fix that changed the encryption algorithm, but couldn’t see it.

Recently, someone sent me a Windows DB2 backup for me to look at, and I wanted to move it to a Linux machine.

Here’s some steps about how you would do this.

1. On the source machine run:

where is the name of the database you want to move.

2. Copy the database.sql to your destination machine.

3. Create a database on the destination machine. You can use the same name, or use a different name and edit first connect statement in the database.sql file to point to the new name.

4. If you look at the database.sql, you will notice that the CREATE TABLESPACE commands will have paths in them. This will probably present a problem, since the paths are unlikely to exist on your destination machine. There are a number of ways you could deal with this, but the easiest in my opinion is to just use DB2′s automatic storage feature and let DB2 worry about it. To show you what I mean by this, here is a tablespace definition from my source database script, straight from db2look.

You can see that a Unix/Linux DB2 install would puke on the path in there. Using automatic storage command this becomes:

Much simpler, but you will need to change these tablespace definitions by hand.

5. After fixing up the tablespace paths, try executing:

I had a problem on my system, doing a Windows -> Linux restore. The database.sql had Windows line endings in it, and so when running it on Linux the command just hung. Running dos2unix database.sql fixed it. (This problem was the actual point of this post, but it seemed hard to explain by itself, so…. here we are).

6. Now you should have a skeleton database on the destination, with all the tables there just ready to receive data. To copy the actual data, we’ll be using db2move.
On the source machine, create a new folder and change into it, and then run:

7. This should fill the folder up with .ixf and .msg files . Copy the entire folder to your destination machine.

8. On the destination machine change to the export folder you just copied over and run:

9. db2load temporarily suspends the referential integrity constraints of DB2. This is done so it doesn’t matter which order you load tables in. But since you have suspended these checks while the data is being loaded in you will need to go and make db2 check each table, to make sure that any referential integrity constraints in the database are valid. If you don’t, you get back a message like this when accessing any tables that you have loaded:

This means – “You need to check this table, to make sure it is valid” .

To do this, you can query the system catalog table to get back a list of all the tables that need checking, and with a little awk, generate a script to run against the database. There’s probably a prettier way to do this, but it works.

Now you’re done. If you run a simple select statement against one of the tables you have loaded into the database, DB2 should return with the data. It’s worth noting that this method will work if changing versions of DB2, and will also cover moving from 32 bit versions of DB2 to 64 bit.

All this change has thrown up some new problems however. For each of the installs I was doing, the system would hang when trying to install DB2.

When there is a problem with the db2 install, the first place to go is the /tmp/db2setup.log. Inside that it seemed to be hanging on the instance creation step.

Looking through the output of ps -ef | grep db2, I saw a suspicious process called UpdateAutoRun.sh.

I couldn’t find a DB2 specific technote for this error, but a bit of searching brought up this one from Tivoli Monitoring (ITM). Apparently DB2 installs an instance of ITM along with DB2 – I’m not sure what it is for. Anyway, there seems to be a dodgy script inside the ITM that relies on the venerable text editor ‘ed’. Without ed installed the log file /itma/logs/UpdateAutoRun.log keeps filling up with the line:

Installing ed in (even while db2setup is running!) allows this script to finish and the rest of the install to complete successfully.

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.

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

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:

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 ” modifiers on the end of the database create command. So how about this?

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 ” type commands again.

Open /etc/pam.d/common-password in a text editor and change this line:

to

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:
SHA512

MD5

(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.