Skip to content

Upgrading on Podman

On Podman, an upgrade replaces the pod files, which name the release's images, and restarts JIM. Do the steps in Before you upgrade first. The commands are for the default, rootful installation, run as root; for a rootless one, see Rootless commands.

An upgrade on Podman, and the way back With the old release running, steps 1 and 2 stop JIM, leaving the bundled database running, take the backup, and keep the current pod files as jim.yaml.previous and jim-database.yaml.previous. While JIM is stopped, the backup and the .previous files hold the old release. Steps 3 and 4 put the new release's files and images in place and start JIM, restarting the database first, so the new release runs. To roll back, stop JIM again, restore the backup, put the .previous files back, and start JIM on the old release. steps 1 and 2 stop, back up restore, start steps 3 and 4 new files, start roll back: stop Old release JIM stoppedbackup, .previous files New release An upgrade on Podman, and the way back With the old release running, steps 1 and 2 stop JIM, leaving the bundled database running, take the backup, and keep the current pod files as jim.yaml.previous and jim-database.yaml.previous. While JIM is stopped, the backup and the .previous files hold the old release. Steps 3 and 4 put the new release's files and images in place and start JIM, restarting the database first, so the new release runs. To roll back, stop JIM again, restore the backup, put the .previous files back, and start JIM on the old release. steps 1 and 2 stop, back up restore, start steps 3 and 4 new files, start roll back: stop Old release JIM stoppedbackup, .previous files New release

Upgrade JIM

  1. Stop JIM, leaving the bundled database running, and take your backup per Backup & Disaster Recovery:

    systemctl stop jim.service

  2. Keep the current pod files, for rolling back:

    cd /opt/jim
cp jim.yaml jim.yaml.previous && cp jim-database.yaml jim-database.yaml.previous

  3. Put the new release's files in place, and its images. Connected, download the pod files from the release and pull the images they name:

    cd /opt/jim
for f in jim.yaml jim-database.yaml setup.sh; do
  curl -fsSLO "https://github.com/TetronIO/JIM/releases/download/v0.14.0/$f"
done
chmod 755 setup.sh
for image in $(awk '$1 == "image:" { print $2 }' jim.yaml jim-database.yaml); do podman pull "$image"; done

    Air-gapped, from the extracted bundle, load the images and copy the files:

    for f in docker-images/*.tar; do podman load < "$f"; done
cp podman/jim.yaml podman/jim-database.yaml setup.sh /opt/jim/

    If you tuned PostgreSQL in jim-database.yaml, carry your settings into the new copy rather than losing them. Compare the release's jim-config.yaml with yours for new settings.

    Upgrading from v0.16.0 or earlier with the bundled PostgreSQL: its memory settings now come from jim-config.yaml, and without them it uses defaults for a 4 GB host, where the earlier pod file asked for 8 GB of shared_buffers. On a larger host, add them to jim-config.yaml, sized as the installer would (see Bundled PostgreSQL Memory).

    Upgrading a rootful JIM from v0.16.0 or earlier, make the host changes Firewall, SELinux, AppArmor and NetworkManager shows:

    • firewalld: enable netavark-firewalld-reload.service, or a firewalld reload leaves JIM unable to reach its database until you restart JIM.
    • RHEL or a derivative: tell NetworkManager to leave Podman's interfaces alone, or a restart or reboot can leave JIM's database unplugged from its network, with JIM's services logging No route to host.
    • Ubuntu 24.04: add the AppArmor signal rule, without which JIM's services crash and restart, and in step 4 restart the server instead of the two services. Podman loads the rule only when the server starts.

  4. Start JIM, restarting the database first so it runs the release's PostgreSQL image:

    systemctl restart jim-database.service
systemctl start jim.service

Check it worked

Check it as Check it worked on Upgrading describes, with systemctl status jim-database.service jim.service in place of docker compose ps, and re-enable the Schedules you disabled.

Rolling back

Stop JIM, restore the pre-upgrade backup as Rolling back describes (it explains why both halves go back together), put jim.yaml.previous and jim-database.yaml.previous back in place of the new files, and start JIM again.