A Portal to a Portal: April 2010

Wednesday, 28 April 2010

This blog has moved

This blog is now located at http://portal2portal.blogspot.com/.
You will be automatically redirected in 30 seconds or you may click here.

For feed subscribers, please update your feed subscriptions to
http://portal2portal.blogspot.com/feeds/posts/default.

Tuesday, 27 April 2010

Using WebSphere Portal from mobile devices

I've just spent a few hours testing this, following a question from a customer, who had a requirement to show/hide portal resources e.g. pages, portlets etc. when accessing WebSphere Portal via a RIM BlackBerry device.

I was able to create a Personalization Visibility Rule that will hide a portlet based upon the browser's User-Agent parameter. The rule is: -

Hide page or portlet when

current Browser Capability.Agent includes blackberry

Otherwise show

I had previously written a portlet, using WebSphere Portlet Factory Designer, that captures this User-Agent string, using the following JSP: -

<html>

<body>

out.println("User agent is " + request.getHeader("User-Agent"));

</body>

<html>

which, for my BlackBerry Curve 8310, returned: -

BlackBerry8310/4.5.0.180 Profile/MIDP-2.0 Configuration/CLDC-1.1 VendorID/120

The final trick is to realise that the Visibility Rule is case-sensitive - in other words, the test needs to be for "blackberry" rather than "BlackBerry". Similarly, for Mozilla Firefox, which returns a User-Agent string of: -

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)

the test needs to be for "mozilla" rather than "Mozilla".

Once I'd gone through the above, I was able to browse to my portal instance using the native BlackBerry browser on a 8310 Curve, and see that the rule was working e.g. that the portlet to which I had applied the rule was HIDDEN for the BB, whereas it was visible on other devices.

The trick re case sensitivity came from a friend, Mike Spradbery, who had previously blogged about using a similar Visbility Rule with the Apple iPhone - in his example, he'd used a rule: -

Hide page or portlet when

current Browser Capability.Agent includes iphone

Otherwise show

Note the use of the case - iphone - rather than iPhone.

Thursday, 22 April 2010

Installing WebSphere Portal Extend 6.1.5

Whilst building a PoC environment, I had a requirement to download and use WebSphere Portal Extend 6.1.5, which includes Lotus Web Content Management 6.1.5.

This is what I actually downloaded: -

IBM WebSphere Portal V6.1.5 and Lotus Web Content Management V6.1.5- IBM WebSphere Portal Server Content Install V6.1.5 (W-Setup, A-Setup, H-Setup, HI-Setup, I-Setup, IL-Setup, PL-Setup, ZL-Setup, SS-Setup, SO-Setup) Multiplatform Multilingual (CZ8G9ML)

IBM WebSphere Portal V6.1.5, WebSphere Portal Express V6.1.5 and Lotus Web Content Management V6.1.5 - IBM WebSphere Application Server Network Deployment for Windows x86-32, V6.1.0.27 (W-1) Multilingual (CZ8H2ML)

IBM WebSphere Portal V6.1.5 and Lotus Web Content Management V6.1.5 - IBM WebSphere Application Server Network Deployment for Windows x86-64 (W-2) Multilingual (CZ8H8ML)

IBM WebSphere Portal V6.1.5 and Lotus Web Content Management V6.1.5- IBM WebSphere Portal Server Content component (Disk 1 of 4) V6.15 (W-3, A-3, H-3, HI-3, I-3, IL-3, PL-3, ZL-3, SS-3, SO-3) Multiplatform Multilingual (CZ8IBML)

IBM WebSphere Portal V6.1.5 and Lotus Web Content Management V6.1.5- IBM WebSphere Portal Server Content component (Disk 2 of 4) V6.1.5 (W-4, A-4, H-4, HI-4, I-4, IL-4, PL-4, ZL-4, SS-4, SO-4) Multiplatform Multilingual (CZ8ICML)

IBM WebSphere Portal V6.1.5 and Lotus Web Content Management V6.1.5- IBM WebSphere Portal Server Content component (Disk 3 of 4) V6.1.5 (W-5, A-5, H-5, HI-5, I-5, IL-5, PL-5, ZL-5, SS-5, SO-5) Multiplatform Multilingual (CZ8IDML)

IBM WebSphere Portal V6.1.5 and Lotus Web Content Management V6.1.5- IBM WebSphere Portal Server Content component (Disk 4 of 4) V6.1.5 (W-5A, A-5A,, H-5A,, HI-5A,, I-5A,, IL-5A,, PL-5A,, ZL-5A,, SS-5A,, SO-5A,) Multiplatform Multilingual (CZ8IEML)

and I used my usual trick of writing an script, unpack,bat, to extract from the six ZIP files into, in my case, c:\temp

cd \temp

unzip CZ8G9ML.zip -D W-Setup

