Friday, 27 July 2012

Hot on the heels - scripting the installation of IBM Lotus Domino 8.5.3 Fixpack 1

Following on from my earlier post: -

Following the script - installing IBM Lotus Domino using a response file ( silent installation )

I also wanted to script the installation of the Domino 8.5.3 fix pack.

Apart from this being general good practice, I needed to get around an interesting little problem that I experienced when I installed the fix pack interactively: -

$ ./install

Lotus Notes for Unix Install Program
------------------------------------
Installer is initializing. It may take a few minutes, please, wait.

Error: The minimum supported terminal size is 130 columns by 24 rows.
Please ensure that the terminal/window used is at least this size.
If user just install hotfix not fix package, you can disable this check by.
LOTUS_NOROWCOLCHECK=1
export LOTUS_NOROWCOLCHECK

I was seeing this natively within the VM, whilst running without X11 loaded, but also within a terminal window whilst X11 was running. In addition, I also saw the same thing from my host OS ( Ubuntu 12.04 ) whilst SSH'd into the RHEL VM.

This Technote wasn't much use: -

Error installing hotfix or fixpack

as it mainly related to using PuTTY on Windows.

However, it did provide one insight: -

5. Use the silent install method.

Therefore, in the spirit of the series, I created a response file: -

$ vi script.dat

installation_type = 2

and then ran the installation thusly: -

./install -script script.dat

Lotus Notes for Unix Install Program
------------------------------------
Installer is initializing. It may take a few minutes, please, wait.


WARNING:
The following system commands were not located:
  rsh
Installation to remote systems will not be possible.

Fri Jul 27 19:32:18 BST 2012

Batch mode script file is:  /root/foo/linux/domino/script.dat
Installing  Domino Server kits ...
Replacing domino_6_5_6.dtd
Replacing xspClientDojo.js.gz
Replacing domino_6_0_6.dtd
Replacing domino_8_0_2.dtd
Replacing Bahia
....

I now have a nice shiny 8.5.3 FP1 server with which to play ...

Whilst I was on the journey to this discovery, I found this rather excellent presentation from DanNotes, which covers Domino 8.5.2 installation on SuSE Linux Enterprise Server (SLES).

The deck also makes reference to Daniel Nashed's excellent script for managing Domino under Linux.

Following the script - installing IBM Lotus Domino using a response file ( silent installation )

This follows on from the series of posts that I started last month, which include:-

Following the script - installing IBM HTTP Server using a response file ( silent installation )

Following the script - installing and using IBM WebSphere Update Installer using a response file ( silent installation )

Following the script - installing IBM Tivoli Directory Integrator using a response file ( silent installation )

Following the script - installing IBM DB2 UDB using a response file ( silent installation )

More on automation - this time it's the DB2 UDB 9.7.0.2 fixpack ....

I wanted  to include IBM Lotus Domino, as I needed an LDAP server for my IBM Connections 3.0.1 installation.

So here goes ...

Firstly, I'm using Domino 8.5.3 Fixpack 1, which I downloaded as: -

lotus_domino853_xlinux_en.tar
lotus_domser853FP1_LIN_Intel.tar

*UPDATE* I've also since used Fixpack 2 as well: -

lotus_domino853FP2_linux_x86.tar
As before, I am using Red Hat Enterprise Linux 6.2 for the installation, which I performed as root.

Before installing Domino, it's necessary to set two of the ulimits: -

open files                      (-n)
stack size              (kbytes, -s)


This is done via a change to the file /etc/security/limits.conf to which I add: -

* hard nofile 20000
* soft nofile 20000


to the end of the file.

These are the recommended values for Domino 8.

Right, onto the installation itself ...

First, I expanded the Domino code into my /tmp directory: -

$ cd /tmp
$ tar xvf /root/lotus_domino853_xlinux_en.tar

I then created a response file: -

$ vi ~/unix_response.dat

