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.
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 thestorage-system
service. -
filesystem
: This backend persists the settings data in a directory on the local filesystem. The directory can be configured withSETTINGS_DATA_PATH
. This backend is not suitable for running multiple intances of thesettings
service in a scale-out deployment and should be therefore considered deprecated.
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 store used for the cache can be configured using the SETTINGS_CACHE_STORE
environment variable. Possible stores are:
Store Type | Description |
---|---|
|
Basic in-memory store and the default. |
|
Advanced in-memory store allowing max size. |
|
Stores data in a configured Redis cluster. |
|
Stores data in a configured Redis Sentinel cluster. |
|
Stores data in a configured etcd cluster. |
|
Stores data using the key-value-store feature of NATS JetStream. |
|
Stores nothing. Useful for testing. Not recommended in production environments. |
-
Note that in-memory stores are by nature not reboot-persistent.
-
Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type
in-memory
. These settings are blank by default which means that the standard settings of the configured store apply. -
The settings service can be scaled if not using
in-memory
stores and the stores are configured identically over all instances. -
When using
redis-sentinel
, the Redis master to use is configured viaSETTINGS_CACHE_STORE_NODES
in the form of<sentinel-host>:<sentinel-port>/<redis-master>
like10.10.0.200:26379/mymaster
.
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.
Configuration
Environment Variables
The settings
service is configured via the following environment variables. Read the Environment Variable Types documentation for important details.
Name | Type | Default Value | Description |
---|---|---|---|
|
bool |
false |
Activates tracing. |
|
string |
|
The type of tracing. Defaults to '', which is the same as 'jaeger'. Allowed tracing types are 'jaeger' and '' as of now. |
|
string |
|
The endpoint of the tracing agent. |
|
string |
|
The HTTP endpoint for sending spans directly to a collector, i.e. http://jaeger-collector:14268/api/traces. Only used if the tracing endpoint is unset. |
|
string |
|
The log level. Valid values are: 'panic', 'fatal', 'error', 'warn', 'info', 'debug', 'trace'. |
|
bool |
false |
Activates pretty log output. |
|
bool |
false |
Activates colorized log output. |
|
string |
|
The path to the log file. Activates logging to this file if set. |
|
string |
127.0.0.1:9194 |
Bind address of the debug server, where metrics, health, config and debug endpoints will be exposed. |
|
string |
|
Token to secure the metrics endpoint. |
|
bool |
false |
Enables pprof, which can be used for profiling. |
|
bool |
false |
Enables zpages, which can be used for collecting and viewing in-memory traces. |
|
string |
127.0.0.1:9190 |
The bind address of the HTTP service. |
|
bool |
false |
Activates TLS for the http based services using the server certifcate and key configured via OCIS_HTTP_TLS_CERTIFICATE and OCIS_HTTP_TLS_KEY. If OCIS_HTTP_TLS_CERTIFICATE is not set a temporary server certificate is generated - to be used with PROXY_INSECURE_BACKEND=true. |
|
string |
|
Path/File name of the TLS server certificate (in PEM format) for the http services. |
|
string |
|
Path/File name for the TLS certificate key (in PEM format) for the server certificate to use for the http services. |
|
string |
/ |
Subdirectory that serves as the root for this HTTP service. |
|
[]string |
[*] |
A comma-separated list of allowed CORS origins. See following chapter for more details: Access-Control-Allow-Origin at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin |
|
[]string |
[GET POST PUT PATCH DELETE OPTIONS] |
A comma-separated list of allowed CORS methods. See following chapter for more details: Access-Control-Request-Method at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Method |
|
[]string |
[Authorization Origin Content-Type Accept X-Requested-With X-Request-Id] |
A blank or comma-separated list of allowed CORS headers. See following chapter for more details: Access-Control-Request-Headers at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Headers. |
|
bool |
true |
Allow credentials for CORS.See following chapter for more details: Access-Control-Allow-Credentials at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials. |
|
string |
127.0.0.1:9191 |
The bind address of the GRPC service. |
|
string |
metadata |
Store type configures the persistency driver. Supported values are 'metadata' and 'filesystem'. Note that the value 'filesystem' is considered deprecated. |
|
string |
~/.ocis/settings |
The directory where the filesystem storage will store ocis settings. If not defined, the root directory derives from $OCIS_BASE_DATA_PATH:/settings. |
|
string |
com.owncloud.api.storage-system |
GRPC address of the STORAGE-SYSTEM service. |
|
string |
com.owncloud.api.storage-system |
GRPC address of the STORAGE-SYSTEM service. |
|
string |
|
ID of the oCIS STORAGE-SYSTEM system user. Admins need to set the ID for the STORAGE-SYSTEM system user in this config option which is then used to reference the user. Any reasonable long string is possible, preferably this would be an UUIDv4 format. |
|
string |
internal |
IDP of the oCIS STORAGE-SYSTEM system user. |
|
string |
|
API key for the STORAGE-SYSTEM system user. |
|
string |
memory |
The type of the cache store. Supported values are: 'memory', 'ocmem', 'etcd', 'redis', 'redis-sentinel', 'nats-js', 'noop'. See the text description for details. |
|
[]string |
[] |
A comma separated list of nodes to access the configured store. This has no effect when 'memory' or 'ocmem' stores are configured. Note that the behaviour how nodes are used is dependent on the library of the configured store. |
|
string |
ocis |
The database name the configured store should use. |
|
string |
settings_files |
The database table the store should use for the file cache. |
|
string |
settings_dirs |
The database table the store should use for the directory cache. |
|
Duration |
10m0s |
Default time to live for entries in the cache. Only applied when access tokens has no expiration. The duration can be set as number followed by a unit identifier like s, m or h. Defaults to '10m' (10 minutes). |
|
int |
0 |
The maximum quantity of items in the cache. Only applies when store type 'ocmem' is configured. Defaults to 512. |
|
string |
|
The path to a JSON file with a list of bundles. If not defined, the default bundles will be loaded. |
|
string |
|
ID of the user that should receive admin privileges. Consider that the UUID can be encoded in some LDAP deployment configurations like in .ldif files. These need to be decoded beforehand. |
|
string |
|
The secret to mint and validate jwt tokens. |
|
bool |
false |
The default role assignments the demo users should be setup. |
YAML Example
Note that the filename shown below has been chosen on purpose.
See the Configuration File Naming for details when setting up your own configuration.
# Autogenerated
# Filename: settings-config-example.yaml
tracing:
enabled: false
type: ""
endpoint: ""
collector: ""
log:
level: ""
pretty: false
color: false
file: ""
debug:
addr: 127.0.0.1:9194
token: ""
pprof: false
zpages: false
http:
addr: 127.0.0.1:9190
tls:
enabled: false
cert: ""
key: ""
root: /
cors:
allow_origins:
- '*'
allow_methods:
- GET
- POST
- PUT
- PATCH
- DELETE
- OPTIONS
allow_headers:
- Authorization
- Origin
- Content-Type
- Accept
- X-Requested-With
- X-Request-Id
allow_credentials: true
grpc:
addr: 127.0.0.1:9191
tls: null
grpc_client_tls: null
store_type: metadata
data_path: ~/.ocis/settings
metadata_config:
gateway_addr: com.owncloud.api.storage-system
storage_addr: com.owncloud.api.storage-system
system_user_id: ""
system_user_idp: internal
system_user_api_key: ""
cache:
store: memory
addresses: []
database: ocis
files_table: settings_files
directories_table: settings_dirs
ttl: 10m0s
size: 0
bundles_path: ""
admin_user_id: ""
token_manager:
jwt_secret: ""
set_default_assignments: false