Showing posts sorted by relevance for query ltpa. Sort by date Show all posts
Showing posts sorted by relevance for query ltpa. Sort by date Show all posts

Tuesday, 13 May 2014

IBM Business Monitor 8.0.1.2 - Problems emitting events from IBM BPM Advanced 8.5

So I'm on a journey of discovery, working with a colleague to set up IBM BPM -> IBM Business Monitor integration for the very first time.

I will write up my notes in due course, but I did hit two problems, one of which I've referenced below, purely for information.

The thing that kicked this off was an exception: -

Track support for CWMAX4230 error on IBM® WebSphere® Business Monitor model configuration.

that my colleague saw when he tried to deploy a Monitor model .....


Briefly, it's necessary to set up a security relationship between BPM and Monitor, in order that the BPM server can publish events to a Service Integration bus topic, to which Monitor can then subscribe.

This requires the exchange of certain security information, including SSL certificates and, if one so chooses, Lightweight Third Party Authentication (LTPA) tokens.

LTPA tokens are used to assert the identity of a user from the BPM environment ( which is running on one WAS cell ) to the Monitor environment ( which is running on a second WAS cell ).

Now I've used LTPA many many times in the past, usually to integrate WebSphere Portal with IBM Connections, IBM Sametime with IBM Connections, IBM Quickr with WebSphere Portal, IBM Domino with WebSphere Portal etc.

In essence, one generates a LTPA key on server A ( BPM cell ) and imports it into server B ( Monitor cell ), and vice versa.

The LTPA token uses the WebSphere Identity Manager (WIM) realm, which is typically defaultWIMFileBasedRealm e.g.

...
com.ibm.websphere.ltpa.Realm=defaultWIMFileBasedRealm
...

In essence, we set up a trust relationship between the two WAS cells, using the exported/imported LTPA keys.

However, one other important thing is that the LTPA token, generated and delivered back to the end-user, and then used to assert the user's identity to the target WAS cell, is generated with an expiration interval.

Therefore, the clock on the server that generated it needs to be in sync with the target WAS server.

If the clocks aren't in sync, then we got a problem ..... :-)

So this is what I had: -

Monitor

Tue May 13 05:49:02 CDT 2014

BPM

Tue May 13 11:46:24 CDT 2014

Thankfully, this old but useful document: -


This issue is resolved through the following actions:

• Enable the exchange of LTPA keys between the WebSphere Business Monitor and WebSphere Process Server nodes. Refer to WebSphere Business Monitor, Version 6.1 product documentation for "Sharing LTPA keys" at: http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r1mx/index.jsp?topic=/com.ibm.btools.help.monitor.install.doc/security/ltpa_cfg.html
• Assure that the system clocks of the WebSphere Business Monitor and WebSphere Portal Server nodes are synchronised

For the record, I was also seeing this: -

[5/13/14 11:49:30:432 CDT] 00000559 LTPAServerObj W   SECJ0371W: Validation of the LTPA token failed because the token expired with the following info: Token expiration Date: Tue May 13 11:46:00 CDT 2014, current Date: Tue May 13 11:49:30 CDT 2014 Token attributes:  username=user:defaultWIMFileBasedRealm/uid=wasadmin,o=defaultWIMFileBasedRealm.. This warning might indicate expected behavior. Please refer to technote at http://www-01.ibm.com/support/docview.wss?uid=swg21594981
.

in the SystemOut.log of the BPM cell's Deployment Manager.

Bottom line, get your clocks in order or LTPA won't work :-)

Thursday, 25 October 2012

Lotus Domino - For a change ….

This article outlines a couple of potentially useful tips for Lotus Domino administrators.

Whilst helping a friend debug a problems with the import of a WebSphere LTPA token into Domino, I "discovered" two useful (to me) things: -

Remote Console

Firstly, when running a remote Domino server, it's nice to be able to access the console at your desktop, rather than needing to walk across the floor to the server. In my case, the Domino server is running on a Red Hat Enterprise Linux 6.3 VMware image on my Lenovo Thinkpad ( which is running Ubuntu 12.04 ) on my desk in Hursley - which is about 25 miles from where I'm sitting.

Now there are various ways to get access to the Domino console ( especially when the server is running on Linux ), not least of which is to start the server within a terminal session: -

$ /local/notesdata/DomShrct.sh

or: -

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

So, here's a third way to get the console working, in a GUI :-)

This requires an X11 tunnel to be created between the client PC ( on which the X11 server actually runs !! ) and the target server.

cd /local/notesdata
/opt/ibm/lotus/bin/server -jc

The -jc option is the thing that starts the Java Console, which is then tunnelled back from the server to the client, and the command returns: -

Domino Server Controller started at 25/10/12 12:18.
Host name is localhost/127.0.0.1
Listening for connect requests on TCP Port:2050

Domino Console started at 25/10/12 12:18.
localAdmin connected from localhost/127.0.0.1 at 25/10/12 12:19.


etc.

More importantly, an X11 window pops up with the console contained within


Along with the File menu shown above, there's also some useful functionality on the Edit menu: -


and the View menu: -


So you now have another choice for the Domino console, along with the terminal and the nice-but-limited Web Administrator ( http://wp7.uk.ibm.com/webadmin.nsf ).

LTPA Token Import Debugging

As per this IBM Technote: -


this message is rather annoying: -


So Domino 8.5.X has a solution - the Domino configuration parameter - debug_ltpa_key_import=1 - which SHOULD provide some rather useful debug output when importing an LTPA token - as per the Technote's examples: -

Successful import of WAS key:

01/14/2009 03:35:48.33 PM [1208:0002-1274] LtpaImportWSKeyFile> Importing WebSphere LTPA keys from file at path c:\lotus\waskeys
01/14/2009 03:35:48.34 PM [1208:0002-1274] LtpaImportWSKeyFile> Successfully read file to memory
01/14/2009 03:35:48.34 PM [1208:0002-1274] LtpaImportWSKeyFile> Successfully imported WebSphere LTPA keys from file


Bad Password given for WAS key:

01/14/2009 03:36:29.81 PM [1208:0002-1274] LtpaImportWSKeyFile> Importing WebSphere LTPA keys from file at path c:\lotus\waskeys
01/14/2009 03:36:29.81 PM [1208:0002-1274] LtpaImportWSKeyFile> Successfully read file to memory
01/14/2009 03:36:29.81 PM [1208:0002-1274] LtpaDecryptKey> Error as decrypted key has invalid padding
01/14/2009 03:36:29.81 PM [1208:0002-1274] LtpaEncodeData1> Error processing, phase 2
01/14/2009 03:36:29.81 PM [1208:0002-1274] LtpaImportWSKeyFile> Error processing key file contents, phase 3


Invalid or Nonexistent PATH specified:

01/14/2009 03:36:58.32 PM [1208:0002-1274] LtpaImportWSKeyFile> Importing WebSphere LTPA keys from file at path c:\waskeys
01/14/2009 03:36:58.32 PM [1208:0002-1274] LtpaImportWSKeyFile> Failed to open file at path c:\waskeys for reading

Sadly, at least for me, I couldn't work out precisely where this debug is supposed to appear - I'd assumed the Domino console ( see above ).

However, having set the parameter, and tested by importing a token using a Notes client against the server's names.nsf, whilst I did get "Error importing WebSphere LTPA keys. Check file path and password", I did NOT see anything else on the Domino console or in the log.nsf file.

I'm not the only person to have noticed this - I also see a forum posting here: -


I've raised a PMR with IBM Support, and will update this post when I find out more.

*UPDATE* My contact in IBM Support did point out my obvious mistake - the Technote requires that  debug_ltpa_key_import=1 be set in the CLIENT notes.ini rather than on the SERER. Doh!

Sadly, this didn't seem to make any difference, and I've fed this back to L2. Will see with what he comes back.

**UPDATE #2** So, I now have this working - three things to note: -

(a) As mentioned before, the  debug_ltpa_key_import=1 statement needs to be set in the notes.ini file on the Notes client - I was using Notes 8.5.3 FP1 Basic (nlnotes.exe) on Windows XP SP3
(b) There needs to be at least one Carriage Return/Line Feed character AFTER the parameter e.g.

...
NSF_HOOKS=NLNVP
SelectNamesDialogSize=189,828,155,518,
NameAddressingDlgLastViewName=0,List by name

debug_ltpa_key_import=1



...
(c) The output is written to the Notes client's console.log file - for me, this was located here: -

C:\lotus\notes\data\IBM_TECHNICAL_SUPPORT

( for the record,  notes.ini is in C:\lotus\notes 'cos I hate Windows path names that include space characters - C:\Program Files\ - I'm looking at you ... )

This is what the LTPA debug stuff looks like: -

Incorrect file name / path

[0408:0002-0D8C] 31/10/2012 10:13:15.84 LtpaImportWSKeyFile> Importing WebSphere LTPA keys from file at path c:\foobar.key
[0408:0002-0D8C] 31/10/2012 10:13:15.84 LtpaImportWSKeyFile> Failed to open file at path c:\foobar.key for reading


Incorrect password

[0408:0002-0D8C] 31/10/2012 10:16:30.76 LtpaImportWSKeyFile> Importing WebSphere LTPA keys from file at path c:\temp\bpm_ltpa.key
[0408:0002-0D8C] 31/10/2012 10:16:30.78 LtpaImportWSKeyFile> Successfully read file to memory
[0408:0002-0D8C] 31/10/2012 10:16:30.78 LtpaDecryptKey> Error as decrypted key has invalid padding
[0408:0002-0D8C] 31/10/2012 10:16:30.78 LtpaEncodeData1> Error processing, phase 2
[0408:0002-0D8C] 31/10/2012 10:16:30.78 LtpaImportWSKeyFile> Error processing key file contents, phase 3


Successful import

[0408:0002-0D8C] 31/10/2012 10:16:55.90 LtpaImportWSKeyFile> Importing WebSphere LTPA keys from file at path c:\temp\bpm_ltpa.key
[0408:0002-0D8C] 31/10/2012 10:16:55.90 LtpaImportWSKeyFile> Successfully read file to memory
[0408:0002-0D8C] 31/10/2012 10:16:55.90 LtpaImportWSKeyFile> Successfully imported WebSphere LTPA keys from file


As ever, shiny :-)

