IBM Security Verify

 View Only

Running same ISVA configuration concurrently during migration event

  • 1.  Running same ISVA configuration concurrently during migration event

    IBM Champion
    Posted Wed May 31, 2023 12:23 PM

    Is it possible/safe to run multiple configurations for the same PD environment during migration events, with the configuration only being touched on one configuration?  Here is the scenario:

    We are migrating the underlying container environment.  Unfortunately we are not using basic user mode.  So the user registry is a sticking point in having to use the same copy of the configuration between both copies of the configuration container as we migrate.  What I had planned to do was run both the same copy of the configuration in parallel until the cutover event.  I won't get into the details, but we aren't using a snapshot manager in the old environment so everything is fetching the config from the config container which is not accessible to the new environment.  So hence the need for the config container to run in parallel.  Also, the new environment has some different port numbers, so a few things get updated on the new environment after the config is copied over there.

    Now, to my concern...  The PD certs.  I noticed today when I copied the config from the old environment to the new environment, and then tried to publish the configuration on the new environment using the container CLI, I got this message warning about an automatic refresh of the keyfile.  Here is the message:

    oc rsh isam-config-0 mesa_control snapshotmgr_create_published
    2023-05-31-11:55:23.303-04:00I----- 0x10652121 WebSEAL-Mgmt-API WARNING bas mts PDCertSigner.cpp 813 0x7fe1edf56940
    HPDBA0289W   Automatic refresh of the certificate could not be performed because of error (0x132120c8).
    2023-05-31-11:55:23.305-04:00I----- 0x10652123 WebSEAL-Mgmt-API FATAL bas mts mtscertsignerclient.cpp 53 0x7fe1edf56940
    HPDBA0291I   Automatic refresh of the keyfile certificate failed.  The signed certificate could not be obtained from the policy server because of an error.
    isva_10.0.5.0_published.snapshot

    I've been bitten by these key refreshes in the past and messing around with different snapshots.  So I've got some concern now with allowing these environments to run in parallel like we had planned.

    So, my question is this.  What does the PD runtime update in the LDAP with regards to these certs?  When does this happen (what triggers it on containers)?  If I recall, there was a cert version # that is maintained on the PD servers (PDmgrd, webseald, etc.) and in LDAP.  Is this still a problem if the LDAP gets out of sync with the published configuration?  The same condition could happen without this migration and just simply restoring a snapshot from a couple weeks ago.  So what happens in those cases where an older snapshot is restored and things don't match?

    Are there risks I am not thinking of here other than the PD certs getting out of sync?  Is there a way to tell the PD runtime / config container not to update these certs so perhaps I could configure the new environment not to update them and hence reduce the risk here (since the configuration always get copied from the old to the new and then the handful of port numbers and such updated each time until our final cutover event).

    Thanks for any thoughts.



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