Anyway, when trying this out, I got this error when starting Apache. This error is pretty straightforward :

This simply means that the wrong version of the plugin is installed. I’m using 64 bit linux and 64 bit Apache, but the 32 bit version of the WAS Plugin. Reinstalling the 64 bit version made it work fine.

The first thing to do when debugging a WAS install problem is to look at the logs in ~/waslogs . These indicated the following problem:

My system had heaps of space on it! Surely the installer wouldn’t even run if there was 0 MB free! The method that the installer used to determine how much disk space was free was failing. But how does the installer figure out how much disk space is free? After lots of poking and prodding around I stumbled on dtrace. I had heard of it before, but never had the opportunity to use it. Dtrace is a mechanism to instrument and probe the tiniest little interactions on a Solaris/BSD/OSX machine. Being so powerful, it has a steep learning curve. This collection of handy dtrace oneliners was really helpful.

I kicked off the WAS install portion of the Portal install and ran this dtrace command in another window.

It captured each file interaction that occurred when running the install. Luckily the WAS install failed after about 30 seconds, so there wasn’t too much data to wade through.

Here is the dtrace log (trace.log from the command above). Something called gushellsupport.sh is calling df (standard unix disk free command). This must be how the installer determines how much disk space is free. The column on the left is the pid of the install process (which is java) . The library files on the far right are what is being called by each executable; the next column over to the left.

This script, gushellsupport.sh, is owned by InstallShield so I can’t publish the contents of it. But it has a diskcheck function in it that relies on ‘/usr/xpg4/bin/df’ which I didn’t have installed. Solaris has many different versions of the same tools that are left behind for backwards compatibility. When installing this system initially, I used the “Core System Support” option in the Solaris install to build a lean, quick machine. Unfortunately it didn’t come with this legacy version of df.

df belongs in a package called SUNWxcu4. To install it, mount your Solaris CD and go to the directory Solaris_10/Product/ . In there, copy the subdirectory ‘SUNWxcu4′ to /var/spool/pkg and run

If you rerun the install again it’ll work since gushellsupport.sh is calling the correct version of df. Talk about obscure huh?

After installing 6.0.1.4-WP-IFPK83731.zip and 6.0.1.4-WP-IFPK70263.zip on a machine here I got this error message, and a 404 when I tried to hit portal. These fixes update the version of WMM to the (current) latest version. Here’s what was in my SystemOut.log

