IBM HTTP Server

Changing subdomain in Connections,CCM and Docs

I’ve just completed a process where a customer needed to change their subdomain due to an organisational name change. This site has a pretty large install.  CCM, Docs and also leveraged Windows Desktop SSO via SPNEGO.

The change was connections.OLD.sub.dom.au to connections.NEW.sub.dom.au

There is some documentation out there on how to change host names, but I wanted to compile a list for this specific task. So here you go.

Pre-tasks

SSL CSR created, new key created and imported into new KDB. Make available on IBM HTTP Server.

DNS change implemented, and points to existing IBM HTTP Server. Keep old record in place as well. Also ensure that the new record is resolvable on all Connections hosts.

Change the SSL Certificate over in IHS. (Change the following)

Keyfile D:\IBM\HTTPServer\NEWkey.kdb
SSLStashFile D:\IBM\HTTPServer\NEWkey.sth

CellDefaultTrustStore as it shared a common root with the previous Certificate.

Connections changes

Change the LotusConnectection-config.xml file. Check out with wsadmin, change the references to OLD and replace with NEW. Check-in. Process here

While in wsadmin, change the Notifications file to reflect new mail domain. Change the Administration user that notifications come from. Check-in. Process here

Change and update Blogs

To update the URL’s inside blogs, there is an AdminTask. while still in wsadmin, execute the following.

execfile(blogsAdmin.py)
BlogsAdminService.fixBrokenUrls(https://connections.old.sub.dom.au, https://connections.new.sub.dom.au)

 

Change LTPA to reflect new Domain.

In the ISC, select Global Security > Single sign-on

Update the Domain name field to reflect the new sub domain. i.e from .old.sub.com.au to .new.sub.dom.au

editor_image_cb34e16e-94cb-42a1-8921-1333db1dd095

Re-sync all nodes, stop and restart the entire environment (DMGR and NODES).

Docs Changes

Docs is pretty straight forward.

The property files for Docs all need to be changed. They are found in: <WAS_HOME>/profiles/<DMGR>/config/cells/{cellname}/IBMDocs-config/

Change all instances of OLD url to NEW in the concord-config.json file, and the viewer-config.json file. Just to be safe, verify no instances of OLD url exist in the other .json files in the directory. If there are, change them.

Re-sync all nodes, stop and restart the entire environment (DMGR and NODES).

CCM Changes

For CCM, we only had to update the Activity stream widget. Follow this process

 

Update Scheduled tasks

Jump back into wsadmin, and run the following. Following is from the knowledge centre.

Scheduler.listAllTasks() 
Scheduler.clearAllTasks()

Note: If Scheduler.clearAllTasks() does not clear tasks successfully, run clearScheduler.sql manually for each of the applications. 
For example:

db2 -v -td@ -f activities\db2\clearScheduler.sql
db2 -v -td@ -f homepage\db2\clearScheduler.sql 
The SQL scripts are in the following locations:

AIX or Linux: connections_root/connections.sql directory.

 

Update Search

I planned on updating search, but I didn’t get any errors after the change while using the search. Just to be safe,  I kicked off a new once off index task after the changes were completed.

Process.

SPNEGO SSO

 

…..and finally, a bit of a catch all

IBM HTTP Server rewrite – redirect OLD url to NEW

Add the following to handle any URLS that still come in using the old name. Replace your new server names below.

#Added to support redirect from OLD to NEW
<VirtualHost *:80>
    ServerName connections.OLD.sub.dom.au
    RewriteEngine On
    RewriteRule ^/$    /homepage     [PT] 
    RewriteRule ^/(.*) http://connections.NEW.sub.dom.au/$1 [R,L]
  
</VirtualHost>
RewriteEngine off

<VirtualHost *:443>
    ServerName connections.OLD.sub.dom.au
    SSLEnable
    RewriteEngine on
    RewriteRule ^/$    https://connections.NEW.sub.dom.au/homepage [PT]      RewriteRule ^/(.*) https://connections.NEW.sub.dom.au/$1 [R,L]    
</VirtualHost>
RewriteEngine off
SSLDisable

<VirtualHost *:80>
    ServerName connections.NEW.sub.dom.au
    RewriteEngine On
    RewriteRule ^/$     /homepage     [PT]
</VirtualHost>
RewriteEngine Off

<VirtualHost *:443>
    ServerName connections.NEW.sub.dom.au
    SSLEnable
    RewriteEngine On
    RewriteRule ^/$     /homepage     [PT]
</VirtualHost>
RewriteEngine Off

 

 

 

 

RSA Premaster Secret Error in Connections 5

I’m doing an install for a customer at the moment, and it’s a large install. All on RHEL, integrated with Portal, and hosted in SoftLayer. Very Cool. I love playing with this stuff!

So the Connections install was running along great, until it was time to bring up the Connections Apps and test login. The way we usually configure Connections these days is to setup WAS primary administration user to exist in the LDAP directory, and use the default file based admin as a backup. We also then use this same user as the Connections administrator. We ensure that this user also has a profile. This just seems to make the installation (especially of companion products/extensions) easier..

I go to log into Connections the first time with the Admin user.. I get the “Unable to process your request page”. Damn.

Start troubleshooting. Eventually find the stanza that I think is logging for the error. This was in the Homepage Server System.Out. (Large Connections Install)..

 [14/01/16 19:30:20:532 EST] 00000120 HttpMethodDir I org.apache.commons.httpclient.HttpMethodDirector executeWithRetry Retrying request
 [14/01/16 19:30:20:535 EST] 00000120 HttpMethodDir I org.apache.commons.httpclient.HttpMethodDirector executeWithRetry I/O exception (javax.net.ssl.SSLKeyException) caught when processing request: RSA premaster secret error
 [14/01/16 19:30:20:536 EST] 00000120 HttpMethodDir I org.apache.commons.httpclient.HttpMethodDirector executeWithRetry Retrying request
 [14/01/16 19:30:20:539 EST] 00000120 UserInfoInter E com.ibm.lconn.homepage.web.interceptor.UserInfoInterceptor cacheUserInfo CLFRQ0341E: Could not retrieve details for the user with login ID: ConnectionsAdmin@domain.blah.au due to an exception. The exception occurred when retrieving the details via Profiles Directory Service Extension: [Ljava.lang.Object;@5c0f8907

More digging revealed that this error was due to…….the SSL Key.

What was occurring is this. I’d setup the IBM HTTP Server to use the key provided by the customer. I’d imported this into the CellDefaultTrustStore, as required. It was 4096 bits wide, which Java security in the WAS stack had an issue with. Some secret squirrel stuff about the governments wanting to control Encryption or something. So when the Homepage app was hitting the URL for profiles and verifying I am who I say I am, it caused the SSL error.

How did I fix it?

Copy and replace the Java policy files with the unrestricted policy files, then restart the Connections servers.

cd /opt/IBM/WebSphere/AppServer/java/demo/jce/policy-files/unrestricted/
[root@connwas2 unrestricted]# cp *.jar /opt/IBM/WebSphere/AppServer/java/jre/lib/security/
cp: overwrite `/opt/IBM/WebSphere/AppServer/java/jre/lib/security/local_policy.jar'? yes
cp: overwrite `/opt/IBM/WebSphere/AppServer/java/jre/lib/security/US_export_policy.jar'? yes

That’s it. Restart servers and enjoy.

Thanks to Mikkel Heisterberg,  you pointed me in the right direction with this Blog. Cheers!

 


					

OAuth2 error in Activity stream popout

I’ve just finished with installing IBM Docs; an install post will follow shortly.

Users were reporting issues of the Activity stream popout failing with “An error has occurred”

Selecting more details, reveals the following.

000002a7 BasicOAuth2Re W BasicOAuth2Request exception
java.lang.NullPointerException
at java.util.zip.InflaterInputStream.<init>(InflaterInputStream.java:77)
at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:65)
at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:76)