unzip CZ8H2ML.zip -D W-1

unzip CZ8H8ML.zip -D W-2

unzip CZ8IBML.zip -D W-3

unzip CZ8ICML.zip -D W-4

unzip CZ8IDML.zip -D W-5

unzip CZ8IEML.zip -D W-5A

using a command line tool, UNZIP.EXE, which is ( I believe ) part of the original PKZIP tool from way back when ...

Monday, 19 April 2010

SAML assertions across WebSphere Application Server security domains

"...

Security Assertion Markup Language (SAML) is fast becoming the technology of choice to create Single Sign-On (SSO) solutions across enterprise boundaries. This article describes how to use the SAML support in IBM® WebSphere® Application Server V7.0 Fix Pack 7 to assert SAML tokens across enterprise boundaries in different security domains, and also to make access control decisions directly using the foreign security domain user identity and custom SAML group attribute, all based on the trust relationship. Trust relationship validation is enforced via policy set binding configuration at three points to ensure authenticity and to guard against security threats. This article shows how this technology can be easier to manage and more scalable compared to the alternative identity mapping approach.

..."

http://www.ibm.com/developerworks/websphere/techjournal/1004_chao/1004_chao.html

Wednesday, 7 April 2010

Lotus Forms Server - Webform Server 3.5.1 - Some Windows-based weirdness

I haven't properly thought this through yet, but I wanted to write up the results of some work with which I was involved last week that initially led to some confusion about the way that the Lotus Forms Server Translator application actually works.

In my environment, we had three Windows-based virtual machines running the LF infrastructure, as follows: -

Node 1

Log Server

Shared File Cache ( shared as a Windows networked drive using the UNC e..g. W$ )

Access Control Database ( DB2 UDB )

Node 2

Translator Server

Node 3

Translator Server

with Nodes 2 and 3 being federated into a managed cell, and operating as a cluster, via the WebSphere Plugin deployed onto a pair of co-located IBM HTTP Servers.

Having built the cluster, updated the Plugin configuration files etc. all appeared to work, and we even proved that failover worked, via an externally deployed load balancer, based upon WebSphere Edge Components.

So all was well .....

.... until we reconfigured WAS on Nodes 2 and 3 to allow the node agents to run as Windows services, using the WASService.exe binary.

From this point on, we were getting a strange set of errors ( which I need to recapture and record here ) implying that the Translator servers ( which are executing on Nodes 2 and 3 under the control of the Deployment Manager ) were no longer able to access the Shared File Cache. Apart from the error messages in SystemOut.log and StdOut.log on each of the WAS servers, we were also seeing NO files or directories being written to the SFC itself.

My colleague had seen similar problems previously, which appeared to be related to a lack of time synchronisation between the WAS nodes and the DM. However, in this case, the clocks were all showing the same time, down to the second.

We experimented with the SFC settings in translator.properties on each of the two nodes, e.g.: -

<entry key="fileCacheLocation">\\vbCONF0001\SharedFileCache</entry>

or: -

<entry key="fileCacheLocation">\\vbCONF0001\W$\SharedFileCache</entry>

etc.

but to no avail.

We also confirmed that the logged-in Windows user on either Node 2 or Node 3 ( actually the LOCAL Windows Administrator account ) could map to the SFC via the UNC e.g. \\vbCONF0001\w$ or \\vbCONF0001\SharedFileCache etc. and read AND write files and directories.

Having recognised that this all worked until we added the Node Agents in as Windows services, we did a quick test to manually start the Node Agent, using the startNode.bat script, rather than via the Windows Services Control Panel ( services.msc ). In this configuration, we were able to successfully start the Translator cluster from the DM, and all was well.

We then changed the Windows account that is used to start the Node Agent, from within the Services Control Panel, from the default of Local System Account to the actual user name of the local Administrator user ( .\Administrator ), along with the user's password.

Having made this final change, we were able to start/stop/restart the Node Agents from the Services Control Panel, and start the cluster from the DM without any problems at all.

The moral of the story ?

When you run a WAS Node Agent as a service, check the user under which it's running. I've not seen this problem elsewhere e.g. with a similarly clustered instance of WebSphere Portal 6.1.5, running on the same version of WAS - 6.1.0.27, so I'm assuming that it's the added wrinkle of the Shared File Cache that's being read/written via the Windows UNC.

I'd be interested to see if others have had the same problem ....

Friday, 2 April 2010

SSH Fun and Games

Want to connect to a Linux server via SSH ? Want to have the X11 protocol tunneled back to your client device ?

If so, run the command: -

ssh -o ForwardX11=true root@hostname

where hostname is the Linux box to which you want to connect.

This sets the DISPLAY variable on the target host to localhost:10.0, which is one less thing to do. It's also no longer necessary to run xhost + on the client machine.

Sweet :-)

A Portal to a Portal