Updating Qisutu

Always extract a new release into a separate directory. Do not copy it over the existing installation or extract it directly there. The new update.sh then updates exactly the instance supplied as its argument.

Preparation and backup

Before every update, create and verify a complete backup. It must include at least:

  • The complete instance directory, especially core/config/QisutuConfig.pm

  • var/secure/security.key

  • The database

  • Custom Apache, proxy, TLS, and systemd changes

  • External attachments or connected storage locations, where applicable

security.key is essential for recovering encrypted email, OAuth, and two-factor secrets. Store it securely with the matching instance backup.

Downloading the release

cd /tmp
wget https://ftp.qisutu.de/qisutu-1.0.2.tar.gz
tar xzf qisutu-1.0.2.tar.gz
cd qisutu-1.0.2

When updating to a later version, use the URL and directory name for that target version.

Starting the update

Production instance:

sudo ./update.sh /opt/qisutu

Additional instance:

sudo ./update.sh /opt/qisututest

The updater reads var/install/instance.conf and displays the installation path, instance identifier, web path, database, and systemd service before asking for confirmation. Cancel if any of these values does not belong to the intended instance.

Update process

The script performs the following steps, among others:

  1. Verifies release checksums, versions, the schema file, Perl syntax, and program registration.

  2. Optionally creates an additional database dump. Check the available space under /var/backups first.

  3. Enables maintenance mode, stops the instance-specific daemon, and blocks new email retrieval.

  4. Updates all application files managed by the release; adds new files and removes managed files that are no longer published.

  5. Preserves local instance files, configurations, logs, runtime data, and the security key.

  6. Reconciles the database schema and runs all SQL and Perl migrations that have not yet been recorded.

  7. Verifies the target state again and starts the daemon.

Post-update checks

After successful completion, run:

systemctl status qisutu-daemon.service
journalctl -u qisutu-daemon.service --since today

Then sign in, check the displayed Qisutu and database versions, and test at least sign-in, the ticket view, email retrieval, and email delivery. If there are multiple instances, perform these checks separately for every updated instance.

Failed update

Do not restart the script repeatedly without first identifying the cause. Save the output and logs, then check free storage, database access, file permissions, and service status. If the state is unclear, restore the previously verified complete backup of the application directory and database together.