Provisioning DranSCADA

In previous versions of DranSCADA, you could only use the API for provisioning data sources and dashboards. But that required the service to be running before you started creating dashboards and you also needed to set up credentials for the HTTP API. In v5.0 we decided to improve this experience by adding a new active provisioning system that uses config files. This will make GitOps more natural as data sources and dashboards can be defined via files that can be version controlled. We hope to extend this system to later add support for users, orgs and alerts as well.

Check out the configuration page for more information on what you can configure in dranscada.ini

• Default configuration from $WORKING_DIR/conf/defaults.ini
• Custom configuration from $WORKING_DIR/conf/custom.ini
• The custom configuration file path can be overridden using the --config parameter

Note: If you have installed DranSCADA using the deb or rpm packages, then your configuration file is located at /etc/dranscada/dranscada.ini. This path is specified in the DranSCADA init.d script using --config file parameter.

It is possible to use environment variable interpolation in all 3 provisioning config types. Allowed syntax is either $ENV_VAR_NAME or ${ENV_VAR_NAME} and can be used only for values not for keys or bigger parts of the configs. It is not available in the dashboard’s definition files just the dashboard provisioning configuration. Example:

datasources:
  - name: MySQL
    url: http://localhost:$PORT
    user: $USER
    secureJsonData:
      password: $PASSWORD

If you have a literal $ in your value and want to avoid interpolation, $$ can be used.

This feature is available from v5.0

It’s possible to manage data sources in DranSCADA by adding one or more YAML config files in the provisioning/datasources directory. Each config file can contain a list of datasources that will get added or updated during start up. If the data source already exists, then DranSCADA updates it to match the configuration file. The config file can also contain a list of data sources that should be deleted. That list is called deleteDatasources. DranSCADA will delete data sources listed in deleteDatasources before inserting/updating those in the datasource list.

If you are running multiple instances of DranSCADA you might run into problems if they have different versions of the datasource.yaml configuration file. The best way to solve this problem is to add a version number to each datasource in the configuration and increase it when you update the config. DranSCADA will only update datasources with the same or lower version number than specified in the config. That way, old configs cannot overwrite newer configs if they restart at the same time.

# config file version
apiVersion: 1

# list of datasources that should be deleted from the database
deleteDatasources:
  - name: MySQL
    orgId: 1

# list of datasources to insert/update depending
# what's available in the database
datasources:
  # <string, required> name of the datasource. Required
  - name: MySQL
    # <string, required> datasource type. Required
    type: mysql
    # <string, required> access mode. proxy or direct (Server or Browser in the UI). Required
    access: proxy
    # <int> org id. will default to orgId 1 if not specified
    orgId: 1
    # <string> custom UID which can be used to reference this datasource in other parts of the configuration, if not specified will be generated automatically
    uid: my_unique_uid
    # <string> url
    url: http://localhost:3306
    # <string> Deprecated, use secureJsonData.password
    password:
    # <string> database user, if used
    user:
    # <string> database name, if used
    database:
    # <bool> enable/disable basic auth
    basicAuth:
    # <string> basic auth username
    basicAuthUser:
    # <string> Deprecated, use secureJsonData.basicAuthPassword
    basicAuthPassword:
    # <bool> enable/disable with credentials headers
    withCredentials:
    # <bool> mark as default datasource. Max one per org
    isDefault:
    # <map> fields that will be converted to json and stored in jsonData
    jsonData:
      tlsAuth: true
      tlsAuthWithCACert: true
    # <string> json object of data that will be encrypted.
    secureJsonData:
      tlsCACert: '...'
      tlsClientCert: '...'
      tlsClientKey: '...'
      # <string> database password, if used
      password:
      # <string> basic auth password
      basicAuthPassword:
    version: 1
    # <bool> allow users to edit datasources from the UI.
    editable: false

Please refer to each datasource documentation for specific provisioning examples.

Since not all datasources have the same configuration settings we only have the most common ones as fields. The rest should be stored as a json blob in the jsonData field. Here are the most common settings that the core datasources use.

{"authType":"keys","defaultRegion":"us-west-2","timeField":"@timestamp"}

Secure json data is a map of settings that will be encrypted with secret key from the DranSCADA config. The purpose of this is only to hide content from the users of the application. This should be used for storing TLS Cert and password that DranSCADA will append to the request on the server side. All of these settings are optional.

Data sources managed by DranSCADAs provisioning can be configured to add HTTP headers to all requests going to that datasource. The header name is configured in the jsonData field and the header value should be configured in secureJsonData.

apiVersion: 1

datasources:
  - name: MySQL
    jsonData:
      httpHeaderName1: 'HeaderName'
      httpHeaderName2: 'Authorization'
    secureJsonData:
      httpHeaderValue1: 'HeaderValue'
      httpHeaderValue2: 'Bearer XXXXXXXXX'

You can manage dashboards in DranSCADA by adding one or more YAML config files in the provisioning/dashboards directory. Each config file can contain a list of dashboards providers that load dashboards into DranSCADA from the local filesystem.

The dashboard provider config file looks somewhat like this:

apiVersion: 1

