Upgrade Nexus OCSP Responder on Podman

This article includes updates for OCSP Responder 6.4.1.

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

Prerequisites

A previous version of Nexus OCSP responder deployed as Podman Quadlets.
Podman version 4.9.4 or later versions.
Access to the new version's distributable package including new container images.

Step-by-step instruction

Stop the OCSP container and create Backup

Stop all running containers
Use the following commands to stop the running containers:
CODE
```
systemctl --user stop ocsp
```
Backup Volumes: (optional)

Backup Volumes

If something goes wrong, the backup can be restored, and the system can return to its previous state.

Locate the volumes using:

BASH

podman volume list

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

BASH

> 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

Locate the Mountpoint on host:

CODE

podman volume inspect <volume-name>

Example:

BASH

> podman volume inspect systemd-ocsp-bin
[
     {
          "Name": "systemd-ocsp-bin",
          "Driver": "local",
          "Mountpoint": "/home/user/.local/share/containers/storage/volumes/systemd-ocsp-bin/_data",
          "CreatedAt": "2024-06-27T13:20:27.293170168Z",
          "Labels": {},
          "Scope": "local",
          "Options": {},
          "MountCount": 0,
          "NeedsCopyUp": true,
          "LockNumber": 14
     }
]

Back up the Mountpoint.

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.

BASH

podman image load --input ocsp-<version>/images/ocsp-<version>.tar

Ensure the new images are loaded correctly:

BASH

podman images

Update Quadlet configuration

Locate the ocsp.container used in the previous installation.
The following command can help to locate the path of the ocsp.container file.
CODE
```
 systemctl --user status ocsp
```
Update the image name
Modify the Image Name and Tag to the new target Image in the ocsp.container file.
Reload systemd daemon:
Make sure to reload systemd daemon to apply the changes.
BASH
```
systemctl --user daemon-reload
```

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.

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

CODE

systemctl --user start ocsp

Logs can be viewed using the following command:

CODE

podman logs -f ocsp

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.

CODE

systemctl --user start ocsp; podman logs -f ocsp

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.