I then backtraced the changes we had made. As the issue referred to GZIP, I thought of compression and what changes I’d made in the installation of Docs.

One step of this installation is to modify the httpd.conf file on the IBM HTTP Server to enable compression for various data streams. This is done by invoking the mod_deflate directive.

The main winners when this form of compression is enabled is the end user on a low bandwidth connection. Users on a local LAN the benefits aren’t as drastic, but it’s still a good idea.

For example, text can be compressed by up to 70%. That baeing said, some types of data don’t lend well to compression, i.e jpg, pdf, etc.

Read here for IBM’s technote on enabling mod_deflate.

Anyway, back to my error.  I had added the following  changes to our httpd.conf file as part of the docs install. Please note these are all commented out.

#AddOutputFilterByType DEFLATE application/atom+xml 
  #AddOutputFilterByType DEFLATE application/atomcat+xml 
  #AddOutputFilterByType DEFLATE application/javascript 
  #AddOutputFilterByType DEFLATE application/json 
  #AddOutputFilterByType DEFLATE application/octet-stream 
  #AddOutputFilterByType DEFLATE application/xhtml+xml 
  #AddOutputFilterByType DEFLATE text/css 
  #AddOutputFilterByType DEFLATE text/plain 
  #AddOutputFilterByType DEFLATE text/xml 
  #AddOutputFilterByType DEFLATE text/xsl

By a method of deduction, we worked out that the “application/octet-stream” was the culprit for killing the Activity stream popout. We’ve disabled this entry, and all works again.

Hope this saves someone half a day of stuffing around!