Installing Lotus Quickr on Ubuntu Linux Server 9.10

The installation of Lotus Quickr Services for WebSphere Portal includes an installation of DB2. Installing Quickr on an out-of-the-box installation of Ubuntu will fail due to a missing C++ library. The DB2 service requires a standard C++ library in version 5. Ubuntu Linux 9.10 includes version 6 of that library. In order to install Quickr 8.1.1 on a Ubuntu 9.10 system, you have to manually install the required library from an older release. You can find the package in the Debian package repository

. Download the .deb file from the repository and install it by issuing the following command as superuser

dpkg -i libstdc++5_3.3.6-18_i386.deb

The next issue I stumbled upon was during the creation of the was profile. The default shell of Ubuntu Linux is /bin/sh which does not support arrays and therefore a call to wsadmin.sh during the profile creation fails. I found this blog entry that describes how to solve this. You have to unlink /bin/sh, link it to bash and do a reconfigure. Enter the following commands as superuser:

unlink /bin/sh
ln -s /bin/bash /bin/sh

or

dpkg-reconfigure dash

Finally, after the installation is complete, you have to change the default shell for the created DB2 instance user for Quickr (i.e. quickradm), which is set to /bin/sh. Using this shell won't properly initialize the db2 environment when running the db2profile script. You should change the shell to bash, otherwise commands like db2stop and db2start won't be accessible. To change the default shell, edit as superuser the file /etc/passwd, look for the quickr users (usually in the end), and change the /bin/sh to /bin/bash.

Single Sign On with Quickr 8.1 and SPNEGO

Yesterday I was at a customer that is using Lotus Quickr 8.1 (J2EE) and als uses an ISSW asset - the SPNEGO TAI for WebSphere Application Server 6.0 - for WebSphere Portal 6.0. This customer wanted to use the TAI for Quickr too, respectively the underlying Application Server version 6.0.2.17.

And after some troubleshooting and a fix for WAS we finally managed to achieve SPNEGO/Windows Single Sign On for Quickr 8.1!

The only real issue with the product (Quickr) itself was a bug in the redirection after the request had not been intercepted by any TAI where the user was redirected to an error page instead of the login page. This was no specific SPNEGO TAI issue but an issue with the Trust Association Interception in general in the Quickr 8.1 and 8.1.1 underlying App Server, version 6.0.2.17.

However there is a technote and a fix for that known issue if you ever stumble upon this error.

After that fix had been installed - which went pretty smooth - Single Sign On with SPNEGO worked properly. At least in the WebUI but unfortunately not with the connectors.

One of the issues was that with SPNEGO enabled it didn't matter which values we specified for the main UI as user/pwd in the first dialog that comes up when we added a place to the connectors. These values were sent to the server and failed. However, the SPNEGO credentials were also sent along as we were authenticated successfully. But there were other user/pwd dialog boxes that appeared in the usage of the connectors as well. These did not work correctly with SPNEGO enabled.
Currently the Java based connectors (ie ST, Notes 8 Standard, etc) do not work at all when SPNEGO is enabled.

As a workaround to disable SPNEGO for the Connectors we considered two options:
The first (that was tested and finally implemented) was simply to create an additional DNS entry for the same Quickr server and specified this entry in the Connector (ie. web.quickr.intranet.com for the browser and connector.quickr.intranet.com for the connector). The TAI is configured to intercept only requests to a particular URL respectively a host (ie. web.quickr.intranet.com). If a request is sent to a different hostname (ie connector.quickr.intranet.com), the request is not intercepted and thus no Single Sign On happens.

The second option we thought of but did not test yet was to configure the TAI that way, that it uses a filter to exclude the URL used by the Connector respectively only intercept requests for the protected URLs of the web ui, which are URLs that contain /lotus/myquickr. Using the HTTPFilter for the configured server and a filter string "request-url==/lotus/myquickr" should do the job, but as mentioned - we did not test this.

Luckily, Quickr 8.2 is coming soon with official SSO support for the Connectors and it will be backward compatible to Quickr 8.1.1.

Quickr UI hacking

This week I was in a workshop at a customer where we discussed among others how to customize Quickr for Portal. They had some special requirements regarding the UI about which I'd like to write here.

