Perfom updates from 3.2 to 3.3

LOGS is officially supported on Ubuntu 22.04 and 24.04 as well as AlmaLinux 9.2+ as well as Windows 10+ and Windows Server 2022+. Only 64-bit operating systems are supported. Please update your OS if needed before updating LOGS.

 

You need a new LOGS license file, you will receive this from SciY support. The filename should look like logs-license.yourgroupname.toml. If you have multiple groups, you'll receive a licenses folder with one license per group. Copy those licenses next to the install script before continuing.

 

The LOGS installation script (see Installation of the SciY LOGS Core Engine - LOGS) can also perform the upgrade from LOGS 3.2 to LOGS 3.3.

 

If your LOGS is installed in /opt/logs, the script should work without further input. If you have it installed somewhere else, you must provide the proper parameters to the install script.

You should shut down the old LOGS 3.2 and perform the DB dump. Shutting down LOGS before is important so that nobody can add or modify data in the old LOGS while the backup is running as those changes would not be imported to the new LOGS 3.3. Use the ./logs down and ./logs db-backup commmands using the old LOGS 3.2 executable to do this.

Run the following command and follow the instructions to get the install script:

 

sudo curl -Ls https://install.logs-sciy.com | bash

 

Run the install script with the following parameters:

sudo bash ./install_logs_ubuntu24_alma.sh current --import-logs-from /opt/logs/ --import-backup /opt/logs/backup/my-backup-db.dump --install-dir /opt/logs

You can run sudo bash ./install_logs_ubuntu24_alma.sh --help to see all available parameters. The import and install dir default to /opt/logs, so you can omit them if your LOGS is installed there.

 

Perform updates via script (to the most recent 3.3 version)

For maximum convenience, we provide a collection of scripts to automate recurring tasks. These tasks include updating LOGS.
If you haven’t installed this script collection yet (by default it is located under /opt/logs/scripts/), please refer to this article.

Please note that the legacy installation script (* /opt/installer.sh *) only supports LOGS versions below 3.1 and can therefore be removed.

 

To update LOGS to the most recent stable version execute:

 

 

To update LOGS to a specific version execute:

 

 

Tip: Create a symbolic link to the update script inside /opt/logs for easier access using:

 

 

During the update process a backup of the database will be performed automatically. Depending on the amount of meta data this may take some time to finish before the download and installation of the new LOGS binary is performed. If your network / firewall does not allow to access our download server, copy the new LOGS binary manually in /opt/logs before running the update script. It will automatically recognize the local file and will skip attempting to download it.

 

Updates of LOGS 3.2 and older

 

IMPORTANT NOTES:

1) Never skip major versions. Make sure you always update first to the latest release of each major version.

2) Some major version updates will trigger internal DB or file migrations. Make sure that those migrations are finished before updating to the next version. The easiest way is to check if you can log in into LOGS and if the dashboard is loading as usual. If not please wait some time and re-check. Depending on the number of datasets and samples, it might take between 5 minutes to overnight to finish. More advanced users can have a look at the internal log using "sudo ./logs logs" and look for the term "Migration". To exit the log view press Ctrl+c. 

3) There is a breaking change introduced in 3.1.100+. (Upgrade of the PostgreSQL database version) which requires the execution of a migration script in order to update from 3.1.x (x<=100) to 3.1.y (y >= 100). The migration script is part of the bash tools collection whose installation is described in this article. 

 

 

4) Starting with LOGS 3.3, the applicatiion is longer shipped as a docker container, but as a native binary. Also, the PostgreSQL database is installed seperatly as independent application and/or can be managed externally. Please note, that the binary is names "LOGS" (capital letters, without version number) starting with 3.3, while it was "logs-VERSION" in older installations <=3.2). To find out the version via the command line run "sudo ./LOGS version" from inside the installation directory.

 

5) LOGS 3.3 uses a different license file format than teh previous versions, rendering any older license invalid. Please contact [email protected] to get a new license file and place it in /opt/logs/ before starting the update process.

 

6) Stick to the following updating path. If you are unsure please contact our support team before you start. Pay attention to all points described in this section, especially to wait until all migrations are finished. This can be checked by logging into the application via the browser. If the login page is not spinning up or if you get a maintenance notification than migrations are still ongoing. Do not continue with updating until LOGS operates normally.

 

• If you are updating from 2.7.x:  updateRelease_legacy.sh 2.7.145 -> updateRelease_legacy.sh 3.0.89 -> updateRelease_legacy.sh 3.1.52 -> run migration script -> updateRelease_legacy.sh 3.1.219 -> updateRelease_legacy.sh current -> scripts/installation/ubuntu24_alma.sh current
• If you are updating from 3.0.x: updateRelease_legacy.sh 3.0.89 ->updateRelease_legacy.sh 3.1.52 -> run migration script -> updateRelease_legacy.sh 3.1.219 -> updateRelease_legacy.sh current ->scripts/installation/ubuntu24_alma.sh current
• If you are updating from 3.1.x (x<100): updateRelease_legacy.sh 3.1.52 -> run migration script -> updateRelease.sh 3.1.219 -> updateRelease.sh current -> scripts/installation/ubuntu24_alma.sh current
• If you are updating from 3.1.y (y >=100): updateRelease_legacy.sh 3.1.219 -> updateRelease_legacy.sh current -> scripts/installation/ubuntu24_alma.sh current
• if you are updating from 3.2.x: updateRelease_legacy.sh current -> scripts/installation/ubuntu24_alma.sh current

 

If you cannot find the ubuntuRelase_legacy.sh script inside scripts/updates folder, make sure that you have the latest bash tool scripts collection installed (cd scripts && sudo bash updateScriptsViaGithub.sh).