IBM Verify

 View Only
  • 1.  Proper fixpack distribution for containers

    Posted Tue October 03, 2023 10:46 AM

    On all the docker containers, we set the FIXPACKS environment variable on each container (app) to a space separated list of fixpack names to load (per documentation).  In the past, we have only used the configuration container and not a snapshot manager.  Hence, we just put those fixpacks under /var/shared/fixpacks on the config container.

    Now that we are using snapshot managers instead of a central config container, I have found we need to put the fixpacks on the snapshot managers under the fixpacks directory.  However, I believe from my previous testing pushing the fixpacks has to be manually done to each snapshot manager.

    Is there a way to make the configuration container push the fixpacks to all the snapshot managers, say when publishing the latest configuration (snapshot)?  Or is the process for fixpacks to always have to put the fixpacks on each snapshot manager manually?

    Thanks!



    ------------------------------
    Matt Jenkins
    ------------------------------


  • 2.  RE: Proper fixpack distribution for containers

    Posted Tue October 03, 2023 04:46 PM

    Matt,

     

    I can confirm that the publishing of fix-packs is always manual.

     

    Thanks.

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     

     






  • 3.  RE: Proper fixpack distribution for containers

    Posted Tue October 03, 2023 05:17 PM

    @Scott Exton Thanks for confirming.  I just wrote a quick shell script I can run from the configuration container to use it's list of snapshot managers and credentials and sync the fixpacks across all the snapshot managers.

    One additional question, I noticed the DELETE method does not work against the snapshot manager.  However, the operator documentation seems to indicate it should work.  I don't see a DELETE method defined for the Python http server that is used for the snapshot manager.

    Is this something that can be corrected?  Should I open an L2 support case, or an RFE?  Thanks!

    10.125.132.100 - - [03/Oct/2023 21:04:24] "DELETE /fixpacks/IJ45492_10050v2.fixpack HTTP/1.1" 501 -
    10.125.132.100 - - [03/Oct/2023 21:04:24] code 501, message Unsupported method ('DELETE')

    Reference:

    https://github.com/IBM-Security/verify-access-operator/blob/master/README.md#delete



    ------------------------------
    Matt Jenkins
    ------------------------------



  • 4.  RE: Proper fixpack distribution for containers

    Posted Tue October 03, 2023 05:48 PM

    Matt,

     

    Just to confirm, you are talking about the snapshot manager (icr.io/isva/verify-access-snapshotmgr) image, and not the operator, and you are asking for the snapshot manager to support the same delete operation as the operator (https://github.com/IBM-Security/verify-access-operator/blob/master/README.md#delete)?

     

    If so, I would suggest that you create an idea/RFE for this.

     

    Thanks.

     

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     

     






  • 5.  RE: Proper fixpack distribution for containers

    Posted Wed October 04, 2023 08:58 AM
    Edited by Matt Jenkins Wed October 04, 2023 08:58 AM

    @Scott Exton you are correct, I was referring to the standalone manager.  I had assumed the code base would be similar but apparently not.  I'll open an RFE/idea for it.  The idea # is ISAM-I-1250.

    I'd like to get to the point of using the operator.  However, we have some challenges internally here that make it difficult to load anything onto our OpenShift infrastructure.  The IAM team doesn't maintain any sort of admin access on the OpenShift environments we run on top of, so it makes it time consuming to get anything outside of the standard OCP installation going.



    ------------------------------
    Matt Jenkins
    ------------------------------