Thursday, 23 November 2017

"com.ibm.bpm.config.util.ConfigException: Failed to import LTPA:" seen when attempting to move a BPM Deployment Environment from one host to another

I saw this exception: -

[23/11/17 11:57:38:222 GMT] 00000001 BPMConfig     E com.ibm.bpm.config.BPMConfig main Failed to import LTPA:
                                 com.ibm.bpm.config.util.ConfigException: Failed to import LTPA:
        at com.ibm.bpm.config.util.ws.update.UpdateLTPAKeys.importLTPA(UpdateLTPAKeys.java:170)
        at com.ibm.bpm.config.util.ws.update.UpdateLTPAKeys.updateSecurityParameters(UpdateLTPAKeys.java:73)
        at com.ibm.bpm.config.util.ws.update.ConfigPostUpdater.postUpdate(ConfigPostUpdater.java:72)
        at com.ibm.bpm.config.BPMConfig.configureDeploymentEnvironment(BPMConfig.java:835)
        at com.ibm.bpm.config.BPMConfig$Actions.createDe(BPMConfig.java:4444)
        at com.ibm.bpm.config.cli.CreateAction.runInner(CreateAction.java:156)
        at com.ibm.bpm.config.cli.AbstractConfigAction.run(AbstractConfigAction.java:129)
        at com.ibm.bpm.config.cli.CreateAction.run(CreateAction.java:35)
        at com.ibm.bpm.config.BPMConfig.main(BPMConfig.java:299)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
        at java.lang.reflect.Method.invoke(Method.java:508)
        at com.ibm.wsspi.bootstrap.WSLauncher.launchMain(WSLauncher.java:234)
        at com.ibm.wsspi.bootstrap.WSLauncher.main(WSLauncher.java:96)
        at com.ibm.wsspi.bootstrap.WSLauncher.run(WSLauncher.java:77)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
        at java.lang.reflect.Method.invoke(Method.java:508)
        at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
        at java.lang.reflect.Method.invoke(Method.java:508)
        at org.eclipse.core.launcher.Main.invokeFramework(Main.java:340)
        at org.eclipse.core.launcher.Main.basicRun(Main.java:282)
        at org.eclipse.core.launcher.Main.run(Main.java:981)
        at com.ibm.wsspi.bootstrap.WSPreLauncher.launchEclipse(WSPreLauncher.java:406)
        at com.ibm.wsspi.bootstrap.WSPreLauncher.main(WSPreLauncher.java:169)
Caused by: java.io.FileNotFoundException: /home/wasadmin/ltpa.jceks (No such file or directory)
        at java.io.FileInputStream.open0(Native Method)
        at java.io.FileInputStream.open(FileInputStream.java:212)
        at java.io.FileInputStream.<init>(FileInputStream.java:152)
        at com.ibm.bpm.config.util.ws.update.UpdateLTPAKeys.importLTPA(UpdateLTPAKeys.java:119)
        ... 34 more

[23/11/17 11:57:38:229 GMT] 00000001 Ffdc          I com.ibm.ffdc.util.provider.FfdcOnDirProvider logIncident FFDC1003I: FFDC Incident emitted on /opt/ibm/WebSphere/AppServer/logs/config/ffdc_20171123-114355/ffdc.6106113977348147943.txt com.ibm.bpm.config.BPMConfig.main 163
[23/11/17 11:57:38:230 GMT] 00000001 BPMConfig     E com.ibm.bpm.config.BPMConfig main Failed to import LTPA:
[23/11/17 11:57:38:230 GMT] 00000001 SoeFactory    > com.ibm.bpm.config.soe.SoeFactory currentOs ENTRY
[23/11/17 11:57:38:230 GMT] 00000001 SoeFactory    > com.ibm.bpm.config.soe.SoeFactory getOsByType ENTRY Unix
[23/11/17 11:57:38:230 GMT] 00000001 SoeFactory    < com.ibm.bpm.config.soe.SoeFactory getOsByType RETURN Unix
[23/11/17 11:57:38:230 GMT] 00000001 SoeFactory    < com.ibm.bpm.config.soe.SoeFactory currentOs RETURN Unix
[23/11/17 11:57:38:230 GMT] 00000001 BPMConfig     I com.ibm.bpm.config.BPMConfig main The 'BPMConfig.sh -create -de /home/wasadmin/De1.properties' command failed. For more information, see the log file /opt/ibm/WebSphere/AppServer/logs/config/BPMConfig_20171123-114355.log.

whilst trying to move an IBM BPM Deployment Environment from one host to another.

The TL;DR; is that I'm running through a BPM 8.5.5 to 8.6 side-by-side migration, aiming to lift and shift the configuration from one box ( running 8.5.5 ) to another box ( running 8.6 ).

Having exported the 8.5.5 Deployment Environment: -

/opt/ibm/WebSphere/AppServer/bin/BPMConfig.sh -export -profile Dmgr01 -de De1 -outputDir  /mnt/BPM855.response

modified the resulting De1.properties file to reflect the new hostname: -

sed -i 's/bpm855/bpm86/g' De1.properties

I then attempted to create a new Deployment Environment on the box with the 8.6 binaries installed: -

