Requirements for a LOGS server
Hardware requirements for a server or VM:
HDD size depends on the projected need for storage space.
We recommend using a RAID1 and daily backups.
Software requirements for a server or VM:
Supported operating systems:
Ubuntu 22.04 LTS, 64 bit
Ubuntu 20.04 LTS, 64 bit
CentOS 7.x, 64 bit
Additional software requirements (will be installed automatically by the installer script):
Docker-CE 18.06 or higher
Docker-Compose 1.26 or higher
- Set up server hardware
- Install supported operating system
- Ensure that a user with root access is available
- Make sure the server has internet access
- Copy the LOGS installation script and the LOGS license to the server
- Organize SSL certificates for the server from the local IT department in order to use HTTPS encryption (Let’s Encrypt can be used if the server is accessible from the internet)
- Ensure all instrument PCs that are meant to be connected to LOGS have an SSH server running
- Ensure that the LOGS server can connect to the computers instrument PCs via SSH
- Collect access information for all instrument PCs:
- IP addresses
- user names
- data directories
- Ensure that the server can be reached from the user PCs via HTTP(S)
- We recommend using a local backup solution in addition to hardware measures such as RAID1
LOGS can either be installed manually or by installation script
Installation by script
Copy the installation script (install.sh) and a valid license file (logs.license) to the LOGS server. Default directory is /opt/, the program directory /opt/logs/ will be created automatically. All data will be stored in subfolders of this directory, partition sizes should be planned accordingly.
Start the installation with sudo ./install.sh install current in order to install the most recent version or with sudo ./install.sh install < version > in order to install a specific version of LOGS.
The installation script will automatically check if all dependencies are met and ask for approval before installing additional packages.
The installation script will offer to use Let’s Encrypt in order to automatically obtain SSL certificates for HTTPS encryption, but the LOGS server has to be accessible from the internet to do so. Certificates might also be obtained from a local IT department and manually added to the ./certs/ subdirectory.
The installation script will ask for instance names to use which will be part of the URL of the LOGS GUI (http(s)://subdomain.domain.com/instance) and for the LOGS edition (academia, facility or enterprise) to use. Number and type of instances has to correspond to the ones specified in the license file.
After the installation is complete, the installer script will create an administrative user for each instance and ask to provide user names and passwords.
Copy the LOGS executable to the target directory, usually /opt/logs/.
Copy a configuration file (config-v1.yaml) and a valid license file to the ./config/ subdirectory e.g. /opt/logs/config/.
Create a symlink to the logs executable, e.g. sudo ln -s /opt/logs/logs-1.2.3 /opt/logs/logs so you can start, stop or restart LOGS with version-independent commands.
Start LOGS using the symlink with /opt/logs/logs up.
Updates by script
The installation script can be used to apply updates:
Start the update with sudo ./install.sh update current in order to update to the most recent version or with sudo ./install.sh update < version > in order to update to a specific version of LOGS.
A backup of the DB will be performed automatically before applying the update.
Copy the new LOGS executable to the target directory, usually /opt/logs/.
We recommend doing a manual backup of the database with /opt/logs/logs db-backup /usr/bin/date -Iminutes`.
Stop LOGS with sudo ./logs down
Adjust the symlink to point to the new LOGS executable.
Start the new LOGS with sudo ./logs up
We recommend making daily backups of LOGS.
Database dumps can be created scheduling a cron job like /opt/logs/logs db-backup myserver_$(/usr/bin/date -Iminutes).
Directories to include in the backup are ./backup/ (containing the database dumps), ./files/ (containing the primary data) and ./config/ (containing the LOGS configuration).
A file backup of the running database is not sufficient.
A RAID system is no replacement for a backup.
Stop LOGS with sudo ./logs down
Make sure no docker containers are running: sudo docker ps.
Make absolutely sure you don’t want to keep any of the data in the LOGS directory, e.g. the database in ./db and the primary data files in ./files.
Remove the LOGS directory.
If docker isn’t used for other applications, remove unused docker containers, images and networks with “sudo docker system prune -a”.
LOGS needs SSL certificates in order to serve the web interface via HTTPS instead of unencrypted HTTP.
These certificates can either be provided by the local IT department or obtained automatically (and for free) from the Let’s Encrypt certificate authority.
Support for Let’s Encrypt is built into LOGS and can either be activated during setup with the installer script or later by editing the main configuration file.
In order for the Let’s Encrypt mechanism of authentication to work, the LOGS server has to be accessible from the internet - a restriction by whitelist is not possible.
Certificates will be issued for 3 months and automatically updated before they expire.
Certificates obtained manually from the local IT department have to be stored in the ./certs subdirectory of LOGS in form of the the files fullchain.pem and privkey.pem and will be used automatically if HTTPS is activated in the main configuration file.
fullchain.pem contains the X.509 certificate for the LOGS server in the .pem format, followed by all other certificates in the chain.
privkey.pem contains the private key for the certificate in the .pem format.