Settings Service Configuration

Introduction

The Infinite Scale Settings service provides functionality for other services to register new settings as well as storing and retrieving the respective settings' values.

Default Values

  • Settings listens on port 9190 by default.

Settings Managed

The settings service is currently used for managing the:

  • users' profile settings like the language and the email notification settings,

  • possible user roles and their respective permissions,

  • assignment of roles to users.

As an example, user profile settings that can be changed in the Web UI must be persistent.

The settings service supports two different backends for persisting the data. The backend can be set via the SETTINGS_STORE_TYPE environment variable. Supported values are:

  • metadata: The default. This backend persists the settings data via the storage-system service.

  • filesystem: This backend persists the settings data in a directory on the local filesystem. The directory can be configured with SETTINGS_DATA_PATH. This backend is not suitable for running multiple intances of the settings service in a scale-out deployment and should be therefore considered deprecated.

Settings Management

Infinite Scale services can register settings bundles with the settings service.

Settings Usage

Services can set or query Infinite Scale setting values of a user from settings bundles.

Service Accounts

The settings service needs to know the IDs of service accounts but it doesn’t need their secrets. Currently only one service account can be configured which has the admin role. This can be set with the SETTINGS_SERVICE_ACCOUNT_ID_ADMIN envvar, but it will also pick up the global OCIS_SERVICE_ACCOUNT_ID envvar. Also see the auth-service service description for additional details.

Translations

The settings service has embedded translations sourced via transifex to provide a basic set of translated languages. These embedded translations are available for all deployment scenarios. In addition, the service supports custom translations, though it is currently not possible to just add custom translations to embedded ones. If custom translations are configured, the embedded ones are not used. To configure custom translations, the SETTINGS_TRANSLATION_PATH environment variable needs to point to a base folder that will contain the translation files. This path must be available from all instances of the userlog service, a shared storage is recommended. Translation files must be of type .po or .mo. For each language, the filename needs to be settings.po (or settings.mo) and stored in a folder structure defining the language code. In general the path/name pattern for a translation file needs to be:

{SETTINGS_TRANSLATION_PATH}/{language-code}/LC_MESSAGES/settings.po

The language code pattern is composed of language[_territory] where language is the base language and _territory is optional and defines a country.

For example, for the language de, one needs to place the corresponding translation files to

{SETTINGS_TRANSLATION_PATH}/de/LC_MESSAGES/settings.po


For the time being, the embedded ownCloud Web frontend only supports the main language code but does not handle any territory. When strings are available in the language code language_territory, the web frontend does not see it as it only requests language. In consequence, any translations made must exist in the requested language to avoid a fallback to the default.

Translation Rules

  • If a requested language code is not available, the service tries to fall back to the base language if available. For example, if the requested language-code de_DE is not available, the service tries to fall back to translations in the de folder.

  • If the base language de is also not available, the service falls back to the system’s default English (en), which is the source of the texts provided by the code.

Default Language

The default language can be defined via the OCIS_DEFAULT_LANGUAGE environment variable. See the settings service for a detailed description.

Default Language

The default language can be defined via the OCIS_DEFAULT_LANGUAGE environment variable. If this variable is not defined, English will be used as default. The value has the ISO 639-1 format ("de", "en", etc.) and is limited to the list of supported languages. This setting can be used to set the default language for notification and invitation emails.

The OCIS_DEFAULT_LANGUAGE setting impacts the notification and userlog services and the WebUI. Note that translations must exist for all named components to be presented correctly.

  • If OCIS_DEFAULT_LANGUAGE is not set, the expected behavior is:

    • The notification and userlog services and the Web UI use English by default, until a user sets another language in the Web UI via Account  Language.

    • If a user sets another language in the Web UI in Account  Language, then the notification and userlog services and Web UI use the language defined by the user. If no translation is found, it falls back to English.

  • If OCIS_DEFAULT_LANGUAGE is set, the expected behavior is:

    • The notification and userlog services and the Web UI use OCIS_DEFAULT_LANGUAGE by default, until a user sets another language in the Web UI via Account  Language.

    • If a user sets another language in the Web UI in Account  Language, the notification and userlog services and Web UI use the language defined by the user. If no translation is found, it falls back to OCIS_DEFAULT_LANGUAGE and then to English.

Custom Roles

It is possible to replace the default Infinite Scale roles (admin, user) with custom roles that contain custom permissions. One can set SETTINGS_BUNDLES_PATH to the path of a json file containing the new role definition.