One of their requirements was, to have a sidebar menu on the left-hand side containing the place navigation in the upper part of the sidebar and the functional elements below the navigation. They took the current Quickr for Domino look&feel as an example. I don't exactly know how the Quickr for Domino works, but I know that the Quickr for Portal works differently. The main problem is, that the PDM portlet (Library) in Quickr J2EE contains the entire toolbox as a right-side menu (with the "Create" button on top of if). So I needed to find a way to rip it off the portlet and place it in the right side navigation. I did this using JavaScript and it was actually only a couple lines of code.

First of all, create a place that uses a theme policy that displays the sidebar. Create a page that contains the library portlet (the one with the right sidebar). Then open the Default.jsp of the theme and search for the expression that includes the sidebar.

<%@ include file="./sideNav.jspf" %>

Place the following html snippet below this sidebar include.

<div id="injection-point"> </div>

Its important, that it is not a standalone html tag.
Now go to the end of the file and add the following script before the closing body tag:

<script type="text/javascript">
document.getElementById("injection-point").appendChild(document.getElementById("sidebar").parentNode);
document.getElementById("sidebar").style.visibility = "visible";
</script>

You could see, that the visibility attribute of the sidebar is set to visible, this comes a long with a change in the styles.jsp where you'll have to add the following snippet
#sidebar {
visibility: hidden;
}
This prevents from showing the sidebar on the right side during page load and then jumping to the left side, when the rendering process is complete. The sidebar is simply not shown from the beginning. Now save the files and see what happens :)

The final result looks like this:




Using this technique of adding injection points to the theme and some javascript code that moves elements around, you could easily modify the entire look and feel. For a customization I did this week for a customer, I moved the Create button and the Action menu to the left bar, and the other sections to the right side (outside of the portlet area). I also modified the search box, which is completely generated by a JSP tag.

Integrating Lotus Quickr into Connections

This week we configured the integration of Lotus Quickr into Lotus Connections Activities and Communities. We experienced some minor problems of which I like to write here, so you don't step into them, too. First of all, the configuration is quite straight forward and looks more complicated on first glance, than it actually is, so don't be afraid of it.

Activities
How Activities need to be configured, is described in the Infocenter, here. However, we had the problem, that we were not able to connect to the Quickr server that we configured. The reason of that was, that we used a self-signed certificate for the HTTP server, since it was only a proof of concept installation. But first, some words, how the Activities integration works.
For querying the Quickr server for places, Activities uses a REST service of Quickr and since Activities is mainly based on AJAX, the REST request is sent via JavaScript. For security reasons, the JavaScript script can't access the quickr sever directly, since it runs on a different server that the connections server. So the request is delegated to a proxy running on the connections server and the proxy forwards the request to the Quickr server.
However, to send the REST request from the proxy to the Quickr server, the proxy servlet needs to establish an HTTP connection, and since we used SSL for that, the connections was established over HTTPS. The trouble we had was, that the proxy did not trust the self-signed certificate of the Quickr HTTP server, so we needed to import that self signed certificate into the trust store of the WebSphere Application server (described here) the proxy was running on. That was all.

Communities
Different from Activities, the integration of Quickr into Communities requires some more steps. Therefor you need to download the Lotus Connections Connector for Lotus Quickr, and follow the installation instructions. That was straightforward, but it did not work with our setup, unfortunately.
To explain a little bit the setup we used, Connections and Quickr were both running on seperate servers, both with a collocated HTTP Server that performs the forwarding from the standard http ports 80 and 443 to the ports  Quickr is running on in the AppServer, which are for instance 10038 for http. So we configured during the installation of the Connector to use the default ports, 80 and 443 for ssl. What worked in Activities, did not work in Communities.
When we created a new community and checked the both new Quickr integration checkboxes, we experienced an exception, telling us (in the logs) that an URL like this one http://quickr.demolab.com/myqcs/rest/places/feed was not found. The reason for this was, that the Connector searched at the wrong port. For this particular URL the HTTP did no port forwarding, we still need to find out, why not. But anyway, after changing the http port following the instructions in the InfoCenter to port 10038, the integration worked perfectly... and btw. is pretty cool :)