Update

The CipherMail Appliance is installed and updated using RPM packages. To install updates, use the operating system’s standard update tool, dnf.

If you are using the Enterprise or Professional edition, dnf automatically downloads available updates from the official CipherMail repository. If you are using another edition, updates may need to be provided through a different repository or supplied by your administrator, depending on your deployment.

To ensure a smooth update, make sure the appliance has network access to the configured update repository before starting the update process.

Install updates from the command line using SSH, direct console access, or the Cockpit web interface’s built-in Terminal.

To install updates, run the following command:

sudo dnf update

After dnf installs an update, the CipherMail playbook runs automatically to verify that the system is in the correct state.

Most package updates do not require a reboot. However, some operating system updates, such as kernel updates, only take effect after the system is restarted. If a reboot is required, plan a maintenance window to minimize downtime and ensure the update is fully applied.

Note

Pro/Ent only dnf keeps the three most recently installed kernels and removes older ones when a newer kernel is installed. Every kept kernel takes space in /boot. To keep fewer or more kernels, set ciphermail_appliance__dnf_installonly_limit in override.yml (see below) and run the playbook. dnf requires a value of 0 (keep all) or at least 2.

A virtual appliance built before version 6.5.1 has a 1 GB /boot partition, which is sometimes too small for three kernels. A kernel update then fails with No space left on device while writing to /boot. Do not reboot before recovering: if the failure happened while the initramfs was being built, the new kernel is already the default boot entry but has no initramfs, and a reboot ends in the dracut emergency shell. To recover, set ciphermail_appliance__dnf_installonly_limit to 2 in override.yml, run the playbook and check how many kernels are installed:

sudo cm-run-playbook
rpm -q kernel-core

With two kernels, the update failed before the new kernel was unpacked and nothing is installed. Reboot into the newest installed kernel and run sudo dnf update again; it now fits.

With three kernels, the new kernel is installed without an initramfs. Remove the kernels above the new limit and rebuild the initramfs of every kernel:

sudo dnf remove --oldinstallonly
sudo dracut -f --regenerate-all

dnf never removes the running kernel. If the first command removes nothing, the appliance still runs its oldest kernel; compare uname -r with rpm -q kernel-core, remove the kernel which is neither running nor the newest with sudo dnf remove kernel-core-<version> and run the dracut command. Then reboot into the new kernel.

The reboot matters in both cases: while the appliance runs an older kernel, dnf keeps that kernel in addition to the two newest, and the next kernel update fails again. Keep the limit at 2 on such an appliance.

If a kernel update does not fit even with two kernels, the initramfs images themselves are large. ls -lh /boot shows their sizes. A gateway installed on an existing AlmaLinux or RHEL machine by a playbook before version 6.5.1 has the dracut-config-generic package, which builds an initramfs that boots on any hardware, together with the full linux-firmware package. Such an image is over 200 MB, and a plain installation also has a rescue image (initramfs-0-rescue-*.img) of that size, which a kernel update never replaces. Keep dracut-config-generic installed: an initramfs built without it only carries the drivers of the hardware it was built on, and the machine no longer boots after a move to another hypervisor or storage controller.

What does free a quarter of a 1 GB /boot is the rescue image. It is a fallback for a kernel that does not boot, and the virtual appliance image is built without one. On a virtual machine with snapshots or backups it can be removed, together with the package that would create it again and its boot entry:

sudo dnf remove dracut-config-rescue
sudo rm /boot/initramfs-0-rescue-*.img /boot/vmlinuz-0-rescue-* /boot/loader/entries/*-0-rescue.conf

If that is not acceptable, the remaining options are a larger /boot partition, which usually means reinstalling, or keeping the limit at 2 and removing the older kernel by hand before every kernel update.

Hint

CipherMail configures an alias for the dnf command to ensure the playbook runs automatically whenever you install or update a package. If you do not want the playbook to run automatically, use \dnf to execute the original, unaliased dnf command.

Note

Pro/Ent only The DNF configuration file at /etc/dnf/dnf.conf is managed by Ansible. Do not edit this file directly, because your changes will be overwritten the next time the Ansible playbook runs. If you need to add or change DNF settings, place them in the ciphermail_appliance__dnf_additional_config Ansible variable instead. This ensures your custom configuration is preserved and applied correctly during future updates:

sudo vi /etc/ciphermail/ansible/group_vars/all/override.yml

Example which configures dnf proxy support and timeouts:

ciphermail_appliance__dnf_additional_config: |
    proxy=http://1.2.3.4:8080
    proxy_username=some_user
    proxy_password=some_password
    timeout=180

After changing override.yml, run the playbook:

sudo cm-run-playbook

For a complete list of available DNF configuration options, see the man page:

man dnf.conf