[12/14/09 17:31:09:618 EST] 0000002a SystemOut O WMM Implementation Version: WMM5.6_PK83731 (April 1 2009)
[12/14/09 17:31:09:618 EST] 0000002a WSMM Message E com.ibm.ws.wmm.MemberRepositoryManager init() Initialization failed due to invalid property “supportedMemberTypes”.
[12/14/09 17:31:09:653 EST] 0000002a WSMM Message E com.ibm.ws.wmm.objectimpl.MemberServiceBeanBase ejbCreate() com.ibm.websphere.wmm.exception.InitializationException: Initialization failed due to invalid property “supportedMemberTypes”.
[12/14/09 17:31:09:655 EST] 0000002a ExceptionUtil E CNTR0019E: EJB threw an unexpected (non-declared) exception during invocation of method “getConfigurationData”. Exception data: com.ibm.ejs.container.CreateFailureException: ; nested exception is:
java.lang.reflect.InvocationTargetException
at com.ibm.ejs.container.StatelessBeanO.(StatelessBeanO.java:172)
at com.ibm.ejs.container.CMStatelessBeanO.(CMStatelessBeanO.java:58)
at com.ibm.ejs.container.CMStatelessBeanOFactory.create(CMStatelessBeanOFactory.java:40)
at com.ibm.ejs.container.EJSHome.createBeanO(EJSHome.java:913)
at com.ibm.ejs.container.EJSHome.createBeanO(EJSHome.java:1016)
at com.ibm.ejs.container.activator.UncachedActivationStrategy.atActivate(UncachedActivationStrategy.java:83)
at com.ibm.ejs.container.activator.Activator.activateBean(Activator.java:595)
at com.ibm.ejs.container.EJSContainer.preInvokeActivate(EJSContainer.java:3439)
at com.ibm.ejs.container.EJSContainer.preInvoke(EJSContainer.java:2836)
at com.ibm.ejs.container.EJSContainer.preInvoke(EJSContainer.java:2745)
at com.ibm.websphere.wmm.objects.EJSRemoteStatelessMemberService_14d751a3.getConfigurationData(Unknown Source)
at com.ibm.websphere.wmm.objects._MemberService_Stub.getConfigurationData(_MemberService_Stub.java:2292)
at com.ibm.wps.services.puma.SystemWMMAccessBean$39.run(SystemWMMAccessBean.java:906)
at com.ibm.ws.security.auth.distContextManagerImpl.runAs(distContextManagerImpl.java:2771)
at com.ibm.ws.security.auth.distContextManagerImpl.runAsSystem(distContextManagerImpl.java:2651)
at com.ibm.wps.services.puma.SystemWMMAccessBean.getConfigurationData(SystemWMMAccessBean.java:912)
at com.ibm.wps.services.puma.RealmAwareURManager.initRealms(RealmAwareURManager.java:117)
at com.ibm.wps.services.puma.RealmAwareURManager.(RealmAwareURManager.java:103)
at com.ibm.wps.services.puma.PumaServiceImpl.init(PumaServiceImpl.java:215)
at com.ibm.wps.services.Service.init(Service.java:107)
at com.ibm.wps.services.Service.init(Service.java:83)
at com.ibm.wps.services.ServiceManager.createService(ServiceManager.java:400)
at com.ibm.wps.services.ServiceManager.getService(ServiceManager.java:527)
at com.ibm.wps.services.ServiceManager.getService(ServiceManager.java:553)
at com.ibm.wps.services.puma.Puma.(Puma.java:52)
at com.ibm.wps.ac.impl.AccessControlDataManagementServiceImpl.initializeDomainConfig(AccessControlDataManagementServiceImpl.java:885)
at com.ibm.wps.ac.impl.AccessControlDataManagementServiceImpl.reinit(AccessControlDataManagementServiceImpl.java:792)
at com.ibm.wps.ac.impl.AccessControlDataManagementServiceImpl.init(AccessControlDataManagementServiceImpl.java:439)
at com.ibm.wps.services.ServiceManager.createService(ServiceManager.java:400)
at com.ibm.wps.services.ServiceManager.getService(ServiceManager.java:527)
at com.ibm.wps.ac.impl.AccessControlDataManagement.(AccessControlDataManagement.java:41)
at com.ibm.wps.ac.impl.AccessControlServiceImpl.initializeServices(AccessControlServiceImpl.java:138)
at com.ibm.wps.ac.impl.AccessControlServiceImpl.init(AccessControlServiceImpl.java:114)
at com.ibm.wps.services.ServiceManager.createService(ServiceManager.java:400)
at com.ibm.wps.services.ServiceManager.getService(ServiceManager.java:527)
at com.ibm.wps.ac.internal.AccessControlLookupManager.getAccessControlLookup(AccessControlLookupManager.java:37)
at com.ibm.wps.ac.ACManager.getAccessControl(ACManager.java:132)
at com.ibm.hrl.siapi.search.admin.utils.PortletUtils.getPortalAdminUserID(PortletUtils.java:321)
at com.ibm.hrl.siapi.search.admin.portlets.manage.SearchAdminPortletManager.(SearchAdminPortletManager.java:64)
at com.ibm.hrl.siapi.search.admin.portlets.SiapiSearchAdminPortlet.init(SiapiSearchAdminPortlet.java:532)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:320)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.initialize(ServletWrapper.java:1821)
at com.ibm.wsspi.webcontainer.extension.WebExtensionProcessor.createServletWrapper(WebExtensionProcessor.java:141)
at com.ibm.ws.webcontainer.webapp.WebApp.getServletWrapper(WebApp.java:885)
at com.ibm.ws.webcontainer.webapp.WebApp.initializeTargetMappings(WebApp.java:612)
at com.ibm.ws.webcontainer.webapp.WebApp.initialize(WebApp.java:479)
at com.ibm.ws.webcontainer.webapp.WebGroup.addWebApplication(WebGroup.java:123)
at com.ibm.ws.webcontainer.VirtualHost.addWebApplication(VirtualHost.java:146)
at com.ibm.ws.webcontainer.WebContainer.addWebApp(WebContainer.java:940)
at com.ibm.ws.webcontainer.WebContainer.addWebApplication(WebContainer.java:893)

I’m not sure what was updated in WMM for this one, but the solution is simple: install WAS 6.0.2.37 to fix it.

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.

Luckily enough, there’s an easy way to do this. The infocenters for WebSphere Application Server and WebSphere Portal are available in Eclipse Help System form, which is pretty much the same way they are presented over the web.

You can download the infocenter in Eclipse Help System format from this page for WAS and this page for Portal.

If you don’t have Eclipse already, download it from here. Any one of the versions should do. Unzip Eclipse and then copy the infocenter zips into the eclipse/plugins directory. Then unzip the infocenter zips in the plugins directory.

Now start Eclipse, and pick any old workspace. Click Help -> Help Contents, and the Infocenter zips that you copied in should be along side any other help files that come with Eclipse originally.

Now you have a local copy, make sure to update it since the infocenter is updated monthly.

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.