1. Install libstdc++5 from here. Apparently this has been dropped from karmic (9.10) but you can use 9.04 packages instead and it will work.

2. Make sure you can ping yourself on the fully qualified hostname that you will be using in the install. This is a good general tip for installing Portal. If the machine doesn’t respond, add an alias in your /etc/hosts file, like this:

Also think about disabling any firewalls . The install process needs to be able to connect to certain ports running on your machine.
If you let the install run all the way through, and then re enable your firewall after, debugging and adding new firewall exceptions should be way easier.

3. Drop this file in /etc . It will make AppServer think that you are running RHEL
5, which is a supported OS.

4. Unlink /bin/sh and link it to /bin/bash, like this:

Here’s a more detailed post about why you need to do this, if you are interested.

5. Don’t use sudo ./install.sh, but rather execute sudo su and then run ./install.sh . The installer executes a ConfigEngine.sh task late in the install, and if you use sudo to execute install.sh, the installer will attempt to run the ConfigEngine task as your logged in user, not as root, and the task will fail.

I think you should also be able to run the install as a non root user, I just haven’t tried it yet, I will post back when I have.

These steps also work with 6101.

Another guy in the office mentioned that he had converted his work laptop into a VM, so he could work at home on his nice quick desktop machine. I run Ubuntu 9.04 on the laptop and Windows 7 at home.

The T60 has a pretty hectic partitioning scheme, LVM, ext4, encrypted partitions, the whole works. This procedure handled it all. It makes a ‘bit for bit’ copy of the drive, and I knew it should work, but am happy it did anyway.

Here’s how to do it:

1. Boot up using a live cd. I used an Ubuntu 9.04 disk.
2. Grab a external drive bigger that the entire internal drive. The T60 hard drive is only 100GB, so this wasn’t hard.
3. Use fdisk -l to figure out which drive is which. My internal drive was /dev/sda and the external was /dev/sdb
4. Mount the external drive, if it isn’t mounted. Let’s say it’s mounted at /media/external
5. Run

If you don’t have an external drive, you could use netcat or scp or something, and send the drive image over the wire instead. It’ll just be much slower.

6. Reboot the laptop, you don’t need it anymore.
7. Copy drive.img to the host machine. I’m running Virtual Box 3.06 on Windows 7.
8. Run this command to convert the raw disk image to a Virtual Box drive image file.

9. Create a new Virtual Box Guest in the usual way, and point it to the vdi file. I used a SATA controller since my laptop has one, but not sure if this matters or not.
10. Boot up your new guest machine.

Hey presto, it’s the same! Now I don’t have to carry my laptop home anymore. It seems to run a bit slower than the native machine, but that’s to be expected.

This would probably work for a Windows physical machine too, although I think you’d want to add an extra step at the beginning. On the Windows laptop, set the IDE controller to use the Microsoft driver, rather than your default driver before you take the image. That way, when the guest OS boots up, it will have access to a ‘lowest common denominator’ disk driver.

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.

For some reason Ubuntu, ships a shell called ‘dash’ as their default, rather than good old bash. (Well, they have their reasons.) This presents a problem for App Server, as all the scripts in AppServer/bin use #!/bin/sh (the Bourne shell) as their command interpreter, which on a Redhat machine is symlinked to /bin/bash . The reason why AppServer uses the Bourne shell is that it needs to work on AIX and Solaris too, and you can’t be sure that you have bash on one of those machines.

If you try to call wsadmin.sh on an Ubuntu system you get this error :

Now, when you’re installing Portal, it installs AppServer, and then calls the manageprofile.sh script to create the default profile for Portal “wp_profile” . Manageprofile.sh calls a bunch of ant scripts that needs to use wsadmin.sh (you can see where I’m going here….) . You might notice in AppServer/log/wp_profile_create.log messages like this :

It actually hangs for 20 minutes waiting for wsadmin to start!

So how do you fix it? Simply, before you install it, unlink /bin/sh -> /bin/dash , and relink so it reads /bin/sh -> /bin/bash

Carefully:

Now the install should run properly.