Following up on my earlier post: -
the problem WAS firewall-related, but it took me a heck of a long time to crack it.
I went down a few blind alleys, including setting up directory service extensions by setting: -
<sloc:serviceReference communities_directory_service_extension_auth="DSX-Admin" communities_directory_service_extension_auth_alias="connectionsAdmin" communities_directory_service_extension_enabled="true" communities_directory_service_extension_href="http://connections.demo.uk.ibm.com:82/communities/dsx/" profiles_directory_service_extension_auth="DSX-Admin" profiles_directory_service_extension_auth_alias="connectionsAdmin" profiles_directory_service_extension_enabled="true" profiles_directory_service_extension_href="http://connections.demo.uk.ibm.com:82/profiles/dsx/" serviceName="directory"/>
( One of my colleagues, Gerald Muecke, had blogged mentioning that profiles_directory_service_extension_auth="DSX-Admin" needs to be set regardless of whether you're hiding email addresses )
in LotusConnections-config.xml ( having done the right thing and checked the file out, edited it, checked it back in, and then synchronised the nodes ).
Initially, I was testing with Homepage and Profiles running on a single node of my two-node cluster, with a single HTTP server running, sitting behind the load balancer. I have HTTP running on port 82 because I'm actually hosting three instances of IBM HTTP Server on each of the two web nodes; one for Portal ( port 81 ), one for Tivoli Identity Manager ( port 80 ) and one for Connections ( port 82 ).
I'd even enabled tracing in the WebSphere Plugin, which showed me lots of useful information, but didn't enable me to crack it.
I'd also checked my Virtual Hosts within the DM, and also within the plugin-cfg.xml that's generated by the DM and propagated out to the HTTP servers, but I couldn't see anything awry - the right 90XX ports were in there, as was 82
Having fooled around with DSX-Admin as above, I then decided to start Communities, and test that. Again, I was getting an exception, but it was slightly more meaningful: -
Error 500: ServletException in '/WEB-INF/jsps/html/scenes/dashboard/banner.jsp': com.ibm.connections.directory.services.exception.DSException: com.ibm.connections.directory.services.exception.DSOutOfServiceException: java.net.NoRouteToHostException: No route to host
However, when I inspected the source of that error page, I saw a lot of references to the FQ hostname of the webserver as well as the load balanced hostname that represents the Connections cluster.
The HTTP server listens on port 82, and the Connections features listen on port 9082 ( Homepage ), 9088 ( Profiles ) and 9085 ( Communities ).
On a complete whim, I decided to test, using TELNET, to see whether I could connect FROM the Connections WAS node TO the web server on port 82.
Lo and behold, I saw: -
telnet: Unable to connect to remote host: No route to host
I took a gamble and stopped the IPTables firewall on the HTTP server ( service iptables stop ) and re-tested using TELNET. This time, I was in like Flynn.
I re-tested Connections by hitting Homepage on the load balanced hostname ( http://connections.demo.uk.ibm.com:82/homepage ), logged in ( thus hitting Profiles ) and .... all worked according to plan.
I then went the whole hog and started Activities, Blogs, Dogear, Files and Wikis ( News and Search are sitting on the Homepage cluster ), and ..... EVERYTHING WORKS :-)
The moral of the story ? Firewalls do exactly what they say on the tin - they stop people getting into places that they shouldn't - even if they actually should get in, if you see what I mean :-)
More importantly, despite my understanding to the contrary, WebSphere needs to talk to the HTTP server, not just from the Deployment Manager ( on port 8008 *AND* 82 in my case ), but also from the nodes - on port 82 in my case.
PS These documents: -
were of use with regard to the Plugin.
No comments:
Post a Comment