-G licenseAccepted=true
-W InstallDataOnlyOptionPanel.InstallDataOnly=false
-P installLocation="/opt/ibm/lotus"
-W normalData.installLocationData="/local/notesdata"
-W NameUserGroupPanel.UserName="notes"
-W NameUserGroupPanel.GroupName="notes"
-W SetupTypePanel.selectedSetupTypeId=EnterpriseServer
-W ServerSetupPanel.ServerSetupType="Manual"
-P LicenseFeature.active=true
-P ProgramFilesFeature.active=true
-P BillingSupportFeature.active=true
-P ClusteringSupportFeature.active=true
-P bean2236.active=true
-P DataFilesFeature.active=true
-P beanRequiredTemplates.active=true
-P beanAdministrationTemplates.active=true
-P beanOptionalTemplates.active=true
-P beanCertificateManagement.active=true
-P beanWebServicesDataFiles.active=true
-P beanReadme.active=true
-P beanDojo.active=true
-P beanDojo2.active=true
-P beanXSPages.active=true
-P DECSFeature.active=true
-P DOLSFeature.active=true
-P DWAFeature.active=true
-P SametimeIntegrationFeature.active=true
-P RMEFeature.active=true
-P HelpFeature.active=true
-P OSIntegFeature.active=true

I then created the required Domino user and group: -

groupadd notes
useradd -g notes notes
passwd notes

I then started the installation: 

$ cd /tmp/domino/linux/domino
$ ./install -options ~/unix_response.dat -silent

This initially failed with: -

Lotus Domino for Unix Install Program
------------------------------------

The following OS patches or higher are missing. Please update all patches before starting the Domino Server.
    libXmu-1.0.5-1.el6.i686
    libXp-1.0.0-15.1.el6.i686


which I overcame by installing the required libraries: -

$ yum install -y libXmu-1.0.5-1.el6.i686
$ yum install -y libXp-1.0.0-15.1.el6.i686

Second time around, the installation completed OK.

Once the installation had finished, I attempted to start the Domino server ( X11 was already running ): -

$ su notes
$ cd /local/notesdata
$ /opt/ibm/lotus/bin/server

Sadly this failed with: -

WARNING: the maximum number of file handles (ulimit -n)
           allowed for Domino is 1024.
         See Lotus Tech Note 1221870 and set the allowable maximum to 20000.
./java -ss512k -Xoss5M -cp jhall.jar:cfgdomserver.jar:./ndext/ibmdirectoryservices.jar lotus.domino.setup.WizardManagerDomino -data /local/notesdata
Please edit your shell's DISPLAY environment variable to reflect an unlocked terminal that you would like to launch the Domino Setup Program on.
*Warning all runtime debug info will be logged to /local/notesdata/setuplog.txt
Now I have seen this problem before, and immediately looked at the following IBM Technotes: -

Setting up a Domino server on a UNIX-based system

Error: "Please edit your shell's DISPLAY environment variable..." when launching Domino remote server setup

including running the command ( as root ): -
$ xhost +

but nothing was helped.

I then found this Technote: -

Red Hat 6 Linux OS: Domino will not install

which said, in part, that I was missing a bunch of required libraries: -

Domino requires the following packages to be installed. They can be located on the RHEL6 distribution disks or installed via RPM.

glibc-2.12-1.7.el6.i686
libgcc-4.4.4-13.el6.i686
libstdc++-4.4.4-13.el6.i686

The packages listed above are sufficient to install Domino in silent and console modes.

To run GUI Domino installer, you will need additional xWindows packages:

libXtst-1.0.99.2-3.el6.i686

libXmu-1.0.5-1.el6.i686
libXp-1.0.0-15.1.el6.i686

To run GUI setup you will need two more packages:


libXft-2.1.13-4.1.el6.i686.rpm
libXi-1.3-3.el6.i686.rpm


In the end, this is what I ended up installing: -

