IBM WebSphere Portal 6.1.0.6/6.1.5.3 Known Install/Uninstall issues

Content

---

Known issues for install and uninstall of WebSphere Portal 6.1.0.6/6.1.5.3


Problem: Applying this Portal fix pack as non-root user on Linux or Unix platforms fails.
Solution: Ensure the user running the feature pack install is the same user that owns the WebSphere file structure, and has r/w/x access to the system's /tmp directory. Note: For AIX, a root user must be used for the installation.

Problem: During Portal 6.1.0.6 upgrade in consolidate-config-extension-deploy-portlets an entry in the SystemOut.log, "WSVR0605W: Thread "WebContainer : 2" (0000003a) has been active for 608093 milliseconds and may be hung. There is/are 1 thread(s) in total in the server that may be hung."
Solution: The warning is ok but can be prevented by increasing the threshold timeout following WebSphere Application Server documentation for Configuring the hang detection policy. The hung thread resolves itself even if the timeout is not set high enough.

Problem: If you plan to configure Computer Associates eTrust SiteMinder as your external security manager to handle authorization and authentication, the XML configuration interface may not be able to access WebSphere Portal through eTrust SiteMinder.
Solution: To enable the XML configuration interface to access WebSphere Portal, use eTrust SiteMinder to define the configuration URL (/wps/config) as unprotected. Refer to the eTrust SiteMinder documentation for specific instructions. After the configuration URL is defined as unprotected, only WebSphere Portal enforces access control to this URL. Other resources such as the /wps/myportal URL are still protected by eTrust SiteMinder. If you already set up eTrust SiteMinder for external authorization and you want to use XMLConfiguration Interface (xmlaccess), make sure you have followed the procedure to allow for xmlaccess execution.

Problem: During uninstallation of Portal 6.1.0.6 to a level prior to Portal 6.1.0.3, the activate-portlets task fails with an entry in the ConfigTrace.log similar to the one below:
---
action-start-all-portlets:
Tue Sep 29 09:43:05 EDT 2009
[xmlaccess] EJPXB0006I: Connecting to URL http://localhost:10040/wps/config/
[xmlaccess] EJPXB0002I: Reading input file /opt/IBM/WebSphere/wp_profile/ConfigEngine/config/work/StartPortlets.xml
[xmlaccess] <request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" build="wp610_493_01" type="update" version="6.1.0.0" xsi:noNamespaceSchemaLocation="PortalConfig_6.1.0.xsd">
[xmlaccess] <status element="unknown" result="failed">
[xmlaccess] <message id="EJPXA0049E">com.ibm.wps.command.xml.XmlFormatException: EJPXA0049E: Input syntax error in line 10 column 63: the XML input does not conform to the XML schema PortalConfig_6.1.0.xsd. unknown</message>
[xmlaccess] <message>org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'porttype'. One of '{localedata, access-control}' is expected.</message>
[xmlaccess] </status>
[xmlaccess] </request>
[xmlaccess] EJPXB0015E: Server response indicates an error.
---
This error occurs only if wsrp producers are present in the Portal installation.
Solution: Install PK82932 and repeat the execution of the activate-portlets task

Problem: After installing the fix pack on Linux or Unix variants, the file <WP_root>/migration/WPmigrate.sh has permissions -rw-r--r-- or 644 and is not executable.
Solution: Manually set the permissions to -r-xr-x--- or 550 in order to use the command.

Problem: Task ./ConfigEngine.sh modify-servlet-path is not executable as a NON-ROOT user after upgrade.
Solution: If running the ./ConfigEngine.sh modify-servlet-path task as a NON-ROOT user it's necessary to change the PortalServer directories permission to 750. This can be done using the unix chmod command: chmod -R 750 <installlocation>/*
Example: chmod -R 750 /opt/IBM/PortalServer/*

Problem: After uninstall of fix pack, WPVersionInfo shows IBM WebSphere Portal Configuration Framework (CFGFW) at the upgraded version level.
Solution: This is expected. The CFGFW version level shown after the uninstall of the fix pack remains at the upgraded level. There is no functional problem.