Userlog Service Configuration
Introduction
The Infinite Scale userlog service is a mediator between the eventhistory service and clients who want to be informed about user-related events. It provides an API to retrieve those.
The Log Service Ecosystem
Log services like the activitylog, clientlog, sse and userlog are responsible for composing notifications for a certain audience.
| Log services and their tasks | |
|---|---|
This service stores events per resource. These can be retrieved to show item activities. |
|
This service composes machine-readable messages, so clients can act without the need to query the server. |
|
This service stores events and allows other services to retrieve them via an event ID. |
|
This service is only responsible for sending these messages. It does not care about their form or language. |
|
userlog 2 |
This service translates and adjusts messages to be human-readable. |
Services may depend on each other:
-
The
activitylogservice requires theeventhistoryservice. -
The
userlogservice is configured by default to use both theeventhistoryandsseservice. It can be configured to use both, the one, or the other.
Prerequisites
Running the userlog service without running the eventhistory service is not possible.
Configuring Events
Currently, the configuration which user-related events are of interest is hard-coded and cannot be changed.
Retrieving
The userlog service provides an API to retrieve configured events. For now, this API is mostly following the ownCloud Classic notification GET API.
Subscribing
The userlog service provides an /sse (Server-Sent Events) endpoint to be informed by the server when an event happens. See What is Server-Sent Events for a simple introduction and examples to server-sent events. The sse endpoint will respect language changes of the user without needing to reconnect. Note that SSE have the limitation of six open connections per browser which can be reached if one has opened various tabs of the Web UI pointing to the same Infinite Scale instance.
Posting
The userlog service is able to store global messages that will be displayed in the Web UI to all users. If a user deletes the message in the Web UI, it reappears on reload. Global messages use the endpoint /ocs/v2.php/apps/notifications/api/v1/notifications/global and are activated by sending a POST request. Note that sending another POST request of the same type overwrites the previous one. For the time being, only the type deprovision is supported.
Authentication
POST and DELETE endpoints provide notifications to all users. Therefore only certain users can configure them. Two authentication methods for this endpoint are provided:
-
Users with the
adminrole can always access these endpoints. -
Additionally, a static secret via the
USERLOG_GLOBAL_NOTIFICATIONS_SECRETcan be defined to enable access for users knowing this secret, which has to be sent with the header containing the request.
Deprovisioning
Deprovision messages announce a deprovision text including a deprovision date of the instance to all users. With this message, users get informed that the instance will be shut down and deprovisioned and no further access to their data is possible past the given date. This implies that users must download their data before the given date. The text shown to users refers to this information. Note that the task to deprovision the instance does not depend on the message. The text of the message can be translated according to the translation settings, see section Translations. The endpoint only expects a deprovision_date parameter in the POST request body as the final text is assembled automatically. The string hast to be in RFC3339 format, however, this format can be changed by using deprovision_date_format. See the go time formating for more details.
Also see the GRAPH_LDAP_SCHOOL_TERMINATION_MIN_GRACE_DAYS environment variable for an additional configuration parameter.
Deleting
-
To delete events for an user, use a
DELETErequest to:https://<your-ocis-instance>/ocs/v2.php/apps/notifications/api/v1/notificationcontaining the IDs to delete.
-
Sending a
DELETErequest to the global endpoint:https://<your-ocis-instance>/ocs/v2.php/apps/notifications/api/v1/notifications/globalto remove a global message is a restricted action, see the Authentication section for more details.
Translations
The userlog 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 USERLOG_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 userlog.po (or userlog.mo) and stored in a folder structure defining the language code. In general the path/name pattern for a translation file needs to be:
{USERLOG_TRANSLATION_PATH}/{language-code}/LC_MESSAGES/userlog.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
{USERLOG_TRANSLATION_PATH}/de/LC_MESSAGES/userlog.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_DEis not available, the service tries to fall back to translations in thedefolder. -
If the base language
deis 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.
Storing
The userlog service can use a configured store via the global OCIS_PERSISTENT_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 |
|---|---|
|
Basic in-memory store. Will not survive a restart. |
|
Stores data using key-value-store feature of NATS JetStream. |
|
Stores data in a configured Redis Sentinel cluster. |
|
Stores nothing. Useful for testing. Not recommended in production environments. |
The userlog 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_PERSISTENT_STORE_NODESin the form of<sentinel-host>:<sentinel-port>/<redis-master>like10.10.0.200:26379/mymaster. -
When using
nats-js-kv:-
It is recommended to set
OCIS_PERSISTENT_STORE_NODESto the same value asOCIS_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_USERNAMEandOCIS_CACHE_AUTH_PASSWORD. -
It is possible to set
OCIS_CACHE_DISABLE_PERSISTENCEto 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.
|
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 |
|---|---|
|
The address of the event system. |
|
The clusterID of the event system. Mandatory when using NATS as event system. |
|
Enable TLS for the connection to the events broker. |
|
Whether to verify the server TLS certificates. |
|
The username to authenticate with the events broker. |
|
The password to authenticate with the events broker. |
Configuration
Environment Variables
The userlog 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
YAML Example
-
Note the file shown below must be renamed and placed in the correct folder according to the Configuration File Naming conventions to be effective.
-
See the Notes for Environment Variables if you want to use environment variables in the yaml file.