$ yum install -y libXtst-1.0.99.2-3.el6.i686
$ yum install -y libXmu-1.0.5-1.el6.i686
$ yum install -y libXp-1.0.0-15.1.el6.i686
$ yum install -y libXft-2.1.13-4.1.el6.i686
$ yum install -y --skip-broken libXft-2.1.13-4.1.el6.i686
$ yum install -y libXi-1.3-3.el6.i686

Note that libXft didn't go on - this became a real PITA.

The solution, as with many other things, was to hook up my RHEL VM to my company's network, from where I can connect to a Red Hat Enterprise Network mirror, and run: -

$ yum update

as root.

Once I updated my system to the latest and greatest RHEL 6.2, I was able to successfully install libXft and then start my Domino server.

The moral of the story ?

Ensure that your RHEL boxen is up-to-date before you start installing Domino.

Other than that, all is good.

Finally, I then updated Domino to 8.5.3 FP2 as follows: -

$ cd /tmp
$ rm -Rf linux             ( to clear down the original Domino installation code )
$ tar xvf /mnt/hgfs/Software/LD853/lotus_domino853FP2_linux_x86.tar
$ cd linux/domino
$ ./install -script script.dat

This uses the supplied response file to update Domino to 8.5.3 FP2.

Job done :-)

OSX - Climbing the Mountain Lion

Well, after much furore, Mac OSX 10.8 Mountain Lion was released on Wednesday 25 July.

I, like the rest of the world, downloaded it ( which took an absolute age - 2-3 hours on a 4 Mb/s ADSL connection, bearing in mind that it's over 4 GB in size ).

My plan is to install this onto my other Mac - a late 2008 MacBook Pro Core Duo with 8 GB RAM and a 320 GB spinny disk ( 5,400 RPM ), as a fresh install.

Rather than burning it onto a DVD, which I avoided because I'll eventually want to install it on my new MacBook Pro, which doesn't have a DVD drive, I chose to "burn" it onto a 8 GB USB key.

That, it turns out, was part of the problem.

So I followed one of a series of articles: -

Installing Mountain Lion Clean


How to Burn OS X Mountain Lion to a DVD or USB Flash Drive

How to make a bootable Mountain Lion install drive

all of which describe, in clear and precise detail, how to use Disk Utility to "burn" the installer onto a USB key.

However, Disk Utility would also fail with "Could not restore - Invalid argument" at the end of the process - after about 30 minutes and following the Verification process.

No matter how many times I tried, using different combinations of the advice given, I couldn't get away from that error.

Despite this, I tried the installation - I booted the MBP from the USB key ( having first backed up my data in a number of places - see below for details ), initialised the hard disk, and took the option to reinstall OSX.

This took the requisite 4-5 minutes and then .... failed with "Can't download the additional components needed to install OS X".

So back I went to Disk Utility, but kept getting the same error as before.

In semi-desperation, I tried a different tack - following a link from a Google Groups post,  I downloaded a piece of so-called donation-ware software - Lion Disk Maker - which used a different mechanism to burn the downloaded code ( InstallESD.dmg ) to the USB key.

This took an equally long time, and then failed with: -






At that point, I was ready to give up. I even started thinking about how I might somehow do a network install - I'm sure I heard @EwenRankin make reference to that on the @BritishTechMac show a week or so ago.

And then inspiration hit me - perhaps there's something wrong with my USB key :-)

So I popped out to Sainsbury's this morning, and picked up an Optima 8 GB USB 2.0 key for the princely sum of £7.99 - that's quite expensive, considering that it works out at an exchange rate of £1 for 1 GB, but hey .... it's only money.

I reverted back to the original Disk Utility method to burn the ML code onto the key - that took about 35 minutes (ish), but did NOT NOT NOT fail with any errors.

I'm just completing the installation of Mountain Lion as I type - the initial 4-5 minute process ( to install the boot loader etc. onto the MBP's spinny disk ) worked a treat.

So far, so good :-)

I'm sure I'll post more about ML shortly ...


Desktop SSO with WebSphere Application Server 7 and MS Active Directory - It's Ain't Working

Am posting this to remind myself how to resolve an issue of my own making.

