Installation

Attention

If you’ve deployed a local instance of the Wizard (Docker or build from source), we kindly request you to fill out this DS Wizard instance registration.

Public Instances

The application is currently deployed on a server provided by CESNET. Here are the addresses of running applications:

Tip

You are free to register and test out the Wizard within the ds-wizard.org. Then you can decide if you want a local instance for you or your organization. Eventually you can contact us about DSW Cloud service where we can host and maintain your DSW instance, see our Get Started page.

Registry

When you have your own self-hosted instance, it is essential for you to register within the DSW Registry. It is source of shared knowledge models and can support your deployment. After registration of your organization with unique ID and email verification, you will get your token. This token is then used in Settings. Then your instance is connected automatically to the Registry service for specific functionality such as accessing shared knowledge models and document templates.

Own Instance

Warning

For production use, consult deployment and other operations with your sysadmin or contact us for professional services.

The following instructions are recommended only for local deployment and trying it out. It does not include any safety measures that are required for production deployment and are handled differently based on specific requirements and deployment site.

With Docker

The simplest way is to use Docker Compose. Requirements are just to have Docker installed, privileges for current user and the Docker daemon started.

  1. Visit and clone https://github.com/ds-wizard/dsw-deployment-example

  2. Check config files (described in Configuration), especially application.yml and docker-compose.yml

  3. Run the DSW with Docker compose docker-compose up -d

  4. After starting up, you will be able to open the Wizard in your browser on http://localhost:8080

  5. You can use docker-compose logs to see the logs and docker-compose down to stop all the services

Without Docker

We highly recommend using Docker, but you are open to compile and run everything directly on your device. It is tested and distributed using Ubuntu 18.04. Additional expertise related to programming and building/running Elm, Haskell, Python, and others is required.

The related code and instructions are available:

Default Users

Initially, migrations will fill the database with predefined data needed including three users, all with password “password”:

You can use those accounts for testing or to initially made your own account admin and then delete them.

Danger

Having public instance with default accounts is a security risk. Delete or change default accounts (mainly Albert Einstein) if your DSW instance is public as soon as possible.

Initial Knowledge Model

When you have a fresh installation, there are just the default users and no knowledge models. You are free to create a new one from scratch if you want. Other option is to import existing KM dsw:root:X.Y.Z from the Registry. It is the core knowledge model for general data stewardship. The specific latest version (or other version that is the best for you) as well as other shared knowledge models can be found on the landing page of the Registry service. Other option is to import it from file if you have any (according to Usage).

Database Backup

If you want to regularly backup your database (and you should!), all you need to do is to set-up simple script as cronjob:

dsw-backup.sh
 1#!/bin/bash
 2# Location of Mongo's data folder (Dockerized Mongo)
 3MONGO_DATA_DIR=/dsw/mongo/data
 4# - or your Mongo without using Docker
 5# - MONGO_DATA_DIR=/data/db
 6# Target for storing backups
 7TARGET_DIR=/var/backups/dsw
 8# Backup
 9BACKUP_FILE=$TARGET_DIR/backup_$(date +%d%m%y-%H%M).tgz
10tar czf $BACKUP_FILE $MONGO_DATA_DIR

Make it executable (chmod a+x dsw-backup.sh) and add it as cronjob with crontab -e:

0 4 * * * /dsw/dsw-backup.sh

(This will do the backup every day at 4:00 AM. For more information, see crontab.guru.)

Danger

This is just a very simple example. For production use you need to consider some more advances backup techniques including storing backups encrypted on other servers (or even other geographic location).