Thursday, 20 May 2010

Argh, near panic when a new clustered installation of Lotus Connections 2.5.0.1 starts #failing

Having spent 2-3 days this week, preparing for, and building a clustered installation of Lotus Connections 2.5.01, I was feeling a little panic-stricken yesterday, when I was unable to log into Connections, either directly into Profiles, or into any other service, all of which use Profiles.

I was getting exceptions such as: -

19/05/10 17:20:23:625 BST] 0000002c WebApp        E   Exception caught while initializing context 
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'com.ibm.lconn.core.appext.api.SNAXPersonService' defined in URL [wsjar:file:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/connut-1Node01Cell/Profiles.ear/peoplepages.war/WEB-INF/lib/lc.appext.core.impl-2.5.jar!/META-INF/spring/lconn-service-context.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [com.ibm.lconn.core.appext.impl.SNAXPersonServiceImpl]: Constructor threw exception; nested exception is java.lang.ExceptionInInitializerError        at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:243)

in the SystemOut.log for Profiles, which gave me great cause for concern.

Reading through this forum thread: -


gave me a few pointers, but nothing really concrete.

When I dug a little further into the logs, I found this: -

Caused by: com.ibm.connections.directory.services.exception.DSRuntimeException: com.ibm.connections.directory.services.exception.DSException: CLFRK0004E: SSO domain name '.foobar.snafu.com' is not configured properly for host name 'http://<HOSTNAME.DOMAIN.COM>:9085/communities/dsx/'!

( I've anonymised the domain names etc. )

This started me thinking and I checked the /etc/hosts file of the Linux box on which Connections is running.

Sure enough, the .foobar.snafu.com domain matched a "private" network that only exists between Connections and the back-end data server on which NFS is being used for shared file systems etc.

I'm guessing that WAS was looking at, perhaps, the first IP address on the system, doing a reverse lookup via /etc/hosts and then returning the domain name portion of its hostname.

The solution ?

Set the SSO domain name to something sensible ( matching the domain name portion of the network on which ALL the Connections and Portal and Quickr servers are sitting ).

I did this via the Integrated Solutions Console (ISC), via Security -> Secure administration, applications and infrastructure -> Web security -> single sign-on (SSO), setting the Domain name field.

Once I restarted the Connections cluster, all was well, and I was able to log into Profiles, and access all the other services.

Nice

2 comments:

Er manno said...

Thank you so much, your tip was very useful and fixed my issue. My Connections 2.5 pilot was originally installed on a single Win2003 not joined in a domain and mapped in DNS on myserver.mydomain.mytld. Worked very well on http//myserver.mydomain.mytld/homepage until I decided to "simply" join the server to the domain "something.local". After that, same error as you. Fixed putting the original DNS domain myserver.mydomain.mytld in SSO configuration as you explained.

Dave Hay said...

Glad you fixed it, thanks for letting me know :-)