You are using an unsupported browser. Please update your browser to the latest version on or before July 31, 2020.
close
You are viewing the article in preview mode. It is not live at the moment.
Home > LOGS SDMS > Installation > Installation of the SciY LOGS Core Engine
Installation of the SciY LOGS Core Engine
print icon

LOGS installation

This document covers the installation of LOGS 3.3 and later.

Requirements

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.

While other operating systems were not supported, it was possible to install older LOGS versions on other Linux distributions. With LOGS 3.3 the requirements are stricter, and LOGS will not run on all distributions that earlier LOGS versions did. The known problems on other Linux distributions are

  • Linux distributions older than Ubuntu 22.04 use a glibc library older than the minimum requirements of your parsing system. This is not a fixable problem, those Linux distributions are fundamentally incompatible with LOGS 3.3
  • The installation script only supports Ubuntu and AlmaLinux, it will not run on other distributions or old versions of the supported ones.

We strongly recommend to install LOGS on a separate server or VM, no other server software should be running on the same system. The installation script assumes that LOGS is the only server software running.

You need valid TLS certificates to run LOGS properly. You can get these from your IT department, or if your LOGS server is public and reachable from the internet you can use Let's Encrypt to generate those certificates.

Automatic Installation on Windows

Please download the current installer using the link provided in the order confirmation email. Once downloaded, place the license file in the same directory as the installer and execute the msi file. The installer will automatically install the LOGS-Core Engine as well as the PostreSQL server.

Automatic Installation on Ubuntu 24.04 LTS

The installation process can be started right away by fetching the latest script from our server and piping it into bash:

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

Make sure the server is connected to the internet. For security reasons, the installation script is encrypted, and you need a decryption passphrase to proceed. This passphrase has been sent to you via email. The input is hidden, so just type and press Enter to proceed. Afterwards, the installation process begins, and you are guided through it interactively. If the script does not find any local license file, you will be asked to enter the activation key as well as the decryption passphrase for your license. Both can be found in the email you should have received after purchase.

After the installation is completed, you start connecting your the first instruments as described here.

Administration commands

Linux: The core engine is installed by default under /opt/logs. License files are stored in the licenses subdirectory. The installed LOGS version can be verified using the command /opt/logs/LOGS version.

To manage the service, use systemctl start|stop|restart logs-core-engine. The current service status can be checked with systemctl status logs-core-engine.

For a complete list of available commands, run LOGS help.

Windows: On Windows systems, the LOGS Core Engine service can be started or stopped using the operating system’s Services application.

LOGS components/dependencies

The LOGS server itself is by default installed under /opt/logs. It consists of a single executable "LOGS" and a folder "system".

LOGS requires PostgreSQL 18+ as a database. The installation script automatically installs Postgres 18 and sets up the database and database user for LOGS.

The LOGS PDF export requires a headless browser installed on the system. The installation script automatically installs Chromium via the system package management.

The LOGS server is installed as a systemd service and can be started and stopped with systemctl.

License

LOGS requires a license to be installed. You should copy the license next to the installation script before starting it. Licenses for LOGS 3.3 have a different format than licenses for earlier LOGS versions. The license files have the format logs-license.[group].toml with [group] being the name of your LOGS group. If you have more than one group on your LOGS server, you will receive a license file for each group. Put them all in a "licenses" folder next to the installation script.

LOGS licenses are specific to each group. You must use exactly the same group names in your main config as in your license files. Any group defined in the LOGS main config that doesn't have a corresponding license file will not start at all. This is all handled automatically when using the installation script, the groups in the main config are set based on the license files you copied next to the installation script.

LOGS main config

The LOGS 3.3 main config file is "logs-config.toml" in the installation directory. This file is automatically created by the installation script when installing a new LOGS 3.3 or when upgrading from LOGS 3.2. This file configures on which Ports LOGS will listen, where the TLS certificates are found, how to connect to the PostgreSQL DB, in which directories the data is stored and which groups are defined for this LOGS instance. For a full description of all available options see the LOGS config reference.

Storage paths

By default LOGS sets the storage paths to subfolders under /opt/logs. The Files and Cache storage paths should be set to a volume or disk with sufficient space. You should do that before any data is uploaded into LOGS, and restart LOGS after changing the main config.

Troubleshooting

When LOGS detects a critical error on startup it will start into an admin-mode UI for troubleshooting. The UI will show a short description of the problem, for more details you need to look into the logs. There are two places where startup errors could be logged: the system journalctl log and the LOGS log files (at /opt/logs/log). To see the system logs run the command sudo journalctl -u logs-core-engine. The LOGS log files are text files in the log folder set in the main config.

IF you encounter any problems that trigger the admin-mode UI, always restart LOGS via sudo systemctl restart logs-core-engine after any changes to see if the problem is fixed.

The main problems that will prevent LOGS from fully starting and will trigger the admin-mode UI are the following:

No config file present

LOGS requires a config file. This is automatically created in the installation script. You can create a new config later by using the ./logs create-config CLI tool.

No database connection

On startup, LOGS connects to the database defined in the main config file in the [Database] section. Make sure Postgres is installed and running (e.g. with sudo systemctl status postgresql). Check the log files for the detailed error message. If the error is about the credentials, make sure the Postgres user and Password set inside the main LOGS config are correct, and that this user has all rights on the LOGS database (by default it is the logs DB, this can be set to a different value in the main config).

License file missing

Without a license file LOGS will not start. Provide a valid license file for LOGS 3.3 (in the format logs-license.[group].toml), not an old LOGS 3.2 license (logs.license) and put the license files into the "licenses" subfolder in the LOGS installation directory (/opt/logs/licenses).

No certificates

LOGS by default requires HTTPS. This is set in the AllowHttp setting in the [Server] section of the main config file. When this setting is false, LOGS will not start up without TLS certificates.

To provide the certificates set the CertificatePath and KeyPath settings in the [Server] section and point them to valid TLS certificates in PEM format.

If you set AllowHttp to true, LOGS will start up without certificates. But this is insecure and means the communication between users and LOGS is not encrypted. This setting should never be used in production environments.

Config validation errors

The exact error message will be shown in the admin UI and the log files. The message should point you towards the setting that has an invalid value.

Critical startup error

If you see this error, copy the full error message and provide it to LOGS support.

Feedback
0 out of 0 found this helpful

scroll to top icon