IBM Security Verify

 View Only
Expand all | Collapse all

Upgrading the ISAM Docker image

  • 1.  Upgrading the ISAM Docker image

    Posted Thu January 16, 2020 10:19 AM
    Hi All,

    Currently we are using the ISAM Docker Image for Version 9.0.4 and it has been configured with an external SDS. 

    We need to upgrade this to v9.0.7 but are unsure as to how that will work.

    We tried using the snapshot of the v9.0.4 and copied it in v9.0.7 but due to some expired CA certificates that does not work and all the WebSEAL instances are not starting up. We also tried updating those CA certificates but that did not help.

    We would like to do a seamless upgrade without affecting the current configuration.

    We currently have 4 docker containers running, where 1 is running as the config service where as the other 3 are running as WebSEALs.

    Any pointers in this direction would help.

    ------------------------------
    Sushant Dusad
    Associate Technical Manager
    Great Software Laboratory
    Pune
    ------------------------------


  • 2.  RE: Upgrading the ISAM Docker image

    Posted Thu January 16, 2020 11:43 AM
    Sushant,

    Upgrade should be achieved by upgrading the configuration container to 9.0.7.0.  When the 9.0.7.0 configuration container starts it detects it has no 9.0.7.0 snapshot available, reads the 9.0.4.0 snapshot, converts it to 9.0.7.0, and saves it as 9.0.7.0 snapshot.  Any configuration changes made are saved as updated 9.0.7.0 snapshots.   The 9.0.4.0 snapshot is not updated.

    As you upgrade other containers (your WebSEALs) to 9.0.7.0 they will read this 9.0.7.0 snapshot and use it.
    Old WebSEALs (still at 9.0.4.0) will read the 9.0.4.0 snapshot.

    I didn't understand your issue with expired certificates.  I don't understand how the upgrade from 9.0.4.0 to 9.0.7.0 cause certificate expiry.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message


  • 3.  RE: Upgrading the ISAM Docker image

    Posted Tue October 20, 2020 09:24 PM
    Hi Jon,

    As we are trying to upgrade our container, I have stumble upon this post. We also wanted a seamless upgrade of the containers like what we are having in the appliance version.

    We have ibmcom/verify-access:10.0.0.0 and would like to upgrade to 10.0.0.1, as what you mentioned we need to upgrade the configuration container first.  We did the below steps:

    1. We are using docker-compose, we updated docker-compose.yaml for config container and the rest are still 10.0.0.0:
    isam-config:
    image: ibmcom/verify-access:10.0.0.1

    we have an existing snapshot isva_10.0.0.0_published.snapshot in our volume

    2. run docker-compose -f docker-compose.yaml up -d
    output:
    Recreating isam_isam-config_1 ...
    isam_isam-dsc_1 is up-to-date
    Recreating isam_isam-config_1 ... done

    879931ceacd7 ibmcom/verify-access:10.0.0.1 "/sbin/bootstrap.sh" 34 minutes ago Up 34 minutes (healthy) 443/tcp, 0.0.0.0:9443->9443/tcp isam_isam-config_1
    8a9b3696602f ibmcom/verify-access:10.0.0.0 "/sbin/bootstrap.sh" 41 hours ago Up 41 hours (healthy) 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 9443/tcp isam_isam-webseal_1
    711034e4a4ea ibmcom/verify-access:10.0.0.0 "/sbin/bootstrap.sh" 41 hours ago Up 41 hours (healthy) 9443/tcp, 0.0.0.0:10443->443/tcp, 0.0.0.0:10444->444/tcp isam_isam-dsc_1

    3. access config container. upload license. 

    Please correct me if I am wrong here, it says that it will automatically convert our old version snapshot in the volume, but in which part? We where tailing the logs of docker-compose the whole time no conversion was done. Please let us know if we miss a step here. 
    Thank you. 



    ------------------------------
    Pang Dela Cruz
    ------------------------------

    Original Message


  • 4.  RE: Upgrading the ISAM Docker image

    Posted Wed October 21, 2020 02:43 AM
    Pang,

    I'm pretty sure that you will not see an upgrade of the config file moving to 10.0.0.1 because this is just a fixpack release.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message


  • 5.  RE: Upgrading the ISAM Docker image

    Posted Wed October 21, 2020 09:00 PM
    Hi Jon,

    Thank you for your response and we appreciate it.
    We tried to install the fixpack in the container by updating the docker-compose.yaml and .env(we are using the same files in your git repo)

    Notice that there is no *.fixpack file in this release, only *.pkg, unlike when we do it in our appliance.
    https://www.ibm.com/support/fixcentral/swg/selectFixes?product=ibm%2FTivoli%2FIBM+Security+Verify+Access&fixids=10.0.0-ISS-ISVA-FP0001&source=SAR&function=fixId&parent=IBM%20Security

    But upon recreating of container, we received this error:

    isam-config_1 | 2020-10-21T08:05:59+0800: ---- Applying fixpack: isva_10.0.0.1_20200928-1645.pkg
    isam-dsc_1 | 2020-10-21T08:06:02+0800: ---- Applying fixpack: isva_10.0.0.1_20200928-1645.pkg
    isam-webseal_1 | 2020-10-21T08:06:23+0800: ---- Applying fixpack: isva_10.0.0.1_20200928-1645.pkg
    isam-config_1 | isva_10.0.0.1_20200928-1645.pkg: Signature verified
    isam-config_1 | isva_10.0.0.1_20200928-1645.pkg: Fix pack is not in the correct format
    isam-config_1 | umount: /tmp/mesa_install_fixpack566.mJPbsQ: must be superuser to umount
    isam-config_1 | isva_10.0.0.1_20200928-1645.pkg install failed
    isam-config_1 | isva_10.0.0.1_20200928-1645.pkg install failed
    isam-config_1 | 2020-10-21T08:06:34+0800: ---- Failed to apply fixpack: isva_10.0.0.1_20200928-1645.pkg
    isam-dsc_1 | isva_10.0.0.1_20200928-1645.pkg: Signature verified
    isam-dsc_1 | isva_10.0.0.1_20200928-1645.pkg: Fix pack is not in the correct format
    isam-dsc_1 | umount: /tmp/mesa_install_fixpack527.19B4cy: must be superuser to umount
    isam-dsc_1 | isva_10.0.0.1_20200928-1645.pkg install failed
    isam-dsc_1 | isva_10.0.0.1_20200928-1645.pkg install failed
    isam-dsc_1 | 2020-10-21T08:06:40+0800: ---- Failed to apply fixpack: isva_10.0.0.1_20200928-1645.pkg
    isam-webseal_1 | isva_10.0.0.1_20200928-1645.pkg: Signature verified
    isam-webseal_1 | isva_10.0.0.1_20200928-1645.pkg: Fix pack is not in the correct format
    isam-webseal_1 | umount: /tmp/mesa_install_fixpack532.XtZ7cP: must be superuser to umount
    isam-webseal_1 | isva_10.0.0.1_20200928-1645.pkg install failed
    isam-webseal_1 | isva_10.0.0.1_20200928-1645.pkg install failed
    isam-webseal_1 | 2020-10-21T08:07:00+0800: ---- Failed to apply fixpack: isva_10.0.0.1_20200928-1645.pkg


    Appreciate your help here Jon. Thank you.

    ------------------------------
    Pang Dela Cruz
    Middleware Administrator
    ADB
    ------------------------------

    Original Message


  • 6.  RE: Upgrading the ISAM Docker image

    Posted Thu October 22, 2020 03:25 AM
    Hi Pang,

    I'm sorry - I assumed some knowledge about the confusing use of the work "fixpack"...

    The "Fixpack" option in the LMI is only used for loading "hot fixes" from Support.  These make changes to individual files to fix a specific issue.  They are usually created and issued by support when working on a support case.  Usually they have a .fixpack extension.

    All other code updates are released as firmware updates (even what are called "interim fixes" or "fixpacks" in release management terms).
    So, the 10.0.0.1 "fixpack" (fixpack 1 for 10.0.0) is shipped as .pkg file which is loaded to an appliance as a firmware update.
    (it may also be available as .iso or .vhd for direct use for creation of new virtual appliances - not sure about that).

    For Docker, you should upgrade to a new fixpack by simply modifying the image specified for the containers (changing the tag).  This is (I think) what you were already doing:

    image: ibmcom/verify-access:10.0.0.0 -->image: ibmcom/verify-access:10.0.0.1

    You should use this new image version for all Verify Access containers (but not openldap/postgres if you have those in dev/test).

    I hope this helps clear up the confusion and sorry for not being clearer the first time around.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message


  • 7.  RE: Upgrading the ISAM Docker image

    Posted Thu October 22, 2020 03:41 AM
    Hi Jon,

    Yes thank you for the clarification. We really appreciate it.
    Back to our container, I already tried using the new image ibmcom/verify-access:10.0.0.1 that was pulled from docker store, updated the .env version. But what should be the behavior of it? will it pick up the existing snapshot isva_10.0.0.0_published.snapshot?
    Because what I notice when the config container started, it is like a NEW setup container and our existing setup in isva_10.0.0.0_published.snapshot is not loaded.
    We are just wondering if we are missing a step here? 

    Apology for bothering you on this, we are really new in ISAM container and we are waiting for Container and Openshift expert that will guide us on this migration from appliance to container. 

    We really appreciate you helping us. Thank you very much.

    ------------------------------
    Pang Dela Cruz
    Middleware Administrator
    ADB
    ------------------------------

    Original Message


  • 8.  RE: Upgrading the ISAM Docker image

    Posted Thu October 22, 2020 04:38 AM
    Hi Pang,

    I've recreated your issue and have done some investigation.  It appears that there is (unfortunately) a known issue with upgrading from 10.0.0.0 to 10.0.0.1 version when running in containers.  The new code is looking for a snapshot called isva_10.0.0.1_published.snapshot but the configuration container is not creating the migrated snapshot as it should.

    I was able to get my test system up and running by performing the following steps:
    1. Update .env file to specify 10.0.0.1 image tag
    2. Stop all Verify Access containers (leave DB and directory running)
    3. Start only configuration container (it comes up with empty configuration)
    4. Use "exec" command to manually copy isva_10.0.0.0_published.snapshot to isva_10.0.0.1_published.snapshot
    5. Restart configuration container (it comes up with working 10.0.0.1 configuration)
    6. Start all other Verify Access containers (they come up, read 10.0.0.1 snapshot, and start successfully)

    The docker-compose command I used to copy the configuration file was this:

    docker-compose exec isvaconfig cp /var/shared/snapshots/isva_10.0.0.0_published.snapshot /var/shared/snapshots/isva_10.0.0.1_published.snapshot

    If you would like more formal advice (which is probably a good idea for a production system), please open a support case.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message


  • 9.  RE: Upgrading the ISAM Docker image

    Posted Thu October 22, 2020 09:05 PM
    Hi Jon,

    This work like a charm!! Thank you very much for your help :)

    ------------------------------
    Pang Dela Cruz
    Middleware Administrator
    ADB
    ------------------------------

    Original Message


  • 10.  RE: Upgrading the ISAM Docker image

    Posted Thu November 12, 2020 04:13 AM
    A quick update on this thread...

    I uncovered an issue with the workaround above which causes a problem in environments that include the Distributed Session Cache (DSC).  The symptom is that, after the migration, WebSEAL is unable to contact the DSC because, in the DSC container, the dscd process is not running.

    I traced this issue to a problem that occurs when the DSC container attempts to locally migrate a configuration file from a previous version.  Usually migration is only performed on the configuration container but, by manually renaming a 10.0.0.0 configuration as 10.0.0.1, all 10.0.0.1 containers read this file, detect it is for an old version, and perform a local migration.

    To avoid this issue, I would recommend the following alternative workaround process if upgrading from 10.0.0.0 to 10.0.0.1 in a container environment:

    Starting with system running 10.0.0.0...
    1. Use "exec" command to manually copy isva_10.0.0.0_published.snapshot to isam_9.0.7.1_published.snapshot in configuration container.
    2. Update deployment (e.g. .env file) to specify 10.0.0.1 image tag
    3. Re-deploy system to use 10.0.0.1 images.

      The docker-compose command I used to copy the configuration file was this:

      docker-compose exec isvaconfig cp /var/shared/snapshots/isva_10.0.0.0_published.snapshot /var/shared/snapshots/isam_9.0.7.1_published.snapshot

      [alternatively, you could probably also manually create a snapshot with this name from the LMI]

      This process works because the 10.0.0.1 configuration container detects the 9.0.7.1-named configuration file (which avoids the issue that 10.0.0.0 config is not detected) but, during migration, will still correctly migrate it as a 10.0.0.0 file.  The configuration container saves the migrated snapshot as isva_10.0.0.1_published.snapshot which is then detected and loaded by all other 10.0.0.1 containers.

      Again, if you would like more formal advice (which is probably a good idea for a production system), please open a support case.

      Jon.

      ------------------------------
      Jon Harry
      Consulting IT Security Specialist
      IBM
      ------------------------------

      Original Message