/opt/ibm/WebSphere/AppServer/bin/BPMConfig.sh -create -de ~/De1.properties

This failed alas.

However, the message is clear: -

Caused by: java.io.FileNotFoundException: /home/wasadmin/ltpa.jceks (No such file or directory)

When I did the original export, I did get a bunch o' files: -

-rw-r--r-- 1 501 games  7540 Nov 23 11:38 Application-config-bpc.xml
-rw-r--r-- 1 501 games 76228 Nov 23 11:38 De1.properties
-rw-r--r-- 1 501 games  1639 Nov 23 11:38 fileRegistry.xml
-rw-r--r-- 1 501 games  1613 Nov 23 11:38 ltpa.jceks
-rw-r--r-- 1 501 games 13782 Nov 23 11:38 resources-bpc.xml


To validate the hypothesis, I cleaned up ( this on the "new" 8.6 environment ): -

/opt/ibm/WebSphere/AppServer/bin/manageprofiles.sh -deleteAll

rm -Rf /opt/ibm/WebSphereProfiles/

and then copied the ltpa.jceks to the same directory as the De1.properties file: -

cp /mnt/BPM855.response/ltpa.jceks ~

and tried again: -

/opt/ibm/WebSphere/AppServer/bin/BPMConfig.sh -create -de ~/De1.properties

which again failed: -

CWMCB2118E: No source fileRegistry.xml is found in path /home/wasadmin
The 'BPMConfig.sh -create -de /home/wasadmin/De1.properties' command failed. For more information, see the log file /opt/ibm/WebSphere/AppServer/logs/config/BPMConfig_20171123-125129.log.


Again, this makes sense, and that's easy to fix: -

cp /mnt/BPM855.response/fileRegistry.xml .

This time around ….

The 'BPMConfig.sh -create -de /home/wasadmin/De1.properties' command completed successfully.

Yay !

The moral of the story ? Make sure you have ALL the right files in ALL the right places !

For reference, here's the source for the Export process: -



Thursday, 29 December 2011

Lightweight Third Party Authentication (LTPA) FAQs

I've blogged about LTPA in the past, as it's an important part of any Single Sign-On (SSO) configuration, especially where WebSphere and/or Domino are working together.

This FAQ document contains a useful set of answers to common questions, including: -

What happens when the Security Cache, LTPA Token timeout, and session time out?
I want to force my users to re-login after a set "inactivity timeout" period. How is WebSphere Application Server supposed to work with regard to session timeouts and LTPA timeout.

etc.

Wednesday, 18 November 2009

SECJ0375E: Mismatch of realms during token validation

More notes from the front-line. Whilst trying to get WebSphere Portal <-> Lotus Connections <-> Lotus Quickr to place nicely using the Lightweight Third Party Authentication (LTPA) mechanism to achieve Single Sign-On, we were hitting these two messages: -

SECJ0375E: Mismatch of realms during token validation
SECJ0373E: Cannot create credential for the user <null> due to failed validation of the LTPA token. The exception is com.ibm.websphere.security.CustomRegistryException: The realm in the token: domino.uk.ibm.com:389 does not match the current realm: defaultWIMFileBasedRealm

This was being displayed in SystemOut.log on the Connections server. The second message really says it all.

When we configured the underlying WebSphere Application Server 6.1.0.23 instance for security, using a Federated Repository, Domino LDAP etc., we failed to change the realm name, but left it at the default of defaultWIMFileBasedRealm.