providers:
  # <string> an unique provider name. Required
  - name: 'a unique provider name'
    # <int> Org id. Default to 1
    orgId: 1
    # <string> name of the dashboard folder.
    folder: ''
    # <string> folder UID. will be automatically generated if not specified
    folderUid: ''
    # <string> provider type. Default to 'file'
    type: file
    # <bool> disable dashboard deletion
    disableDeletion: false
    # <int> how often DranSCADA will scan for changed dashboards
    updateIntervalSeconds: 10
    # <bool> allow updating provisioned dashboards from the UI
    allowUiUpdates: false
    options:
      # <string, required> path to dashboard files on disk. Required when using the 'file' type
      path: /var/lib/dranscada/dashboards
      # <bool> use folder names from filesystem to create folders in DranSCADA
      foldersFromFilesStructure: true

When DranSCADA starts, it will update/insert all dashboards available in the configured path. Then later on poll that path every updateIntervalSeconds and look for updated json files and update/insert those into the database.

Note: Dashboards are provisioned to the General folder if the folder option is missing or empty.

It’s possible to make changes to a provisioned dashboard in the DranSCADA UI. However, it is not possible to automatically save the changes back to the provisioning source. If allowUiUpdates is set to true and you make changes to a provisioned dashboard, you can Save the dashboard then changes will be persisted to the DranSCADA database.

Note: If a provisioned dashboard is saved from the UI and then later updated from the source, the dashboard stored in the database will always be overwritten. The version property in the JSON file will not affect this, even if it is lower than the existing dashboard.

If a provisioned dashboard is saved from the UI and the source is removed, the dashboard stored in the database will be deleted unless the configuration option disableDeletion is set to true.

If allowUiUpdates is configured to false, you are not able to make changes to a provisioned dashboard. When you click Save, DranSCADA brings up a Cannot save provisioned dashboard dialog. The screenshot below illustrates this behavior.

DranSCADA offers options to export the JSON definition of a dashboard. Either Copy JSON to Clipboard or Save JSON to file can help you synchronize your dashboard changes back to the provisioning source.

Note: The JSON definition in the input field when using Copy JSON to Clipboard or Save JSON to file will have the id field automatically removed to aid the provisioning workflow.

If the dashboard in the json file contains an uid, DranSCADA will force insert/update on that uid. This allows you to migrate dashboards between DranSCADA instances and provisioning DranSCADA from configuration without breaking the URLs given since the new dashboard URL uses the uid as identifier. When DranSCADA starts, it will update/insert all dashboards available in the configured folders. If you modify the file, the dashboard will also be updated. By default, DranSCADA will delete dashboards in the database if the file is removed. You can disable this behavior using the disableDeletion setting.

Note: Provisioning allows you to overwrite existing dashboards which leads to problems if you re-use settings that are supposed to be unique. Be careful not to re-use the same title multiple times within a folder or uid within the same installation as this will cause weird behaviors.

If you already store your dashboards using folders in a git repo or on a filesystem, and also you want to have the same folder names in the DranSCADA menu, you can use foldersFromFilesStructure option.

For example, to replicate these dashboards structure from the filesystem to DranSCADA,

/etc/dashboards
├── /server
│   ├── /common_dashboard.json
│   └── /network_dashboard.json
└── /application
    ├── /requests_dashboard.json
    └── /resources_dashboard.json

you need to specify just this short provision configuration file.

apiVersion: 1

providers:
- name: dashboards
  type: file
  updateIntervalSeconds: 30
  options:
    path: /etc/dashboards
    foldersFromFilesStructure: true

server and application will become new folders in DranSCADA menu.

Note: folder and folderUid options should be empty or missing to make foldersFromFilesStructure work.

Note: To provision dashboards to the General folder, store them in the root of your path.

Alert Notification Channels can be provisioned by adding one or more YAML config files in the provisioning/notifiers directory.

Each config file can contain the following top-level fields:

• notifiers, a list of alert notifications that will be added or updated during start up. If the notification channel already exists, DranSCADA will update it to match the configuration file.
• delete_notifiers, a list of alert notifications to be deleted before inserting/updating those in the notifiers list.

Provisioning looks up alert notifications by uid, and will update any existing notification with the provided uid.

By default, exporting a dashboard as JSON will use a sequential identifier to refer to alert notifications. The field uid can be optionally specified to specify a string identifier for the alert name.

{
  ...
      "alert": {
        ...,
        "conditions": [...],
        "frequency": "24h",
        "noDataState": "ok",
        "notifications": [
           {"uid": "notifier1"},
           {"uid": "notifier2"},
        ]
      }
  ...
}

notifiers:
  - name: notification-channel-1
    type: slack
    uid: notifier1
    # either
    org_id: 2
    # or
    org_name: Main Org.
    is_default: true
    send_reminder: true
    frequency: 1h
    disable_resolve_message: false
    # See `Supported Settings` section for settings supported for each
    # alert notification type.
    settings:
      recipient: 'XXX'
      uploadImage: true
      token: 'xoxb' # legacy setting since DranSCADA v7.2 (stored non-encrypted)
      url: https://slack.com # legacy setting since DranSCADA v7.2 (stored non-encrypted)
    # Secure settings that will be encrypted in the database (supported since DranSCADA v7.2). See `Supported Settings` section for secure settings supported for each notifier.
    secure_settings:
      token: 'xoxb'
      url: https://slack.com

delete_notifiers:
  - name: notification-channel-1
    uid: notifier1
    # either
    org_id: 2
    # or
    org_name: Main Org.
  - name: notification-channel-2
    # default org_id: 1

The following sections detail the supported settings and secure settings for each alert notification type. Secure settings are stored encrypted in the database and you add them to secure_settings in the YAML file instead of settings.

Note: Secure settings is supported since DranSCADA v7.2.