Yesterday, I was working to resolve an issue whereby users from one of a number of Active Directory domains were unable to automagically log in to WebSphere Application Server v7 ( hosting IBM Connections v3 and IBM WebSphere Portal v7 ) using SPNEGO/Kerberos.

The user would arrive at the site, via a load-balanced URL, but would be presented with the login page, rather than getting into the application transparently.

I knew that this worked for me, in another AD domain, so was reasonably confident that the AD and SPNEGO configuration was OK.

Therefore, I enabled tracing in WAS using this trace string: -

*=info: com.ibm.ws.security.spnego.*=all

( I love the way that WAS 7 allows one to enable tracing in-flight, without needing to restart the JVM ).

I saw the usual bunch of SPNEGO messages, indicating that WAS was pulling out the userPrincipalName (UPN) attribute e.g. hayd@foobar.com from the SPNEGO token.

However, I also saw references to a First Failure Data Capture (FFDC) log, and a corresponding com.ibm.websphere.wim.exception.EntityNotFoundException error.

This was the main error within the FFDC log: -

...
[25/07/12 17:13:28:341 BST]     FFDC
Exception:com.ibm.websphere.wim.exception.EntityNotFoundException
SourceId:com.ibm.websphere.security.EntryNotFoundException ProbeId:190
Reporter:com.ibm.websphere.security.EntryNotFoundException@48104810

com.ibm.websphere.wim.exception.EntityNotFoundException: CWWIM4001E The 'bloggsf@snafu.com' entity was not found.
 at com.ibm.ws.wim.registry.util.UniqueIdBridge.getUniqueUserId(UniqueIdBridge.java:226)
 at com.ibm.ws.wim.registry.WIMUserRegistry$6.run(WIMUserRegistry.java:365)


Given that the error was coming from the WebSphere Identity Manager (WIM) component of WAS, I had a fair suspicion of the root cause.

I compared and contrasted the cell-level wimconfig.xml file, looking at the working domain ( for the UPN hayd@foobar.com ): -


     
       
          PersonAccount
       

       
          PersonAccount
       

       
          PersonAccount
       

       
          Group
...

and the failing domain ( for the UPN bloggsf@snafu.com ): -


     
       
          PersonAccount
       

       
          PersonAccount
       

       
          Group


Can you spot the error ? I bet you can ….

I'd forgotten to explicitly add: -

       
          PersonAccount
       

to the definition for the newly added realms ( for the two new AD domains ).

Therefore, WAS/WIM was correctly pulling the userPrincipalName attribute, but did not know what to do with that i.e. what to map it to in WIM.

Once I explicitly mapped userPrincipalName to uid, WAS/WIM could then correctly use it as a login attribute ( along with commonName - cn ), and SSO started working.

Something else to add to my ever-evolving presentation: -

Desktop Single Sign-On in an Active Directory World

Desktop SSO with WebSphere Application Server 7 and MS Active Directory - It's Ain't Working

Am posting this to remind myself how to resolve an issue of my own making.

Yesterday, I was working to resolve an issue whereby users from one of a number of Active Directory domains were unable to automagically log in to WebSphere Application Server v7 ( hosting IBM Connections v3 and IBM WebSphere Portal v7 ) using SPNEGO/Kerberos.

The user would arrive at the site, via a load-balanced URL, but would be presented with the login page, rather than getting into the application transparently.

I knew that this worked for me, in another AD domain, so was reasonably confident that the AD and SPNEGO configuration was OK.

Therefore, I enabled tracing in WAS using this trace string: -

*=info: com.ibm.ws.security.spnego.*=all

( I love the way that WAS 7 allows one to enable tracing in-flight, without needing to restart the JVM ).

I saw the usual bunch of SPNEGO messages, indicating that WAS was pulling out the userPrincipalName (UPN) attribute e.g. hayd@foobar.com from the SPNEGO token.

However, I also saw references to a First Failure Data Capture (FFDC) log, and a corresponding com.ibm.websphere.wim.exception.EntityNotFoundException error.