Interestingly, the LC25 Information Centre does imply that it's OK to leave it as-is: -

  • On the Federated Repositories page, enter an administrative user ID (for example, wasadmin) in the Primary administrative user name field. You can leave the other default settings, such as Realm name, unchanged.
    Note: The administrative user ID must be unique, and must not exist in the LDAP repository to be federated.


  • However, the LTPA token that had been generated on the portal server ( WebSphere Portal Server 6.1.0.2 running on WebSphere Application Server 6.1.0.25 ), and contained the line: -

    com.ibm.websphere.ltpa.Realm=domino.uk.ibm.com\:389

    The solution ?

    We simply changed the Realm Name from defaultWIMFileBasedRealm to domino.uk.ibm.com:389 and then restarted Connections.

    Job done, next .....

    Wednesday, 6 February 2019

    WebSphere Liberty Profile on Docker - An update

    In the context of my current project, we were talking about running WebSphere Liberty Profile on Docker, so here's an update: -

    Pull Liberty Docker Image

    docker pull websphere-liberty

    Using default tag: latest
    latest: Pulling from library/websphere-liberty
    7b722c1070cd: Pull complete 
    5fbf74db61f1: Pull complete 
    ed41cb72e5c9: Pull complete 
    7ea47a67709e: Pull complete 
    449210cbff3b: Pull complete 
    18c9d73c43bb: Pull complete 
    34afdf15398d: Pull complete 
    83a69d4d0146: Pull complete 
    bb817bf5c90c: Pull complete 
    ebb9f104335d: Pull complete 
    7714cd589690: Pull complete 
    d5191570a227: Pull complete 
    79c80066476d: Pull complete 
    acf01b72e712: Pull complete 
    c9445dae1684: Pull complete 
    Digest: sha256:fa2aaccc861c66fa20c8d6f67b8913b10517e6e441d2420d525e591b718c2e77
    Status: Downloaded newer image for websphere-liberty:latest

    Validate the image

    docker images

    REPOSITORY                                  TAG                 IMAGE ID            CREATED             SIZE
    websphere-liberty                           latest              a83fa38506a5        4 days ago          585MB
    hello-world                                 latest              fce289e99eb9        5 weeks ago         1.84kB
    registry.ng.bluemix.net/davehay42/davehay   helloworld          fce289e99eb9        5 weeks ago         1.84kB

    Start a container

    - Note that we're using the -v ( aka --volumes ) switch to make a local WAR file available to the container
    - Note that we're also mapping ports using -p and running the container as a daemon ( -d )

    docker run -d -p 80:9080 -p 443:9443 -v /tmp/ferret-1.2.war:/config/dropins/ferret-1.2.war websphere-liberty:latest

    4823dd0bc7a690a1ae6eafce6a0a8611fdf4cc73f6beadd6436c67c1a4838231

    - Note that the container ID is in full; the short version is 4823dd0bc7a6 as will be seen later using docker ps -a

    Check the container logs

    docker logs 4823dd0bc7a690a1ae6eafce6a0a8611fdf4cc73f6beadd6436c67c1a4838231

    Launching defaultServer (WebSphere Application Server 19.0.0.1/wlp-1.0.24.cl190120190124-2339) on IBM J9 VM, version 8.0.5.27 - pxa6480sr5fp27-20190104_01(SR5 FP27) (en_US)
    [AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
    [AUDIT   ] CWWKE0100I: This product is licensed for development, and limited production use. The full license terms can be viewed here: https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/license/base_ilan/ilan/19.0.0.1/lafiles/en.html
    [AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ibm/wlp/usr/servers/defaultServer/configDropins/defaults/keystore.xml
    [WARNING ] CWWKS3103W: There are no users defined for the BasicRegistry configuration of ID com.ibm.ws.security.registry.basic.config[basic].
    [AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
    [AUDIT   ] CWWKS4104A: LTPA keys created in 0.650 seconds. LTPA key file: /opt/ibm/wlp/output/defaultServer/resources/security/ltpa.keys
    [AUDIT   ] CWPKI0803A: SSL certificate created in 2.125 seconds. SSL key file: /opt/ibm/wlp/output/defaultServer/resources/security/key.jks
    [AUDIT   ] CWWKI0001I: The CORBA name server is now available at corbaloc:iiop:localhost:2809/NameService.
    [AUDIT   ] CWWKT0016I: Web application available (default_host): http://4823dd0bc7a6:9080/ferret/
    [AUDIT   ] CWWKZ0001I: Application ferret-1.2 started in 0.725 seconds.
    [AUDIT   ] CWWKF0012I: The server installed the following features: [beanValidation-2.0, servlet-4.0, ssl-1.0, jndi-1.0, jca-1.7, cdi-2.0, jdbc-4.2, jms-2.0, ejbPersistentTimer-3.2, appSecurity-3.0, appSecurity-2.0, j2eeManagement-1.1, wasJmsServer-1.0, javaMail-1.6, jaxrs-2.1, webProfile-8.0, jpa-2.2, jcaInboundSecurity-1.0, jsp-2.3, jsonb-1.0, ejbLite-3.2, managedBeans-1.0, jsf-2.3, ejbHome-3.2, jaxws-2.2, jsonp-1.1, jaxrsClient-2.1, el-3.0, concurrent-1.0, appClientSupport-1.0, ejbRemote-3.2, jaxb-2.2, mdb-3.2, jacc-1.5, javaee-8.0, batch-1.0, ejb-3.2, jpaContainer-2.2, jaspic-1.1, distributedMap-1.0, websocket-1.1, wasJmsSecurity-1.0, wasJmsClient-2.0].
    [AUDIT   ] CWWKF0011I: The server defaultServer is ready to run a smarter planet.

    Test the Ferret app using cURL

    curl http://localhost/ferret/

    Test the Ferret app using a real browser



    Look at the running Docker container(s)

    docker ps -a

    CONTAINER ID        IMAGE                      COMMAND                  CREATED             STATUS                         PORTS                                         NAMES
    4823dd0bc7a6        websphere-liberty:latest   "/opt/ibm/helpers/ru…"   22 minutes ago      Up 22 minutes                  0.0.0.0:80->9080/tcp, 0.0.0.0:443->9443/tcp   keen_torvalds
    3d8899de8f32        hello-world                "/hello"                 About an hour ago   Exited (0) About an hour ago                                                 happy_colden

    Open a shell to the container

    docker exec -i -t 4823dd0bc7a6 /bin/bash

    default@4823dd0bc7a6:/$ 

    Examine the detailed Liberty messages

    default@4823dd0bc7a6:/$ cat logs/messages.log 

    Check the Liberty version

    default@4823dd0bc7a6:/$ /opt/ibm/wlp/bin/server version

    WebSphere Application Server 19.0.0.1 (1.0.24.cl190120190124-2339) on IBM J9 VM, version 8.0.5.27 - pxa6480sr5fp27-20190104_01(SR5 FP27) (en_US)

    Exit the shell

    default@4823dd0bc7a6:/$ exit

    Stop the container

    docker stop 4823dd0bc7a6

    4823dd0bc7a6

    Remove the container

    docker rm 4823dd0bc7a6

    4823dd0bc7a6

    Thanks to this: -

    Official IBM WebSphere Application Server for Developers Liberty image.

    for inspiration.

    Wednesday, 10 April 2013

    CWWIM4529E and SECJ0369E seen when authenticating a user in WebSphere Application Server

    If you see exceptions such as: -

    [08/04/13 13:11:01:956 BST] 0000001d LTPAServerObj E   SECJ0369E: Authentication failed when using LTPA. The exception is com.ibm.websphere.wim.exception.PasswordCheckFailedException: CWWIM4529E  The password verification for the 'wasadmin' principal name failed. Root cause: 'javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]; Resolved object: 'com.sun.jndi.ldap.LdapCtx@a9d2c4f9''..

    [08/04/13 12:35:42:483 BST] 0000001c LTPAServerObj E   SECJ0369E: Authentication failed when using LTPA. The exception is com.ibm.websphere.wim.exception.WIMException.
    [08/04/13 12:35:42:485 BST] 0000001c FormLoginExte E   SECJ0118E: Authentication error during authentication for user wasadmin

    [08/04/13 12:34:41:460 BST] 0000001c UserRegistryI E   SECJ0363E: Cannot create credential for the user wasadmin because of the following exception com.ibm.websphere.wim.exception.WIMException
    [08/04/13 12:34:41:469 BST] 0000001c LTPAServerObj E   SECJ0373E: Cannot create credential for the user wasadmin due to failed validation of the LTPA token. The exception is com.ibm.websphere.wim.exception.WIMException

    and, most tellingly: -

    [08/04/13 12:46:28:546 BST] 00000024 exception     E com.ibm.ws.wim.adapter.file.was.FileAdapter create
                                     com.ibm.websphere.wim.exception.EntityAlreadyExistsException: CWWIM4501E  An entity with same unique name, 'uid=wasadmin,o=defaultWIMFileBasedRealm', or same RDN value already exists.

    and ( in SystemErr.log ): -

    [08/04/13 12:46:28:557 BST] 00000024 SystemErr     R com.ibm.websphere.wim.exception.EntityAlreadyExistsException: CWWIM4501E  An entity with same unique name, 'uid=wasadmin,o=defaultWIMFileBasedRealm', or same RDN value already exists.

    there's a very good chance that you do have TWO wasadmin accounts :-)

    In our case, we were using wasadmin from the File-Based Registry, which was working perfectly UNTIL we added LDAP.

    After much faffing about, we realised that we did indeed have a duplicate ID problem and, when we checked the LDAP, lo and behold, there was another account called wasadmin.

    Strangely, this had worked a few weeks back, so I can only assume that (a) the LDAP-based wasadmin was new or (b) it had previously had the same password as the local account, but had been subsequently changed.

    Bottom line, when adding LDAP, check that you're not going to hit this problem …. BEFORE you hit this problem.

    If in doubt, make sure that the account you use when creating the profile ( which automagically creates the File-Based Registry ) is going to be unique, unique, unique.

    :-)


    Thursday, 9 August 2018

    Deploying IBM MDM on WAS - Interesting quirk - CWWIM4537E for d9u6m12g7w

    So I'm working through the implementation of another IBM Master Data Management (MDM) Advanced Edition (AE) stack, this time using MDM AE 11.5.0.5.

    I'm installing it onto WebSphere Application Server (WAS) Network Deployment (ND) 8.5.5.13.

    Unlike other products with which I've worked, the installation is a bit more interactive, in that the deployment using IBM Installation Manager (IIM) requires connectivity to both the database ( Oracle in my case ) and to WAS ND.

    Therefore, it's necessary to have an existing ( but new ) WAS cell, with a Deployment Manager (DM) and managed node.

    Having created my Deployment Manager, and started it, I was working through IIM using it's console mode, and one step: -


    requires connectivity to the DM.

    This wasn't working, so I checked the DM log: -

    cat /opt/ibm/WebSphere/AppServer/profiles/Dmgr01/logs/dmgr/SystemOut.log

    and was surprised to see: -

    SystemOut.log:[09/08/18 09:45:42:971 BST] 0000010c LTPAServerObj E   SECJ0369E: Authentication failed when using LTPA. The exception is com.ibm.websphere.wim.exception.PasswordCheckFailedException: CWWIM4537E  No principal is found from the 'd9u6m12g7w' principal name..

    Given that I'd "told" IIM that the User name was wasadmin, I couldn't see where d9u6m12g7w was coming from.

    It seemed to be an internal SOAP user that IIM was sending, for no apparent reason.

    In case I'd missed something, I even created a user called d9u6m12g7w in WAS, and gave it full access ( as for the wasadmin user itself ), but then saw this: -

    SystemOut.log:[09/08/18 09:49:48:747 BST] 0000010a LTPAServerObj E   SECJ0369E: Authentication failed when using LTPA. The exception is com.ibm.websphere.wim.exception.PasswordCheckFailedException: CWWIM4513E  The password match failed for the 'd9u6m12g7w' principal name..

    which kinda makes sense - if IIM is using a "random" user, it's probably also using a "random" password.

    I dug around and found this: -


    which, although it references an older version of MDM, made some sense.

    The solution ( well, I'd call it a circumvention ) is this: -

    Resolving the problem

    Performing a new installation of InfoSphere MDM v11.4 on WebSphere Application Server v8.5.5.12 using the IBM Installation Manager GUI panels

    • Open the WebSphere Application Server Integrated Solutions console (admin console).
    • Go to System Administration > Deployment Manager > Java and Process Management > Process definition > Java Virtual Machine > Custom Properties.
    • Add the property com.ibm.ws.management.connector.soap.disableSOAPAuthCheck with a value of true.
    • Restart the Deployment Manager.

    Optional: After the InfoSphere MDM installation is complete, delete the property com.ibm.ws.management.connector.soap.disableSOAPAuthCheck and restart the Deployment Manager.

    Having restarted the DM, and retried the IIM step, I get further, although I still see this: -

    [09/08/18 10:30:24:097 BST] 00000101 LTPAServerObj E   SECJ0369E: Authentication failed when using LTPA. The exception is com.ibm.websphere.wim.exception.PasswordCheckFailedException: CWWIM4513E  The password match failed for the 'd9u6m12g7w' principal name..
    [09/08/18 10:30:24:100 BST] 00000101 RoleBasedAuth A   SECJ0305I: The role-based authorization check failed for admin-authz operation Server:getProcessType.  The user UNAUTHENTICATED (unique ID: unauthenticated) was not granted any of the following required roles: monitor, auditor, configurator, administrator, deployer, operator, adminsecuritymanager.


    Weird

    Saturday, 4 September 2010

    Lotus Connections Profiles - Not Playing Nicely with WebSphere Portal

    Whilst working on my WebSphere Portal <-> Lotus Connections integration challenge, I hit upon this exception: -

    [9/3/10 12:43:54:087 BST] 000000a5 ServletWrappe E   SRVE0068E: Uncaught exception thrown in one of the service methods of the servlet: /genjsp/lcaccelerator/portlets/profiles/ProfilesPortlet_myNetworkMain.jsp. Exception thrown : java.io.IOException: Server returned HTTP response code: 400 for URL: https://lc25.uk.ibm.com:9446/profiles/atom/profileService.do

    in the SystemOut.log file on the portal server.

    When I tried the URL: -

    https://lc25.uk.ibm.com:9446/profiles/atom/profileService.do

    in a browser window, I received the response: -

    CLFRN1172E: The request is invalid

    ( full details below ).

    >From a previous investigation, I know that Connections has a mechanism for retrieving an XML document ( known as a Service Document ) from Profiles using the Atom API via an HTTP request, as documented here: -

    http://publib.boulder.ibm.com/infocenter/ltscnnct/v2r0/topic/com.ibm.connections.25.help/r_api_prof_get_service_doc.html

    I tested the two mechanisms with which I'm most familiar: -

    https://lc25.uk.ibm.com:9446/profiles/atom/profileService.do?email=padmin@uk.ibm.com

    and: -

    https://lc25.uk.ibm.com:9446/profiles/atom/profileService.do?userid=24dcc5c0-23b2-102f-8265-e965b3598651

    This suggests that the portlet isn't sending a valid userid with the HTTP/Atom request.

    Given that I'm also seeing: -

    [9/4/10 14:42:22:133 BST] 00000071 LTPAServerObj W   SECJ0371W: Validation of the LTPA token failed because the token expired with the following info: Token expiration Date: Fri Sep 03 14:43:45 BST 2010, current Date: Sat Sep 04 14:42:22 BST 2010.

    in the SystemOut.log file on the Profiles WAS instance, I'm wondering whether there's an LTPA-related SSO issue between Portal and Connections.

    I'm going to regenerate the LTPA token on Portal, import it into Connections, and try again.

    Will report back ...









    Full details of exception: -

    -<error>
    <code>
    400
    </code>

    <message>
    CLFRN1172E: The request is invalid.
    </message>

    <trace>
    com.ibm.lconn.profiles.api.actions.APIException
    at com.ibm.lconn.profiles.api.actions.APIAction.assertNotNull(APIAction.java:161)
    at com.ibm.lconn.profiles.api.actions.APIAction.assertNotNull(APIAction.java:154)
    at com.ibm.lconn.profiles.api.actions.ProfilesServiceAction.getBean(ProfilesServiceAction.java:181)
    at com.ibm.lconn.profiles.api.actions.ProfilesServiceAction.getLastModified(ProfilesServiceAction.java:162)
    at com.ibm.lconn.profiles.web.actions.BaseAction.execute(BaseAction.java:150)
    at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:421)
    at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
    at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
    at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1146)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1087)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:145)
    at com.ibm.peoplepages.web.rpfilter.RPFilter.doFilter(RPFilter.java:154)
    at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
    at com.ibm.lconn.core.web.util.lang.LanguageFilter.doFilter(LanguageFilter.java:105)
    at com.ibm.lconn.core.web.util.lang.LanguageFilter.doFilter(LanguageFilter.java:73)
    at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
    at com.ibm.lconn.profiles.web.servlet.DisableSSLCachingFilter.doFilter(DisableSSLCachingFilter.java:62)
    at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
    at com.ibm.lconn.core.web.auth.LCRestSecurityFilter.doFilter(LCRestSecurityFilter.java:157)
    at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
    at com.ibm.lconn.profiles.web.servlet.AppContextFilter.doFilter(AppContextFilter.java:286)
    at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
    at com.ibm.lconn.core.web.auth.LCBasicAuthFilter.doFilter(LCBasicAuthFilter.java:79)
    at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
    at com.ibm.lconn.core.web.auth.LCUserDataConstraintFilter.doFilter(LCUserDataConstraintFilter.java:84)
    at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
    at com.ibm.lconn.core.web.request.HttpRequestFilter.doFilter(HttpRequestFilter.java:77)
    at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
    at com.ibm.lconn.core.web.util.lang.I18NFilter.doFilter(I18NFilter.java:203)
    at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
    at com.ibm.lconn.core.web.util.Utf8CharsetFilter.doFilter(Utf8CharsetFilter.java:45)
    at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
    at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:87)
    at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:837)
    at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:680)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:588)
    at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:525)
    at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:90)
    at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:751)
    at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1478)
    at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:126)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:458)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:387)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:267)
    at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.determineNextChannel(SSLConnectionLink.java:1037)
    at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.readyInboundPostHandshake(SSLConnectionLink.java:725)
    at com.ibm.ws.ssl.channel.impl.SSLConnectionLink$MyHandshakeCompletedCallback.complete(SSLConnectionLink.java:412)
    at com.ibm.ws.ssl.channel.impl.SSLUtils.handleHandshake(SSLUtils.java:869)
    at com.ibm.ws.ssl.channel.impl.SSLHandshakeIOCallback.complete(SSLHandshakeIOCallback.java:70)
    at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
    at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
    at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
    at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
    at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:196)
    at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:751)
    at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:881)
    at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1497)
    </trace>
    </error>

    Friday, 28 May 2010

    LTPA and WAS 6.1 Clusters

    Hmmm, whilst importing a new LTPA token into my WAS 6.1.0.29 cluster of Lotus Connections 2.5.0.1, having generated/exported it from my WAS 6.1.0.27 cluster of WebSphere Portal 6.1.5, I then found that I couldn't sychronise my two WAS nodes from the Deployment Manager.

    I was seeing: -

    00002a04 NodeSync E ADMS0005E: The system is unable to generate synchronization request:
    javax.management.JMRuntimeException: ADMN0022E: Access is denied for the getRepositoryEpoch operation on ConfigRepository MBean because of insufficient or empty credentials.


    etc.

    After some digging through the logs, and Googling, I found this Technote: -


    which, in essence, required me to turn off automatic LTPA token generation, not a bad thing in itself, and then remove the temporary files under temp, wstemp and config/temp in my Deployment Manager, before forcing the nodes to resychronise using the synchNode.sh script.


    Wednesday, 6 February 2019

    Fun and games with pushing Docker images to Kubernetes registry

    I hit a wee problem today, whilst pushing a Docker image ( WebSphere Liberty Profile ) from my local Docker registry to the registry associated with my IBM Kubernetes Service (IKS) cluster.

    For reference, I wrote about Liberty on Docker earlier: -

     WebSphere Liberty Profile on Docker - An update 

    I'd tagged the image: -

    docker tag websphere-liberty:latest registry.ng.bluemix.net/davehay42/wlp

    and pushed it to the newly created IKS cluster registry: -

    docker push registry.ng.bluemix.net/davehay42/wlp:latest

    I validated that the image was there: -

    ibmcloud cr image-list

    ...
    Listing images...

    REPOSITORY                                        TAG          DIGEST         NAMESPACE     CREATED       SIZE     SECURITY STATUS
    registry.ng.bluemix.net/davehay42/davehay         helloworld   92c7f9c92844   davehay42     1 month ago   977 B    No Issues
    registry.ng.bluemix.net/davehay42/wlp             latest       6631eaf721ad   davehay42     4 days ago    335 MB   No Issues
    registry.ng.bluemix.net/dmh_k8s_poc/dmh_k8s_poc   hello        92c7f9c92844   dmh_k8s_poc   1 month ago   977 B    No Issues
    ...

    and then created a K8S deployment: -

    kubectl create deployment wlp --image=latest

    Alas when I checked the pod to which the deployment was pushed: -

    kubectl describe pod `kubectl get pods | grep wlp | awk '{print $1}'`

    I saw this: -

    ...
      Type     Reason                 Age                From                   Message
      ----     ------                 ----               ----                   -------
      Normal   Scheduled              36s                default-scheduler      Successfully assigned wlp-598d758678-w4tj7 to 10.76.195.65
      Normal   SuccessfulMountVolume  36s                kubelet, 10.76.195.65  MountVolume.SetUp succeeded for volume "default-token-8znfb"
      Normal   Pulling                19s (x2 over 35s)  kubelet, 10.76.195.65  pulling image "a83fa38506a5"
      Warning  Failed                 18s (x2 over 34s)  kubelet, 10.76.195.65  Failed to pull image "a83fa38506a5": rpc error: code = Unknown desc = Error response from daemon: pull access denied for a83fa38506a5, repository does not exist or may require 'docker login'
      Warning  Failed                 18s (x2 over 34s)  kubelet, 10.76.195.65  Error: ErrImagePull
      Normal   BackOff                4s (x2 over 33s)   kubelet, 10.76.195.65  Back-off pulling image "a83fa38506a5"
      Warning  Failed                 4s (x2 over 33s)   kubelet, 10.76.195.65  Error: ImagePullBackOff
    ...

    Thankfully, after reading this tutorial: -


    This tutorial shows you how to run a simple Hello World Node.js app on Kubernetes using Minikube and Katacoda. Katacoda provides a free, in-browser Kubernetes environment.

    I realised where I was going wrong ....

    The image specified in the kubectl create deployment command was WAY too vague.

    I deleted my deployment

    kubectl delete deployment wlp

    and then recreated it using the full tag ( registry/namespace/tag ): -

    kubectl create deployment wlp --image=registry.ng.bluemix.net/davehay42/wlp

    I was then able to validate the deployment: -

    kubectl get deployments

    NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
    wlp       1         1         1            1           16m

    and validated the deployed pod: -

    kubectl describe pod `kubectl get pods | grep wlp | awk '{print $1}'`

    ...
    Events:
      Type    Reason                 Age   From                   Message
      ----    ------                 ----  ----                   -------
      Normal  Scheduled              17m   default-scheduler      Successfully assigned wlp-7865f8b77c-xlnf2 to 10.76.195.65
      Normal  SuccessfulMountVolume  17m   kubelet, 10.76.195.65  MountVolume.SetUp succeeded for volume "default-token-8znfb"
      Normal  Pulling                17m   kubelet, 10.76.195.65  pulling image "registry.ng.bluemix.net/davehay42/wlp"
      Normal  Pulled                 16m   kubelet, 10.76.195.65  Successfully pulled image "registry.ng.bluemix.net/davehay42/wlp"
      Normal  Created                16m   kubelet, 10.76.195.65  Created container
      Normal  Started                16m   kubelet, 10.76.195.65  Started container
    ...

    I was then able to validate that Liberty was up-and-running: -

    kubectl logs `kubectl get pods | grep wlp | awk '{print $1}'`

    Launching defaultServer (WebSphere Application Server 19.0.0.1/wlp-1.0.24.cl190120190124-2339) on IBM J9 VM, version 8.0.5.27 - pxa6480sr5fp27-20190104_01(SR5 FP27) (en_US)
    [AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
    [AUDIT   ] CWWKE0100I: This product is licensed for development, and limited production use. The full license terms can be viewed here: https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/license/base_ilan/ilan/19.0.0.1/lafiles/en.html
    [AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ibm/wlp/usr/servers/defaultServer/configDropins/defaults/keystore.xml
    [WARNING ] CWWKS3103W: There are no users defined for the BasicRegistry configuration of ID com.ibm.ws.security.registry.basic.config[basic].
    [AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
    [AUDIT   ] CWWKS4104A: LTPA keys created in 1.268 seconds. LTPA key file: /opt/ibm/wlp/output/defaultServer/resources/security/ltpa.keys
    [AUDIT   ] CWPKI0803A: SSL certificate created in 2.690 seconds. SSL key file: /opt/ibm/wlp/output/defaultServer/resources/security/key.jks
    [AUDIT   ] CWWKI0001I: The CORBA name server is now available at corbaloc:iiop:localhost:2809/NameService.
    [AUDIT   ] CWWKF0012I: The server installed the following features: [beanValidation-2.0, servlet-4.0, ssl-1.0, jndi-1.0, jca-1.7, cdi-2.0, jdbc-4.2, jms-2.0, ejbPersistentTimer-3.2, appSecurity-3.0, appSecurity-2.0, j2eeManagement-1.1, wasJmsServer-1.0, javaMail-1.6, jaxrs-2.1, webProfile-8.0, jpa-2.2, jcaInboundSecurity-1.0, jsp-2.3, jsonb-1.0, ejbLite-3.2, managedBeans-1.0, jsf-2.3, ejbHome-3.2, jaxws-2.2, jsonp-1.1, jaxrsClient-2.1, el-3.0, concurrent-1.0, appClientSupport-1.0, ejbRemote-3.2, jaxb-2.2, mdb-3.2, jacc-1.5, javaee-8.0, batch-1.0, ejb-3.2, jpaContainer-2.2, jaspic-1.1, distributedMap-1.0, websocket-1.1, wasJmsSecurity-1.0, wasJmsClient-2.0].
    [AUDIT   ] CWWKF0011I: The server defaultServer is ready to run a smarter planet.

    which is a good sign.

    I could then open a command prompt ( shell ) on the WLP container within the pod: -

    kubectl exec -i -t `kubectl get pods | grep wlp | awk '{print $1}'` /bin/bash

    default@wlp-7865f8b77c-xlnf2:/$ 

    and run a WLP command: -

    /opt/ibm/wlp/bin/server version

    WebSphere Application Server 19.0.0.1 (1.0.24.cl190120190124-2339) on IBM J9 VM, version 8.0.5.27 - pxa6480sr5fp27-20190104_01(SR5 FP27) (en_US)

    and examine the WLP server.xml file: -

    cat /opt/ibm/wlp/usr/servers/defaultServer/server.xml 


       
       
            javaee-8.0
       

       
        
       
       
        
       
         
             
       
        
       
       
                      host="*"
     httpPort="9080"
                      httpsPort="9443" />
                      
       
       


    This means that we have a pod deployed, hosting the WebSphere Liberty Profile container, and that WLP is looking clean-and-green.

    I then used kubectl cp to copy a JEE web application ( Ferret ) into the WLP container in the pod: -

    kubectl cp /tmp/ferret-1.2.war `kubectl get pods | grep wlp | awk '{print $1}'`:/opt/ibm/wlp/usr/servers/defaultServer/dropins/

    and validated that it started: -

    kubectl logs `kubectl get pods | grep wlp | awk '{print $1}'`

    ....
    [AUDIT   ] CWWKF0011I: The server defaultServer is ready to run a smarter planet.
    [AUDIT   ] CWWKT0016I: Web application available (default_host): http://wlp-7865f8b77c-xlnf2:9080/ferret/
    [AUDIT   ] CWWKZ0001I: Application ferret-1.2 started in 1.414 seconds.
    ...

    I then created a nodeport service: -

    kubectl create service nodeport wlp --tcp=80:9080

    and retrieved the node details: -

    kubectl describe node `kubectl get nodes | grep -i iks|awk '{print $1}'`
    ...
    Addresses:
      InternalIP:  10.76.195.65
      ExternalIP:  173.193.82.117
      Hostname:    10.76.195.65
    ...

    and the newly created nodeport service: -

    kubectl get services

    ...
    NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
    kubernetes   ClusterIP   172.21.0.1              443/TCP        1h
    wlp          NodePort    172.21.67.96          80:31135/TCP   23m
    ...

    Using the combination of the external IP ( 173.193.82.117 ) and the generated node port ( 31135 ), I was then able to access Liberty: -

    http://173.193.82.117:31135/


    AND the Ferret application: -

    http://173.193.82.117:31135/ferret/


    So, to summarise, we've taken a Docker image from the official repo ( https://hub.docker.com/_/websphere-liberty ), tagged it to make unique to us, pushed it to a newly created IBM Kubernetes Service (IKS) cluster, created a deployment ( deploying the container to a pod on a node ), created a service to expose the Liberty server's port 9080, and accessed Liberty via the web UI.

    We also showed how one can use kubectl cp and kubectl exec to access the internals of the running container, similar to the way that docker cp and docker exec work.

    Nice.

    Wednesday, 21 November 2018

    Goops, I broke WebSphere Liberty ....

    Having started a Liberty instance, I was seeing errors : -

    cat ~/wlp/usr/servers/foobar/logs/console.log

    Launching foobar (WebSphere Application Server 18.0.0.3/wlp-1.0.22.cl180320180905-2337) on Java HotSpot(TM) 64-Bit Server VM, version 1.8.0_181-b13 (en_GB)
    [AUDIT   ] CWWKE0001I: The server foobar has been launched.
    [AUDIT   ] CWWKE0100I: This product is licensed for development, and limited production use. The full license terms can be viewed here: https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/license/base_ilan/ilan/18.0.0.3/lafiles/en.html
    [AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
    [AUDIT   ] CWWKI0001I: The CORBA name server is now available at corbaloc:iiop:localhost:2809/NameService.
    [ERROR   ] CWWKE0702E: Could not resolve module: com.ibm.ws.ui [426]
      Unresolved requirement: Import-Package: org.apache.commons.io; packageType="was_internal"; version="1.4.0"

    [AUDIT   ] CWWKF0012I: The server installed the following features: [beanValidation-2.0, servlet-4.0, ssl-1.0, jndi-1.0, jca-1.7, cdi-2.0, transportSecurity-1.0, jdbc-4.2, jms-2.0, ejbPersistentTimer-3.2, appSecurity-3.0, appSecurity-2.0, j2eeManagement-1.1, wasJmsServer-1.0, javaMail-1.6, jaxrs-2.1, restConnector-2.0, webProfile-8.0, adminCenter-1.0, jpa-2.2, jcaInboundSecurity-1.0, jsp-2.3, jsonb-1.0, ejbLite-3.2, managedBeans-1.0, jsf-2.3, ejbHome-3.2, jaxws-2.2, localConnector-1.0, jsonp-1.1, jaxrsClient-2.1, el-3.0, concurrent-1.0, appClientSupport-1.0, ejbRemote-3.2, jaxb-2.2, mdb-3.2, jacc-1.5, javaee-8.0, batch-1.0, ejb-3.2, jpaContainer-2.2, json-1.0, jaspic-1.1, distributedMap-1.0, websocket-1.1, wasJmsSecurity-1.0, wasJmsClient-2.0].
    [AUDIT   ] CWWKF0011I: The server foobar is ready to run a smarter planet.
    [AUDIT   ] CWWKT0016I: Web application available (default_host): http://192.168.153.1:9080/ibm/adminCenter/explore-1.0/
    [AUDIT   ] CWWKT0016I: Web application available (default_host): http://192.168.153.1:9080/ibm/api/
    [AUDIT   ] CWWKT0016I: Web application available (default_host): http://192.168.153.1:9080/IBMJMXConnectorREST/
    [AUDIT   ] CWWKT0016I: Web application available (default_host): http://192.168.153.1:9080/ibm/adminCenter/serverConfig-1.0/


    for no apparent reason.

    BUT I KNOW WHAT'S CHANGED :-)

    I'd installed WLP 18.0.0.3 over 17.0.0.3, which is almost certainly the fault i.e. I merely unzipped one version over the other ….

    I tried cleaning the server: -

    ~/wlp/bin/server start foobar --clean

    but to no avail.

    So it's nuking time …..

    ( THIS IS MY TEST ENVIRONMENT - DON'T TRY THIS ON A PRODUCTION SYSTEM !! )

    Backup existing server.xml

    cp ~/wlp/usr/servers/foobar/server.xml /tmp

    Nuke existing installation

    rm -Rf ~/wlp

    Install WLP 18.0.0.3

    unzip ~/Downloads/wlp-javaee8-18.0.0.3.zip 

    Create a new server

    ~/wlp/bin/server create foobar

    ...
    Server foobar created.


    Create a SSL keystore

    ~/wlp/bin/securityUtility createSSLCertificate --server=foobar --password=passw0rd --validity=365

    ...
    Creating keystore /Users/davidhay/wlp/usr/servers/foobar/resources/security/key.jks

    Created SSL certificate for server foobar. The certificate is created with CN=10.128.1.1,OU=foobar,O=ibm,C=us as the SubjectDN.

    Add the following lines to the server.xml to enable SSL:

        <featureManager>
            <feature>ssl-1.0</feature>
        </featureManager>
        <keyStore id="defaultKeyStore" password="{xor}Lz4sLChvLTs=" />



    Restore previously backed-up  server.xml

    cp /tmp/server.xml ~/wlp/usr/servers/foobar/server.xml 

    For the record, this is what I have: -

    <server description="new server">

        <featureManager>
            <feature>javaee-8.0</feature>
            <feature>localConnector-1.0</feature>
            <feature>adminCenter-1.0</feature>
            <feature>transportSecurity-1.0</feature>
        </featureManager>

        <keyStore id="defaultKeyStore" password="{xor}Lz4sLChvLTs="/>
        
        <httpEndpoint host="*" httpsPort="9443" id="defaultHttpEndpoint"/>
                      
        <applicationManager autoExpand="true"/>

        <applicationMonitor updateTrigger="mbean"/>

        <basicRegistry id="basic" realm="BasicRealm">
            <user name="wasadmin" password="{xor}Lz4sLChvLTs="/>
        </basicRegistry>

        <administrator-role>
            <user>wasadmin</user>
        </administrator-role>

        <remoteFileAccess>
            <writeDir>${server.config.dir}</writeDir>
        </remoteFileAccess>
    </server>


    Start server

    ~/wlp/bin/server start foobar

    ...
    Starting server foobar.
    Server foobar started with process ID 64926.


    Check logs

    cat ~/wlp/usr/servers/foobar/logs/console.log

    ...
    Launching foobar (WebSphere Application Server 18.0.0.3/wlp-1.0.22.cl180320180905-2337) on Java HotSpot(TM) 64-Bit Server VM, version 1.8.0_181-b13 (en_GB)
    [AUDIT   ] CWWKE0001I: The server foobar has been launched.
    [AUDIT   ] CWWKE0100I: This product is licensed for development, and limited production use. The full license terms can be viewed here: https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/license/base_ilan/ilan/18.0.0.3/lafiles/en.html
    [ERROR   ] CWWKF0042E: A feature definition cannot  be found for the  admincenter-1.0 feature.  Try running the command, bin/installUtility install admincenter-1.0,  to install the feature. Alternatively, you can run the command, bin/installUtility install foobar,  to install all features that are referenced by this configuration.
    [AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
    [AUDIT   ] CWWKS4104A: LTPA keys created in 0.444 seconds. LTPA key file: /Users/davidhay/wlp/usr/servers/foobar/resources/security/ltpa.keys
    [AUDIT   ] CWWKI0001I: The CORBA name server is now available at corbaloc:iiop:localhost:2809/NameService.
    [AUDIT   ] CWWKF0012I: The server installed the following features: [beanValidation-2.0, servlet-4.0, ssl-1.0, jndi-1.0, jca-1.7, cdi-2.0, transportSecurity-1.0, jdbc-4.2, jms-2.0, ejbPersistentTimer-3.2, appSecurity-3.0, appSecurity-2.0, j2eeManagement-1.1, wasJmsServer-1.0, javaMail-1.6, jaxrs-2.1, webProfile-8.0, jpa-2.2, jcaInboundSecurity-1.0, jsp-2.3, jsonb-1.0, ejbLite-3.2, managedBeans-1.0, jsf-2.3, ejbHome-3.2, jaxws-2.2, localConnector-1.0, jsonp-1.1, jaxrsClient-2.1, el-3.0, concurrent-1.0, appClientSupport-1.0, ejbRemote-3.2, jaxb-2.2, mdb-3.2, jacc-1.5, javaee-8.0, batch-1.0, ejb-3.2, jpaContainer-2.2, jaspic-1.1, distributedMap-1.0, websocket-1.1, wasJmsSecurity-1.0, wasJmsClient-2.0].
    [AUDIT   ] CWWKF0011I: The server foobar is ready to run a smarter planet.


    noting that I'm missing adminCenter-1.0

    Stop server

    ~/wlp/bin/server stop foobar

    Install missing feature(s)

    ~/wlp/bin/installUtility install foobar

    Checking for missing features required by the server ...
    The server requires the following additional features: admincenter-1.0.  Installing features from the repository ...
    Establishing a connection to the configured repositories ...
    This process might take several minutes to complete.

    Successfully connected to all configured repositories.

    Preparing assets for installation. This process might take several minutes to complete.

    Additional Liberty features must be installed for this server.

    To install the additional features, review and accept the feature license agreement:
    Select [1] I Agree, or [2] I do not Agree:  1

    Step 1 of 20: Downloading servlet-3.0 ...
    Step 2 of 20: Installing servlet-3.0 ...
    Step 3 of 20: Downloading restConnector-1.0 ...
    Step 4 of 20: Installing restConnector-1.0 ...
    Step 5 of 20: Downloading jsp-2.2 ...
    Step 6 of 20: Installing jsp-2.2 ...
    Step 7 of 20: Downloading adminCenter-1.0 ...
    Step 8 of 20: Installing adminCenter-1.0 ...
    Step 9 of 20: Downloading cdi-1.2 ...
    Step 10 of 20: Installing cdi-1.2 ...
    Step 11 of 20: Downloading jaxrs-1.1 ...
    Step 12 of 20: Installing jaxrs-1.1 ...
    Step 13 of 20: Downloading servlet-3.1 ...
    Step 14 of 20: Installing servlet-3.1 ...
    Step 15 of 20: Downloading jaxrsClient-2.0 ...
    Step 16 of 20: Installing jaxrsClient-2.0 ...
    Step 17 of 20: Downloading jaxrs-2.0 ...
    Step 18 of 20: Installing jaxrs-2.0 ...
    Step 19 of 20: Validating installed fixes ...
    Step 20 of 20: Cleaning up temporary files ...


    All assets were successfully installed.

    Start product validation...
    Product validation completed successfully.

    Start server

    ~/wlp/bin/server start foobar

    Check logs

    cat ~/wlp/usr/servers/foobar/logs/console.log

    ...
    Launching foobar (WebSphere Application Server 18.0.0.3/wlp-1.0.22.cl180320180905-2337) on Java HotSpot(TM) 64-Bit Server VM, version 1.8.0_181-b13 (en_GB)
    [AUDIT   ] CWWKE0001I: The server foobar has been launched.
    [AUDIT   ] CWWKE0100I: This product is licensed for development, and limited production use. The full license terms can be viewed here: https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/license/base_ilan/ilan/18.0.0.3/lafiles/en.html
    [AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
    [AUDIT   ] CWWKI0001I: The CORBA name server is now available at corbaloc:iiop:localhost:2809/NameService.
    [AUDIT   ] CWWKF0012I: The server installed the following features: [beanValidation-2.0, servlet-4.0, ssl-1.0, jndi-1.0, jca-1.7, cdi-2.0, transportSecurity-1.0, jdbc-4.2, jms-2.0, ejbPersistentTimer-3.2, appSecurity-3.0, appSecurity-2.0, j2eeManagement-1.1, wasJmsServer-1.0, javaMail-1.6, jaxrs-2.1, restConnector-2.0, webProfile-8.0, adminCenter-1.0, jpa-2.2, jcaInboundSecurity-1.0, jsp-2.3, jsonb-1.0, ejbLite-3.2, managedBeans-1.0, jsf-2.3, ejbHome-3.2, jaxws-2.2, localConnector-1.0, jsonp-1.1, jaxrsClient-2.1, el-3.0, concurrent-1.0, appClientSupport-1.0, ejbRemote-3.2, jaxb-2.2, mdb-3.2, jacc-1.5, javaee-8.0, batch-1.0, ejb-3.2, jpaContainer-2.2, json-1.0, jaspic-1.1, distributedMap-1.0, websocket-1.1, wasJmsSecurity-1.0, wasJmsClient-2.0].
    [AUDIT   ] CWWKF0011I: The server foobar is ready to run a smarter planet.
    [AUDIT   ] CWWKT0016I: Web application available (default_host): http://192.168.153.1:9080/ibm/api/
    [AUDIT   ] CWWKT0016I: Web application available (default_host): http://192.168.153.1:9080/ibm/adminCenter/explore-1.0/
    [AUDIT   ] CWWKT0016I: Web application available (default_host): http://192.168.153.1:9080/ibm/adminCenter/serverConfig-1.0/
    [AUDIT   ] CWWKT0016I: Web application available (default_host): http://192.168.153.1:9080/IBMJMXConnectorREST/
    [AUDIT   ] CWWKT0016I: Web application available (default_host): http://192.168.153.1:9080/adminCenter/

    ...

    Good to go …..

    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...