Document toolboxDocument toolbox

OCSP upgrade using Quadlets

This article is new for OCSP Responder 6.3.0-1.

This article describes how to upgrade Nexus OCSP Responder server using quadlets.

Prerequisites

  • Quadlet installation of OCSP installed with version 6.2.x-1.

  • Podman version 4.9.4 or higher.

  • Access to the new version's distributable package including new container images.

Step-by-step instruction

Stop the OCSP container and create Backup

  1. Stop all running containers
    Use the following commands to stop the running containers:

    systemctl --user stop ocsp
  2. Backup Volumes: (optional but highly recommended)
    If something goes wrong, the backup can be restored, and the system can return to its previous state.

    1. Locate the volumes using:

      podman volume list

      Example (name can change but should contain (ocsp):

      > podman volume list local systemd-ocsp-crls local systemd-ocsp-config local systemd-ocsp-certs local systemd-ocsp-health local systemd-ocsp-bin local systemd-ocsp-cils local systemd-ocsp-utimaco local systemd-ocsp-lib
    2. Locate the Mountpoint on host:

      Example:

    3. Back up the Mountpoint.

  3. Backup the unit files.
    Locate the .container, .volumes and .network files used for the quadlet installation of OCSP and make a backup.

Import the new Image.

Use podman image load to load the new image.

Ensure the new images are loaded correctly:

Update Quadlet configuration

  1. Locate the ocsp.container used in the previous installation.
    The following command can help to locate the path of the ocsp.container file.

  2. Update the image name
    Modify the Image Name and Tag to the new target Image in the ocsp.container file.

  3. Reload systemd daemon:
    Make sure to reload systemd daemon to apply the changes.

Create New volumes

New versions of nexus OCSP responder might see new default volumes added to the OCSP container which need to be added as part of the upgrade.

  1. Locate Default OCSP volumes.
    Default OCSP volumes are listed in the new ocsp.container file distributed with the new release zip.
    Compare the ocsp.container file between the current installation and the new one to identify new default volumes.

  2. Add the new default volumes.
    Once these volumes are identified, add the corresponding volumes.
    For more information how to add these volumes: OCSP Quadlet Deployment

  3. Create new directory in systemd-ocsp-certs volume for fallback-truststore to use fallback funcitonality.
    mkdir /home/azureuser/.local/share/containers/storage/volumes/systemd-ocsp-certs/_data/fallback-truststore

    To continue fallback configuration follow the release notes.

Update configuration files

Make sure while doing file changes that the owner of the file does not change!

Configuration Changes between specific version can be found here:

OCSP Responder release notes

Restart the Containers

Once everything has been done, the containers can be restarted.

Logs can be viewed using the following command:

If logs cannot be seen it is most likely because of a startup error, to still see the logs chain the 2 pervious commands together.

Rollback procedure

If any issue occurs during the upgrade, it is possible to roll back.

Simply restore the volume state and the .container, .volume and .network files from the backup made previously.

Copyright 2024 Technology Nexus Secured Business Solutions AB. All rights reserved.
Contact Nexus | https://www.nexusgroup.com | Disclaimer | Terms & Conditions