Role Example (shortned):
[
    {
        "id": "38071a68-456a-4553-846a-fa67bf5596cc", // ID of the role. Recommendation is to use a random uuidv4. But any unique string will do.
        "name": "user-light",                         // Internal name of the role. This is used by the system to identify the role. Any string will do here, but it should be unique among the other roles.
        "type": "TYPE_ROLE",                          // Always use `TYPE_ROLE`
        "extension": "ocis-roles",                    // Always use `ocis-roles`
        "displayName": "User Light",                  // DisplayName of the role used in webui
        "settings": [
        ],                                            // Permissions attached to the role. See Details below.
        "resource": {
            "type": "TYPE_SYSTEM"                     // Always use `TYPE_SYSTEM`
        }
    }
]

To create custom roles:

  • Copy the role example to a json file.

  • Change id, name, and displayName according your requirements.

  • Copy the desired permissions from the user-all-permissions example to the settings array of the role.

  • Set the SETTINGS_BUNDLE_PATH environment variable to the path/json-file and (re)start Infinite Scale.

See the full Custom Roles json example in the developer documentation for more details.

Caching

When using SETTINGS_STORE_TYPE=metadata, the settings service caches the results of queries against the storage backend to provide faster responses. The content of this cache is independent of the cache used in the storage-system service as it caches directory listing and settings content stored in files.

The settings service can use a configured store via the global OCIS_CACHE_STORE environment variable.

Note that for each global environment variable, an independent service-based one might be available additionally. For precedences see Environment Variable Notes. Check the configuration section below. Supported stores are:

Store Type Description

memory

Basic in-memory store. Will not survive a restart.
Usually the default for caches. See the store environment variable for which one is used.

nats-js-kv

Stores data using key-value-store feature of NATS JetStream.
Usually the default for stores, see the store environment variable for which one is used.

redis-sentinel

Stores data in a configured Redis Sentinel cluster.

noop

Stores nothing. Useful for testing. Not recommended in production environments.
The settings service can only be scaled if not using the memory store and the stores are configured identically over all instances!
If you have used one of the deprecated stores of a former version, you should reconfigure to use one of the supported ones as the deprecated stores will be removed in a later version.
Store specific notes

  • When using redis-sentinel:
    The Redis master to use is configured via e.g. OCIS_CACHE_STORE_NODES in the form of <sentinel-host>:<sentinel-port>/<redis-master> like 10.10.0.200:26379/mymaster.

  • When using nats-js-kv:

    • It is recommended to set OCIS_CACHE_STORE_NODES to the same value as OCIS_EVENTS_ENDPOINT. That way the cache uses the same nats instance as the event bus. See the Event Bus Configuration for more details.

    • Authentication can be added, if configured, via OCIS_CACHE_AUTH_USERNAME and OCIS_CACHE_AUTH_PASSWORD.

    • It is possible to set OCIS_CACHE_DISABLE_PERSISTENCE to instruct nats to not persist cache data on disc.

Event Bus Configuration

The Infinite Scale event bus can be configured by a set of environment variables.

  • In case of an orchestrated installation like with Docker or Kubernetes, the event bus must be an external service for scalability like a Redis Sentinel cluster or a key-value-store NATS JetStream. Both named stores are supported and also used in Caching and Persistence. The store used is not part of the Infinite Scale installation and must be separately provided and configured.

  • Note that from a configuration point of view, caching and persistence are independent of the event bus configuration.

Note that for each global environment variable, a service-based one might be available additionally. For precedences see Environment Variable Notes. Check the configuration section below.

Without the aim of completeness, see the list of environment variables to configure the event bus:

Envvar Description

OCIS_EVENTS_ENDPOINT

The address of the event system.

OCIS_EVENTS_CLUSTER

The clusterID of the event system. Mandatory when using NATS as event system.

OCIS_EVENTS_ENABLE_TLS

Enable TLS for the connection to the events broker.

OCIS_INSECURE

Whether to verify the server TLS certificates.

OCIS_EVENTS_AUTH_USERNAME

The username to authenticate with the events broker.

OCIS_EVENTS_AUTH_PASSWORD

The password to authenticate with the events broker.

Configuration

Environment Variables

The settings service is configured via the following environment variables. Read the Environment Variable Types documentation for important details. Column IV shows with which release the environment variable has been introduced.

404: Not Found

  • 8.1.0

404: Not Found

YAML Example

  • 8.1.0

404: Not Found