This was the main error within the FFDC log: -

...
[25/07/12 17:13:28:341 BST]     FFDC 
Exception:com.ibm.websphere.wim.exception.EntityNotFoundException 
SourceId:com.ibm.websphere.security.EntryNotFoundException ProbeId:190 
Reporter:com.ibm.websphere.security.EntryNotFoundException@48104810

com.ibm.websphere.wim.exception.EntityNotFoundException: CWWIM4001E The 'bloggsf@snafu.com' entity was not found.
 at com.ibm.ws.wim.registry.util.UniqueIdBridge.getUniqueUserId(UniqueIdBridge.java:226)
 at com.ibm.ws.wim.registry.WIMUserRegistry$6.run(WIMUserRegistry.java:365)

Given that the error was coming from the WebSphere Identity Manager (WIM) component of WAS, I had a fair suspicion of the root cause.

I compared and contrasted the cell-level wimconfig.xml file, looking at the working domain ( for the UPN hayd@foobar.com ): -

      <config:attributeConfiguration> 
        <config:attributes defaultValue="544" name="userAccountControl"> 
          <config:entityTypes>PersonAccount</config:entityTypes> 
        </config:attributes> 
        <config:attributes name="userPrincipalName" propertyName="uid"> 
          <config:entityTypes>PersonAccount</config:entityTypes> 
        </config:attributes> 
        <config:attributes name="samAccountName" propertyName="cn"> 
          <config:entityTypes>PersonAccount</config:entityTypes> 
        </config:attributes> 
        <config:attributes defaultAttribute="cn" name="samAccountName"> 
          <config:entityTypes>Group</config:entityTypes>
...

and the failing domain ( for the UPN bloggsf@snafu.com ): -

      <config:attributeConfiguration> 
        <config:attributes defaultValue="544" name="userAccountControl"> 
          <config:entityTypes>PersonAccount</config:entityTypes> 
        </config:attributes> 
        <config:attributes name="samAccountName" propertyName="cn"> 
          <config:entityTypes>PersonAccount</config:entityTypes> 
        </config:attributes> 
        <config:attributes defaultAttribute="cn" name="samAccountName"> 
          <config:entityTypes>Group</config:entityTypes>

Can you spot the error ? I bet you can ….

I'd forgotten to explicitly add: -

        <config:attributes name="userPrincipalName" propertyName="uid"> 
          <config:entityTypes>PersonAccount</config:entityTypes> 
        </config:attributes> 

to the definition for the newly added realms ( for the two new AD domains ).

Therefore, WAS/WIM was correctly pulling the userPrincipalName attribute, but did not know what to do with that i.e. what to map it to in WIM.

Once I explicitly mapped userPrincipalName to uid, WAS/WIM could then correctly use it as a login attribute ( along with commonName - cn ), and SSO started working.

Something else to add to my ever-evolving presentation: -


Tuesday, 24 July 2012

Monday, 23 July 2012

IBM Worklight Education - Free Free Free

Thanks to Rob Novak for sharing this: -

Course description: Introduction to IBM Worklight V5.0 for Application Development and Deployment - New

This 2-day, self-paced course explains how to develop mobile web applications by using IBM Worklight Studio, a plug-in for WebSphere Developer Tools (WDT) for Eclipse. It also covers how to deploy the applications to an IBM Worklight Server running on a WebSphere Application Server Liberty Profile.

The course covers applications and adapters, and looks at security issues such as user authentication and how to protect sensitive data that is held on a mobile device. Other topics include notification of updates, globalization, and the various JavaScript languages that can be used.

In addition to the lectures and demonstrations, students can download optional sample applications and exercises for further study.

and the cost ?

Free Free Free

Want to enrol ? Go here.

Thanks for sharing, Rob :-)

Note to self - Firefox and local connections

 Whilst trying to hit my NAS from Firefox on my Mac, I kept seeing errors such as:- Unable to connect Firefox can’t establish a connection t...