How to solve CWWIM4520E on Portal 6.1

You may have seen this error if you tried the steps in “Configuring WCM email actions with a local SMTP server”.

When you edit the user’s properties this nasty error can appear if your Portal server is connected to an LDAP.

Error entering mail address into Self Care Portlet

Btw, this is a 6.1 or Portal.Next beta specific error, it should work fine on 6.0.

Here’s the full text of the error:

The reason this happens is that the portlet ( the self care portlet in this case)  is wired up to write the email address you entered in the form to a VMM attribute called ibm-primaryEmail . If your ldap schema doesn’t have a user attribute in it called ibm-primaryEmail , then you’re going to get an error when you try and write something to it.

Just to check it out, let’s look at the LDAP schema on this server (which is IBM Tivoli Directory Server 6.0)  . I’m using the awesome and free Apache Directory Studio to investigate the LDAP schema here.  Once the connection to the ldap is defined, go LDAP -> Open Schema Browser , and select the tab attribute types.

TDS ldap schema

Ok, so we have an attribute type ‘drink, favouriteDrink’ ;o) , but no ibm-primaryEmail . No matter, there is a ‘mail’ attribute there. We can make Portal use that to save email related attributes.

Open up wkplc.properties and find the section entitled LDAP Attribute Configuration (it’s near the bottom) . Here’s my completed one:

Cool, now run the task :

If you are using a federated ldap setup, edit the corresponding federated properties instead, and then run the following task:

. Restart the server and try the form again. It should correctly save the email attribute for the user and you can get on with sending email through Portal. Just for kicks, lets look at what that task did. It just edits the wimconfig file, which defines how VMM interacts . Open wimconfig.xml (wp_profile/config/cells/<cellname>/wim/config/wimconfig.xml) and search for ibm-primaryEmail.

Here is the part that does the mapping:

So the task is really just a (welcome) convenience, all it does it edit the xml file for you. Anyone who has tried to set up multirealms on 6.0 would be grateful for that!

ERRORCODE=-4214, SQLSTATE=28000 from DB2 on Ubuntu

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.

Getting WebSphere Portal to install on Ubuntu

Ok, ok, I know Ubuntu isn’t supported by IBM, but if you’re a developer, and you run Ubuntu on your laptop and would like to run Portal on there too, here’s how you do it. This should work for Debian too . I guess this isn’t really a Portal only problem, rather it’s a general Application Server + Ubuntu issue. I’ve only tried this with 6.1, but it is probably an issue with 6.0 as well, since it uses similar profile creation code.

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.