From e939cbf88b50779b708cdb07c3d117e05b1da5d0 Mon Sep 17 00:00:00 2001 From: Michael Barz Date: Fri, 18 Dec 2020 01:10:55 +0000 Subject: [PATCH] commit 8d9c53c6a9d1e0b136b5970275e10337a32d87d2 Merge: 8c635a8 78c86a3 Author: Michael Barz Date: Thu Dec 10 17:02:07 2020 +0100 Merge pull request #21 from wkloucek/bump_geekdoc_version bump version of geekdoc --- clients/index.html | 2 +- clients/web/backend-oc10/index.html | 2 +- clients/web/backend-ocis/index.html | 2 +- clients/web/building/index.html | 2 +- clients/web/deployments/index.html | 2 +- clients/web/deployments/oc10-app/index.html | 2 +- clients/web/getting-started/index.html | 2 +- clients/web/index.html | 2 +- clients/web/releasing/index.html | 2 +- clients/web/testing/index.html | 2 +- extensions/accounts/configuration/index.html | 50 ++--- extensions/accounts/index.html | 2 +- extensions/accounts/index.xml | 4 +- .../glauth/configuration-hints/index.html | 2 +- extensions/glauth/configuration/index.html | 2 +- extensions/glauth/index.html | 2 +- extensions/glauth/index.xml | 2 +- extensions/index.html | 2 +- extensions/index.xml | 2 +- extensions/konnectd/configuration/index.html | 38 ++-- extensions/konnectd/index.html | 2 +- extensions/konnectd/index.xml | 6 +- extensions/ocis_hello/building/index.html | 2 +- .../configuration-with-ocis/index.html | 2 +- .../ocis_hello/getting-started/index.html | 2 +- extensions/ocis_hello/index.html | 2 +- extensions/ocis_hello/license/index.html | 2 +- extensions/ocis_hello/settings/index.html | 2 +- extensions/ocis_hello/testing/index.html | 2 +- extensions/ocs/configuration/index.html | 2 +- extensions/ocs/index.html | 2 +- extensions/ocs/index.xml | 2 +- extensions/onlyoffice/building/index.html | 2 +- .../onlyoffice/configuration/index.html | 2 +- .../onlyoffice/getting-started/index.html | 2 +- extensions/onlyoffice/index.html | 2 +- extensions/onlyoffice/index.xml | 2 +- extensions/onlyoffice/license/index.html | 2 +- extensions/proxy/configuration/index.html | 2 +- extensions/proxy/index.html | 2 +- extensions/proxy/index.xml | 4 +- extensions/settings/bundles/index.html | 2 +- extensions/settings/configuration/index.html | 18 +- extensions/settings/glossary/index.html | 2 +- extensions/settings/index.html | 2 +- extensions/settings/index.xml | 4 +- extensions/settings/values/index.html | 2 +- extensions/storage/configuration/index.html | 202 +++++++++--------- extensions/storage/index.html | 2 +- extensions/storage/index.xml | 4 +- extensions/storage/releasing/index.html | 2 +- extensions/storage/storages/index.html | 2 +- extensions/storage/updating/index.html | 2 +- extensions/storage/users/index.html | 2 +- extensions/store/configuration/index.html | 22 +- extensions/store/index.html | 2 +- extensions/store/index.xml | 4 +- .../thumbnails/configuration/index.html | 22 +- extensions/thumbnails/grpc/index.html | 2 +- extensions/thumbnails/index.html | 2 +- extensions/thumbnails/index.xml | 4 +- extensions/web/configuration/index.html | 2 +- extensions/web/index.html | 2 +- extensions/web/index.xml | 2 +- extensions/web/releasing/index.html | 2 +- extensions/webdav/configuration/index.html | 22 +- extensions/webdav/index.html | 2 +- extensions/webdav/index.xml | 4 +- index.html | 2 +- index.xml | 54 ++--- .../accessing-resources/index.html | 2 +- .../file_picker/getting-started/index.html | 2 +- integration/file_picker/index.html | 2 +- .../file_picker/installation/index.html | 2 +- integration/index.html | 2 +- ...65ad118b95ffbc2521983e042421266b9a4e057.js | 1 - ...917c50670d23f43919eef331fca6cd0f4b51912.js | 1 + ...d0a3a4d3a56a39a0240179a13c8d978c7db9e6.js} | 2 +- ocis/configuration/index.html | 118 +++++----- ocis/deployment/basic-remote-setup/index.html | 2 +- ocis/deployment/bridge/index.html | 2 +- ocis/deployment/index.html | 2 +- ocis/deployment/ocis_keycloak/index.html | 2 +- ocis/deployment/ocis_traefik/index.html | 2 +- .../owncloud10_with_oc_web/index.html | 2 +- ocis/deployment/preparing_server/index.html | 2 +- ocis/development/build-docs/index.html | 2 +- ocis/development/build/index.html | 2 +- .../continuous-integration/index.html | 2 +- ocis/development/debugging/index.html | 2 +- ocis/development/extensions/index.html | 2 +- ocis/development/getting-started/index.html | 2 +- ocis/development/index.html | 2 +- ocis/development/testing/index.html | 2 +- ocis/development/tracing/index.html | 2 +- ocis/flow-docs/index.html | 2 +- ocis/flow-docs/login-flow/index.html | 2 +- ocis/flow-docs/public-upload-flow/index.html | 2 +- ocis/flow-docs/request-flow/index.html | 2 +- ocis/getting-started/index.html | 2 +- ocis/index.html | 2 +- ocis/index.xml | 4 +- ocis/license/index.html | 2 +- ocis/metrics/index.html | 2 +- ocis/release_notes/index.html | 2 +- ocis/storage-backends/eos/index.html | 2 +- ocis/storage-backends/index.html | 2 +- sitemap.xml | 38 ++-- 108 files changed, 399 insertions(+), 399 deletions(-) delete mode 100644 js/en.search-data.min.3ccf11e25ef498d481a7400a165ad118b95ffbc2521983e042421266b9a4e057.js create mode 100644 js/en.search-data.min.91704021600fa95e2ca21db96917c50670d23f43919eef331fca6cd0f4b51912.js rename js/{en.search.min.36e2a3daa1a7d9d1a933e76363bd1cadad789d8474329428a44ff2517a93eed4.js => en.search.min.8e63005e83f25e0b9e559c19ffd0a3a4d3a56a39a0240179a13c8d978c7db9e6.js} (89%) diff --git a/clients/index.html b/clients/index.html index 599d68d8d1c..b16f55c25b3 100644 --- a/clients/index.html +++ b/clients/index.html @@ -2653,7 +2653,7 @@

Clients

- + diff --git a/clients/web/backend-oc10/index.html b/clients/web/backend-oc10/index.html index 531c0ebcd5b..5e1a12edce5 100644 --- a/clients/web/backend-oc10/index.html +++ b/clients/web/backend-oc10/index.html @@ -2741,7 +2741,7 @@

Setup with ownCloud 10

- + diff --git a/clients/web/backend-ocis/index.html b/clients/web/backend-ocis/index.html index 30f61bfff0e..922f03e22e1 100644 --- a/clients/web/backend-ocis/index.html +++ b/clients/web/backend-ocis/index.html @@ -2711,7 +2711,7 @@

Setup with OCIS

- + diff --git a/clients/web/building/index.html b/clients/web/building/index.html index ef59b9b5387..477ebe4ebba 100644 --- a/clients/web/building/index.html +++ b/clients/web/building/index.html @@ -2719,7 +2719,7 @@

Building from source

- + diff --git a/clients/web/deployments/index.html b/clients/web/deployments/index.html index 3b30a6f490b..f67ad273639 100644 --- a/clients/web/deployments/index.html +++ b/clients/web/deployments/index.html @@ -2675,7 +2675,7 @@

Deployments

- + diff --git a/clients/web/deployments/oc10-app/index.html b/clients/web/deployments/oc10-app/index.html index 48a72055908..b95c1bb0b00 100644 --- a/clients/web/deployments/oc10-app/index.html +++ b/clients/web/deployments/oc10-app/index.html @@ -2760,7 +2760,7 @@

Deploy as an app in ownCloud 10

- + diff --git a/clients/web/getting-started/index.html b/clients/web/getting-started/index.html index 904f028e0d9..d7558c911a6 100644 --- a/clients/web/getting-started/index.html +++ b/clients/web/getting-started/index.html @@ -2732,7 +2732,7 @@

Getting Started

- + diff --git a/clients/web/index.html b/clients/web/index.html index 80890ab0a72..085b9d03dda 100644 --- a/clients/web/index.html +++ b/clients/web/index.html @@ -2668,7 +2668,7 @@

ownCloud Web

- + diff --git a/clients/web/releasing/index.html b/clients/web/releasing/index.html index 681e12987e0..b937fc217d1 100644 --- a/clients/web/releasing/index.html +++ b/clients/web/releasing/index.html @@ -2720,7 +2720,7 @@

Releasing

- + diff --git a/clients/web/testing/index.html b/clients/web/testing/index.html index 5d10f610332..4270f786e79 100644 --- a/clients/web/testing/index.html +++ b/clients/web/testing/index.html @@ -2915,7 +2915,7 @@

Running acceptance tests

- + diff --git a/extensions/accounts/configuration/index.html b/extensions/accounts/configuration/index.html index 4093bfc1bcd..f439c1955ef 100644 --- a/extensions/accounts/configuration/index.html +++ b/extensions/accounts/configuration/index.html @@ -2627,12 +2627,12 @@

Configuration

  • Configuration using config files
  • Environment variables
  • Commandline flags
    • -
  • accounts server
    • -
  • accounts add
    • -
  • accounts list
  • accounts version
  • accounts update
  • accounts remove
    • +
  • accounts server
    • +
  • accounts add
    • +
  • accounts list
  • accounts rebuildIndex
  • accounts ocis-accounts
  • accounts inspect
    • @@ -2653,6 +2653,27 @@

    Configuration

    If you prefer to configure the service with environment variables you can see the available variables below.

    Commandline flags

    If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.

    +

    accounts version

    +

    Print the versions of the running instances

    +

    Usage: accounts version [command options] [arguments...]

    +
    +
    –grpc-namespace | $ACCOUNTS_GRPC_NAMESPACE
    +
    Set the base namespace for the grpc namespace. Default: com.owncloud.api.
    +
    –name | $ACCOUNTS_NAME
    +
    service name. Default: accounts.
    +
    +

    accounts update

    +

    Make changes to an existing account

    +

    Usage: accounts update [command options] [arguments...]

    +

    accounts remove

    +

    Removes an existing account

    +

    Usage: accounts remove [command options] [arguments...]

    +
    +
    –grpc-namespace | $ACCOUNTS_GRPC_NAMESPACE
    +
    Set the base namespace for the grpc namespace. Default: com.owncloud.api.
    +
    –name | $ACCOUNTS_NAME
    +
    service name. Default: accounts.
    +

    accounts server

    Start ocis accounts service

    Usage: accounts server [command options] [arguments...]

    @@ -2710,27 +2731,6 @@

    Configuration

    –name | $ACCOUNTS_NAME
    service name. Default: accounts.
    -

    accounts version

    -

    Print the versions of the running instances

    -

    Usage: accounts version [command options] [arguments...]

    -
    -
    –grpc-namespace | $ACCOUNTS_GRPC_NAMESPACE
    -
    Set the base namespace for the grpc namespace. Default: com.owncloud.api.
    -
    –name | $ACCOUNTS_NAME
    -
    service name. Default: accounts.
    -
    -

    accounts update

    -

    Make changes to an existing account

    -

    Usage: accounts update [command options] [arguments...]

    -

    accounts remove

    -

    Removes an existing account

    -

    Usage: accounts remove [command options] [arguments...]

    -
    -
    –grpc-namespace | $ACCOUNTS_GRPC_NAMESPACE
    -
    Set the base namespace for the grpc namespace. Default: com.owncloud.api.
    -
    –name | $ACCOUNTS_NAME
    -
    service name. Default: accounts.
    -

    accounts rebuildIndex

    Rebuilds the service’s index, i.e. deleting and then re-adding all existing documents

    Usage: accounts rebuildIndex [command options] [arguments...]

    @@ -2810,7 +2810,7 @@

    Configuration

    - + diff --git a/extensions/accounts/index.html b/extensions/accounts/index.html index fd3fb430a2c..099a3480e4d 100644 --- a/extensions/accounts/index.html +++ b/extensions/accounts/index.html @@ -2705,7 +2705,7 @@

    Accounts

    - + diff --git a/extensions/accounts/index.xml b/extensions/accounts/index.xml index c81066400bc..7901d450f0b 100644 --- a/extensions/accounts/index.xml +++ b/extensions/accounts/index.xml @@ -14,10 +14,10 @@ Configuration https://owncloud.github.io/extensions/accounts/configuration/ - Thu, 17 Dec 2020 21:01:15 +0000 + Fri, 18 Dec 2020 01:09:31 +0000 https://owncloud.github.io/extensions/accounts/configuration/ - Configuration Configuration using config files Environment variables Commandline flags accounts server accounts add accounts list accounts version accounts update accounts remove accounts rebuildIndex accounts ocis-accounts accounts inspect Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: + Configuration Configuration using config files Environment variables Commandline flags accounts version accounts update accounts remove accounts server accounts add accounts list accounts rebuildIndex accounts ocis-accounts accounts inspect Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: /etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. diff --git a/extensions/glauth/configuration-hints/index.html b/extensions/glauth/configuration-hints/index.html index 512ec6f736a..567caba34be 100644 --- a/extensions/glauth/configuration-hints/index.html +++ b/extensions/glauth/configuration-hints/index.html @@ -2685,7 +2685,7 @@

    Configuration Hints

    - + diff --git a/extensions/glauth/configuration/index.html b/extensions/glauth/configuration/index.html index 3409ee418bd..7ed497573fd 100644 --- a/extensions/glauth/configuration/index.html +++ b/extensions/glauth/configuration/index.html @@ -2788,7 +2788,7 @@

    Configuration

    - + diff --git a/extensions/glauth/index.html b/extensions/glauth/index.html index 9ba84d9a58b..820747c9d8c 100644 --- a/extensions/glauth/index.html +++ b/extensions/glauth/index.html @@ -2669,7 +2669,7 @@

    GLAuth

    - + diff --git a/extensions/glauth/index.xml b/extensions/glauth/index.xml index c5e7db31d15..56463196a03 100644 --- a/extensions/glauth/index.xml +++ b/extensions/glauth/index.xml @@ -14,7 +14,7 @@ Configuration https://owncloud.github.io/extensions/glauth/configuration/ - Thu, 17 Dec 2020 21:01:17 +0000 + Fri, 18 Dec 2020 01:09:33 +0000 https://owncloud.github.io/extensions/glauth/configuration/ Configuration Configuration using config files Environment variables Commandline flags glauth health glauth server glauth ocis-glauth Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: diff --git a/extensions/index.html b/extensions/index.html index fbe9b3625d0..f95c044850a 100644 --- a/extensions/index.html +++ b/extensions/index.html @@ -2653,7 +2653,7 @@

    Extensions

    - + diff --git a/extensions/index.xml b/extensions/index.xml index d99feea8aae..495219b61cb 100644 --- a/extensions/index.xml +++ b/extensions/index.xml @@ -6,7 +6,7 @@ Recent content in Extensions on ownCloud Hugo -- gohugo.io en-us - Thu, 17 Dec 2020 21:01:29 +0000 + Fri, 18 Dec 2020 01:09:45 +0000 diff --git a/extensions/konnectd/configuration/index.html b/extensions/konnectd/configuration/index.html index 1e4ae5d684e..f77b81cc712 100644 --- a/extensions/konnectd/configuration/index.html +++ b/extensions/konnectd/configuration/index.html @@ -2627,10 +2627,10 @@

    Configuration

  • Configuration using config files
  • Environment variables
  • Commandline flags
    • -
  • konnectd version
    • -
  • konnectd health
  • konnectd server
  • konnectd ocis-konnectd
    • +
  • konnectd version
    • +
  • konnectd health
    • @@ -2648,22 +2648,6 @@

    Configuration

    If you prefer to configure the service with environment variables you can see the available variables below.

    Commandline flags

    If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.

    -

    konnectd version

    -

    Print the versions of the running instances

    -

    Usage: konnectd version [command options] [arguments...]

    -
    -
    –http-namespace | $KONNECTD_HTTP_NAMESPACE
    -
    Set the base namespace for service discovery. Default: com.owncloud.web.
    -
    –name | $KONNECTD_NAME
    -
    Service name. Default: konnectd.
    -
    -

    konnectd health

    -

    Check health status

    -

    Usage: konnectd health [command options] [arguments...]

    -
    -
    –debug-addr | $KONNECTD_DEBUG_ADDR
    -
    Address to debug endpoint. Default: 0.0.0.0:9134.
    -

    konnectd server

    Start integrated server

    Usage: konnectd server [command options] [arguments...]

    @@ -2751,6 +2735,22 @@

    Configuration

    Enable pretty logging. Default: true.
    –log-color | $KONNECTD_LOG_COLOR
    Enable colored logging. Default: true.
    + +

    konnectd version

    +

    Print the versions of the running instances

    +

    Usage: konnectd version [command options] [arguments...]

    +
    +
    –http-namespace | $KONNECTD_HTTP_NAMESPACE
    +
    Set the base namespace for service discovery. Default: com.owncloud.web.
    +
    –name | $KONNECTD_NAME
    +
    Service name. Default: konnectd.
    +
    +

    konnectd health

    +

    Check health status

    +

    Usage: konnectd health [command options] [arguments...]

    +
    +
    –debug-addr | $KONNECTD_DEBUG_ADDR
    +
    Address to debug endpoint. Default: 0.0.0.0:9134.
    @@ -2808,7 +2808,7 @@

    Configuration

    - + diff --git a/extensions/konnectd/index.html b/extensions/konnectd/index.html index caea9167f89..64e2ab608b6 100644 --- a/extensions/konnectd/index.html +++ b/extensions/konnectd/index.html @@ -2668,7 +2668,7 @@

    Konnectd

    - + diff --git a/extensions/konnectd/index.xml b/extensions/konnectd/index.xml index ad8c8b9c034..03170898ab6 100644 --- a/extensions/konnectd/index.xml +++ b/extensions/konnectd/index.xml @@ -6,7 +6,7 @@ Recent content in Konnectd on ownCloud Hugo -- gohugo.io en-us - Thu, 17 Dec 2020 21:01:19 +0000 + Fri, 18 Dec 2020 01:09:34 +0000 @@ -14,10 +14,10 @@ Configuration https://owncloud.github.io/extensions/konnectd/configuration/ - Thu, 17 Dec 2020 21:01:19 +0000 + Fri, 18 Dec 2020 01:09:34 +0000 https://owncloud.github.io/extensions/konnectd/configuration/ - Configuration Configuration using config files Environment variables Commandline flags konnectd version konnectd health konnectd server konnectd ocis-konnectd Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: + Configuration Configuration using config files Environment variables Commandline flags konnectd server konnectd ocis-konnectd konnectd version konnectd health Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: /etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. diff --git a/extensions/ocis_hello/building/index.html b/extensions/ocis_hello/building/index.html index 37607a13893..7dddcae4f38 100644 --- a/extensions/ocis_hello/building/index.html +++ b/extensions/ocis_hello/building/index.html @@ -2695,7 +2695,7 @@

    Building

    - + diff --git a/extensions/ocis_hello/configuration-with-ocis/index.html b/extensions/ocis_hello/configuration-with-ocis/index.html index 72262bd36f4..8163919961c 100644 --- a/extensions/ocis_hello/configuration-with-ocis/index.html +++ b/extensions/ocis_hello/configuration-with-ocis/index.html @@ -2755,7 +2755,7 @@

    Running

    - + diff --git a/extensions/ocis_hello/getting-started/index.html b/extensions/ocis_hello/getting-started/index.html index 636eac47616..cef571b5081 100644 --- a/extensions/ocis_hello/getting-started/index.html +++ b/extensions/ocis_hello/getting-started/index.html @@ -2893,7 +2893,7 @@

    Getting Started

    - + diff --git a/extensions/ocis_hello/index.html b/extensions/ocis_hello/index.html index f6c44f9121f..8610cb551f4 100644 --- a/extensions/ocis_hello/index.html +++ b/extensions/ocis_hello/index.html @@ -2803,7 +2803,7 @@

    Hello

    - + diff --git a/extensions/ocis_hello/license/index.html b/extensions/ocis_hello/license/index.html index 8b517df7bc9..57357514eed 100644 --- a/extensions/ocis_hello/license/index.html +++ b/extensions/ocis_hello/license/index.html @@ -2675,7 +2675,7 @@

    License

    - + diff --git a/extensions/ocis_hello/settings/index.html b/extensions/ocis_hello/settings/index.html index 67da94bab5b..c0c80059917 100644 --- a/extensions/ocis_hello/settings/index.html +++ b/extensions/ocis_hello/settings/index.html @@ -2773,7 +2773,7 @@

    Settings

    - + diff --git a/extensions/ocis_hello/testing/index.html b/extensions/ocis_hello/testing/index.html index 930c86e10c3..720a79825f4 100644 --- a/extensions/ocis_hello/testing/index.html +++ b/extensions/ocis_hello/testing/index.html @@ -2709,7 +2709,7 @@

    Testing

    - + diff --git a/extensions/ocs/configuration/index.html b/extensions/ocs/configuration/index.html index c0d0b77452f..c171fbdbd6b 100644 --- a/extensions/ocs/configuration/index.html +++ b/extensions/ocs/configuration/index.html @@ -2766,7 +2766,7 @@

    Configuration

    - + diff --git a/extensions/ocs/index.html b/extensions/ocs/index.html index d8983ac2dc1..a72f307e79c 100644 --- a/extensions/ocs/index.html +++ b/extensions/ocs/index.html @@ -2668,7 +2668,7 @@

    Ocs

    - + diff --git a/extensions/ocs/index.xml b/extensions/ocs/index.xml index f7370f9b85f..0617888098c 100644 --- a/extensions/ocs/index.xml +++ b/extensions/ocs/index.xml @@ -14,7 +14,7 @@ Configuration https://owncloud.github.io/extensions/ocs/configuration/ - Thu, 17 Dec 2020 21:01:23 +0000 + Fri, 18 Dec 2020 01:09:38 +0000 https://owncloud.github.io/extensions/ocs/configuration/ Configuration Configuration using config files Environment variables Commandline flags ocs health ocs server ocs ocis-ocs ocs version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: diff --git a/extensions/onlyoffice/building/index.html b/extensions/onlyoffice/building/index.html index d07c5eb9122..7a4cc22e73d 100644 --- a/extensions/onlyoffice/building/index.html +++ b/extensions/onlyoffice/building/index.html @@ -2690,7 +2690,7 @@

    Building

    - + diff --git a/extensions/onlyoffice/configuration/index.html b/extensions/onlyoffice/configuration/index.html index 646d3ca43be..8e10764ed8d 100644 --- a/extensions/onlyoffice/configuration/index.html +++ b/extensions/onlyoffice/configuration/index.html @@ -2761,7 +2761,7 @@

    Configuration

    - + diff --git a/extensions/onlyoffice/getting-started/index.html b/extensions/onlyoffice/getting-started/index.html index c360ab73338..67145e1af3e 100644 --- a/extensions/onlyoffice/getting-started/index.html +++ b/extensions/onlyoffice/getting-started/index.html @@ -2903,7 +2903,7 @@

    Getting Started

    - + diff --git a/extensions/onlyoffice/index.html b/extensions/onlyoffice/index.html index 18aaa5ceada..798e85c13f1 100644 --- a/extensions/onlyoffice/index.html +++ b/extensions/onlyoffice/index.html @@ -2668,7 +2668,7 @@

    OnlyOffice

    - + diff --git a/extensions/onlyoffice/index.xml b/extensions/onlyoffice/index.xml index 6ab59893e57..d3ea673760e 100644 --- a/extensions/onlyoffice/index.xml +++ b/extensions/onlyoffice/index.xml @@ -14,7 +14,7 @@ Configuration https://owncloud.github.io/extensions/onlyoffice/configuration/ - Thu, 17 Dec 2020 21:01:29 +0000 + Fri, 18 Dec 2020 01:09:45 +0000 https://owncloud.github.io/extensions/onlyoffice/configuration/ Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands onlyoffice server onlyoffice health Configuration oCIS Single Binary is not responsible for configuring extensions. Instead, each extension could either be configured by environment variables, cli flags or config files. diff --git a/extensions/onlyoffice/license/index.html b/extensions/onlyoffice/license/index.html index 3b0a6861a9c..66e4b100c1a 100644 --- a/extensions/onlyoffice/license/index.html +++ b/extensions/onlyoffice/license/index.html @@ -2675,7 +2675,7 @@

    License

    - + diff --git a/extensions/proxy/configuration/index.html b/extensions/proxy/configuration/index.html index fffbf59c720..e2708d3f634 100644 --- a/extensions/proxy/configuration/index.html +++ b/extensions/proxy/configuration/index.html @@ -2790,7 +2790,7 @@

    Configuration

    - + diff --git a/extensions/proxy/index.html b/extensions/proxy/index.html index c13bfa16078..3d110cebd5b 100644 --- a/extensions/proxy/index.html +++ b/extensions/proxy/index.html @@ -2668,7 +2668,7 @@

    Proxy

    - + diff --git a/extensions/proxy/index.xml b/extensions/proxy/index.xml index 891dda63012..01c2153e147 100644 --- a/extensions/proxy/index.xml +++ b/extensions/proxy/index.xml @@ -6,7 +6,7 @@ Recent content in Proxy on ownCloud Hugo -- gohugo.io en-us - Thu, 17 Dec 2020 21:01:24 +0000 + Fri, 18 Dec 2020 01:09:39 +0000 @@ -14,7 +14,7 @@ Configuration https://owncloud.github.io/extensions/proxy/configuration/ - Thu, 17 Dec 2020 21:01:24 +0000 + Fri, 18 Dec 2020 01:09:39 +0000 https://owncloud.github.io/extensions/proxy/configuration/ Configuration Configuration using config files Environment variables Commandline flags proxy health proxy server proxy ocis-proxy proxy version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: diff --git a/extensions/settings/bundles/index.html b/extensions/settings/bundles/index.html index 39a5829b87f..d41e69cfc3f 100644 --- a/extensions/settings/bundles/index.html +++ b/extensions/settings/bundles/index.html @@ -2736,7 +2736,7 @@

    Settings Bundles

    - + diff --git a/extensions/settings/configuration/index.html b/extensions/settings/configuration/index.html index 9b346ebaba8..575ba767a55 100644 --- a/extensions/settings/configuration/index.html +++ b/extensions/settings/configuration/index.html @@ -2627,10 +2627,10 @@

    Configuration

  • Configuration using config files
  • Environment variables
  • Commandline flags
    • -
  • settings health
  • settings server
  • settings ocis-settings
  • settings version
    • +
  • settings health
    • @@ -2648,13 +2648,6 @@

    Configuration

    If you prefer to configure the service with environment variables you can see the available variables below.

    Commandline flags

    If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.

    -

    settings health

    -

    Check health status

    -

    Usage: settings health [command options] [arguments...]

    -
    -
    –debug-addr | $SETTINGS_DEBUG_ADDR
    -
    Address to debug endpoint. Default: 0.0.0.0:9194.
    -

    settings server

    Start integrated server

    Usage: settings server [command options] [arguments...]

    @@ -2717,6 +2710,13 @@

    Configuration

    Set the base namespace for the grpc namespace. Default: com.owncloud.api.
    –name | $SETTINGS_NAME
    service name. Default: settings.
    + +

    settings health

    +

    Check health status

    +

    Usage: settings health [command options] [arguments...]

    +
    +
    –debug-addr | $SETTINGS_DEBUG_ADDR
    +
    Address to debug endpoint. Default: 0.0.0.0:9194.
    @@ -2774,7 +2774,7 @@

    Configuration

    - + diff --git a/extensions/settings/glossary/index.html b/extensions/settings/glossary/index.html index 7ebe76707d3..43453685681 100644 --- a/extensions/settings/glossary/index.html +++ b/extensions/settings/glossary/index.html @@ -2707,7 +2707,7 @@

    Glossary

    - + diff --git a/extensions/settings/index.html b/extensions/settings/index.html index d4b6d174530..61a5788dec9 100644 --- a/extensions/settings/index.html +++ b/extensions/settings/index.html @@ -2715,7 +2715,7 @@

    Settings

    - + diff --git a/extensions/settings/index.xml b/extensions/settings/index.xml index c635e5772fe..d4e700b6a1b 100644 --- a/extensions/settings/index.xml +++ b/extensions/settings/index.xml @@ -14,10 +14,10 @@ Configuration https://owncloud.github.io/extensions/settings/configuration/ - Thu, 17 Dec 2020 21:01:25 +0000 + Fri, 18 Dec 2020 01:09:40 +0000 https://owncloud.github.io/extensions/settings/configuration/ - Configuration Configuration using config files Environment variables Commandline flags settings health settings server settings ocis-settings settings version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: + Configuration Configuration using config files Environment variables Commandline flags settings server settings ocis-settings settings version settings health Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: /etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. diff --git a/extensions/settings/values/index.html b/extensions/settings/values/index.html index 9845d8914c7..4c56a6ee77d 100644 --- a/extensions/settings/values/index.html +++ b/extensions/settings/values/index.html @@ -2735,7 +2735,7 @@

    Settings Values

    - + diff --git a/extensions/storage/configuration/index.html b/extensions/storage/configuration/index.html index bcc422ef752..e08939cbb39 100644 --- a/extensions/storage/configuration/index.html +++ b/extensions/storage/configuration/index.html @@ -2632,17 +2632,17 @@

    Configuration

  • Root Command
  • Sub Commands
    • @@ -2683,6 +2683,68 @@

    Configuration

    Enable colored logging.

    Sub Commands

    +

    storage storage-home

    +

    Start storage-home service

    +

    Usage: storage storage-home [command options] [arguments...]

    +
    +
    –debug-addr | $STORAGE_HOME_DEBUG_ADDR
    +
    Address to bind debug server. Default: 0.0.0.0:9156.
    +
    –grpc-network | $STORAGE_HOME_GRPC_NETWORK
    +
    Network to use for the storage service, can be ‘tcp’, ‘udp’ or ‘unix’. Default: tcp.
    +
    –grpc-addr | $STORAGE_HOME_GRPC_ADDR
    +
    Address to bind storage service. Default: 0.0.0.0:9154.
    +
    –http-network | $STORAGE_HOME_HTTP_NETWORK
    +
    Network to use for the storage service, can be ‘tcp’, ‘udp’ or ‘unix’. Default: tcp.
    +
    –http-addr | $STORAGE_HOME_HTTP_ADDR
    +
    Address to bind storage service. Default: 0.0.0.0:9155.
    +
    –driver | $STORAGE_HOME_DRIVER
    +
    storage driver for home mount: eg. local, eos, owncloud, ocis or s3. Default: ocis.
    +
    –mount-path | $STORAGE_HOME_MOUNT_PATH
    +
    mount path. Default: /home.
    +
    –mount-id | $STORAGE_HOME_MOUNT_ID
    +
    mount id. Default: 1284d238-aa92-42ce-bdc4-0b0000009157.
    +
    –expose-data-server | $STORAGE_HOME_EXPOSE_DATA_SERVER
    +
    exposes a dedicated data server. Default: false.
    +
    –data-server-url | $STORAGE_HOME_DATA_SERVER_URL
    +
    data server url. Default: http://localhost:9155/data.
    +
    –http-prefix | $STORAGE_HOME_HTTP_PREFIX
    +
    prefix for the http endpoint, without leading slash. Default: data.
    +
    –tmp-folder | $STORAGE_HOME_TMP_FOLDER
    +
    path to tmp folder. Default: /var/tmp/ocis/tmp/home.
    +
    –enable-home | $STORAGE_HOME_ENABLE_HOME
    +
    enable the creation of home directories. Default: true.
    +
    –gateway-endpoint | $STORAGE_GATEWAY_ENDPOINT
    +
    endpoint to use for the storage gateway service. Default: localhost:9142.
    +
    –users-endpoint | $STORAGE_USERPROVIDER_ENDPOINT
    +
    endpoint to use for the storage service. Default: localhost:9144.
    +
    +

    storage storage-metadata

    +

    Start storage-metadata service

    +

    Usage: storage storage-metadata [command options] [arguments...]

    +
    +
    –debug-addr | $STORAGE_METADATA_DEBUG_ADDR
    +
    Address to bind debug server. Default: 0.0.0.0:9217.
    +
    –grpc-network | $STORAGE_METADATA_GRPC_NETWORK
    +
    Network to use for the storage service, can be ‘tcp’, ‘udp’ or ‘unix’. Default: tcp.
    +
    –grpc-addr | $STORAGE_METADATA_GRPC_PROVIDER_ADDR
    +
    Address to bind storage service. Default: 0.0.0.0:9215.
    +
    –data-server-url | $STORAGE_METADATA_DATA_SERVER_URL
    +
    URL of the data-provider the storage-provider uses. Default: http://localhost:9216.
    +
    –http-network | $STORAGE_METADATA_HTTP_NETWORK
    +
    Network to use for the storage service, can be ‘tcp’, ‘udp’ or ‘unix’. Default: tcp.
    +
    –http-addr | $STORAGE_METADATA_HTTP_ADDR
    +
    Address to bind storage service. Default: 0.0.0.0:9216.
    +
    –tmp-folder | $STORAGE_METADATA_TMP_FOLDER
    +
    path to tmp folder. Default: /var/tmp/ocis/tmp/metadata.
    +
    –driver | $STORAGE_METADATA_DRIVER
    +
    storage driver for metadata mount: eg. local, eos, owncloud, ocis or s3. Default: ocis.
    +
    –gateway-endpoint | $STORAGE_GATEWAY_ENDPOINT
    +
    endpoint to use for the gateway service. Default: localhost:9142.
    +
    –userprovider-endpoint | $STORAGE_USERPROVIDER_ENDPOINT
    +
    endpoint to use for the userprovider service. Default: localhost:9144.
    +
    –storage-root | $STORAGE_METADATA_ROOT
    +
    the path to the metadata storage root. Default: /var/tmp/ocis/storage/metadata.
    +

    storage storage-users

    Start storage-users service

    Usage: storage storage-users [command options] [arguments...]

    @@ -2786,6 +2848,21 @@

    Configuration

    –storage-public-link-mount-path | $STORAGE_PUBLIC_LINK_MOUNT_PATH
    mount path. Default: /public.
    +

    storage auth-basic

    +

    Start authprovider for basic auth

    +

    Usage: storage auth-basic [command options] [arguments...]

    +
    +
    –debug-addr | $STORAGE_AUTH_BASIC_DEBUG_ADDR
    +
    Address to bind debug server. Default: 0.0.0.0:9147.
    +
    –auth-driver | $STORAGE_AUTH_DRIVER
    +
    auth driver: ‘demo’, ‘json’ or ‘ldap’. Default: ldap.
    +
    –auth-json | $STORAGE_AUTH_JSON
    +
    Path to users.json file.
    +
    –network | $STORAGE_AUTH_BASIC_GRPC_NETWORK
    +
    Network to use for the storage auth-basic service, can be ‘tcp’, ‘udp’ or ‘unix’. Default: tcp.
    +
    –addr | $STORAGE_AUTH_BASIC_GRPC_ADDR
    +
    Address to bind storage service. Default: 0.0.0.0:9146.
    +

    storage users

    Start users service

    Usage: storage users [command options] [arguments...]

    @@ -2856,6 +2933,25 @@

    Configuration

    –upload-http-method-override | $STORAGE_FRONTEND_UPLOAD_HTTP_METHOD_OVERRIDE
    Specify an HTTP method (ex: POST) that clients should to use when uploading instead of PATCH.
    +

    storage sharing

    +

    Start sharing service

    +

    Usage: storage sharing [command options] [arguments...]

    +
    +
    –debug-addr | $STORAGE_SHARING_DEBUG_ADDR
    +
    Address to bind debug server. Default: 0.0.0.0:9151.
    +
    –network | $STORAGE_SHARING_GRPC_NETWORK
    +
    Network to use for the storage service, can be ‘tcp’, ‘udp’ or ‘unix’. Default: tcp.
    +
    –addr | $STORAGE_SHARING_GRPC_ADDR
    +
    Address to bind storage service. Default: 0.0.0.0:9150.
    +
    –user-driver | $STORAGE_SHARING_USER_DRIVER
    +
    driver to use for the UserShareProvider. Default: json.
    +
    –user-json-file | $STORAGE_SHARING_USER_JSON_FILE
    +
    file used to persist shares for the UserShareProvider. Default: /var/tmp/ocis/storage/shares.json.
    +
    –public-driver | $STORAGE_SHARING_PUBLIC_DRIVER
    +
    driver to use for the PublicShareProvider. Default: json.
    +
    –public-json-file | $STORAGE_SHARING_PUBLIC_JSON_FILE
    +
    file used to persist shares for the PublicShareProvider. Default: /var/tmp/ocis/storage/publicshares.json.
    +

    storage storage

    Storage service for oCIS

    Usage: storage storage [command options] [arguments...]

    @@ -2869,68 +2965,6 @@

    Configuration

    –log-color | $STORAGE_LOG_COLOR
    Enable colored logging.
    -

    storage storage-home

    -

    Start storage-home service

    -

    Usage: storage storage-home [command options] [arguments...]

    -
    -
    –debug-addr | $STORAGE_HOME_DEBUG_ADDR
    -
    Address to bind debug server. Default: 0.0.0.0:9156.
    -
    –grpc-network | $STORAGE_HOME_GRPC_NETWORK
    -
    Network to use for the storage service, can be ‘tcp’, ‘udp’ or ‘unix’. Default: tcp.
    -
    –grpc-addr | $STORAGE_HOME_GRPC_ADDR
    -
    Address to bind storage service. Default: 0.0.0.0:9154.
    -
    –http-network | $STORAGE_HOME_HTTP_NETWORK
    -
    Network to use for the storage service, can be ‘tcp’, ‘udp’ or ‘unix’. Default: tcp.
    -
    –http-addr | $STORAGE_HOME_HTTP_ADDR
    -
    Address to bind storage service. Default: 0.0.0.0:9155.
    -
    –driver | $STORAGE_HOME_DRIVER
    -
    storage driver for home mount: eg. local, eos, owncloud, ocis or s3. Default: ocis.
    -
    –mount-path | $STORAGE_HOME_MOUNT_PATH
    -
    mount path. Default: /home.
    -
    –mount-id | $STORAGE_HOME_MOUNT_ID
    -
    mount id. Default: 1284d238-aa92-42ce-bdc4-0b0000009157.
    -
    –expose-data-server | $STORAGE_HOME_EXPOSE_DATA_SERVER
    -
    exposes a dedicated data server. Default: false.
    -
    –data-server-url | $STORAGE_HOME_DATA_SERVER_URL
    -
    data server url. Default: http://localhost:9155/data.
    -
    –http-prefix | $STORAGE_HOME_HTTP_PREFIX
    -
    prefix for the http endpoint, without leading slash. Default: data.
    -
    –tmp-folder | $STORAGE_HOME_TMP_FOLDER
    -
    path to tmp folder. Default: /var/tmp/ocis/tmp/home.
    -
    –enable-home | $STORAGE_HOME_ENABLE_HOME
    -
    enable the creation of home directories. Default: true.
    -
    –gateway-endpoint | $STORAGE_GATEWAY_ENDPOINT
    -
    endpoint to use for the storage gateway service. Default: localhost:9142.
    -
    –users-endpoint | $STORAGE_USERPROVIDER_ENDPOINT
    -
    endpoint to use for the storage service. Default: localhost:9144.
    -
    -

    storage storage-metadata

    -

    Start storage-metadata service

    -

    Usage: storage storage-metadata [command options] [arguments...]

    -
    -
    –debug-addr | $STORAGE_METADATA_DEBUG_ADDR
    -
    Address to bind debug server. Default: 0.0.0.0:9217.
    -
    –grpc-network | $STORAGE_METADATA_GRPC_NETWORK
    -
    Network to use for the storage service, can be ‘tcp’, ‘udp’ or ‘unix’. Default: tcp.
    -
    –grpc-addr | $STORAGE_METADATA_GRPC_PROVIDER_ADDR
    -
    Address to bind storage service. Default: 0.0.0.0:9215.
    -
    –data-server-url | $STORAGE_METADATA_DATA_SERVER_URL
    -
    URL of the data-provider the storage-provider uses. Default: http://localhost:9216.
    -
    –http-network | $STORAGE_METADATA_HTTP_NETWORK
    -
    Network to use for the storage service, can be ‘tcp’, ‘udp’ or ‘unix’. Default: tcp.
    -
    –http-addr | $STORAGE_METADATA_HTTP_ADDR
    -
    Address to bind storage service. Default: 0.0.0.0:9216.
    -
    –tmp-folder | $STORAGE_METADATA_TMP_FOLDER
    -
    path to tmp folder. Default: /var/tmp/ocis/tmp/metadata.
    -
    –driver | $STORAGE_METADATA_DRIVER
    -
    storage driver for metadata mount: eg. local, eos, owncloud, ocis or s3. Default: ocis.
    -
    –gateway-endpoint | $STORAGE_GATEWAY_ENDPOINT
    -
    endpoint to use for the gateway service. Default: localhost:9142.
    -
    –userprovider-endpoint | $STORAGE_USERPROVIDER_ENDPOINT
    -
    endpoint to use for the userprovider service. Default: localhost:9144.
    -
    –storage-root | $STORAGE_METADATA_ROOT
    -
    the path to the metadata storage root. Default: /var/tmp/ocis/storage/metadata.
    -

    storage health

    Check health status

    Usage: storage health [command options] [arguments...]

    @@ -2938,40 +2972,6 @@

    Configuration

    –debug-addr | $STORAGE_DEBUG_ADDR
    Address to debug endpoint. Default: 0.0.0.0:9109.
    -

    storage auth-basic

    -

    Start authprovider for basic auth

    -

    Usage: storage auth-basic [command options] [arguments...]

    -
    -
    –debug-addr | $STORAGE_AUTH_BASIC_DEBUG_ADDR
    -
    Address to bind debug server. Default: 0.0.0.0:9147.
    -
    –auth-driver | $STORAGE_AUTH_DRIVER
    -
    auth driver: ‘demo’, ‘json’ or ‘ldap’. Default: ldap.
    -
    –auth-json | $STORAGE_AUTH_JSON
    -
    Path to users.json file.
    -
    –network | $STORAGE_AUTH_BASIC_GRPC_NETWORK
    -
    Network to use for the storage auth-basic service, can be ‘tcp’, ‘udp’ or ‘unix’. Default: tcp.
    -
    –addr | $STORAGE_AUTH_BASIC_GRPC_ADDR
    -
    Address to bind storage service. Default: 0.0.0.0:9146.
    -
    -

    storage sharing

    -

    Start sharing service

    -

    Usage: storage sharing [command options] [arguments...]

    -
    -
    –debug-addr | $STORAGE_SHARING_DEBUG_ADDR
    -
    Address to bind debug server. Default: 0.0.0.0:9151.
    -
    –network | $STORAGE_SHARING_GRPC_NETWORK
    -
    Network to use for the storage service, can be ‘tcp’, ‘udp’ or ‘unix’. Default: tcp.
    -
    –addr | $STORAGE_SHARING_GRPC_ADDR
    -
    Address to bind storage service. Default: 0.0.0.0:9150.
    -
    –user-driver | $STORAGE_SHARING_USER_DRIVER
    -
    driver to use for the UserShareProvider. Default: json.
    -
    –user-json-file | $STORAGE_SHARING_USER_JSON_FILE
    -
    file used to persist shares for the UserShareProvider. Default: /var/tmp/ocis/storage/shares.json.
    -
    –public-driver | $STORAGE_SHARING_PUBLIC_DRIVER
    -
    driver to use for the PublicShareProvider. Default: json.
    -
    –public-json-file | $STORAGE_SHARING_PUBLIC_JSON_FILE
    -
    file used to persist shares for the PublicShareProvider. Default: /var/tmp/ocis/storage/publicshares.json.
    -

    storage auth-bearer

    Start authprovider for bearer auth

    Usage: storage auth-bearer [command options] [arguments...]

    @@ -3124,7 +3124,7 @@

    Configuration

    - + diff --git a/extensions/storage/index.html b/extensions/storage/index.html index e3f8722086b..b030ad5dc52 100644 --- a/extensions/storage/index.html +++ b/extensions/storage/index.html @@ -2799,7 +2799,7 @@

    Storage

    - + diff --git a/extensions/storage/index.xml b/extensions/storage/index.xml index 390930c4f03..a28a57e91f6 100644 --- a/extensions/storage/index.xml +++ b/extensions/storage/index.xml @@ -14,10 +14,10 @@ Configuration https://owncloud.github.io/extensions/storage/configuration/ - Thu, 17 Dec 2020 21:01:25 +0000 + Fri, 18 Dec 2020 01:09:41 +0000 https://owncloud.github.io/extensions/storage/configuration/ - Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands storage storage-users storage storage-public-link storage gateway storage users storage frontend storage storage storage storage-home storage storage-metadata storage health storage auth-basic storage sharing storage auth-bearer Config for the different Storage Drivers Local Driver Eos Driver owCloud Driver Ocis Driver Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: + Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands storage storage-home storage storage-metadata storage storage-users storage storage-public-link storage gateway storage auth-basic storage users storage frontend storage sharing storage storage storage health storage auth-bearer Config for the different Storage Drivers Local Driver Eos Driver owCloud Driver Ocis Driver Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: diff --git a/extensions/storage/releasing/index.html b/extensions/storage/releasing/index.html index 72cece8778f..05b480a2894 100644 --- a/extensions/storage/releasing/index.html +++ b/extensions/storage/releasing/index.html @@ -2699,7 +2699,7 @@

    Releasing

    - + diff --git a/extensions/storage/storages/index.html b/extensions/storage/storages/index.html index 4c03652588e..885937acd88 100644 --- a/extensions/storage/storages/index.html +++ b/extensions/storage/storages/index.html @@ -2874,7 +2874,7 @@

    Storages

    - + diff --git a/extensions/storage/updating/index.html b/extensions/storage/updating/index.html index 062ee3a9ec6..0b45171c631 100644 --- a/extensions/storage/updating/index.html +++ b/extensions/storage/updating/index.html @@ -2690,7 +2690,7 @@

    Updating reva

    - + diff --git a/extensions/storage/users/index.html b/extensions/storage/users/index.html index 19851beab2d..a72c332ae84 100644 --- a/extensions/storage/users/index.html +++ b/extensions/storage/users/index.html @@ -2701,7 +2701,7 @@

    Users

    - + diff --git a/extensions/store/configuration/index.html b/extensions/store/configuration/index.html index 469627fcdfc..53a8999690c 100644 --- a/extensions/store/configuration/index.html +++ b/extensions/store/configuration/index.html @@ -2627,10 +2627,10 @@

    Configuration

  • Configuration using config files
  • Environment variables
  • Commandline flags
    • +
  • store version
  • store health
  • store server
  • store ocis-store
    • -
  • store version
    • @@ -2648,6 +2648,15 @@

    Configuration

    If you prefer to configure the service with environment variables you can see the available variables below.

    Commandline flags

    If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.

    +

    store version

    +

    Print the versions of the running instances

    +

    Usage: store version [command options] [arguments...]

    +
    +
    –grpc-namespace | $STORE_GRPC_NAMESPACE
    +
    Set the base namespace for the grpc namespace. Default: com.owncloud.api.
    +
    –name | $STORE_NAME
    +
    Service name. Default: store.
    +

    store health

    Check health status

    Usage: store health [command options] [arguments...]

    @@ -2696,15 +2705,6 @@

    Configuration

    Enable pretty logging. Default: true.
    –log-color | $STORE_LOG_COLOR
    Enable colored logging. Default: true.
    - -

    store version

    -

    Print the versions of the running instances

    -

    Usage: store version [command options] [arguments...]

    -
    -
    –grpc-namespace | $STORE_GRPC_NAMESPACE
    -
    Set the base namespace for the grpc namespace. Default: com.owncloud.api.
    -
    –name | $STORE_NAME
    -
    Service name. Default: store.
    @@ -2762,7 +2762,7 @@

    Configuration

    - + diff --git a/extensions/store/index.html b/extensions/store/index.html index 43890c2034f..35e39f67b6a 100644 --- a/extensions/store/index.html +++ b/extensions/store/index.html @@ -2668,7 +2668,7 @@

    Store

    - + diff --git a/extensions/store/index.xml b/extensions/store/index.xml index 72d2dce1a42..0ef6026191a 100644 --- a/extensions/store/index.xml +++ b/extensions/store/index.xml @@ -14,10 +14,10 @@ Configuration https://owncloud.github.io/extensions/store/configuration/ - Thu, 17 Dec 2020 21:01:26 +0000 + Fri, 18 Dec 2020 01:09:42 +0000 https://owncloud.github.io/extensions/store/configuration/ - Configuration Configuration using config files Environment variables Commandline flags store health store server store ocis-store store version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: + Configuration Configuration using config files Environment variables Commandline flags store version store health store server store ocis-store Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: /etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. diff --git a/extensions/thumbnails/configuration/index.html b/extensions/thumbnails/configuration/index.html index 9cee40dadff..36bc3b08b8e 100644 --- a/extensions/thumbnails/configuration/index.html +++ b/extensions/thumbnails/configuration/index.html @@ -2627,10 +2627,10 @@

    Configuration

  • Configuration using config files
  • Environment variables
  • Commandline flags
    • -
  • thumbnails version
  • thumbnails health
  • thumbnails server
  • thumbnails ocis-thumbnails
    • +
  • thumbnails version
    • @@ -2648,15 +2648,6 @@

    Configuration

    If you prefer to configure the service with environment variables you can see the available variables below.

    Commandline flags

    If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.

    -

    thumbnails version

    -

    Print the versions of the running instances

    -

    Usage: thumbnails version [command options] [arguments...]

    -
    -
    –grpc-name | $THUMBNAILS_GRPC_NAME
    -
    Name of the service. Default: thumbnails.
    -
    –grpc-namespace | $THUMBNAILS_GRPC_NAMESPACE
    -
    Set the base namespace for the grpc namespace. Default: com.owncloud.api.
    -

    thumbnails health

    Check health status

    Usage: thumbnails health [command options] [arguments...]

    @@ -2711,6 +2702,15 @@

    Configuration

    Enable pretty logging. Default: true.
    –log-color | $THUMBNAILS_LOG_COLOR
    Enable colored logging. Default: true.
    + +

    thumbnails version

    +

    Print the versions of the running instances

    +

    Usage: thumbnails version [command options] [arguments...]

    +
    +
    –grpc-name | $THUMBNAILS_GRPC_NAME
    +
    Name of the service. Default: thumbnails.
    +
    –grpc-namespace | $THUMBNAILS_GRPC_NAMESPACE
    +
    Set the base namespace for the grpc namespace. Default: com.owncloud.api.
    @@ -2768,7 +2768,7 @@

    Configuration

    - + diff --git a/extensions/thumbnails/grpc/index.html b/extensions/thumbnails/grpc/index.html index 869ad39acfd..bee9760467b 100644 --- a/extensions/thumbnails/grpc/index.html +++ b/extensions/thumbnails/grpc/index.html @@ -2943,7 +2943,7 @@

    GRPC API

    - + diff --git a/extensions/thumbnails/index.html b/extensions/thumbnails/index.html index 7a20d90691a..7a9860d6765 100644 --- a/extensions/thumbnails/index.html +++ b/extensions/thumbnails/index.html @@ -2668,7 +2668,7 @@

    Thumbnails

    - + diff --git a/extensions/thumbnails/index.xml b/extensions/thumbnails/index.xml index f4d0c365cc0..9146a9fab30 100644 --- a/extensions/thumbnails/index.xml +++ b/extensions/thumbnails/index.xml @@ -14,10 +14,10 @@ Configuration https://owncloud.github.io/extensions/thumbnails/configuration/ - Thu, 17 Dec 2020 21:01:27 +0000 + Fri, 18 Dec 2020 01:09:43 +0000 https://owncloud.github.io/extensions/thumbnails/configuration/ - Configuration Configuration using config files Environment variables Commandline flags thumbnails version thumbnails health thumbnails server thumbnails ocis-thumbnails Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: + Configuration Configuration using config files Environment variables Commandline flags thumbnails health thumbnails server thumbnails ocis-thumbnails thumbnails version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: /etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. diff --git a/extensions/web/configuration/index.html b/extensions/web/configuration/index.html index b2692a98f74..3d2373f9668 100644 --- a/extensions/web/configuration/index.html +++ b/extensions/web/configuration/index.html @@ -2777,7 +2777,7 @@

    Configuration

    - + diff --git a/extensions/web/index.html b/extensions/web/index.html index 9fd7ce265ac..6d67e36b3b8 100644 --- a/extensions/web/index.html +++ b/extensions/web/index.html @@ -2668,7 +2668,7 @@

    ownCloud Web

    - + diff --git a/extensions/web/index.xml b/extensions/web/index.xml index a0d37b2d70c..6a765476890 100644 --- a/extensions/web/index.xml +++ b/extensions/web/index.xml @@ -14,7 +14,7 @@ Configuration https://owncloud.github.io/extensions/web/configuration/ - Thu, 17 Dec 2020 21:01:22 +0000 + Fri, 18 Dec 2020 01:09:37 +0000 https://owncloud.github.io/extensions/web/configuration/ Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands web health web server Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: diff --git a/extensions/web/releasing/index.html b/extensions/web/releasing/index.html index 20510295f3d..cb194da5d16 100644 --- a/extensions/web/releasing/index.html +++ b/extensions/web/releasing/index.html @@ -2725,7 +2725,7 @@

    Releasing

    - + diff --git a/extensions/webdav/configuration/index.html b/extensions/webdav/configuration/index.html index e9bdbc30976..a8295275738 100644 --- a/extensions/webdav/configuration/index.html +++ b/extensions/webdav/configuration/index.html @@ -2632,9 +2632,9 @@

    Configuration

  • Root Command
  • Sub Commands
    • @@ -2664,15 +2664,6 @@

    Configuration

    Enable colored logging. Default: true.

    Sub Commands

    -

    webdav version

    -

    Print the versions of the running instances

    -

    Usage: webdav version [command options] [arguments...]

    -
    -
    –http-namespace | $WEBDAV_HTTP_NAMESPACE
    -
    Set the base namespace for service discovery. Default: com.owncloud.web.
    -
    –service-name | $WEBDAV_SERVICE_NAME
    -
    Service name. Default: webdav.
    -

    webdav health

    Check health status

    Usage: webdav health [command options] [arguments...]

    @@ -2712,6 +2703,15 @@

    Configuration

    Service name. Default: webdav.
    –http-root | $WEBDAV_HTTP_ROOT
    Root path of http server. Default: /.
    + +

    webdav version

    +

    Print the versions of the running instances

    +

    Usage: webdav version [command options] [arguments...]

    +
    +
    –http-namespace | $WEBDAV_HTTP_NAMESPACE
    +
    Set the base namespace for service discovery. Default: com.owncloud.web.
    +
    –service-name | $WEBDAV_SERVICE_NAME
    +
    Service name. Default: webdav.
    @@ -2769,7 +2769,7 @@

    Configuration

    - + diff --git a/extensions/webdav/index.html b/extensions/webdav/index.html index 6530c9587d0..32bd0ba8383 100644 --- a/extensions/webdav/index.html +++ b/extensions/webdav/index.html @@ -2668,7 +2668,7 @@

    WebDaV

    - + diff --git a/extensions/webdav/index.xml b/extensions/webdav/index.xml index 9bac27c87b0..c37d62586bf 100644 --- a/extensions/webdav/index.xml +++ b/extensions/webdav/index.xml @@ -14,10 +14,10 @@ Configuration https://owncloud.github.io/extensions/webdav/configuration/ - Thu, 17 Dec 2020 21:01:28 +0000 + Fri, 18 Dec 2020 01:09:44 +0000 https://owncloud.github.io/extensions/webdav/configuration/ - Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands webdav version webdav health webdav server Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: + Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands webdav health webdav server webdav version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: /etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. diff --git a/index.html b/index.html index f839d9c693b..912733dfced 100644 --- a/index.html +++ b/index.html @@ -2681,7 +2681,7 @@

    ownCloud

    - + diff --git a/index.xml b/index.xml index d1a6c30b9d0..dd26b726c03 100644 --- a/index.xml +++ b/index.xml @@ -6,7 +6,7 @@ Recent content on ownCloud Hugo -- gohugo.io en-us - Thu, 17 Dec 2020 21:01:29 +0000 + Fri, 18 Dec 2020 01:09:45 +0000 @@ -24,10 +24,10 @@ Depending on your setup, the name of apps-external folder can vary. It is import Configuration https://owncloud.github.io/ocis/configuration/ - Thu, 17 Dec 2020 21:01:21 +0000 + Fri, 18 Dec 2020 01:09:36 +0000 https://owncloud.github.io/ocis/configuration/ - Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands ocis run ocis server ocis list ocis health ocis kill List of available Extension subcommands ocis thumbnails ocis ocs ocis version ocis storage-gateway ocis storage-auth-basic ocis glauth ocis konnectd ocis webdav ocis storage-frontend ocis storage-home ocis storage-metadata ocis onlyoffice ocis storage-users ocis web ocis storage-userprovider ocis store ocis settings ocis storage-public-link ocis storage-auth-bearer ocis proxy ocis accounts ocis storage-sharing Configuration oCIS Single Binary is not responsible for configuring extensions. + Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands ocis list ocis run ocis health ocis server ocis kill List of available Extension subcommands ocis accounts ocis thumbnails ocis webdav ocis settings ocis storage-metadata ocis storage-userprovider ocis konnectd ocis store ocis ocs ocis storage-auth-bearer ocis storage-users ocis storage-sharing ocis glauth ocis proxy ocis web ocis storage-frontend ocis onlyoffice ocis storage-home ocis version ocis storage-public-link ocis storage-gateway ocis storage-auth-basic Configuration oCIS Single Binary is not responsible for configuring extensions. @@ -113,7 +113,7 @@ If you need to access ocis on a VM or a remote machine e.g. when testing a mobil Configuration https://owncloud.github.io/extensions/onlyoffice/configuration/ - Thu, 17 Dec 2020 21:01:29 +0000 + Fri, 18 Dec 2020 01:09:45 +0000 https://owncloud.github.io/extensions/onlyoffice/configuration/ Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands onlyoffice server onlyoffice health Configuration oCIS Single Binary is not responsible for configuring extensions. Instead, each extension could either be configured by environment variables, cli flags or config files. @@ -123,56 +123,56 @@ Each extension has its dedicated documentation page (e.g. https://owncloud.githu Configuration https://owncloud.github.io/extensions/webdav/configuration/ - Thu, 17 Dec 2020 21:01:28 +0000 + Fri, 18 Dec 2020 01:09:44 +0000 https://owncloud.github.io/extensions/webdav/configuration/ - Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands webdav version webdav health webdav server Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: + Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands webdav health webdav server webdav version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: /etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. Configuration https://owncloud.github.io/extensions/thumbnails/configuration/ - Thu, 17 Dec 2020 21:01:27 +0000 + Fri, 18 Dec 2020 01:09:43 +0000 https://owncloud.github.io/extensions/thumbnails/configuration/ - Configuration Configuration using config files Environment variables Commandline flags thumbnails version thumbnails health thumbnails server thumbnails ocis-thumbnails Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: + Configuration Configuration using config files Environment variables Commandline flags thumbnails health thumbnails server thumbnails ocis-thumbnails thumbnails version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: /etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. Configuration https://owncloud.github.io/extensions/store/configuration/ - Thu, 17 Dec 2020 21:01:26 +0000 + Fri, 18 Dec 2020 01:09:42 +0000 https://owncloud.github.io/extensions/store/configuration/ - Configuration Configuration using config files Environment variables Commandline flags store health store server store ocis-store store version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: + Configuration Configuration using config files Environment variables Commandline flags store version store health store server store ocis-store Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: /etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. Configuration - https://owncloud.github.io/extensions/settings/configuration/ - Thu, 17 Dec 2020 21:01:25 +0000 + https://owncloud.github.io/extensions/storage/configuration/ + Fri, 18 Dec 2020 01:09:41 +0000 - https://owncloud.github.io/extensions/settings/configuration/ - Configuration Configuration using config files Environment variables Commandline flags settings health settings server settings ocis-settings settings version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: -/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. + https://owncloud.github.io/extensions/storage/configuration/ + Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands storage storage-home storage storage-metadata storage storage-users storage storage-public-link storage gateway storage auth-basic storage users storage frontend storage sharing storage storage storage health storage auth-bearer Config for the different Storage Drivers Local Driver Eos Driver owCloud Driver Ocis Driver Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: Configuration - https://owncloud.github.io/extensions/storage/configuration/ - Thu, 17 Dec 2020 21:01:25 +0000 + https://owncloud.github.io/extensions/settings/configuration/ + Fri, 18 Dec 2020 01:09:40 +0000 - https://owncloud.github.io/extensions/storage/configuration/ - Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands storage storage-users storage storage-public-link storage gateway storage users storage frontend storage storage storage storage-home storage storage-metadata storage health storage auth-basic storage sharing storage auth-bearer Config for the different Storage Drivers Local Driver Eos Driver owCloud Driver Ocis Driver Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: + https://owncloud.github.io/extensions/settings/configuration/ + Configuration Configuration using config files Environment variables Commandline flags settings server settings ocis-settings settings version settings health Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: +/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. Configuration https://owncloud.github.io/extensions/proxy/configuration/ - Thu, 17 Dec 2020 21:01:24 +0000 + Fri, 18 Dec 2020 01:09:39 +0000 https://owncloud.github.io/extensions/proxy/configuration/ Configuration Configuration using config files Environment variables Commandline flags proxy health proxy server proxy ocis-proxy proxy version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: @@ -182,7 +182,7 @@ Each extension has its dedicated documentation page (e.g. https://owncloud.githu Configuration https://owncloud.github.io/extensions/ocs/configuration/ - Thu, 17 Dec 2020 21:01:23 +0000 + Fri, 18 Dec 2020 01:09:38 +0000 https://owncloud.github.io/extensions/ocs/configuration/ Configuration Configuration using config files Environment variables Commandline flags ocs health ocs server ocs ocis-ocs ocs version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: @@ -192,7 +192,7 @@ Each extension has its dedicated documentation page (e.g. https://owncloud.githu Configuration https://owncloud.github.io/extensions/web/configuration/ - Thu, 17 Dec 2020 21:01:22 +0000 + Fri, 18 Dec 2020 01:09:37 +0000 https://owncloud.github.io/extensions/web/configuration/ Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands web health web server Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: @@ -202,17 +202,17 @@ Each extension has its dedicated documentation page (e.g. https://owncloud.githu Configuration https://owncloud.github.io/extensions/konnectd/configuration/ - Thu, 17 Dec 2020 21:01:19 +0000 + Fri, 18 Dec 2020 01:09:34 +0000 https://owncloud.github.io/extensions/konnectd/configuration/ - Configuration Configuration using config files Environment variables Commandline flags konnectd version konnectd health konnectd server konnectd ocis-konnectd Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: + Configuration Configuration using config files Environment variables Commandline flags konnectd server konnectd ocis-konnectd konnectd version konnectd health Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: /etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. Configuration https://owncloud.github.io/extensions/glauth/configuration/ - Thu, 17 Dec 2020 21:01:17 +0000 + Fri, 18 Dec 2020 01:09:33 +0000 https://owncloud.github.io/extensions/glauth/configuration/ Configuration Configuration using config files Environment variables Commandline flags glauth health glauth server glauth ocis-glauth Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: @@ -222,10 +222,10 @@ Each extension has its dedicated documentation page (e.g. https://owncloud.githu Configuration https://owncloud.github.io/extensions/accounts/configuration/ - Thu, 17 Dec 2020 21:01:15 +0000 + Fri, 18 Dec 2020 01:09:31 +0000 https://owncloud.github.io/extensions/accounts/configuration/ - Configuration Configuration using config files Environment variables Commandline flags accounts server accounts add accounts list accounts version accounts update accounts remove accounts rebuildIndex accounts ocis-accounts accounts inspect Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: + Configuration Configuration using config files Environment variables Commandline flags accounts version accounts update accounts remove accounts server accounts add accounts list accounts rebuildIndex accounts ocis-accounts accounts inspect Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from: /etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. diff --git a/integration/file_picker/accessing-resources/index.html b/integration/file_picker/accessing-resources/index.html index 802ad46a215..d2df34279ca 100644 --- a/integration/file_picker/accessing-resources/index.html +++ b/integration/file_picker/accessing-resources/index.html @@ -2694,7 +2694,7 @@

    Accessing Resources

    - + diff --git a/integration/file_picker/getting-started/index.html b/integration/file_picker/getting-started/index.html index 7764057e1b2..49c2e7bc80d 100644 --- a/integration/file_picker/getting-started/index.html +++ b/integration/file_picker/getting-started/index.html @@ -2694,7 +2694,7 @@

    Getting Started

    - + diff --git a/integration/file_picker/index.html b/integration/file_picker/index.html index f93f7ea13fd..b023d01a365 100644 --- a/integration/file_picker/index.html +++ b/integration/file_picker/index.html @@ -2668,7 +2668,7 @@

    File Picker

    - + diff --git a/integration/file_picker/installation/index.html b/integration/file_picker/installation/index.html index 6e12daa40f4..73c075ddb4f 100644 --- a/integration/file_picker/installation/index.html +++ b/integration/file_picker/installation/index.html @@ -2746,7 +2746,7 @@

    Installation

    - + diff --git a/integration/index.html b/integration/index.html index 1a519672fe8..2c557f56008 100644 --- a/integration/index.html +++ b/integration/index.html @@ -2653,7 +2653,7 @@

    Integrations

    - + diff --git a/js/en.search-data.min.3ccf11e25ef498d481a7400a165ad118b95ffbc2521983e042421266b9a4e057.js b/js/en.search-data.min.3ccf11e25ef498d481a7400a165ad118b95ffbc2521983e042421266b9a4e057.js deleted file mode 100644 index fbfb8bcab0d..00000000000 --- a/js/en.search-data.min.3ccf11e25ef498d481a7400a165ad118b95ffbc2521983e042421266b9a4e057.js +++ /dev/null @@ -1 +0,0 @@ -'use strict';(function(){const indexCfg={};indexCfg.doc={id:'id',field:['title','content'],store:['title','href','parent'],};const index=FlexSearch.create(indexCfg);window.geekdocSearchIndex=index;index.add({'id':0,'href':'/clients/web/','title':"ownCloud Web",'parent':"Clients",'content':"This is the next generation ownCloud frontend.\n"});index.add({'id':1,'href':'/ocis/','title':"oCIS - ownCloud Infinite Scale",'parent':"ownCloud",'content':" ownCloud Infinite Scale Welcome to oCIS, the modern file-sync and share platform, which is based on our knowledge and experience with the PHP based ownCloud server.\noCIS server The oCIS server implementation follows Go best practices and is based on the go-micro framework and REVA. We love and stick to 12 Factor. oCIS is a micro-service based server, which allows scale-out of individual services to meet your specific performance requirements. We run a huge test suite, which was originated in ownCloud 10 and continues to grow.\nArchitecture Overview document.addEventListener(\"DOMContentLoaded\", function(event) { mermaid.initialize({ flowchart: { useMaxWidth: true } }); }); graph TD proxy -- konnectd \u0026 web \u0026 thumbnails \u0026 ocs \u0026 webdav \u0026 storage \u0026 accounts \u0026 store \u0026 settings konnectd -- glauth storage -- REVA "});index.add({'id':2,'href':'/integration/file_picker/','title':"File Picker",'parent':"Integrations",'content':"Easily integrate ownCloud into your own product.\n"});index.add({'id':3,'href':'/clients/web/deployments/oc10-app/','title':"Deploy as an app in ownCloud 10",'parent':"Deployments",'content':" Prerequisites Deploying ownCloud Web Configure oauth2 Configure ownCloud 10 Configure ownCloud Web Accessing ownCloud Web The ownCloud Web is being deployed as an app to ownCloud marketplace to enable easy early integration into existing ownCloud 10 instances. After completing this setup, ownCloud Web will be available on https://\u0026lt;your-owncloud-server\u0026gt;/apps-external/web.\nDepending on your setup, the name of apps-external folder can vary. It is important to use the correct name in all of the mentioned URLs. Prerequisites Running ownCloud 10 server with version 10.6 Installed oauth2 app Deploying ownCloud Web Download ownCloud Web app from the marketplace and enable it.\nConfigure oauth2 In the Admin of ownCloud 10, head into User Authentication and add a new client with arbitrary name and redirection URL https://\u0026lt;your-owncloud-server\u0026gt;/apps-external/web/oidc-callback.html.\n Configure ownCloud 10 To display ownCloud Web in the app switcher and to redirect all private and public links to the new WebUI, add the following config into config/config.php:\n\u0026#39;web.baseUrl\u0026#39; =\u0026gt; \u0026#39;https://\u0026lt;your-owncloud-server\u0026gt;/apps-external/web\u0026#39;, Configure ownCloud Web There are a few config values which need to be set in order for ownCloud Web to work correctly. Navigate into apps-external/web and adjust config.json according to the following example:\n{ \u0026#34;server\u0026#34; : \u0026#34;https://\u0026lt;your-owncloud-server\u0026gt;\u0026#34;, // ownCloud 10 server address \u0026#34;theme\u0026#34;: \u0026#34;owncloud\u0026#34;, // Theme to be used in ownCloud Web pointing to a json file inside of `themes` folder \u0026#34;auth\u0026#34;: { \u0026#34;clientId\u0026#34;: \u0026#34;\u0026lt;client-id-from-oauth2\u0026gt;\u0026#34;, // Client ID received when adding ownCloud Web in the `User Authentication` section in `Admin` \u0026#34;url\u0026#34;: \u0026#34;https://\u0026lt;your-owncloud-server\u0026gt;/index.php/apps/oauth2/api/v1/token\u0026#34;, \u0026#34;authUrl\u0026#34;: \u0026#34;https://\u0026lt;your-owncloud-server\u0026gt;/index.php/apps/oauth2/authorize\u0026#34; }, \u0026#34;apps\u0026#34; : [ // List of extensions to be loaded \u0026#34;files\u0026#34; ], \u0026#34;applications\u0026#34; : [ // Apps to be displayed in the application switcher or in the user menu { \u0026#34;title\u0026#34;: { // Item in apps switcher pointing to the old ownCloud UI \u0026#34;en\u0026#34;: \u0026#34;Classic Design\u0026#34;, \u0026#34;de\u0026#34;: \u0026#34;Dateien\u0026#34;, \u0026#34;fr\u0026#34;: \u0026#34;Fichiers\u0026#34;, \u0026#34;zh_CN\u0026#34;: \u0026#34;文件\u0026#34; }, \u0026#34;icon\u0026#34;: \u0026#34;switch_ui\u0026#34;, \u0026#34;url\u0026#34;: \u0026#34;http://\u0026lt;your-owncloud-server\u0026gt;/index.php/apps/files\u0026#34; }, { // Item in user menu pointing to user settings in the old ownCloud UI \u0026#34;icon\u0026#34;: \u0026#34;application\u0026#34;, \u0026#34;menu\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;target\u0026#34;: \u0026#34;_self\u0026#34;, \u0026#34;title\u0026#34;: { \u0026#34;de\u0026#34;: \u0026#34;Einstellungen\u0026#34;, \u0026#34;en\u0026#34;: \u0026#34;Settings\u0026#34; }, \u0026#34;url\u0026#34;: \u0026#34;https://\u0026lt;your-owncloud-server\u0026gt;/index.php/settings/personal\u0026#34; } ] } Accessing ownCloud Web After following all the steps, you should see a new entry in the application switcher called New Design which points to the ownCloud web.\n "});index.add({'id':4,'href':'/ocis/configuration/','title':"Configuration",'parent':"oCIS - ownCloud Infinite Scale",'content':" Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands ocis run ocis server ocis list ocis health ocis kill List of available Extension subcommands ocis thumbnails ocis ocs ocis version ocis storage-gateway ocis storage-auth-basic ocis glauth ocis konnectd ocis webdav ocis storage-frontend ocis storage-home ocis storage-metadata ocis onlyoffice ocis storage-users ocis web ocis storage-userprovider ocis store ocis settings ocis storage-public-link ocis storage-auth-bearer ocis proxy ocis accounts ocis storage-sharing Configuration oCIS Single Binary is not responsible for configuring extensions. Instead, each extension could either be configured by environment variables, cli flags or config files.\nEach extension has its dedicated documentation page (e.g. proxy configuration) which lists all possible configurations. Config files and environment variables are picked up if you use the ./bin/ocis server command within the oCIS single binary. Command line flags must be set explicitly on the extensions subcommands.\nConfiguration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-proxy reads proxy.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nRoot Command ownCloud Infinite Scale Stack\nUsage: ocis [global options] command [command options] [arguments...]\n \u0026ndash;config-file | $OCIS_CONFIG_FILE Path to config file. \u0026ndash;log-level | $OCIS_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $OCIS_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $OCIS_LOG_COLOR Enable colored logging. Default: true. \u0026ndash;tracing-enabled | $OCIS_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $OCIS_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $OCIS_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $OCIS_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $OCIS_TRACING_SERVICE Service name for tracing. Default: ocis. \u0026ndash;jwt-secret | $OCIS_JWT_SECRET Used to dismantle the access token, should equal reva\u0026rsquo;s jwt-secret. Default: Pive-Fumkiu4. Sub Commands ocis run Runs an extension\nUsage: ocis run [command options] [arguments...]\nocis server Start fullstack server\nUsage: ocis server [command options] [arguments...]\n \u0026ndash;debug-addr | $OCIS_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9010. \u0026ndash;debug-token | $OCIS_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $OCIS_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $OCIS_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $OCIS_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9000. \u0026ndash;http-root | $OCIS_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;grpc-addr | $OCIS_GRPC_ADDR Address to bind grpc server. Default: 0.0.0.0:9001. ocis list Lists running ocis extensions\nUsage: ocis list [command options] [arguments...]\nocis health Check health status\nUsage: ocis health [command options] [arguments...]\n \u0026ndash;debug-addr | $OCIS_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9010. ocis kill Kill an extension by name\nUsage: ocis kill [command options] [arguments...]\nList of available Extension subcommands There are more subcommands to start the individual extensions. Please check the documentation about their usage and options in the dedicated section of the documentation.\nocis thumbnails Start thumbnails server\nocis ocs Start ocs server\nocis version Lists running services with version\nocis storage-gateway Start storage gateway\nocis storage-auth-basic Start storage auth-basic service\nocis glauth Start glauth server\nocis konnectd Start konnectd server\nocis webdav Start webdav server\nocis storage-frontend Start storage frontend\nocis storage-home Start storage and data provider for /home mount\nocis storage-metadata Start storage and data service for metadata\nocis onlyoffice Start onlyoffice server\nocis storage-users Start storage and data provider for /users mount\nocis web Start web server\nocis storage-userprovider Start storage userprovider service\nocis store Start a go-micro store\nocis settings Start settings server\nocis storage-public-link Start storage public link storage\nocis storage-auth-bearer Start storage auth-bearer service\nocis proxy Start proxy server\nocis accounts Start accounts server\nocis storage-sharing Start storage sharing service\n"});index.add({'id':5,'href':'/integration/file_picker/getting-started/','title':"Getting Started",'parent':"File Picker",'content':" Components of the File picker File picker Location picker ownCloud File picker is a web component which can be integrated into existing web applications. It connects to an ownCloud server and enables a user to select resources which are then provided in a response of a fired event. Visit installation to see how to integrate the File picker into your product.\nComponents of the File picker The file picker can be used in two different variations: File picker and location picker.\nFile picker The file picker enables users to select multiple resources and is intended to bring resources from within ownCloud into your web applications.\nLocation picker The location picker allows only one folder to be selected and its main purpose is to enable users to save files into the connected ownCloud instance.\n"});index.add({'id':6,'href':'/integration/file_picker/installation/','title':"Installation",'parent':"File Picker",'content':" Setup authorization Install File picker package Integrate in HTML page with vanilla JavaScript Integrate in Vue web application Set correct variation Pass bearer token Setup authorization The config for authorization is provided via a json file. Location of the file can be provided via a prop called configLocation. This requires full URL address (e.g. https://\u0026lt;your-server\u0026gt;/\u0026lt;path-to-the-config\u0026gt;). If the prop is not defined, the location will fallback to https://\u0026lt;your-server\u0026gt;/file-picker-config.json. The config can point to both oauth2 and OIDC. You can take a look at the following example to see how OIDC can be defined:\n{ \u0026#34;server\u0026#34;: \u0026#34;\u0026lt;owncloud-server\u0026gt;\u0026#34;, \u0026#34;openIdConnect\u0026#34;: { \u0026#34;metadata_url\u0026#34;: \u0026#34;\u0026lt;your-server\u0026gt;/.well-known/openid-configuration\u0026#34;, \u0026#34;authority\u0026#34;: \u0026#34;\u0026lt;your-server\u0026gt;\u0026#34;, \u0026#34;client_id\u0026#34;: \u0026#34;\u0026lt;client-id\u0026gt;\u0026#34;, \u0026#34;response_type\u0026#34;: \u0026#34;code\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;openid profile email\u0026#34; }, } Install File picker package To integrate File picker into your own product, you can install it via one of the following commands:\nnpm install @ownclouders/file-picker --save # OR yarn add @ownclouders/file-picker Integrate in HTML page with vanilla JavaScript When including File picker in an HTML page, it is important to include Vue.js as well. In this case, we will import it via unpkg. Without this, the component won\u0026rsquo;t work. Vue needs to be included also if you\u0026rsquo;re importing the File picker into a web application built with other framework than Vue (e.g. React, Angular).\nFor the purpose of this example, we will assume that you do not move installed packages and include the folder \u0026ldquo;node_modules\u0026rdquo; with installed packages in the same location as your index.html file on your server.\n... \u0026lt;meta charset=\u0026#34;utf-8\u0026#34;\u0026gt; \u0026lt;title\u0026gt;File picker example\u0026lt;/title\u0026gt; \u0026lt;script src=\u0026#34;https://unpkg.com/vue\u0026#34;\u0026gt;\u0026lt;/script\u0026gt; \u0026lt;script src=\u0026#34;./node_modules/file-picker/dist/file-picker.js\u0026#34;\u0026gt;\u0026lt;/script\u0026gt; ... \u0026lt;file-picker id=\u0026#34;file-picker\u0026#34; variation=\u0026#34;resource\u0026#34;\u0026gt;\u0026lt;/file-picker\u0026gt; Integrate in Vue web application There is a caveat when using the File picker inside an existing Vue application. Since the web component will be imported before Vue, we need to define it as a global variable on our own. This requires us to separate the import of Vue into a bootstrap file.\nvue.js:\nimport Vue from \u0026#39;vue\u0026#39; window.Vue = Vue main.js:\nimport Vue from \u0026#39;./vue\u0026#39; new Vue(...) When importing the component, we need to reach it under the .default key.\n\u0026lt;template\u0026gt; \u0026lt;file-picker variation=\u0026#34;location\u0026#34; /\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script\u0026gt; export default: { components: { FilePicker: require(\u0026#39;@owncloud/file-picker\u0026#39;).default } } \u0026lt;/script\u0026gt; Set correct variation As described in Getting Started, File picker comes in two variations. To define which one should be used, you need to pass it to the component via its variation property. Valid values are:\n resource - File picker location - Location picker Pass bearer token In case you already have a bearer token and want to skip the whole authorization process inside of the File picker, you can pass it to the component via prop called bearerToken.\n"});index.add({'id':7,'href':'/integration/file_picker/accessing-resources/','title':"Accessing Resources",'parent':"File Picker",'content':" Access resources File picker is returning selected resources via event called selectResources. To access them, you need to set an event listener where you\u0026rsquo;ll be able to get them as part of the response of the callback function.\nAccess resources \u0026lt;file-picker id=\u0026#34;file-picker\u0026#34; variation=\u0026#34;resource\u0026#34;\u0026gt;\u0026lt;/file-picker\u0026gt; \u0026lt;script\u0026gt; const item = document.getElementById(\u0026#39;file-picker\u0026#39;) let resources = [] item.addEventListener(\u0026#39;selectResources\u0026#39;, event =\u0026gt; { resources = event.detail[0] }) \u0026lt;/script\u0026gt; "});index.add({'id':8,'href':'/ocis/deployment/preparing_server/','title':"Preparing a server",'parent':"Deployment",'content':" Example for Hetzner Cloud Example for Hetzner Cloud create server on Hetzner Cloud. Set labels \u0026ldquo;owner\u0026rdquo; and \u0026ldquo;for\u0026rdquo;. Example for hcloud cli: hcloud server create --type cx21 --image ubuntu-20.04 --ssh-key admin --name ocis-server --label owner=admin --label for=testing\n Configure DNS A-records for needed domains pointing on the servers ip address, for example in CloudFlare\n Access server via ssh as root\n Create a new user\n$ adduser --disabled-password --gecos \u0026quot;\u0026quot; admin\n Add user to sudo group\n$ usermod -aG sudo admin\n Install docker\napt update apt install docker.io Add user to docker group\nusermod -aG docker admin\n Install docker-compose via\ncurl -L \u0026quot;https://github.com/docker/compose/releases/download/1.27.4/docker-compose-$(uname -s)-$(uname -m)\u0026quot; -o /usr/local/bin/docker-compose\n(docker compose version 1.27.4 as of today)\n Make docker-compose executable\nchmod +x /usr/local/bin/docker-compose\n Add users pub key to\nmkdir /home/admin/.ssh echo \u0026#34;\u0026lt;pubkey\u0026gt;\u0026#34; \u0026gt;\u0026gt; /home/admin/.ssh/authorized_keys` chown admin:admin -R /home/admin/.ssh Secure ssh daemon by editing /etc/ssh/sshd_config\nPermitRootLogin no ChallengeResponseAuthentication no PasswordAuthentication no UsePAM no restart sshd server to apply settings systemctl restart sshd\n Login as the user you created\n "});index.add({'id':9,'href':'/ocis/development/','title':"Development",'parent':"oCIS - ownCloud Infinite Scale",'content':""});index.add({'id':10,'href':'/clients/web/getting-started/','title':"Getting Started",'parent':"ownCloud Web",'content':" Installation Docker Binaries Source code Configuration Options Setting up backend and running Running Installation Docker TBD\nBinaries TBD\nSource code The source code is hosted at https://github.com/owncloud/web Please refer to the build documentation for Web.\nConfiguration Depending on the backend you are using, there are sample config files provided in the ownCloud Web git repository. Please refer to the configuration details below.\nOptions options.hideSearchBar Lets you hide the search bar at the top of the screen for all users. options.homeFolder You can specify a folder that is used when the user navigates home. Navigating home gets triggered by clicking on the All files menu item. The user will not be jailed in that directory. It simply serves as a default location. You can either provide a static location, or you can use variables of the user object to come up with a user specific home path. This uses twig template variable style and allows you to pick a value or a substring of a value of the authenticated user. Examples are /Shares, /{{.Id}} and /{{substr 0 3 .Id}}/{{.Id}. options.disablePreviews Set this option to true to disable previews in all the different file listing views. The only list view that is not affected by this is the trash bin, as that doesn\u0026rsquo;t allow showing previews at all. Setting up backend and running Web can run against either ownCloud 10 as backend or OCIS. Depending which one you chose, please check the matching section:\n Setting up with ownCloud as backend Setting up with OCIS as backend Running Running with ownCloud as backend Running with OCIS as backend "});index.add({'id':11,'href':'/extensions/ocis_hello/getting-started/','title':"Getting Started",'parent':"Hello",'content':" Installation Docker Binaries Configuration Envrionment variables Global Server Health Commandline flags Global Server Health Configuration file Usage Server Health Metrics Installation So far we are offering two different variants for the installation. You can choose between Docker or pre-built binaries which are stored on our download mirrors and GitHub releases. Maybe we will also provide system packages for the major distributions later if we see the need for it.\nDocker TBD\nBinaries TBD\nConfiguration We provide overall three different variants of configuration. The variant based on environment variables and commandline flags are split up into global values and command-specific values.\nEnvrionment variables If you prefer to configure the service with environment variables you can see the available variables below.\nGlobal HELLO_CONFIG_FILE Path to config file, empty default value HELLO_LOG_LEVEL Set logging level, defaults to info HELLO_LOG_COLOR Enable colored logging, defaults to true HELLO_LOG_PRETTY Enable pretty logging, defaults to true Server HELLO_TRACING_ENABLED Enable sending traces, defaults to false HELLO_TRACING_TYPE Tracing backend type, defaults to jaeger HELLO_TRACING_ENDPOINT Endpoint for the agent, empty default value HELLO_TRACING_COLLECTOR Endpoint for the collector, empty default value HELLO_TRACING_SERVICE Service name for tracing, defaults to hello HELLO_DEBUG_ADDR Address to bind debug server, defaults to 0.0.0.0:9109 HELLO_DEBUG_TOKEN Token to grant metrics access, empty default value HELLO_DEBUG_PPROF Enable pprof debugging, defaults to false HELLO_DEBUG_ZPAGES Enable zpages debugging, defaults to false HELLO_HTTP_ADDR Address to bind http server, defaults to 0.0.0.0:9105 HELLO_HTTP_ROOT Root path of http server, defaults to / HELLO_GRPC_ADDR Address to bind grpc server, defaults to 0.0.0.0:9106 HELLO_ASSET_PATH Path to custom assets, empty default value Health HELLO_DEBUG_ADDR Address to debug endpoint, defaults to 0.0.0.0:9109 Commandline flags If you prefer to configure the service with commandline flags you can see the available variables below.\nGlobal \u0026ndash;config-file Path to config file, empty default value \u0026ndash;log-level Set logging level, defaults to info \u0026ndash;log-color Enable colored logging, defaults to true \u0026ndash;log-pretty Enable pretty logging, defaults to true Server \u0026ndash;tracing-enabled Enable sending traces, defaults to false \u0026ndash;tracing-type Tracing backend type, defaults to jaeger \u0026ndash;tracing-endpoint Endpoint for the agent, empty default value \u0026ndash;tracing-collector Endpoint for the collector, empty default value \u0026ndash;tracing-service Service name for tracing, defaults to hello \u0026ndash;debug-addr Address to bind debug server, defaults to 0.0.0.0:9109 \u0026ndash;debug-token Token to grant metrics access, empty default value \u0026ndash;debug-pprof Enable pprof debugging, defaults to false \u0026ndash;debug-zpages Enable zpages debugging, defaults to false \u0026ndash;http-addr Address to bind http server, defaults to 0.0.0.0:9105 \u0026ndash;http-root Root path of http server, defaults to / \u0026ndash;grpc-addr Address to bind grpc server, defaults to 0.0.0.0:9106 \u0026ndash;asset-path Path to custom assets, empty default value Health \u0026ndash;debug-addr Address to debug endpoint, defaults to 0.0.0.0:9109 Configuration file So far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/hello.yml, ${HOME}/.ocis/hello.yml or $(pwd)/config/hello.yml.\nUsage The program provides a few sub-commands on execution. The available configuration methods have already been mentioned above. Generally you can always see a formated help output if you execute the binary via ocis-hello --help.\nServer The server command is used to start the http and debug server on two addresses within a single process. The http server is serving the general webservice while the debug server is used for health check, readiness check and to server the metrics mentioned below. For further help please execute:\nocis-hello server --help Health The health command is used to execute a health check, if the exit code equals zero the service should be up and running, if the exist code is greater than zero the service is not in a healthy state. Generally this command is used within our Docker containers, it could also be used within Kubernetes.\nocis-hello health --help Metrics This service provides some Prometheus metrics through the debug endpoint, you can optionally secure the metrics endpoint by some random token, which got to be configured through one of the flag --debug-token or the environment variable HELLO_DEBUG_TOKEN mentioned above. By default the metrics endpoint is bound to http://0.0.0.0:9109/metrics.\n go_gc_duration_seconds A summary of the GC invocation durations go_gc_duration_seconds_sum A summary of the GC invocation durations go_gc_duration_seconds_count A summary of the GC invocation durations go_goroutines Number of goroutines that currently exist go_info Information about the Go environment go_memstats_alloc_bytes Number of bytes allocated and still in use go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table go_memstats_frees_total Total number of frees go_memstats_gc_cpu_fraction The fraction of this program\u0026rsquo;s available CPU time used by the GC since the program started go_memstats_gc_sys_bytes Number of bytes used for garbage collection system metadata go_memstats_heap_alloc_bytes Number of heap bytes allocated and still in use go_memstats_heap_idle_bytes Number of heap bytes waiting to be used go_memstats_heap_inuse_bytes Number of heap bytes that are in use go_memstats_heap_objects Number of allocated objects go_memstats_heap_released_bytes Number of heap bytes released to OS go_memstats_heap_sys_bytes Number of heap bytes obtained from system go_memstats_last_gc_time_seconds Number of seconds since 1970 of last garbage collection go_memstats_lookups_total Total number of pointer lookups go_memstats_mallocs_total Total number of mallocs go_memstats_mcache_inuse_bytes Number of bytes in use by mcache structures go_memstats_mcache_sys_bytes Number of bytes used for mcache structures obtained from system go_memstats_mspan_inuse_bytes Number of bytes in use by mspan structures go_memstats_mspan_sys_bytes Number of bytes used for mspan structures obtained from system go_memstats_next_gc_bytes Number of heap bytes when next garbage collection will take place go_memstats_other_sys_bytes Number of bytes used for other system allocations go_memstats_stack_inuse_bytes Number of bytes in use by the stack allocator go_memstats_stack_sys_bytes Number of bytes obtained from system for stack allocator go_memstats_sys_bytes Number of bytes obtained from system go_threads Number of OS threads created promhttp_metric_handler_requests_in_flight Current number of scrapes being served promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code "});index.add({'id':12,'href':'/extensions/onlyoffice/','title':"OnlyOffice",'parent':"Extensions",'content':"This service enables users open documents, spreadsheets and presentations in the OnlyOffice app installed in ownCloud 10.\n"});index.add({'id':13,'href':'/ocis/development/getting-started/','title':"Getting Started",'parent':"Development",'content':" Requirements Repository structure Starting points Developing oCIS Developing extensions Requirements We want contribution to oCIS and the creation of extensions to be as easy as possible. So we are trying to reflect this in the tooling. It should be kept simple and quick to be set up.\nBesides standard development tools like git and a text editor, you need the following software for development:\n Go \u0026gt;= v1.13 (install instructions) Yarn (install instructions) docker (install instructions) docker-compose (install instructions) If you find tools needed besides the mentioned above, please feel free to open an issue or open a PR.\nRepository structure This repository follows the golang-standard project-layout.\noCIS consists of multiple micro services, also called extensions. We started by having standalone repositories for each of them but quickly noticed, that this adds a time consuming overhead for developers. So we ended up with a monorepo housing all the extensions in one repository.\nEach of the extensions live in a subfolder (eg. accounts or settings) in this repository, technically creating independant Go modules.\nThe ocis folder does also contain a Go module but is no extension at all. Instead this module is used to import all extensions and furthermore implement commands to start the extensions. With the resulting oCIS binary you can start single extensions or even all extensions at the same time.\nThe docs folder contains the source for the oCIS documentation.\nThe deployments folder contains documented deployment configurations and templates.\nThe scripts folder contains scripts to perform various build, install, analysis, etc operations.\nStarting points Depending on what you want to develop there are different starting points. These will be described below.\nDeveloping oCIS If you want to contribute to oCIS:\n see contribution guidelines make sure the tooling is set up by building oCIS and building the docs create or pick an open issue to develop on and mention in the issue that you are working on it open a PR and get things done Developing extensions If you want to develop an extension, start here: Extensions\n"});index.add({'id':14,'href':'/ocis/deployment/basic-remote-setup/','title':"Basic Remote Setup",'parent':"Deployment",'content':" Use the binary Add your hostname to the idp config Start the ocis fullstack server Use Docker Compose Out of the box the ocis single binary and the owncloud/ocis docker image are configured to run on localhost for quick testing and development.\nIf you need to access ocis on a VM or a remote machine e.g. when testing a mobile client you need to configure ocis to run on a different host.\nUse the binary If you start the ocis fullstack for the first time with ./bin/ocis server it will generate a file identifier-registration.yml in the config folder relative to its location. This file is used to configure the clients for the built-in Identity Provider.\nOutdated version\nThe identifier-registration.yml file will only be generated if there is no such file in place. You could miss updates on this file. Run make clean to delete the file and keep the development environment tidy otherwise as well. Add your hostname to the idp config Let us assume your-host is your remote domain name or IP adress. Add your host to the identifier-registration.yml like this:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # OpenID Connect client registry.clients:- id:webname:ownCloudwebappapplication_type:webinsecure:yestrusted:yesredirect_uris:- http://localhost:9100/- http://localhost:9100/oidc-callback.html- http://localhost:9100/oidc-silent-redirect.html- https://localhost:9200/- https://localhost:9200/oidc-callback.html- https://localhost:9200/oidc-silent-redirect.html- https://your-server:9200/- https://your-server:9200/oidc-callback.html- https://your-server:9200/oidc-silent-redirect.htmlorigins:- http://localhost:9100- https://localhost:9200- https://your-server:9200 In this example we do not change the default port (9200). But this could be changed to another port.\nStart the ocis fullstack server You need to configure your-host in some services to provide the needed public resources.\nPROXY_HTTP_ADDR=0.0.0.0:9200 \\ KONNECTD_ISS=https://your-server:9200 \\ REVA_OIDC_ISSUER=https://your-server:9200 \\ WEB_OIDC_AUTHORITY=https://your-server:9200 \\ WEB_UI_CONFIG_SERVER=https://your-server:9200 \\ WEB_OIDC_METADATA_URL=https://your-server:9200/.well-known/openid-configuration \\ REVA_DATAGATEWAY_URL=https://your-server:9200/data \\ REVA_FRONTEND_URL=https://your-server:9200 \\ PROXY_TRANSPORT_TLS_KEY=./certs/your-host.key \\ PROXY_TRANSPORT_TLS_CERT=./certs/your-host.crt \\ KONNECTD_TLS=0 \\ ./bin/ocis server For more configuration options check the configuration secion in ocis and every ocis extension.\nTLS Certificate\nIn this example, we are replacing the default self signed cert with a CA signed one to avoid the certificate warning when accessing the login page. Use Docker Compose We are using our docker compose playground as a repository to share snippets that make our test setups easier and more aligned.\nYou can start oCIS with docker very easily on a different host using this snippet.\nLet us assume your local IP is 192.168.103.195\ngit clone https://github.com/owncloud-docker/compose-playground.git cd compose-playground/compose/ocis sed -i -e \u0026#39;s/your-url/192.168.103.195/g\u0026#39; config/identifier-registration.yml cat \u0026lt;\u0026lt; EOF \u0026gt; .env OCIS_BASE_URL=192.168.103.195 OCIS_HTTP_PORT=9200 OCIS_DOCKER_TAG=latest EOF curl -k https://192.168.103.195:9200/status.php "});index.add({'id':15,'href':'/extensions/onlyoffice/configuration/','title':"Configuration",'parent':"OnlyOffice",'content':" Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands onlyoffice server onlyoffice health Configuration oCIS Single Binary is not responsible for configuring extensions. Instead, each extension could either be configured by environment variables, cli flags or config files.\nEach extension has its dedicated documentation page (e.g. https://owncloud.github.io/extensions/onlyoffice/configuration) which lists all possible configurations. Config files and environment variables are picked up if you use the ./bin/ocis server command within the oCIS single binary. Command line flags must be set explicitly on the extensions subcommands.\nConfiguration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: onlyoffice reads onlyoffice.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nRoot Command OnlyOffice oCIS extension\nUsage: onlyoffice [global options] command [command options] [arguments...]\n \u0026ndash;config-file | $ONLYOFFICE_CONFIG_FILE Path to config file. \u0026ndash;log-level | $ONLYOFFICE_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $ONLYOFFICE_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $ONLYOFFICE_LOG_COLOR Enable colored logging. Default: true. Sub Commands onlyoffice server Start integrated server\nUsage: onlyoffice server [command options] [arguments...]\n \u0026ndash;tracing-enabled | $ONLYOFFICE_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $ONLYOFFICE_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $ONLYOFFICE_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $ONLYOFFICE_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $ONLYOFFICE_TRACING_SERVICE Service name for tracing. Default: onlyoffice. \u0026ndash;debug-addr | $ONLYOFFICE_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9224. \u0026ndash;debug-token | $ONLYOFFICE_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $ONLYOFFICE_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $ONLYOFFICE_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $ONLYOFFICE_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9220. \u0026ndash;http-namespace | $ONLYOFFICE_HTTP_NAMESPACE Set the base namespace for the http namespace. Default: com.owncloud.web. \u0026ndash;http-root | $ONLYOFFICE_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;asset-path | $ONLYOFFICE_ASSET_PATH Path to custom assets. onlyoffice health Check health status\nUsage: onlyoffice health [command options] [arguments...]\n \u0026ndash;debug-addr | $ONLYOFFICE_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9224. "});index.add({'id':16,'href':'/extensions/webdav/configuration/','title':"Configuration",'parent':"WebDaV",'content':" Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands webdav version webdav health webdav server Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-proxy reads proxy.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nRoot Command Serve WebDAV API for oCIS\nUsage: webdav [global options] command [command options] [arguments...]\n \u0026ndash;log-level | $WEBDAV_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $WEBDAV_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $WEBDAV_LOG_COLOR Enable colored logging. Default: true. Sub Commands webdav version Print the versions of the running instances\nUsage: webdav version [command options] [arguments...]\n \u0026ndash;http-namespace | $WEBDAV_HTTP_NAMESPACE Set the base namespace for service discovery. Default: com.owncloud.web. \u0026ndash;service-name | $WEBDAV_SERVICE_NAME Service name. Default: webdav. webdav health Check health status\nUsage: webdav health [command options] [arguments...]\n \u0026ndash;debug-addr | $WEBDAV_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9119. webdav server Start integrated server\nUsage: webdav server [command options] [arguments...]\n \u0026ndash;config-file | $WEBDAV_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $WEBDAV_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $WEBDAV_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $WEBDAV_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $WEBDAV_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $WEBDAV_TRACING_SERVICE Service name for tracing. Default: webdav. \u0026ndash;debug-addr | $WEBDAV_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9119. \u0026ndash;debug-token | $WEBDAV_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $WEBDAV_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $WEBDAV_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $WEBDAV_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9115. \u0026ndash;http-namespace | $WEBDAV_HTTP_NAMESPACE Set the base namespace for service discovery. Default: com.owncloud.web. \u0026ndash;service-name | $WEBDAV_SERVICE_NAME Service name. Default: webdav. \u0026ndash;http-root | $WEBDAV_HTTP_ROOT Root path of http server. Default: /. "});index.add({'id':17,'href':'/extensions/thumbnails/configuration/','title':"Configuration",'parent':"Thumbnails",'content':" Configuration Configuration using config files Environment variables Commandline flags thumbnails version thumbnails health thumbnails server thumbnails ocis-thumbnails Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-proxy reads proxy.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nthumbnails version Print the versions of the running instances\nUsage: thumbnails version [command options] [arguments...]\n \u0026ndash;grpc-name | $THUMBNAILS_GRPC_NAME Name of the service. Default: thumbnails. \u0026ndash;grpc-namespace | $THUMBNAILS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. thumbnails health Check health status\nUsage: thumbnails health [command options] [arguments...]\n \u0026ndash;debug-addr | $THUMBNAILS_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9189. thumbnails server Start integrated server\nUsage: thumbnails server [command options] [arguments...]\n \u0026ndash;config-file | $THUMBNAILS_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $THUMBNAILS_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $THUMBNAILS_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $THUMBNAILS_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $THUMBNAILS_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $THUMBNAILS_TRACING_SERVICE Service name for tracing. Default: thumbnails. \u0026ndash;debug-addr | $THUMBNAILS_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9189. \u0026ndash;debug-token | $THUMBNAILS_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $THUMBNAILS_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $THUMBNAILS_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;grpc-name | $THUMBNAILS_GRPC_NAME Name of the service. Default: thumbnails. \u0026ndash;grpc-addr | $THUMBNAILS_GRPC_ADDR Address to bind grpc server. Default: 0.0.0.0:9185. \u0026ndash;grpc-namespace | $THUMBNAILS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;filesystemstorage-root | $THUMBNAILS_FILESYSTEMSTORAGE_ROOT Root path of the filesystem storage directory. Default: filepath.Join(os.TempDir(), \u0026quot;ocis-thumbnails/\u0026quot;). \u0026ndash;webdavsource-baseurl | $THUMBNAILS_WEBDAVSOURCE_BASEURL Base url for a webdav api. Default: https://localhost:9200/remote.php/webdav/. \u0026ndash;webdavsource-insecure | $THUMBNAILS_WEBDAVSOURCE_INSECURE Whether to skip certificate checks. Default: true. thumbnails ocis-thumbnails Example usage\nUsage: thumbnails ocis-thumbnails [command options] [arguments...]\n \u0026ndash;log-level | $THUMBNAILS_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $THUMBNAILS_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $THUMBNAILS_LOG_COLOR Enable colored logging. Default: true. "});index.add({'id':18,'href':'/extensions/store/configuration/','title':"Configuration",'parent':"Store",'content':" Configuration Configuration using config files Environment variables Commandline flags store health store server store ocis-store store version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-proxy reads proxy.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nstore health Check health status\nUsage: store health [command options] [arguments...]\n \u0026ndash;debug-addr | $STORE_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9460. store server Start integrated server\nUsage: store server [command options] [arguments...]\n \u0026ndash;tracing-enabled | $STORE_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $STORE_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $STORE_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $STORE_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $STORE_TRACING_SERVICE Service name for tracing. Default: store. \u0026ndash;debug-addr | $STORE_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9460. \u0026ndash;debug-token | $STORE_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $STORE_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $STORE_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;grpc-namespace | $STORE_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $STORE_NAME Service name. Default: store. \u0026ndash;data-path | $STORE_DATA_PATH location of the store data path. Default: /var/tmp/ocis/store. store ocis-store Service to store values for ocis extensions\nUsage: store ocis-store [command options] [arguments...]\n \u0026ndash;config-file | $STORE_CONFIG_FILE Path to config file. \u0026ndash;log-level | $STORE_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $STORE_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $STORE_LOG_COLOR Enable colored logging. Default: true. store version Print the versions of the running instances\nUsage: store version [command options] [arguments...]\n \u0026ndash;grpc-namespace | $STORE_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $STORE_NAME Service name. Default: store. "});index.add({'id':19,'href':'/extensions/settings/configuration/','title':"Configuration",'parent':"Settings",'content':" Configuration Configuration using config files Environment variables Commandline flags settings health settings server settings ocis-settings settings version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-proxy reads proxy.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nsettings health Check health status\nUsage: settings health [command options] [arguments...]\n \u0026ndash;debug-addr | $SETTINGS_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9194. settings server Start integrated server\nUsage: settings server [command options] [arguments...]\n \u0026ndash;config-file | $SETTINGS_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $SETTINGS_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $SETTINGS_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $SETTINGS_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $SETTINGS_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $SETTINGS_TRACING_SERVICE Service name for tracing. Default: settings. \u0026ndash;debug-addr | $SETTINGS_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9194. \u0026ndash;debug-token | $SETTINGS_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $SETTINGS_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $SETTINGS_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $SETTINGS_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9190. \u0026ndash;http-namespace | $SETTINGS_HTTP_NAMESPACE Set the base namespace for the http namespace. Default: com.owncloud.web. \u0026ndash;http-root | $SETTINGS_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;grpc-addr | $SETTINGS_GRPC_ADDR Address to bind grpc server. Default: 0.0.0.0:9191. \u0026ndash;asset-path | $SETTINGS_ASSET_PATH Path to custom assets. \u0026ndash;grpc-namespace | $SETTINGS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $SETTINGS_NAME service name. Default: settings. \u0026ndash;data-path | $SETTINGS_DATA_PATH Mount path for the storage. Default: /var/tmp/ocis/settings. \u0026ndash;jwt-secret | $SETTINGS_JWT_SECRET Used to create JWT to talk to reva, should equal reva\u0026rsquo;s jwt-secret. Default: Pive-Fumkiu4. settings ocis-settings Provide settings and permissions for oCIS\nUsage: settings ocis-settings [command options] [arguments...]\n \u0026ndash;log-level | $SETTINGS_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $SETTINGS_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $SETTINGS_LOG_COLOR Enable colored logging. Default: true. settings version Print the versions of the running instances\nUsage: settings version [command options] [arguments...]\n \u0026ndash;grpc-namespace | $SETTINGS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $SETTINGS_NAME service name. Default: settings. "});index.add({'id':20,'href':'/extensions/storage/configuration/','title':"Configuration",'parent':"Storage",'content':" Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands storage storage-users storage storage-public-link storage gateway storage users storage frontend storage storage storage storage-home storage storage-metadata storage health storage auth-basic storage sharing storage auth-bearer Config for the different Storage Drivers Local Driver Eos Driver owCloud Driver Ocis Driver Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-proxy reads proxy.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nRoot Command Storage service for oCIS\nUsage: storage [global options] command [command options] [arguments...]\n \u0026ndash;config-file | $STORAGE_CONFIG_FILE Path to config file. \u0026ndash;log-level | $STORAGE_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $STORAGE_LOG_PRETTY Enable pretty logging. \u0026ndash;log-color | $STORAGE_LOG_COLOR Enable colored logging. Sub Commands storage storage-users Start storage-users service\nUsage: storage storage-users [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_USERS_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9159. \u0026ndash;grpc-network | $STORAGE_USERS_GRPC_NETWORK Network to use for the users storage, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;grpc-addr | $STORAGE_USERS_GRPC_ADDR GRPC Address to bind users storage. Default: 0.0.0.0:9157. \u0026ndash;http-network | $STORAGE_USERS_HTTP_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;http-addr | $STORAGE_USERS_HTTP_ADDR HTTP Address to bind users storage. Default: 0.0.0.0:9158. \u0026ndash;driver | $STORAGE_USERS_DRIVER storage driver for users mount: eg. local, eos, owncloud, ocis or s3. Default: ocis. \u0026ndash;mount-path | $STORAGE_USERS_MOUNT_PATH mount path. Default: /users. \u0026ndash;mount-id | $STORAGE_USERS_MOUNT_ID mount id. Default: 1284d238-aa92-42ce-bdc4-0b0000009157. \u0026ndash;expose-data-server | $STORAGE_USERS_EXPOSE_DATA_SERVER exposes a dedicated data server. Default: false. \u0026ndash;data-server-url | $STORAGE_USERS_DATA_SERVER_URL data server url. Default: http://localhost:9158/data. \u0026ndash;http-prefix | $STORAGE_USERS_HTTP_PREFIX prefix for the http endpoint, without leading slash. Default: data. \u0026ndash;tmp-folder | $STORAGE_USERS_TMP_FOLDER path to tmp folder. Default: /var/tmp/ocis/tmp/users. \u0026ndash;gateway-endpoint | $STORAGE_GATEWAY_ENDPOINT endpoint to use for the storage gateway service. Default: localhost:9142. \u0026ndash;users-endpoint | $STORAGE_USERPROVIDER_ENDPOINT endpoint to use for the storage service. Default: localhost:9144. storage storage-public-link Start storage-public-link service\nUsage: storage storage-public-link [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_PUBLIC_LINK_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9179. \u0026ndash;network | $STORAGE_PUBLIC_LINK_GRPC_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;addr | $STORAGE_PUBLIC_LINK_GRPC_ADDR Address to bind storage service. Default: 0.0.0.0:9178. \u0026ndash;mount-path | $STORAGE_PUBLIC_LINK_MOUNT_PATH mount path. Default: /public. \u0026ndash;gateway-endpoint | $STORAGE_GATEWAY_ENDPOINT endpoint to use for the storage gateway service. Default: localhost:9142. storage gateway Start gateway\nUsage: storage gateway [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_GATEWAY_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9143. \u0026ndash;transfer-secret | $STORAGE_TRANSFER_SECRET Transfer secret for datagateway. Default: replace-me-with-a-transfer-secret. \u0026ndash;network | $STORAGE_GATEWAY_GRPC_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;addr | $STORAGE_GATEWAY_GRPC_ADDR Address to bind storage service. Default: 0.0.0.0:9142. \u0026ndash;endpoint | $STORAGE_GATEWAY_ENDPOINT endpoint to use for the storage service. Default: localhost:9142. \u0026ndash;commit-share-to-storage-grant | $STORAGE_GATEWAY_COMMIT_SHARE_TO_STORAGE_GRANT Commit shares to the share manager. Default: true. \u0026ndash;commit-share-to-storage-ref | $STORAGE_GATEWAY_COMMIT_SHARE_TO_STORAGE_REF Commit shares to the storage. Default: true. \u0026ndash;share-folder | $STORAGE_GATEWAY_SHARE_FOLDER mount shares in this folder of the home storage provider. Default: Shares. \u0026ndash;disable-home-creation-on-login | $STORAGE_GATEWAY_DISABLE_HOME_CREATION_ON_LOGIN Disable creation of home folder on login. \u0026ndash;auth-basic-endpoint | $STORAGE_AUTH_BASIC_ENDPOINT endpoint to use for the basic auth provider. Default: localhost:9146. \u0026ndash;auth-bearer-endpoint | $STORAGE_AUTH_BEARER_ENDPOINT endpoint to use for the bearer auth provider. Default: localhost:9148. \u0026ndash;storage-registry-driver | $STORAGE_STORAGE_REGISTRY_DRIVER driver of the storage registry. Default: static. \u0026ndash;storage-home-provider | $STORAGE_REGISTRY_HOME_PROVIDER mount point of the storage provider for user homes in the global namespace. Default: /home. \u0026ndash;public-url | $STORAGE_FRONTEND_PUBLIC_URL URL to use for the storage service. Default: https://localhost:9200. \u0026ndash;datagateway-url | $STORAGE_DATAGATEWAY_PUBLIC_URL URL to use for the storage datagateway. Default: https://localhost:9200/data. \u0026ndash;userprovider-endpoint | $STORAGE_USERPROVIDER_ENDPOINT endpoint to use for the userprovider. Default: localhost:9144. \u0026ndash;sharing-endpoint | $STORAGE_SHARING_ENDPOINT endpoint to use for the storage service. Default: localhost:9150. \u0026ndash;storage-home-endpoint | $STORAGE_HOME_ENDPOINT endpoint to use for the home storage. Default: localhost:9154. \u0026ndash;storage-home-mount-path | $STORAGE_HOME_MOUNT_PATH mount path. Default: /home. \u0026ndash;storage-home-mount-id | $STORAGE_HOME_MOUNT_ID mount id. Default: 1284d238-aa92-42ce-bdc4-0b0000009154. \u0026ndash;storage-users-endpoint | $STORAGE_USERS_ENDPOINT endpoint to use for the users storage. Default: localhost:9157. \u0026ndash;storage-users-mount-path | $STORAGE_USERS_MOUNT_PATH mount path. Default: /users. \u0026ndash;storage-users-mount-id | $STORAGE_USERS_MOUNT_ID mount id. Default: 1284d238-aa92-42ce-bdc4-0b0000009157. \u0026ndash;public-link-endpoint | $STORAGE_PUBLIC_LINK_ENDPOINT endpoint to use for the public links service. Default: localhost:9178. \u0026ndash;storage-public-link-mount-path | $STORAGE_PUBLIC_LINK_MOUNT_PATH mount path. Default: /public. storage users Start users service\nUsage: storage users [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_SHARING_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9145. \u0026ndash;network | $STORAGE_USERPROVIDER_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;addr | $STORAGE_USERPROVIDER_ADDR Address to bind storage service. Default: 0.0.0.0:9144. \u0026ndash;endpoint | $STORAGE_USERPROVIDER_ENDPOINT URL to use for the storage service. Default: localhost:9144. \u0026ndash;driver | $STORAGE_USERPROVIDER_DRIVER user driver: \u0026lsquo;demo\u0026rsquo;, \u0026lsquo;json\u0026rsquo;, \u0026lsquo;ldap\u0026rsquo;, or \u0026lsquo;rest\u0026rsquo;. Default: ldap. \u0026ndash;json-config | $STORAGE_USERPROVIDER_JSON Path to users.json file. \u0026ndash;rest-client-id | $STORAGE_REST_CLIENT_ID User rest driver Client ID. \u0026ndash;rest-client-secret | $STORAGE_REST_CLIENT_SECRET User rest driver Client Secret. \u0026ndash;rest-redis-address | $STORAGE_REST_REDIS_ADDRESS Address for redis server. Default: localhost:6379. \u0026ndash;rest-redis-username | $STORAGE_REST_REDIS_USERNAME Username for redis server. \u0026ndash;rest-redis-password | $STORAGE_REST_REDIS_PASSWORD Password for redis server. \u0026ndash;rest-id-provider | $STORAGE_REST_ID_PROVIDER The OIDC Provider. \u0026ndash;rest-api-base-url | $STORAGE_REST_API_BASE_URL Base API Endpoint. \u0026ndash;rest-oidc-token-endpoint | $STORAGE_REST_OIDC_TOKEN_ENDPOINT Endpoint to generate token to access the API. \u0026ndash;rest-target-api | $STORAGE_REST_TARGET_API The target application. storage frontend Start frontend service\nUsage: storage frontend [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_FRONTEND_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9141. \u0026ndash;transfer-secret | $STORAGE_TRANSFER_SECRET Transfer secret for datagateway. Default: replace-me-with-a-transfer-secret. \u0026ndash;chunk-folder | $STORAGE_CHUNK_FOLDER temp directory for chunked uploads. Default: /var/tmp/ocis/tmp/chunks. \u0026ndash;webdav-namespace | $STORAGE_WEBDAV_NAMESPACE Namespace prefix for the /webdav endpoint. Default: /home/. \u0026ndash;dav-files-namespace | $STORAGE_DAV_FILES_NAMESPACE Namespace prefix for the webdav /dav/files endpoint. Default: /users/. \u0026ndash;network | $STORAGE_FRONTEND_HTTP_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;addr | $STORAGE_FRONTEND_HTTP_ADDR Address to bind storage service. Default: 0.0.0.0:9140. \u0026ndash;public-url | $STORAGE_FRONTEND_PUBLIC_URL URL to use for the storage service. Default: https://localhost:9200. \u0026ndash;datagateway-prefix | $STORAGE_FRONTEND_DATAGATEWAY_PREFIX datagateway prefix. Default: data. \u0026ndash;ocdav-prefix | $STORAGE_FRONTEND_OCDAV_PREFIX owncloud webdav endpoint prefix. \u0026ndash;ocs-prefix | $STORAGE_FRONTEND_OCS_PREFIX open collaboration services endpoint prefix. Default: ocs. \u0026ndash;ocs-share-prefix | $STORAGE_FRONTEND_OCS_Share_PREFIX the prefix prepended to the path of shared files. Default: /Shares. \u0026ndash;gateway-url | $STORAGE_GATEWAY_ENDPOINT URL to use for the storage gateway service. Default: localhost:9142. \u0026ndash;upload-disable-tus | $STORAGE_FRONTEND_UPLOAD_DISABLE_TUS Disables TUS upload mechanism. Default: false. \u0026ndash;upload-http-method-override | $STORAGE_FRONTEND_UPLOAD_HTTP_METHOD_OVERRIDE Specify an HTTP method (ex: POST) that clients should to use when uploading instead of PATCH. storage storage Storage service for oCIS\nUsage: storage storage [command options] [arguments...]\n \u0026ndash;config-file | $STORAGE_CONFIG_FILE Path to config file. \u0026ndash;log-level | $STORAGE_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $STORAGE_LOG_PRETTY Enable pretty logging. \u0026ndash;log-color | $STORAGE_LOG_COLOR Enable colored logging. storage storage-home Start storage-home service\nUsage: storage storage-home [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_HOME_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9156. \u0026ndash;grpc-network | $STORAGE_HOME_GRPC_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;grpc-addr | $STORAGE_HOME_GRPC_ADDR Address to bind storage service. Default: 0.0.0.0:9154. \u0026ndash;http-network | $STORAGE_HOME_HTTP_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;http-addr | $STORAGE_HOME_HTTP_ADDR Address to bind storage service. Default: 0.0.0.0:9155. \u0026ndash;driver | $STORAGE_HOME_DRIVER storage driver for home mount: eg. local, eos, owncloud, ocis or s3. Default: ocis. \u0026ndash;mount-path | $STORAGE_HOME_MOUNT_PATH mount path. Default: /home. \u0026ndash;mount-id | $STORAGE_HOME_MOUNT_ID mount id. Default: 1284d238-aa92-42ce-bdc4-0b0000009157. \u0026ndash;expose-data-server | $STORAGE_HOME_EXPOSE_DATA_SERVER exposes a dedicated data server. Default: false. \u0026ndash;data-server-url | $STORAGE_HOME_DATA_SERVER_URL data server url. Default: http://localhost:9155/data. \u0026ndash;http-prefix | $STORAGE_HOME_HTTP_PREFIX prefix for the http endpoint, without leading slash. Default: data. \u0026ndash;tmp-folder | $STORAGE_HOME_TMP_FOLDER path to tmp folder. Default: /var/tmp/ocis/tmp/home. \u0026ndash;enable-home | $STORAGE_HOME_ENABLE_HOME enable the creation of home directories. Default: true. \u0026ndash;gateway-endpoint | $STORAGE_GATEWAY_ENDPOINT endpoint to use for the storage gateway service. Default: localhost:9142. \u0026ndash;users-endpoint | $STORAGE_USERPROVIDER_ENDPOINT endpoint to use for the storage service. Default: localhost:9144. storage storage-metadata Start storage-metadata service\nUsage: storage storage-metadata [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_METADATA_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9217. \u0026ndash;grpc-network | $STORAGE_METADATA_GRPC_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;grpc-addr | $STORAGE_METADATA_GRPC_PROVIDER_ADDR Address to bind storage service. Default: 0.0.0.0:9215. \u0026ndash;data-server-url | $STORAGE_METADATA_DATA_SERVER_URL URL of the data-provider the storage-provider uses. Default: http://localhost:9216. \u0026ndash;http-network | $STORAGE_METADATA_HTTP_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;http-addr | $STORAGE_METADATA_HTTP_ADDR Address to bind storage service. Default: 0.0.0.0:9216. \u0026ndash;tmp-folder | $STORAGE_METADATA_TMP_FOLDER path to tmp folder. Default: /var/tmp/ocis/tmp/metadata. \u0026ndash;driver | $STORAGE_METADATA_DRIVER storage driver for metadata mount: eg. local, eos, owncloud, ocis or s3. Default: ocis. \u0026ndash;gateway-endpoint | $STORAGE_GATEWAY_ENDPOINT endpoint to use for the gateway service. Default: localhost:9142. \u0026ndash;userprovider-endpoint | $STORAGE_USERPROVIDER_ENDPOINT endpoint to use for the userprovider service. Default: localhost:9144. \u0026ndash;storage-root | $STORAGE_METADATA_ROOT the path to the metadata storage root. Default: /var/tmp/ocis/storage/metadata. storage health Check health status\nUsage: storage health [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9109. storage auth-basic Start authprovider for basic auth\nUsage: storage auth-basic [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_AUTH_BASIC_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9147. \u0026ndash;auth-driver | $STORAGE_AUTH_DRIVER auth driver: \u0026lsquo;demo\u0026rsquo;, \u0026lsquo;json\u0026rsquo; or \u0026lsquo;ldap\u0026rsquo;. Default: ldap. \u0026ndash;auth-json | $STORAGE_AUTH_JSON Path to users.json file. \u0026ndash;network | $STORAGE_AUTH_BASIC_GRPC_NETWORK Network to use for the storage auth-basic service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;addr | $STORAGE_AUTH_BASIC_GRPC_ADDR Address to bind storage service. Default: 0.0.0.0:9146. storage sharing Start sharing service\nUsage: storage sharing [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_SHARING_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9151. \u0026ndash;network | $STORAGE_SHARING_GRPC_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;addr | $STORAGE_SHARING_GRPC_ADDR Address to bind storage service. Default: 0.0.0.0:9150. \u0026ndash;user-driver | $STORAGE_SHARING_USER_DRIVER driver to use for the UserShareProvider. Default: json. \u0026ndash;user-json-file | $STORAGE_SHARING_USER_JSON_FILE file used to persist shares for the UserShareProvider. Default: /var/tmp/ocis/storage/shares.json. \u0026ndash;public-driver | $STORAGE_SHARING_PUBLIC_DRIVER driver to use for the PublicShareProvider. Default: json. \u0026ndash;public-json-file | $STORAGE_SHARING_PUBLIC_JSON_FILE file used to persist shares for the PublicShareProvider. Default: /var/tmp/ocis/storage/publicshares.json. storage auth-bearer Start authprovider for bearer auth\nUsage: storage auth-bearer [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_AUTH_BEARER_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9149. \u0026ndash;oidc-issuer | $STORAGE_OIDC_ISSUER OIDC issuer. Default: https://localhost:9200. \u0026ndash;oidc-insecure | $STORAGE_OIDC_INSECURE OIDC allow insecure communication. Default: true. \u0026ndash;oidc-id-claim | $STORAGE_OIDC_ID_CLAIM OIDC id claim. Default: preferred_username. \u0026ndash;oidc-uid-claim | $STORAGE_OIDC_UID_CLAIM OIDC uid claim. \u0026ndash;oidc-gid-claim | $STORAGE_OIDC_GID_CLAIM OIDC gid claim. \u0026ndash;network | $STORAGE_AUTH_BEARER_GRPC_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;addr | $STORAGE_AUTH_BEARER_GRPC_ADDR Address to bind storage service. Default: 0.0.0.0:9148. Config for the different Storage Drivers You can set different storage drivers for the Storage Providers. Please check the storage provider configuration.\nExample: Set the home and users Storage Provider to ocis\nSTORAGE_HOME_DRIVER=ocis STORAGE_USERS_DRIVER=ocis\nLocal Driver \u0026ndash;storage-local-root | $STORAGE_DRIVER_LOCAL_ROOT the path to the local storage root. Default: /var/tmp/ocis/storage/local. Eos Driver \u0026ndash;storage-eos-namespace | $STORAGE_DRIVER_EOS_NAMESPACE Namespace for metadata operations. Default: /eos/dockertest/reva. \u0026ndash;storage-eos-shadow-namespace | $STORAGE_DRIVER_EOS_SHADOW_NAMESPACE Shadow namespace where share references are stored. \u0026ndash;storage-eos-share-folder | $STORAGE_DRIVER_EOS_SHARE_FOLDER name of the share folder. Default: /Shares. \u0026ndash;storage-eos-binary | $STORAGE_DRIVER_EOS_BINARY Location of the eos binary. Default: /usr/bin/eos. \u0026ndash;storage-eos-xrdcopy-binary | $STORAGE_DRIVER_EOS_XRDCOPY_BINARY Location of the xrdcopy binary. Default: /usr/bin/xrdcopy. \u0026ndash;storage-eos-master-url | $STORAGE_DRIVER_EOS_MASTER_URL URL of the Master EOS MGM. Default: root://eos-mgm1.eoscluster.cern.ch:1094. \u0026ndash;storage-eos-slave-url | $STORAGE_DRIVER_EOS_SLAVE_URL URL of the Slave EOS MGM. Default: root://eos-mgm1.eoscluster.cern.ch:1094. \u0026ndash;storage-eos-cache-directory | $STORAGE_DRIVER_EOS_CACHE_DIRECTORY Location on the local fs where to store reads. Default: os.TempDir(). \u0026ndash;storage-eos-enable-logging | $STORAGE_DRIVER_EOS_ENABLE_LOGGING Enables logging of the commands executed. \u0026ndash;storage-eos-show-hidden-sysfiles | $STORAGE_DRIVER_EOS_SHOW_HIDDEN_SYSFILES show internal EOS files like .sys.v# and .sys.a# files.. \u0026ndash;storage-eos-force-singleuser-mode | $STORAGE_DRIVER_EOS_FORCE_SINGLEUSER_MODE force connections to EOS to use SingleUsername. \u0026ndash;storage-eos-use-keytab | $STORAGE_DRIVER_EOS_USE_KEYTAB authenticate requests by using an EOS keytab. \u0026ndash;storage-eos-enable-home | $STORAGE_DRIVER_EOS_ENABLE_HOME enable the creation of home directories. \u0026ndash;storage-eos-sec-protocol | $STORAGE_DRIVER_EOS_SEC_PROTOCOL the xrootd security protocol to use between the server and EOS. \u0026ndash;storage-eos-keytab | $STORAGE_DRIVER_EOS_KEYTAB the location of the keytab to use to authenticate to EOS. \u0026ndash;storage-eos-single-username | $STORAGE_DRIVER_EOS_SINGLE_USERNAME the username to use when SingleUserMode is enabled. \u0026ndash;storage-eos-layout | $STORAGE_DRIVER_EOS_LAYOUT \u0026quot;layout of the users home dir path on disk, in addition to {{.Username}}, {{.UsernameLower}} and {{.Provider}} also supports prefixing dirs: \u0026quot;{{.UsernamePrefixCount.2}}/{{.UsernameLower}}\u0026quot; will turn \u0026quot;Einstein\u0026quot; into \u0026quot;Ei/Einstein\u0026quot; . Default: {{substr 0 1 .Username}}/{{.Username}}. \u0026ndash;storage-eos-gatewaysvc | $STORAGE_DRIVER_EOS_GATEWAYSVC URL to use for the storage gateway service. Default: localhost:9142. owCloud Driver \u0026ndash;storage-owncloud-datadir | $STORAGE_DRIVER_OWNCLOUD_DATADIR the path to the owncloud data directory. Default: /var/tmp/ocis/storage/owncloud. \u0026ndash;storage-owncloud-uploadinfo-dir | $STORAGE_DRIVER_OWNCLOUD_UPLOADINFO_DIR the path to the tus upload info directory. Default: /var/tmp/ocis/storage/uploadinfo. \u0026ndash;storage-owncloud-share-folder | $STORAGE_DRIVER_OWNCLOUD_SHARE_FOLDER name of the shares folder. Default: /Shares. \u0026ndash;storage-owncloud-scan | $STORAGE_DRIVER_OWNCLOUD_SCAN scan files on startup to add fileids. Default: true. \u0026ndash;storage-owncloud-redis | $STORAGE_DRIVER_OWNCLOUD_REDIS_ADDR the address of the redis server. Default: :6379. \u0026ndash;storage-owncloud-enable-home | $STORAGE_DRIVER_OWNCLOUD_ENABLE_HOME enable the creation of home storages. Default: false. \u0026ndash;storage-owncloud-layout | $STORAGE_DRIVER_OWNCLOUD_LAYOUT \u0026quot;layout of the users home dir path on disk, in addition to {{.Username}}, {{.Mail}}, {{.Id.OpaqueId}}, {{.Id.Idp}} also supports prefixing dirs: \u0026quot;{{substr 0 1 .Username}}/{{.Username}}\u0026quot; will turn \u0026quot;Einstein\u0026quot; into \u0026quot;Ei/Einstein\u0026quot; . Default: {{.Id.OpaqueId}}. Ocis Driver \u0026ndash;storage-ocis-root | $STORAGE_DRIVER_OCIS_ROOT the path to the local storage root. Default: /var/tmp/ocis/storage/users. \u0026ndash;storage-ocis-enable-home | $STORAGE_DRIVER_OCIS_ENABLE_HOME enable the creation of home storages. Default: false. \u0026ndash;storage-ocis-layout | $STORAGE_DRIVER_OCIS_LAYOUT \u0026quot;layout of the users home dir path on disk, in addition to {{.Username}}, {{.Mail}}, {{.Id.OpaqueId}}, {{.Id.Idp}} also supports prefixing dirs: \u0026quot;{{substr 0 1 .Username}}/{{.Username}}\u0026quot; will turn \u0026quot;Einstein\u0026quot; into \u0026quot;Ei/Einstein\u0026quot; . Default: {{.Id.OpaqueId}}. "});index.add({'id':21,'href':'/extensions/proxy/configuration/','title':"Configuration",'parent':"Proxy",'content':" Configuration Configuration using config files Environment variables Commandline flags proxy health proxy server proxy ocis-proxy proxy version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-proxy reads proxy.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nproxy health Check health status\nUsage: proxy health [command options] [arguments...]\n \u0026ndash;debug-addr | $PROXY_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9109. proxy server Start integrated server\nUsage: proxy server [command options] [arguments...]\n \u0026ndash;config-file | $PROXY_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $PROXY_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $PROXY_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $PROXY_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $PROXY_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $PROXY_TRACING_SERVICE Service name for tracing. Default: proxy. \u0026ndash;debug-addr | $PROXY_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9205. \u0026ndash;debug-token | $PROXY_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $PROXY_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $PROXY_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $PROXY_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9200. \u0026ndash;http-root | $PROXY_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;asset-path | $PROXY_ASSET_PATH Path to custom assets. \u0026ndash;service-namespace | $PROXY_SERVICE_NAMESPACE Set the base namespace for the service namespace. Default: com.owncloud.web. \u0026ndash;service-name | $PROXY_SERVICE_NAME Service name. Default: proxy. \u0026ndash;transport-tls-cert | $PROXY_TRANSPORT_TLS_CERT Certificate file for transport encryption. \u0026ndash;transport-tls-key | $PROXY_TRANSPORT_TLS_KEY Secret file for transport encryption. \u0026ndash;tls | $PROXY_TLS Use TLS (disable only if proxy is behind a TLS-terminating reverse-proxy).. Default: true. \u0026ndash;jwt-secret | $PROXY_JWT_SECRET Used to create JWT to talk to reva, should equal reva\u0026rsquo;s jwt-secret. Default: Pive-Fumkiu4. \u0026ndash;reva-gateway-addr | $PROXY_REVA_GATEWAY_ADDR REVA Gateway Endpoint. Default: 127.0.0.1:9142. \u0026ndash;insecure | $PROXY_INSECURE_BACKENDS allow insecure communication to upstream servers. Default: false. \u0026ndash;oidc-issuer | $PROXY_OIDC_ISSUER OIDC issuer. Default: https://localhost:9200. \u0026ndash;oidc-insecure | $PROXY_OIDC_INSECURE OIDC allow insecure communication. Default: true. \u0026ndash;autoprovision-accounts | $PROXY_AUTOPROVISION_ACCOUNTS create accounts from OIDC access tokens to learn new users. Default: false. \u0026ndash;enable-presignedurls | $PROXY_ENABLE_PRESIGNEDURLS Enable or disable handling the presigned urls in the proxy. Default: true. \u0026ndash;enable-basic-auth | $PROXY_ENABLE_BASIC_AUTH enable basic authentication. Default: false. \u0026ndash;account-backend-type | $PROXY_ACCOUNT_BACKEND_TYPE account-backend-type. Default: accounts. proxy ocis-proxy proxy for Reva/oCIS\nUsage: proxy ocis-proxy [command options] [arguments...]\n \u0026ndash;log-level | $PROXY_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $PROXY_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $PROXY_LOG_COLOR Enable colored logging. Default: true. proxy version Print the versions of the running instances\nUsage: proxy version [command options] [arguments...]\n \u0026ndash;service-namespace | $PROXY_SERVICE_NAMESPACE Set the base namespace for the service namespace. Default: com.owncloud.web. \u0026ndash;service-name | $PROXY_SERVICE_NAME Service name. Default: proxy. "});index.add({'id':22,'href':'/extensions/proxy/','title':"Proxy",'parent':"Extensions",'content':"This service provides a proxy service that routes requests to the correct extensions.\n"});index.add({'id':23,'href':'/extensions/ocs/configuration/','title':"Configuration",'parent':"Ocs",'content':" Configuration Configuration using config files Environment variables Commandline flags ocs health ocs server ocs ocis-ocs ocs version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-ocs reads ocs.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nocs health Check health status\nUsage: ocs health [command options] [arguments...]\n \u0026ndash;debug-addr | $OCS_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9114. ocs server Start integrated server\nUsage: ocs server [command options] [arguments...]\n \u0026ndash;config-file | $OCS_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $OCS_TRACING_ENABLED Enable sending traces. Default: false. \u0026ndash;tracing-type | $OCS_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $OCS_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $OCS_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $OCS_TRACING_SERVICE Service name for tracing. Default: ocs. \u0026ndash;debug-addr | $OCS_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9114. \u0026ndash;debug-token | $OCS_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $OCS_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $OCS_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $OCS_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9110. \u0026ndash;http-namespace | $OCS_NAMESPACE Set the base namespace for the http namespace. Default: com.owncloud.web. \u0026ndash;name | $OCS_NAME Service name. Default: ocs. \u0026ndash;http-root | $OCS_HTTP_ROOT Root path of http server. Default: /ocs. \u0026ndash;jwt-secret | $OCS_JWT_SECRET Used to dismantle the access token, should equal reva\u0026rsquo;s jwt-secret. Default: Pive-Fumkiu4. ocs ocis-ocs Serve OCS API for oCIS\nUsage: ocs ocis-ocs [command options] [arguments...]\n \u0026ndash;log-level | $OCS_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $OCS_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $OCS_LOG_COLOR Enable colored logging. Default: true. ocs version Print the versions of the running instances\nUsage: ocs version [command options] [arguments...]\n \u0026ndash;http-namespace | $OCS_NAMESPACE Set the base namespace for the http namespace. Default: com.owncloud.web. \u0026ndash;name | $OCS_NAME Service name. Default: ocs. "});index.add({'id':24,'href':'/extensions/web/configuration/','title':"Configuration",'parent':"ownCloud Web",'content':" Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands web health web server Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-web reads web.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nRoot Command Serve ownCloud Web for oCIS\nUsage: web [global options] command [command options] [arguments...]\n \u0026ndash;log-level | $WEB_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $WEB_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $WEB_LOG_COLOR Enable colored logging. Default: true. Sub Commands web health Check health status\nUsage: web health [command options] [arguments...]\n \u0026ndash;debug-addr | $WEB_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9104. web server Start integrated server\nUsage: web server [command options] [arguments...]\n \u0026ndash;config-file | $WEB_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $WEB_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $WEB_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $WEB_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $WEB_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $WEB_TRACING_SERVICE Service name for tracing. Default: web. \u0026ndash;debug-addr | $WEB_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9104. \u0026ndash;debug-token | $WEB_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $WEB_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $WEB_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $WEB_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9100. \u0026ndash;http-root | $WEB_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;http-namespace | $WEB_NAMESPACE Set the base namespace for the http namespace. Default: com.owncloud.web. \u0026ndash;asset-path | $WEB_ASSET_PATH Path to custom assets. \u0026ndash;web-config | $WEB_UI_CONFIG Path to web config. \u0026ndash;web-config-server | $WEB_UI_CONFIG_SERVER Server URL. Default: https://localhost:9200. \u0026ndash;web-config-theme | $WEB_UI_CONFIG_THEME Theme. Default: owncloud. \u0026ndash;web-config-version | $WEB_UI_CONFIG_VERSION Version. Default: 0.1.0. \u0026ndash;oidc-metadata-url | $WEB_OIDC_METADATA_URL OpenID Connect metadata URL. Default: https://localhost:9200/.well-known/openid-configuration. \u0026ndash;oidc-authority | $WEB_OIDC_AUTHORITY OpenID Connect authority. Default: https://localhost:9200. \u0026ndash;oidc-client-id | $WEB_OIDC_CLIENT_ID OpenID Connect client ID. Default: web. \u0026ndash;oidc-response-type | $WEB_OIDC_RESPONSE_TYPE OpenID Connect response type. Default: code. \u0026ndash;oidc-scope | $WEB_OIDC_SCOPE OpenID Connect scope. Default: openid profile email. "});index.add({'id':25,'href':'/extensions/konnectd/configuration/','title':"Configuration",'parent':"Konnectd",'content':" Configuration Configuration using config files Environment variables Commandline flags konnectd version konnectd health konnectd server konnectd ocis-konnectd Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-konnectd reads konnectd.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nkonnectd version Print the versions of the running instances\nUsage: konnectd version [command options] [arguments...]\n \u0026ndash;http-namespace | $KONNECTD_HTTP_NAMESPACE Set the base namespace for service discovery. Default: com.owncloud.web. \u0026ndash;name | $KONNECTD_NAME Service name. Default: konnectd. konnectd health Check health status\nUsage: konnectd health [command options] [arguments...]\n \u0026ndash;debug-addr | $KONNECTD_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9134. konnectd server Start integrated server\nUsage: konnectd server [command options] [arguments...]\n \u0026ndash;config-file | $KONNECTD_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $KONNECTD_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $KONNECTD_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $KONNECTD_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $KONNECTD_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $KONNECTD_TRACING_SERVICE Service name for tracing. Default: konnectd. \u0026ndash;debug-addr | $KONNECTD_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9134. \u0026ndash;debug-token | $KONNECTD_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $KONNECTD_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $KONNECTD_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $KONNECTD_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9130. \u0026ndash;http-root | $KONNECTD_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;http-namespace | $KONNECTD_HTTP_NAMESPACE Set the base namespace for service discovery. Default: com.owncloud.web. \u0026ndash;name | $KONNECTD_NAME Service name. Default: konnectd. \u0026ndash;identity-manager | $KONNECTD_IDENTITY_MANAGER Identity manager (one of ldap,kc,cookie,dummy). Default: ldap. \u0026ndash;transport-tls-cert | $KONNECTD_TRANSPORT_TLS_CERT Certificate file for transport encryption. \u0026ndash;transport-tls-key | $KONNECTD_TRANSPORT_TLS_KEY Secret file for transport encryption. \u0026ndash;iss | $KONNECTD_ISS OIDC issuer URL. Default: https://localhost:9200. \u0026ndash;signing-kid | $KONNECTD_SIGNING_KID Value of kid field to use in created tokens (uniquely identifying the signing-private-key). \u0026ndash;validation-keys-path | $KONNECTD_VALIDATION_KEYS_PATH Full path to a folder containg PEM encoded private or public key files used for token validaton (file name without extension is used as kid). \u0026ndash;encryption-secret | $KONNECTD_ENCRYPTION_SECRET Full path to a file containing a %d bytes secret key. \u0026ndash;signing-method | $KONNECTD_SIGNING_METHOD JWT default signing method. Default: PS256. \u0026ndash;uri-base-path | $KONNECTD_URI_BASE_PATH Custom base path for URI endpoints. \u0026ndash;sign-in-uri | $KONNECTD_SIGN_IN_URI Custom redirection URI to sign-in form. \u0026ndash;signed-out-uri | $KONNECTD_SIGN_OUT_URI Custom redirection URI to signed-out goodbye page. \u0026ndash;authorization-endpoint-uri | $KONNECTD_ENDPOINT_URI Custom authorization endpoint URI. \u0026ndash;endsession-endpoint-uri | $KONNECTD_ENDSESSION_ENDPOINT_URI Custom endsession endpoint URI. \u0026ndash;asset-path | $KONNECTD_ASSET_PATH Path to custom assets. \u0026ndash;identifier-client-path | $KONNECTD_IDENTIFIER_CLIENT_PATH Path to the identifier web client base folder. Default: /var/tmp/ocis/konnectd. \u0026ndash;identifier-registration-conf | $KONNECTD_IDENTIFIER_REGISTRATION_CONF Path to a identifier-registration.yaml configuration file. Default: ./config/identifier-registration.yaml. \u0026ndash;identifier-scopes-conf | $KONNECTD_IDENTIFIER_SCOPES_CONF Path to a scopes.yaml configuration file. \u0026ndash;insecure | $KONNECTD_INSECURE Disable TLS certificate and hostname validation. \u0026ndash;tls | $KONNECTD_TLS Use TLS (disable only if konnectd is behind a TLS-terminating reverse-proxy).. Default: false. \u0026ndash;allow-client-guests | $KONNECTD_ALLOW_CLIENT_GUESTS Allow sign in of client controlled guest users. \u0026ndash;allow-dynamic-client-registration | $KONNECTD_ALLOW_DYNAMIC_CLIENT_REGISTRATION Allow dynamic OAuth2 client registration. Default: true. \u0026ndash;disable-identifier-webapp | $KONNECTD_DISABLE_IDENTIFIER_WEBAPP Disable built-in identifier-webapp to use a frontend hosted elsewhere.. Default: true. konnectd ocis-konnectd Serve Konnectd API for oCIS\nUsage: konnectd ocis-konnectd [command options] [arguments...]\n \u0026ndash;log-level | $KONNECTD_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $KONNECTD_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $KONNECTD_LOG_COLOR Enable colored logging. Default: true. "});index.add({'id':26,'href':'/extensions/konnectd/','title':"Konnectd",'parent':"Extensions",'content':"This service provides an OpenID Connect provider which is the default way to authenticate in oCIS.\n"});index.add({'id':27,'href':'/extensions/glauth/configuration/','title':"Configuration",'parent':"GLAuth",'content':" Configuration Configuration using config files Environment variables Commandline flags glauth health glauth server glauth ocis-glauth Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-glauth reads glauth.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nglauth health Check health status\nUsage: glauth health [command options] [arguments...]\n \u0026ndash;debug-addr | $GLAUTH_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9129. glauth server Start integrated server\nUsage: glauth server [command options] [arguments...]\n \u0026ndash;config-file | $GLAUTH_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $GLAUTH_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $GLAUTH_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $GLAUTH_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $GLAUTH_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $GLAUTH_TRACING_SERVICE Service name for tracing. Default: glauth. \u0026ndash;debug-addr | $GLAUTH_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9129. \u0026ndash;debug-token | $GLAUTH_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $GLAUTH_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $GLAUTH_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;role-bundle-id | $GLAUTH_ROLE_BUNDLE_ID roleid used to make internal grpc requests. Default: 71881883-1768-46bd-a24d-a356a2afdf7f. \u0026ndash;ldap-addr | $GLAUTH_LDAP_ADDR Address to bind ldap server. Default: 0.0.0.0:9125. \u0026ndash;ldap-enabled | $GLAUTH_LDAP_ENABLED Enable ldap server. Default: true. \u0026ndash;ldaps-addr | $GLAUTH_LDAPS_ADDR Address to bind ldap server. Default: 0.0.0.0:9126. \u0026ndash;ldaps-enabled | $GLAUTH_LDAPS_ENABLED Enable ldap server. Default: true. \u0026ndash;ldaps-cert | $GLAUTH_LDAPS_CERT path to ldaps certificate in PEM format. Default: ./ldap.crt. \u0026ndash;ldaps-key | $GLAUTH_LDAPS_KEY path to ldaps key in PEM format. Default: ./ldap.key. \u0026ndash;backend-basedn | $GLAUTH_BACKEND_BASEDN base distinguished name to expose. Default: dc=example,dc=org. \u0026ndash;backend-name-format | $GLAUTH_BACKEND_NAME_FORMAT name attribute for entries to expose. typically cn or uid. Default: cn. \u0026ndash;backend-group-format | $GLAUTH_BACKEND_GROUP_FORMAT name attribute for entries to expose. typically ou, cn or dc. Default: ou. \u0026ndash;backend-ssh-key-attr | $GLAUTH_BACKEND_SSH_KEY_ATTR ssh key attribute for entries to expose. Default: sshPublicKey. \u0026ndash;backend-datastore | $GLAUTH_BACKEND_DATASTORE datastore to use as the backend. one of accounts, ldap or owncloud. Default: accounts. \u0026ndash;backend-insecure | $GLAUTH_BACKEND_INSECURE Allow insecure requests to the datastore. Default: false. \u0026ndash;backend-use-graphapi | $GLAUTH_BACKEND_USE_GRAPHAPI use Graph API, only for owncloud datastore. Default: true. \u0026ndash;fallback-basedn | $GLAUTH_FALLBACK_BASEDN base distinguished name to expose. Default: dc=example,dc=org. \u0026ndash;fallback-name-format | $GLAUTH_FALLBACK_NAME_FORMAT name attribute for entries to expose. typically cn or uid. Default: cn. \u0026ndash;fallback-group-format | $GLAUTH_FALLBACK_GROUP_FORMAT name attribute for entries to expose. typically ou, cn or dc. Default: ou. \u0026ndash;fallback-ssh-key-attr | $GLAUTH_FALLBACK_SSH_KEY_ATTR ssh key attribute for entries to expose. Default: sshPublicKey. \u0026ndash;fallback-datastore | $GLAUTH_FALLBACK_DATASTORE datastore to use as the fallback. one of accounts, ldap or owncloud. \u0026ndash;fallback-insecure | $GLAUTH_FALLBACK_INSECURE Allow insecure requests to the datastore. Default: false. \u0026ndash;fallback-use-graphapi | $GLAUTH_FALLBACK_USE_GRAPHAPI use Graph API, only for owncloud datastore. Default: true. glauth ocis-glauth Serve GLAuth API for oCIS\nUsage: glauth ocis-glauth [command options] [arguments...]\n \u0026ndash;log-level | $GLAUTH_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $GLAUTH_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $GLAUTH_LOG_COLOR Enable colored logging. Default: true. "});index.add({'id':28,'href':'/extensions/accounts/configuration/','title':"Configuration",'parent':"Accounts",'content':" Configuration Configuration using config files Environment variables Commandline flags accounts server accounts add accounts list accounts version accounts update accounts remove accounts rebuildIndex accounts ocis-accounts accounts inspect Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-accounts reads accounts.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\naccounts server Start ocis accounts service\nUsage: accounts server [command options] [arguments...]\n \u0026ndash;tracing-enabled | $ACCOUNTS_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $ACCOUNTS_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $ACCOUNTS_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $ACCOUNTS_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $ACCOUNTS_TRACING_SERVICE Service name for tracing. Default: accounts. \u0026ndash;http-namespace | $ACCOUNTS_HTTP_NAMESPACE Set the base namespace for the http namespace. Default: com.owncloud.web. \u0026ndash;http-addr | $ACCOUNTS_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9181. \u0026ndash;http-root | $ACCOUNTS_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;grpc-namespace | $ACCOUNTS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;grpc-addr | $ACCOUNTS_GRPC_ADDR Address to bind grpc server. Default: 0.0.0.0:9180. \u0026ndash;name | $ACCOUNTS_NAME service name. Default: accounts. \u0026ndash;asset-path | $ACCOUNTS_ASSET_PATH Path to custom assets. \u0026ndash;jwt-secret | $ACCOUNTS_JWT_SECRET Used to create JWT to talk to reva, should equal reva\u0026rsquo;s jwt-secret. Default: Pive-Fumkiu4. \u0026ndash;storage-disk-path | $ACCOUNTS_STORAGE_DISK_PATH Path on the local disk, e.g. /var/tmp/ocis/accounts. \u0026ndash;storage-cs3-provider-addr | $ACCOUNTS_STORAGE_CS3_PROVIDER_ADDR bind address for the metadata storage provider. Default: localhost:9215. \u0026ndash;storage-cs3-data-url | $ACCOUNTS_STORAGE_CS3_DATA_URL http endpoint of the metadata storage. Default: http://localhost:9216. \u0026ndash;storage-cs3-data-prefix | $ACCOUNTS_STORAGE_CS3_DATA_PREFIX path prefix for the http endpoint of the metadata storage, without leading slash. Default: data. \u0026ndash;storage-cs3-jwt-secret | $ACCOUNTS_STORAGE_CS3_JWT_SECRET Used to create JWT to talk to reva, should equal reva\u0026rsquo;s jwt-secret. Default: Pive-Fumkiu4. \u0026ndash;service-user-uuid | $ACCOUNTS_SERVICE_USER_UUID uuid of the internal service user (required on EOS). Default: 95cb8724-03b2-11eb-a0a6-c33ef8ef53ad. \u0026ndash;service-user-username | $ACCOUNTS_SERVICE_USER_USERNAME username of the internal service user (required on EOS). accounts add Create a new account\nUsage: accounts add [command options] [arguments...]\naccounts list List existing accounts\nUsage: accounts list [command options] [arguments...]\n \u0026ndash;grpc-namespace | $ACCOUNTS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $ACCOUNTS_NAME service name. Default: accounts. accounts version Print the versions of the running instances\nUsage: accounts version [command options] [arguments...]\n \u0026ndash;grpc-namespace | $ACCOUNTS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $ACCOUNTS_NAME service name. Default: accounts. accounts update Make changes to an existing account\nUsage: accounts update [command options] [arguments...]\naccounts remove Removes an existing account\nUsage: accounts remove [command options] [arguments...]\n \u0026ndash;grpc-namespace | $ACCOUNTS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $ACCOUNTS_NAME service name. Default: accounts. accounts rebuildIndex Rebuilds the service\u0026rsquo;s index, i.e. deleting and then re-adding all existing documents\nUsage: accounts rebuildIndex [command options] [arguments...]\naccounts ocis-accounts Provide accounts and groups for oCIS\nUsage: accounts ocis-accounts [command options] [arguments...]\n \u0026ndash;log-level | $ACCOUNTS_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $ACCOUNTS_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $ACCOUNTS_LOG_COLOR Enable colored logging. Default: true. accounts inspect Show detailed data on an existing account\nUsage: accounts inspect [command options] [arguments...]\n \u0026ndash;grpc-namespace | $ACCOUNTS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $ACCOUNTS_NAME service name. Default: accounts. "});index.add({'id':29,'href':'/ocis/deployment/','title':"Deployment",'parent':"oCIS - ownCloud Infinite Scale",'content':" Deployments scenarios and examples Setup oCIS on your server Migrate an existing ownCloud 10 Deployments scenarios and examples This section handles deployments and operations for admins and people who are interested in how versatile oCIS is. If you want to just try oCIS you may also follow Getting started.\nSetup oCIS on your server oCIS deployments are super simple, yet there are many configurations possible for advanced setups.\n Basic oCIS setup - configure domain, certificates and port oCIS setup with Traefik for SSL termination oCIS setup with Keycloak as identity provider Migrate an existing ownCloud 10 You can run ownCloud 10 and oCIS together. This allows you to use new parts of oCIS already with ownCloud 10 and also to have a smooth transition for users from ownCloud 10 to oCIS.\n ownCloud 10 setup with oCIS serving ownCloud Web and acting as OIDC provider - This allows you to switch between the traditional ownCloud 10 frontend and the new ownCloud Web frontend Run ownCloud 10 and oCIS in parallel - together Migrate users from ownCloud 10 to oCIS "});index.add({'id':30,'href':'/extensions/accounts/','title':"Accounts",'parent':"Extensions",'content':"Abstract oCIS needs to be able to identify users. Without a non reassignable and persistent account ID share metadata cannot be reliably persisted. accounts allows exchanging oidc claims for a uuid. Using a uuid allows users to change the login, mail or even openid connect provider without breaking any persisted metadata that might have been attached to it.\n persists accounts uses graph api properties ldap can be synced using the onpremise* attributes Table of Contents Configuration "});index.add({'id':31,'href':'/extensions/ocis_hello/building/','title':"Building",'parent':"Hello",'content':" Frontend Backend As this project is built with Go and NodeJS, so you need to install that first. The installation of Go and NodeJS is out of the scope of this document, please follow the official documentation for Go, NodeJS and Yarn, to build this project you have to install Go \u0026gt;= v1.13. After the installation of the required tools you need to get the sources:\ngit clone https://github.com/owncloud/ocis-hello.git cd ocis-hello All required tool besides Go itself and make are bundled or getting automatically installed within the GOPATH. All commands to build this project are part of our Makefile and respectively our package.json.\nFrontend yarn install yarn build The above commands will install the required build dependencies and build the whole frontend bundle. This bundle will we embeded into the binary later on.\nBackend make generate make build The above commands will embed the frontend bundle into the binary. Finally you should have the binary within the bin/ folder now, give it a try with ./bin/ocis-hello -h to see all available options.\n"});index.add({'id':32,'href':'/clients/web/building/','title':"Building from source",'parent':"ownCloud Web",'content':" Building ownCloud Web Updating dependencies Cleaning up the workspace Building the documentation Setting up Viewing the documentation Deploying the documentation Building ownCloud Web Run yarn install to install core dependencies Run yarn install-all to install dependencies of all apps and core Run yarn dist to build Web and all apps included in the apps folder Updating dependencies Run yarn upgrade-all to update core and app dependencies Cleaning up the workspace Run yarn clean-all to remove node_modules and dist folder Building the documentation Setting up Install hugo Run make docs Viewing the documentation To view the rendered docs in the browser run:\ncd hugo hugo -D server Then open \u0026ldquo;http://localhost:1313/\u0026rdquo;\nWhen making changes to the docs, run make docs again and the server will pick up the changes and reload the page automatically\nDeploying the documentation The documentation is automatically deployed from the master branch to https://owncloud.github.io/web/\n"});index.add({'id':33,'href':'/extensions/glauth/configuration-hints/','title':"Configuration Hints",'parent':"GLAuth",'content':" Configuration hints Configuration hints The default setup does not use a fallback backend. It can be enabled by setting the GLAUTH_FALLBACK_DATASTORE environment variable.\nWhen using owncloud make sure to use the full URL to the ownCloud 10 graph api app endpoint, eg.: GLAUTH_FALLBACK_SERVERS=\u0026quot;https://demo.owncloud.com/apps/graphapi/v1.0\u0026quot;\n"});index.add({'id':34,'href':'/extensions/onlyoffice/getting-started/','title':"Getting Started",'parent':"OnlyOffice",'content':" Installation Docker Binaries Configuration ownCloud Web configuration Envrionment variables Global Server Health Commandline flags Global Server Health Configuration file Usage Server Health Metrics Installation So far we are offering two different variants for the installation. You can choose between Docker or pre-built binaries which are stored on our download mirrors and GitHub releases. Maybe we will also provide system packages for the major distributions later if we see the need for it.\nDocker TBD\nBinaries TBD\nConfiguration We provide overall three different variants of configuration. The variant based on environment variables and commandline flags are split up into global values and command-specific values.\nownCloud Web configuration When loading the extension in the ownCloud Web, it is necessary to specify to which ownCloud 10 server the extension is supposed to connect to. This can be done via config object when registering the extension in config.json. For more details, you can take a look at the following example:\n\u0026#34;external_apps\u0026#34;: [ { \u0026#34;id\u0026#34;: \u0026#34;onlyoffice\u0026#34;, \u0026#34;path\u0026#34;: \u0026#34;https://localhost:9200/onlyoffice.js\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;server\u0026#34;: \u0026#34;https://oc10.example.org\u0026#34; } } ] Envrionment variables If you prefer to configure the service with environment variables you can see the available variables below.\nGlobal ONLYOFFICE_CONFIG_FILE Path to config file, empty default value ONLYOFFICE_LOG_LEVEL Set logging level, defaults to info ONLYOFFICE_LOG_COLOR Enable colored logging, defaults to true ONLYOFFICE_LOG_PRETTY Enable pretty logging, defaults to true Server ONLYOFFICE_TRACING_ENABLED Enable sending traces, defaults to false ONLYOFFICE_TRACING_TYPE Tracing backend type, defaults to jaeger ONLYOFFICE_TRACING_ENDPOINT Endpoint for the agent, empty default value ONLYOFFICE_TRACING_COLLECTOR Endpoint for the collector, empty default value ONLYOFFICE_TRACING_SERVICE Service name for tracing, defaults to onlyoffice ONLYOFFICE_DEBUG_ADDR Address to bind debug server, defaults to 0.0.0.0:9224 ONLYOFFICE_DEBUG_TOKEN Token to grant metrics access, empty default value ONLYOFFICE_DEBUG_PPROF Enable pprof debugging, defaults to false ONLYOFFICE_DEBUG_ZPAGES Enable zpages debugging, defaults to false ONLYOFFICE_HTTP_ADDR Address to bind http server, defaults to 0.0.0.0:9220 ONLYOFFICE_HTTP_NAMESPACE The http namespace ONLYOFFICE_HTTP_ROOT Root path of http server, defaults to / Health ONLYOFFICE_DEBUG_ADDR Address to debug endpoint, defaults to 0.0.0.0:9224 Commandline flags If you prefer to configure the service with commandline flags you can see the available variables below.\nGlobal \u0026ndash;config-file | $ONLYOFFICE_CONFIG_FILE Path to config file. \u0026ndash;log-level | $ONLYOFFICE_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $ONLYOFFICE_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $ONLYOFFICE_LOG_COLOR Enable colored logging. Default: true. Server \u0026ndash;tracing-enabled | $ONLYOFFICE_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $ONLYOFFICE_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $ONLYOFFICE_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $ONLYOFFICE_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $ONLYOFFICE_TRACING_SERVICE Service name for tracing. Default: onlyoffice. \u0026ndash;debug-addr | $ONLYOFFICE_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9224. \u0026ndash;debug-token | $ONLYOFFICE_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $ONLYOFFICE_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $ONLYOFFICE_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $ONLYOFFICE_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9220. \u0026ndash;http-namespace | $ONLYOFFICE_HTTP_NAMESPACE Set the base namespace for the http namespace. Default: com.owncloud.web. \u0026ndash;http-root | $ONLYOFFICE_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;asset-path | $ONLYOFFICE_ASSET_PATH Path to custom assets. Health \u0026ndash;debug-addr | $ONLYOFFICE_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9224. Configuration file So far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/onlyoffice.yml, ${HOME}/.ocis/onlyoffice.yml or $(pwd)/config/onlyoffice.yml.\nUsage The program provides a few sub-commands on execution. The available configuration methods have already been mentioned above. Generally you can always see a formated help output if you execute the binary via ocis-onlyoffice --help.\nServer The server command is used to start the http and debug server on two addresses within a single process. The http server is serving the general webservice while the debug server is used for health check, readiness check and to server the metrics mentioned below. For further help please execute:\nocis-onlyoffice server --help Health The health command is used to execute a health check, if the exit code equals zero the service should be up and running, if the exist code is greater than zero the service is not in a healthy state. Generally this command is used within our Docker containers, it could also be used within Kubernetes.\nocis-onlyoffice health --help Metrics This service provides some Prometheus metrics through the debug endpoint, you can optionally secure the metrics endpoint by some random token, which got to be configured through one of the flag --debug-token or the environment variable ONLYOFFICE_DEBUG_TOKEN mentioned above. By default the metrics endpoint is bound to http://0.0.0.0:9224/metrics.\n go_gc_duration_seconds A summary of the GC invocation durations go_gc_duration_seconds_sum A summary of the GC invocation durations go_gc_duration_seconds_count A summary of the GC invocation durations go_goroutines Number of goroutines that currently exist go_info Information about the Go environment go_memstats_alloc_bytes Number of bytes allocated and still in use go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table go_memstats_frees_total Total number of frees go_memstats_gc_cpu_fraction The fraction of this program\u0026rsquo;s available CPU time used by the GC since the program started go_memstats_gc_sys_bytes Number of bytes used for garbage collection system metadata go_memstats_heap_alloc_bytes Number of heap bytes allocated and still in use go_memstats_heap_idle_bytes Number of heap bytes waiting to be used go_memstats_heap_inuse_bytes Number of heap bytes that are in use go_memstats_heap_objects Number of allocated objects go_memstats_heap_released_bytes Number of heap bytes released to OS go_memstats_heap_sys_bytes Number of heap bytes obtained from system go_memstats_last_gc_time_seconds Number of seconds since 1970 of last garbage collection go_memstats_lookups_total Total number of pointer lookups go_memstats_mallocs_total Total number of mallocs go_memstats_mcache_inuse_bytes Number of bytes in use by mcache structures go_memstats_mcache_sys_bytes Number of bytes used for mcache structures obtained from system go_memstats_mspan_inuse_bytes Number of bytes in use by mspan structures go_memstats_mspan_sys_bytes Number of bytes used for mspan structures obtained from system go_memstats_next_gc_bytes Number of heap bytes when next garbage collection will take place go_memstats_other_sys_bytes Number of bytes used for other system allocations go_memstats_stack_inuse_bytes Number of bytes in use by the stack allocator go_memstats_stack_sys_bytes Number of bytes obtained from system for stack allocator go_memstats_sys_bytes Number of bytes obtained from system go_threads Number of OS threads created promhttp_metric_handler_requests_in_flight Current number of scrapes being served promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code "});index.add({'id':35,'href':'/extensions/glauth/','title':"GLAuth",'parent':"Extensions",'content':"This service provides a glauth based LDAP proxy for ocis which can be used by clients or other extensions. It allows applications relying on LDAP to access the accounts stored in the ocis accounts service. It can be used to make firewalls or identity providers aware of all users, including guest accounts.\nWe are using it to make eos aware of all accounts so the native ACLs can be used to persist share information in the storage.\n"});index.add({'id':36,'href':'/extensions/ocs/','title':"Ocs",'parent':"Extensions",'content':"This service provides the OCS API which is required by some ownCloud clients.\n"});index.add({'id':37,'href':'/extensions/web/','title':"ownCloud Web",'parent':"Extensions",'content':"This service embeds ownCloud Web to provide a UI for ownCloud Infinite Scale.\n"});index.add({'id':38,'href':'/extensions/settings/','title':"Settings",'parent':"Extensions",'content':"Abstract When using oCIS, the requirement to store settings arises. This extension provides functionality for other extensions to register new settings within oCIS. It is responsible for storing the respective settings values as well.\nFor ease of use, this extension provides an ocis-web extension which allows users to change their settings values. Please refer to the ocis-web extension docs for running ocis-web extensions.\n document.addEventListener(\"DOMContentLoaded\", function(event) { mermaid.initialize({ flowchart: { useMaxWidth: true } }); }); graph TD subgraph ow[ocis-web] ows[ocis-web-settings] owc[ocis-web-core] end ows ---|\"listSettingsBundles(),\nsaveSettingsValue(value)\"| os[ocis-settings] owc ---|\"listSettingsValues()\"| sdk[oC SDK] sdk --- sdks{ocis-settings\navailable?} sdks ---|\"yes\"| os sdks ---|\"no\"| defaults[Use set of\ndefault values] oa[oCIS extensions\ne.g. ocis-accounts] ---|\"saveSettingsBundle(bundle)\"| os The diagram shows how the settings service integrates into oCIS:\nSettings management:\n oCIS extensions can register settings bundles with the ocis-settings service. The settings frontend can be plugged into ocis-web, showing forms for changing settings values as a user. The forms are generated from the registered settings bundles. Settings usage:\n Extensions can query ocis-settings for settings values of a user. The ownCloud SDK, used as a data abstraction layer for ocis-web, will query ocis-settings for settings values of a user, if it\u0026rsquo;s available. The SDK uses sensible defaults when ocis-settings is not part of the setup. For compatibility with ownCloud 10, a migration of ownCloud 10 settings into the storage of ocis-settings will be available.\n"});index.add({'id':39,'href':'/extensions/storage/','title':"Storage",'parent':"Extensions",'content':"This service provides an ocis extension that wraps reva and adds an opinionated configuration to it.\nIt uses the port range 9140-9179 to preconfigure several services.\n port service 9109 health? 9140 frontend 9141 frontend debug 9142 gateway 9143 gateway debug 9144 users 9145 users debug 9146 authbasic 9147 authbasic debug 9148 authbearer 9149 authbearer debug 9150 sharing 9151 sharing debug 9152 storage root 9153 storage root debug 9154 storage home 9155 storage home debug 9156 storage home data 9157 storage home data debug 9158 storage eos 9159 storage eos debug 9160 storage eos data 9161 storage eos data debug 9162 storage oc 9163 storage oc debug 9164 storage oc data 9165 storage oc data debug 9166-9177 reserved for s3, wnd, custom + data providers 9178 storage public link 9179 storage public link data "});index.add({'id':40,'href':'/extensions/store/','title':"Store",'parent':"Extensions",'content':"This service provides \u0026hellip;\n"});index.add({'id':41,'href':'/extensions/thumbnails/','title':"Thumbnails",'parent':"Extensions",'content':"This service provides an ocis extensions which generates thumbnails for image files.\n"});index.add({'id':42,'href':'/extensions/webdav/','title':"WebDaV",'parent':"Extensions",'content':"This service provides the WebDAV API which is required by some ownCloud clients.\n"});index.add({'id':43,'href':'/ocis/deployment/ocis_keycloak/','title':"oCIS with Keycloak",'parent':"Deployment",'content':" Overview Server Deployment Requirements Install oCIS and Traefik Local setup Overview oCIS and Keycloak running behind Traefik as reverse proxy Keycloak acting as the IDP for oCIS Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup Find this example on GitHub\nThe docker stack consists 4 containers. One of them is Traefik, a proxy which is terminating ssl and forwards the requests to oCIS in the internal docker network.\nKeykloak add two containers: Keycloak itself and a PostgreSQL as database. Keycloak will be configured as oCIS\u0026rsquo; IDP instead of the internal IDP Konnectd\nThe other container is oCIS itself running all extensions in one container. In this example oCIS uses oCIS storage driver\nServer Deployment Requirements Linux server with docker and docker-compose installed Three domains set up and pointing to your server ocis.* for serving oCIS keycloak.* for serving Keycloak traefik.* for serving the Traefik dashboard See also example server setup\nInstall oCIS and Traefik Clone oCIS repository\ngit clone https://github.com/owncloud/ocis.git\n Go to the deployment example\ncd ocis/deployment/examples/ocis_keycloak\n Open the .env file in a text editor The file by default looks like this:\n# If you\u0026#39;re on a internet facing server please comment out following line. # It skips certificate validation for various parts of oCIS and is needed if you use self signed certificates. INSECURE=true ### Traefik settings ### # Domain of Traefik, where you can find the dashboard. Defaults to \u0026#34;traefik.owncloud.test\u0026#34; TRAEFIK_DOMAIN= # Basic authentication for the dashboard. Defaults to user \u0026#34;admin\u0026#34; and password \u0026#34;admin\u0026#34; TRAEFIK_BASIC_AUTH_USERS= # Email address for obtaining LetsEncrypt certificates, needs only be changed if this is a public facing server TRAEFIK_ACME_MAIL= ### oCIS settings ### # oCIS version. Defaults to \u0026#34;latest\u0026#34; OCIS_DOCKER_TAG= # Domain of oCIS, where you can find the frontend. Defaults to \u0026#34;ocis.owncloud.test\u0026#34; OCIS_DOMAIN= # ownCloud Web openid connect client id. Defaults to \u0026#34;ocis-web\u0026#34; OCIS_OIDC_CLIENT_ID= ### Keycloak ### # Domain of Keycloak, where you can find the managment and authentication frontend. Defaults to \u0026#34;keycloak.owncloud.test\u0026#34; KEYCLOAK_DOMAIN= # Realm which to be used with oCIS. Defaults to \u0026#34;master\u0026#34; KEYCLOAK_REALM= # Admin user login name. Defaults to \u0026#34;admin\u0026#34; KEYCLOAK_ADMIN_USER= # Admin user login password. Defaults to \u0026#34;admin\u0026#34; KEYCLOAK_ADMIN_PASSWORD= You are installing oCIS on a server and Traefik will obtain valid certificates for you so please remove INSECURE=true or set it to false.\nSet your domain for the Traefik dasboard in TRAEFIK_DOMAIN= eg. TRAEFIK_DOMAIN=traefik.owncloud.test.\nThe Traefik dasboard is secured by basic auth. Default credentials are the user admin with the password admin. To set your own credentials, generate a htpasswd (eg. by using an online tool or a cli tool).\nTraefik will issue certificates with LetsEncrypt and therefore you must set an email address in TRAEFIK_ACME_MAIL=.\nBy default ocis will be started in the latest version. If you want to start a specific version of oCIS set the version to OCIS_DOCKER_TAG=. Available versions can be found on Docker Hub.\nSet your domain for the oCIS frontend in OCIS_DOMAIN=, eg. OCIS_DOMAIN=ocis.owncloud.test.\nIf you want to change the OIDC client id of th ownCloud Web frontend, you can do this by setting the name to OCIS_OIDC_CLIENT_ID=.\nSet your domain for the Keycloak adminstration panel and authentication endpoints to KEYCLOAK_DOMAIN= eg. KEYCLOAK_DOMAIN=keycloak.owncloud.test.\nChanging the used Keycloak realm can be done by setting KEYCLOAK_REALM=. This defaults to the master realm KEYCLOAK_REALM=master.\nYou probably should secure your Keycloak admin account by setting KEYCLOAK_ADMIN_USER= and KEYCLOAK_ADMIN_PASSWORD= to values other than admin.\nNow you have configured everything and can save the file.\n Start the docker stack\ndocker-compose up -d\n Visit the Keycloak administration console on your configured domain. Go to clients settings and add a client. The client id is ocis-web or the one you changed it to. The client protocol is openid-connect. The root url for the client is the url you selected for oCIS. Then save the client.\n You may also add users to Keycloak\n You now can visit oCIS and Traefik dashboard on your configured domains\n Local setup For a more simple local ocis setup see Getting started\nThis docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.\nOn Linux and macOS you can add them to your /etc/hosts files like this:\n127.0.0.1 ocis.owncloud.test 127.0.0.1 traefik.owncloud.test 127.0.0.1 keycloak.owncloud.test After that you\u0026rsquo;re ready to start the application stack:\ndocker-compose up -d\nOpen https://keycloak.owncloud.test in your browser and accept the invalid certificate warning. Go to clients settings and add a client. The client id is ocis-web or the one you changed it to. The client protocol is openid-connect. THe root url for the client is https://ocis.owncloud.test. Then save the client.\n You may also add users to Keycloak Open https://ocis.owncloud.test in your browser and accept the invalid certificate warning. You now can login to oCIS with the admin user of keycloak and additional users you created.\n"});index.add({'id':44,'href':'/ocis/deployment/ocis_traefik/','title':"oCIS with Traefik",'parent':"Deployment",'content':" Overview Server Deployment Requirements Install oCIS and Traefik Local setup Overview oCIS running behind Traefik as reverse proxy Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup Find this example on GitHub\nThe docker stack consists of two containers. One of them is Traefik, a proxy which is terminating ssl and forwards the requests to oCIS in the internal docker network.\nThe other one is oCIS itself running all extensions in one container. In this example oCIS uses its internal IDP Konnectd and the oCIS storage driver\nServer Deployment Requirements Linux server with docker and docker-compose installed Two domains set up and pointing to your server ocis.* for serving oCIS traefik.* for serving the Traefik dashboard See also example server setup\nInstall oCIS and Traefik Clone oCIS repository\ngit clone https://github.com/owncloud/ocis.git\n Go to the deployment example\ncd ocis/deployment/examples/ocis_traefik\n Open the .env file in a text editor The file by default looks like this:\n# If you\u0026#39;re on a internet facing server please comment out following line. # It skips certificate validation for various parts of oCIS and is needed if you use self signed certificates. INSECURE=true ### Traefik settings ### # Domain of Traefik, where you can find the dashboard. Defaults to \u0026#34;traefik.owncloud.test\u0026#34; TRAEFIK_DOMAIN= # Basic authentication for the dashboard. Defaults to user \u0026#34;admin\u0026#34; and password \u0026#34;admin\u0026#34; TRAEFIK_BASIC_AUTH_USERS= # Email address for obtaining LetsEncrypt certificates, needs only be changed if this is a public facing server TRAEFIK_ACME_MAIL= ### oCIS settings ### # oCIS version. Defaults to \u0026#34;latest\u0026#34; OCIS_DOCKER_TAG= # Domain of oCIS, where you can find the frontend. Defaults to \u0026#34;ocis.owncloud.test\u0026#34; OCIS_DOMAIN= You are installing oCIS on a server and Traefik will obtain valid certificates for you so please remove INSECURE=true or set it to false.\nSet your domain for the Traefik dasboard in TRAEFIK_DOMAIN= eg. TRAEFIK_DOMAIN=traefik.owncloud.test.\nThe Traefik dasboard is secured by basic auth. Default credentials are the user admin with the password admin. To set your own credentials, generate a htpasswd (eg. by using an online tool or a cli tool).\nTraefik will issue certificates with LetsEncrypt and therefore you must set an email address in TRAEFIK_ACME_MAIL=.\nBy default ocis will be started in the latest version. If you want to start a specific version of oCIS set the version to OCIS_DOCKER_TAG=. Available versions can be found on Docker Hub.\nSet your domain for the oCIS frontend in OCIS_DOMAIN=, eg. OCIS_DOMAIN=ocis.owncloud.test.\nNow you have configured everything and can save the file.\n Start the docker stack\ndocker-compose up -d\n You now can visit oCIS and Traefik dashboard on your configured domains\n Local setup For a more simple local ocis setup see Getting started\nThis docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.\nOn Linux and macOS you can add them to your /etc/hosts files like this:\n127.0.0.1 ocis.owncloud.test 127.0.0.1 traefik.owncloud.test After that you\u0026rsquo;re ready to start the application stack:\ndocker-compose up -d\nOpen https://ocis.owncloud.test in your browser and accept the invalid certificate warning. You now can login to oCIS with the default users, which also can be found here: Getting started\n"});index.add({'id':45,'href':'/ocis/deployment/owncloud10_with_oc_web/','title':"ownCloud 10 with ownCloud Web",'parent':"Deployment",'content':" Overview Server Deployment Requirements Install oCIS and Traefik Local setup This deployment scenario shows how to use ownCloud Web as frontend for an existing ownCloud 10 production installation. It enables ownCloud 10 users to log in and work with their files using the new ownCloud Web. While the scenario includes an ownCloud 10 instance, it only exists to show the necessary configuration for your already existing ownCloud 10 installation.\nOverview oCIS setup serving ownCloud Web oCIS acting as OIDC IDP on the ownCloud 10 user database ownCloud 10 setup connected to oCIS DNS is resolving one domain for ocis and one for oc10 Valid ssl certificates for the domains for ssl termination Find this example on GitHub\nIn this setup it\u0026rsquo;s mandatory that the users in ownCloud 10 are assigned to at least one group. In this setup relies on graph-api app to be installed in ownCloud 10. This app is included by default beginning with ownCloud 10.6. If you are on a lower version, please install it manually. Server Deployment Requirements Linux server with docker and docker-compose installed Three domains set up and pointing to your server ocis.* for serving oCIS oc10.* for serving traefik.* for serving the Traefik dashboard See also example server setup\nInstall oCIS and Traefik Clone oCIS repository\ngit clone https://github.com/owncloud/ocis.git\n Go to the deployment example\ncd ocis/deployment/examples/ocis_oc10_backend\n Open the .env file in a text editor The file by default looks like this:\n# If you\u0026#39;re on a internet facing server please comment out following line. # It skips certificate validation for various parts of oCIS and is needed if you use self signed certificates. INSECURE=true ### Traefik settings ### # Domain of Traefik, where you can find the dashboard. Defaults to \u0026#34;traefik.owncloud.test\u0026#34; TRAEFIK_DOMAIN= # Basic authentication for the dashboard. Defaults to user \u0026#34;admin\u0026#34; and password \u0026#34;admin\u0026#34; TRAEFIK_BASIC_AUTH_USERS= # Email address for obtaining LetsEncrypt certificates, needs only be changed if this is a public facing server TRAEFIK_ACME_MAIL= ### oCIS settings ### # oCIS version. Defaults to \u0026#34;latest\u0026#34; OCIS_DOCKER_TAG= # Domain of oCIS, where you can find the frontend. Defaults to \u0026#34;ocis.owncloud.test\u0026#34; OCIS_DOMAIN= ### oC10 ### # Domain of ownCloud 10, where you can find the frontend. Defaults to \u0026#34;oc10.owncloud.test\u0026#34; #OC10_DOMAIN= You are installing oCIS on a server and Traefik will obtain valid certificates for you so please remove INSECURE=true or set it to false.\nSet your domain for the Traefik dasboard in TRAEFIK_DOMAIN= eg. TRAEFIK_DOMAIN=traefik.owncloud.test.\nThe Traefik dasboard is secured by basic auth. Default credentials are the user admin with the password admin. To set your own credentials, generate a htpasswd (eg. by using an online tool or a cli tool).\nTraefik will issue certificates with LetsEncrypt and therefore you must set an email address in TRAEFIK_ACME_MAIL=.\nBy default ocis will be started in the latest version. If you want to start a specific version of oCIS set the version to OCIS_DOCKER_TAG=. Available versions can be found on Docker Hub.\nSet your domain for the oCIS frontend in OCIS_DOMAIN=, eg. OCIS_DOMAIN=ocis.owncloud.test.\nSet your domain for the ownCloud 10 frontend in OC10_DOMAIN= eg. OC10_DOMAIN=oc10.owncloud.test.\nNow you have configured everything and can save the file.\n Start the docker stack\ndocker-compose up -d\n You now can visit oCIS and Traefik dashboard on your configured domains\n Local setup For a more simple local ocis setup see Getting started\nThis docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.\nOn Linux and macOS you can add them to your /etc/hosts files like this:\n127.0.0.1 ocis.owncloud.test 127.0.0.1 oc10.owncloud.test 127.0.0.1 traefik.owncloud.test After that you\u0026rsquo;re ready to start the application stack:\ndocker-compose up -d\nOpen https://oc10.owncloud.test in your browser and accept the invalid certificate warning. You now can login with the ownCloud 10 default user \u0026ldquo;admin\u0026rdquo; and password \u0026ldquo;admin\u0026rdquo;. As you might have noticed, you did not see the login prompt of ownCloud 10. This was the login prompt of oCIS. When you go to application you can both in ownCloud Web and ownCloud 10 see a switch to switch vice versa.\n"});index.add({'id':46,'href':'/clients/web/releasing/','title':"Releasing",'parent':"ownCloud Web",'content':" Releasing ownCloud Web Package Hierarchy Releasing Web Frontend Next steps Releasing ownCloud Web The ownCloud Web is shipped as an ocis Extension. The ocis-web extension is also embedded in the single binary and part of the ocis server command.\nThis repository contains the assets and these must be released first before being bundled into ocis-web.\nPackage Hierarchy ocis ocis-web ocis-pkg web Releasing Web Frontend Create a branch release-$version in https://github.com/owncloud/web. Create a folder in changelog for the release version and date mkdir $major.$minor.$patchVersion_YYYY-MM-DD. Move all changelog items from the changelog/unreleased/ folder to the $major.$minor.$patchVersion_YYYY-MM-DD folder. Commit your changes. After merging, wait for the CI to run on the merge commit. Go to the Releases section and click \u0026ldquo;Draft a new Release\u0026rdquo;. Use v$major.$minor.$patch as a tag (the v prefix is important) and publish it. The tag and the Release artifacts will be created automatically. Next steps The next steps are usually to update the Web assets in the ocis-web repository.\n"});index.add({'id':47,'href':'/ocis/flow-docs/','title':"Flow documentation",'parent':"oCIS - ownCloud Infinite Scale",'content':""});index.add({'id':48,'href':'/ocis/deployment/bridge/','title':"Bridge",'parent':"Deployment",'content':" Current status How to do it Install the owncloud 10 graphapi app Enable the graphapi app Start ocis-glauth Grab it! Run it! Check it is up and running Start ocis-web Get it! Run it! Start ocis-konnectd Get it! Set environment variables Configure clients Run it! Check it is up and running Patch owncloud Install the owncloud 10 openidconnect app Next steps We are planning to build a bridge from ownCloud 10 to ocis. The idea is to have a reverse proxy infront of ownCloud 10 that will forward requests to ownCloud 10 or ocis-reva, depending on the migration status of the logged in user.\nThis document is a work in progress of the current setup.\nCurrent status Using ocis and the ownCloud 10 openidconnect and graphapi plugins it is possible today to introduce openid connect based authentication to existing instances. That is a prerequisite for migrating to ocis.\nHow to do it Install the owncloud 10 graphapi app In an owncloud 10 apps folder\n$ git clone git@github.com:owncloud/graphapi.git $ cd graphapi $ composer install Enable the graphapi app occ a:e graphapi No configuration necessary. You can test with curl:\n$ curl https://cloud.example.com/index.php/apps/graphapi/v1.0/users -u admin | jq Enter host password for user \u0026#39;admin\u0026#39;: % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 694 100 694 0 0 4283 0 --:--:-- --:--:-- --:--:-- 4283 { \u0026#34;value\u0026#34;: [ { \u0026#34;id\u0026#34;: \u0026#34;admin\u0026#34;, \u0026#34;displayName\u0026#34;: \u0026#34;admin\u0026#34;, \u0026#34;mail\u0026#34;: null }, { \u0026#34;id\u0026#34;: \u0026#34;demo\u0026#34;, \u0026#34;displayName\u0026#34;: \u0026#34;Demo\u0026#34;, \u0026#34;mail\u0026#34;: null }, ... ], \u0026#34;@odata.nextLink\u0026#34;: \u0026#34;https://oc.butonic.de/apps/graphapi/v1.0/users?$top=10\u0026amp;$skip=10\u0026#34; } Note: The MS graph api actually asks for Bearer auth, but in order to check users passwords during an LDAP bind we are exploiting ownClouds authentication implementation that will grant access when Basic auth is used. An LDAP Bind you may ask? Read on!\n Start ocis-glauth We are going to use the above ownCloud 10 and graphapi app to turn it into the datastore for an LDAP proxy.\nGrab it! In an ocis folder\n$ git clone git@github.com:owncloud/ocis-glauth.git $ cd ocis-glauth $ make This should give you a bin/ocis-glauth binary. Try listing the help with bin/ocis-glauth --help.\nRun it! You need to point ocis-glauth to your owncloud domain:\n$ bin/ocis-glauth --log-level debug server --backend-datastore owncloud --backend-server https://cloud.example.com --backend-basedn dc=example,dc=com --log-level debug is only used to generate more verbose output --backend-datastore owncloud switches to tho owncloud datastore --backend-server https://cloud.example.com is the url to an ownCloud instance with an enabled graphapi app --backend-basedn dc=example,dc=com is used to construct the LDAP dn. The user admin will become cn=admin,dc=example,dc=com.\nCheck it is up and running You should now be able to list accounts from your ownCloud 10 oc_accounts table using:\n$ ldapsearch -x -H ldap://localhost:9125 -b dc=example,dc=com -D \u0026#34;cn=admin,dc=example,dc=com\u0026#34; -W \u0026#39;(objectclass=posixaccount)\u0026#39; Groups should work as well:\n$ ldapsearch -x -H ldap://localhost:9125 -b dc=example,dc=com -D \u0026#34;cn=admin,dc=example,dc=com\u0026#34; -W \u0026#39;(objectclass=posixgroup)\u0026#39; Note: This is currently a readonly implementation and minimal to the usecase of authenticating users with konnectd.\n Start ocis-web Get it! In an ocis folder\n$ git clone git@github.com:owncloud/ocis.git $ cd web $ make This should give you a bin/web binary. Try listing the help with bin/web --help.\nRun it! Point ocis-web to your owncloud domain and tell it where to find the openid connect issuing authority:\n$ bin/web server --web-config-server https://cloud.example.com --oidc-authority https://192.168.1.100:9130 --oidc-metadata-url https://192.168.1.100:9130/.well-known/openid-configuration --oidc-client-id ocis ocis-web needs to know\n --web-config-server https://cloud.example.com is ownCloud url with webdav and ocs endpoints (oc10 or ocis) --oidc-authority https://192.168.1.100:9130 the openid connect issuing authority, in our case oidc-konnectd, running on port 9130 --oidc-metadata-url https://192.168.1.100:9130/.well-known/openid-configuration the openid connect configuration endpoint, typically the issuer host with .well-known/openid-configuration, but there are cases when another endpoint is used, eg. ping identity provides multiple endpoints to separate domains --oidc-client-id ocis the client id we will register later with ocis-konnectd in the identifier-registration.yaml Start ocis-konnectd Get it! In an ocis folder\n$ git clone git@github.com:owncloud/ocis-konnectd.git $ cd ocis-konnectd $ make This should give you a bin/ocis-konnectd binary. Try listing the help with bin/ocis-konnectd --help.\nSet environment variables Konnectd needs environment variables to configure the LDAP server:\nexport LDAP_URI=ldap://192.168.1.100:9125 export LDAP_BINDDN=\u0026#34;cn=admin,dc=example,dc=com\u0026#34; export LDAP_BINDPW=\u0026#34;its-a-secret\u0026#34; export LDAP_BASEDN=\u0026#34;dc=example,dc=com\u0026#34; export LDAP_SCOPE=sub export LDAP_LOGIN_ATTRIBUTE=uid export LDAP_EMAIL_ATTRIBUTE=mail export LDAP_NAME_ATTRIBUTE=givenName export LDAP_UUID_ATTRIBUTE=uid export LDAP_UUID_ATTRIBUTE_TYPE=text export LDAP_FILTER=\u0026#34;(objectClass=posixaccount)\u0026#34; Don\u0026rsquo;t forget to use an existing user and the correct password.\nConfigure clients Now we need to configure a client we can later use to configure the ownCloud 10 openidconnect app. In the assets/identifier-registration.yaml have:\n---# OpenID Connect client registry.clients:- id:ocisname:ownCloudInfiniteScaleinsecure:yesapplication_type:webredirect_uris:- https://cloud.example.com/apps/openidconnect/redirect- http://localhost:9100/oidc-callback.html- http://localhost:9100- http://localhost:9100/You will need the insecure: yes if you are using self signed certificates.\nReplace cloud.example.com in the redirect URI with your ownCloud 10 host and port. Replace localhost:9100 in the redirect URIs with your ocis-web host and port.\nRun it! You can now bring up ocis-konnectd with:\n$ bin/ocis-konnectd server --iss https://192.168.1.100:9130 --identifier-registration-conf assets/identifier-registration.yaml --signing-kid gen1-2020-02-27 ocis-konnectd needs to know\n --iss https://192.168.1.100:9130 the issuer, which must be a reachable https endpoint. For testing an ip works. HTTPS is NOT optional. This url is exposed in the https://192.168.1.100:9130/.well-known/openid-configuration endpoint and clients need to be able to connect to it --identifier-registration-conf assets/identifier-registration.yaml the identifier-registration.yaml you created --signing-kid gen1-2020-02-27 a signature key id, otherwise the jwks key has no name, which might cause problems with clients. a random key is ok, but it should change when the actual signing key changes. Check it is up and running Try getting the configuration: $ curl https://192.168.1.100:9130/.well-known/openid-configuration Check if the login works at https://192.168.1.100:9130/signin/v1/identifier Note: If you later get a Unable to find a key for (algorithm, kid):PS256, ) Error make sure you did set a --signing-kid when starting ocis-konnectd by checking it is present in https://192.168.1.100:9130/konnect/v1/jwks.json\n Patch owncloud While the UserSession in ownCloud 10 is currently used to test all available IAuthModule implementations, it immediately logs out the user when an exception occurs. However, existing owncloud 10 instances use the oauth2 app to create Bearer tokens for mobile and desktop clients.\nTo give the openidconnect app a chance to verify the tokens we need to change the code a bit. See https://github.com/owncloud/core/pull/37043 for a possible solution.\n Note: The PR is hot \u0026hellip; as in younger than this list of steps. And it messes with authentication. Use with caution.\n Install the owncloud 10 openidconnect app In an owncloud 10 apps folder\n$ git clone git@github.com:owncloud/openidconnect.git $ cd openidconnect $ composer install After enabling the app configure it in config/oidc.config.php\n$CONFIG = [ \u0026#39;openid-connect\u0026#39; =\u0026gt; [ \u0026#39;provider-url\u0026#39; =\u0026gt; \u0026#39;https://192.168.1.100:9130\u0026#39;, \u0026#39;client-id\u0026#39; =\u0026gt; \u0026#39;ocis\u0026#39;, \u0026#39;loginButtonName\u0026#39; =\u0026gt; \u0026#39;OpenId Connect @ Konnectd\u0026#39;, ], \u0026#39;debug\u0026#39; =\u0026gt; true, // if using self signed certificates // allow the different domains access to the ocs and wabdav endpoints: \u0026#39;cors.allowed-domains\u0026#39; =\u0026gt; [ \u0026#39;https://cloud.example.com\u0026#39;, \u0026#39;http://localhost:9100\u0026#39;, ], ]; In the above configuration replace\n provider-url with the URL to your ocis-konnectd issuer https://cloud.example.com with the URL to your ownCloud 10 instance http://localhost:9100 with the URL to your ownCloud Web instance Note: By default the openidconnect app will use the email of the user to match the user from the oidc userinfo endpoint with the ownCloud account. So make sure your users have a unique primary email.\n Next steps Aside from the above todos these are the next stepo\n tie it all together behind ocis-proxy create an ocis bridge command that runs all the ocis services in one step with a properly preconfigured ocis-konnectd identifier-registration.yaml file for ownCloud Web and the owncloud 10 openidconnect app, as well as a randomized --signing-kid. "});index.add({'id':49,'href':'/ocis/development/build/','title':"Build",'parent':"Development",'content':" Build requirements Get the sources Build the oCIS binary Build a local oCIS docker image Build requirements see Development - Getting Started\nGet the sources git clone https://github.com/owncloud/ocis.git cd ocis Build the oCIS binary The oCIS binary source is in the ocis folder inside the oCIS repository. In this folder you can build the oCIS binary:\ncd ocis make generate make build After building you have the binary within the bin/ folder. Try to run it: ./bin/ocis -h\nBuild a local oCIS docker image If you are developing and want to run your local changes in a docker or docker-compose setup, you have to build an image locally.\nTherefore run following commands in the root of the oCIS repository:\ndocker build -t owncloud/ocis:dev . Then you can test as usual via\ndocker run --rm -ti owncloud/ocis:dev "});index.add({'id':50,'href':'/ocis/storage-backends/eos/','title':"EOS",'parent':"Storage backends",'content':" Docker dev environment for eos storage 1. Start eos \u0026amp; ocis containers 2. LDAP support 3. Home storage 4. Users storage 5. Metadata storage 6. Accounts service Verification Further exploration Cleaning up Troubleshooting Docker-compose exits right away Where are the logs ? How do I update a service in the ocis container? Creation and upload of files does not work Uploading big files appears to hang Running out of space quickly oCIS can be configured to run on top of eos. While the eos documentation does cover a lot of topics it leaves out some details that you may have to either pull from various docker containers, the forums or even the source itself.\nThis document is a work in progress of the current setup.\nDocker dev environment for eos storage We begin with the docker-compose.yml found in https://github.com/owncloud/ocis/tree/master/ocis/ and switch it to eos-storage.\n1. Start eos \u0026amp; ocis containers Start the eos cluster and ocis via the compose stack.\ndocker-compose up -d The first time the ocis container starts up, it will compile ocis from scratch which can take a while. To follow progress, run docker-compose logs -f --tail=10 ocis 2. LDAP support Configure the OS to resolve users and groups using ldap\ndocker-compose exec -d ocis /start-ldap Check that the OS in the ocis container can now resolve einstein or the other demo users\n$ docker-compose exec ocis id einstein uid=20000(einstein) gid=30000(users) groups=30000(users),30001(sailing-lovers),30002(violin-haters),30007(physics-lovers) If the user is not found at first you might need to wait a few more minutes in case the ocis container is still compiling. We also need to restart the storage-userprovider service, so it picks up the changed environment. Without a restart it is not able to resolve users from LDAP.\ndocker-compose exec ocis ./bin/ocis kill storage-userprovider docker-compose exec ocis ./bin/ocis run storage-userprovider 3. Home storage Kill the home storage. By default it uses the ocis storage driver. We need to switch it to the eoshome driver:\ndocker-compose exec ocis ./bin/ocis kill storage-home docker-compose exec -e STORAGE_HOME_DRIVER=eoshome ocis ./bin/ocis run storage-home 4. Users storage Kill the users storage. By default it uses the ocis storage driver. We need to switch it to the eos driver:\ndocker-compose exec ocis ./bin/ocis kill storage-users docker-compose exec -e STORAGE_USERS_DRIVER=eos ocis ./bin/ocis run storage-users 5. Metadata storage First we need to create the metadata root in eos and set an owner:\ndocker-compose exec ocis eos mkdir -p /eos/dockertest/ocis/metadata docker-compose exec ocis eos chown 2:2 /eos/dockertest/ocis/metadata The uid and gid 2 are referencing the user daemon inside the ocis container. That user is also configured when restarting the accounts service later. For production systems you should create a dedicated user for the metadata storage. Kill the metadata storage. By default it uses the ocis storage driver. We need to switch it to the eos driver:\ndocker-compose exec ocis ./bin/ocis kill storage-metadata docker-compose exec -e STORAGE_METADATA_DRIVER=eos -e STORAGE_METADATA_ROOT=/eos/dockertest/ocis/metadata ocis ./bin/ocis run storage-metadata 6. Accounts service Kill the accounts service. By default it uses the ocis storage driver. We need to switch it to the eos driver:\ndocker-compose exec ocis ./bin/ocis kill accounts docker-compose exec -e ACCOUNTS_SERVICE_USER_USERNAME=daemon -e ACCOUNTS_SERVICE_USER_UID=2 -e ACCOUNTS_SERVICE_USER_GID=2 ocis ./bin/ocis run accounts Verification Login with einstein / relativity, upload a file to einsteins home and verify the file is there using\ndocker-compose exec ocis eos ls -l /eos/dockertest/reva/users/4/4c510ada-c86b-4815-8820-42cdf82c3d51/ -rw-r--r-- 1 einstein users 10 Jul 1 15:24 newfile.txt If the problem persists, please check the troubleshooting section about uploads.\nFurther exploration EOS has a built in shell that you can enter using\n$ docker-compose exec mgm-master eos # --------------------------------------------------------------------------- # EOS Copyright (C) 2011-2019 CERN/Switzerland # This program comes with ABSOLUTELY NO WARRANTY; for details type `license\u0026#39;. # This is free software, and you are welcome to redistribute it # under certain conditions; type `license\u0026#39; for details. # --------------------------------------------------------------------------- EOS_INSTANCE=eostest EOS_SERVER_VERSION=4.6.5 EOS_SERVER_RELEASE=1 EOS_CLIENT_VERSION=4.6.5 EOS_CLIENT_RELEASE=1 EOS Console [root://localhost] |/\u0026gt; help access Access Interface accounting Accounting Interface acl Acl Interface archive Archive Interface attr Attribute Interface backup Backup Interface clear Clear the terminal cd Change directory chmod Mode Interface chown Chown Interface config Configuration System console Run Error Console cp Cp command debug Set debug level exit Exit from EOS console file File Handling fileinfo File Information find Find files/directories newfind Find files/directories (new implementation) fs File System configuration fsck File System Consistency Checking fuse Fuse Mounting fusex Fuse(x) Administration geosched Geoscheduler Interface group Group configuration health Health information about system help Display this text info Retrieve file or directory information inspector Interact with File Inspector io IO Interface json Toggle JSON output flag for stdout license Display Software License ls List a directory ln Create a symbolic link map Path mapping interface member Check Egroup membership mkdir Create a directory motd Message of the day mv Rename file or directory node Node configuration ns Namespace Interface pwd Print working directory quit Exit from EOS console quota Quota System configuration reconnect Forces a re-authentication of the shell recycle Recycle Bin Functionality rmdir Remove a directory rm Remove a file role Set the client role route Routing interface rtlog Get realtime log output from mgm \u0026amp; fst servers silent Toggle silent flag for stdout space Space configuration stagerrm Remove disk replicas of a file if it has tape replicas stat Run \u0026#39;stat\u0026#39; on a file or directory squash Run \u0026#39;squashfs\u0026#39; utility function test Run performance test timing Toggle timing flag for execution time measurement touch Touch a file token Token interface tracker Interact with File Tracker transfer Transfer Interface version Verbose client/server version vid Virtual ID System Configuration whoami Determine how we are mapped on server side who Statistics about connected users ? Synonym for \u0026#39;help\u0026#39; .q Exit from EOS console EOS Console [root://localhost] |/\u0026gt; But this is a different adventure. See the links at the top of this page for other sources of information on eos.\nCleaning up To clean up and start completely from scratch, run docker-compose down -v. Then delete the local \u0026ldquo;bin\u0026rdquo; folder as root which contains the ocis binaries compiled by the \u0026ldquo;ocis\u0026rdquo; docker.\nTroubleshooting Docker-compose exits right away When running docker-compose up -d ocis exits right away.\nYou can check the error code using docker-compose ps and investigate further by running only ocis again using docker-compose up ocis (without -d so you can see what is going on in the foreground). One reason might be that the binary was already built but does not match the container env. Try running make clean before running docker-compose up ocis so it gets built inside the container.\nWhere are the logs ? The ocis logs can be accessed using docker-compose logs ocis. Add -f for following.\nHow do I update a service in the ocis container? docker-compose exec ocis make clean build to update the binary docker-compose exec ocis ./bin/ocis kill \u0026lt;service\u0026gt; to kill the service docker-compose exec ocis ./bin/ocis run \u0026lt;service\u0026gt; to start the service. Do not forget to set any env vars, eg. docker-compose exec -e STORAGE_HOME_DRIVER=eoshome -e STORAGE_DRIVER_EOS_LAYOUT=\u0026quot;{{substr 0 1 .Id.OpaqueId}}/{{.Id.OpaqueId}}\u0026quot; ocis ./bin/ocis run storage-home Creation and upload of files does not work If the upload did not work, please check the status of the eos space using the command docker-compose exec mgm-master eos fs ls. In case the default space appears as offline, run docker-compose exec mgm-master eos space set default on.\nUploading big files appears to hang Please note that the uploads first go into the \u0026ldquo;ocis\u0026rdquo; docker and land in its \u0026ldquo;/tmp\u0026rdquo; folder, then gets copied over to the EOS docker using xrdcopy. This is why uploading first transfers all bytes and then seem to hang for a while during the final copy.\nRunning out of space quickly The EOS dockers are configured with replication, so every file uploaded there will be replicated 4 times, so make sure there is enough physical space on disk when testing.\nAlso please note that older failed uploads might still be present in the \u0026ldquo;/tmp\u0026rdquo; directory of the \u0026ldquo;ocis\u0026rdquo; container.\n"});index.add({'id':51,'href':'/extensions/onlyoffice/building/','title':"Building",'parent':"OnlyOffice",'content':" Backend As this project is built with Go, so you need to install that first. The installation of Go is out of the scope of this document, please follow the official documentation for Go, to build this project you have to install Go \u0026gt;= v1.12. After the installation of the required tools you need to get the sources:\ngit clone https://github.com/owncloud/ocis/onlyoffice.git cd ocis-onlyoffice All required tool besides Go itself and make are bundled or getting automatically installed within the GOPATH. All commands to build this project are part of our Makefile.\nBackend make generate make build Finally you should have the binary within the bin/ folder now, give it a try with ./bin/onlyoffice -h to see all available options.\n"});index.add({'id':52,'href':'/extensions/storage/users/','title':"Users",'parent':"Storage",'content':"Demo driver This is a simple user driver for testing. It contains three users:\neinstein:relativity marie:radioactivty richard:superfluidity In order to use the demo driver you need to export the relevant environment variable:\nexport STORAGE_USERS_DRIVER=demo JSON driver In order to switch from the ldap driver to JSON based users you need to export the relevant environment variables:\nexport STORAGE_USERS_DRIVER=json export STORAGE_USERS_JSON=/path/to/users.json For the format of the users.json have a look at the reva examples\nLDAP driver This is the default user driver.\nIf the below defaults don\u0026rsquo;t match your environment change them accordingly:\nexport STORAGE_LDAP_HOSTNAME=localhost export STORAGE_LDAP_PORT=9126 export STORAGE_LDAP_BASE_DN=\u0026#39;dc=example,dc=org\u0026#39; export STORAGE_LDAP_USERFILTER=\u0026#39;(\u0026amp;(objectclass=posixAccount)(cn=%s))\u0026#39; export STORAGE_LDAP_GROUPFILTER=\u0026#39;(\u0026amp;(objectclass=posixGroup)(cn=%s))\u0026#39; export STORAGE_LDAP_BIND_DN=\u0026#39;cn=reva,ou=sysusers,dc=example,dc=org\u0026#39; export STORAGE_LDAP_BIND_PASSWORD=reva export STORAGE_LDAP_SCHEMA_UID=uid export STORAGE_LDAP_SCHEMA_MAIL=mail export STORAGE_LDAP_SCHEMA_DISPLAYNAME=sn export STORAGE_LDAP_SCHEMA_CN=cn Then restart the bin/storage users and bin/storage auth-basic services for the changes to take effect.\n"});index.add({'id':53,'href':'/extensions/storage/storages/','title':"Storages",'parent':"Storage",'content':"Storage commands storage has multiple storage provider commands to preconfigure different default configurations for the reva storage provider service. While you could rerun storage storage-oc multiple times with different flags to get multiple instances we are giving the different commands the necessary default configuration to allow the ocis binary to simply start them and not deal with configuration.\nStorage providers To manage the file tree ocis uses storage storage providers that are accessing the underlying storage using a storage driver. The driver can be used to change the implementation of a storage aspect to better reflect the actual underlying storage capabilities. As an example a move operation on a POSIX filesystem (theoretically) is an atomic operation. When trying to implement a file tree on top of S3 there is no native move operation that can be used. A naive implementation might fall back on a COPY and DELETE. Some S3 implementations provide a COPY operation that uses an existing key as the source, so the file at least does not need to be reuploaded. In the worst case scenario, which is renaming a folder with hundreds of thousands of objects, a reupload for every file has to be made. Instead of hiding this complexity a better choice might be to disable renaming of files or at least folders on S3. There are however implementations of filesystems on top of S3 that store the tree metadata in dedicated objects or use a completely different persistence mechanism like a distributed key value store to implement the file tree aspect of a storage.\nWhile the storage provider is responsible for managing the tree, file up and download is delegated to a dedicated data provider. See below. Storage aspects A lot of different storage technologies exist, ranging from general purpose file systems with POSIX semantics to software defined storage with multiple APIs. Choosing any of them is making a tradeoff decision. Or, if a storage technology is already in place it automatically predetermines the capabilities that can be made available. Not all storage systems are created equal.\nUnfortunately, no POSIX filesystem natively supports all storage aspects that ownCloud 10 requires:\nA hierarchical file tree An important aspect of a filesystem is organizing files and directories in a file hierarchy, or tree. It allows you to create, move and delete nodes. Beside the name a node also has well known metadata like size and mtime that are persisted in the tree as well.\nFolders are not directories There is a difference between folder and directory: a directory is a file system concept. A folder is a metaphor for the concept of a physical file folder. There are also virtual folders or smart folders like the recent files folder which are no file system directories. So, every directory and every virtual folder is a folder, but not every folder is a directory. See the folder metaphor in wikipedia. Also see the activity history below. Id based lookup While traditionally nodes in the tree are reached by traversing the path the tree persistence should be prepared to look up a node by an id. Think of an inode in a POSIX filesystem. If this operation needs to be cached for performance reasons keep in mind that cache invalidation is hard and crawling all files to update the inode to path mapping takes O(n), not O(1).\nETag propagation For the state based sync a client can discover changes by recursively descending the tree and comparing the ETag for every node. If the storage technology supports propagating ETag changes up the tree, only the root node of a tree needs to be checked to determine if a discovery needs to be started and which nodes need to be traversed. This allows using the storage technology itself to persist all metadata that is necessary for sync, without additional services or caches.\nSubtree size accounting The tree can keep track of how many bytes are stored in a folder. Similar to ETag propagation a change in file size is propagated up the hierarchy.\nETag and Size propagation When propagating the ETag (mtime) and size changes up the tree the question is where to stop. If all changes need to be propagated to the root of a storage then the root or busy folders will become a hotspot. There are two things to keep in mind: 1. propagation only happens up to the root of a single space (a user private drive or a single group drive), 2. no cross storage propagation. The latter was used in oc10 to let clients detect when a file in a received shared folder changed. This functionality is moving to the storage registry which caches the ETag for every root so clients can discover if and which storage changed. Rename Depending on the underlying storage technology some operations may either be slow, up to a point where it makes more sense to disable them entirely. One example is a folder rename: on S3 a simple folder rename translates to a copy and delete operation for every child of the renamed folder. There is an exception though: this restriction only applies if the S3 storage is treated like a filesystem, where the keys are the path and the value is the file content. There are smarter ways to implement file systems on top of S3, but again: there is always a tradeoff.\nS3 has no rename Technically, S3 has no rename operation at all. By design, the location of the value is determined by the key, so it always has to do a copy and delete. Another example is the redis RENAME operation: while being specified as O(1) it executes an implicit DEL operation, so if the deleted key contains a very big value it may cause high latency\u0026hellip; Arbitrary metadata persistence In addition to well known metadata like name size and mtime, users might be able to add arbitrary metadata like tags, comments or dublin core. In POSIX filesystems this maps to extended attributes.\nGrant persistence The CS3 API uses grants to describe access permissions. Storage systems have a wide range of permissions granularity and not all grants may be supported by every storage driver. POSIX ACLs for example have no expiry. If the storage system does not support certain grant properties, e.g. expiry, then the storage driver may choose to implement them in a different way. Expiries could be persisted in a different way and checked periodically to remove the grants. Again: every decision is a tradeoff.\nTrash persistence After deleting a node the storage allows listing the deleted nodes and has an undo mechanism for them.\nVersions persistence A user can restore a previous version of a file.\nSnapshots are not versions Modern POSIX filesystems support snapshotting of volumes. This is different from keeping track of versions to a file or folder, but might be another implementation strategy for a storage driver to allow users to restore content. Activity History The storage keeps an activity history, tracking the different actions that have been performed. This does not only include file changes but also metadata changes like renames and permission changes.\nStorage drivers Reva currently has four storage driver implementations that can be used for storage providers an well as data providers.\nLocal Storage Driver The minimal storage driver for a POSIX based filesystem. It literally supports none of the storage aspect other than basic file tree management. Sharing can - to a degree - be implemented using POSIX ACLs.\n tree provided by a POSIX filesystem inefficient path by id lookup, currently uses the file path as id, so ids are not stable can store a uuid in extended attributes and use a cache to look them up, similar to the ownCloud driver no native ETag propagation, five options are available: built in propagation (changes bypassing ocis are not picked up until a rescan) built in inotify (requires 48 bytes of RAM per file, needs to keep track of every file and folder) external inotify (same RAM requirement, but could be triggered by external tools, e.g. a workflow engine) kernel audit log (use the linux kernel audit to capture file events on the storage and offload them to a queue) fuse filesystem overlay no subtree accounting, same options as for ETag propagation efficient rename arbitrary metadata using extended attributes grant persistence using POSIX ACLs requires an LDAP server to make guest accounts available in the OS oCIS has glauth which contains all users an existing LDAP could be used if guests ar provisioned in another way using extended attributes to implement expiry or sharing that does not require OS level integration fuse filesystem overlay no native trash could use the The FreeDesktop.org Trash specification fuse filesystem overlay no native versions, multiple options possible git for folders rcs for single files rsnapshot for hourly / daily / weekly / monthly backups \u0026hellip; but this is not versioning as known from oc10 design new freedesktop spec, basically what is done in oc10 without the limitations or borrow ideas from the freedesktop trash spec fuse filesystem overlay To provide the other storage aspects we plan to implement a FUSE overlay filesystem which will add the different aspects on top of local filesystems like ext4, btrfs or xfs. It should work on NFSv45 as well, although NFSv4 supports RichACLs and we will explore how to leverage them to implement sharing at a future date. The idea is to use the storages native capabilities to deliver the best user experience. But again: that means making the right tradeoffs.\nOwnCloud Storage Driver This is the current default storage driver. While it implements the file tree (using redis, including id based lookup), ETag propagation, trash, versions and sharing (including expiry) using the data directory layout of ownCloud 10 it has known limitations that cannot be fixed without changing the actual layout on disk.\nTo setup it up properly in a distributed fashion, the storage-home and the storage-oc need to share the same underlying FS. Their \u0026ldquo;data\u0026rdquo; counterparts also need access to the same shared FS. For a simple docker-compose setup, you can create a volume which will be used by the \u0026ldquo;storage-storage-home\u0026rdquo;, \u0026ldquo;storage-storage-home-data\u0026rdquo;, \u0026ldquo;storage-storage-oc\u0026rdquo; and \u0026ldquo;storage-storage-oc-data\u0026rdquo; containers. Using the owncloud/ocis docker image, the volume would need to be hooked in the /var/tmp/ocis folder inside the containers.\n tree provided by a POSIX filesystem file layout is mapped to the old ownCloud 10 layout the root of tree for a user on disk is prefixed with /path/to/data/\u0026lt;username\u0026gt;/files/ efficient path by id lookup all files and folders get assigned a uuid in the extended attributes when starting the storage provider it will walk all files to populate a redis kv store for uuid to path lookup slow to boot trees with lots of nodes build in ETag propagation ETags are calculated based on mtime mtime is propagated by the storage driver changes bypassing ocis are not picked up until a restart of the storage provider no subtree accounting, same options as for local storage efficient rename TODO update the kv store for path lookup, this is an O(n) operation arbitrary metadata using extended attributes grant persistence using custom ACLs that are stored as extended attributes a grant corresponds to one extended attribute of 40-100 bytes, effectively limiting the number of shares to ~100-40 extended attributes have varying limitations, based on the underlying filesystem the linux kernel imposes a limit of 255bytes per name and 64KiB per value ext2/3/4: total bytes for all attributes of a file is limited to 4KiB (a filesystem block) xfs: limit of 64KiB per value btrfs: total bytes used for the name, value, and implementation overhead bytes 16KiB (the default filesystem nodesize value) does not require OS level integration built in trash trashed files are moved to /path/to/data/\u0026lt;username\u0026gt;/files_trashbin/ trashed files are appended a timestamp .d\u0026lt;unixtime\u0026gt;, which breaks trashing of files that reach the filesystems specific name limit built in versions file versions are stored in /path/to/data/\u0026lt;username\u0026gt;/files_versions/ file versions are appended a timestamp .d\u0026lt;unixtime\u0026gt;, which breaks versioning of files that reach the filesystems specific name limit EOS Storage Driver The CERN eos storage has evolved with ownCloud and natively supports id based lookup, ETag propagation, subtree size accounting, sharing, trash and versions. To use it you need to change the default configuration of the storage storage-home command (or have a look at the Makefile ̀ eos-start` target):\nexport STORAGE_HOME_DRIVER=eos export STORAGE_DRIVER_EOS_NAMESPACE=/eos export STORAGE_DRIVER_EOS_MASTER_URL=\u0026#34;root://eos-mgm1.eoscluster.cern.ch:1094\u0026#34; export STORAGE_DRIVER_EOS_ENABLE_HOME=true export STORAGE_DRIVER_EOS_LAYOUT=\u0026#34;dockertest/{{.Username}}\u0026#34; Running it locally also requires the eos and xrootd binaries. Running it using make eos-start will use CentOS based containers that already have the necessary packages installed.\nPull requests to add explicit storage storage-(s3|custom|...) commands with working defaults are welcome. S3 Storage Driver A naive driver that treats the keys in an S3 capable storage as / delimited path names. While it does not support MOVE or ETag propagation it can be used to read and write files. Better integration with native capabilities like versioning is possible but depends on the Use Case. Several storage solutions that provide an S3 interface also support some form of notifications that can be used to implement ETag propagation.\nData Providers Clients using the CS3 API use an InitiateFileDownload and ]InitiateUpload](https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.InitiateFileUploadRequest) request at the storage gateway to obtain a URL endpoint that can be used to either GET the file content or upload content using the resumable tus.io protocol.\nThe data provider uses the same storage driver as the storage provider but can be scaled independently.\nThe dataprovider allows uploading the file to a quarantine area where further data analysis may happen before making the file accessible again. One use case for this is anti virus scanning for files coming from untrusted sources.\nFuture work FUSE overlay filesystem We are planning to further separate the concerns and use a local storage provider with a FUSE filesystem overlaying the actual POSIX storage that can be used to capture deletes and writes that might happen outside of ocis/reva.\nIt would allow us to extend the local storage driver with missing storage aspects while keeping a tree like filesystem that end users are used to see when sshing into the machine.\nUpload to Quarantine area Antivirus scanning of random files uploaded from untrusted sources and executing metadata extraction or thumbnail generation should happen in a sandboxed system to prevent malicious users from gaining any information about the system. By spawning a new container with access to only the uploaded data we can further limit the attack surface.\n"});index.add({'id':54,'href':'/ocis/development/testing/','title':"Testing",'parent':"Development",'content':" Testing with test suite in docker Run full test suite Run single feature test oCIS image to be tested (or: skip build and take existing image) Test log output Cleanup Testing with test suite natively installed Getting the tests Run ocis Run the acceptance tests use existing tests for BDD For running tests in the test suite you have two options. You may go the easy way and just run the test suite in docker. But for some tasks you could also need to install the test suite natively, which requires a little bit more setup since PHP and some dependencies need to be installed.\nBoth ways to run tests with the test suites are described here.\nTesting with test suite in docker Let\u0026rsquo;s see what is available. Invoke the following command from within the root of the oCIS repository.\nmake -C tests/acceptance/docker help Basically we have two sources for feature tests and test suites:\n oCIS feature test and test suites ownCloud feature tests and test suites At the moment both can be applied to oCIS since the api of oCIS is designed to be compatible to ownCloud.\nSince we have to offer an migration path to existing users of ownCloud, you can use your existing ownCloud as storage backend for oCIS. As another storage backend we offer oCIS native storage, also called \u0026ldquo;oCIS\u0026rdquo;. This stores files directly on disk. Which storage backend is used is also reflected in the tests, there are always different tests for oCIS storage and ownCloud storage.\nYou can invoke two types of test suite runs:\n run a full test suite, which consists of multiple feature tests run a single feature test Run full test suite The names of the full test suite make targets have the same naming as in the CI pipeline.\nFor example make -C tests/acceptance/docker localApiTests-apiOcisSpecific-ocis runs the same tests as the localApiTests-apiOcisSpecific-ocis CI pipeline, which runs the oCIS test suite \u0026ldquo;apiOcisSpecific\u0026rdquo; against an oCIS with oCIS storage.\nFor example make -C tests/acceptance/docker Core-API-Tests-owncloud-storage-3runs the same tests as the Core-API-Tests-owncloud-storage-3 CI pipline, which runs the third (out of ten) ownCloud test suite against an oCIS with owncloud storage.\nRun single feature test The single feature tests can also be run against the different storage backends. Therefore multiple make targets with the schema test--feature-exists. For selecting a single feature test you have to add an additional BEHAT_FEATURE=... parameter when invoking the make command:\nmake -C tests/acceptance/docker test-ocis-feature-ocis BEHAT_FEATURE=\u0026#39;tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsDELETEAuth.feature\u0026#39; This must be pointing to a valid feature definition.\noCIS image to be tested (or: skip build and take existing image) By default the tests will be run against docker image built from your current working state of the oCIS repository. For some purposes it might also be handy to use a oCIS image from Docker Hub. Therefore you can provide the optional flag OCIS_IMAGE_TAG=... which must contain an available docker tag of the owncloud/ocis registry on Docker Hub (eg. \u0026lsquo;latest\u0026rsquo;).\nmake -C tests/acceptance/docker localApiTests-apiOcisSpecific-ocis OCIS_IMAGE_TAG=latest Test log output While a test is running or when it is finished, you can attach to the logs generated by the tests.\nmake -C tests/acceptance/docker show-test-logs The log output is opened in less. You can navigate up and down with your cursors. By pressing \u0026ldquo;F\u0026rdquo; you can follow the latest line of the output. Cleanup During testing we start an redis and oCIS docker container. These will not be stopped automatically. You can stop them with:\nmake -C tests/acceptance/docker clean Testing with test suite natively installed We are using the ownCloud 10 acceptance test suite against oCIS.\nGetting the tests All you need to do to get the acceptance tests is check out the core repo:\ngit clone https://github.com/owncloud/core.git Run ocis To start ocis:\nPROXY_ENABLE_BASIC_AUTH=true bin/ocis server PROXY_ENABLE_BASIC_AUTH will allow the acceptance tests to make requests against the provisioning api (and other endpoints) using basic auth.\nRun the acceptance tests First we will need to clone the testing app in owncloud which contains the skeleton files required for running the tests. In the ownCloud 10 core clone the testing app with the following command:\ngit clone https://github.com/owncloud/testing apps/testing Then run the api acceptance tests with the following command from the root of the ownCloud 10 core repository:\nmake test-acceptance-api \\ TEST_SERVER_URL=https://localhost:9200 \\ TEST_OCIS=true \\ SKELETON_DIR=apps/testing/data/apiSkeleton \\ DELETE_USER_DATA_CMD=\u0026#39;rm -rf /var/tmp/ocis/storage/users/nodes/root/* /var/tmp/ocis/storage/users/nodes/*-*-*-*\u0026#39; \\ BEHAT_FILTER_TAGS=\u0026#39;~@notToImplementOnOCIS\u0026amp;\u0026amp;~@toImplementOnOCIS\u0026#39; Make sure to adjust the settings TEST_SERVER_URL and OCIS_REVA_DATA_ROOT according to your environment.\nThis will run all tests that are relevant to oCIS.\nTo run a single test add BEHAT_FEATURE=\u0026lt;feature file\u0026gt;\nuse existing tests for BDD As a lot of scenarios are written for oC10, we can use those tests for Behaviour driven development in ocis. Every scenario that does not work in oCIS with \u0026ldquo;owncloud\u0026rdquo; storage, is listed in tests/acceptance/expected-failures-on-OWNCLOUD-storage.txt with a link to the related issue. Every scenario that does not work in oCIS with \u0026ldquo;ocis\u0026rdquo; storage, is listed in tests/acceptance/expected-failures-on-OCIS-storage.txt with a link to the related issue.\nThose scenarios are run in the ordinary acceptance test pipeline in CI. The scenarios that fail are checked against the expected failures. If there are any differences then the CI pipeline fails. Similarly, scenarios that do not work in oCIS with EOS storage are listed in tests/acceptance/expected-failures-on-EOS-storage.txt. Additionally, some issues have scenarios that demonstrate the current buggy behaviour in ocis(reva). Those scenarios are in this ocis repository in tests/acceptance/features/apiOcisSpecific. Have a look into the documentation to understand why we are writing those tests.\nIf you want to work on a specific issue\n adjust the core commit id to the latest commit in core so that CI will run the latest test code and scenarios from core. For that change coreCommit in the config section:\nconfig = { 'apiTests': { 'coreBranch': 'master', 'coreCommit': 'a06b1bd5ba8e5244bfaf7fa04f441961e6fb0daa', 'numberOfParts': 6 } } locally run each of the tests marked with that issue in the expected failures file.\nE.g.:\nmake test-acceptance-api \\ TEST_SERVER_URL=https://localhost:9200 \\ TEST_OCIS=true \\ DELETE_USER_DATA_CMD=\u0026#39;rm -rf /var/tmp/ocis/storage/users/nodes/root/* /var/tmp/ocis/storage/users/nodes/*-*-*-*\u0026#39; \\ BEHAT_FEATURE=\u0026#39;tests/acceptance/features/apiComments/comments.feature:123\u0026#39; the tests will fail, try to understand how and why they are failing\n fix the code\n go back to 2. and repeat till the tests are passing.\n remove those tests from the expected failures file\n run each of the local tests that were demonstrating the buggy behavior. They should fail.\n delete each of the local tests that were demonstrating the buggy behavior.\n make a PR that has the fixed code, relevant lines removed from the expected failures file and bug demonstration tests deleted.\n "});index.add({'id':55,'href':'/clients/web/backend-oc10/','title':"Setup with ownCloud 10",'parent':"ownCloud Web",'content':" Prerequisites Setting up the ownCloud Server Adjusting config.php Setting up OAuth2 Setting up Web Running Web Running acceptance tests Prerequisites Decide on which host and port Web will be served, for example https://web-host:8300/web-path/. In this document, we will refer to the following:\n \u0026lt;web-url\u0026gt; as the full URL, for example https://web-host:8300/web-path/ \u0026lt;web-domain\u0026gt; as the protocol, domain and port, for example: https://web-host:8300 Setting up the ownCloud Server Make sure you have an ownCloud Server already installed.\nAdjusting config.php Add the following entries to config/config.php:\n tell ownCloud where Web is located: \u0026#39;web.baseUrl\u0026#39; =\u0026gt; \u0026#39;\u0026lt;web-url\u0026gt;\u0026#39;, add a CORS domain entry for Web in config.php: \u0026#39;cors.allowed-domains\u0026#39; =\u0026gt; [\u0026#39;\u0026lt;web-domain\u0026gt;\u0026#39;], optional: when developing against unstable APIs (technical preview), these need to be enabled in the server core: dav.enable.tech_preview =\u0026gt; true, Setting up OAuth2 To connect to the ownCloud server, it is necessary to set it up with OAuth2.\nInstall and enable the oauth2 app:\n% occ market:install oauth2 % occ app:enable oauth2 Login as administrator in the ownCloud Server web interface and go to the \u0026ldquo;User Authentication\u0026rdquo; section in the admin settings and add an entry for Web as follows:\n pick an arbitrary name for the client set the redirection URI to \u0026lt;web-url\u0026gt;/oidc-callback.html make sure to take note of the client identifier value as it will be needed in the Web configuration later on Setting up Web In the local Web checkout, copy the config.json.sample-oc10 file to config.json and adjust it accordingly:\n Set the \u0026ldquo;server\u0026rdquo; key to the URL of the ownCloud server including path. If the URL contains a path, please also add a trailing slash there. Set the \u0026ldquo;clientId\u0026rdquo; key to the client identifier as copied from the \u0026ldquo;User Authentication\u0026rdquo; section before. Adjust \u0026ldquo;url\u0026rdquo; and \u0026ldquo;authUrl\u0026rdquo; using the ownCloud server URL as prefix for both Optionally adjust \u0026ldquo;apps\u0026rdquo; for the list of apps to be loaded. These match the app names inside the \u0026ldquo;apps\u0026rdquo; folder. Running Web if running from source, make sure to build Web first run by launching a webpack dev server yarn watch-all when working on the Web code, webpack will recompile the code automatically Running acceptance tests For testing, please refer to the ownCloud 10 testing section\n"});index.add({'id':56,'href':'/ocis/development/extensions/','title':"Extensions",'parent':"Development",'content':" How to build and run ocis-simple Hacking ocis-hello Option 1: Hacking ownCloud Web (and ocis-web) The ownCloud design system External ownCloud Web apps ownCloud Web extension points ownCloud Web Files app API driven development How to build and run ocis-simple ocis uses build tags to build different flavors of the binary. In order to work on a new extension we are going to reduce the scope a little and use the simple tag. Let us begin by creating a dedicated folder:\nmkdir ocis-extension-workshop \u0026amp;\u0026amp; ocis-extension-workshop Following https://github.com/owncloud/ocis\ngit clone https://github.com/owncloud/ocis.git cd ocis TAGS=simple make generate build Q: Can you specify which version of ownCloud Web to use? A: No, the ownCloud Web that is used is compiled into the assets of ocis-web which is currently not automatically updated. We\u0026rsquo;ll see how to use a custom ownCloud Web later.\nbin/ocis server\nOpen the browser at http://localhost:9100\n You land on the login screen. click login You are redirected to an idp at http://localhost:9140/oauth2/auth with a login mask. Use einstein:relativityto login (one of the three demo users) You are redirected to http://localhost:9100/#/hello the ocis-hello app Replace World with something else and submit. You should see Hello %something else% Q: One of the required ports is already in use. Ocis seems to be trying to restart the service over and over. What gives? A: Using the ocis binary to start the server will case ocis to keep track of the different services and restart them in case they crash.\nHacking ocis-hello go back to the ocis-extension-workshop folder\ncd .. Following https://github.com/owncloud/ocis-hello\ngit clone https://github.com/owncloud/ocis-hello.git cd ocis-hello yarn install # this actually creates the assets yarn build # this will compile the assets into the binary make generate build Two options:\n run only the necessery services from ocis and ocis-hello independently compile ocis with the updated ocis-hello Option 1: get a list of ocis services:\nps ax | grep ocis Try to kill ocis hello\nRemember: for now, killing a service will cause ocis to restart it. This is subject to change.\nIn order to be able to manage the processes ourselves we need to start them independently:\nbin/ocis server starts the same services as:\nbin/ocis micro \u0026amp; bin/ocis web \u0026amp; bin/ocis hello \u0026amp; bin/ocis reva \u0026amp; Now we can kill the ocis hello and use our custom built ocis-hello binary:\ncd ../ocis-hello bin/ocis-hello server Hacking ownCloud Web (and ocis-web) Following https://github.com/owncloud/web we are going to build the current ownCloud Web\ngit clone https://github.com/owncloud/web.git cd web yarn install yarn dist We can tell ocis to use the compiled assets:\nKill ocis web, then use the compiled assets when starting ownCloud Web.\ncd ../ocis WEB_ASSET_PATH=\u0026#34;`pwd`/../web/dist\u0026#34; bin/ocis web The ownCloud design system The ownCloud design system contains a set of ownCloud vue components for ownCloud Web or your own ocis extensions. Please use it for a consistent look and feel.\nExternal ownCloud Web apps This is what hello is: copy and extend!\n ownCloud Web is configured using the config.json which is served by the ocis-web service (either bin/ocis web or bin/web server)\n point ocis-web to the web config which you extended with an external app: WEB_UI_CONFIG=\u0026quot;pwd/../web/config.json\u0026quot; ASSET_PATH=\u0026quot;pwd/../web/dist\u0026quot; bin/ocis web\n { \u0026#34;server\u0026#34;: \u0026#34;http://localhost:9140\u0026#34;, \u0026#34;theme\u0026#34;: \u0026#34;owncloud\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;0.1.0\u0026#34;, \u0026#34;openIdConnect\u0026#34;: { \u0026#34;metadata_url\u0026#34;: \u0026#34;http://localhost:9140/.well-known/openid-configuration\u0026#34;, \u0026#34;authority\u0026#34;: \u0026#34;http://localhost:9140\u0026#34;, \u0026#34;client_id\u0026#34;: \u0026#34;web\u0026#34;, \u0026#34;response_type\u0026#34;: \u0026#34;code\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;openid profile email\u0026#34; }, \u0026#34;apps\u0026#34;: [], \u0026#34;external_apps\u0026#34;: [ { \u0026#34;id\u0026#34;: \u0026#34;hello\u0026#34;, \u0026#34;path\u0026#34;: \u0026#34;http://localhost:9105/hello.js\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;url\u0026#34;: \u0026#34;http://localhost:9105\u0026#34; } }, { \u0026#34;id\u0026#34;: \u0026#34;myapp\u0026#34;, \u0026#34;path\u0026#34;: \u0026#34;http://localhost:6789/superapp.js\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;backend\u0026#34;: \u0026#34;http://someserver:1234\u0026#34;, \u0026#34;myconfig\u0026#34;: \u0026#34;is awesome\u0026#34; } } ] } ownCloud Web extension points For an up to date list check out the ownCloud Web documentation. Several ones available:\nownCloud Web App switcher (defined in config.json) App container (loads UI of your extension) Files app File action Create new file action Sidebar Quick access for sidebar inside of file actions (in the file row) Example of a file action in the app.js:\nconst appInfo = { name: \u0026#39;MarkdownEditor\u0026#39;, id: \u0026#39;markdown-editor\u0026#39;, icon: \u0026#39;text\u0026#39;, isFileEditor: true, extensions: [{ extension: \u0026#39;txt\u0026#39;, newFileMenu: { menuTitle ($gettext) { return $gettext(\u0026#39;Create new plain text file…\u0026#39;) } } }, { extension: \u0026#39;md\u0026#39;, newFileMenu: { menuTitle ($gettext) { return $gettext(\u0026#39;Create new mark-down file…\u0026#39;) } } }] } For the side bar have a look at the files app, defaults.js \u0026amp; fileSideBars\nAPI driven development Until now we only had a look at the ui and how the extensions are managed on the cli. But how do apps actually talk to the server?\nShort answer: any way you like\nLong answer: micro and ocis-hello follow a protocol driven development:\n specify the API using protobuf\n generate client and server code\n evolve based on the protocol\n CS3 api uses protobuf as well and uses GRPC\n ocis uses go-micro, which provides http and grpc gateways\n the gateways and protocols are optional\n owncloud and kopano are looking into a MS graph like api to handle ownCloud Web requests.\n they might be about user, contacrs, calendars \u0026hellip; which is covered by the graph api we want to integrate with eg. kopano and provide a commen api (file sync and share is covered as well) as an example for protobuf take a look at ocis-hello\n "});index.add({'id':57,'href':'/ocis/storage-backends/','title':"Storage backends",'parent':"oCIS - ownCloud Infinite Scale",'content':""});index.add({'id':58,'href':'/extensions/onlyoffice/license/','title':"License",'parent':"OnlyOffice",'content':"This project is licensed under the Apache 2.0 license. For the license of the used libraries you have to check the respective sources.\n"});index.add({'id':59,'href':'/extensions/web/releasing/','title':"Releasing",'parent':"ownCloud Web",'content':" Releasing Package Hierarchy Prerequisites Updating ocis-web Releasing The next generation Web Frontend is shipped as an oCIS Extension. The ocis-web extension is also embedded in the single binary and part of the ocis server command.\nTo update this package within all the deliveries, we need to update the package in the following chain from the bottom to the top.\nPackage Hierarchy ocis ocis-web ocis-pkg ownCloud Web Prerequisites Before updating the assets, make sure that ownCloud Web has been released first and take note of its release tag name.\nUpdating ocis-web Create a branch release-$version. in https://github.com/owncloud/ocis Create a Folder in changelog for the release version and date mkdir $major.$minor.$patchVersion_YYYY-MM-DD. Move all changelog items from the changelog/unreleased/ folder to the $major.$minor.$patchVersion_YYYY-MM-DD folder. Update the go module ocis-pkg to the latest version https://blog.golang.org/using-go-modules . Update the ownCloud Web asset by adjusting the value of WEB_ASSETS_VERSION at the top of the Makefile and specify the tag name of the latest ownCloud Web release. Run make clean generate. Create a changelog item for the update in the changelog/$major.$minor.$patchVersion_YYYY-MM-DD folder. Commit your changes. After merging, wait for the CI to run on the merge commit. Go to \u0026ldquo;Releases\u0026rdquo; in GH click \u0026ldquo;Draft a new Release\u0026rdquo;. Use v$major.$minor.$patch as a tag (the v prefix is important) and publish it. The tag and the Release artifacts will be created automatically. "});index.add({'id':60,'href':'/ocis/flow-docs/login-flow/','title':"Login Flow",'parent':"Flow documentation",'content':"Login Flow The following sequence diagram describes the openid connect auth code flow. The eight numbered steps and notes correspond to the openid connect auth code flow steps. Example requests are based on the spec as well.:\n document.addEventListener(\"DOMContentLoaded\", function(event) { mermaid.initialize({ flowchart: { useMaxWidth: true } }); }); sequenceDiagram %% we have comments!! \\o/ %% this documents the login workflow %% examples taken from the oidc spec https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth %% TODO add PKCE, see https://developer.okta.com/blog/2019/08/22/okta-authjs-pkce#use-pkce-to-make-your-apps-more-secure participant user as User participant client as Client participant proxy as ocis-proxy participant idp as IdP participant glauth as ocis-glauth participant graph as ocis-graph participant accounts as ocis-accounts participant ldap as external LDAP server user-+client: What is the content of my home? client-+proxy: PROPFIND no (or expired) auth Note over client,proxy: ocis needs to know the IdP that is\nused to authenticate users. The\nproxy will redirect unauthenticated\nrequests to that IdP. proxy---client: 302 Found Note over client, idp: HTTP/1.1 302 Found\nLocation: https://server.example.com/authorize?\nresponse_type=code\u0026\nscope=openid%20profile%20email\n\u0026client_id=s6BhdRkqt3\n\u0026state=af0ifjsldkj\n\u0026redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb Note over client, idp: We should follow the OpenID Connect Discovery protocol Note over client, idp: Clients might fall back to the ocis server if the discovery failed.\nWe can provide a webfinger endpoint there to let guests use an idp\nthat is backed by the accounts service. Note over client, idp: For now, clients can only handle one IdP, which is configured in ocis. client--client: 1. Client prepares an Authentication Request\ncontaining the desired request parameters. client-+idp: 2. Client sends the request to the Authorization Server. Note over client, idp: GET /authorize?\nresponse_type=code\n\u0026scope=openid%20profile%20email\n\u0026client_id=s6BhdRkqt3\n\u0026state=af0ifjsldkj\n\u0026redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1\nHost: server.example.com Note over user, idp: 3. Authorization Server Authenticates the End-User. Note over idp,ldap: Either an IdP already exists or a new one is introduced. Since we are not yet using oidc discovery we can only use one IdP. alt all users managed by konnectd/ocis idp-+glauth: LDAP query/bind glauth-+graph: GET user with Basic Auth\nGraphAPI graph-+accounts: internal GRPC accounts---graph: response graph---glauth: OData response glauth---idp: LDAP result Note over accounts,ldap: In case internal users are managed\nin an external ldap they have to be\nsynced to the accounts service to\nshow up as recipients during sharing. else all users authenticated by an external idp idp-+ldap: LDAP query/bind ldap---idp: LDAP result alt guest accounts managed in ocis / lookup using glauth proxy: Note over idp,glauth: Idp is configured to use glauth as a\nsecond ldap server. idp-+glauth: LDAP query/bind glauth-+graph: GET user with Basic Auth\nGraphAPI graph-+accounts: internal GRPC accounts---graph: response graph---glauth: OData response glauth---idp: LDAP result else guest account provisioned by other means Note over accounts, ldap: In case guest accounts are managed\nin an existing ldap they need to be\nsynced to the accounts service to\nbe able to login and show up as\nrecipients during sharing. end end Note over user, idp: 4. Authorization Server obtains End-User Consent/Authorization. idp---client: 5. Authorization Server sends the End-User back\nto the Client with an Authorization Code. Note over client, idp: HTTP/1.1 302 Found\nLocation: https://client.example.org/cb?\ncode=SplxlOBeZQQYbYS6WxSbIA\u0026state=af0ifjsldkj client-+idp: 6. Client requests a response using the\nAuthorization Code at the Token Endpoint. Note over client, idp: POST /token HTTP/1.1\nHost: server.example.com\nContent-Type: application/x-www-form-urlencoded\ngrant_type=authorization_code\u0026code=SplxlOBeZQQYbYS6WxSbIA\n\u0026redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb idp---client: 7. Client receives a response that contains an\nID Token and Access Token in the response body. Note over client, idp: HTTP/1.1 200 OK\nContent-Type: application/json\nCache-Control: no-store\nPragma: no-cache\n{\n\"access_token\": \"SlAV32hkKG\",\n\"token_type\": \"Bearer\",\n\"refresh_token\": \"8xLOxBtZp8\",\n\"expires_in\": 3600,\n\"id_token\": \"a ... b.c ... d.e ... f\" // must be a JWT\n} client--client: 8. Client validates the ID token and\nretrieves the End-User's Subject Identifier. client-+proxy: PROPFIND With access token proxy---client: 207 Multi-Status client---user: List of Files X, Y, Z ... "});index.add({'id':61,'href':'/ocis/metrics/','title':"Metrics",'parent':"oCIS - ownCloud Infinite Scale",'content':"Metrics This service provides some Prometheus metrics through the debug endpoint, you can optionally secure the metrics endpoint by some random token, which got to be configured through one of the flag --debug-token or the environment variable OCIS_DEBUG_TOKEN mentioned above. By default the metrics endpoint is bound to http://0.0.0.0:8001/metrics.\n go_gc_duration_seconds A summary of the GC invocation durations go_gc_duration_seconds_sum A summary of the GC invocation durations go_gc_duration_seconds_count A summary of the GC invocation durations go_goroutines Number of goroutines that currently exist go_info Information about the Go environment go_memstats_alloc_bytes Number of bytes allocated and still in use go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table go_memstats_frees_total Total number of frees go_memstats_gc_cpu_fraction The fraction of this program\u0026rsquo;s available CPU time used by the GC since the program started go_memstats_gc_sys_bytes Number of bytes used for garbage collection system metadata go_memstats_heap_alloc_bytes Number of heap bytes allocated and still in use go_memstats_heap_idle_bytes Number of heap bytes waiting to be used go_memstats_heap_inuse_bytes Number of heap bytes that are in use go_memstats_heap_objects Number of allocated objects go_memstats_heap_released_bytes Number of heap bytes released to OS go_memstats_heap_sys_bytes Number of heap bytes obtained from system go_memstats_last_gc_time_seconds Number of seconds since 1970 of last garbage collection go_memstats_lookups_total Total number of pointer lookups go_memstats_mallocs_total Total number of mallocs go_memstats_mcache_inuse_bytes Number of bytes in use by mcache structures go_memstats_mcache_sys_bytes Number of bytes used for mcache structures obtained from system go_memstats_mspan_inuse_bytes Number of bytes in use by mspan structures go_memstats_mspan_sys_bytes Number of bytes used for mspan structures obtained from system go_memstats_next_gc_bytes Number of heap bytes when next garbage collection will take place go_memstats_other_sys_bytes Number of bytes used for other system allocations go_memstats_stack_inuse_bytes Number of bytes in use by the stack allocator go_memstats_stack_sys_bytes Number of bytes obtained from system for stack allocator go_memstats_sys_bytes Number of bytes obtained from system go_threads Number of OS threads created promhttp_metric_handler_requests_in_flight Current number of scrapes being served promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code "});index.add({'id':62,'href':'/ocis/flow-docs/request-flow/','title':"Request Flow",'parent':"Flow documentation",'content':"Request Flow The following sequence diagram describes the general request flow. It shows where account provisioning and token minting are happening:\n document.addEventListener(\"DOMContentLoaded\", function(event) { mermaid.initialize({ flowchart: { useMaxWidth: true } }); }); sequenceDiagram %% we have comments!! \\o/ participant user as User participant client as Client participant proxy as ocis-proxy participant idp as IdP participant accounts as ocis-accounts participant ldap as corporate LDAP server user-+client: What is the content of my home? client-+proxy: PROPFIND Bearer auth using oidc auth token Note over client,proxy: What is in a bearer token? The spec recommends opaque tokens. Treat it as random byte noise. Note over client,proxy: the proxy MUST authenticate users using ocis-accounts because it needs to decide where to send the request %% Mention introspection endpoint for opaque tokens %% konnectd uses jwt, so we can save a request %% either way the token can be used to look up the sub and iss of the user %% or is token check enough? proxy-+idp: GET /userinfo alt userinfo succeeds idp--proxy: 200 OK Note over proxy,accounts: Content-Type: application/json\n{\n\"sub\": \"248289761001\",\n\"name\": \"Jane Doe\",\n\"given_name\": \"Jane\",\n\"family_name\": \"Doe\",\n\"preferred_username\": \"j.doe\",\n\"email\": \"janedoe@example.com\",\n\"picture\": \"http://example.com/janedoe/me.jpg\"\n} %% see: https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse else userinfo fails idp---proxy: 401 Unauthorized Note over proxy,accounts: WWW-Authenticate: error=\"invalid_token\",\nerror_description=\"The Access Token expired\" proxy--client: 401 Unauthorized or 302 Found with redirect to idp Note over client: start at login flow\nor refresh the token end proxy-+accounts: TODO API call to exchange sub@iss with account UUID Note over proxy,accounts: does not autoprovision users. They are explicitly provsioned later. alt account exists or has been migrated accounts--proxy: existing account UUID else account does not exist opt oc10 endpoint is configured Note over proxy,oc10: Check if user exists in oc10 proxy-+oc10: GET /apps/graphapi/v1.0/users/\u0026lt;uuid\u0026gt; opt user exists in oc10 oc10---proxy: 200 %% TODO auth using internal token proxy-+oc10: PROPFIND Note over proxy,oc10: forward existing bearer auth oc10---proxy: Multistatus response proxy--client: Multistatus response client--user: List of Files X, Y, Z ... end end Note over proxy,accounts: provision a new account including displayname, email and sub@iss TODO only if the user is allowed to login, based on group membership in the ldap server proxy-proxy: generate new uuid proxy-+accounts: TODO create account with new generated uuid accounts---proxy: OK / error else account has been disabled accounts---proxy: account is disabled proxy--client: 401 Unauthorized or 302 Found with redirect to idp Note over client: start at login flow\nor refresh the token end proxy-proxy: store uuid in context %% what if oc10 does not support a certain request / API proxy-proxy: mint an internal jwt that includes the UUID and username using revas `x-access-token` header proxy-+reva: PROPFIND Token auth using internal JWT reva---proxy: Multistatus response proxy---client: Multistatus response client---user: List of Files X, Y, Z ... "});index.add({'id':63,'href':'/ocis/flow-docs/public-upload-flow/','title':"Public upload Flow",'parent':"Flow documentation",'content':"Public Upload flow The following diagram describes the flow of requests:\nocis-reva sharing\nREVA_SHARING_ADDR = 0.0.0.0:9150\nocis-reva sharing...ocis-reva frontend\nREVA_FRONTEND_ADDR = 0.0.0.0:9140\nREVA_GATEWAY_URL = ocis:9142\nocis-reva frontend...ocis-proxy\nPROXY_HTTP_ADDR = 0.0.0.0:9200\nocis-proxy...2  POST http://ocis:9140/remote.php/dav/files/einstein/2 POST http:/...ocdav\nprefix = \"\"\ntimeout = 86400\nocdav...datagateway\nprefix = \"data\"\ntimeout = 86400\ndatagateway...client\nclient\u0026#xa;22  PATCH https://oc.example.org/data/{token}\nTus-Resumable: 1.0.022 PATCH http...ocis-reva gateway\nREVA_GATEWAY_ADDR = 0.0.0.0:9142\nocis-reva gateway...storage-registry\nstorage-registry\u0026#xa;Expose: trueExpose: true24  PATCH http://ocis:9156/data/u-u-i-d24 PATCH http...4  GetStorageProvider\n(ShareReference)4 GetStorageP...5  ProviderInfo5 ProviderInfostorageprovider\nREVA_STORAGE_HOME_ADDR = 0.0.0.0:9154\nREVA_STORAGE_HOME_DRIVER = eoshome\nREVA_STORAGE_HOME_EXPOSE_DATA_SERVER = false\nREVA_STORAGE_HOME_DATA_SERVER_URL =\nhttp://ocis:9156/data\nstorageprovider...Expose: falseExpose: false6  InitiateFileUpload\n(ShareReference)6 InitiateFil...EOSEOS15  WriteFile(upload info)15 WriteFile(...7  GetPublicShare7 GetPublicSh...19  UploadEndpoint\nhttps://oc.example.org/data/{token}19 UploadEndp...20  201 Created\nLocation: https://oc.example.org/data/{token}20 201 Create...21  201 Created\nLocation: https://oc.example.org/data/{token}21 201 Create...1 POST https://oc.example.org/remote.php/dav/files/einstein/\nUpload-Length: 100\nTus-Resumable: 1.0.0\nUpload-Metadata: filename d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg==,dir d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg==1 POST https:...23  PATCH http://ocis:9140/data/{token}\nTus-Resumable: 1.0.023 PATCH http...3  InitiateFileUpload3 InitiateFil...25  Write(bytes)25 Write(byte...26  204 No Content26 204 No Con...27  204 No Content27 204 No Con...28  204 No Content28 204 No Con...publicstorageprovider\nexpose-data-server = true\npublicstorageprovider...publicshareprovider\npublicshareprovider\u0026#xa;8  GetPublicShare8 GetPublicSh...9  PublicShare9 PublicShare10  PublicShare10 PublicShare11  InitiateFileUpload(TargetReference)11 InitiateFi...12  GetStorageProvider\n(TargetReference)12 GetStorage...13  ProviderInfo13 ProviderIn...14  InitiateFileUpload(TargetReference)14 InitiateFi...16  UploadEndpoint\nhttp://ocis:9156/data/u-u-i-d\nExpose: false16 UploadEndp...17 UploadEndpoint\nhttps://oc.example.org/data/\ntoken: sign(http://ocis:9156/data/u-u-i-d)17 UploadEndp...18  UploadEndpoint\nhttps://oc.example.org/data/{token}\nExpose: true18 UploadEndp...gateway\nREVA_TRANSFER_EXPIRES = 86400\nREVA_FRONTEND_URL =\nhttps://oc.example.org\nREVA_DATAGATEWAY_URL =\nhttps://oc.example.org/data\n\ngateway...When a storage provider\nsets the Expose flag of an Upload/Download Endpoint to false the gateway will wrap the url in a JWT and return the URL of the datagateway along with a transfer-token.When a storage provider...dataprovider\nREVA_STORAGE_HOME_DATA_ADDR = 0.0.0.0:9156\nREVA_STORAGE_HOME_DATA_DRIVER = eoshome\ndataprovider...GOAL: transfer bytes from the client up here ...GOAL: tran...... to the storage system somewhere down here... to the storage syst...Viewer does not support full SVG 1.1 "});index.add({'id':64,'href':'/extensions/storage/updating/','title':"Updating reva",'parent':"Storage",'content':" Updating reva Updating reva Run go get github.com/cs3org/reva@master Create a changelog entry containing changes that were done in reva Create a Pull Request to ocis-reva master with those changes If test issues appear, you might need to adjust the tests After the PR is merged, consider doing a release of the storage submodule "});index.add({'id':65,'href':'/extensions/settings/bundles/','title':"Settings Bundles",'parent':"Settings",'content':"A Settings Bundle is a collection of settings, uniquely identified by the key of the extension registering the bundle and the key of the bundle itself. It\u0026rsquo;s purpose is to let oCIS extensions define settings and make them available to users. They are dynamically rendered into forms, available in the frontend.\nAs of now we support five different types of settings:\n boolean integer string single choice list of integers or strings multiple choice list of integers or strings Each Setting is uniquely identified by a key within the bundle. Some attributes depend on the chosen type of setting. Through the information provided with the attributes of the setting, the settings frontend dynamically renders form elements, allowing users to change their settings individually.\nExample { \u0026#34;identifier\u0026#34;: { \u0026#34;extension\u0026#34;: \u0026#34;ocis-accounts\u0026#34;, \u0026#34;bundleKey\u0026#34;: \u0026#34;profile\u0026#34; }, \u0026#34;displayName\u0026#34;: \u0026#34;Profile\u0026#34;, \u0026#34;settings\u0026#34;: [ { \u0026#34;settingKey\u0026#34;: \u0026#34;lastname\u0026#34;, \u0026#34;displayName\u0026#34;: \u0026#34;Lastname\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Input for lastname\u0026#34;, \u0026#34;stringValue\u0026#34;: { \u0026#34;placeholder\u0026#34;: \u0026#34;Set lastname\u0026#34; } }, { \u0026#34;settingKey\u0026#34;: \u0026#34;age\u0026#34;, \u0026#34;displayName\u0026#34;: \u0026#34;Age\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Input for age\u0026#34;, \u0026#34;intValue\u0026#34;: { \u0026#34;min\u0026#34;: \u0026#34;16\u0026#34;, \u0026#34;max\u0026#34;: \u0026#34;200\u0026#34;, \u0026#34;step\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;placeholder\u0026#34;: \u0026#34;Set age\u0026#34; } }, { \u0026#34;settingKey\u0026#34;: \u0026#34;timezone\u0026#34;, \u0026#34;displayName\u0026#34;: \u0026#34;Timezone\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;User timezone\u0026#34;, \u0026#34;singleChoiceValue\u0026#34;: { \u0026#34;options\u0026#34;: [ { \u0026#34;stringValue\u0026#34;: \u0026#34;Europe/Berlin\u0026#34;, \u0026#34;displayValue\u0026#34;: \u0026#34;Europe/Berlin\u0026#34; }, { \u0026#34;stringValue\u0026#34;: \u0026#34;Asia/Kathmandu\u0026#34;, \u0026#34;displayValue\u0026#34;: \u0026#34;Asia/Kathmandu\u0026#34; } ] } } ] } "});index.add({'id':66,'href':'/clients/web/backend-ocis/','title':"Setup with OCIS",'parent':"ownCloud Web",'content':" Setting up OCIS services Setting up Web Setting up ocis-web service Running Web Running acceptance tests Setting up OCIS services Setup OCIS by cloning the ocis repository and following the setup instructions there. Do not start the whole server but run ./bin/ocis --log-level debug $EXTENSION for all the existing extensions except the web service. A list of extensions can be found by running ./bin/ocis without arguments and looking at the \u0026ldquo;Extensions\u0026rdquo; section. Setting up Web Please note that config.json is generated by ocis-web so there is no need to create one. If you want to provide a config.json file, you can do so by starting ocis with WEB_UI_CONFIG=/path/to/config.json Setting up ocis-web service Clone the ocis-web repository and follow the setup instructions there. Set export WEB_ASSET_PATH=$WEB_CHECKOUT/dist and replace with the path to the local git checkout of the Web repository Run \u0026ldquo;ocis-web\u0026rdquo;: ./bin/ocis-web --log-level debug server Running Web in the Web checkout folder, run yarn watch-all-ocis open https://localhost:9200 and accept the certificate. when signing in, use one of the available test users whenever code changes are made, you need to manually reload the browser page (no hot reload) Running acceptance tests For testing, please refer to the OCIS testing section\n"});index.add({'id':67,'href':'/ocis/development/debugging/','title':"Debugging",'parent':"Development",'content':" Debugging Start ocis Use the debug binary and attach to the process as needed Start all services independently to replace one of them with a debug process Gather error messages Managing dependencies and testing changes Debugging As a single binary for easy deployment running ocis server just forks itself to start all the services, which makes debugging those processes a little harder.\nUltimately, we want to be able to stop a single service using eg. ocis kill web so that you can start the service you want to debug in debug mode. We need to change the way we fork processes though, otherwise the runtime will automatically restart a service if killed.\nStart ocis For debugging there are two workflows that work well, depending on your preferences.\nUse the debug binary and attach to the process as needed Run the debug binary with OCIS_LOG_LEVEL=debug bin/ocis-debug server and then find the service you want to debug using:\n# ps ax | grep ocis 12837 pts/1 Sl+ 0:00 bin/ocis-debug server 12845 pts/1 Sl 0:00 bin/ocis-debug graph 12847 pts/1 Sl 0:00 bin/ocis-debug reva-auth-bearer 12848 pts/1 Sl 0:00 bin/ocis-debug graph-explorer 12849 pts/1 Sl 0:00 bin/ocis-debug ocs 12850 pts/1 Sl 0:00 bin/ocis-debug reva-storage-oc-data 12863 pts/1 Sl 0:00 bin/ocis-debug webdav 12874 pts/1 Sl 0:00 bin/ocis-debug reva-frontend 12897 pts/1 Sl 0:00 bin/ocis-debug reva-sharing 12905 pts/1 Sl 0:00 bin/ocis-debug reva-gateway 12912 pts/1 Sl 0:00 bin/ocis-debug reva-storage-home 12920 pts/1 Sl 0:00 bin/ocis-debug reva-users 12929 pts/1 Sl 0:00 bin/ocis-debug glauth 12940 pts/1 Sl 0:00 bin/ocis-debug reva-storage-home-data 12948 pts/1 Sl 0:00 bin/ocis-debug konnectd 12952 pts/1 Sl 0:00 bin/ocis-debug proxy 12961 pts/1 Sl 0:00 bin/ocis-debug thumbnails 12971 pts/1 Sl 0:00 bin/ocis-debug reva-storage-oc 12981 pts/1 Sl 0:00 bin/ocis-debug web 12993 pts/1 Sl 0:00 bin/ocis-debug api 12998 pts/1 Sl 0:00 bin/ocis-debug registry 13004 pts/1 Sl 0:00 bin/ocis-debug web 13015 pts/1 Sl 0:00 bin/ocis-debug reva-auth-basic Then you can set a breakpoint in the service you need and attach to the process via processid. To debug the reva-sharing service the VS Code launch.json would look like this:\n{ \u0026#34;version\u0026#34;: \u0026#34;0.2.0\u0026#34;, \u0026#34;configurations\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;ocis attach\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;go\u0026#34;, \u0026#34;request\u0026#34;: \u0026#34;attach\u0026#34;, \u0026#34;mode\u0026#34;: \u0026#34;local\u0026#34;, \u0026#34;processId\u0026#34;: 12897 } ] } Start all services independently to replace one of them with a debug process You can use this ./ocis.sh script to start all services independently, so they don\u0026rsquo;t get restrarted by the runtime when you kill them: #/bin/sh LOG_LEVEL=\u0026#34;debug\u0026#34; bin/ocis --log-level=$LOG_LEVEL micro \u0026amp; bin/ocis --log-level=$LOG_LEVEL glauth \u0026amp; bin/ocis --log-level=$LOG_LEVEL graph-explorer \u0026amp; bin/ocis --log-level=$LOG_LEVEL graph \u0026amp; #bin/ocis --log-level=$LOG_LEVEL hello \u0026amp; bin/ocis --log-level=$LOG_LEVEL konnectd \u0026amp; #bin/ocis --log-level=$LOG_LEVEL ocs \u0026amp; bin/ocis --log-level=$LOG_LEVEL web \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-auth-basic \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-auth-bearer \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-frontend \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-gateway \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-sharing \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-storage-home \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-storage-home-data \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-storage-oc \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-storage-oc-data \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-storage-root \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-users \u0026amp; #bin/ocis --log-level=$LOG_LEVEL webdav bin/ocis --log-level=$LOG_LEVEL proxy \u0026amp; Get the list of running processes: # ps ax | grep ocis 12837 pts/1 Sl+ 0:00 bin/ocis-debug server 12845 pts/1 Sl 0:00 bin/ocis-debug graph 12847 pts/1 Sl 0:00 bin/ocis-debug reva-auth-bearer 12848 pts/1 Sl 0:00 bin/ocis-debug graph-explorer 12849 pts/1 Sl 0:00 bin/ocis-debug ocs 12850 pts/1 Sl 0:00 bin/ocis-debug reva-storage-oc-data 12863 pts/1 Sl 0:00 bin/ocis-debug webdav 12874 pts/1 Sl 0:00 bin/ocis-debug reva-frontend 12897 pts/1 Sl 0:00 bin/ocis-debug reva-sharing 12905 pts/1 Sl 0:00 bin/ocis-debug reva-gateway 12912 pts/1 Sl 0:00 bin/ocis-debug reva-storage-home 12920 pts/1 Sl 0:00 bin/ocis-debug reva-users 12929 pts/1 Sl 0:00 bin/ocis-debug glauth 12940 pts/1 Sl 0:00 bin/ocis-debug reva-storage-home-data 12948 pts/1 Sl 0:00 bin/ocis-debug konnectd 12952 pts/1 Sl 0:00 bin/ocis-debug proxy 12961 pts/1 Sl 0:00 bin/ocis-debug thumbnails 12971 pts/1 Sl 0:00 bin/ocis-debug reva-storage-oc 12981 pts/1 Sl 0:00 bin/ocis-debug web 12993 pts/1 Sl 0:00 bin/ocis-debug api 12998 pts/1 Sl 0:00 bin/ocis-debug registry 13004 pts/1 Sl 0:00 bin/ocis-debug web 13015 pts/1 Sl 0:00 bin/ocis-debug reva-auth-basic Kill the service you want to start in debug mode: # kill 17628 Start the service you are interested in in debug mode. When using make to build the binary there is already a bin/ocis-debug binary for you. When running an IDE tell it which service to start by providing the corresponding sub command, eg. bin\\ocis-debug reva-frontend. Gather error messages We recommend you collect all related information in a single file or in a github issue. Let us start with an error that pops up in the Web UI:\n Error while sharing. error sending a grpc stat request\n This popped up when I tried to add marie as a collaborator in ownCloud Web. That triggers a request to the server which I copied as curl. We can strip a lot of headers and the gist of it is:\n# curl \u0026#39;https://localhost:9200/ocs/v1.php/apps/files_sharing/api/v1/shares\u0026#39; -d \u0026#39;shareType=0\u0026amp;shareWith=marie\u0026amp;path=%2FNeuer+Ordner\u0026amp;permissions=1\u0026#39; -u einstein:relativity -k -v | xmllint -format - [... headers ...] \u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;UTF-8\u0026#34;?\u0026gt; \u0026lt;ocs\u0026gt; \u0026lt;meta\u0026gt; \u0026lt;status\u0026gt;error\u0026lt;/status\u0026gt; \u0026lt;statuscode\u0026gt;998\u0026lt;/statuscode\u0026gt; \u0026lt;message\u0026gt;error sending a grpc stat request\u0026lt;/message\u0026gt; \u0026lt;/meta\u0026gt; \u0026lt;/ocs\u0026gt; The username and password only work when basic auth is available. Otherwise you have to obtain a bearer token, eg. by grabbing it from the browser. TODO add ocis cli tool to obtain a bearer token. We also have a few interesting log entries:\n0:43PM INF home/jfd/go/pkg/mod/github.com/cs3org/reva@v0.0.2-0.20200318111623-a2f97d4aa741/internal/grpc/interceptors/log/log.go:69 \u0026gt; unary code=OK end=\u0026#34;18/Mar/2020:22:43:40 +0100\u0026#34; from=tcp://[::1]:44078 pid=17836 pkg=rgrpc start=\u0026#34;18/Mar/2020:22:43:40 +0100\u0026#34; time_ns=95841 traceid=b4eb9a9f45921f7d3632523ca32a42b0 uri=/cs3.storage.registry.v1beta1.RegistryAPI/GetStorageProvider user-agent=grpc-go/1.26.0 10:43PM ERR home/jfd/go/pkg/mod/github.com/cs3org/reva@v0.0.2-0.20200318111623-a2f97d4aa741/internal/grpc/interceptors/log/log.go:69 \u0026gt; unary code=Unknown end=\u0026#34;18/Mar/2020:22:43:40 +0100\u0026#34; from=tcp://[::1]:43910 pid=17836 pkg=rgrpc start=\u0026#34;18/Mar/2020:22:43:40 +0100\u0026#34; time_ns=586115 traceid=b4eb9a9f45921f7d3632523ca32a42b0 uri=/cs3.gateway.v1beta1.GatewayAPI/Stat user-agent=grpc-go/1.26.0 10:43PM ERR home/jfd/go/pkg/mod/github.com/cs3org/reva@v0.0.2-0.20200318111623-a2f97d4aa741/internal/http/services/owncloud/ocs/reqres.go:94 \u0026gt; error sending a grpc stat request error=\u0026#34;rpc error: code = Unknown desc = gateway: error calling Stat: rpc error: code = Unavailable desc = connection error: desc = \\\u0026#34;transport: Error while dialing dial tcp [::1]:9152: connect: connection refused\\\u0026#34;\u0026#34; pid=17832 pkg=rhttp traceid=b4eb9a9f45921f7d3632523ca32a42b0 TODO return the trace id in the response so we can correlate easier. For reva tracked in https://github.com/cs3org/reva/issues/587 The last line gives us a hint where the log message originated: .../github.com/cs3org/reva@v0.0.2-0.20200318111623-a2f97d4aa741/internal/http/services/owncloud/ocs/reqres.go:94. Which looks like this:\n89: // WriteOCSResponse handles writing ocs responses in json and xml 90: func WriteOCSResponse(w http.ResponseWriter, r *http.Request, res *Response, err error) { 91: var encoded []byte 92: 93: if err != nil { 94: appctx.GetLogger(r.Context()).Error().Err(err).Msg(res.OCS.Meta.Message) 95: } Ok, so this seems to be a convenience method that is called from multiple places an also handles errors. Unfortunately, this hides the actual source of the error. We could set a breakpoint in line 94 and reproduce the problem, which can be a lot harder than just clicking the share button or sending a curl request again. So let us see what else the log tells us.\nThe previous line tells us that a Stat request failed: uri=/cs3.gateway.v1beta1.GatewayAPI/Stat. This time the line is written by the grpc log interceptor. What else is there?\nThe first line tells us that looking up the responsible storage provider seems to have succeeded: uri=/cs3.storage.registry.v1beta1.RegistryAPI/GetStorageProvider.\nAt this point it your familiarity with the codebase starts to become a factor. If you are new you should probably go back to setting a break point on the log line and check the stack trace.\nDebug wherever the call trace leads you to \u0026hellip; good luck!\nManaging dependencies and testing changes You can either run and manage the services independently, or you can update the go.mod file and replace dependencies with your local version.\nTo debug the reva frontend we need to add two replacements:\n// use the local ocis-reva repo replace github.com/owncloud/ocis-reva =\u0026gt; ../ocis-reva // also use the local reva repo replace github.com/cs3org/reva =\u0026gt; ../reva The username and password only work when basic auth is available. Otherwise you have to obtain a bearer token, eg. by grabbing it from the browser. Rebuild ocis to make sure the dependency is used. It should be sufficient to just restart the service you want to debug.\n"});index.add({'id':68,'href':'/extensions/thumbnails/grpc/','title':"GRPC API",'parent':"Thumbnails",'content':" pkg/proto/v0/thumbnails.proto GetRequest GetResponse GetRequest.FileType ThumbnailService Scalar Value Types pkg/proto/v0/thumbnails.proto GetRequest A request to retrieve a thumbnail\n Field Type Label Description filepath string The path to the source image filetype GetRequest.FileType The type to which the thumbnail should get encoded to. etag string The etag of the source image width int32 The width of the thumbnail height int32 The height of the thumbnail authorization string The authorization token GetResponse The service response\n Field Type Label Description thumbnail bytes The thumbnail as a binary mimetype string The mimetype of the thumbnail GetRequest.FileType The file types to which the thumbnail cna get encoded to.\n Name Number Description PNG 0 Represents PNG type JPG 1 Represents JPG type ThumbnailService A Service for handling thumbnail generation\n Method Name Request Type Response Type Description GetThumbnail GetRequest GetResponse Generates the thumbnail and returns it. Scalar Value Types .proto Type Notes C++ Java double double double float float float int32 Uses variable-length encoding. Inefficient for encoding negative numbers – if your field is likely to have negative values, use sint32 instead. int32 int int64 Uses variable-length encoding. Inefficient for encoding negative numbers – if your field is likely to have negative values, use sint64 instead. int64 long uint32 Uses variable-length encoding. uint32 int uint64 Uses variable-length encoding. uint64 long sint32 Uses variable-length encoding. Signed int value. These more efficiently encode negative numbers than regular int32s. int32 int sint64 Uses variable-length encoding. Signed int value. These more efficiently encode negative numbers than regular int64s. int64 long fixed32 Always four bytes. More efficient than uint32 if values are often greater than 2^28. uint32 int fixed64 Always eight bytes. More efficient than uint64 if values are often greater than 2^56. uint64 long sfixed32 Always four bytes. int32 int sfixed64 Always eight bytes. int64 long bool bool boolean string A string must always contain UTF-8 encoded or 7-bit ASCII text. string String bytes May contain any arbitrary sequence of bytes. string ByteString "});index.add({'id':69,'href':'/extensions/ocis_hello/configuration-with-ocis/','title':"Running",'parent':"Hello",'content':"Configuring ocis-hello with ocis We will need various services to run ocis\nRunning a ldap server in docker container We will use the ldap server as users provider for ocis.\ndocker run --hostname ldap.my-company.com \\ -e LDAP_TLS_VERIFY_CLIENT=never \\ -e LDAP_DOMAIN=owncloud.com \\ -e LDAP_ORGANISATION=ownCloud \\ -e LDAP_ADMIN_PASSWORD=admin \\ --name docker-slapd \\ -p 127.0.0.1:389:389 \\ -p 636:636 -d osixia/openldap Running a redis server in a docker container Redis will be used by ocis for various caching purposes.\ndocker run -e REDIS_DATABASES=1 -p 6379:6379 -d webhippie/redis:latest Running ocis In order to run this extension we will need to run ocis first. For that clone and build the ocis single binary from the github repo https://github.com/owncloud/ocis. After that we will need to create a config file for phoenix so that we can load the hello app in the frontend. Create a file phoenix-config.json with the following contents.\n{ \u0026#34;server\u0026#34;: \u0026#34;https://localhost:9200\u0026#34;, \u0026#34;theme\u0026#34;: \u0026#34;owncloud\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;0.1.0\u0026#34;, \u0026#34;openIdConnect\u0026#34;: { \u0026#34;metadata_url\u0026#34;: \u0026#34;https://localhost:9200/.well-known/openid-configuration\u0026#34;, \u0026#34;authority\u0026#34;: \u0026#34;https://localhost:9200\u0026#34;, \u0026#34;client_id\u0026#34;: \u0026#34;phoenix\u0026#34;, \u0026#34;response_type\u0026#34;: \u0026#34;code\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;openid profile email\u0026#34; }, \u0026#34;apps\u0026#34;: [ \u0026#34;files\u0026#34;, \u0026#34;draw-io\u0026#34;, \u0026#34;pdf-viewer\u0026#34;, \u0026#34;markdown-editor\u0026#34;, \u0026#34;media-viewer\u0026#34; ], \u0026#34;external_apps\u0026#34;: [ { \u0026#34;id\u0026#34;: \u0026#34;hello\u0026#34;, \u0026#34;path\u0026#34;: \u0026#34;http://localhost:9105/hello.js\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;url\u0026#34;: \u0026#34;http://localhost:9105\u0026#34; } } ] } Here we can add the url for the js file from where the hello app will be loaded.\nAfter that we will need a configuration file for ocis where we can specify the path for the hello app in the backend. For this you can use the existing proxy-example.json file from the ocis-proxy repo. Just add an extra endpoint at the end for the hello app.\n{ \u0026#34;endpoint\u0026#34;: \u0026#34;/api/v0/greet\u0026#34;, \u0026#34;backend\u0026#34;: \u0026#34;http://localhost:9105\u0026#34; } With all this in place we can finally start ocis. But first we will need to set some configuration variables.\nexport REVA_USERS_DRIVER=ldap export REVA_LDAP_HOSTNAME=localhost export REVA_LDAP_PORT=636 export REVA_LDAP_BASE_DN=\u0026#39;dc=owncloud,dc=com\u0026#39; export REVA_LDAP_USERFILTER=\u0026#39;(\u0026amp;(objectclass=posixAccount)(cn=%s))\u0026#39; export REVA_LDAP_GROUPFILTER=\u0026#39;(\u0026amp;(objectclass=posixGroup)(cn=%s))\u0026#39; export REVA_LDAP_BIND_DN=\u0026#39;cn=admin,dc=owncloud,dc=com\u0026#39; export REVA_LDAP_BIND_PASSWORD=admin export REVA_LDAP_SCHEMA_UID=uid export REVA_LDAP_SCHEMA_MAIL=mail export REVA_LDAP_SCHEMA_DISPLAYNAME=displayName export REVA_LDAP_SCHEMA_CN=cn export LDAP_URI=ldap://localhost export LDAP_BINDDN=\u0026#39;cn=admin,dc=owncloud,dc=com\u0026#39; export LDAP_BINDPW=admin export LDAP_BASEDN=\u0026#39;dc=owncloud,dc=com\u0026#39; In addition to all these we will also need to set the config files we just modified. For that set these variables with the path to the config files.\nexport PHOENIX_WEB_CONFIG=\u0026lt;path to phoenix config file\u0026gt; export OCIS_CONFIG_FILE=\u0026lt;path to ocis proxy config file\u0026gt; And finally start the ocis server\nbin/ocis server After this we will need to start the ocis-hello service. For that just build ocis-hello binary.\ncd ocis-hello make And Run the service\nbin/ocis-hello server "});index.add({'id':70,'href':'/extensions/ocis_hello/settings/','title':"Settings",'parent':"Hello",'content':"The ocis-settings service exposes an endpoint for registering so called settings bundles. This gives control to every service to define settings that are needed for fulfilling it\u0026rsquo;s intended purpose. There are different types of settings available out of the box - hopefully those already fit your needs. The settings defined through settings bundles can be changed by authenticated users through an ocis-web extension, which is also provided by the settings service. As a result, your service only has to register a settings bundle and oCIS takes care of everything else. Your service can simply use the settings values that were set by users.\nWith this chapter we want to show you, how to register a settings bundle and how to use the respective values that were set by users. We do this by customizing the greeter phrase from our greeter service in ocis-hello.\nYou can find the source code, especially how it\u0026rsquo;s integrated into the service, in the following files:\n pkg/service/v0/service.go for the requests, pkg/command/server.go for the integration of RegisterSettingsBundles into the service start. Register settings bundle In order to register a settings bundle, you need to create a request message and then send it to the BundleService of ocis-settings through a gRPC call.\nCreate request request := \u0026amp;settings.SaveSettingsBundleRequest{ SettingsBundle: \u0026amp;settings.SettingsBundle{ Identifier: \u0026amp;settings.Identifier{ Extension: \u0026#34;ocis-hello\u0026#34;, BundleKey: \u0026#34;greeting\u0026#34;, }, DisplayName: \u0026#34;Greeting\u0026#34;, Settings: []*settings.Setting{ { SettingKey: \u0026#34;phrase\u0026#34;, DisplayName: \u0026#34;Phrase\u0026#34;, Description: \u0026#34;Phrase for replies on the greet request\u0026#34;, Value: \u0026amp;settings.Setting_StringValue{ StringValue: \u0026amp;settings.StringSetting{ Required: true, Default: \u0026#34;Hello\u0026#34;, MaxLength: 15, }, }, }, }, }, } The request holds only one field, which is a SettingsBundle. It consists of an Identifier, a DisplayName and a list of Settings.\n The Extension and BundleKey inside the Identifier are required and have to be alphanumeric (- and _ are allowed as well). The Identifier has to stay stable - if you change it, existing settings will not be migrated to the new identifier. The DisplayName is required and may contain any UTF8 character. It will be shown in the settings user frontend in a generated form, so please try to be descriptive. You can change the DisplayName at any time. Settings is the list of settings you want to make available with this settings bundle. In this example, there is only one setting defined - a string setting for the phrase our greeter uses in the response. You can explore more types of settings in the settings package. All of them come with their own characteristics and validations. For the phrase setting we decided to set it to Required, so that it can\u0026rsquo;t be empty, and to set a MaxLength of 15 characters, so that the phrase is not too long. The SettingKey is particularly important, as this is used for referencing the setting in other requests. It has to fulfill the same rules as the other Identifier attributes. Please also take the time to set a Description, in order to provide accessibility in the generated forms as good as possible. Send request to ocis-settings This request message can be sent to the BundleService of ocis-settings like this:\nbundleService := settings.NewBundleService(\u0026#34;com.owncloud.api.settings\u0026#34;, mclient.DefaultClient) response, err := bundleService.SaveSettingsBundle(context.Background(), request) We run this request on every start of ocis-hello so that the settings service always has the most recent version of the settings bundle.\nUse settings value We registered the greeter phrase setting for a reason: We want to allow the authenticated user to customize how they want to be greeted by ocis-hello. In order to do this, we need to ask ocis-settings on every request, what the greeter phrase of the authenticated user is.\nAccount UUID The settings request has one important prerequisite: As our service is stateless, we need to know the account UUID of the authenticated user the incoming POST request to our greeter service is coming from. As that POST request is coming through ocis-proxy, there is an HTTP header x-access-token that holds a JWT with the account UUID in it. We just have to dismantle the JWT to get the UUID. There is a middleware for that in ocis-pkg. You can look up the server configuration for that middleware in pkg/server/http/server.go. In essence, it dismantles the x-access-token, extracts the account UUID and makes it available in the context. It can be subsequently retrieved from the context like this:\nownAccountUUID := ctx.Value(middleware.UUIDKey).(string) Create request With the account UUID we can build an Identifier for the request to ocis-settings as follows:\nrequest := \u0026amp;settings.GetSettingsValueRequest{ Identifier: \u0026amp;settings.Identifier{ Extension: \u0026#34;ocis-hello\u0026#34;, BundleKey: \u0026#34;greeting\u0026#34;, SettingKey: \u0026#34;phrase\u0026#34;, AccountUuid: ownAccountUUID, }, } The Identifier for getting a value from ocis-settings needs the three fields for extension, bundle and setting that we chose in the settings bundle. The fourth field is the UUID of the authenticated user.\nSend request to ocis-settings This request message can be sent to the ValueService of ocis-settings like this:\nvalueService := settings.NewValueService(\u0026#34;com.owncloud.api.settings\u0026#34;, mclient.DefaultClient) response, err := valueService.GetSettingsValue(ctx, request) If this request is successful we will have a - possibly customized - greeting phrase. It could also be the default value, if the user didn\u0026rsquo;t customize their phrase in the settings frontend.\nConclusion You have learned how to register settings bundles, how to get the account UUID of the authenticated user and how to query the settings service for settings values.\n"});index.add({'id':71,'href':'/extensions/ocis_hello/testing/','title':"Testing",'parent':"Hello",'content':"This repository provides a general guideline for creating tests for the ocis extensions. The tests can be written in various levels from unit, integration, and end-to-end. It is not essential to write tests on all these levels as it can be redundant in some cases. This repository provides a reference for all levels of tests.\nUnit tests Unit tests generally live inside *_test.go files in the /pkg directory. One such example in this extension is in /pkg/service/v0/service_test.go. Similarly the unit test for the protobuf generated code can also be written just like in /pkg/proto/hello.pb_test.go.\nIntegration tests There are mainly 2 types of integration tests, namely HTTP tests, and GRPC tests. These tests mostly live in /pkg/proto directory where all the protobuf definitions are specified. The examples for the HTTP integration tests are in /pkg/proto/hello.pb.web_test.go whereas the GRPC tests are in /pkg/proto/hello.pb.micro_test.go.\nEnd-to-End tests For extensions with an UI, we can also write end-to-end tests using the Nightwatch test framework. These tests live in /ui/tests directory. We can reuse already existing Gherkin steps from the phoenix tests here.\nRunning the tests Unit and integration tests The unit and integration tests are run using the simple go test command. If you wish to run all the tests with the coverage you can just use make command.\nmake test You can also run a specific file with the go test command\ngo test \u0026lt;path to package or file\u0026gt; End-to-End tests Running end-to-end tests is a bit more complicated than unit and integration tests. First of all we will need a complete ocis setup with ocis-hello running. For that refer to this guide.\nAfter that, We need to set the proper test environment. To run the end-to-end tests, first-of-all we need the phoenix repository where all the test infrastructure exists. So, clone the phoenix repository in your system in any location.\ngit clone https://github.com/owncloud/phoenix $HOME/phoenix Next we will need to start the selenium server which will control the browser. There is a script in the phoenix repo that starts the selenium server, just run that to start selenium.\ncd $HOME/phoenix yarn run selenium Now we can run the tests. The tests will take several configuration variables which can be found here. Without configuration, most of the defaults will work. We just need make sure to set these values through env variable.\nexport PHOENIX_PATH=$HOME/phoenix export OCIS_SKELETON_DIR=\u0026lt;path to the skeleton directory\u0026gt; export PHOENIX_CONFIG=\u0026lt;path to the config.json file used by phoenix\u0026gt; The phoenix path should be set to the directory where the phoenix source files are. Our tests use the existing infrastructure from the phoenix directory to run the tests.\nThe skeleton directory for the webui tests can be found in the testing app. You can just clone that repository in your local machine and point the env variable to the correct path.\nWhile running ocis we should always use a config file for phoenix because our tests will read this file and sometimes even change it which cannot be done if you use env variables or the default values.\nWith all this in place we can just run the tests with a simple make command. First go to the ocis-hello repository\ncd \u0026lt;path to ocis-hello\u0026gt; Then Simply run\nmake test-acceptance-webui To run just one feature you can run\nmake test-acceptance-webui \u0026lt;path-to-feature file\u0026gt;:\u0026lt;line-number\u0026gt; "});index.add({'id':72,'href':'/extensions/settings/values/','title':"Settings Values",'parent':"Settings",'content':"A Settings Value is the value an authenticated user has chosen for a specific setting, defined in a settings bundle. For choosing settings values as a user the sole entry point is the ocis-web extension provided by this service.\nIdentifying settings values A settings value is uniquely identified by four attributes. Three of them are coming from the definition of the setting within it\u0026rsquo;s settings bundle (see Settings Bundles for an example). The fourth identifies the user.\n extension: Key of the extension that registered the settings bundle, bundleKey: Key of the settings bundle, settingKey: Key of the setting as defined within the bundle, accountUuid: The UUID of the authenticated user who has saved the setting. When requests are going through ocis-proxy, the accountUuid attribute can be set to the static keyword me instead of using a real UUID. ocis-proxy will take care of minting the UUID of the authenticated user into a JWT, providing it in the HTTP header as x-access-token. That UUID is then used in this service, to replace me with the actual UUID of the authenticated user. Example of stored settings values { \u0026#34;values\u0026#34;: { \u0026#34;language\u0026#34;: { \u0026#34;identifier\u0026#34;: { \u0026#34;extension\u0026#34;: \u0026#34;ocis-accounts\u0026#34;, \u0026#34;bundleKey\u0026#34;: \u0026#34;profile\u0026#34;, \u0026#34;settingKey\u0026#34;: \u0026#34;language\u0026#34;, \u0026#34;accountUuid\u0026#34;: \u0026#34;5681371f-4a6e-43bc-8bb5-9c9237fa9c58\u0026#34; }, \u0026#34;listValue\u0026#34;: { \u0026#34;values\u0026#34;: [ { \u0026#34;stringValue\u0026#34;: \u0026#34;de\u0026#34; } ] } }, \u0026#34;timezone\u0026#34;: { \u0026#34;identifier\u0026#34;: { \u0026#34;extension\u0026#34;: \u0026#34;ocis-accounts\u0026#34;, \u0026#34;bundleKey\u0026#34;: \u0026#34;profile\u0026#34;, \u0026#34;settingKey\u0026#34;: \u0026#34;timezone\u0026#34;, \u0026#34;accountUuid\u0026#34;: \u0026#34;5681371f-4a6e-43bc-8bb5-9c9237fa9c58\u0026#34; }, \u0026#34;listValue\u0026#34;: { \u0026#34;values\u0026#34;: [ { \u0026#34;stringValue\u0026#34;: \u0026#34;Europe/Berlin\u0026#34; } ] } } } } gRPC endpoints The obvious way of modifying settings is the ocis-web extension, as described earlier. However, services can use the respective gRPC endpoints of the ValueService to query and modify settings values as well. The gRPC endpoints require the same identifier attributes as described above, so for making a request to the ValueService you will have to make sure that the accountUuid of the authenticated user is available in your service at the time of the request.\n"});index.add({'id':73,'href':'/ocis/development/tracing/','title':"Tracing",'parent':"Development",'content':" By default, we use Jaeger for request tracing within oCIS. You can follow these steps to get started:\n Start Jaeger by using the all-in-one docker image: docker run -d --name jaeger \\ -e COLLECTOR_ZIPKIN_HTTP_PORT=9411 \\ -p 5775:5775/udp \\ -p 6831:6831/udp \\ -p 6832:6832/udp \\ -p 5778:5778 \\ -p 16686:16686 \\ -p 14268:14268 \\ -p 14250:14250 \\ -p 9411:9411 \\ jaegertracing/all-in-one:1.17 Every single oCIS service has its own environment variables for enabling and configuring tracing. You can enable and configure tracing on each service individually. For example, enable tracing in Reva when starting the oCIS single binary like this: REVA_TRACING_ENABLED=true \\ REVA_TRACING_ENDPOINT=localhost:6831 \\ REVA_TRACING_COLLECTOR=http://localhost:14268/api/traces \\ ./bin/ocis server Enabling and configuring tracing on oCIS itself will forward the configuration to all services: OCIS_TRACING_ENABLED=true \\ OCIS_TRACING_ENDPOINT=localhost:6831 \\ OCIS_TRACING_COLLECTOR=http://localhost:14268/api/traces \\ ./bin/ocis server If you want to set individual tracing configuration for each service, make sure to set OCIS_TRACING_ENABLED=false.\n Make the actual request that you want to trace. Open up the Jaeger UI to analyze request traces. For more information on Jaeger, please refer to their Documentation.\n"});index.add({'id':74,'href':'/clients/web/deployments/','title':"Deployments",'parent':"ownCloud Web",'content':"Showcases of different scenarios of deploying ownCloud Web.\n"});index.add({'id':75,'href':'/extensions/storage/releasing/','title':"Releasing",'parent':"Storage",'content':" Preparation Release To release a new version of the storage submodule, you have to follow a few simple steps.\nPreparation Before releasing, make sure that reva has been updated to the desired version Release Check out master git checkout master git pull origin master Create a new tag (preferably signed) and replace the version number accordingly. Prefix the tag with the submodule storage/v. git tag -s storage/vx.x.x -m \u0026#34;release vx.x.x\u0026#34; git push origin storage/vx.x.x Wait for CI and check that the GitHub release was published. Congratulations, you just released the storage submodule!\n"});index.add({'id':76,'href':'/clients/web/testing/','title':"Running acceptance tests",'parent':"ownCloud Web",'content':" Setting up Selenium Setup using Docker Setup using Docker Desktop for Mac Setup using standalone Selenium server Run tests with ownCloud 10 backend with OCIS backend the quick way (all automated) the manual way (e.g. to run from an existing ocis location) Available settings to be set by environment variables Tips too many open files Acceptance Tests in CI 1. web Repo 2. ocis Repo Setting up Selenium There are multiple ways to run Selenium:\n Setup using Docker Setup using Docker Desktop for Mac Setup using a standalone Selenium server Setup using Docker Set the environment variables SELENIUM_HOST as localhost and SERVER_HOST in the format http://\u0026lt;ip_addr\u0026gt;:9100. Run yarn run selenium (available only on Linux) If you are a Mac user, you can run yarn run selenium:mac This command creates a docker container which uses port forwarding instead of host networking which is not supported on Mac Setup using Docker Desktop for Mac In order to run acceptance tests with selenium running in Docker Desktop for Mac while having ownCloud Server and Web running as services on the host machine, localhost will not work as URL. Use the Docker host ip 172.17.0.1 or its alias host.docker.internal instead. This requires adjusting all relevant config files to use host.docker.internal instead of localhost (config.json in Web and config/config.php in oC10) and changing the web OIDC-callback url. Set the SERVER_HOST and BACKEND_HOST environment variables accordingly. In order to use the same url for development on the host machine, define it as an alias to 127.0.0.1 in /etc/hosts. After all these changes Web will be accessible at http://host.docker.internal:8300 for both development and acceptance tests.\nSetup using standalone Selenium server When running a standalone Selenium server, make sure to set the environment variable SELENIUM_HOST, SELENIUM_PORT and LOCAL_UPLOAD_DIR accordingly.\nRun tests with ownCloud 10 backend setup the ownCloud 10 backend clone and install the testing app into ownCloud build Web start the Web server set SERVER_HOST to point at the URL where the Web web pages are served, for example \u0026ldquo;http://localhost:8300\u0026rdquo; set BACKEND_HOST to point to the URL of the backend, for example \u0026ldquo;http://localhost/owncloud/\u0026rdquo; to be able to run federation tests, additional setup is needed: Install and setup a second ownCloud server-instance that is accessible by a different URL. That second server-instance must have its own database and data directory. clone and install the testing app into the second ownCloud server-instance from http://github.com/owncloud/testing . when running the acceptance tests use REMOTE_BACKEND_HOST environment variable to define its address, for example, REMOTE_BACKEND_HOST=http://\u0026lt;ip_address_of_second_ownCloud_server-instance\u0026gt; yarn run acceptance-tests \u0026lt;feature-files-to-test\u0026gt; . -set the SELENIUM_HOST environment variable to your host that runs selenium, mostly localhost -set the SELENIUM_PORT environment variable to your selenium port, mostly 4444 Run yarn run acceptance-tests \u0026lt;feature-files-to-test\u0026gt;.\nThe feature files are located in the \u0026ldquo;tests/acceptance/features\u0026rdquo; subdirectories.\nsee available settings for further setup if needed\nwith OCIS backend build Web create a new web config.json file and copy it into the dist folder, even though running web in the default ocis environment does not need a config.json file, some tests rely on it being present. As a starting point and example that should work when running every service on localhost use Linux: config.json.sample-ocis Mac: tests/acceptance/ocis-mac-config.json the quick way (all automated) run yarn run test-requirements:ocis (yarn run test-requirements:ocis:mac for Mac users) to install, configure and run all ocis requirements run yarn run acceptance-tests-ocis \u0026lt;feature-files-to-test\u0026gt; to run the tests. The feature files are located in the \u0026ldquo;tests/acceptance/features\u0026rdquo; subdirectories. To separate ocis log output from the tests output, run the command in a separate console. after the tests finish, run yarn run killall to stop all created docker containers, and the ocis services the manual way (e.g. to run from an existing ocis location) clone and build ocis\n From inside the web directory run yarn run testing-app to get the testing-app, it\u0026rsquo;s needed to have the skeleton folder for the tests\n Run redis server using docker\nyarn run redis-server Run the OCIS server with the necessary configurations\nexport WEB_ASSET_PATH=\u0026#39;\u0026lt;path-to-web-clone\u0026gt;/dist\u0026#39; export WEB_UI_CONFIG=\u0026#39;\u0026lt;path-to-web-clone\u0026gt;/dist/config.json\u0026#39; export STORAGE_HOME_DRIVER=owncloud export STORAGE_USERS_DRIVER=owncloud export PROXY_ENABLE_BASIC_AUTH=true note: WEB_UI_CONFIG should point to the same config file you have created earlier. note: currently it\u0026rsquo;s not possible to run the UI tests with OCIS \u0026amp; OWNCLOUD storage-driver\nrun the server:\nbin/ocis server Run yarn run acceptance-tests-ocis \u0026lt;feature-files-to-test\u0026gt;. The feature files are located in the \u0026ldquo;tests/acceptance/features\u0026rdquo; subdirectories.\n see available settings for further setup if needed\nAvailable settings to be set by environment variables These values can be set using the environment variables to configure yarn run acceptance-tests and yarn run acceptance-tests-ocis to match your local test environment.\n setting meaning default SERVER_HOST web URL http://localhost:8300 BACKEND_HOST ownCloud server URL (or reva service url for running with OCIS) http://localhost:8080 BACKEND_USERNAME ownCloud administrator username admin BACKEND_PASSWORD ownCloud administrator password admin SELENIUM_HOST selenium server host, if not set yarn will start selenium automaticallyif running the selenium docker container as mentioned above set to localhost SELENIUM_PORT port of selenium server 4444 SCREEN_RESOLUTION width and height in px to set the browser resolution to e.g. 375x812 empty = fullscreen REMOTE_UPLOAD_DIR path to filesForUpload directory, used when uploading files through api ./tests/acceptance/filesForUpload LOCAL_UPLOAD_DIR filesForUpload directory available for selenium for direct uploadsIf using selenium-docker and example above, set it as /uploads.If running local selenium, set value same as REMOTE_UPLOAD_DIR (please, remember to use absolute path) /uploads REMOTE_BACKEND_HOST ownCloud remote server URL http://localhost:8080 RUN_ON_OCIS Running the tests using the OCIS backend false OCIS_REVA_DATA_ROOT Data directory of OCIS /var/tmp/reva OCIS_SKELETON_DIR Skeleton files directory for new users - WEB_UI_CONFIG Path for the web config file (usually in the dist folder) - Tips too many open files If tests were running fine and then suddenly start to fail your system might run into open file limits. In that case you will see messages in the OCIS log output that look like this:\n2020-05-12 11:33:43.974552 I | http: Accept error: accept tcp [::]:9200: accept4: too many open files; retrying in 1s\nIn that case increase the open file limits, how to do that would be beyond the scope of this documentation.\nAcceptance Tests in CI In the CI we run the UI tests using different backends on different repos. We use commit IDs to indicate the version of the backend or testrunner we want to use. These commit IDs should be regularly updated in the .drone.star file to keep the CI up to date. We run web UI tests in the following repos in the CI.\n1. web Repo In the owncloud/web repo, we run the tests using both the oc10 backend and the OCIS backend. For the oc10 backend, we use the owncloudci/core docker image which runs the latest daily-master-qa version of owncloud.\nFor the OCIS backend, we use the Commit ID from the owncloud/ocis repo to indicate which version of backend to use. This can be specified in the .drone.star file in the config.defaults section.\n\u0026#39;defaults\u0026#39;: { \u0026#39;acceptance\u0026#39;: { \u0026#39;ocisBranch\u0026#39;: \u0026#39;master\u0026#39;, \u0026#39;ocisCommit\u0026#39;: \u0026#39;284a9996dffa912cc1382e259b748c56ddc4aa0f\u0026#39;, } }, If the version you want to run is on a different branch from master, you also need to change the branch name.\nIn order to check if new tests are compatible with OCIS, after changing the commit id and the branch name, we can create a draft PR in owncloud/web which triggers the CI, and we can see the result there.\n2. ocis Repo We follow the same approach in the owncloud/ocis repo too. In order to run the UI tests in CI we use commit IDs from web which can be changed in the .drone.star file.\n\u0026#39;uiTests\u0026#39;: { \u0026#39;webBranch\u0026#39;: \u0026#39;master\u0026#39;, \u0026#39;webCommit\u0026#39;: \u0026#39;492e6a663efad67f770ba4ac405c4d9983d00cd3\u0026#39;, ... } This is the commit ID of web indicating the version of testrunner we want to use. If the version is on a branch other than master, we will also need to change the branch name.\n"});index.add({'id':77,'href':'/extensions/settings/glossary/','title':"Glossary",'parent':"Settings",'content':"In the context of this extension and oCIS in general, we are using the following terminology.\nConfiguration System configuration e.g. service host names and ports Changes need to be propagated to other services Typically modified on the CLI Settings Application level settings e.g. default language Can be modified at runtime without restarting the service Typically modified in the UI Preferences User settings Subset of \u0026ldquo;Settings\u0026rdquo; e.g. preferred language of a user Settings Bundle Collection of related settings Registered by an oCIS extension Settings Value Manifestation of a setting for a specific user E.g. used for customization (at runtime) in ocis-web ocis-web-settings extension for modifying settings values is provided by this service Can be queried and modified by other ocis extensions "});index.add({'id':78,'href':'/extensions/ocis_hello/license/','title':"License",'parent':"Hello",'content':"This project is licensed under the Apache 2.0 license. For the license of the used libraries you have to check the respective sources.\n"});index.add({'id':79,'href':'/ocis/development/build-docs/','title':"Documentation",'parent':"Development",'content':" Build the documentation Add changes to the documentation Build the documentation Just run make -C docs docs-serve from within the root level of the oCIS git repository.\nAdd changes to the documentation Please keep this documentation in sync with the oCIS source code.\nChanges on the documentation are automatically applied to this site when merged to the master branch.\n"});index.add({'id':80,'href':'/ocis/development/continuous-integration/','title':"Continuous Integration",'parent':"Development",'content':" Concepts Things done in CI Flags in commit message and PR title Knowledge base oCIS uses DRONE as CI system. You can find the pipeline logs here or in your PR.\nConcepts The pipeline is defined in Starlark and transformed to YAML upon pipeline run. This enables us to do a highly dynamic and non repeating pipeline configuration.\nUpon running the pipeline, your branch gets merged to the master branch. This ensures that we always test your changeset if as it was applied to the master of oCIS. Please note that this does not apply to the pipeline definition (.drone.star).\nThings done in CI static code analysis linting running UI tests running ownCloud 10 test suite against oCIS build and release docker images build and release binaries build and release documentation Flags in commit message and PR title You may add flags to your commit message or PR title in order to speed up pipeline runs and take load from the CI runners.\n [CI SKIP]: no ci is run on the commit or PR\n [docs-only]: please add this flag, if you only changed documentation. This will only trigger documentation related CI steps.\n [tests-only]: please add this flag, if you only changed tests or test-related tooling. You do not need to add a changelog for tests-only changes.\n [with-benchmarks]: please add this flag, if you want benchmarks to be run in CI.\n Knowledge base My pipeline fails because some CI related files or commands are missing.\nPlease make sure to rebase your branch onto the lastest master of oCIS. It could be that the pipeline definition (.drone.star) was changed on the master branch. This is the only file, that will not be auto merged to master upon pipeline run. So things could be out of sync.\n How can I see the YAML drone pipeline definition?\nIn order to see the Yaml pipeline definition you can use the drone-cli to convert the Starlark file.\ndrone starlark If you experience a \u0026quot;build\u0026quot; struct has no .title attribute error you need a patched drone-cli binary. You need to build it yourself from this source code. (There is also an open PR for that on drone-cli) "});index.add({'id':81,'href':'/ocis/license/','title':"License",'parent':"oCIS - ownCloud Infinite Scale",'content':"This project is licensed under the Apache 2.0 license. For the license of the used libraries you have to check the respective sources.\n"});index.add({'id':82,'href':'/extensions/','title':"Extensions",'parent':"ownCloud",'content':""});index.add({'id':83,'href':'/','title':"ownCloud",'parent':'','content':" Developer Documentation We love open source Join us Developer Documentation Welcome to our developer documentation. Here you can find developer documentation on:\n oCIS server oCIS extensions Clients, like: ownCloud Web - the new web frontend for oCIS and ownCloud ownCloud Android app ownCloud iOS app ownCloud Desktop Syncing Client Integrations We love open source The oCIS server is Apache v2 licensed. The lower storage layer of oCIS is defined by the CS3 APIs and implemented in the REVA project. Our goal is to develop the CS3 APIs to an open standard and collaborate on the open source REVA reference implementation for CS3 APIs.\nYou can also find all client sources on github.\nJoin us The oCIS server repository on github is a good entry point for you to join the project. But we also develop clients for iOS, Android, Desktop and Web.\nFor communication on development you can join our public chat talk.owncloud.com\nIf you want to help and improve ownCloud or oCIS, start coding or open issues on github in the related repository.\nWe are very happy to hear your feedback and ideas!\n"});index.add({'id':84,'href':'/ocis/release_notes/','title':"Release Notes",'parent':"oCIS - ownCloud Infinite Scale",'content':"ownCloud Infinite Scale 1.0.0 Technology Preview We are pleased to announce the availability of ownCloud Infinite Scale 1.0.0 Technology Preview which is released as the first public version of the new Infinite Scale platform.\nMicroservice architecture ownCloud Infinite Scale is following the microservices architectural pattern. It is implemented as a set of microservices which are independent of each other. They are coupled with well-defined APIs. This architecture fosters a lot of benefits that we were aiming for with the new design for oCIS:\n Every service is independent, comparably small and brings it\u0026rsquo;s own webserver, backend/APIs and frontend components Each service runs as a separate service on the system, increasing security and stability Scalability: High performance demands can be fulfilled by scaling and distributing of services Testability: Each service can be tested on its own due to well-defined APIs and functionality Protocol-driven development using protobuf High-performance communication between services through gRPC Multi-platform support powered by Golang - only minimal dependency on platform packages Cloud-native deployment, update, monitoring, logging, tracing and orchestration strategies Key figures The all-new ownCloud Web frontend is shipped as part of the platform OpenID Connect is the future-proof technology choice for authentication An Identity Provider is bundled to ease deployment and operations. It can be replaced with an external OpenID IdP, if desired Automatically built and fully maintained Docker containers are available Flexible configuration through environment variables, config files or command-line flags Database-less architecture - metadata and data are kept together in the storage as a single source of truth Native storage capabilities are used where like native versioning and trashbin Public APIs like WebDAV and OCS have been kept compatible with ownCloud 10 A secure and flexible framework to create extensions Supported platforms Linux-amd64 Darwin-amd64 Experimental: Windows, ARM (e.g., Raspberry Pi, Termux on Android) Client support All official ownCloud Clients support the Infinite Scale server with the following versions:\n Desktop \u0026gt;= 2.7 Android \u0026gt;= 2.15 iOS \u0026gt;= 1.2 Architecture components ownCloud Infinite Scale is built as a modular framework in which components can be scaled individually. It consists of\n a user management service a settings service a frontend service a storage backend service a built-in IdP an application gateway/proxy These components can be deployed in a multi-tier deployment architecture. See the documentation for an overview of the services.\nOperation modes Standalone mode (with oCIS storage driver) In standalone mode oCIS uses its built-in orchestrator to start all necessary services. This allows you to run oCIS on a single node without any outside dependencies like docker-compose, kubernetes or even a webserver. It will start an OpenID IdP and create a self-signed certificate. You can start right away by navigating to https://localhost:9200.\nSingle services scaleout oCIS allows you to scale individual services using well-known orchestration frameworks like docker-compose, dockerSwarm and kubernetes.\nBridge mode with ownCloud 10 backend For the product transition phase, ownCloud Infinite Scale comes with an operation mode (\u0026ldquo;bridge mode\u0026rdquo;) that allows a hybrid deployment, between both server generations to operate the new web frontend with ownCloud 10 and Infinite Scale in parallel. This setup allows the ownCloud Web frontend to operate with both server generations and provides the foundation to migrate users gradually to the new backend.\nRequirements for the bridge mode\n ownCloud Server \u0026gt;= 10.6 Open ID Connect is used for user authentication The Graph API app is installed on ownCloud Server The latest client versions are rolled-out to users (required for OpenID Connect support). See the documentation for more information. See the documentation on how to deploy Infinite Scale in bridge mode.\nTechnology Preview\nownCloud Infinite Scale is currently in Technology Preview. The bridge mode should only be used in non-production environments.\n What to expect? This is the first promoted public release of ownCloud Infinite Scale, released as \u0026ldquo;Technical Preview\u0026rdquo;. Infinite Scale is not yet ready for production installations. Technical audiences will be able to get a good understanding of the potential of ownCloud\u0026rsquo;s new platform.\nVersion 1.0.0 comes with the base functionality for sync and share with a much higher performance-, stability- and security-level compared to all available platforms. Based on ten years of experience in enterprise sync and share and a long standing collaboration with the biggest global science organizations this new platform will exceed what content collaboration is today.\nHow to get started? One of the most important objectives for oCIS was to ease the setup of a working instance dramatically. Since oCIS is built with Google\u0026rsquo;s powerful Go language it supports the single-file-deployment: Installing oCIS 1.0.0 is as easy as downloading a single file, applying execution permission to it and get started. No more fiddling around with complicated LAMP stacks.\nDeployment Options Given the architecture of oCIS, there are various deployment options based on the users requirements. In our experience setting up the LAMP stack for ownCloud 10 was difficult for many users. Therefore a big emphasis was put on easy yet functional deployment strategies.\nSingle binary Delivery as single binary The single binary is the best option to test the new ownCloud Infinite Scale 1.0.0 Technical Preview release on a local machine. Follow these instructions to get the platform running in the most simple way:\n Download the binary\nLinux curl https://download.owncloud.com/ocis/ocis/1.0.0/ocis-1.0.0-linux-amd64 -o ocis\nMacOS curl https://download.owncloud.com/ocis/ocis/1.0.0/ocis-1.0.0-darwin-amd64 -o ocis\n Make it executable\nchmod +x ocis\n Run it\n./ocis server\n Navigate to https://localhost:9200 and log in to ownCloud Web (admin:admin)\n Production environments will need a more sophisticated setup, see https://owncloud.github.io/ocis/deployment/ for more information.\n Docker Containerized Setup For more sophisticated setups we recommend using one of our docker setup examples. See the documentation for a setup with Traefik as a reverse proxy which also includes automated SSL certificate provisioning using Letsencrypt tools. ownCloud Web Features Framework Framework User avatars (compatible with oC 10 API) Alerts for information/errors Notifications (bell icon, compatible with oC 10 API) Extension points Available extensions Media Viewer (images and videos) Draw.io Files Files Listing and browsing the hierarchy Sorting by columns (name/size/updated) Breadcrumb Thumbnail previews for images (compatible with oC 10 API and Thumbnails service API) Upload (file/folder), using the TUS protocol for reliable uploads Download (file) Rename Copy Move Delete Indicators for resources shared with people (including subfiles and subfolders) Indicators for resources shared by link (including subfiles and subfolders) Quick actions Add people Create public link on-the-fly and copy it to the clipboard Favorites (view + add/remove) Shared with me (view) Shared with others (view) Deleted files Versions (list/restore/download/delete) File/folder search Sharing Sharing with People (user/group shares) Adding people to a resource Adding multiple people at once (users and groups) Autocomplete search to find users Roles: Viewer / Editor (folder) / Advanced permissions (granular permissions) Expiration date Listing people who have access to a resource People can be listed when a resource is directly shared and when it\u0026rsquo;s indirectly shared via a parent folder When listing people of an indirectly shared resource, there is a \u0026ldquo;via\u0026rdquo; indicator that guides to the directly shared parent Every person can recognize the owner of a resource Every person can recognize their role The owner of a resource can recognize persons that added other people (reshare indicator) Editing persons Removing persons Links Sharing with Links Private links (copy) Public links Adding public links on single files and folders Roles: Viewer / Editor (folder) / Contributor (folder) / Uploader (folder) Password-protection Expiration date Listing public links Public links can be listed when a resource is directly shared and when it\u0026rsquo;s indirectly shared via a parent folder When listing public links of an indirectly shared resource, there is a \u0026ldquo;via\u0026rdquo; indicator that guides to the directly shared parent Copying existing public links Editing existing public links Removing existing public links Viewing public links User Profile User Profile Display basic profile information (user name, display name, e-mail, group memberships) \u0026ldquo;Edit\u0026rdquo; button guides to ownCloud 10 user settings (when used with oC 10) User Settings Basic user settings Language of the web interface oCIS Backend Features Storage Storage The default oCIS storage driver deconstructs a filesystem to be able to efficiently look up files by fileid as well as path. It stores all folders and files by a uuid and persists share and other metadata using extended attributes. This allows using the linux VFS cache using stat syscalls instead of a database or key/value store. The driver implements trash, versions and sharing. It not only serves as the current default storage driver, but also as a blueprint for future storage driver implementations. IDM User and group management Functionality available via API and frontend (\u0026ldquo;Accounts\u0026rdquo; extension) User listing (API/FE) User creation (API/FE) User deletion (API/FE) User activation/blocking (API/FE) Role assignment for users (API/FE) User editing (API) Multi-select in the frontend (delete \u0026amp; block/activate) Group creation (API) Add/remove users to/from groups (API) Group deletion (API) Create/read/update/delete users and groups (CLI) Settings Settings The settings service provides APIs for other services for registering a set of settings as Bundle. It also provides a pluggable extension for ownCloud Web which provides dynamically built web forms, so that users can customize their own settings. Some well known settings are directly used by ownCloud Web for adapted user experience, e.g. the UI language. Services can query the users\u0026rsquo; chosen settings for customized backend and frontend operations as needed.\nRoles \u0026amp; Permissions System Infinite Scale follows a role-based access control model. Based on permissions for actions which are provided by the system and by extensions, roles can be composed. Ultimately, these roles can be assigned to users to define what users are permitted to do. This model allows a segregation of duties for administration and allows granular control of how different types of users (e.g., Guests) can use the platform.\n Currently available permissions: Manage accounts (gives access to the internal user management) The current roles are exemplary default roles which are used for demonstration purposes \u0026ldquo;Admin\u0026rdquo;: Has the permission to \u0026ldquo;manage accounts\u0026rdquo; \u0026ldquo;User\u0026rdquo;: Does not have any dedicated permission \u0026ldquo;Guest\u0026rdquo;: Does not have any dedicated permission Currently a user can only have one role Users with the role \u0026ldquo;Admin\u0026rdquo; can assign/unassign roles to/from other users (as part of the permission to \u0026ldquo;manage roles\u0026rdquo;) APIs APIs WebDAV OCS Known issues There are feature differences depending on the operation mode, e.g., no user management with ownCloud Web and oC 10 backend Public links do not yet respect the given role (a recipient has full permissions no matter which role has been set) Resharing does not yet work as expected Share recipients can create public links with higher permissions than they originally had Share recipients can add other people but they will not be able to access the data Sharing indicators in the file list will only be shown after opening the right sidebar for a resource Users can\u0026rsquo;t change their password yet Folder sizes will not be calculated Cleanups are not yet available (e.g., shares of a deleted user will not be removed) Sharing from the desktop client does not work yet There are no notifications yet There can be issues with access tokens not being refreshed correctly, leading to interruptings, e.g., during uploads Deleting non-empty folders from the trash bin does not work Emptying the whole trash bin does not work For feedback and bug reports, please use the public issue tracker.\n"});index.add({'id':85,'href':'/integration/','title':"Integrations",'parent':"ownCloud",'content':""});index.add({'id':86,'href':'/clients/','title':"Clients",'parent':"ownCloud",'content':""});index.add({'id':87,'href':'/ocis/getting-started/','title':"Getting Started",'parent':"oCIS - ownCloud Infinite Scale",'content':" Run oCIS Binaries Docker Usage Login to ownCloud Web Basic Management Commands Run oCIS We are distributing oCIS as binaries and Docker images.\nYou can find more deployments examples in the deployment section\nBinaries The binaries for different platforms are downloadable at our download mirror or on GitHub. Latest binaries from the master branch can be found at our download mirrors testing section.\n# for mac curl https://download.owncloud.com/ocis/ocis/testing/ocis-testing-darwin-amd64 --output ocis # for linux curl https://download.owncloud.com/ocis/ocis/testing/ocis-testing-linux-amd64 --output ocis # make binary executable chmod +x ocis ./ocis server The default primary storage location is /var/tmp/ocis. You can change that value by configuration.\nDocker Docker images for oCIS are available on Docker Hub.\nThe latest tag always reflects the current master branch.\ndocker pull owncloud/ocis docker run --rm -ti -p 9200:9200 owncloud/ocis Usage Login to ownCloud Web Open https://localhost:9200 and login using one of the demo accounts:\neinstein:relativity marie:radioactivity richard:superfluidity There are admin demo accounts:\nmoss:vista admin:admin Basic Management Commands The oCIS single binary contains multiple extensions and the ocis command helps you to manage them. You already used ocis server to run all available extensions in the Run oCIS section. We now will show you some more management commands, which you may also explore by typing ocis --help or going to the docs.\nTo start oCIS server:\nocis server The list command prints all running oCIS extensions. ocis list\nTo stop a particular extension: ocis kill web\nTo start a particular extension: ocis run web\nThe version command prints the version of your installed oCIS. ocis --version\nThe health command is used to execute a health check, if the exit code equals zero the service should be up and running, if the exist code is greater than zero the service is not in a healthy state. Generally this command is used within our Docker containers, it could also be used within Kubernetes.\nocis health --help "});index.add({'id':88,'href':'/extensions/ocis_hello/','title':"Hello",'parent':"Extensions",'content':"\nAbstract When getting started with ocis development developers need to learn about the building blocks of ocis extensions. Without guidance or orientation of the why and what of an extension they may start feeling lost. The ocis-hello repository serves as a blueprint for ocis extensions. It allows developers to get started with ocis extension development by looking at the code, configuration and documentation.\n document.addEventListener(\"DOMContentLoaded\", function(event) { mermaid.initialize({ flowchart: { useMaxWidth: true } }); }); graph TD subgraph ow[ocis-web] owh[ocis-web-hello] end owh ---|\"greet()\"| ows[ocis-hello-server] ocis-hello provides a simple hello world example with\n a protobuf based greeter API a grpc service implementing the API a vue.js frontend using the API It can be integrated into ocis web as documented in the extensions docs.\nTable of Contents Getting Started Building Running Settings Testing License "});index.add({'id':89,'href':'/categories/','title':"Categories",'parent':"ownCloud",'content':""});index.add({'id':90,'href':'/tags/','title':"Tags",'parent':"ownCloud",'content':""});})(); \ No newline at end of file diff --git a/js/en.search-data.min.91704021600fa95e2ca21db96917c50670d23f43919eef331fca6cd0f4b51912.js b/js/en.search-data.min.91704021600fa95e2ca21db96917c50670d23f43919eef331fca6cd0f4b51912.js new file mode 100644 index 00000000000..6358dbac27a --- /dev/null +++ b/js/en.search-data.min.91704021600fa95e2ca21db96917c50670d23f43919eef331fca6cd0f4b51912.js @@ -0,0 +1 @@ +'use strict';(function(){const indexCfg={};indexCfg.doc={id:'id',field:['title','content'],store:['title','href','parent'],};const index=FlexSearch.create(indexCfg);window.geekdocSearchIndex=index;index.add({'id':0,'href':'/clients/web/','title':"ownCloud Web",'parent':"Clients",'content':"This is the next generation ownCloud frontend.\n"});index.add({'id':1,'href':'/ocis/','title':"oCIS - ownCloud Infinite Scale",'parent':"ownCloud",'content':" ownCloud Infinite Scale Welcome to oCIS, the modern file-sync and share platform, which is based on our knowledge and experience with the PHP based ownCloud server.\noCIS server The oCIS server implementation follows Go best practices and is based on the go-micro framework and REVA. We love and stick to 12 Factor. oCIS is a micro-service based server, which allows scale-out of individual services to meet your specific performance requirements. We run a huge test suite, which was originated in ownCloud 10 and continues to grow.\nArchitecture Overview document.addEventListener(\"DOMContentLoaded\", function(event) { mermaid.initialize({ flowchart: { useMaxWidth: true } }); }); graph TD proxy -- konnectd \u0026 web \u0026 thumbnails \u0026 ocs \u0026 webdav \u0026 storage \u0026 accounts \u0026 store \u0026 settings konnectd -- glauth storage -- REVA "});index.add({'id':2,'href':'/integration/file_picker/','title':"File Picker",'parent':"Integrations",'content':"Easily integrate ownCloud into your own product.\n"});index.add({'id':3,'href':'/clients/web/deployments/oc10-app/','title':"Deploy as an app in ownCloud 10",'parent':"Deployments",'content':" Prerequisites Deploying ownCloud Web Configure oauth2 Configure ownCloud 10 Configure ownCloud Web Accessing ownCloud Web The ownCloud Web is being deployed as an app to ownCloud marketplace to enable easy early integration into existing ownCloud 10 instances. After completing this setup, ownCloud Web will be available on https://\u0026lt;your-owncloud-server\u0026gt;/apps-external/web.\nDepending on your setup, the name of apps-external folder can vary. It is important to use the correct name in all of the mentioned URLs. Prerequisites Running ownCloud 10 server with version 10.6 Installed oauth2 app Deploying ownCloud Web Download ownCloud Web app from the marketplace and enable it.\nConfigure oauth2 In the Admin of ownCloud 10, head into User Authentication and add a new client with arbitrary name and redirection URL https://\u0026lt;your-owncloud-server\u0026gt;/apps-external/web/oidc-callback.html.\n Configure ownCloud 10 To display ownCloud Web in the app switcher and to redirect all private and public links to the new WebUI, add the following config into config/config.php:\n\u0026#39;web.baseUrl\u0026#39; =\u0026gt; \u0026#39;https://\u0026lt;your-owncloud-server\u0026gt;/apps-external/web\u0026#39;, Configure ownCloud Web There are a few config values which need to be set in order for ownCloud Web to work correctly. Navigate into apps-external/web and adjust config.json according to the following example:\n{ \u0026#34;server\u0026#34; : \u0026#34;https://\u0026lt;your-owncloud-server\u0026gt;\u0026#34;, // ownCloud 10 server address \u0026#34;theme\u0026#34;: \u0026#34;owncloud\u0026#34;, // Theme to be used in ownCloud Web pointing to a json file inside of `themes` folder \u0026#34;auth\u0026#34;: { \u0026#34;clientId\u0026#34;: \u0026#34;\u0026lt;client-id-from-oauth2\u0026gt;\u0026#34;, // Client ID received when adding ownCloud Web in the `User Authentication` section in `Admin` \u0026#34;url\u0026#34;: \u0026#34;https://\u0026lt;your-owncloud-server\u0026gt;/index.php/apps/oauth2/api/v1/token\u0026#34;, \u0026#34;authUrl\u0026#34;: \u0026#34;https://\u0026lt;your-owncloud-server\u0026gt;/index.php/apps/oauth2/authorize\u0026#34; }, \u0026#34;apps\u0026#34; : [ // List of extensions to be loaded \u0026#34;files\u0026#34; ], \u0026#34;applications\u0026#34; : [ // Apps to be displayed in the application switcher or in the user menu { \u0026#34;title\u0026#34;: { // Item in apps switcher pointing to the old ownCloud UI \u0026#34;en\u0026#34;: \u0026#34;Classic Design\u0026#34;, \u0026#34;de\u0026#34;: \u0026#34;Dateien\u0026#34;, \u0026#34;fr\u0026#34;: \u0026#34;Fichiers\u0026#34;, \u0026#34;zh_CN\u0026#34;: \u0026#34;文件\u0026#34; }, \u0026#34;icon\u0026#34;: \u0026#34;switch_ui\u0026#34;, \u0026#34;url\u0026#34;: \u0026#34;http://\u0026lt;your-owncloud-server\u0026gt;/index.php/apps/files\u0026#34; }, { // Item in user menu pointing to user settings in the old ownCloud UI \u0026#34;icon\u0026#34;: \u0026#34;application\u0026#34;, \u0026#34;menu\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;target\u0026#34;: \u0026#34;_self\u0026#34;, \u0026#34;title\u0026#34;: { \u0026#34;de\u0026#34;: \u0026#34;Einstellungen\u0026#34;, \u0026#34;en\u0026#34;: \u0026#34;Settings\u0026#34; }, \u0026#34;url\u0026#34;: \u0026#34;https://\u0026lt;your-owncloud-server\u0026gt;/index.php/settings/personal\u0026#34; } ] } Accessing ownCloud Web After following all the steps, you should see a new entry in the application switcher called New Design which points to the ownCloud web.\n "});index.add({'id':4,'href':'/ocis/configuration/','title':"Configuration",'parent':"oCIS - ownCloud Infinite Scale",'content':" Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands ocis list ocis run ocis health ocis server ocis kill List of available Extension subcommands ocis accounts ocis thumbnails ocis webdav ocis settings ocis storage-metadata ocis storage-userprovider ocis konnectd ocis store ocis ocs ocis storage-auth-bearer ocis storage-users ocis storage-sharing ocis glauth ocis proxy ocis web ocis storage-frontend ocis onlyoffice ocis storage-home ocis version ocis storage-public-link ocis storage-gateway ocis storage-auth-basic Configuration oCIS Single Binary is not responsible for configuring extensions. Instead, each extension could either be configured by environment variables, cli flags or config files.\nEach extension has its dedicated documentation page (e.g. proxy configuration) which lists all possible configurations. Config files and environment variables are picked up if you use the ./bin/ocis server command within the oCIS single binary. Command line flags must be set explicitly on the extensions subcommands.\nConfiguration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-proxy reads proxy.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nRoot Command ownCloud Infinite Scale Stack\nUsage: ocis [global options] command [command options] [arguments...]\n \u0026ndash;config-file | $OCIS_CONFIG_FILE Path to config file. \u0026ndash;log-level | $OCIS_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $OCIS_LOG_PRETTY Enable pretty logging. Default: false. \u0026ndash;log-color | $OCIS_LOG_COLOR Enable colored logging. Default: true. \u0026ndash;tracing-enabled | $OCIS_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $OCIS_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $OCIS_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $OCIS_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $OCIS_TRACING_SERVICE Service name for tracing. Default: ocis. \u0026ndash;jwt-secret | $OCIS_JWT_SECRET Used to dismantle the access token, should equal reva\u0026rsquo;s jwt-secret. Default: Pive-Fumkiu4. Sub Commands ocis list Lists running ocis extensions\nUsage: ocis list [command options] [arguments...]\nocis run Runs an extension\nUsage: ocis run [command options] [arguments...]\nocis health Check health status\nUsage: ocis health [command options] [arguments...]\n \u0026ndash;debug-addr | $OCIS_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9010. ocis server Start fullstack server\nUsage: ocis server [command options] [arguments...]\n \u0026ndash;debug-addr | $OCIS_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9010. \u0026ndash;debug-token | $OCIS_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $OCIS_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $OCIS_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $OCIS_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9000. \u0026ndash;http-root | $OCIS_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;grpc-addr | $OCIS_GRPC_ADDR Address to bind grpc server. Default: 0.0.0.0:9001. ocis kill Kill an extension by name\nUsage: ocis kill [command options] [arguments...]\nList of available Extension subcommands There are more subcommands to start the individual extensions. Please check the documentation about their usage and options in the dedicated section of the documentation.\nocis accounts Start accounts server\nocis thumbnails Start thumbnails server\nocis webdav Start webdav server\nocis settings Start settings server\nocis storage-metadata Start storage and data service for metadata\nocis storage-userprovider Start storage userprovider service\nocis konnectd Start konnectd server\nocis store Start a go-micro store\nocis ocs Start ocs server\nocis storage-auth-bearer Start storage auth-bearer service\nocis storage-users Start storage and data provider for /users mount\nocis storage-sharing Start storage sharing service\nocis glauth Start glauth server\nocis proxy Start proxy server\nocis web Start web server\nocis storage-frontend Start storage frontend\nocis onlyoffice Start onlyoffice server\nocis storage-home Start storage and data provider for /home mount\nocis version Lists running services with version\nocis storage-public-link Start storage public link storage\nocis storage-gateway Start storage gateway\nocis storage-auth-basic Start storage auth-basic service\n"});index.add({'id':5,'href':'/integration/file_picker/getting-started/','title':"Getting Started",'parent':"File Picker",'content':" Components of the File picker File picker Location picker ownCloud File picker is a web component which can be integrated into existing web applications. It connects to an ownCloud server and enables a user to select resources which are then provided in a response of a fired event. Visit installation to see how to integrate the File picker into your product.\nComponents of the File picker The file picker can be used in two different variations: File picker and location picker.\nFile picker The file picker enables users to select multiple resources and is intended to bring resources from within ownCloud into your web applications.\nLocation picker The location picker allows only one folder to be selected and its main purpose is to enable users to save files into the connected ownCloud instance.\n"});index.add({'id':6,'href':'/integration/file_picker/installation/','title':"Installation",'parent':"File Picker",'content':" Setup authorization Install File picker package Integrate in HTML page with vanilla JavaScript Integrate in Vue web application Set correct variation Pass bearer token Setup authorization The config for authorization is provided via a json file. Location of the file can be provided via a prop called configLocation. This requires full URL address (e.g. https://\u0026lt;your-server\u0026gt;/\u0026lt;path-to-the-config\u0026gt;). If the prop is not defined, the location will fallback to https://\u0026lt;your-server\u0026gt;/file-picker-config.json. The config can point to both oauth2 and OIDC. You can take a look at the following example to see how OIDC can be defined:\n{ \u0026#34;server\u0026#34;: \u0026#34;\u0026lt;owncloud-server\u0026gt;\u0026#34;, \u0026#34;openIdConnect\u0026#34;: { \u0026#34;metadata_url\u0026#34;: \u0026#34;\u0026lt;your-server\u0026gt;/.well-known/openid-configuration\u0026#34;, \u0026#34;authority\u0026#34;: \u0026#34;\u0026lt;your-server\u0026gt;\u0026#34;, \u0026#34;client_id\u0026#34;: \u0026#34;\u0026lt;client-id\u0026gt;\u0026#34;, \u0026#34;response_type\u0026#34;: \u0026#34;code\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;openid profile email\u0026#34; }, } Install File picker package To integrate File picker into your own product, you can install it via one of the following commands:\nnpm install @ownclouders/file-picker --save # OR yarn add @ownclouders/file-picker Integrate in HTML page with vanilla JavaScript When including File picker in an HTML page, it is important to include Vue.js as well. In this case, we will import it via unpkg. Without this, the component won\u0026rsquo;t work. Vue needs to be included also if you\u0026rsquo;re importing the File picker into a web application built with other framework than Vue (e.g. React, Angular).\nFor the purpose of this example, we will assume that you do not move installed packages and include the folder \u0026ldquo;node_modules\u0026rdquo; with installed packages in the same location as your index.html file on your server.\n... \u0026lt;meta charset=\u0026#34;utf-8\u0026#34;\u0026gt; \u0026lt;title\u0026gt;File picker example\u0026lt;/title\u0026gt; \u0026lt;script src=\u0026#34;https://unpkg.com/vue\u0026#34;\u0026gt;\u0026lt;/script\u0026gt; \u0026lt;script src=\u0026#34;./node_modules/file-picker/dist/file-picker.js\u0026#34;\u0026gt;\u0026lt;/script\u0026gt; ... \u0026lt;file-picker id=\u0026#34;file-picker\u0026#34; variation=\u0026#34;resource\u0026#34;\u0026gt;\u0026lt;/file-picker\u0026gt; Integrate in Vue web application There is a caveat when using the File picker inside an existing Vue application. Since the web component will be imported before Vue, we need to define it as a global variable on our own. This requires us to separate the import of Vue into a bootstrap file.\nvue.js:\nimport Vue from \u0026#39;vue\u0026#39; window.Vue = Vue main.js:\nimport Vue from \u0026#39;./vue\u0026#39; new Vue(...) When importing the component, we need to reach it under the .default key.\n\u0026lt;template\u0026gt; \u0026lt;file-picker variation=\u0026#34;location\u0026#34; /\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script\u0026gt; export default: { components: { FilePicker: require(\u0026#39;@owncloud/file-picker\u0026#39;).default } } \u0026lt;/script\u0026gt; Set correct variation As described in Getting Started, File picker comes in two variations. To define which one should be used, you need to pass it to the component via its variation property. Valid values are:\n resource - File picker location - Location picker Pass bearer token In case you already have a bearer token and want to skip the whole authorization process inside of the File picker, you can pass it to the component via prop called bearerToken.\n"});index.add({'id':7,'href':'/integration/file_picker/accessing-resources/','title':"Accessing Resources",'parent':"File Picker",'content':" Access resources File picker is returning selected resources via event called selectResources. To access them, you need to set an event listener where you\u0026rsquo;ll be able to get them as part of the response of the callback function.\nAccess resources \u0026lt;file-picker id=\u0026#34;file-picker\u0026#34; variation=\u0026#34;resource\u0026#34;\u0026gt;\u0026lt;/file-picker\u0026gt; \u0026lt;script\u0026gt; const item = document.getElementById(\u0026#39;file-picker\u0026#39;) let resources = [] item.addEventListener(\u0026#39;selectResources\u0026#39;, event =\u0026gt; { resources = event.detail[0] }) \u0026lt;/script\u0026gt; "});index.add({'id':8,'href':'/ocis/deployment/preparing_server/','title':"Preparing a server",'parent':"Deployment",'content':" Example for Hetzner Cloud Example for Hetzner Cloud create server on Hetzner Cloud. Set labels \u0026ldquo;owner\u0026rdquo; and \u0026ldquo;for\u0026rdquo;. Example for hcloud cli: hcloud server create --type cx21 --image ubuntu-20.04 --ssh-key admin --name ocis-server --label owner=admin --label for=testing\n Configure DNS A-records for needed domains pointing on the servers ip address, for example in CloudFlare\n Access server via ssh as root\n Create a new user\n$ adduser --disabled-password --gecos \u0026quot;\u0026quot; admin\n Add user to sudo group\n$ usermod -aG sudo admin\n Install docker\napt update apt install docker.io Add user to docker group\nusermod -aG docker admin\n Install docker-compose via\ncurl -L \u0026quot;https://github.com/docker/compose/releases/download/1.27.4/docker-compose-$(uname -s)-$(uname -m)\u0026quot; -o /usr/local/bin/docker-compose\n(docker compose version 1.27.4 as of today)\n Make docker-compose executable\nchmod +x /usr/local/bin/docker-compose\n Add users pub key to\nmkdir /home/admin/.ssh echo \u0026#34;\u0026lt;pubkey\u0026gt;\u0026#34; \u0026gt;\u0026gt; /home/admin/.ssh/authorized_keys` chown admin:admin -R /home/admin/.ssh Secure ssh daemon by editing /etc/ssh/sshd_config\nPermitRootLogin no ChallengeResponseAuthentication no PasswordAuthentication no UsePAM no restart sshd server to apply settings systemctl restart sshd\n Login as the user you created\n "});index.add({'id':9,'href':'/ocis/development/','title':"Development",'parent':"oCIS - ownCloud Infinite Scale",'content':""});index.add({'id':10,'href':'/clients/web/getting-started/','title':"Getting Started",'parent':"ownCloud Web",'content':" Installation Docker Binaries Source code Configuration Options Setting up backend and running Running Installation Docker TBD\nBinaries TBD\nSource code The source code is hosted at https://github.com/owncloud/web Please refer to the build documentation for Web.\nConfiguration Depending on the backend you are using, there are sample config files provided in the ownCloud Web git repository. Please refer to the configuration details below.\nOptions options.hideSearchBar Lets you hide the search bar at the top of the screen for all users. options.homeFolder You can specify a folder that is used when the user navigates home. Navigating home gets triggered by clicking on the All files menu item. The user will not be jailed in that directory. It simply serves as a default location. You can either provide a static location, or you can use variables of the user object to come up with a user specific home path. This uses twig template variable style and allows you to pick a value or a substring of a value of the authenticated user. Examples are /Shares, /{{.Id}} and /{{substr 0 3 .Id}}/{{.Id}. options.disablePreviews Set this option to true to disable previews in all the different file listing views. The only list view that is not affected by this is the trash bin, as that doesn\u0026rsquo;t allow showing previews at all. Setting up backend and running Web can run against either ownCloud 10 as backend or OCIS. Depending which one you chose, please check the matching section:\n Setting up with ownCloud as backend Setting up with OCIS as backend Running Running with ownCloud as backend Running with OCIS as backend "});index.add({'id':11,'href':'/extensions/ocis_hello/getting-started/','title':"Getting Started",'parent':"Hello",'content':" Installation Docker Binaries Configuration Envrionment variables Global Server Health Commandline flags Global Server Health Configuration file Usage Server Health Metrics Installation So far we are offering two different variants for the installation. You can choose between Docker or pre-built binaries which are stored on our download mirrors and GitHub releases. Maybe we will also provide system packages for the major distributions later if we see the need for it.\nDocker TBD\nBinaries TBD\nConfiguration We provide overall three different variants of configuration. The variant based on environment variables and commandline flags are split up into global values and command-specific values.\nEnvrionment variables If you prefer to configure the service with environment variables you can see the available variables below.\nGlobal HELLO_CONFIG_FILE Path to config file, empty default value HELLO_LOG_LEVEL Set logging level, defaults to info HELLO_LOG_COLOR Enable colored logging, defaults to true HELLO_LOG_PRETTY Enable pretty logging, defaults to true Server HELLO_TRACING_ENABLED Enable sending traces, defaults to false HELLO_TRACING_TYPE Tracing backend type, defaults to jaeger HELLO_TRACING_ENDPOINT Endpoint for the agent, empty default value HELLO_TRACING_COLLECTOR Endpoint for the collector, empty default value HELLO_TRACING_SERVICE Service name for tracing, defaults to hello HELLO_DEBUG_ADDR Address to bind debug server, defaults to 0.0.0.0:9109 HELLO_DEBUG_TOKEN Token to grant metrics access, empty default value HELLO_DEBUG_PPROF Enable pprof debugging, defaults to false HELLO_DEBUG_ZPAGES Enable zpages debugging, defaults to false HELLO_HTTP_ADDR Address to bind http server, defaults to 0.0.0.0:9105 HELLO_HTTP_ROOT Root path of http server, defaults to / HELLO_GRPC_ADDR Address to bind grpc server, defaults to 0.0.0.0:9106 HELLO_ASSET_PATH Path to custom assets, empty default value Health HELLO_DEBUG_ADDR Address to debug endpoint, defaults to 0.0.0.0:9109 Commandline flags If you prefer to configure the service with commandline flags you can see the available variables below.\nGlobal \u0026ndash;config-file Path to config file, empty default value \u0026ndash;log-level Set logging level, defaults to info \u0026ndash;log-color Enable colored logging, defaults to true \u0026ndash;log-pretty Enable pretty logging, defaults to true Server \u0026ndash;tracing-enabled Enable sending traces, defaults to false \u0026ndash;tracing-type Tracing backend type, defaults to jaeger \u0026ndash;tracing-endpoint Endpoint for the agent, empty default value \u0026ndash;tracing-collector Endpoint for the collector, empty default value \u0026ndash;tracing-service Service name for tracing, defaults to hello \u0026ndash;debug-addr Address to bind debug server, defaults to 0.0.0.0:9109 \u0026ndash;debug-token Token to grant metrics access, empty default value \u0026ndash;debug-pprof Enable pprof debugging, defaults to false \u0026ndash;debug-zpages Enable zpages debugging, defaults to false \u0026ndash;http-addr Address to bind http server, defaults to 0.0.0.0:9105 \u0026ndash;http-root Root path of http server, defaults to / \u0026ndash;grpc-addr Address to bind grpc server, defaults to 0.0.0.0:9106 \u0026ndash;asset-path Path to custom assets, empty default value Health \u0026ndash;debug-addr Address to debug endpoint, defaults to 0.0.0.0:9109 Configuration file So far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/hello.yml, ${HOME}/.ocis/hello.yml or $(pwd)/config/hello.yml.\nUsage The program provides a few sub-commands on execution. The available configuration methods have already been mentioned above. Generally you can always see a formated help output if you execute the binary via ocis-hello --help.\nServer The server command is used to start the http and debug server on two addresses within a single process. The http server is serving the general webservice while the debug server is used for health check, readiness check and to server the metrics mentioned below. For further help please execute:\nocis-hello server --help Health The health command is used to execute a health check, if the exit code equals zero the service should be up and running, if the exist code is greater than zero the service is not in a healthy state. Generally this command is used within our Docker containers, it could also be used within Kubernetes.\nocis-hello health --help Metrics This service provides some Prometheus metrics through the debug endpoint, you can optionally secure the metrics endpoint by some random token, which got to be configured through one of the flag --debug-token or the environment variable HELLO_DEBUG_TOKEN mentioned above. By default the metrics endpoint is bound to http://0.0.0.0:9109/metrics.\n go_gc_duration_seconds A summary of the GC invocation durations go_gc_duration_seconds_sum A summary of the GC invocation durations go_gc_duration_seconds_count A summary of the GC invocation durations go_goroutines Number of goroutines that currently exist go_info Information about the Go environment go_memstats_alloc_bytes Number of bytes allocated and still in use go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table go_memstats_frees_total Total number of frees go_memstats_gc_cpu_fraction The fraction of this program\u0026rsquo;s available CPU time used by the GC since the program started go_memstats_gc_sys_bytes Number of bytes used for garbage collection system metadata go_memstats_heap_alloc_bytes Number of heap bytes allocated and still in use go_memstats_heap_idle_bytes Number of heap bytes waiting to be used go_memstats_heap_inuse_bytes Number of heap bytes that are in use go_memstats_heap_objects Number of allocated objects go_memstats_heap_released_bytes Number of heap bytes released to OS go_memstats_heap_sys_bytes Number of heap bytes obtained from system go_memstats_last_gc_time_seconds Number of seconds since 1970 of last garbage collection go_memstats_lookups_total Total number of pointer lookups go_memstats_mallocs_total Total number of mallocs go_memstats_mcache_inuse_bytes Number of bytes in use by mcache structures go_memstats_mcache_sys_bytes Number of bytes used for mcache structures obtained from system go_memstats_mspan_inuse_bytes Number of bytes in use by mspan structures go_memstats_mspan_sys_bytes Number of bytes used for mspan structures obtained from system go_memstats_next_gc_bytes Number of heap bytes when next garbage collection will take place go_memstats_other_sys_bytes Number of bytes used for other system allocations go_memstats_stack_inuse_bytes Number of bytes in use by the stack allocator go_memstats_stack_sys_bytes Number of bytes obtained from system for stack allocator go_memstats_sys_bytes Number of bytes obtained from system go_threads Number of OS threads created promhttp_metric_handler_requests_in_flight Current number of scrapes being served promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code "});index.add({'id':12,'href':'/extensions/onlyoffice/','title':"OnlyOffice",'parent':"Extensions",'content':"This service enables users open documents, spreadsheets and presentations in the OnlyOffice app installed in ownCloud 10.\n"});index.add({'id':13,'href':'/ocis/development/getting-started/','title':"Getting Started",'parent':"Development",'content':" Requirements Repository structure Starting points Developing oCIS Developing extensions Requirements We want contribution to oCIS and the creation of extensions to be as easy as possible. So we are trying to reflect this in the tooling. It should be kept simple and quick to be set up.\nBesides standard development tools like git and a text editor, you need the following software for development:\n Go \u0026gt;= v1.13 (install instructions) Yarn (install instructions) docker (install instructions) docker-compose (install instructions) If you find tools needed besides the mentioned above, please feel free to open an issue or open a PR.\nRepository structure This repository follows the golang-standard project-layout.\noCIS consists of multiple micro services, also called extensions. We started by having standalone repositories for each of them but quickly noticed, that this adds a time consuming overhead for developers. So we ended up with a monorepo housing all the extensions in one repository.\nEach of the extensions live in a subfolder (eg. accounts or settings) in this repository, technically creating independant Go modules.\nThe ocis folder does also contain a Go module but is no extension at all. Instead this module is used to import all extensions and furthermore implement commands to start the extensions. With the resulting oCIS binary you can start single extensions or even all extensions at the same time.\nThe docs folder contains the source for the oCIS documentation.\nThe deployments folder contains documented deployment configurations and templates.\nThe scripts folder contains scripts to perform various build, install, analysis, etc operations.\nStarting points Depending on what you want to develop there are different starting points. These will be described below.\nDeveloping oCIS If you want to contribute to oCIS:\n see contribution guidelines make sure the tooling is set up by building oCIS and building the docs create or pick an open issue to develop on and mention in the issue that you are working on it open a PR and get things done Developing extensions If you want to develop an extension, start here: Extensions\n"});index.add({'id':14,'href':'/ocis/deployment/basic-remote-setup/','title':"Basic Remote Setup",'parent':"Deployment",'content':" Use the binary Add your hostname to the idp config Start the ocis fullstack server Use Docker Compose Out of the box the ocis single binary and the owncloud/ocis docker image are configured to run on localhost for quick testing and development.\nIf you need to access ocis on a VM or a remote machine e.g. when testing a mobile client you need to configure ocis to run on a different host.\nUse the binary If you start the ocis fullstack for the first time with ./bin/ocis server it will generate a file identifier-registration.yml in the config folder relative to its location. This file is used to configure the clients for the built-in Identity Provider.\nOutdated version\nThe identifier-registration.yml file will only be generated if there is no such file in place. You could miss updates on this file. Run make clean to delete the file and keep the development environment tidy otherwise as well. Add your hostname to the idp config Let us assume your-host is your remote domain name or IP adress. Add your host to the identifier-registration.yml like this:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # OpenID Connect client registry.clients:- id:webname:ownCloudwebappapplication_type:webinsecure:yestrusted:yesredirect_uris:- http://localhost:9100/- http://localhost:9100/oidc-callback.html- http://localhost:9100/oidc-silent-redirect.html- https://localhost:9200/- https://localhost:9200/oidc-callback.html- https://localhost:9200/oidc-silent-redirect.html- https://your-server:9200/- https://your-server:9200/oidc-callback.html- https://your-server:9200/oidc-silent-redirect.htmlorigins:- http://localhost:9100- https://localhost:9200- https://your-server:9200 In this example we do not change the default port (9200). But this could be changed to another port.\nStart the ocis fullstack server You need to configure your-host in some services to provide the needed public resources.\nPROXY_HTTP_ADDR=0.0.0.0:9200 \\ KONNECTD_ISS=https://your-server:9200 \\ REVA_OIDC_ISSUER=https://your-server:9200 \\ WEB_OIDC_AUTHORITY=https://your-server:9200 \\ WEB_UI_CONFIG_SERVER=https://your-server:9200 \\ WEB_OIDC_METADATA_URL=https://your-server:9200/.well-known/openid-configuration \\ REVA_DATAGATEWAY_URL=https://your-server:9200/data \\ REVA_FRONTEND_URL=https://your-server:9200 \\ PROXY_TRANSPORT_TLS_KEY=./certs/your-host.key \\ PROXY_TRANSPORT_TLS_CERT=./certs/your-host.crt \\ KONNECTD_TLS=0 \\ ./bin/ocis server For more configuration options check the configuration secion in ocis and every ocis extension.\nTLS Certificate\nIn this example, we are replacing the default self signed cert with a CA signed one to avoid the certificate warning when accessing the login page. Use Docker Compose We are using our docker compose playground as a repository to share snippets that make our test setups easier and more aligned.\nYou can start oCIS with docker very easily on a different host using this snippet.\nLet us assume your local IP is 192.168.103.195\ngit clone https://github.com/owncloud-docker/compose-playground.git cd compose-playground/compose/ocis sed -i -e \u0026#39;s/your-url/192.168.103.195/g\u0026#39; config/identifier-registration.yml cat \u0026lt;\u0026lt; EOF \u0026gt; .env OCIS_BASE_URL=192.168.103.195 OCIS_HTTP_PORT=9200 OCIS_DOCKER_TAG=latest EOF curl -k https://192.168.103.195:9200/status.php "});index.add({'id':15,'href':'/extensions/onlyoffice/configuration/','title':"Configuration",'parent':"OnlyOffice",'content':" Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands onlyoffice server onlyoffice health Configuration oCIS Single Binary is not responsible for configuring extensions. Instead, each extension could either be configured by environment variables, cli flags or config files.\nEach extension has its dedicated documentation page (e.g. https://owncloud.github.io/extensions/onlyoffice/configuration) which lists all possible configurations. Config files and environment variables are picked up if you use the ./bin/ocis server command within the oCIS single binary. Command line flags must be set explicitly on the extensions subcommands.\nConfiguration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: onlyoffice reads onlyoffice.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nRoot Command OnlyOffice oCIS extension\nUsage: onlyoffice [global options] command [command options] [arguments...]\n \u0026ndash;config-file | $ONLYOFFICE_CONFIG_FILE Path to config file. \u0026ndash;log-level | $ONLYOFFICE_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $ONLYOFFICE_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $ONLYOFFICE_LOG_COLOR Enable colored logging. Default: true. Sub Commands onlyoffice server Start integrated server\nUsage: onlyoffice server [command options] [arguments...]\n \u0026ndash;tracing-enabled | $ONLYOFFICE_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $ONLYOFFICE_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $ONLYOFFICE_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $ONLYOFFICE_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $ONLYOFFICE_TRACING_SERVICE Service name for tracing. Default: onlyoffice. \u0026ndash;debug-addr | $ONLYOFFICE_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9224. \u0026ndash;debug-token | $ONLYOFFICE_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $ONLYOFFICE_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $ONLYOFFICE_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $ONLYOFFICE_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9220. \u0026ndash;http-namespace | $ONLYOFFICE_HTTP_NAMESPACE Set the base namespace for the http namespace. Default: com.owncloud.web. \u0026ndash;http-root | $ONLYOFFICE_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;asset-path | $ONLYOFFICE_ASSET_PATH Path to custom assets. onlyoffice health Check health status\nUsage: onlyoffice health [command options] [arguments...]\n \u0026ndash;debug-addr | $ONLYOFFICE_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9224. "});index.add({'id':16,'href':'/extensions/webdav/configuration/','title':"Configuration",'parent':"WebDaV",'content':" Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands webdav health webdav server webdav version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-proxy reads proxy.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nRoot Command Serve WebDAV API for oCIS\nUsage: webdav [global options] command [command options] [arguments...]\n \u0026ndash;log-level | $WEBDAV_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $WEBDAV_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $WEBDAV_LOG_COLOR Enable colored logging. Default: true. Sub Commands webdav health Check health status\nUsage: webdav health [command options] [arguments...]\n \u0026ndash;debug-addr | $WEBDAV_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9119. webdav server Start integrated server\nUsage: webdav server [command options] [arguments...]\n \u0026ndash;config-file | $WEBDAV_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $WEBDAV_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $WEBDAV_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $WEBDAV_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $WEBDAV_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $WEBDAV_TRACING_SERVICE Service name for tracing. Default: webdav. \u0026ndash;debug-addr | $WEBDAV_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9119. \u0026ndash;debug-token | $WEBDAV_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $WEBDAV_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $WEBDAV_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $WEBDAV_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9115. \u0026ndash;http-namespace | $WEBDAV_HTTP_NAMESPACE Set the base namespace for service discovery. Default: com.owncloud.web. \u0026ndash;service-name | $WEBDAV_SERVICE_NAME Service name. Default: webdav. \u0026ndash;http-root | $WEBDAV_HTTP_ROOT Root path of http server. Default: /. webdav version Print the versions of the running instances\nUsage: webdav version [command options] [arguments...]\n \u0026ndash;http-namespace | $WEBDAV_HTTP_NAMESPACE Set the base namespace for service discovery. Default: com.owncloud.web. \u0026ndash;service-name | $WEBDAV_SERVICE_NAME Service name. Default: webdav. "});index.add({'id':17,'href':'/extensions/thumbnails/configuration/','title':"Configuration",'parent':"Thumbnails",'content':" Configuration Configuration using config files Environment variables Commandline flags thumbnails health thumbnails server thumbnails ocis-thumbnails thumbnails version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-proxy reads proxy.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nthumbnails health Check health status\nUsage: thumbnails health [command options] [arguments...]\n \u0026ndash;debug-addr | $THUMBNAILS_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9189. thumbnails server Start integrated server\nUsage: thumbnails server [command options] [arguments...]\n \u0026ndash;config-file | $THUMBNAILS_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $THUMBNAILS_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $THUMBNAILS_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $THUMBNAILS_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $THUMBNAILS_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $THUMBNAILS_TRACING_SERVICE Service name for tracing. Default: thumbnails. \u0026ndash;debug-addr | $THUMBNAILS_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9189. \u0026ndash;debug-token | $THUMBNAILS_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $THUMBNAILS_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $THUMBNAILS_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;grpc-name | $THUMBNAILS_GRPC_NAME Name of the service. Default: thumbnails. \u0026ndash;grpc-addr | $THUMBNAILS_GRPC_ADDR Address to bind grpc server. Default: 0.0.0.0:9185. \u0026ndash;grpc-namespace | $THUMBNAILS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;filesystemstorage-root | $THUMBNAILS_FILESYSTEMSTORAGE_ROOT Root path of the filesystem storage directory. Default: filepath.Join(os.TempDir(), \u0026quot;ocis-thumbnails/\u0026quot;). \u0026ndash;webdavsource-baseurl | $THUMBNAILS_WEBDAVSOURCE_BASEURL Base url for a webdav api. Default: https://localhost:9200/remote.php/webdav/. \u0026ndash;webdavsource-insecure | $THUMBNAILS_WEBDAVSOURCE_INSECURE Whether to skip certificate checks. Default: true. thumbnails ocis-thumbnails Example usage\nUsage: thumbnails ocis-thumbnails [command options] [arguments...]\n \u0026ndash;log-level | $THUMBNAILS_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $THUMBNAILS_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $THUMBNAILS_LOG_COLOR Enable colored logging. Default: true. thumbnails version Print the versions of the running instances\nUsage: thumbnails version [command options] [arguments...]\n \u0026ndash;grpc-name | $THUMBNAILS_GRPC_NAME Name of the service. Default: thumbnails. \u0026ndash;grpc-namespace | $THUMBNAILS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. "});index.add({'id':18,'href':'/extensions/store/configuration/','title':"Configuration",'parent':"Store",'content':" Configuration Configuration using config files Environment variables Commandline flags store version store health store server store ocis-store Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-proxy reads proxy.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nstore version Print the versions of the running instances\nUsage: store version [command options] [arguments...]\n \u0026ndash;grpc-namespace | $STORE_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $STORE_NAME Service name. Default: store. store health Check health status\nUsage: store health [command options] [arguments...]\n \u0026ndash;debug-addr | $STORE_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9460. store server Start integrated server\nUsage: store server [command options] [arguments...]\n \u0026ndash;tracing-enabled | $STORE_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $STORE_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $STORE_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $STORE_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $STORE_TRACING_SERVICE Service name for tracing. Default: store. \u0026ndash;debug-addr | $STORE_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9460. \u0026ndash;debug-token | $STORE_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $STORE_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $STORE_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;grpc-namespace | $STORE_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $STORE_NAME Service name. Default: store. \u0026ndash;data-path | $STORE_DATA_PATH location of the store data path. Default: /var/tmp/ocis/store. store ocis-store Service to store values for ocis extensions\nUsage: store ocis-store [command options] [arguments...]\n \u0026ndash;config-file | $STORE_CONFIG_FILE Path to config file. \u0026ndash;log-level | $STORE_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $STORE_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $STORE_LOG_COLOR Enable colored logging. Default: true. "});index.add({'id':19,'href':'/extensions/storage/configuration/','title':"Configuration",'parent':"Storage",'content':" Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands storage storage-home storage storage-metadata storage storage-users storage storage-public-link storage gateway storage auth-basic storage users storage frontend storage sharing storage storage storage health storage auth-bearer Config for the different Storage Drivers Local Driver Eos Driver owCloud Driver Ocis Driver Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-proxy reads proxy.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nRoot Command Storage service for oCIS\nUsage: storage [global options] command [command options] [arguments...]\n \u0026ndash;config-file | $STORAGE_CONFIG_FILE Path to config file. \u0026ndash;log-level | $STORAGE_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $STORAGE_LOG_PRETTY Enable pretty logging. \u0026ndash;log-color | $STORAGE_LOG_COLOR Enable colored logging. Sub Commands storage storage-home Start storage-home service\nUsage: storage storage-home [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_HOME_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9156. \u0026ndash;grpc-network | $STORAGE_HOME_GRPC_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;grpc-addr | $STORAGE_HOME_GRPC_ADDR Address to bind storage service. Default: 0.0.0.0:9154. \u0026ndash;http-network | $STORAGE_HOME_HTTP_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;http-addr | $STORAGE_HOME_HTTP_ADDR Address to bind storage service. Default: 0.0.0.0:9155. \u0026ndash;driver | $STORAGE_HOME_DRIVER storage driver for home mount: eg. local, eos, owncloud, ocis or s3. Default: ocis. \u0026ndash;mount-path | $STORAGE_HOME_MOUNT_PATH mount path. Default: /home. \u0026ndash;mount-id | $STORAGE_HOME_MOUNT_ID mount id. Default: 1284d238-aa92-42ce-bdc4-0b0000009157. \u0026ndash;expose-data-server | $STORAGE_HOME_EXPOSE_DATA_SERVER exposes a dedicated data server. Default: false. \u0026ndash;data-server-url | $STORAGE_HOME_DATA_SERVER_URL data server url. Default: http://localhost:9155/data. \u0026ndash;http-prefix | $STORAGE_HOME_HTTP_PREFIX prefix for the http endpoint, without leading slash. Default: data. \u0026ndash;tmp-folder | $STORAGE_HOME_TMP_FOLDER path to tmp folder. Default: /var/tmp/ocis/tmp/home. \u0026ndash;enable-home | $STORAGE_HOME_ENABLE_HOME enable the creation of home directories. Default: true. \u0026ndash;gateway-endpoint | $STORAGE_GATEWAY_ENDPOINT endpoint to use for the storage gateway service. Default: localhost:9142. \u0026ndash;users-endpoint | $STORAGE_USERPROVIDER_ENDPOINT endpoint to use for the storage service. Default: localhost:9144. storage storage-metadata Start storage-metadata service\nUsage: storage storage-metadata [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_METADATA_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9217. \u0026ndash;grpc-network | $STORAGE_METADATA_GRPC_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;grpc-addr | $STORAGE_METADATA_GRPC_PROVIDER_ADDR Address to bind storage service. Default: 0.0.0.0:9215. \u0026ndash;data-server-url | $STORAGE_METADATA_DATA_SERVER_URL URL of the data-provider the storage-provider uses. Default: http://localhost:9216. \u0026ndash;http-network | $STORAGE_METADATA_HTTP_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;http-addr | $STORAGE_METADATA_HTTP_ADDR Address to bind storage service. Default: 0.0.0.0:9216. \u0026ndash;tmp-folder | $STORAGE_METADATA_TMP_FOLDER path to tmp folder. Default: /var/tmp/ocis/tmp/metadata. \u0026ndash;driver | $STORAGE_METADATA_DRIVER storage driver for metadata mount: eg. local, eos, owncloud, ocis or s3. Default: ocis. \u0026ndash;gateway-endpoint | $STORAGE_GATEWAY_ENDPOINT endpoint to use for the gateway service. Default: localhost:9142. \u0026ndash;userprovider-endpoint | $STORAGE_USERPROVIDER_ENDPOINT endpoint to use for the userprovider service. Default: localhost:9144. \u0026ndash;storage-root | $STORAGE_METADATA_ROOT the path to the metadata storage root. Default: /var/tmp/ocis/storage/metadata. storage storage-users Start storage-users service\nUsage: storage storage-users [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_USERS_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9159. \u0026ndash;grpc-network | $STORAGE_USERS_GRPC_NETWORK Network to use for the users storage, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;grpc-addr | $STORAGE_USERS_GRPC_ADDR GRPC Address to bind users storage. Default: 0.0.0.0:9157. \u0026ndash;http-network | $STORAGE_USERS_HTTP_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;http-addr | $STORAGE_USERS_HTTP_ADDR HTTP Address to bind users storage. Default: 0.0.0.0:9158. \u0026ndash;driver | $STORAGE_USERS_DRIVER storage driver for users mount: eg. local, eos, owncloud, ocis or s3. Default: ocis. \u0026ndash;mount-path | $STORAGE_USERS_MOUNT_PATH mount path. Default: /users. \u0026ndash;mount-id | $STORAGE_USERS_MOUNT_ID mount id. Default: 1284d238-aa92-42ce-bdc4-0b0000009157. \u0026ndash;expose-data-server | $STORAGE_USERS_EXPOSE_DATA_SERVER exposes a dedicated data server. Default: false. \u0026ndash;data-server-url | $STORAGE_USERS_DATA_SERVER_URL data server url. Default: http://localhost:9158/data. \u0026ndash;http-prefix | $STORAGE_USERS_HTTP_PREFIX prefix for the http endpoint, without leading slash. Default: data. \u0026ndash;tmp-folder | $STORAGE_USERS_TMP_FOLDER path to tmp folder. Default: /var/tmp/ocis/tmp/users. \u0026ndash;gateway-endpoint | $STORAGE_GATEWAY_ENDPOINT endpoint to use for the storage gateway service. Default: localhost:9142. \u0026ndash;users-endpoint | $STORAGE_USERPROVIDER_ENDPOINT endpoint to use for the storage service. Default: localhost:9144. storage storage-public-link Start storage-public-link service\nUsage: storage storage-public-link [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_PUBLIC_LINK_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9179. \u0026ndash;network | $STORAGE_PUBLIC_LINK_GRPC_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;addr | $STORAGE_PUBLIC_LINK_GRPC_ADDR Address to bind storage service. Default: 0.0.0.0:9178. \u0026ndash;mount-path | $STORAGE_PUBLIC_LINK_MOUNT_PATH mount path. Default: /public. \u0026ndash;gateway-endpoint | $STORAGE_GATEWAY_ENDPOINT endpoint to use for the storage gateway service. Default: localhost:9142. storage gateway Start gateway\nUsage: storage gateway [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_GATEWAY_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9143. \u0026ndash;transfer-secret | $STORAGE_TRANSFER_SECRET Transfer secret for datagateway. Default: replace-me-with-a-transfer-secret. \u0026ndash;network | $STORAGE_GATEWAY_GRPC_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;addr | $STORAGE_GATEWAY_GRPC_ADDR Address to bind storage service. Default: 0.0.0.0:9142. \u0026ndash;endpoint | $STORAGE_GATEWAY_ENDPOINT endpoint to use for the storage service. Default: localhost:9142. \u0026ndash;commit-share-to-storage-grant | $STORAGE_GATEWAY_COMMIT_SHARE_TO_STORAGE_GRANT Commit shares to the share manager. Default: true. \u0026ndash;commit-share-to-storage-ref | $STORAGE_GATEWAY_COMMIT_SHARE_TO_STORAGE_REF Commit shares to the storage. Default: true. \u0026ndash;share-folder | $STORAGE_GATEWAY_SHARE_FOLDER mount shares in this folder of the home storage provider. Default: Shares. \u0026ndash;disable-home-creation-on-login | $STORAGE_GATEWAY_DISABLE_HOME_CREATION_ON_LOGIN Disable creation of home folder on login. \u0026ndash;auth-basic-endpoint | $STORAGE_AUTH_BASIC_ENDPOINT endpoint to use for the basic auth provider. Default: localhost:9146. \u0026ndash;auth-bearer-endpoint | $STORAGE_AUTH_BEARER_ENDPOINT endpoint to use for the bearer auth provider. Default: localhost:9148. \u0026ndash;storage-registry-driver | $STORAGE_STORAGE_REGISTRY_DRIVER driver of the storage registry. Default: static. \u0026ndash;storage-home-provider | $STORAGE_REGISTRY_HOME_PROVIDER mount point of the storage provider for user homes in the global namespace. Default: /home. \u0026ndash;public-url | $STORAGE_FRONTEND_PUBLIC_URL URL to use for the storage service. Default: https://localhost:9200. \u0026ndash;datagateway-url | $STORAGE_DATAGATEWAY_PUBLIC_URL URL to use for the storage datagateway. Default: https://localhost:9200/data. \u0026ndash;userprovider-endpoint | $STORAGE_USERPROVIDER_ENDPOINT endpoint to use for the userprovider. Default: localhost:9144. \u0026ndash;sharing-endpoint | $STORAGE_SHARING_ENDPOINT endpoint to use for the storage service. Default: localhost:9150. \u0026ndash;storage-home-endpoint | $STORAGE_HOME_ENDPOINT endpoint to use for the home storage. Default: localhost:9154. \u0026ndash;storage-home-mount-path | $STORAGE_HOME_MOUNT_PATH mount path. Default: /home. \u0026ndash;storage-home-mount-id | $STORAGE_HOME_MOUNT_ID mount id. Default: 1284d238-aa92-42ce-bdc4-0b0000009154. \u0026ndash;storage-users-endpoint | $STORAGE_USERS_ENDPOINT endpoint to use for the users storage. Default: localhost:9157. \u0026ndash;storage-users-mount-path | $STORAGE_USERS_MOUNT_PATH mount path. Default: /users. \u0026ndash;storage-users-mount-id | $STORAGE_USERS_MOUNT_ID mount id. Default: 1284d238-aa92-42ce-bdc4-0b0000009157. \u0026ndash;public-link-endpoint | $STORAGE_PUBLIC_LINK_ENDPOINT endpoint to use for the public links service. Default: localhost:9178. \u0026ndash;storage-public-link-mount-path | $STORAGE_PUBLIC_LINK_MOUNT_PATH mount path. Default: /public. storage auth-basic Start authprovider for basic auth\nUsage: storage auth-basic [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_AUTH_BASIC_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9147. \u0026ndash;auth-driver | $STORAGE_AUTH_DRIVER auth driver: \u0026lsquo;demo\u0026rsquo;, \u0026lsquo;json\u0026rsquo; or \u0026lsquo;ldap\u0026rsquo;. Default: ldap. \u0026ndash;auth-json | $STORAGE_AUTH_JSON Path to users.json file. \u0026ndash;network | $STORAGE_AUTH_BASIC_GRPC_NETWORK Network to use for the storage auth-basic service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;addr | $STORAGE_AUTH_BASIC_GRPC_ADDR Address to bind storage service. Default: 0.0.0.0:9146. storage users Start users service\nUsage: storage users [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_SHARING_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9145. \u0026ndash;network | $STORAGE_USERPROVIDER_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;addr | $STORAGE_USERPROVIDER_ADDR Address to bind storage service. Default: 0.0.0.0:9144. \u0026ndash;endpoint | $STORAGE_USERPROVIDER_ENDPOINT URL to use for the storage service. Default: localhost:9144. \u0026ndash;driver | $STORAGE_USERPROVIDER_DRIVER user driver: \u0026lsquo;demo\u0026rsquo;, \u0026lsquo;json\u0026rsquo;, \u0026lsquo;ldap\u0026rsquo;, or \u0026lsquo;rest\u0026rsquo;. Default: ldap. \u0026ndash;json-config | $STORAGE_USERPROVIDER_JSON Path to users.json file. \u0026ndash;rest-client-id | $STORAGE_REST_CLIENT_ID User rest driver Client ID. \u0026ndash;rest-client-secret | $STORAGE_REST_CLIENT_SECRET User rest driver Client Secret. \u0026ndash;rest-redis-address | $STORAGE_REST_REDIS_ADDRESS Address for redis server. Default: localhost:6379. \u0026ndash;rest-redis-username | $STORAGE_REST_REDIS_USERNAME Username for redis server. \u0026ndash;rest-redis-password | $STORAGE_REST_REDIS_PASSWORD Password for redis server. \u0026ndash;rest-id-provider | $STORAGE_REST_ID_PROVIDER The OIDC Provider. \u0026ndash;rest-api-base-url | $STORAGE_REST_API_BASE_URL Base API Endpoint. \u0026ndash;rest-oidc-token-endpoint | $STORAGE_REST_OIDC_TOKEN_ENDPOINT Endpoint to generate token to access the API. \u0026ndash;rest-target-api | $STORAGE_REST_TARGET_API The target application. storage frontend Start frontend service\nUsage: storage frontend [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_FRONTEND_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9141. \u0026ndash;transfer-secret | $STORAGE_TRANSFER_SECRET Transfer secret for datagateway. Default: replace-me-with-a-transfer-secret. \u0026ndash;chunk-folder | $STORAGE_CHUNK_FOLDER temp directory for chunked uploads. Default: /var/tmp/ocis/tmp/chunks. \u0026ndash;webdav-namespace | $STORAGE_WEBDAV_NAMESPACE Namespace prefix for the /webdav endpoint. Default: /home/. \u0026ndash;dav-files-namespace | $STORAGE_DAV_FILES_NAMESPACE Namespace prefix for the webdav /dav/files endpoint. Default: /users/. \u0026ndash;network | $STORAGE_FRONTEND_HTTP_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;addr | $STORAGE_FRONTEND_HTTP_ADDR Address to bind storage service. Default: 0.0.0.0:9140. \u0026ndash;public-url | $STORAGE_FRONTEND_PUBLIC_URL URL to use for the storage service. Default: https://localhost:9200. \u0026ndash;datagateway-prefix | $STORAGE_FRONTEND_DATAGATEWAY_PREFIX datagateway prefix. Default: data. \u0026ndash;ocdav-prefix | $STORAGE_FRONTEND_OCDAV_PREFIX owncloud webdav endpoint prefix. \u0026ndash;ocs-prefix | $STORAGE_FRONTEND_OCS_PREFIX open collaboration services endpoint prefix. Default: ocs. \u0026ndash;ocs-share-prefix | $STORAGE_FRONTEND_OCS_Share_PREFIX the prefix prepended to the path of shared files. Default: /Shares. \u0026ndash;gateway-url | $STORAGE_GATEWAY_ENDPOINT URL to use for the storage gateway service. Default: localhost:9142. \u0026ndash;upload-disable-tus | $STORAGE_FRONTEND_UPLOAD_DISABLE_TUS Disables TUS upload mechanism. Default: false. \u0026ndash;upload-http-method-override | $STORAGE_FRONTEND_UPLOAD_HTTP_METHOD_OVERRIDE Specify an HTTP method (ex: POST) that clients should to use when uploading instead of PATCH. storage sharing Start sharing service\nUsage: storage sharing [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_SHARING_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9151. \u0026ndash;network | $STORAGE_SHARING_GRPC_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;addr | $STORAGE_SHARING_GRPC_ADDR Address to bind storage service. Default: 0.0.0.0:9150. \u0026ndash;user-driver | $STORAGE_SHARING_USER_DRIVER driver to use for the UserShareProvider. Default: json. \u0026ndash;user-json-file | $STORAGE_SHARING_USER_JSON_FILE file used to persist shares for the UserShareProvider. Default: /var/tmp/ocis/storage/shares.json. \u0026ndash;public-driver | $STORAGE_SHARING_PUBLIC_DRIVER driver to use for the PublicShareProvider. Default: json. \u0026ndash;public-json-file | $STORAGE_SHARING_PUBLIC_JSON_FILE file used to persist shares for the PublicShareProvider. Default: /var/tmp/ocis/storage/publicshares.json. storage storage Storage service for oCIS\nUsage: storage storage [command options] [arguments...]\n \u0026ndash;config-file | $STORAGE_CONFIG_FILE Path to config file. \u0026ndash;log-level | $STORAGE_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $STORAGE_LOG_PRETTY Enable pretty logging. \u0026ndash;log-color | $STORAGE_LOG_COLOR Enable colored logging. storage health Check health status\nUsage: storage health [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9109. storage auth-bearer Start authprovider for bearer auth\nUsage: storage auth-bearer [command options] [arguments...]\n \u0026ndash;debug-addr | $STORAGE_AUTH_BEARER_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9149. \u0026ndash;oidc-issuer | $STORAGE_OIDC_ISSUER OIDC issuer. Default: https://localhost:9200. \u0026ndash;oidc-insecure | $STORAGE_OIDC_INSECURE OIDC allow insecure communication. Default: true. \u0026ndash;oidc-id-claim | $STORAGE_OIDC_ID_CLAIM OIDC id claim. Default: preferred_username. \u0026ndash;oidc-uid-claim | $STORAGE_OIDC_UID_CLAIM OIDC uid claim. \u0026ndash;oidc-gid-claim | $STORAGE_OIDC_GID_CLAIM OIDC gid claim. \u0026ndash;network | $STORAGE_AUTH_BEARER_GRPC_NETWORK Network to use for the storage service, can be \u0026lsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. Default: tcp. \u0026ndash;addr | $STORAGE_AUTH_BEARER_GRPC_ADDR Address to bind storage service. Default: 0.0.0.0:9148. Config for the different Storage Drivers You can set different storage drivers for the Storage Providers. Please check the storage provider configuration.\nExample: Set the home and users Storage Provider to ocis\nSTORAGE_HOME_DRIVER=ocis STORAGE_USERS_DRIVER=ocis\nLocal Driver \u0026ndash;storage-local-root | $STORAGE_DRIVER_LOCAL_ROOT the path to the local storage root. Default: /var/tmp/ocis/storage/local. Eos Driver \u0026ndash;storage-eos-namespace | $STORAGE_DRIVER_EOS_NAMESPACE Namespace for metadata operations. Default: /eos/dockertest/reva. \u0026ndash;storage-eos-shadow-namespace | $STORAGE_DRIVER_EOS_SHADOW_NAMESPACE Shadow namespace where share references are stored. \u0026ndash;storage-eos-share-folder | $STORAGE_DRIVER_EOS_SHARE_FOLDER name of the share folder. Default: /Shares. \u0026ndash;storage-eos-binary | $STORAGE_DRIVER_EOS_BINARY Location of the eos binary. Default: /usr/bin/eos. \u0026ndash;storage-eos-xrdcopy-binary | $STORAGE_DRIVER_EOS_XRDCOPY_BINARY Location of the xrdcopy binary. Default: /usr/bin/xrdcopy. \u0026ndash;storage-eos-master-url | $STORAGE_DRIVER_EOS_MASTER_URL URL of the Master EOS MGM. Default: root://eos-mgm1.eoscluster.cern.ch:1094. \u0026ndash;storage-eos-slave-url | $STORAGE_DRIVER_EOS_SLAVE_URL URL of the Slave EOS MGM. Default: root://eos-mgm1.eoscluster.cern.ch:1094. \u0026ndash;storage-eos-cache-directory | $STORAGE_DRIVER_EOS_CACHE_DIRECTORY Location on the local fs where to store reads. Default: os.TempDir(). \u0026ndash;storage-eos-enable-logging | $STORAGE_DRIVER_EOS_ENABLE_LOGGING Enables logging of the commands executed. \u0026ndash;storage-eos-show-hidden-sysfiles | $STORAGE_DRIVER_EOS_SHOW_HIDDEN_SYSFILES show internal EOS files like .sys.v# and .sys.a# files.. \u0026ndash;storage-eos-force-singleuser-mode | $STORAGE_DRIVER_EOS_FORCE_SINGLEUSER_MODE force connections to EOS to use SingleUsername. \u0026ndash;storage-eos-use-keytab | $STORAGE_DRIVER_EOS_USE_KEYTAB authenticate requests by using an EOS keytab. \u0026ndash;storage-eos-enable-home | $STORAGE_DRIVER_EOS_ENABLE_HOME enable the creation of home directories. \u0026ndash;storage-eos-sec-protocol | $STORAGE_DRIVER_EOS_SEC_PROTOCOL the xrootd security protocol to use between the server and EOS. \u0026ndash;storage-eos-keytab | $STORAGE_DRIVER_EOS_KEYTAB the location of the keytab to use to authenticate to EOS. \u0026ndash;storage-eos-single-username | $STORAGE_DRIVER_EOS_SINGLE_USERNAME the username to use when SingleUserMode is enabled. \u0026ndash;storage-eos-layout | $STORAGE_DRIVER_EOS_LAYOUT \u0026quot;layout of the users home dir path on disk, in addition to {{.Username}}, {{.UsernameLower}} and {{.Provider}} also supports prefixing dirs: \u0026quot;{{.UsernamePrefixCount.2}}/{{.UsernameLower}}\u0026quot; will turn \u0026quot;Einstein\u0026quot; into \u0026quot;Ei/Einstein\u0026quot; . Default: {{substr 0 1 .Username}}/{{.Username}}. \u0026ndash;storage-eos-gatewaysvc | $STORAGE_DRIVER_EOS_GATEWAYSVC URL to use for the storage gateway service. Default: localhost:9142. owCloud Driver \u0026ndash;storage-owncloud-datadir | $STORAGE_DRIVER_OWNCLOUD_DATADIR the path to the owncloud data directory. Default: /var/tmp/ocis/storage/owncloud. \u0026ndash;storage-owncloud-uploadinfo-dir | $STORAGE_DRIVER_OWNCLOUD_UPLOADINFO_DIR the path to the tus upload info directory. Default: /var/tmp/ocis/storage/uploadinfo. \u0026ndash;storage-owncloud-share-folder | $STORAGE_DRIVER_OWNCLOUD_SHARE_FOLDER name of the shares folder. Default: /Shares. \u0026ndash;storage-owncloud-scan | $STORAGE_DRIVER_OWNCLOUD_SCAN scan files on startup to add fileids. Default: true. \u0026ndash;storage-owncloud-redis | $STORAGE_DRIVER_OWNCLOUD_REDIS_ADDR the address of the redis server. Default: :6379. \u0026ndash;storage-owncloud-enable-home | $STORAGE_DRIVER_OWNCLOUD_ENABLE_HOME enable the creation of home storages. Default: false. \u0026ndash;storage-owncloud-layout | $STORAGE_DRIVER_OWNCLOUD_LAYOUT \u0026quot;layout of the users home dir path on disk, in addition to {{.Username}}, {{.Mail}}, {{.Id.OpaqueId}}, {{.Id.Idp}} also supports prefixing dirs: \u0026quot;{{substr 0 1 .Username}}/{{.Username}}\u0026quot; will turn \u0026quot;Einstein\u0026quot; into \u0026quot;Ei/Einstein\u0026quot; . Default: {{.Id.OpaqueId}}. Ocis Driver \u0026ndash;storage-ocis-root | $STORAGE_DRIVER_OCIS_ROOT the path to the local storage root. Default: /var/tmp/ocis/storage/users. \u0026ndash;storage-ocis-enable-home | $STORAGE_DRIVER_OCIS_ENABLE_HOME enable the creation of home storages. Default: false. \u0026ndash;storage-ocis-layout | $STORAGE_DRIVER_OCIS_LAYOUT \u0026quot;layout of the users home dir path on disk, in addition to {{.Username}}, {{.Mail}}, {{.Id.OpaqueId}}, {{.Id.Idp}} also supports prefixing dirs: \u0026quot;{{substr 0 1 .Username}}/{{.Username}}\u0026quot; will turn \u0026quot;Einstein\u0026quot; into \u0026quot;Ei/Einstein\u0026quot; . Default: {{.Id.OpaqueId}}. "});index.add({'id':20,'href':'/extensions/settings/configuration/','title':"Configuration",'parent':"Settings",'content':" Configuration Configuration using config files Environment variables Commandline flags settings server settings ocis-settings settings version settings health Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-proxy reads proxy.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nsettings server Start integrated server\nUsage: settings server [command options] [arguments...]\n \u0026ndash;config-file | $SETTINGS_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $SETTINGS_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $SETTINGS_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $SETTINGS_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $SETTINGS_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $SETTINGS_TRACING_SERVICE Service name for tracing. Default: settings. \u0026ndash;debug-addr | $SETTINGS_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9194. \u0026ndash;debug-token | $SETTINGS_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $SETTINGS_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $SETTINGS_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $SETTINGS_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9190. \u0026ndash;http-namespace | $SETTINGS_HTTP_NAMESPACE Set the base namespace for the http namespace. Default: com.owncloud.web. \u0026ndash;http-root | $SETTINGS_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;grpc-addr | $SETTINGS_GRPC_ADDR Address to bind grpc server. Default: 0.0.0.0:9191. \u0026ndash;asset-path | $SETTINGS_ASSET_PATH Path to custom assets. \u0026ndash;grpc-namespace | $SETTINGS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $SETTINGS_NAME service name. Default: settings. \u0026ndash;data-path | $SETTINGS_DATA_PATH Mount path for the storage. Default: /var/tmp/ocis/settings. \u0026ndash;jwt-secret | $SETTINGS_JWT_SECRET Used to create JWT to talk to reva, should equal reva\u0026rsquo;s jwt-secret. Default: Pive-Fumkiu4. settings ocis-settings Provide settings and permissions for oCIS\nUsage: settings ocis-settings [command options] [arguments...]\n \u0026ndash;log-level | $SETTINGS_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $SETTINGS_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $SETTINGS_LOG_COLOR Enable colored logging. Default: true. settings version Print the versions of the running instances\nUsage: settings version [command options] [arguments...]\n \u0026ndash;grpc-namespace | $SETTINGS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $SETTINGS_NAME service name. Default: settings. settings health Check health status\nUsage: settings health [command options] [arguments...]\n \u0026ndash;debug-addr | $SETTINGS_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9194. "});index.add({'id':21,'href':'/extensions/proxy/configuration/','title':"Configuration",'parent':"Proxy",'content':" Configuration Configuration using config files Environment variables Commandline flags proxy health proxy server proxy ocis-proxy proxy version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-proxy reads proxy.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nproxy health Check health status\nUsage: proxy health [command options] [arguments...]\n \u0026ndash;debug-addr | $PROXY_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9109. proxy server Start integrated server\nUsage: proxy server [command options] [arguments...]\n \u0026ndash;config-file | $PROXY_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $PROXY_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $PROXY_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $PROXY_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $PROXY_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $PROXY_TRACING_SERVICE Service name for tracing. Default: proxy. \u0026ndash;debug-addr | $PROXY_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9205. \u0026ndash;debug-token | $PROXY_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $PROXY_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $PROXY_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $PROXY_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9200. \u0026ndash;http-root | $PROXY_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;asset-path | $PROXY_ASSET_PATH Path to custom assets. \u0026ndash;service-namespace | $PROXY_SERVICE_NAMESPACE Set the base namespace for the service namespace. Default: com.owncloud.web. \u0026ndash;service-name | $PROXY_SERVICE_NAME Service name. Default: proxy. \u0026ndash;transport-tls-cert | $PROXY_TRANSPORT_TLS_CERT Certificate file for transport encryption. \u0026ndash;transport-tls-key | $PROXY_TRANSPORT_TLS_KEY Secret file for transport encryption. \u0026ndash;tls | $PROXY_TLS Use TLS (disable only if proxy is behind a TLS-terminating reverse-proxy).. Default: true. \u0026ndash;jwt-secret | $PROXY_JWT_SECRET Used to create JWT to talk to reva, should equal reva\u0026rsquo;s jwt-secret. Default: Pive-Fumkiu4. \u0026ndash;reva-gateway-addr | $PROXY_REVA_GATEWAY_ADDR REVA Gateway Endpoint. Default: 127.0.0.1:9142. \u0026ndash;insecure | $PROXY_INSECURE_BACKENDS allow insecure communication to upstream servers. Default: false. \u0026ndash;oidc-issuer | $PROXY_OIDC_ISSUER OIDC issuer. Default: https://localhost:9200. \u0026ndash;oidc-insecure | $PROXY_OIDC_INSECURE OIDC allow insecure communication. Default: true. \u0026ndash;autoprovision-accounts | $PROXY_AUTOPROVISION_ACCOUNTS create accounts from OIDC access tokens to learn new users. Default: false. \u0026ndash;enable-presignedurls | $PROXY_ENABLE_PRESIGNEDURLS Enable or disable handling the presigned urls in the proxy. Default: true. \u0026ndash;enable-basic-auth | $PROXY_ENABLE_BASIC_AUTH enable basic authentication. Default: false. \u0026ndash;account-backend-type | $PROXY_ACCOUNT_BACKEND_TYPE account-backend-type. Default: accounts. proxy ocis-proxy proxy for Reva/oCIS\nUsage: proxy ocis-proxy [command options] [arguments...]\n \u0026ndash;log-level | $PROXY_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $PROXY_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $PROXY_LOG_COLOR Enable colored logging. Default: true. proxy version Print the versions of the running instances\nUsage: proxy version [command options] [arguments...]\n \u0026ndash;service-namespace | $PROXY_SERVICE_NAMESPACE Set the base namespace for the service namespace. Default: com.owncloud.web. \u0026ndash;service-name | $PROXY_SERVICE_NAME Service name. Default: proxy. "});index.add({'id':22,'href':'/extensions/proxy/','title':"Proxy",'parent':"Extensions",'content':"This service provides a proxy service that routes requests to the correct extensions.\n"});index.add({'id':23,'href':'/extensions/ocs/configuration/','title':"Configuration",'parent':"Ocs",'content':" Configuration Configuration using config files Environment variables Commandline flags ocs health ocs server ocs ocis-ocs ocs version Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-ocs reads ocs.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nocs health Check health status\nUsage: ocs health [command options] [arguments...]\n \u0026ndash;debug-addr | $OCS_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9114. ocs server Start integrated server\nUsage: ocs server [command options] [arguments...]\n \u0026ndash;config-file | $OCS_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $OCS_TRACING_ENABLED Enable sending traces. Default: false. \u0026ndash;tracing-type | $OCS_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $OCS_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $OCS_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $OCS_TRACING_SERVICE Service name for tracing. Default: ocs. \u0026ndash;debug-addr | $OCS_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9114. \u0026ndash;debug-token | $OCS_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $OCS_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $OCS_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $OCS_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9110. \u0026ndash;http-namespace | $OCS_NAMESPACE Set the base namespace for the http namespace. Default: com.owncloud.web. \u0026ndash;name | $OCS_NAME Service name. Default: ocs. \u0026ndash;http-root | $OCS_HTTP_ROOT Root path of http server. Default: /ocs. \u0026ndash;jwt-secret | $OCS_JWT_SECRET Used to dismantle the access token, should equal reva\u0026rsquo;s jwt-secret. Default: Pive-Fumkiu4. ocs ocis-ocs Serve OCS API for oCIS\nUsage: ocs ocis-ocs [command options] [arguments...]\n \u0026ndash;log-level | $OCS_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $OCS_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $OCS_LOG_COLOR Enable colored logging. Default: true. ocs version Print the versions of the running instances\nUsage: ocs version [command options] [arguments...]\n \u0026ndash;http-namespace | $OCS_NAMESPACE Set the base namespace for the http namespace. Default: com.owncloud.web. \u0026ndash;name | $OCS_NAME Service name. Default: ocs. "});index.add({'id':24,'href':'/extensions/web/configuration/','title':"Configuration",'parent':"ownCloud Web",'content':" Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands web health web server Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-web reads web.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nRoot Command Serve ownCloud Web for oCIS\nUsage: web [global options] command [command options] [arguments...]\n \u0026ndash;log-level | $WEB_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $WEB_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $WEB_LOG_COLOR Enable colored logging. Default: true. Sub Commands web health Check health status\nUsage: web health [command options] [arguments...]\n \u0026ndash;debug-addr | $WEB_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9104. web server Start integrated server\nUsage: web server [command options] [arguments...]\n \u0026ndash;config-file | $WEB_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $WEB_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $WEB_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $WEB_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $WEB_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $WEB_TRACING_SERVICE Service name for tracing. Default: web. \u0026ndash;debug-addr | $WEB_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9104. \u0026ndash;debug-token | $WEB_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $WEB_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $WEB_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $WEB_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9100. \u0026ndash;http-root | $WEB_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;http-namespace | $WEB_NAMESPACE Set the base namespace for the http namespace. Default: com.owncloud.web. \u0026ndash;asset-path | $WEB_ASSET_PATH Path to custom assets. \u0026ndash;web-config | $WEB_UI_CONFIG Path to web config. \u0026ndash;web-config-server | $WEB_UI_CONFIG_SERVER Server URL. Default: https://localhost:9200. \u0026ndash;web-config-theme | $WEB_UI_CONFIG_THEME Theme. Default: owncloud. \u0026ndash;web-config-version | $WEB_UI_CONFIG_VERSION Version. Default: 0.1.0. \u0026ndash;oidc-metadata-url | $WEB_OIDC_METADATA_URL OpenID Connect metadata URL. Default: https://localhost:9200/.well-known/openid-configuration. \u0026ndash;oidc-authority | $WEB_OIDC_AUTHORITY OpenID Connect authority. Default: https://localhost:9200. \u0026ndash;oidc-client-id | $WEB_OIDC_CLIENT_ID OpenID Connect client ID. Default: web. \u0026ndash;oidc-response-type | $WEB_OIDC_RESPONSE_TYPE OpenID Connect response type. Default: code. \u0026ndash;oidc-scope | $WEB_OIDC_SCOPE OpenID Connect scope. Default: openid profile email. "});index.add({'id':25,'href':'/extensions/konnectd/configuration/','title':"Configuration",'parent':"Konnectd",'content':" Configuration Configuration using config files Environment variables Commandline flags konnectd server konnectd ocis-konnectd konnectd version konnectd health Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-konnectd reads konnectd.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nkonnectd server Start integrated server\nUsage: konnectd server [command options] [arguments...]\n \u0026ndash;config-file | $KONNECTD_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $KONNECTD_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $KONNECTD_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $KONNECTD_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $KONNECTD_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $KONNECTD_TRACING_SERVICE Service name for tracing. Default: konnectd. \u0026ndash;debug-addr | $KONNECTD_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9134. \u0026ndash;debug-token | $KONNECTD_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $KONNECTD_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $KONNECTD_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $KONNECTD_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9130. \u0026ndash;http-root | $KONNECTD_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;http-namespace | $KONNECTD_HTTP_NAMESPACE Set the base namespace for service discovery. Default: com.owncloud.web. \u0026ndash;name | $KONNECTD_NAME Service name. Default: konnectd. \u0026ndash;identity-manager | $KONNECTD_IDENTITY_MANAGER Identity manager (one of ldap,kc,cookie,dummy). Default: ldap. \u0026ndash;transport-tls-cert | $KONNECTD_TRANSPORT_TLS_CERT Certificate file for transport encryption. \u0026ndash;transport-tls-key | $KONNECTD_TRANSPORT_TLS_KEY Secret file for transport encryption. \u0026ndash;iss | $KONNECTD_ISS OIDC issuer URL. Default: https://localhost:9200. \u0026ndash;signing-kid | $KONNECTD_SIGNING_KID Value of kid field to use in created tokens (uniquely identifying the signing-private-key). \u0026ndash;validation-keys-path | $KONNECTD_VALIDATION_KEYS_PATH Full path to a folder containg PEM encoded private or public key files used for token validaton (file name without extension is used as kid). \u0026ndash;encryption-secret | $KONNECTD_ENCRYPTION_SECRET Full path to a file containing a %d bytes secret key. \u0026ndash;signing-method | $KONNECTD_SIGNING_METHOD JWT default signing method. Default: PS256. \u0026ndash;uri-base-path | $KONNECTD_URI_BASE_PATH Custom base path for URI endpoints. \u0026ndash;sign-in-uri | $KONNECTD_SIGN_IN_URI Custom redirection URI to sign-in form. \u0026ndash;signed-out-uri | $KONNECTD_SIGN_OUT_URI Custom redirection URI to signed-out goodbye page. \u0026ndash;authorization-endpoint-uri | $KONNECTD_ENDPOINT_URI Custom authorization endpoint URI. \u0026ndash;endsession-endpoint-uri | $KONNECTD_ENDSESSION_ENDPOINT_URI Custom endsession endpoint URI. \u0026ndash;asset-path | $KONNECTD_ASSET_PATH Path to custom assets. \u0026ndash;identifier-client-path | $KONNECTD_IDENTIFIER_CLIENT_PATH Path to the identifier web client base folder. Default: /var/tmp/ocis/konnectd. \u0026ndash;identifier-registration-conf | $KONNECTD_IDENTIFIER_REGISTRATION_CONF Path to a identifier-registration.yaml configuration file. Default: ./config/identifier-registration.yaml. \u0026ndash;identifier-scopes-conf | $KONNECTD_IDENTIFIER_SCOPES_CONF Path to a scopes.yaml configuration file. \u0026ndash;insecure | $KONNECTD_INSECURE Disable TLS certificate and hostname validation. \u0026ndash;tls | $KONNECTD_TLS Use TLS (disable only if konnectd is behind a TLS-terminating reverse-proxy).. Default: false. \u0026ndash;allow-client-guests | $KONNECTD_ALLOW_CLIENT_GUESTS Allow sign in of client controlled guest users. \u0026ndash;allow-dynamic-client-registration | $KONNECTD_ALLOW_DYNAMIC_CLIENT_REGISTRATION Allow dynamic OAuth2 client registration. Default: true. \u0026ndash;disable-identifier-webapp | $KONNECTD_DISABLE_IDENTIFIER_WEBAPP Disable built-in identifier-webapp to use a frontend hosted elsewhere.. Default: true. konnectd ocis-konnectd Serve Konnectd API for oCIS\nUsage: konnectd ocis-konnectd [command options] [arguments...]\n \u0026ndash;log-level | $KONNECTD_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $KONNECTD_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $KONNECTD_LOG_COLOR Enable colored logging. Default: true. konnectd version Print the versions of the running instances\nUsage: konnectd version [command options] [arguments...]\n \u0026ndash;http-namespace | $KONNECTD_HTTP_NAMESPACE Set the base namespace for service discovery. Default: com.owncloud.web. \u0026ndash;name | $KONNECTD_NAME Service name. Default: konnectd. konnectd health Check health status\nUsage: konnectd health [command options] [arguments...]\n \u0026ndash;debug-addr | $KONNECTD_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9134. "});index.add({'id':26,'href':'/extensions/konnectd/','title':"Konnectd",'parent':"Extensions",'content':"This service provides an OpenID Connect provider which is the default way to authenticate in oCIS.\n"});index.add({'id':27,'href':'/extensions/glauth/configuration/','title':"Configuration",'parent':"GLAuth",'content':" Configuration Configuration using config files Environment variables Commandline flags glauth health glauth server glauth ocis-glauth Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-glauth reads glauth.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\nglauth health Check health status\nUsage: glauth health [command options] [arguments...]\n \u0026ndash;debug-addr | $GLAUTH_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9129. glauth server Start integrated server\nUsage: glauth server [command options] [arguments...]\n \u0026ndash;config-file | $GLAUTH_CONFIG_FILE Path to config file. \u0026ndash;tracing-enabled | $GLAUTH_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $GLAUTH_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $GLAUTH_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $GLAUTH_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $GLAUTH_TRACING_SERVICE Service name for tracing. Default: glauth. \u0026ndash;debug-addr | $GLAUTH_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9129. \u0026ndash;debug-token | $GLAUTH_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $GLAUTH_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $GLAUTH_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;role-bundle-id | $GLAUTH_ROLE_BUNDLE_ID roleid used to make internal grpc requests. Default: 71881883-1768-46bd-a24d-a356a2afdf7f. \u0026ndash;ldap-addr | $GLAUTH_LDAP_ADDR Address to bind ldap server. Default: 0.0.0.0:9125. \u0026ndash;ldap-enabled | $GLAUTH_LDAP_ENABLED Enable ldap server. Default: true. \u0026ndash;ldaps-addr | $GLAUTH_LDAPS_ADDR Address to bind ldap server. Default: 0.0.0.0:9126. \u0026ndash;ldaps-enabled | $GLAUTH_LDAPS_ENABLED Enable ldap server. Default: true. \u0026ndash;ldaps-cert | $GLAUTH_LDAPS_CERT path to ldaps certificate in PEM format. Default: ./ldap.crt. \u0026ndash;ldaps-key | $GLAUTH_LDAPS_KEY path to ldaps key in PEM format. Default: ./ldap.key. \u0026ndash;backend-basedn | $GLAUTH_BACKEND_BASEDN base distinguished name to expose. Default: dc=example,dc=org. \u0026ndash;backend-name-format | $GLAUTH_BACKEND_NAME_FORMAT name attribute for entries to expose. typically cn or uid. Default: cn. \u0026ndash;backend-group-format | $GLAUTH_BACKEND_GROUP_FORMAT name attribute for entries to expose. typically ou, cn or dc. Default: ou. \u0026ndash;backend-ssh-key-attr | $GLAUTH_BACKEND_SSH_KEY_ATTR ssh key attribute for entries to expose. Default: sshPublicKey. \u0026ndash;backend-datastore | $GLAUTH_BACKEND_DATASTORE datastore to use as the backend. one of accounts, ldap or owncloud. Default: accounts. \u0026ndash;backend-insecure | $GLAUTH_BACKEND_INSECURE Allow insecure requests to the datastore. Default: false. \u0026ndash;backend-use-graphapi | $GLAUTH_BACKEND_USE_GRAPHAPI use Graph API, only for owncloud datastore. Default: true. \u0026ndash;fallback-basedn | $GLAUTH_FALLBACK_BASEDN base distinguished name to expose. Default: dc=example,dc=org. \u0026ndash;fallback-name-format | $GLAUTH_FALLBACK_NAME_FORMAT name attribute for entries to expose. typically cn or uid. Default: cn. \u0026ndash;fallback-group-format | $GLAUTH_FALLBACK_GROUP_FORMAT name attribute for entries to expose. typically ou, cn or dc. Default: ou. \u0026ndash;fallback-ssh-key-attr | $GLAUTH_FALLBACK_SSH_KEY_ATTR ssh key attribute for entries to expose. Default: sshPublicKey. \u0026ndash;fallback-datastore | $GLAUTH_FALLBACK_DATASTORE datastore to use as the fallback. one of accounts, ldap or owncloud. \u0026ndash;fallback-insecure | $GLAUTH_FALLBACK_INSECURE Allow insecure requests to the datastore. Default: false. \u0026ndash;fallback-use-graphapi | $GLAUTH_FALLBACK_USE_GRAPHAPI use Graph API, only for owncloud datastore. Default: true. glauth ocis-glauth Serve GLAuth API for oCIS\nUsage: glauth ocis-glauth [command options] [arguments...]\n \u0026ndash;log-level | $GLAUTH_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $GLAUTH_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $GLAUTH_LOG_COLOR Enable colored logging. Default: true. "});index.add({'id':28,'href':'/extensions/accounts/configuration/','title':"Configuration",'parent':"Accounts",'content':" Configuration Configuration using config files Environment variables Commandline flags accounts version accounts update accounts remove accounts server accounts add accounts list accounts rebuildIndex accounts ocis-accounts accounts inspect Configuration Configuration using config files Out of the box extensions will attempt to read configuration details from:\n/etc/ocis $HOME/.ocis ./config For this configuration to be picked up, have a look at your extension root command and look for which default config name it has assigned. i.e: ocis-accounts reads accounts.json | yaml | toml ....\nSo far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/ocis.yml, ${HOME}/.ocis/ocis.yml or $(pwd)/config/ocis.yml.\nEnvironment variables If you prefer to configure the service with environment variables you can see the available variables below.\nCommandline flags If you prefer to configure the service with commandline flags you can see the available variables below. Command line flags are only working when calling the subcommand directly.\naccounts version Print the versions of the running instances\nUsage: accounts version [command options] [arguments...]\n \u0026ndash;grpc-namespace | $ACCOUNTS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $ACCOUNTS_NAME service name. Default: accounts. accounts update Make changes to an existing account\nUsage: accounts update [command options] [arguments...]\naccounts remove Removes an existing account\nUsage: accounts remove [command options] [arguments...]\n \u0026ndash;grpc-namespace | $ACCOUNTS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $ACCOUNTS_NAME service name. Default: accounts. accounts server Start ocis accounts service\nUsage: accounts server [command options] [arguments...]\n \u0026ndash;tracing-enabled | $ACCOUNTS_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $ACCOUNTS_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $ACCOUNTS_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $ACCOUNTS_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $ACCOUNTS_TRACING_SERVICE Service name for tracing. Default: accounts. \u0026ndash;http-namespace | $ACCOUNTS_HTTP_NAMESPACE Set the base namespace for the http namespace. Default: com.owncloud.web. \u0026ndash;http-addr | $ACCOUNTS_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9181. \u0026ndash;http-root | $ACCOUNTS_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;grpc-namespace | $ACCOUNTS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;grpc-addr | $ACCOUNTS_GRPC_ADDR Address to bind grpc server. Default: 0.0.0.0:9180. \u0026ndash;name | $ACCOUNTS_NAME service name. Default: accounts. \u0026ndash;asset-path | $ACCOUNTS_ASSET_PATH Path to custom assets. \u0026ndash;jwt-secret | $ACCOUNTS_JWT_SECRET Used to create JWT to talk to reva, should equal reva\u0026rsquo;s jwt-secret. Default: Pive-Fumkiu4. \u0026ndash;storage-disk-path | $ACCOUNTS_STORAGE_DISK_PATH Path on the local disk, e.g. /var/tmp/ocis/accounts. \u0026ndash;storage-cs3-provider-addr | $ACCOUNTS_STORAGE_CS3_PROVIDER_ADDR bind address for the metadata storage provider. Default: localhost:9215. \u0026ndash;storage-cs3-data-url | $ACCOUNTS_STORAGE_CS3_DATA_URL http endpoint of the metadata storage. Default: http://localhost:9216. \u0026ndash;storage-cs3-data-prefix | $ACCOUNTS_STORAGE_CS3_DATA_PREFIX path prefix for the http endpoint of the metadata storage, without leading slash. Default: data. \u0026ndash;storage-cs3-jwt-secret | $ACCOUNTS_STORAGE_CS3_JWT_SECRET Used to create JWT to talk to reva, should equal reva\u0026rsquo;s jwt-secret. Default: Pive-Fumkiu4. \u0026ndash;service-user-uuid | $ACCOUNTS_SERVICE_USER_UUID uuid of the internal service user (required on EOS). Default: 95cb8724-03b2-11eb-a0a6-c33ef8ef53ad. \u0026ndash;service-user-username | $ACCOUNTS_SERVICE_USER_USERNAME username of the internal service user (required on EOS). accounts add Create a new account\nUsage: accounts add [command options] [arguments...]\naccounts list List existing accounts\nUsage: accounts list [command options] [arguments...]\n \u0026ndash;grpc-namespace | $ACCOUNTS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $ACCOUNTS_NAME service name. Default: accounts. accounts rebuildIndex Rebuilds the service\u0026rsquo;s index, i.e. deleting and then re-adding all existing documents\nUsage: accounts rebuildIndex [command options] [arguments...]\naccounts ocis-accounts Provide accounts and groups for oCIS\nUsage: accounts ocis-accounts [command options] [arguments...]\n \u0026ndash;log-level | $ACCOUNTS_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $ACCOUNTS_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $ACCOUNTS_LOG_COLOR Enable colored logging. Default: true. accounts inspect Show detailed data on an existing account\nUsage: accounts inspect [command options] [arguments...]\n \u0026ndash;grpc-namespace | $ACCOUNTS_GRPC_NAMESPACE Set the base namespace for the grpc namespace. Default: com.owncloud.api. \u0026ndash;name | $ACCOUNTS_NAME service name. Default: accounts. "});index.add({'id':29,'href':'/ocis/deployment/','title':"Deployment",'parent':"oCIS - ownCloud Infinite Scale",'content':" Deployments scenarios and examples Setup oCIS on your server Migrate an existing ownCloud 10 Deployments scenarios and examples This section handles deployments and operations for admins and people who are interested in how versatile oCIS is. If you want to just try oCIS you may also follow Getting started.\nSetup oCIS on your server oCIS deployments are super simple, yet there are many configurations possible for advanced setups.\n Basic oCIS setup - configure domain, certificates and port oCIS setup with Traefik for SSL termination oCIS setup with Keycloak as identity provider Migrate an existing ownCloud 10 You can run ownCloud 10 and oCIS together. This allows you to use new parts of oCIS already with ownCloud 10 and also to have a smooth transition for users from ownCloud 10 to oCIS.\n ownCloud 10 setup with oCIS serving ownCloud Web and acting as OIDC provider - This allows you to switch between the traditional ownCloud 10 frontend and the new ownCloud Web frontend Run ownCloud 10 and oCIS in parallel - together Migrate users from ownCloud 10 to oCIS "});index.add({'id':30,'href':'/extensions/accounts/','title':"Accounts",'parent':"Extensions",'content':"Abstract oCIS needs to be able to identify users. Without a non reassignable and persistent account ID share metadata cannot be reliably persisted. accounts allows exchanging oidc claims for a uuid. Using a uuid allows users to change the login, mail or even openid connect provider without breaking any persisted metadata that might have been attached to it.\n persists accounts uses graph api properties ldap can be synced using the onpremise* attributes Table of Contents Configuration "});index.add({'id':31,'href':'/extensions/ocis_hello/building/','title':"Building",'parent':"Hello",'content':" Frontend Backend As this project is built with Go and NodeJS, so you need to install that first. The installation of Go and NodeJS is out of the scope of this document, please follow the official documentation for Go, NodeJS and Yarn, to build this project you have to install Go \u0026gt;= v1.13. After the installation of the required tools you need to get the sources:\ngit clone https://github.com/owncloud/ocis-hello.git cd ocis-hello All required tool besides Go itself and make are bundled or getting automatically installed within the GOPATH. All commands to build this project are part of our Makefile and respectively our package.json.\nFrontend yarn install yarn build The above commands will install the required build dependencies and build the whole frontend bundle. This bundle will we embeded into the binary later on.\nBackend make generate make build The above commands will embed the frontend bundle into the binary. Finally you should have the binary within the bin/ folder now, give it a try with ./bin/ocis-hello -h to see all available options.\n"});index.add({'id':32,'href':'/clients/web/building/','title':"Building from source",'parent':"ownCloud Web",'content':" Building ownCloud Web Updating dependencies Cleaning up the workspace Building the documentation Setting up Viewing the documentation Deploying the documentation Building ownCloud Web Run yarn install to install core dependencies Run yarn install-all to install dependencies of all apps and core Run yarn dist to build Web and all apps included in the apps folder Updating dependencies Run yarn upgrade-all to update core and app dependencies Cleaning up the workspace Run yarn clean-all to remove node_modules and dist folder Building the documentation Setting up Install hugo Run make docs Viewing the documentation To view the rendered docs in the browser run:\ncd hugo hugo -D server Then open \u0026ldquo;http://localhost:1313/\u0026rdquo;\nWhen making changes to the docs, run make docs again and the server will pick up the changes and reload the page automatically\nDeploying the documentation The documentation is automatically deployed from the master branch to https://owncloud.github.io/web/\n"});index.add({'id':33,'href':'/extensions/glauth/configuration-hints/','title':"Configuration Hints",'parent':"GLAuth",'content':" Configuration hints Configuration hints The default setup does not use a fallback backend. It can be enabled by setting the GLAUTH_FALLBACK_DATASTORE environment variable.\nWhen using owncloud make sure to use the full URL to the ownCloud 10 graph api app endpoint, eg.: GLAUTH_FALLBACK_SERVERS=\u0026quot;https://demo.owncloud.com/apps/graphapi/v1.0\u0026quot;\n"});index.add({'id':34,'href':'/extensions/onlyoffice/getting-started/','title':"Getting Started",'parent':"OnlyOffice",'content':" Installation Docker Binaries Configuration ownCloud Web configuration Envrionment variables Global Server Health Commandline flags Global Server Health Configuration file Usage Server Health Metrics Installation So far we are offering two different variants for the installation. You can choose between Docker or pre-built binaries which are stored on our download mirrors and GitHub releases. Maybe we will also provide system packages for the major distributions later if we see the need for it.\nDocker TBD\nBinaries TBD\nConfiguration We provide overall three different variants of configuration. The variant based on environment variables and commandline flags are split up into global values and command-specific values.\nownCloud Web configuration When loading the extension in the ownCloud Web, it is necessary to specify to which ownCloud 10 server the extension is supposed to connect to. This can be done via config object when registering the extension in config.json. For more details, you can take a look at the following example:\n\u0026#34;external_apps\u0026#34;: [ { \u0026#34;id\u0026#34;: \u0026#34;onlyoffice\u0026#34;, \u0026#34;path\u0026#34;: \u0026#34;https://localhost:9200/onlyoffice.js\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;server\u0026#34;: \u0026#34;https://oc10.example.org\u0026#34; } } ] Envrionment variables If you prefer to configure the service with environment variables you can see the available variables below.\nGlobal ONLYOFFICE_CONFIG_FILE Path to config file, empty default value ONLYOFFICE_LOG_LEVEL Set logging level, defaults to info ONLYOFFICE_LOG_COLOR Enable colored logging, defaults to true ONLYOFFICE_LOG_PRETTY Enable pretty logging, defaults to true Server ONLYOFFICE_TRACING_ENABLED Enable sending traces, defaults to false ONLYOFFICE_TRACING_TYPE Tracing backend type, defaults to jaeger ONLYOFFICE_TRACING_ENDPOINT Endpoint for the agent, empty default value ONLYOFFICE_TRACING_COLLECTOR Endpoint for the collector, empty default value ONLYOFFICE_TRACING_SERVICE Service name for tracing, defaults to onlyoffice ONLYOFFICE_DEBUG_ADDR Address to bind debug server, defaults to 0.0.0.0:9224 ONLYOFFICE_DEBUG_TOKEN Token to grant metrics access, empty default value ONLYOFFICE_DEBUG_PPROF Enable pprof debugging, defaults to false ONLYOFFICE_DEBUG_ZPAGES Enable zpages debugging, defaults to false ONLYOFFICE_HTTP_ADDR Address to bind http server, defaults to 0.0.0.0:9220 ONLYOFFICE_HTTP_NAMESPACE The http namespace ONLYOFFICE_HTTP_ROOT Root path of http server, defaults to / Health ONLYOFFICE_DEBUG_ADDR Address to debug endpoint, defaults to 0.0.0.0:9224 Commandline flags If you prefer to configure the service with commandline flags you can see the available variables below.\nGlobal \u0026ndash;config-file | $ONLYOFFICE_CONFIG_FILE Path to config file. \u0026ndash;log-level | $ONLYOFFICE_LOG_LEVEL Set logging level. Default: info. \u0026ndash;log-pretty | $ONLYOFFICE_LOG_PRETTY Enable pretty logging. Default: true. \u0026ndash;log-color | $ONLYOFFICE_LOG_COLOR Enable colored logging. Default: true. Server \u0026ndash;tracing-enabled | $ONLYOFFICE_TRACING_ENABLED Enable sending traces. \u0026ndash;tracing-type | $ONLYOFFICE_TRACING_TYPE Tracing backend type. Default: jaeger. \u0026ndash;tracing-endpoint | $ONLYOFFICE_TRACING_ENDPOINT Endpoint for the agent. \u0026ndash;tracing-collector | $ONLYOFFICE_TRACING_COLLECTOR Endpoint for the collector. \u0026ndash;tracing-service | $ONLYOFFICE_TRACING_SERVICE Service name for tracing. Default: onlyoffice. \u0026ndash;debug-addr | $ONLYOFFICE_DEBUG_ADDR Address to bind debug server. Default: 0.0.0.0:9224. \u0026ndash;debug-token | $ONLYOFFICE_DEBUG_TOKEN Token to grant metrics access. \u0026ndash;debug-pprof | $ONLYOFFICE_DEBUG_PPROF Enable pprof debugging. \u0026ndash;debug-zpages | $ONLYOFFICE_DEBUG_ZPAGES Enable zpages debugging. \u0026ndash;http-addr | $ONLYOFFICE_HTTP_ADDR Address to bind http server. Default: 0.0.0.0:9220. \u0026ndash;http-namespace | $ONLYOFFICE_HTTP_NAMESPACE Set the base namespace for the http namespace. Default: com.owncloud.web. \u0026ndash;http-root | $ONLYOFFICE_HTTP_ROOT Root path of http server. Default: /. \u0026ndash;asset-path | $ONLYOFFICE_ASSET_PATH Path to custom assets. Health \u0026ndash;debug-addr | $ONLYOFFICE_DEBUG_ADDR Address to debug endpoint. Default: 0.0.0.0:9224. Configuration file So far we support the file formats JSON and YAML, if you want to get a full example configuration just take a look at our repository, there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it\u0026rsquo;s placed at /etc/ocis/onlyoffice.yml, ${HOME}/.ocis/onlyoffice.yml or $(pwd)/config/onlyoffice.yml.\nUsage The program provides a few sub-commands on execution. The available configuration methods have already been mentioned above. Generally you can always see a formated help output if you execute the binary via ocis-onlyoffice --help.\nServer The server command is used to start the http and debug server on two addresses within a single process. The http server is serving the general webservice while the debug server is used for health check, readiness check and to server the metrics mentioned below. For further help please execute:\nocis-onlyoffice server --help Health The health command is used to execute a health check, if the exit code equals zero the service should be up and running, if the exist code is greater than zero the service is not in a healthy state. Generally this command is used within our Docker containers, it could also be used within Kubernetes.\nocis-onlyoffice health --help Metrics This service provides some Prometheus metrics through the debug endpoint, you can optionally secure the metrics endpoint by some random token, which got to be configured through one of the flag --debug-token or the environment variable ONLYOFFICE_DEBUG_TOKEN mentioned above. By default the metrics endpoint is bound to http://0.0.0.0:9224/metrics.\n go_gc_duration_seconds A summary of the GC invocation durations go_gc_duration_seconds_sum A summary of the GC invocation durations go_gc_duration_seconds_count A summary of the GC invocation durations go_goroutines Number of goroutines that currently exist go_info Information about the Go environment go_memstats_alloc_bytes Number of bytes allocated and still in use go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table go_memstats_frees_total Total number of frees go_memstats_gc_cpu_fraction The fraction of this program\u0026rsquo;s available CPU time used by the GC since the program started go_memstats_gc_sys_bytes Number of bytes used for garbage collection system metadata go_memstats_heap_alloc_bytes Number of heap bytes allocated and still in use go_memstats_heap_idle_bytes Number of heap bytes waiting to be used go_memstats_heap_inuse_bytes Number of heap bytes that are in use go_memstats_heap_objects Number of allocated objects go_memstats_heap_released_bytes Number of heap bytes released to OS go_memstats_heap_sys_bytes Number of heap bytes obtained from system go_memstats_last_gc_time_seconds Number of seconds since 1970 of last garbage collection go_memstats_lookups_total Total number of pointer lookups go_memstats_mallocs_total Total number of mallocs go_memstats_mcache_inuse_bytes Number of bytes in use by mcache structures go_memstats_mcache_sys_bytes Number of bytes used for mcache structures obtained from system go_memstats_mspan_inuse_bytes Number of bytes in use by mspan structures go_memstats_mspan_sys_bytes Number of bytes used for mspan structures obtained from system go_memstats_next_gc_bytes Number of heap bytes when next garbage collection will take place go_memstats_other_sys_bytes Number of bytes used for other system allocations go_memstats_stack_inuse_bytes Number of bytes in use by the stack allocator go_memstats_stack_sys_bytes Number of bytes obtained from system for stack allocator go_memstats_sys_bytes Number of bytes obtained from system go_threads Number of OS threads created promhttp_metric_handler_requests_in_flight Current number of scrapes being served promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code "});index.add({'id':35,'href':'/extensions/glauth/','title':"GLAuth",'parent':"Extensions",'content':"This service provides a glauth based LDAP proxy for ocis which can be used by clients or other extensions. It allows applications relying on LDAP to access the accounts stored in the ocis accounts service. It can be used to make firewalls or identity providers aware of all users, including guest accounts.\nWe are using it to make eos aware of all accounts so the native ACLs can be used to persist share information in the storage.\n"});index.add({'id':36,'href':'/extensions/ocs/','title':"Ocs",'parent':"Extensions",'content':"This service provides the OCS API which is required by some ownCloud clients.\n"});index.add({'id':37,'href':'/extensions/web/','title':"ownCloud Web",'parent':"Extensions",'content':"This service embeds ownCloud Web to provide a UI for ownCloud Infinite Scale.\n"});index.add({'id':38,'href':'/extensions/settings/','title':"Settings",'parent':"Extensions",'content':"Abstract When using oCIS, the requirement to store settings arises. This extension provides functionality for other extensions to register new settings within oCIS. It is responsible for storing the respective settings values as well.\nFor ease of use, this extension provides an ocis-web extension which allows users to change their settings values. Please refer to the ocis-web extension docs for running ocis-web extensions.\n document.addEventListener(\"DOMContentLoaded\", function(event) { mermaid.initialize({ flowchart: { useMaxWidth: true } }); }); graph TD subgraph ow[ocis-web] ows[ocis-web-settings] owc[ocis-web-core] end ows ---|\"listSettingsBundles(),\nsaveSettingsValue(value)\"| os[ocis-settings] owc ---|\"listSettingsValues()\"| sdk[oC SDK] sdk --- sdks{ocis-settings\navailable?} sdks ---|\"yes\"| os sdks ---|\"no\"| defaults[Use set of\ndefault values] oa[oCIS extensions\ne.g. ocis-accounts] ---|\"saveSettingsBundle(bundle)\"| os The diagram shows how the settings service integrates into oCIS:\nSettings management:\n oCIS extensions can register settings bundles with the ocis-settings service. The settings frontend can be plugged into ocis-web, showing forms for changing settings values as a user. The forms are generated from the registered settings bundles. Settings usage:\n Extensions can query ocis-settings for settings values of a user. The ownCloud SDK, used as a data abstraction layer for ocis-web, will query ocis-settings for settings values of a user, if it\u0026rsquo;s available. The SDK uses sensible defaults when ocis-settings is not part of the setup. For compatibility with ownCloud 10, a migration of ownCloud 10 settings into the storage of ocis-settings will be available.\n"});index.add({'id':39,'href':'/extensions/storage/','title':"Storage",'parent':"Extensions",'content':"This service provides an ocis extension that wraps reva and adds an opinionated configuration to it.\nIt uses the port range 9140-9179 to preconfigure several services.\n port service 9109 health? 9140 frontend 9141 frontend debug 9142 gateway 9143 gateway debug 9144 users 9145 users debug 9146 authbasic 9147 authbasic debug 9148 authbearer 9149 authbearer debug 9150 sharing 9151 sharing debug 9152 storage root 9153 storage root debug 9154 storage home 9155 storage home debug 9156 storage home data 9157 storage home data debug 9158 storage eos 9159 storage eos debug 9160 storage eos data 9161 storage eos data debug 9162 storage oc 9163 storage oc debug 9164 storage oc data 9165 storage oc data debug 9166-9177 reserved for s3, wnd, custom + data providers 9178 storage public link 9179 storage public link data "});index.add({'id':40,'href':'/extensions/store/','title':"Store",'parent':"Extensions",'content':"This service provides \u0026hellip;\n"});index.add({'id':41,'href':'/extensions/thumbnails/','title':"Thumbnails",'parent':"Extensions",'content':"This service provides an ocis extensions which generates thumbnails for image files.\n"});index.add({'id':42,'href':'/extensions/webdav/','title':"WebDaV",'parent':"Extensions",'content':"This service provides the WebDAV API which is required by some ownCloud clients.\n"});index.add({'id':43,'href':'/ocis/deployment/ocis_keycloak/','title':"oCIS with Keycloak",'parent':"Deployment",'content':" Overview Server Deployment Requirements Install oCIS and Traefik Local setup Overview oCIS and Keycloak running behind Traefik as reverse proxy Keycloak acting as the IDP for oCIS Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup Find this example on GitHub\nThe docker stack consists 4 containers. One of them is Traefik, a proxy which is terminating ssl and forwards the requests to oCIS in the internal docker network.\nKeykloak add two containers: Keycloak itself and a PostgreSQL as database. Keycloak will be configured as oCIS\u0026rsquo; IDP instead of the internal IDP Konnectd\nThe other container is oCIS itself running all extensions in one container. In this example oCIS uses oCIS storage driver\nServer Deployment Requirements Linux server with docker and docker-compose installed Three domains set up and pointing to your server ocis.* for serving oCIS keycloak.* for serving Keycloak traefik.* for serving the Traefik dashboard See also example server setup\nInstall oCIS and Traefik Clone oCIS repository\ngit clone https://github.com/owncloud/ocis.git\n Go to the deployment example\ncd ocis/deployment/examples/ocis_keycloak\n Open the .env file in a text editor The file by default looks like this:\n# If you\u0026#39;re on a internet facing server please comment out following line. # It skips certificate validation for various parts of oCIS and is needed if you use self signed certificates. INSECURE=true ### Traefik settings ### # Domain of Traefik, where you can find the dashboard. Defaults to \u0026#34;traefik.owncloud.test\u0026#34; TRAEFIK_DOMAIN= # Basic authentication for the dashboard. Defaults to user \u0026#34;admin\u0026#34; and password \u0026#34;admin\u0026#34; TRAEFIK_BASIC_AUTH_USERS= # Email address for obtaining LetsEncrypt certificates, needs only be changed if this is a public facing server TRAEFIK_ACME_MAIL= ### oCIS settings ### # oCIS version. Defaults to \u0026#34;latest\u0026#34; OCIS_DOCKER_TAG= # Domain of oCIS, where you can find the frontend. Defaults to \u0026#34;ocis.owncloud.test\u0026#34; OCIS_DOMAIN= # ownCloud Web openid connect client id. Defaults to \u0026#34;ocis-web\u0026#34; OCIS_OIDC_CLIENT_ID= ### Keycloak ### # Domain of Keycloak, where you can find the managment and authentication frontend. Defaults to \u0026#34;keycloak.owncloud.test\u0026#34; KEYCLOAK_DOMAIN= # Realm which to be used with oCIS. Defaults to \u0026#34;master\u0026#34; KEYCLOAK_REALM= # Admin user login name. Defaults to \u0026#34;admin\u0026#34; KEYCLOAK_ADMIN_USER= # Admin user login password. Defaults to \u0026#34;admin\u0026#34; KEYCLOAK_ADMIN_PASSWORD= You are installing oCIS on a server and Traefik will obtain valid certificates for you so please remove INSECURE=true or set it to false.\nSet your domain for the Traefik dasboard in TRAEFIK_DOMAIN= eg. TRAEFIK_DOMAIN=traefik.owncloud.test.\nThe Traefik dasboard is secured by basic auth. Default credentials are the user admin with the password admin. To set your own credentials, generate a htpasswd (eg. by using an online tool or a cli tool).\nTraefik will issue certificates with LetsEncrypt and therefore you must set an email address in TRAEFIK_ACME_MAIL=.\nBy default ocis will be started in the latest version. If you want to start a specific version of oCIS set the version to OCIS_DOCKER_TAG=. Available versions can be found on Docker Hub.\nSet your domain for the oCIS frontend in OCIS_DOMAIN=, eg. OCIS_DOMAIN=ocis.owncloud.test.\nIf you want to change the OIDC client id of th ownCloud Web frontend, you can do this by setting the name to OCIS_OIDC_CLIENT_ID=.\nSet your domain for the Keycloak adminstration panel and authentication endpoints to KEYCLOAK_DOMAIN= eg. KEYCLOAK_DOMAIN=keycloak.owncloud.test.\nChanging the used Keycloak realm can be done by setting KEYCLOAK_REALM=. This defaults to the master realm KEYCLOAK_REALM=master.\nYou probably should secure your Keycloak admin account by setting KEYCLOAK_ADMIN_USER= and KEYCLOAK_ADMIN_PASSWORD= to values other than admin.\nNow you have configured everything and can save the file.\n Start the docker stack\ndocker-compose up -d\n Visit the Keycloak administration console on your configured domain. Go to clients settings and add a client. The client id is ocis-web or the one you changed it to. The client protocol is openid-connect. The root url for the client is the url you selected for oCIS. Then save the client.\n You may also add users to Keycloak\n You now can visit oCIS and Traefik dashboard on your configured domains\n Local setup For a more simple local ocis setup see Getting started\nThis docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.\nOn Linux and macOS you can add them to your /etc/hosts files like this:\n127.0.0.1 ocis.owncloud.test 127.0.0.1 traefik.owncloud.test 127.0.0.1 keycloak.owncloud.test After that you\u0026rsquo;re ready to start the application stack:\ndocker-compose up -d\nOpen https://keycloak.owncloud.test in your browser and accept the invalid certificate warning. Go to clients settings and add a client. The client id is ocis-web or the one you changed it to. The client protocol is openid-connect. THe root url for the client is https://ocis.owncloud.test. Then save the client.\n You may also add users to Keycloak Open https://ocis.owncloud.test in your browser and accept the invalid certificate warning. You now can login to oCIS with the admin user of keycloak and additional users you created.\n"});index.add({'id':44,'href':'/ocis/deployment/ocis_traefik/','title':"oCIS with Traefik",'parent':"Deployment",'content':" Overview Server Deployment Requirements Install oCIS and Traefik Local setup Overview oCIS running behind Traefik as reverse proxy Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup Find this example on GitHub\nThe docker stack consists of two containers. One of them is Traefik, a proxy which is terminating ssl and forwards the requests to oCIS in the internal docker network.\nThe other one is oCIS itself running all extensions in one container. In this example oCIS uses its internal IDP Konnectd and the oCIS storage driver\nServer Deployment Requirements Linux server with docker and docker-compose installed Two domains set up and pointing to your server ocis.* for serving oCIS traefik.* for serving the Traefik dashboard See also example server setup\nInstall oCIS and Traefik Clone oCIS repository\ngit clone https://github.com/owncloud/ocis.git\n Go to the deployment example\ncd ocis/deployment/examples/ocis_traefik\n Open the .env file in a text editor The file by default looks like this:\n# If you\u0026#39;re on a internet facing server please comment out following line. # It skips certificate validation for various parts of oCIS and is needed if you use self signed certificates. INSECURE=true ### Traefik settings ### # Domain of Traefik, where you can find the dashboard. Defaults to \u0026#34;traefik.owncloud.test\u0026#34; TRAEFIK_DOMAIN= # Basic authentication for the dashboard. Defaults to user \u0026#34;admin\u0026#34; and password \u0026#34;admin\u0026#34; TRAEFIK_BASIC_AUTH_USERS= # Email address for obtaining LetsEncrypt certificates, needs only be changed if this is a public facing server TRAEFIK_ACME_MAIL= ### oCIS settings ### # oCIS version. Defaults to \u0026#34;latest\u0026#34; OCIS_DOCKER_TAG= # Domain of oCIS, where you can find the frontend. Defaults to \u0026#34;ocis.owncloud.test\u0026#34; OCIS_DOMAIN= You are installing oCIS on a server and Traefik will obtain valid certificates for you so please remove INSECURE=true or set it to false.\nSet your domain for the Traefik dasboard in TRAEFIK_DOMAIN= eg. TRAEFIK_DOMAIN=traefik.owncloud.test.\nThe Traefik dasboard is secured by basic auth. Default credentials are the user admin with the password admin. To set your own credentials, generate a htpasswd (eg. by using an online tool or a cli tool).\nTraefik will issue certificates with LetsEncrypt and therefore you must set an email address in TRAEFIK_ACME_MAIL=.\nBy default ocis will be started in the latest version. If you want to start a specific version of oCIS set the version to OCIS_DOCKER_TAG=. Available versions can be found on Docker Hub.\nSet your domain for the oCIS frontend in OCIS_DOMAIN=, eg. OCIS_DOMAIN=ocis.owncloud.test.\nNow you have configured everything and can save the file.\n Start the docker stack\ndocker-compose up -d\n You now can visit oCIS and Traefik dashboard on your configured domains\n Local setup For a more simple local ocis setup see Getting started\nThis docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.\nOn Linux and macOS you can add them to your /etc/hosts files like this:\n127.0.0.1 ocis.owncloud.test 127.0.0.1 traefik.owncloud.test After that you\u0026rsquo;re ready to start the application stack:\ndocker-compose up -d\nOpen https://ocis.owncloud.test in your browser and accept the invalid certificate warning. You now can login to oCIS with the default users, which also can be found here: Getting started\n"});index.add({'id':45,'href':'/ocis/deployment/owncloud10_with_oc_web/','title':"ownCloud 10 with ownCloud Web",'parent':"Deployment",'content':" Overview Server Deployment Requirements Install oCIS and Traefik Local setup This deployment scenario shows how to use ownCloud Web as frontend for an existing ownCloud 10 production installation. It enables ownCloud 10 users to log in and work with their files using the new ownCloud Web. While the scenario includes an ownCloud 10 instance, it only exists to show the necessary configuration for your already existing ownCloud 10 installation.\nOverview oCIS setup serving ownCloud Web oCIS acting as OIDC IDP on the ownCloud 10 user database ownCloud 10 setup connected to oCIS DNS is resolving one domain for ocis and one for oc10 Valid ssl certificates for the domains for ssl termination Find this example on GitHub\nIn this setup it\u0026rsquo;s mandatory that the users in ownCloud 10 are assigned to at least one group. In this setup relies on graph-api app to be installed in ownCloud 10. This app is included by default beginning with ownCloud 10.6. If you are on a lower version, please install it manually. Server Deployment Requirements Linux server with docker and docker-compose installed Three domains set up and pointing to your server ocis.* for serving oCIS oc10.* for serving traefik.* for serving the Traefik dashboard See also example server setup\nInstall oCIS and Traefik Clone oCIS repository\ngit clone https://github.com/owncloud/ocis.git\n Go to the deployment example\ncd ocis/deployment/examples/ocis_oc10_backend\n Open the .env file in a text editor The file by default looks like this:\n# If you\u0026#39;re on a internet facing server please comment out following line. # It skips certificate validation for various parts of oCIS and is needed if you use self signed certificates. INSECURE=true ### Traefik settings ### # Domain of Traefik, where you can find the dashboard. Defaults to \u0026#34;traefik.owncloud.test\u0026#34; TRAEFIK_DOMAIN= # Basic authentication for the dashboard. Defaults to user \u0026#34;admin\u0026#34; and password \u0026#34;admin\u0026#34; TRAEFIK_BASIC_AUTH_USERS= # Email address for obtaining LetsEncrypt certificates, needs only be changed if this is a public facing server TRAEFIK_ACME_MAIL= ### oCIS settings ### # oCIS version. Defaults to \u0026#34;latest\u0026#34; OCIS_DOCKER_TAG= # Domain of oCIS, where you can find the frontend. Defaults to \u0026#34;ocis.owncloud.test\u0026#34; OCIS_DOMAIN= ### oC10 ### # Domain of ownCloud 10, where you can find the frontend. Defaults to \u0026#34;oc10.owncloud.test\u0026#34; #OC10_DOMAIN= You are installing oCIS on a server and Traefik will obtain valid certificates for you so please remove INSECURE=true or set it to false.\nSet your domain for the Traefik dasboard in TRAEFIK_DOMAIN= eg. TRAEFIK_DOMAIN=traefik.owncloud.test.\nThe Traefik dasboard is secured by basic auth. Default credentials are the user admin with the password admin. To set your own credentials, generate a htpasswd (eg. by using an online tool or a cli tool).\nTraefik will issue certificates with LetsEncrypt and therefore you must set an email address in TRAEFIK_ACME_MAIL=.\nBy default ocis will be started in the latest version. If you want to start a specific version of oCIS set the version to OCIS_DOCKER_TAG=. Available versions can be found on Docker Hub.\nSet your domain for the oCIS frontend in OCIS_DOMAIN=, eg. OCIS_DOMAIN=ocis.owncloud.test.\nSet your domain for the ownCloud 10 frontend in OC10_DOMAIN= eg. OC10_DOMAIN=oc10.owncloud.test.\nNow you have configured everything and can save the file.\n Start the docker stack\ndocker-compose up -d\n You now can visit oCIS and Traefik dashboard on your configured domains\n Local setup For a more simple local ocis setup see Getting started\nThis docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.\nOn Linux and macOS you can add them to your /etc/hosts files like this:\n127.0.0.1 ocis.owncloud.test 127.0.0.1 oc10.owncloud.test 127.0.0.1 traefik.owncloud.test After that you\u0026rsquo;re ready to start the application stack:\ndocker-compose up -d\nOpen https://oc10.owncloud.test in your browser and accept the invalid certificate warning. You now can login with the ownCloud 10 default user \u0026ldquo;admin\u0026rdquo; and password \u0026ldquo;admin\u0026rdquo;. As you might have noticed, you did not see the login prompt of ownCloud 10. This was the login prompt of oCIS. When you go to application you can both in ownCloud Web and ownCloud 10 see a switch to switch vice versa.\n"});index.add({'id':46,'href':'/clients/web/releasing/','title':"Releasing",'parent':"ownCloud Web",'content':" Releasing ownCloud Web Package Hierarchy Releasing Web Frontend Next steps Releasing ownCloud Web The ownCloud Web is shipped as an ocis Extension. The ocis-web extension is also embedded in the single binary and part of the ocis server command.\nThis repository contains the assets and these must be released first before being bundled into ocis-web.\nPackage Hierarchy ocis ocis-web ocis-pkg web Releasing Web Frontend Create a branch release-$version in https://github.com/owncloud/web. Create a folder in changelog for the release version and date mkdir $major.$minor.$patchVersion_YYYY-MM-DD. Move all changelog items from the changelog/unreleased/ folder to the $major.$minor.$patchVersion_YYYY-MM-DD folder. Commit your changes. After merging, wait for the CI to run on the merge commit. Go to the Releases section and click \u0026ldquo;Draft a new Release\u0026rdquo;. Use v$major.$minor.$patch as a tag (the v prefix is important) and publish it. The tag and the Release artifacts will be created automatically. Next steps The next steps are usually to update the Web assets in the ocis-web repository.\n"});index.add({'id':47,'href':'/ocis/flow-docs/','title':"Flow documentation",'parent':"oCIS - ownCloud Infinite Scale",'content':""});index.add({'id':48,'href':'/ocis/deployment/bridge/','title':"Bridge",'parent':"Deployment",'content':" Current status How to do it Install the owncloud 10 graphapi app Enable the graphapi app Start ocis-glauth Grab it! Run it! Check it is up and running Start ocis-web Get it! Run it! Start ocis-konnectd Get it! Set environment variables Configure clients Run it! Check it is up and running Patch owncloud Install the owncloud 10 openidconnect app Next steps We are planning to build a bridge from ownCloud 10 to ocis. The idea is to have a reverse proxy infront of ownCloud 10 that will forward requests to ownCloud 10 or ocis-reva, depending on the migration status of the logged in user.\nThis document is a work in progress of the current setup.\nCurrent status Using ocis and the ownCloud 10 openidconnect and graphapi plugins it is possible today to introduce openid connect based authentication to existing instances. That is a prerequisite for migrating to ocis.\nHow to do it Install the owncloud 10 graphapi app In an owncloud 10 apps folder\n$ git clone git@github.com:owncloud/graphapi.git $ cd graphapi $ composer install Enable the graphapi app occ a:e graphapi No configuration necessary. You can test with curl:\n$ curl https://cloud.example.com/index.php/apps/graphapi/v1.0/users -u admin | jq Enter host password for user \u0026#39;admin\u0026#39;: % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 694 100 694 0 0 4283 0 --:--:-- --:--:-- --:--:-- 4283 { \u0026#34;value\u0026#34;: [ { \u0026#34;id\u0026#34;: \u0026#34;admin\u0026#34;, \u0026#34;displayName\u0026#34;: \u0026#34;admin\u0026#34;, \u0026#34;mail\u0026#34;: null }, { \u0026#34;id\u0026#34;: \u0026#34;demo\u0026#34;, \u0026#34;displayName\u0026#34;: \u0026#34;Demo\u0026#34;, \u0026#34;mail\u0026#34;: null }, ... ], \u0026#34;@odata.nextLink\u0026#34;: \u0026#34;https://oc.butonic.de/apps/graphapi/v1.0/users?$top=10\u0026amp;$skip=10\u0026#34; } Note: The MS graph api actually asks for Bearer auth, but in order to check users passwords during an LDAP bind we are exploiting ownClouds authentication implementation that will grant access when Basic auth is used. An LDAP Bind you may ask? Read on!\n Start ocis-glauth We are going to use the above ownCloud 10 and graphapi app to turn it into the datastore for an LDAP proxy.\nGrab it! In an ocis folder\n$ git clone git@github.com:owncloud/ocis-glauth.git $ cd ocis-glauth $ make This should give you a bin/ocis-glauth binary. Try listing the help with bin/ocis-glauth --help.\nRun it! You need to point ocis-glauth to your owncloud domain:\n$ bin/ocis-glauth --log-level debug server --backend-datastore owncloud --backend-server https://cloud.example.com --backend-basedn dc=example,dc=com --log-level debug is only used to generate more verbose output --backend-datastore owncloud switches to tho owncloud datastore --backend-server https://cloud.example.com is the url to an ownCloud instance with an enabled graphapi app --backend-basedn dc=example,dc=com is used to construct the LDAP dn. The user admin will become cn=admin,dc=example,dc=com.\nCheck it is up and running You should now be able to list accounts from your ownCloud 10 oc_accounts table using:\n$ ldapsearch -x -H ldap://localhost:9125 -b dc=example,dc=com -D \u0026#34;cn=admin,dc=example,dc=com\u0026#34; -W \u0026#39;(objectclass=posixaccount)\u0026#39; Groups should work as well:\n$ ldapsearch -x -H ldap://localhost:9125 -b dc=example,dc=com -D \u0026#34;cn=admin,dc=example,dc=com\u0026#34; -W \u0026#39;(objectclass=posixgroup)\u0026#39; Note: This is currently a readonly implementation and minimal to the usecase of authenticating users with konnectd.\n Start ocis-web Get it! In an ocis folder\n$ git clone git@github.com:owncloud/ocis.git $ cd web $ make This should give you a bin/web binary. Try listing the help with bin/web --help.\nRun it! Point ocis-web to your owncloud domain and tell it where to find the openid connect issuing authority:\n$ bin/web server --web-config-server https://cloud.example.com --oidc-authority https://192.168.1.100:9130 --oidc-metadata-url https://192.168.1.100:9130/.well-known/openid-configuration --oidc-client-id ocis ocis-web needs to know\n --web-config-server https://cloud.example.com is ownCloud url with webdav and ocs endpoints (oc10 or ocis) --oidc-authority https://192.168.1.100:9130 the openid connect issuing authority, in our case oidc-konnectd, running on port 9130 --oidc-metadata-url https://192.168.1.100:9130/.well-known/openid-configuration the openid connect configuration endpoint, typically the issuer host with .well-known/openid-configuration, but there are cases when another endpoint is used, eg. ping identity provides multiple endpoints to separate domains --oidc-client-id ocis the client id we will register later with ocis-konnectd in the identifier-registration.yaml Start ocis-konnectd Get it! In an ocis folder\n$ git clone git@github.com:owncloud/ocis-konnectd.git $ cd ocis-konnectd $ make This should give you a bin/ocis-konnectd binary. Try listing the help with bin/ocis-konnectd --help.\nSet environment variables Konnectd needs environment variables to configure the LDAP server:\nexport LDAP_URI=ldap://192.168.1.100:9125 export LDAP_BINDDN=\u0026#34;cn=admin,dc=example,dc=com\u0026#34; export LDAP_BINDPW=\u0026#34;its-a-secret\u0026#34; export LDAP_BASEDN=\u0026#34;dc=example,dc=com\u0026#34; export LDAP_SCOPE=sub export LDAP_LOGIN_ATTRIBUTE=uid export LDAP_EMAIL_ATTRIBUTE=mail export LDAP_NAME_ATTRIBUTE=givenName export LDAP_UUID_ATTRIBUTE=uid export LDAP_UUID_ATTRIBUTE_TYPE=text export LDAP_FILTER=\u0026#34;(objectClass=posixaccount)\u0026#34; Don\u0026rsquo;t forget to use an existing user and the correct password.\nConfigure clients Now we need to configure a client we can later use to configure the ownCloud 10 openidconnect app. In the assets/identifier-registration.yaml have:\n---# OpenID Connect client registry.clients:- id:ocisname:ownCloudInfiniteScaleinsecure:yesapplication_type:webredirect_uris:- https://cloud.example.com/apps/openidconnect/redirect- http://localhost:9100/oidc-callback.html- http://localhost:9100- http://localhost:9100/You will need the insecure: yes if you are using self signed certificates.\nReplace cloud.example.com in the redirect URI with your ownCloud 10 host and port. Replace localhost:9100 in the redirect URIs with your ocis-web host and port.\nRun it! You can now bring up ocis-konnectd with:\n$ bin/ocis-konnectd server --iss https://192.168.1.100:9130 --identifier-registration-conf assets/identifier-registration.yaml --signing-kid gen1-2020-02-27 ocis-konnectd needs to know\n --iss https://192.168.1.100:9130 the issuer, which must be a reachable https endpoint. For testing an ip works. HTTPS is NOT optional. This url is exposed in the https://192.168.1.100:9130/.well-known/openid-configuration endpoint and clients need to be able to connect to it --identifier-registration-conf assets/identifier-registration.yaml the identifier-registration.yaml you created --signing-kid gen1-2020-02-27 a signature key id, otherwise the jwks key has no name, which might cause problems with clients. a random key is ok, but it should change when the actual signing key changes. Check it is up and running Try getting the configuration: $ curl https://192.168.1.100:9130/.well-known/openid-configuration Check if the login works at https://192.168.1.100:9130/signin/v1/identifier Note: If you later get a Unable to find a key for (algorithm, kid):PS256, ) Error make sure you did set a --signing-kid when starting ocis-konnectd by checking it is present in https://192.168.1.100:9130/konnect/v1/jwks.json\n Patch owncloud While the UserSession in ownCloud 10 is currently used to test all available IAuthModule implementations, it immediately logs out the user when an exception occurs. However, existing owncloud 10 instances use the oauth2 app to create Bearer tokens for mobile and desktop clients.\nTo give the openidconnect app a chance to verify the tokens we need to change the code a bit. See https://github.com/owncloud/core/pull/37043 for a possible solution.\n Note: The PR is hot \u0026hellip; as in younger than this list of steps. And it messes with authentication. Use with caution.\n Install the owncloud 10 openidconnect app In an owncloud 10 apps folder\n$ git clone git@github.com:owncloud/openidconnect.git $ cd openidconnect $ composer install After enabling the app configure it in config/oidc.config.php\n$CONFIG = [ \u0026#39;openid-connect\u0026#39; =\u0026gt; [ \u0026#39;provider-url\u0026#39; =\u0026gt; \u0026#39;https://192.168.1.100:9130\u0026#39;, \u0026#39;client-id\u0026#39; =\u0026gt; \u0026#39;ocis\u0026#39;, \u0026#39;loginButtonName\u0026#39; =\u0026gt; \u0026#39;OpenId Connect @ Konnectd\u0026#39;, ], \u0026#39;debug\u0026#39; =\u0026gt; true, // if using self signed certificates // allow the different domains access to the ocs and wabdav endpoints: \u0026#39;cors.allowed-domains\u0026#39; =\u0026gt; [ \u0026#39;https://cloud.example.com\u0026#39;, \u0026#39;http://localhost:9100\u0026#39;, ], ]; In the above configuration replace\n provider-url with the URL to your ocis-konnectd issuer https://cloud.example.com with the URL to your ownCloud 10 instance http://localhost:9100 with the URL to your ownCloud Web instance Note: By default the openidconnect app will use the email of the user to match the user from the oidc userinfo endpoint with the ownCloud account. So make sure your users have a unique primary email.\n Next steps Aside from the above todos these are the next stepo\n tie it all together behind ocis-proxy create an ocis bridge command that runs all the ocis services in one step with a properly preconfigured ocis-konnectd identifier-registration.yaml file for ownCloud Web and the owncloud 10 openidconnect app, as well as a randomized --signing-kid. "});index.add({'id':49,'href':'/ocis/development/build/','title':"Build",'parent':"Development",'content':" Build requirements Get the sources Build the oCIS binary Build a local oCIS docker image Build requirements see Development - Getting Started\nGet the sources git clone https://github.com/owncloud/ocis.git cd ocis Build the oCIS binary The oCIS binary source is in the ocis folder inside the oCIS repository. In this folder you can build the oCIS binary:\ncd ocis make generate make build After building you have the binary within the bin/ folder. Try to run it: ./bin/ocis -h\nBuild a local oCIS docker image If you are developing and want to run your local changes in a docker or docker-compose setup, you have to build an image locally.\nTherefore run following commands in the root of the oCIS repository:\ndocker build -t owncloud/ocis:dev . Then you can test as usual via\ndocker run --rm -ti owncloud/ocis:dev "});index.add({'id':50,'href':'/ocis/storage-backends/eos/','title':"EOS",'parent':"Storage backends",'content':" Docker dev environment for eos storage 1. Start eos \u0026amp; ocis containers 2. LDAP support 3. Home storage 4. Users storage 5. Metadata storage 6. Accounts service Verification Further exploration Cleaning up Troubleshooting Docker-compose exits right away Where are the logs ? How do I update a service in the ocis container? Creation and upload of files does not work Uploading big files appears to hang Running out of space quickly oCIS can be configured to run on top of eos. While the eos documentation does cover a lot of topics it leaves out some details that you may have to either pull from various docker containers, the forums or even the source itself.\nThis document is a work in progress of the current setup.\nDocker dev environment for eos storage We begin with the docker-compose.yml found in https://github.com/owncloud/ocis/tree/master/ocis/ and switch it to eos-storage.\n1. Start eos \u0026amp; ocis containers Start the eos cluster and ocis via the compose stack.\ndocker-compose up -d The first time the ocis container starts up, it will compile ocis from scratch which can take a while. To follow progress, run docker-compose logs -f --tail=10 ocis 2. LDAP support Configure the OS to resolve users and groups using ldap\ndocker-compose exec -d ocis /start-ldap Check that the OS in the ocis container can now resolve einstein or the other demo users\n$ docker-compose exec ocis id einstein uid=20000(einstein) gid=30000(users) groups=30000(users),30001(sailing-lovers),30002(violin-haters),30007(physics-lovers) If the user is not found at first you might need to wait a few more minutes in case the ocis container is still compiling. We also need to restart the storage-userprovider service, so it picks up the changed environment. Without a restart it is not able to resolve users from LDAP.\ndocker-compose exec ocis ./bin/ocis kill storage-userprovider docker-compose exec ocis ./bin/ocis run storage-userprovider 3. Home storage Kill the home storage. By default it uses the ocis storage driver. We need to switch it to the eoshome driver:\ndocker-compose exec ocis ./bin/ocis kill storage-home docker-compose exec -e STORAGE_HOME_DRIVER=eoshome ocis ./bin/ocis run storage-home 4. Users storage Kill the users storage. By default it uses the ocis storage driver. We need to switch it to the eos driver:\ndocker-compose exec ocis ./bin/ocis kill storage-users docker-compose exec -e STORAGE_USERS_DRIVER=eos ocis ./bin/ocis run storage-users 5. Metadata storage First we need to create the metadata root in eos and set an owner:\ndocker-compose exec ocis eos mkdir -p /eos/dockertest/ocis/metadata docker-compose exec ocis eos chown 2:2 /eos/dockertest/ocis/metadata The uid and gid 2 are referencing the user daemon inside the ocis container. That user is also configured when restarting the accounts service later. For production systems you should create a dedicated user for the metadata storage. Kill the metadata storage. By default it uses the ocis storage driver. We need to switch it to the eos driver:\ndocker-compose exec ocis ./bin/ocis kill storage-metadata docker-compose exec -e STORAGE_METADATA_DRIVER=eos -e STORAGE_METADATA_ROOT=/eos/dockertest/ocis/metadata ocis ./bin/ocis run storage-metadata 6. Accounts service Kill the accounts service. By default it uses the ocis storage driver. We need to switch it to the eos driver:\ndocker-compose exec ocis ./bin/ocis kill accounts docker-compose exec -e ACCOUNTS_SERVICE_USER_USERNAME=daemon -e ACCOUNTS_SERVICE_USER_UID=2 -e ACCOUNTS_SERVICE_USER_GID=2 ocis ./bin/ocis run accounts Verification Login with einstein / relativity, upload a file to einsteins home and verify the file is there using\ndocker-compose exec ocis eos ls -l /eos/dockertest/reva/users/4/4c510ada-c86b-4815-8820-42cdf82c3d51/ -rw-r--r-- 1 einstein users 10 Jul 1 15:24 newfile.txt If the problem persists, please check the troubleshooting section about uploads.\nFurther exploration EOS has a built in shell that you can enter using\n$ docker-compose exec mgm-master eos # --------------------------------------------------------------------------- # EOS Copyright (C) 2011-2019 CERN/Switzerland # This program comes with ABSOLUTELY NO WARRANTY; for details type `license\u0026#39;. # This is free software, and you are welcome to redistribute it # under certain conditions; type `license\u0026#39; for details. # --------------------------------------------------------------------------- EOS_INSTANCE=eostest EOS_SERVER_VERSION=4.6.5 EOS_SERVER_RELEASE=1 EOS_CLIENT_VERSION=4.6.5 EOS_CLIENT_RELEASE=1 EOS Console [root://localhost] |/\u0026gt; help access Access Interface accounting Accounting Interface acl Acl Interface archive Archive Interface attr Attribute Interface backup Backup Interface clear Clear the terminal cd Change directory chmod Mode Interface chown Chown Interface config Configuration System console Run Error Console cp Cp command debug Set debug level exit Exit from EOS console file File Handling fileinfo File Information find Find files/directories newfind Find files/directories (new implementation) fs File System configuration fsck File System Consistency Checking fuse Fuse Mounting fusex Fuse(x) Administration geosched Geoscheduler Interface group Group configuration health Health information about system help Display this text info Retrieve file or directory information inspector Interact with File Inspector io IO Interface json Toggle JSON output flag for stdout license Display Software License ls List a directory ln Create a symbolic link map Path mapping interface member Check Egroup membership mkdir Create a directory motd Message of the day mv Rename file or directory node Node configuration ns Namespace Interface pwd Print working directory quit Exit from EOS console quota Quota System configuration reconnect Forces a re-authentication of the shell recycle Recycle Bin Functionality rmdir Remove a directory rm Remove a file role Set the client role route Routing interface rtlog Get realtime log output from mgm \u0026amp; fst servers silent Toggle silent flag for stdout space Space configuration stagerrm Remove disk replicas of a file if it has tape replicas stat Run \u0026#39;stat\u0026#39; on a file or directory squash Run \u0026#39;squashfs\u0026#39; utility function test Run performance test timing Toggle timing flag for execution time measurement touch Touch a file token Token interface tracker Interact with File Tracker transfer Transfer Interface version Verbose client/server version vid Virtual ID System Configuration whoami Determine how we are mapped on server side who Statistics about connected users ? Synonym for \u0026#39;help\u0026#39; .q Exit from EOS console EOS Console [root://localhost] |/\u0026gt; But this is a different adventure. See the links at the top of this page for other sources of information on eos.\nCleaning up To clean up and start completely from scratch, run docker-compose down -v. Then delete the local \u0026ldquo;bin\u0026rdquo; folder as root which contains the ocis binaries compiled by the \u0026ldquo;ocis\u0026rdquo; docker.\nTroubleshooting Docker-compose exits right away When running docker-compose up -d ocis exits right away.\nYou can check the error code using docker-compose ps and investigate further by running only ocis again using docker-compose up ocis (without -d so you can see what is going on in the foreground). One reason might be that the binary was already built but does not match the container env. Try running make clean before running docker-compose up ocis so it gets built inside the container.\nWhere are the logs ? The ocis logs can be accessed using docker-compose logs ocis. Add -f for following.\nHow do I update a service in the ocis container? docker-compose exec ocis make clean build to update the binary docker-compose exec ocis ./bin/ocis kill \u0026lt;service\u0026gt; to kill the service docker-compose exec ocis ./bin/ocis run \u0026lt;service\u0026gt; to start the service. Do not forget to set any env vars, eg. docker-compose exec -e STORAGE_HOME_DRIVER=eoshome -e STORAGE_DRIVER_EOS_LAYOUT=\u0026quot;{{substr 0 1 .Id.OpaqueId}}/{{.Id.OpaqueId}}\u0026quot; ocis ./bin/ocis run storage-home Creation and upload of files does not work If the upload did not work, please check the status of the eos space using the command docker-compose exec mgm-master eos fs ls. In case the default space appears as offline, run docker-compose exec mgm-master eos space set default on.\nUploading big files appears to hang Please note that the uploads first go into the \u0026ldquo;ocis\u0026rdquo; docker and land in its \u0026ldquo;/tmp\u0026rdquo; folder, then gets copied over to the EOS docker using xrdcopy. This is why uploading first transfers all bytes and then seem to hang for a while during the final copy.\nRunning out of space quickly The EOS dockers are configured with replication, so every file uploaded there will be replicated 4 times, so make sure there is enough physical space on disk when testing.\nAlso please note that older failed uploads might still be present in the \u0026ldquo;/tmp\u0026rdquo; directory of the \u0026ldquo;ocis\u0026rdquo; container.\n"});index.add({'id':51,'href':'/extensions/onlyoffice/building/','title':"Building",'parent':"OnlyOffice",'content':" Backend As this project is built with Go, so you need to install that first. The installation of Go is out of the scope of this document, please follow the official documentation for Go, to build this project you have to install Go \u0026gt;= v1.12. After the installation of the required tools you need to get the sources:\ngit clone https://github.com/owncloud/ocis/onlyoffice.git cd ocis-onlyoffice All required tool besides Go itself and make are bundled or getting automatically installed within the GOPATH. All commands to build this project are part of our Makefile.\nBackend make generate make build Finally you should have the binary within the bin/ folder now, give it a try with ./bin/onlyoffice -h to see all available options.\n"});index.add({'id':52,'href':'/extensions/storage/users/','title':"Users",'parent':"Storage",'content':"Demo driver This is a simple user driver for testing. It contains three users:\neinstein:relativity marie:radioactivty richard:superfluidity In order to use the demo driver you need to export the relevant environment variable:\nexport STORAGE_USERS_DRIVER=demo JSON driver In order to switch from the ldap driver to JSON based users you need to export the relevant environment variables:\nexport STORAGE_USERS_DRIVER=json export STORAGE_USERS_JSON=/path/to/users.json For the format of the users.json have a look at the reva examples\nLDAP driver This is the default user driver.\nIf the below defaults don\u0026rsquo;t match your environment change them accordingly:\nexport STORAGE_LDAP_HOSTNAME=localhost export STORAGE_LDAP_PORT=9126 export STORAGE_LDAP_BASE_DN=\u0026#39;dc=example,dc=org\u0026#39; export STORAGE_LDAP_USERFILTER=\u0026#39;(\u0026amp;(objectclass=posixAccount)(cn=%s))\u0026#39; export STORAGE_LDAP_GROUPFILTER=\u0026#39;(\u0026amp;(objectclass=posixGroup)(cn=%s))\u0026#39; export STORAGE_LDAP_BIND_DN=\u0026#39;cn=reva,ou=sysusers,dc=example,dc=org\u0026#39; export STORAGE_LDAP_BIND_PASSWORD=reva export STORAGE_LDAP_SCHEMA_UID=uid export STORAGE_LDAP_SCHEMA_MAIL=mail export STORAGE_LDAP_SCHEMA_DISPLAYNAME=sn export STORAGE_LDAP_SCHEMA_CN=cn Then restart the bin/storage users and bin/storage auth-basic services for the changes to take effect.\n"});index.add({'id':53,'href':'/extensions/storage/storages/','title':"Storages",'parent':"Storage",'content':"Storage commands storage has multiple storage provider commands to preconfigure different default configurations for the reva storage provider service. While you could rerun storage storage-oc multiple times with different flags to get multiple instances we are giving the different commands the necessary default configuration to allow the ocis binary to simply start them and not deal with configuration.\nStorage providers To manage the file tree ocis uses storage storage providers that are accessing the underlying storage using a storage driver. The driver can be used to change the implementation of a storage aspect to better reflect the actual underlying storage capabilities. As an example a move operation on a POSIX filesystem (theoretically) is an atomic operation. When trying to implement a file tree on top of S3 there is no native move operation that can be used. A naive implementation might fall back on a COPY and DELETE. Some S3 implementations provide a COPY operation that uses an existing key as the source, so the file at least does not need to be reuploaded. In the worst case scenario, which is renaming a folder with hundreds of thousands of objects, a reupload for every file has to be made. Instead of hiding this complexity a better choice might be to disable renaming of files or at least folders on S3. There are however implementations of filesystems on top of S3 that store the tree metadata in dedicated objects or use a completely different persistence mechanism like a distributed key value store to implement the file tree aspect of a storage.\nWhile the storage provider is responsible for managing the tree, file up and download is delegated to a dedicated data provider. See below. Storage aspects A lot of different storage technologies exist, ranging from general purpose file systems with POSIX semantics to software defined storage with multiple APIs. Choosing any of them is making a tradeoff decision. Or, if a storage technology is already in place it automatically predetermines the capabilities that can be made available. Not all storage systems are created equal.\nUnfortunately, no POSIX filesystem natively supports all storage aspects that ownCloud 10 requires:\nA hierarchical file tree An important aspect of a filesystem is organizing files and directories in a file hierarchy, or tree. It allows you to create, move and delete nodes. Beside the name a node also has well known metadata like size and mtime that are persisted in the tree as well.\nFolders are not directories There is a difference between folder and directory: a directory is a file system concept. A folder is a metaphor for the concept of a physical file folder. There are also virtual folders or smart folders like the recent files folder which are no file system directories. So, every directory and every virtual folder is a folder, but not every folder is a directory. See the folder metaphor in wikipedia. Also see the activity history below. Id based lookup While traditionally nodes in the tree are reached by traversing the path the tree persistence should be prepared to look up a node by an id. Think of an inode in a POSIX filesystem. If this operation needs to be cached for performance reasons keep in mind that cache invalidation is hard and crawling all files to update the inode to path mapping takes O(n), not O(1).\nETag propagation For the state based sync a client can discover changes by recursively descending the tree and comparing the ETag for every node. If the storage technology supports propagating ETag changes up the tree, only the root node of a tree needs to be checked to determine if a discovery needs to be started and which nodes need to be traversed. This allows using the storage technology itself to persist all metadata that is necessary for sync, without additional services or caches.\nSubtree size accounting The tree can keep track of how many bytes are stored in a folder. Similar to ETag propagation a change in file size is propagated up the hierarchy.\nETag and Size propagation When propagating the ETag (mtime) and size changes up the tree the question is where to stop. If all changes need to be propagated to the root of a storage then the root or busy folders will become a hotspot. There are two things to keep in mind: 1. propagation only happens up to the root of a single space (a user private drive or a single group drive), 2. no cross storage propagation. The latter was used in oc10 to let clients detect when a file in a received shared folder changed. This functionality is moving to the storage registry which caches the ETag for every root so clients can discover if and which storage changed. Rename Depending on the underlying storage technology some operations may either be slow, up to a point where it makes more sense to disable them entirely. One example is a folder rename: on S3 a simple folder rename translates to a copy and delete operation for every child of the renamed folder. There is an exception though: this restriction only applies if the S3 storage is treated like a filesystem, where the keys are the path and the value is the file content. There are smarter ways to implement file systems on top of S3, but again: there is always a tradeoff.\nS3 has no rename Technically, S3 has no rename operation at all. By design, the location of the value is determined by the key, so it always has to do a copy and delete. Another example is the redis RENAME operation: while being specified as O(1) it executes an implicit DEL operation, so if the deleted key contains a very big value it may cause high latency\u0026hellip; Arbitrary metadata persistence In addition to well known metadata like name size and mtime, users might be able to add arbitrary metadata like tags, comments or dublin core. In POSIX filesystems this maps to extended attributes.\nGrant persistence The CS3 API uses grants to describe access permissions. Storage systems have a wide range of permissions granularity and not all grants may be supported by every storage driver. POSIX ACLs for example have no expiry. If the storage system does not support certain grant properties, e.g. expiry, then the storage driver may choose to implement them in a different way. Expiries could be persisted in a different way and checked periodically to remove the grants. Again: every decision is a tradeoff.\nTrash persistence After deleting a node the storage allows listing the deleted nodes and has an undo mechanism for them.\nVersions persistence A user can restore a previous version of a file.\nSnapshots are not versions Modern POSIX filesystems support snapshotting of volumes. This is different from keeping track of versions to a file or folder, but might be another implementation strategy for a storage driver to allow users to restore content. Activity History The storage keeps an activity history, tracking the different actions that have been performed. This does not only include file changes but also metadata changes like renames and permission changes.\nStorage drivers Reva currently has four storage driver implementations that can be used for storage providers an well as data providers.\nLocal Storage Driver The minimal storage driver for a POSIX based filesystem. It literally supports none of the storage aspect other than basic file tree management. Sharing can - to a degree - be implemented using POSIX ACLs.\n tree provided by a POSIX filesystem inefficient path by id lookup, currently uses the file path as id, so ids are not stable can store a uuid in extended attributes and use a cache to look them up, similar to the ownCloud driver no native ETag propagation, five options are available: built in propagation (changes bypassing ocis are not picked up until a rescan) built in inotify (requires 48 bytes of RAM per file, needs to keep track of every file and folder) external inotify (same RAM requirement, but could be triggered by external tools, e.g. a workflow engine) kernel audit log (use the linux kernel audit to capture file events on the storage and offload them to a queue) fuse filesystem overlay no subtree accounting, same options as for ETag propagation efficient rename arbitrary metadata using extended attributes grant persistence using POSIX ACLs requires an LDAP server to make guest accounts available in the OS oCIS has glauth which contains all users an existing LDAP could be used if guests ar provisioned in another way using extended attributes to implement expiry or sharing that does not require OS level integration fuse filesystem overlay no native trash could use the The FreeDesktop.org Trash specification fuse filesystem overlay no native versions, multiple options possible git for folders rcs for single files rsnapshot for hourly / daily / weekly / monthly backups \u0026hellip; but this is not versioning as known from oc10 design new freedesktop spec, basically what is done in oc10 without the limitations or borrow ideas from the freedesktop trash spec fuse filesystem overlay To provide the other storage aspects we plan to implement a FUSE overlay filesystem which will add the different aspects on top of local filesystems like ext4, btrfs or xfs. It should work on NFSv45 as well, although NFSv4 supports RichACLs and we will explore how to leverage them to implement sharing at a future date. The idea is to use the storages native capabilities to deliver the best user experience. But again: that means making the right tradeoffs.\nOwnCloud Storage Driver This is the current default storage driver. While it implements the file tree (using redis, including id based lookup), ETag propagation, trash, versions and sharing (including expiry) using the data directory layout of ownCloud 10 it has known limitations that cannot be fixed without changing the actual layout on disk.\nTo setup it up properly in a distributed fashion, the storage-home and the storage-oc need to share the same underlying FS. Their \u0026ldquo;data\u0026rdquo; counterparts also need access to the same shared FS. For a simple docker-compose setup, you can create a volume which will be used by the \u0026ldquo;storage-storage-home\u0026rdquo;, \u0026ldquo;storage-storage-home-data\u0026rdquo;, \u0026ldquo;storage-storage-oc\u0026rdquo; and \u0026ldquo;storage-storage-oc-data\u0026rdquo; containers. Using the owncloud/ocis docker image, the volume would need to be hooked in the /var/tmp/ocis folder inside the containers.\n tree provided by a POSIX filesystem file layout is mapped to the old ownCloud 10 layout the root of tree for a user on disk is prefixed with /path/to/data/\u0026lt;username\u0026gt;/files/ efficient path by id lookup all files and folders get assigned a uuid in the extended attributes when starting the storage provider it will walk all files to populate a redis kv store for uuid to path lookup slow to boot trees with lots of nodes build in ETag propagation ETags are calculated based on mtime mtime is propagated by the storage driver changes bypassing ocis are not picked up until a restart of the storage provider no subtree accounting, same options as for local storage efficient rename TODO update the kv store for path lookup, this is an O(n) operation arbitrary metadata using extended attributes grant persistence using custom ACLs that are stored as extended attributes a grant corresponds to one extended attribute of 40-100 bytes, effectively limiting the number of shares to ~100-40 extended attributes have varying limitations, based on the underlying filesystem the linux kernel imposes a limit of 255bytes per name and 64KiB per value ext2/3/4: total bytes for all attributes of a file is limited to 4KiB (a filesystem block) xfs: limit of 64KiB per value btrfs: total bytes used for the name, value, and implementation overhead bytes 16KiB (the default filesystem nodesize value) does not require OS level integration built in trash trashed files are moved to /path/to/data/\u0026lt;username\u0026gt;/files_trashbin/ trashed files are appended a timestamp .d\u0026lt;unixtime\u0026gt;, which breaks trashing of files that reach the filesystems specific name limit built in versions file versions are stored in /path/to/data/\u0026lt;username\u0026gt;/files_versions/ file versions are appended a timestamp .d\u0026lt;unixtime\u0026gt;, which breaks versioning of files that reach the filesystems specific name limit EOS Storage Driver The CERN eos storage has evolved with ownCloud and natively supports id based lookup, ETag propagation, subtree size accounting, sharing, trash and versions. To use it you need to change the default configuration of the storage storage-home command (or have a look at the Makefile ̀ eos-start` target):\nexport STORAGE_HOME_DRIVER=eos export STORAGE_DRIVER_EOS_NAMESPACE=/eos export STORAGE_DRIVER_EOS_MASTER_URL=\u0026#34;root://eos-mgm1.eoscluster.cern.ch:1094\u0026#34; export STORAGE_DRIVER_EOS_ENABLE_HOME=true export STORAGE_DRIVER_EOS_LAYOUT=\u0026#34;dockertest/{{.Username}}\u0026#34; Running it locally also requires the eos and xrootd binaries. Running it using make eos-start will use CentOS based containers that already have the necessary packages installed.\nPull requests to add explicit storage storage-(s3|custom|...) commands with working defaults are welcome. S3 Storage Driver A naive driver that treats the keys in an S3 capable storage as / delimited path names. While it does not support MOVE or ETag propagation it can be used to read and write files. Better integration with native capabilities like versioning is possible but depends on the Use Case. Several storage solutions that provide an S3 interface also support some form of notifications that can be used to implement ETag propagation.\nData Providers Clients using the CS3 API use an InitiateFileDownload and ]InitiateUpload](https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.InitiateFileUploadRequest) request at the storage gateway to obtain a URL endpoint that can be used to either GET the file content or upload content using the resumable tus.io protocol.\nThe data provider uses the same storage driver as the storage provider but can be scaled independently.\nThe dataprovider allows uploading the file to a quarantine area where further data analysis may happen before making the file accessible again. One use case for this is anti virus scanning for files coming from untrusted sources.\nFuture work FUSE overlay filesystem We are planning to further separate the concerns and use a local storage provider with a FUSE filesystem overlaying the actual POSIX storage that can be used to capture deletes and writes that might happen outside of ocis/reva.\nIt would allow us to extend the local storage driver with missing storage aspects while keeping a tree like filesystem that end users are used to see when sshing into the machine.\nUpload to Quarantine area Antivirus scanning of random files uploaded from untrusted sources and executing metadata extraction or thumbnail generation should happen in a sandboxed system to prevent malicious users from gaining any information about the system. By spawning a new container with access to only the uploaded data we can further limit the attack surface.\n"});index.add({'id':54,'href':'/ocis/development/testing/','title':"Testing",'parent':"Development",'content':" Testing with test suite in docker Run full test suite Run single feature test oCIS image to be tested (or: skip build and take existing image) Test log output Cleanup Testing with test suite natively installed Getting the tests Run ocis Run the acceptance tests use existing tests for BDD For running tests in the test suite you have two options. You may go the easy way and just run the test suite in docker. But for some tasks you could also need to install the test suite natively, which requires a little bit more setup since PHP and some dependencies need to be installed.\nBoth ways to run tests with the test suites are described here.\nTesting with test suite in docker Let\u0026rsquo;s see what is available. Invoke the following command from within the root of the oCIS repository.\nmake -C tests/acceptance/docker help Basically we have two sources for feature tests and test suites:\n oCIS feature test and test suites ownCloud feature tests and test suites At the moment both can be applied to oCIS since the api of oCIS is designed to be compatible to ownCloud.\nSince we have to offer an migration path to existing users of ownCloud, you can use your existing ownCloud as storage backend for oCIS. As another storage backend we offer oCIS native storage, also called \u0026ldquo;oCIS\u0026rdquo;. This stores files directly on disk. Which storage backend is used is also reflected in the tests, there are always different tests for oCIS storage and ownCloud storage.\nYou can invoke two types of test suite runs:\n run a full test suite, which consists of multiple feature tests run a single feature test Run full test suite The names of the full test suite make targets have the same naming as in the CI pipeline.\nFor example make -C tests/acceptance/docker localApiTests-apiOcisSpecific-ocis runs the same tests as the localApiTests-apiOcisSpecific-ocis CI pipeline, which runs the oCIS test suite \u0026ldquo;apiOcisSpecific\u0026rdquo; against an oCIS with oCIS storage.\nFor example make -C tests/acceptance/docker Core-API-Tests-owncloud-storage-3runs the same tests as the Core-API-Tests-owncloud-storage-3 CI pipline, which runs the third (out of ten) ownCloud test suite against an oCIS with owncloud storage.\nRun single feature test The single feature tests can also be run against the different storage backends. Therefore multiple make targets with the schema test--feature-exists. For selecting a single feature test you have to add an additional BEHAT_FEATURE=... parameter when invoking the make command:\nmake -C tests/acceptance/docker test-ocis-feature-ocis BEHAT_FEATURE=\u0026#39;tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsDELETEAuth.feature\u0026#39; This must be pointing to a valid feature definition.\noCIS image to be tested (or: skip build and take existing image) By default the tests will be run against docker image built from your current working state of the oCIS repository. For some purposes it might also be handy to use a oCIS image from Docker Hub. Therefore you can provide the optional flag OCIS_IMAGE_TAG=... which must contain an available docker tag of the owncloud/ocis registry on Docker Hub (eg. \u0026lsquo;latest\u0026rsquo;).\nmake -C tests/acceptance/docker localApiTests-apiOcisSpecific-ocis OCIS_IMAGE_TAG=latest Test log output While a test is running or when it is finished, you can attach to the logs generated by the tests.\nmake -C tests/acceptance/docker show-test-logs The log output is opened in less. You can navigate up and down with your cursors. By pressing \u0026ldquo;F\u0026rdquo; you can follow the latest line of the output. Cleanup During testing we start an redis and oCIS docker container. These will not be stopped automatically. You can stop them with:\nmake -C tests/acceptance/docker clean Testing with test suite natively installed We are using the ownCloud 10 acceptance test suite against oCIS.\nGetting the tests All you need to do to get the acceptance tests is check out the core repo:\ngit clone https://github.com/owncloud/core.git Run ocis To start ocis:\nPROXY_ENABLE_BASIC_AUTH=true bin/ocis server PROXY_ENABLE_BASIC_AUTH will allow the acceptance tests to make requests against the provisioning api (and other endpoints) using basic auth.\nRun the acceptance tests First we will need to clone the testing app in owncloud which contains the skeleton files required for running the tests. In the ownCloud 10 core clone the testing app with the following command:\ngit clone https://github.com/owncloud/testing apps/testing Then run the api acceptance tests with the following command from the root of the ownCloud 10 core repository:\nmake test-acceptance-api \\ TEST_SERVER_URL=https://localhost:9200 \\ TEST_OCIS=true \\ SKELETON_DIR=apps/testing/data/apiSkeleton \\ DELETE_USER_DATA_CMD=\u0026#39;rm -rf /var/tmp/ocis/storage/users/nodes/root/* /var/tmp/ocis/storage/users/nodes/*-*-*-*\u0026#39; \\ BEHAT_FILTER_TAGS=\u0026#39;~@notToImplementOnOCIS\u0026amp;\u0026amp;~@toImplementOnOCIS\u0026#39; Make sure to adjust the settings TEST_SERVER_URL and OCIS_REVA_DATA_ROOT according to your environment.\nThis will run all tests that are relevant to oCIS.\nTo run a single test add BEHAT_FEATURE=\u0026lt;feature file\u0026gt;\nuse existing tests for BDD As a lot of scenarios are written for oC10, we can use those tests for Behaviour driven development in ocis. Every scenario that does not work in oCIS with \u0026ldquo;owncloud\u0026rdquo; storage, is listed in tests/acceptance/expected-failures-on-OWNCLOUD-storage.txt with a link to the related issue. Every scenario that does not work in oCIS with \u0026ldquo;ocis\u0026rdquo; storage, is listed in tests/acceptance/expected-failures-on-OCIS-storage.txt with a link to the related issue.\nThose scenarios are run in the ordinary acceptance test pipeline in CI. The scenarios that fail are checked against the expected failures. If there are any differences then the CI pipeline fails. Similarly, scenarios that do not work in oCIS with EOS storage are listed in tests/acceptance/expected-failures-on-EOS-storage.txt. Additionally, some issues have scenarios that demonstrate the current buggy behaviour in ocis(reva). Those scenarios are in this ocis repository in tests/acceptance/features/apiOcisSpecific. Have a look into the documentation to understand why we are writing those tests.\nIf you want to work on a specific issue\n adjust the core commit id to the latest commit in core so that CI will run the latest test code and scenarios from core. For that change coreCommit in the config section:\nconfig = { 'apiTests': { 'coreBranch': 'master', 'coreCommit': 'a06b1bd5ba8e5244bfaf7fa04f441961e6fb0daa', 'numberOfParts': 6 } } locally run each of the tests marked with that issue in the expected failures file.\nE.g.:\nmake test-acceptance-api \\ TEST_SERVER_URL=https://localhost:9200 \\ TEST_OCIS=true \\ DELETE_USER_DATA_CMD=\u0026#39;rm -rf /var/tmp/ocis/storage/users/nodes/root/* /var/tmp/ocis/storage/users/nodes/*-*-*-*\u0026#39; \\ BEHAT_FEATURE=\u0026#39;tests/acceptance/features/apiComments/comments.feature:123\u0026#39; the tests will fail, try to understand how and why they are failing\n fix the code\n go back to 2. and repeat till the tests are passing.\n remove those tests from the expected failures file\n run each of the local tests that were demonstrating the buggy behavior. They should fail.\n delete each of the local tests that were demonstrating the buggy behavior.\n make a PR that has the fixed code, relevant lines removed from the expected failures file and bug demonstration tests deleted.\n "});index.add({'id':55,'href':'/clients/web/backend-oc10/','title':"Setup with ownCloud 10",'parent':"ownCloud Web",'content':" Prerequisites Setting up the ownCloud Server Adjusting config.php Setting up OAuth2 Setting up Web Running Web Running acceptance tests Prerequisites Decide on which host and port Web will be served, for example https://web-host:8300/web-path/. In this document, we will refer to the following:\n \u0026lt;web-url\u0026gt; as the full URL, for example https://web-host:8300/web-path/ \u0026lt;web-domain\u0026gt; as the protocol, domain and port, for example: https://web-host:8300 Setting up the ownCloud Server Make sure you have an ownCloud Server already installed.\nAdjusting config.php Add the following entries to config/config.php:\n tell ownCloud where Web is located: \u0026#39;web.baseUrl\u0026#39; =\u0026gt; \u0026#39;\u0026lt;web-url\u0026gt;\u0026#39;, add a CORS domain entry for Web in config.php: \u0026#39;cors.allowed-domains\u0026#39; =\u0026gt; [\u0026#39;\u0026lt;web-domain\u0026gt;\u0026#39;], optional: when developing against unstable APIs (technical preview), these need to be enabled in the server core: dav.enable.tech_preview =\u0026gt; true, Setting up OAuth2 To connect to the ownCloud server, it is necessary to set it up with OAuth2.\nInstall and enable the oauth2 app:\n% occ market:install oauth2 % occ app:enable oauth2 Login as administrator in the ownCloud Server web interface and go to the \u0026ldquo;User Authentication\u0026rdquo; section in the admin settings and add an entry for Web as follows:\n pick an arbitrary name for the client set the redirection URI to \u0026lt;web-url\u0026gt;/oidc-callback.html make sure to take note of the client identifier value as it will be needed in the Web configuration later on Setting up Web In the local Web checkout, copy the config.json.sample-oc10 file to config.json and adjust it accordingly:\n Set the \u0026ldquo;server\u0026rdquo; key to the URL of the ownCloud server including path. If the URL contains a path, please also add a trailing slash there. Set the \u0026ldquo;clientId\u0026rdquo; key to the client identifier as copied from the \u0026ldquo;User Authentication\u0026rdquo; section before. Adjust \u0026ldquo;url\u0026rdquo; and \u0026ldquo;authUrl\u0026rdquo; using the ownCloud server URL as prefix for both Optionally adjust \u0026ldquo;apps\u0026rdquo; for the list of apps to be loaded. These match the app names inside the \u0026ldquo;apps\u0026rdquo; folder. Running Web if running from source, make sure to build Web first run by launching a webpack dev server yarn watch-all when working on the Web code, webpack will recompile the code automatically Running acceptance tests For testing, please refer to the ownCloud 10 testing section\n"});index.add({'id':56,'href':'/ocis/development/extensions/','title':"Extensions",'parent':"Development",'content':" How to build and run ocis-simple Hacking ocis-hello Option 1: Hacking ownCloud Web (and ocis-web) The ownCloud design system External ownCloud Web apps ownCloud Web extension points ownCloud Web Files app API driven development How to build and run ocis-simple ocis uses build tags to build different flavors of the binary. In order to work on a new extension we are going to reduce the scope a little and use the simple tag. Let us begin by creating a dedicated folder:\nmkdir ocis-extension-workshop \u0026amp;\u0026amp; ocis-extension-workshop Following https://github.com/owncloud/ocis\ngit clone https://github.com/owncloud/ocis.git cd ocis TAGS=simple make generate build Q: Can you specify which version of ownCloud Web to use? A: No, the ownCloud Web that is used is compiled into the assets of ocis-web which is currently not automatically updated. We\u0026rsquo;ll see how to use a custom ownCloud Web later.\nbin/ocis server\nOpen the browser at http://localhost:9100\n You land on the login screen. click login You are redirected to an idp at http://localhost:9140/oauth2/auth with a login mask. Use einstein:relativityto login (one of the three demo users) You are redirected to http://localhost:9100/#/hello the ocis-hello app Replace World with something else and submit. You should see Hello %something else% Q: One of the required ports is already in use. Ocis seems to be trying to restart the service over and over. What gives? A: Using the ocis binary to start the server will case ocis to keep track of the different services and restart them in case they crash.\nHacking ocis-hello go back to the ocis-extension-workshop folder\ncd .. Following https://github.com/owncloud/ocis-hello\ngit clone https://github.com/owncloud/ocis-hello.git cd ocis-hello yarn install # this actually creates the assets yarn build # this will compile the assets into the binary make generate build Two options:\n run only the necessery services from ocis and ocis-hello independently compile ocis with the updated ocis-hello Option 1: get a list of ocis services:\nps ax | grep ocis Try to kill ocis hello\nRemember: for now, killing a service will cause ocis to restart it. This is subject to change.\nIn order to be able to manage the processes ourselves we need to start them independently:\nbin/ocis server starts the same services as:\nbin/ocis micro \u0026amp; bin/ocis web \u0026amp; bin/ocis hello \u0026amp; bin/ocis reva \u0026amp; Now we can kill the ocis hello and use our custom built ocis-hello binary:\ncd ../ocis-hello bin/ocis-hello server Hacking ownCloud Web (and ocis-web) Following https://github.com/owncloud/web we are going to build the current ownCloud Web\ngit clone https://github.com/owncloud/web.git cd web yarn install yarn dist We can tell ocis to use the compiled assets:\nKill ocis web, then use the compiled assets when starting ownCloud Web.\ncd ../ocis WEB_ASSET_PATH=\u0026#34;`pwd`/../web/dist\u0026#34; bin/ocis web The ownCloud design system The ownCloud design system contains a set of ownCloud vue components for ownCloud Web or your own ocis extensions. Please use it for a consistent look and feel.\nExternal ownCloud Web apps This is what hello is: copy and extend!\n ownCloud Web is configured using the config.json which is served by the ocis-web service (either bin/ocis web or bin/web server)\n point ocis-web to the web config which you extended with an external app: WEB_UI_CONFIG=\u0026quot;pwd/../web/config.json\u0026quot; ASSET_PATH=\u0026quot;pwd/../web/dist\u0026quot; bin/ocis web\n { \u0026#34;server\u0026#34;: \u0026#34;http://localhost:9140\u0026#34;, \u0026#34;theme\u0026#34;: \u0026#34;owncloud\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;0.1.0\u0026#34;, \u0026#34;openIdConnect\u0026#34;: { \u0026#34;metadata_url\u0026#34;: \u0026#34;http://localhost:9140/.well-known/openid-configuration\u0026#34;, \u0026#34;authority\u0026#34;: \u0026#34;http://localhost:9140\u0026#34;, \u0026#34;client_id\u0026#34;: \u0026#34;web\u0026#34;, \u0026#34;response_type\u0026#34;: \u0026#34;code\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;openid profile email\u0026#34; }, \u0026#34;apps\u0026#34;: [], \u0026#34;external_apps\u0026#34;: [ { \u0026#34;id\u0026#34;: \u0026#34;hello\u0026#34;, \u0026#34;path\u0026#34;: \u0026#34;http://localhost:9105/hello.js\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;url\u0026#34;: \u0026#34;http://localhost:9105\u0026#34; } }, { \u0026#34;id\u0026#34;: \u0026#34;myapp\u0026#34;, \u0026#34;path\u0026#34;: \u0026#34;http://localhost:6789/superapp.js\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;backend\u0026#34;: \u0026#34;http://someserver:1234\u0026#34;, \u0026#34;myconfig\u0026#34;: \u0026#34;is awesome\u0026#34; } } ] } ownCloud Web extension points For an up to date list check out the ownCloud Web documentation. Several ones available:\nownCloud Web App switcher (defined in config.json) App container (loads UI of your extension) Files app File action Create new file action Sidebar Quick access for sidebar inside of file actions (in the file row) Example of a file action in the app.js:\nconst appInfo = { name: \u0026#39;MarkdownEditor\u0026#39;, id: \u0026#39;markdown-editor\u0026#39;, icon: \u0026#39;text\u0026#39;, isFileEditor: true, extensions: [{ extension: \u0026#39;txt\u0026#39;, newFileMenu: { menuTitle ($gettext) { return $gettext(\u0026#39;Create new plain text file…\u0026#39;) } } }, { extension: \u0026#39;md\u0026#39;, newFileMenu: { menuTitle ($gettext) { return $gettext(\u0026#39;Create new mark-down file…\u0026#39;) } } }] } For the side bar have a look at the files app, defaults.js \u0026amp; fileSideBars\nAPI driven development Until now we only had a look at the ui and how the extensions are managed on the cli. But how do apps actually talk to the server?\nShort answer: any way you like\nLong answer: micro and ocis-hello follow a protocol driven development:\n specify the API using protobuf\n generate client and server code\n evolve based on the protocol\n CS3 api uses protobuf as well and uses GRPC\n ocis uses go-micro, which provides http and grpc gateways\n the gateways and protocols are optional\n owncloud and kopano are looking into a MS graph like api to handle ownCloud Web requests.\n they might be about user, contacrs, calendars \u0026hellip; which is covered by the graph api we want to integrate with eg. kopano and provide a commen api (file sync and share is covered as well) as an example for protobuf take a look at ocis-hello\n "});index.add({'id':57,'href':'/ocis/storage-backends/','title':"Storage backends",'parent':"oCIS - ownCloud Infinite Scale",'content':""});index.add({'id':58,'href':'/extensions/onlyoffice/license/','title':"License",'parent':"OnlyOffice",'content':"This project is licensed under the Apache 2.0 license. For the license of the used libraries you have to check the respective sources.\n"});index.add({'id':59,'href':'/extensions/web/releasing/','title':"Releasing",'parent':"ownCloud Web",'content':" Releasing Package Hierarchy Prerequisites Updating ocis-web Releasing The next generation Web Frontend is shipped as an oCIS Extension. The ocis-web extension is also embedded in the single binary and part of the ocis server command.\nTo update this package within all the deliveries, we need to update the package in the following chain from the bottom to the top.\nPackage Hierarchy ocis ocis-web ocis-pkg ownCloud Web Prerequisites Before updating the assets, make sure that ownCloud Web has been released first and take note of its release tag name.\nUpdating ocis-web Create a branch release-$version. in https://github.com/owncloud/ocis Create a Folder in changelog for the release version and date mkdir $major.$minor.$patchVersion_YYYY-MM-DD. Move all changelog items from the changelog/unreleased/ folder to the $major.$minor.$patchVersion_YYYY-MM-DD folder. Update the go module ocis-pkg to the latest version https://blog.golang.org/using-go-modules . Update the ownCloud Web asset by adjusting the value of WEB_ASSETS_VERSION at the top of the Makefile and specify the tag name of the latest ownCloud Web release. Run make clean generate. Create a changelog item for the update in the changelog/$major.$minor.$patchVersion_YYYY-MM-DD folder. Commit your changes. After merging, wait for the CI to run on the merge commit. Go to \u0026ldquo;Releases\u0026rdquo; in GH click \u0026ldquo;Draft a new Release\u0026rdquo;. Use v$major.$minor.$patch as a tag (the v prefix is important) and publish it. The tag and the Release artifacts will be created automatically. "});index.add({'id':60,'href':'/ocis/flow-docs/login-flow/','title':"Login Flow",'parent':"Flow documentation",'content':"Login Flow The following sequence diagram describes the openid connect auth code flow. The eight numbered steps and notes correspond to the openid connect auth code flow steps. Example requests are based on the spec as well.:\n document.addEventListener(\"DOMContentLoaded\", function(event) { mermaid.initialize({ flowchart: { useMaxWidth: true } }); }); sequenceDiagram %% we have comments!! \\o/ %% this documents the login workflow %% examples taken from the oidc spec https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth %% TODO add PKCE, see https://developer.okta.com/blog/2019/08/22/okta-authjs-pkce#use-pkce-to-make-your-apps-more-secure participant user as User participant client as Client participant proxy as ocis-proxy participant idp as IdP participant glauth as ocis-glauth participant graph as ocis-graph participant accounts as ocis-accounts participant ldap as external LDAP server user-+client: What is the content of my home? client-+proxy: PROPFIND no (or expired) auth Note over client,proxy: ocis needs to know the IdP that is\nused to authenticate users. The\nproxy will redirect unauthenticated\nrequests to that IdP. proxy---client: 302 Found Note over client, idp: HTTP/1.1 302 Found\nLocation: https://server.example.com/authorize?\nresponse_type=code\u0026\nscope=openid%20profile%20email\n\u0026client_id=s6BhdRkqt3\n\u0026state=af0ifjsldkj\n\u0026redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb Note over client, idp: We should follow the OpenID Connect Discovery protocol Note over client, idp: Clients might fall back to the ocis server if the discovery failed.\nWe can provide a webfinger endpoint there to let guests use an idp\nthat is backed by the accounts service. Note over client, idp: For now, clients can only handle one IdP, which is configured in ocis. client--client: 1. Client prepares an Authentication Request\ncontaining the desired request parameters. client-+idp: 2. Client sends the request to the Authorization Server. Note over client, idp: GET /authorize?\nresponse_type=code\n\u0026scope=openid%20profile%20email\n\u0026client_id=s6BhdRkqt3\n\u0026state=af0ifjsldkj\n\u0026redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1\nHost: server.example.com Note over user, idp: 3. Authorization Server Authenticates the End-User. Note over idp,ldap: Either an IdP already exists or a new one is introduced. Since we are not yet using oidc discovery we can only use one IdP. alt all users managed by konnectd/ocis idp-+glauth: LDAP query/bind glauth-+graph: GET user with Basic Auth\nGraphAPI graph-+accounts: internal GRPC accounts---graph: response graph---glauth: OData response glauth---idp: LDAP result Note over accounts,ldap: In case internal users are managed\nin an external ldap they have to be\nsynced to the accounts service to\nshow up as recipients during sharing. else all users authenticated by an external idp idp-+ldap: LDAP query/bind ldap---idp: LDAP result alt guest accounts managed in ocis / lookup using glauth proxy: Note over idp,glauth: Idp is configured to use glauth as a\nsecond ldap server. idp-+glauth: LDAP query/bind glauth-+graph: GET user with Basic Auth\nGraphAPI graph-+accounts: internal GRPC accounts---graph: response graph---glauth: OData response glauth---idp: LDAP result else guest account provisioned by other means Note over accounts, ldap: In case guest accounts are managed\nin an existing ldap they need to be\nsynced to the accounts service to\nbe able to login and show up as\nrecipients during sharing. end end Note over user, idp: 4. Authorization Server obtains End-User Consent/Authorization. idp---client: 5. Authorization Server sends the End-User back\nto the Client with an Authorization Code. Note over client, idp: HTTP/1.1 302 Found\nLocation: https://client.example.org/cb?\ncode=SplxlOBeZQQYbYS6WxSbIA\u0026state=af0ifjsldkj client-+idp: 6. Client requests a response using the\nAuthorization Code at the Token Endpoint. Note over client, idp: POST /token HTTP/1.1\nHost: server.example.com\nContent-Type: application/x-www-form-urlencoded\ngrant_type=authorization_code\u0026code=SplxlOBeZQQYbYS6WxSbIA\n\u0026redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb idp---client: 7. Client receives a response that contains an\nID Token and Access Token in the response body. Note over client, idp: HTTP/1.1 200 OK\nContent-Type: application/json\nCache-Control: no-store\nPragma: no-cache\n{\n\"access_token\": \"SlAV32hkKG\",\n\"token_type\": \"Bearer\",\n\"refresh_token\": \"8xLOxBtZp8\",\n\"expires_in\": 3600,\n\"id_token\": \"a ... b.c ... d.e ... f\" // must be a JWT\n} client--client: 8. Client validates the ID token and\nretrieves the End-User's Subject Identifier. client-+proxy: PROPFIND With access token proxy---client: 207 Multi-Status client---user: List of Files X, Y, Z ... "});index.add({'id':61,'href':'/ocis/metrics/','title':"Metrics",'parent':"oCIS - ownCloud Infinite Scale",'content':"Metrics This service provides some Prometheus metrics through the debug endpoint, you can optionally secure the metrics endpoint by some random token, which got to be configured through one of the flag --debug-token or the environment variable OCIS_DEBUG_TOKEN mentioned above. By default the metrics endpoint is bound to http://0.0.0.0:8001/metrics.\n go_gc_duration_seconds A summary of the GC invocation durations go_gc_duration_seconds_sum A summary of the GC invocation durations go_gc_duration_seconds_count A summary of the GC invocation durations go_goroutines Number of goroutines that currently exist go_info Information about the Go environment go_memstats_alloc_bytes Number of bytes allocated and still in use go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table go_memstats_frees_total Total number of frees go_memstats_gc_cpu_fraction The fraction of this program\u0026rsquo;s available CPU time used by the GC since the program started go_memstats_gc_sys_bytes Number of bytes used for garbage collection system metadata go_memstats_heap_alloc_bytes Number of heap bytes allocated and still in use go_memstats_heap_idle_bytes Number of heap bytes waiting to be used go_memstats_heap_inuse_bytes Number of heap bytes that are in use go_memstats_heap_objects Number of allocated objects go_memstats_heap_released_bytes Number of heap bytes released to OS go_memstats_heap_sys_bytes Number of heap bytes obtained from system go_memstats_last_gc_time_seconds Number of seconds since 1970 of last garbage collection go_memstats_lookups_total Total number of pointer lookups go_memstats_mallocs_total Total number of mallocs go_memstats_mcache_inuse_bytes Number of bytes in use by mcache structures go_memstats_mcache_sys_bytes Number of bytes used for mcache structures obtained from system go_memstats_mspan_inuse_bytes Number of bytes in use by mspan structures go_memstats_mspan_sys_bytes Number of bytes used for mspan structures obtained from system go_memstats_next_gc_bytes Number of heap bytes when next garbage collection will take place go_memstats_other_sys_bytes Number of bytes used for other system allocations go_memstats_stack_inuse_bytes Number of bytes in use by the stack allocator go_memstats_stack_sys_bytes Number of bytes obtained from system for stack allocator go_memstats_sys_bytes Number of bytes obtained from system go_threads Number of OS threads created promhttp_metric_handler_requests_in_flight Current number of scrapes being served promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code "});index.add({'id':62,'href':'/ocis/flow-docs/request-flow/','title':"Request Flow",'parent':"Flow documentation",'content':"Request Flow The following sequence diagram describes the general request flow. It shows where account provisioning and token minting are happening:\n document.addEventListener(\"DOMContentLoaded\", function(event) { mermaid.initialize({ flowchart: { useMaxWidth: true } }); }); sequenceDiagram %% we have comments!! \\o/ participant user as User participant client as Client participant proxy as ocis-proxy participant idp as IdP participant accounts as ocis-accounts participant ldap as corporate LDAP server user-+client: What is the content of my home? client-+proxy: PROPFIND Bearer auth using oidc auth token Note over client,proxy: What is in a bearer token? The spec recommends opaque tokens. Treat it as random byte noise. Note over client,proxy: the proxy MUST authenticate users using ocis-accounts because it needs to decide where to send the request %% Mention introspection endpoint for opaque tokens %% konnectd uses jwt, so we can save a request %% either way the token can be used to look up the sub and iss of the user %% or is token check enough? proxy-+idp: GET /userinfo alt userinfo succeeds idp--proxy: 200 OK Note over proxy,accounts: Content-Type: application/json\n{\n\"sub\": \"248289761001\",\n\"name\": \"Jane Doe\",\n\"given_name\": \"Jane\",\n\"family_name\": \"Doe\",\n\"preferred_username\": \"j.doe\",\n\"email\": \"janedoe@example.com\",\n\"picture\": \"http://example.com/janedoe/me.jpg\"\n} %% see: https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse else userinfo fails idp---proxy: 401 Unauthorized Note over proxy,accounts: WWW-Authenticate: error=\"invalid_token\",\nerror_description=\"The Access Token expired\" proxy--client: 401 Unauthorized or 302 Found with redirect to idp Note over client: start at login flow\nor refresh the token end proxy-+accounts: TODO API call to exchange sub@iss with account UUID Note over proxy,accounts: does not autoprovision users. They are explicitly provsioned later. alt account exists or has been migrated accounts--proxy: existing account UUID else account does not exist opt oc10 endpoint is configured Note over proxy,oc10: Check if user exists in oc10 proxy-+oc10: GET /apps/graphapi/v1.0/users/\u0026lt;uuid\u0026gt; opt user exists in oc10 oc10---proxy: 200 %% TODO auth using internal token proxy-+oc10: PROPFIND Note over proxy,oc10: forward existing bearer auth oc10---proxy: Multistatus response proxy--client: Multistatus response client--user: List of Files X, Y, Z ... end end Note over proxy,accounts: provision a new account including displayname, email and sub@iss TODO only if the user is allowed to login, based on group membership in the ldap server proxy-proxy: generate new uuid proxy-+accounts: TODO create account with new generated uuid accounts---proxy: OK / error else account has been disabled accounts---proxy: account is disabled proxy--client: 401 Unauthorized or 302 Found with redirect to idp Note over client: start at login flow\nor refresh the token end proxy-proxy: store uuid in context %% what if oc10 does not support a certain request / API proxy-proxy: mint an internal jwt that includes the UUID and username using revas `x-access-token` header proxy-+reva: PROPFIND Token auth using internal JWT reva---proxy: Multistatus response proxy---client: Multistatus response client---user: List of Files X, Y, Z ... "});index.add({'id':63,'href':'/ocis/flow-docs/public-upload-flow/','title':"Public upload Flow",'parent':"Flow documentation",'content':"Public Upload flow The following diagram describes the flow of requests:\nocis-reva sharing\nREVA_SHARING_ADDR = 0.0.0.0:9150\nocis-reva sharing...ocis-reva frontend\nREVA_FRONTEND_ADDR = 0.0.0.0:9140\nREVA_GATEWAY_URL = ocis:9142\nocis-reva frontend...ocis-proxy\nPROXY_HTTP_ADDR = 0.0.0.0:9200\nocis-proxy...2  POST http://ocis:9140/remote.php/dav/files/einstein/2 POST http:/...ocdav\nprefix = \"\"\ntimeout = 86400\nocdav...datagateway\nprefix = \"data\"\ntimeout = 86400\ndatagateway...client\nclient\u0026#xa;22  PATCH https://oc.example.org/data/{token}\nTus-Resumable: 1.0.022 PATCH http...ocis-reva gateway\nREVA_GATEWAY_ADDR = 0.0.0.0:9142\nocis-reva gateway...storage-registry\nstorage-registry\u0026#xa;Expose: trueExpose: true24  PATCH http://ocis:9156/data/u-u-i-d24 PATCH http...4  GetStorageProvider\n(ShareReference)4 GetStorageP...5  ProviderInfo5 ProviderInfostorageprovider\nREVA_STORAGE_HOME_ADDR = 0.0.0.0:9154\nREVA_STORAGE_HOME_DRIVER = eoshome\nREVA_STORAGE_HOME_EXPOSE_DATA_SERVER = false\nREVA_STORAGE_HOME_DATA_SERVER_URL =\nhttp://ocis:9156/data\nstorageprovider...Expose: falseExpose: false6  InitiateFileUpload\n(ShareReference)6 InitiateFil...EOSEOS15  WriteFile(upload info)15 WriteFile(...7  GetPublicShare7 GetPublicSh...19  UploadEndpoint\nhttps://oc.example.org/data/{token}19 UploadEndp...20  201 Created\nLocation: https://oc.example.org/data/{token}20 201 Create...21  201 Created\nLocation: https://oc.example.org/data/{token}21 201 Create...1 POST https://oc.example.org/remote.php/dav/files/einstein/\nUpload-Length: 100\nTus-Resumable: 1.0.0\nUpload-Metadata: filename d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg==,dir d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg==1 POST https:...23  PATCH http://ocis:9140/data/{token}\nTus-Resumable: 1.0.023 PATCH http...3  InitiateFileUpload3 InitiateFil...25  Write(bytes)25 Write(byte...26  204 No Content26 204 No Con...27  204 No Content27 204 No Con...28  204 No Content28 204 No Con...publicstorageprovider\nexpose-data-server = true\npublicstorageprovider...publicshareprovider\npublicshareprovider\u0026#xa;8  GetPublicShare8 GetPublicSh...9  PublicShare9 PublicShare10  PublicShare10 PublicShare11  InitiateFileUpload(TargetReference)11 InitiateFi...12  GetStorageProvider\n(TargetReference)12 GetStorage...13  ProviderInfo13 ProviderIn...14  InitiateFileUpload(TargetReference)14 InitiateFi...16  UploadEndpoint\nhttp://ocis:9156/data/u-u-i-d\nExpose: false16 UploadEndp...17 UploadEndpoint\nhttps://oc.example.org/data/\ntoken: sign(http://ocis:9156/data/u-u-i-d)17 UploadEndp...18  UploadEndpoint\nhttps://oc.example.org/data/{token}\nExpose: true18 UploadEndp...gateway\nREVA_TRANSFER_EXPIRES = 86400\nREVA_FRONTEND_URL =\nhttps://oc.example.org\nREVA_DATAGATEWAY_URL =\nhttps://oc.example.org/data\n\ngateway...When a storage provider\nsets the Expose flag of an Upload/Download Endpoint to false the gateway will wrap the url in a JWT and return the URL of the datagateway along with a transfer-token.When a storage provider...dataprovider\nREVA_STORAGE_HOME_DATA_ADDR = 0.0.0.0:9156\nREVA_STORAGE_HOME_DATA_DRIVER = eoshome\ndataprovider...GOAL: transfer bytes from the client up here ...GOAL: tran...... to the storage system somewhere down here... to the storage syst...Viewer does not support full SVG 1.1 "});index.add({'id':64,'href':'/extensions/storage/updating/','title':"Updating reva",'parent':"Storage",'content':" Updating reva Updating reva Run go get github.com/cs3org/reva@master Create a changelog entry containing changes that were done in reva Create a Pull Request to ocis-reva master with those changes If test issues appear, you might need to adjust the tests After the PR is merged, consider doing a release of the storage submodule "});index.add({'id':65,'href':'/extensions/settings/bundles/','title':"Settings Bundles",'parent':"Settings",'content':"A Settings Bundle is a collection of settings, uniquely identified by the key of the extension registering the bundle and the key of the bundle itself. It\u0026rsquo;s purpose is to let oCIS extensions define settings and make them available to users. They are dynamically rendered into forms, available in the frontend.\nAs of now we support five different types of settings:\n boolean integer string single choice list of integers or strings multiple choice list of integers or strings Each Setting is uniquely identified by a key within the bundle. Some attributes depend on the chosen type of setting. Through the information provided with the attributes of the setting, the settings frontend dynamically renders form elements, allowing users to change their settings individually.\nExample { \u0026#34;identifier\u0026#34;: { \u0026#34;extension\u0026#34;: \u0026#34;ocis-accounts\u0026#34;, \u0026#34;bundleKey\u0026#34;: \u0026#34;profile\u0026#34; }, \u0026#34;displayName\u0026#34;: \u0026#34;Profile\u0026#34;, \u0026#34;settings\u0026#34;: [ { \u0026#34;settingKey\u0026#34;: \u0026#34;lastname\u0026#34;, \u0026#34;displayName\u0026#34;: \u0026#34;Lastname\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Input for lastname\u0026#34;, \u0026#34;stringValue\u0026#34;: { \u0026#34;placeholder\u0026#34;: \u0026#34;Set lastname\u0026#34; } }, { \u0026#34;settingKey\u0026#34;: \u0026#34;age\u0026#34;, \u0026#34;displayName\u0026#34;: \u0026#34;Age\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Input for age\u0026#34;, \u0026#34;intValue\u0026#34;: { \u0026#34;min\u0026#34;: \u0026#34;16\u0026#34;, \u0026#34;max\u0026#34;: \u0026#34;200\u0026#34;, \u0026#34;step\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;placeholder\u0026#34;: \u0026#34;Set age\u0026#34; } }, { \u0026#34;settingKey\u0026#34;: \u0026#34;timezone\u0026#34;, \u0026#34;displayName\u0026#34;: \u0026#34;Timezone\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;User timezone\u0026#34;, \u0026#34;singleChoiceValue\u0026#34;: { \u0026#34;options\u0026#34;: [ { \u0026#34;stringValue\u0026#34;: \u0026#34;Europe/Berlin\u0026#34;, \u0026#34;displayValue\u0026#34;: \u0026#34;Europe/Berlin\u0026#34; }, { \u0026#34;stringValue\u0026#34;: \u0026#34;Asia/Kathmandu\u0026#34;, \u0026#34;displayValue\u0026#34;: \u0026#34;Asia/Kathmandu\u0026#34; } ] } } ] } "});index.add({'id':66,'href':'/clients/web/backend-ocis/','title':"Setup with OCIS",'parent':"ownCloud Web",'content':" Setting up OCIS services Setting up Web Setting up ocis-web service Running Web Running acceptance tests Setting up OCIS services Setup OCIS by cloning the ocis repository and following the setup instructions there. Do not start the whole server but run ./bin/ocis --log-level debug $EXTENSION for all the existing extensions except the web service. A list of extensions can be found by running ./bin/ocis without arguments and looking at the \u0026ldquo;Extensions\u0026rdquo; section. Setting up Web Please note that config.json is generated by ocis-web so there is no need to create one. If you want to provide a config.json file, you can do so by starting ocis with WEB_UI_CONFIG=/path/to/config.json Setting up ocis-web service Clone the ocis-web repository and follow the setup instructions there. Set export WEB_ASSET_PATH=$WEB_CHECKOUT/dist and replace with the path to the local git checkout of the Web repository Run \u0026ldquo;ocis-web\u0026rdquo;: ./bin/ocis-web --log-level debug server Running Web in the Web checkout folder, run yarn watch-all-ocis open https://localhost:9200 and accept the certificate. when signing in, use one of the available test users whenever code changes are made, you need to manually reload the browser page (no hot reload) Running acceptance tests For testing, please refer to the OCIS testing section\n"});index.add({'id':67,'href':'/ocis/development/debugging/','title':"Debugging",'parent':"Development",'content':" Debugging Start ocis Use the debug binary and attach to the process as needed Start all services independently to replace one of them with a debug process Gather error messages Managing dependencies and testing changes Debugging As a single binary for easy deployment running ocis server just forks itself to start all the services, which makes debugging those processes a little harder.\nUltimately, we want to be able to stop a single service using eg. ocis kill web so that you can start the service you want to debug in debug mode. We need to change the way we fork processes though, otherwise the runtime will automatically restart a service if killed.\nStart ocis For debugging there are two workflows that work well, depending on your preferences.\nUse the debug binary and attach to the process as needed Run the debug binary with OCIS_LOG_LEVEL=debug bin/ocis-debug server and then find the service you want to debug using:\n# ps ax | grep ocis 12837 pts/1 Sl+ 0:00 bin/ocis-debug server 12845 pts/1 Sl 0:00 bin/ocis-debug graph 12847 pts/1 Sl 0:00 bin/ocis-debug reva-auth-bearer 12848 pts/1 Sl 0:00 bin/ocis-debug graph-explorer 12849 pts/1 Sl 0:00 bin/ocis-debug ocs 12850 pts/1 Sl 0:00 bin/ocis-debug reva-storage-oc-data 12863 pts/1 Sl 0:00 bin/ocis-debug webdav 12874 pts/1 Sl 0:00 bin/ocis-debug reva-frontend 12897 pts/1 Sl 0:00 bin/ocis-debug reva-sharing 12905 pts/1 Sl 0:00 bin/ocis-debug reva-gateway 12912 pts/1 Sl 0:00 bin/ocis-debug reva-storage-home 12920 pts/1 Sl 0:00 bin/ocis-debug reva-users 12929 pts/1 Sl 0:00 bin/ocis-debug glauth 12940 pts/1 Sl 0:00 bin/ocis-debug reva-storage-home-data 12948 pts/1 Sl 0:00 bin/ocis-debug konnectd 12952 pts/1 Sl 0:00 bin/ocis-debug proxy 12961 pts/1 Sl 0:00 bin/ocis-debug thumbnails 12971 pts/1 Sl 0:00 bin/ocis-debug reva-storage-oc 12981 pts/1 Sl 0:00 bin/ocis-debug web 12993 pts/1 Sl 0:00 bin/ocis-debug api 12998 pts/1 Sl 0:00 bin/ocis-debug registry 13004 pts/1 Sl 0:00 bin/ocis-debug web 13015 pts/1 Sl 0:00 bin/ocis-debug reva-auth-basic Then you can set a breakpoint in the service you need and attach to the process via processid. To debug the reva-sharing service the VS Code launch.json would look like this:\n{ \u0026#34;version\u0026#34;: \u0026#34;0.2.0\u0026#34;, \u0026#34;configurations\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;ocis attach\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;go\u0026#34;, \u0026#34;request\u0026#34;: \u0026#34;attach\u0026#34;, \u0026#34;mode\u0026#34;: \u0026#34;local\u0026#34;, \u0026#34;processId\u0026#34;: 12897 } ] } Start all services independently to replace one of them with a debug process You can use this ./ocis.sh script to start all services independently, so they don\u0026rsquo;t get restrarted by the runtime when you kill them: #/bin/sh LOG_LEVEL=\u0026#34;debug\u0026#34; bin/ocis --log-level=$LOG_LEVEL micro \u0026amp; bin/ocis --log-level=$LOG_LEVEL glauth \u0026amp; bin/ocis --log-level=$LOG_LEVEL graph-explorer \u0026amp; bin/ocis --log-level=$LOG_LEVEL graph \u0026amp; #bin/ocis --log-level=$LOG_LEVEL hello \u0026amp; bin/ocis --log-level=$LOG_LEVEL konnectd \u0026amp; #bin/ocis --log-level=$LOG_LEVEL ocs \u0026amp; bin/ocis --log-level=$LOG_LEVEL web \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-auth-basic \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-auth-bearer \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-frontend \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-gateway \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-sharing \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-storage-home \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-storage-home-data \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-storage-oc \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-storage-oc-data \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-storage-root \u0026amp; bin/ocis --log-level=$LOG_LEVEL reva-users \u0026amp; #bin/ocis --log-level=$LOG_LEVEL webdav bin/ocis --log-level=$LOG_LEVEL proxy \u0026amp; Get the list of running processes: # ps ax | grep ocis 12837 pts/1 Sl+ 0:00 bin/ocis-debug server 12845 pts/1 Sl 0:00 bin/ocis-debug graph 12847 pts/1 Sl 0:00 bin/ocis-debug reva-auth-bearer 12848 pts/1 Sl 0:00 bin/ocis-debug graph-explorer 12849 pts/1 Sl 0:00 bin/ocis-debug ocs 12850 pts/1 Sl 0:00 bin/ocis-debug reva-storage-oc-data 12863 pts/1 Sl 0:00 bin/ocis-debug webdav 12874 pts/1 Sl 0:00 bin/ocis-debug reva-frontend 12897 pts/1 Sl 0:00 bin/ocis-debug reva-sharing 12905 pts/1 Sl 0:00 bin/ocis-debug reva-gateway 12912 pts/1 Sl 0:00 bin/ocis-debug reva-storage-home 12920 pts/1 Sl 0:00 bin/ocis-debug reva-users 12929 pts/1 Sl 0:00 bin/ocis-debug glauth 12940 pts/1 Sl 0:00 bin/ocis-debug reva-storage-home-data 12948 pts/1 Sl 0:00 bin/ocis-debug konnectd 12952 pts/1 Sl 0:00 bin/ocis-debug proxy 12961 pts/1 Sl 0:00 bin/ocis-debug thumbnails 12971 pts/1 Sl 0:00 bin/ocis-debug reva-storage-oc 12981 pts/1 Sl 0:00 bin/ocis-debug web 12993 pts/1 Sl 0:00 bin/ocis-debug api 12998 pts/1 Sl 0:00 bin/ocis-debug registry 13004 pts/1 Sl 0:00 bin/ocis-debug web 13015 pts/1 Sl 0:00 bin/ocis-debug reva-auth-basic Kill the service you want to start in debug mode: # kill 17628 Start the service you are interested in in debug mode. When using make to build the binary there is already a bin/ocis-debug binary for you. When running an IDE tell it which service to start by providing the corresponding sub command, eg. bin\\ocis-debug reva-frontend. Gather error messages We recommend you collect all related information in a single file or in a github issue. Let us start with an error that pops up in the Web UI:\n Error while sharing. error sending a grpc stat request\n This popped up when I tried to add marie as a collaborator in ownCloud Web. That triggers a request to the server which I copied as curl. We can strip a lot of headers and the gist of it is:\n# curl \u0026#39;https://localhost:9200/ocs/v1.php/apps/files_sharing/api/v1/shares\u0026#39; -d \u0026#39;shareType=0\u0026amp;shareWith=marie\u0026amp;path=%2FNeuer+Ordner\u0026amp;permissions=1\u0026#39; -u einstein:relativity -k -v | xmllint -format - [... headers ...] \u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;UTF-8\u0026#34;?\u0026gt; \u0026lt;ocs\u0026gt; \u0026lt;meta\u0026gt; \u0026lt;status\u0026gt;error\u0026lt;/status\u0026gt; \u0026lt;statuscode\u0026gt;998\u0026lt;/statuscode\u0026gt; \u0026lt;message\u0026gt;error sending a grpc stat request\u0026lt;/message\u0026gt; \u0026lt;/meta\u0026gt; \u0026lt;/ocs\u0026gt; The username and password only work when basic auth is available. Otherwise you have to obtain a bearer token, eg. by grabbing it from the browser. TODO add ocis cli tool to obtain a bearer token. We also have a few interesting log entries:\n0:43PM INF home/jfd/go/pkg/mod/github.com/cs3org/reva@v0.0.2-0.20200318111623-a2f97d4aa741/internal/grpc/interceptors/log/log.go:69 \u0026gt; unary code=OK end=\u0026#34;18/Mar/2020:22:43:40 +0100\u0026#34; from=tcp://[::1]:44078 pid=17836 pkg=rgrpc start=\u0026#34;18/Mar/2020:22:43:40 +0100\u0026#34; time_ns=95841 traceid=b4eb9a9f45921f7d3632523ca32a42b0 uri=/cs3.storage.registry.v1beta1.RegistryAPI/GetStorageProvider user-agent=grpc-go/1.26.0 10:43PM ERR home/jfd/go/pkg/mod/github.com/cs3org/reva@v0.0.2-0.20200318111623-a2f97d4aa741/internal/grpc/interceptors/log/log.go:69 \u0026gt; unary code=Unknown end=\u0026#34;18/Mar/2020:22:43:40 +0100\u0026#34; from=tcp://[::1]:43910 pid=17836 pkg=rgrpc start=\u0026#34;18/Mar/2020:22:43:40 +0100\u0026#34; time_ns=586115 traceid=b4eb9a9f45921f7d3632523ca32a42b0 uri=/cs3.gateway.v1beta1.GatewayAPI/Stat user-agent=grpc-go/1.26.0 10:43PM ERR home/jfd/go/pkg/mod/github.com/cs3org/reva@v0.0.2-0.20200318111623-a2f97d4aa741/internal/http/services/owncloud/ocs/reqres.go:94 \u0026gt; error sending a grpc stat request error=\u0026#34;rpc error: code = Unknown desc = gateway: error calling Stat: rpc error: code = Unavailable desc = connection error: desc = \\\u0026#34;transport: Error while dialing dial tcp [::1]:9152: connect: connection refused\\\u0026#34;\u0026#34; pid=17832 pkg=rhttp traceid=b4eb9a9f45921f7d3632523ca32a42b0 TODO return the trace id in the response so we can correlate easier. For reva tracked in https://github.com/cs3org/reva/issues/587 The last line gives us a hint where the log message originated: .../github.com/cs3org/reva@v0.0.2-0.20200318111623-a2f97d4aa741/internal/http/services/owncloud/ocs/reqres.go:94. Which looks like this:\n89: // WriteOCSResponse handles writing ocs responses in json and xml 90: func WriteOCSResponse(w http.ResponseWriter, r *http.Request, res *Response, err error) { 91: var encoded []byte 92: 93: if err != nil { 94: appctx.GetLogger(r.Context()).Error().Err(err).Msg(res.OCS.Meta.Message) 95: } Ok, so this seems to be a convenience method that is called from multiple places an also handles errors. Unfortunately, this hides the actual source of the error. We could set a breakpoint in line 94 and reproduce the problem, which can be a lot harder than just clicking the share button or sending a curl request again. So let us see what else the log tells us.\nThe previous line tells us that a Stat request failed: uri=/cs3.gateway.v1beta1.GatewayAPI/Stat. This time the line is written by the grpc log interceptor. What else is there?\nThe first line tells us that looking up the responsible storage provider seems to have succeeded: uri=/cs3.storage.registry.v1beta1.RegistryAPI/GetStorageProvider.\nAt this point it your familiarity with the codebase starts to become a factor. If you are new you should probably go back to setting a break point on the log line and check the stack trace.\nDebug wherever the call trace leads you to \u0026hellip; good luck!\nManaging dependencies and testing changes You can either run and manage the services independently, or you can update the go.mod file and replace dependencies with your local version.\nTo debug the reva frontend we need to add two replacements:\n// use the local ocis-reva repo replace github.com/owncloud/ocis-reva =\u0026gt; ../ocis-reva // also use the local reva repo replace github.com/cs3org/reva =\u0026gt; ../reva The username and password only work when basic auth is available. Otherwise you have to obtain a bearer token, eg. by grabbing it from the browser. Rebuild ocis to make sure the dependency is used. It should be sufficient to just restart the service you want to debug.\n"});index.add({'id':68,'href':'/extensions/thumbnails/grpc/','title':"GRPC API",'parent':"Thumbnails",'content':" pkg/proto/v0/thumbnails.proto GetRequest GetResponse GetRequest.FileType ThumbnailService Scalar Value Types pkg/proto/v0/thumbnails.proto GetRequest A request to retrieve a thumbnail\n Field Type Label Description filepath string The path to the source image filetype GetRequest.FileType The type to which the thumbnail should get encoded to. etag string The etag of the source image width int32 The width of the thumbnail height int32 The height of the thumbnail authorization string The authorization token GetResponse The service response\n Field Type Label Description thumbnail bytes The thumbnail as a binary mimetype string The mimetype of the thumbnail GetRequest.FileType The file types to which the thumbnail cna get encoded to.\n Name Number Description PNG 0 Represents PNG type JPG 1 Represents JPG type ThumbnailService A Service for handling thumbnail generation\n Method Name Request Type Response Type Description GetThumbnail GetRequest GetResponse Generates the thumbnail and returns it. Scalar Value Types .proto Type Notes C++ Java double double double float float float int32 Uses variable-length encoding. Inefficient for encoding negative numbers – if your field is likely to have negative values, use sint32 instead. int32 int int64 Uses variable-length encoding. Inefficient for encoding negative numbers – if your field is likely to have negative values, use sint64 instead. int64 long uint32 Uses variable-length encoding. uint32 int uint64 Uses variable-length encoding. uint64 long sint32 Uses variable-length encoding. Signed int value. These more efficiently encode negative numbers than regular int32s. int32 int sint64 Uses variable-length encoding. Signed int value. These more efficiently encode negative numbers than regular int64s. int64 long fixed32 Always four bytes. More efficient than uint32 if values are often greater than 2^28. uint32 int fixed64 Always eight bytes. More efficient than uint64 if values are often greater than 2^56. uint64 long sfixed32 Always four bytes. int32 int sfixed64 Always eight bytes. int64 long bool bool boolean string A string must always contain UTF-8 encoded or 7-bit ASCII text. string String bytes May contain any arbitrary sequence of bytes. string ByteString "});index.add({'id':69,'href':'/extensions/ocis_hello/configuration-with-ocis/','title':"Running",'parent':"Hello",'content':"Configuring ocis-hello with ocis We will need various services to run ocis\nRunning a ldap server in docker container We will use the ldap server as users provider for ocis.\ndocker run --hostname ldap.my-company.com \\ -e LDAP_TLS_VERIFY_CLIENT=never \\ -e LDAP_DOMAIN=owncloud.com \\ -e LDAP_ORGANISATION=ownCloud \\ -e LDAP_ADMIN_PASSWORD=admin \\ --name docker-slapd \\ -p 127.0.0.1:389:389 \\ -p 636:636 -d osixia/openldap Running a redis server in a docker container Redis will be used by ocis for various caching purposes.\ndocker run -e REDIS_DATABASES=1 -p 6379:6379 -d webhippie/redis:latest Running ocis In order to run this extension we will need to run ocis first. For that clone and build the ocis single binary from the github repo https://github.com/owncloud/ocis. After that we will need to create a config file for phoenix so that we can load the hello app in the frontend. Create a file phoenix-config.json with the following contents.\n{ \u0026#34;server\u0026#34;: \u0026#34;https://localhost:9200\u0026#34;, \u0026#34;theme\u0026#34;: \u0026#34;owncloud\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;0.1.0\u0026#34;, \u0026#34;openIdConnect\u0026#34;: { \u0026#34;metadata_url\u0026#34;: \u0026#34;https://localhost:9200/.well-known/openid-configuration\u0026#34;, \u0026#34;authority\u0026#34;: \u0026#34;https://localhost:9200\u0026#34;, \u0026#34;client_id\u0026#34;: \u0026#34;phoenix\u0026#34;, \u0026#34;response_type\u0026#34;: \u0026#34;code\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;openid profile email\u0026#34; }, \u0026#34;apps\u0026#34;: [ \u0026#34;files\u0026#34;, \u0026#34;draw-io\u0026#34;, \u0026#34;pdf-viewer\u0026#34;, \u0026#34;markdown-editor\u0026#34;, \u0026#34;media-viewer\u0026#34; ], \u0026#34;external_apps\u0026#34;: [ { \u0026#34;id\u0026#34;: \u0026#34;hello\u0026#34;, \u0026#34;path\u0026#34;: \u0026#34;http://localhost:9105/hello.js\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;url\u0026#34;: \u0026#34;http://localhost:9105\u0026#34; } } ] } Here we can add the url for the js file from where the hello app will be loaded.\nAfter that we will need a configuration file for ocis where we can specify the path for the hello app in the backend. For this you can use the existing proxy-example.json file from the ocis-proxy repo. Just add an extra endpoint at the end for the hello app.\n{ \u0026#34;endpoint\u0026#34;: \u0026#34;/api/v0/greet\u0026#34;, \u0026#34;backend\u0026#34;: \u0026#34;http://localhost:9105\u0026#34; } With all this in place we can finally start ocis. But first we will need to set some configuration variables.\nexport REVA_USERS_DRIVER=ldap export REVA_LDAP_HOSTNAME=localhost export REVA_LDAP_PORT=636 export REVA_LDAP_BASE_DN=\u0026#39;dc=owncloud,dc=com\u0026#39; export REVA_LDAP_USERFILTER=\u0026#39;(\u0026amp;(objectclass=posixAccount)(cn=%s))\u0026#39; export REVA_LDAP_GROUPFILTER=\u0026#39;(\u0026amp;(objectclass=posixGroup)(cn=%s))\u0026#39; export REVA_LDAP_BIND_DN=\u0026#39;cn=admin,dc=owncloud,dc=com\u0026#39; export REVA_LDAP_BIND_PASSWORD=admin export REVA_LDAP_SCHEMA_UID=uid export REVA_LDAP_SCHEMA_MAIL=mail export REVA_LDAP_SCHEMA_DISPLAYNAME=displayName export REVA_LDAP_SCHEMA_CN=cn export LDAP_URI=ldap://localhost export LDAP_BINDDN=\u0026#39;cn=admin,dc=owncloud,dc=com\u0026#39; export LDAP_BINDPW=admin export LDAP_BASEDN=\u0026#39;dc=owncloud,dc=com\u0026#39; In addition to all these we will also need to set the config files we just modified. For that set these variables with the path to the config files.\nexport PHOENIX_WEB_CONFIG=\u0026lt;path to phoenix config file\u0026gt; export OCIS_CONFIG_FILE=\u0026lt;path to ocis proxy config file\u0026gt; And finally start the ocis server\nbin/ocis server After this we will need to start the ocis-hello service. For that just build ocis-hello binary.\ncd ocis-hello make And Run the service\nbin/ocis-hello server "});index.add({'id':70,'href':'/extensions/ocis_hello/settings/','title':"Settings",'parent':"Hello",'content':"The ocis-settings service exposes an endpoint for registering so called settings bundles. This gives control to every service to define settings that are needed for fulfilling it\u0026rsquo;s intended purpose. There are different types of settings available out of the box - hopefully those already fit your needs. The settings defined through settings bundles can be changed by authenticated users through an ocis-web extension, which is also provided by the settings service. As a result, your service only has to register a settings bundle and oCIS takes care of everything else. Your service can simply use the settings values that were set by users.\nWith this chapter we want to show you, how to register a settings bundle and how to use the respective values that were set by users. We do this by customizing the greeter phrase from our greeter service in ocis-hello.\nYou can find the source code, especially how it\u0026rsquo;s integrated into the service, in the following files:\n pkg/service/v0/service.go for the requests, pkg/command/server.go for the integration of RegisterSettingsBundles into the service start. Register settings bundle In order to register a settings bundle, you need to create a request message and then send it to the BundleService of ocis-settings through a gRPC call.\nCreate request request := \u0026amp;settings.SaveSettingsBundleRequest{ SettingsBundle: \u0026amp;settings.SettingsBundle{ Identifier: \u0026amp;settings.Identifier{ Extension: \u0026#34;ocis-hello\u0026#34;, BundleKey: \u0026#34;greeting\u0026#34;, }, DisplayName: \u0026#34;Greeting\u0026#34;, Settings: []*settings.Setting{ { SettingKey: \u0026#34;phrase\u0026#34;, DisplayName: \u0026#34;Phrase\u0026#34;, Description: \u0026#34;Phrase for replies on the greet request\u0026#34;, Value: \u0026amp;settings.Setting_StringValue{ StringValue: \u0026amp;settings.StringSetting{ Required: true, Default: \u0026#34;Hello\u0026#34;, MaxLength: 15, }, }, }, }, }, } The request holds only one field, which is a SettingsBundle. It consists of an Identifier, a DisplayName and a list of Settings.\n The Extension and BundleKey inside the Identifier are required and have to be alphanumeric (- and _ are allowed as well). The Identifier has to stay stable - if you change it, existing settings will not be migrated to the new identifier. The DisplayName is required and may contain any UTF8 character. It will be shown in the settings user frontend in a generated form, so please try to be descriptive. You can change the DisplayName at any time. Settings is the list of settings you want to make available with this settings bundle. In this example, there is only one setting defined - a string setting for the phrase our greeter uses in the response. You can explore more types of settings in the settings package. All of them come with their own characteristics and validations. For the phrase setting we decided to set it to Required, so that it can\u0026rsquo;t be empty, and to set a MaxLength of 15 characters, so that the phrase is not too long. The SettingKey is particularly important, as this is used for referencing the setting in other requests. It has to fulfill the same rules as the other Identifier attributes. Please also take the time to set a Description, in order to provide accessibility in the generated forms as good as possible. Send request to ocis-settings This request message can be sent to the BundleService of ocis-settings like this:\nbundleService := settings.NewBundleService(\u0026#34;com.owncloud.api.settings\u0026#34;, mclient.DefaultClient) response, err := bundleService.SaveSettingsBundle(context.Background(), request) We run this request on every start of ocis-hello so that the settings service always has the most recent version of the settings bundle.\nUse settings value We registered the greeter phrase setting for a reason: We want to allow the authenticated user to customize how they want to be greeted by ocis-hello. In order to do this, we need to ask ocis-settings on every request, what the greeter phrase of the authenticated user is.\nAccount UUID The settings request has one important prerequisite: As our service is stateless, we need to know the account UUID of the authenticated user the incoming POST request to our greeter service is coming from. As that POST request is coming through ocis-proxy, there is an HTTP header x-access-token that holds a JWT with the account UUID in it. We just have to dismantle the JWT to get the UUID. There is a middleware for that in ocis-pkg. You can look up the server configuration for that middleware in pkg/server/http/server.go. In essence, it dismantles the x-access-token, extracts the account UUID and makes it available in the context. It can be subsequently retrieved from the context like this:\nownAccountUUID := ctx.Value(middleware.UUIDKey).(string) Create request With the account UUID we can build an Identifier for the request to ocis-settings as follows:\nrequest := \u0026amp;settings.GetSettingsValueRequest{ Identifier: \u0026amp;settings.Identifier{ Extension: \u0026#34;ocis-hello\u0026#34;, BundleKey: \u0026#34;greeting\u0026#34;, SettingKey: \u0026#34;phrase\u0026#34;, AccountUuid: ownAccountUUID, }, } The Identifier for getting a value from ocis-settings needs the three fields for extension, bundle and setting that we chose in the settings bundle. The fourth field is the UUID of the authenticated user.\nSend request to ocis-settings This request message can be sent to the ValueService of ocis-settings like this:\nvalueService := settings.NewValueService(\u0026#34;com.owncloud.api.settings\u0026#34;, mclient.DefaultClient) response, err := valueService.GetSettingsValue(ctx, request) If this request is successful we will have a - possibly customized - greeting phrase. It could also be the default value, if the user didn\u0026rsquo;t customize their phrase in the settings frontend.\nConclusion You have learned how to register settings bundles, how to get the account UUID of the authenticated user and how to query the settings service for settings values.\n"});index.add({'id':71,'href':'/extensions/ocis_hello/testing/','title':"Testing",'parent':"Hello",'content':"This repository provides a general guideline for creating tests for the ocis extensions. The tests can be written in various levels from unit, integration, and end-to-end. It is not essential to write tests on all these levels as it can be redundant in some cases. This repository provides a reference for all levels of tests.\nUnit tests Unit tests generally live inside *_test.go files in the /pkg directory. One such example in this extension is in /pkg/service/v0/service_test.go. Similarly the unit test for the protobuf generated code can also be written just like in /pkg/proto/hello.pb_test.go.\nIntegration tests There are mainly 2 types of integration tests, namely HTTP tests, and GRPC tests. These tests mostly live in /pkg/proto directory where all the protobuf definitions are specified. The examples for the HTTP integration tests are in /pkg/proto/hello.pb.web_test.go whereas the GRPC tests are in /pkg/proto/hello.pb.micro_test.go.\nEnd-to-End tests For extensions with an UI, we can also write end-to-end tests using the Nightwatch test framework. These tests live in /ui/tests directory. We can reuse already existing Gherkin steps from the phoenix tests here.\nRunning the tests Unit and integration tests The unit and integration tests are run using the simple go test command. If you wish to run all the tests with the coverage you can just use make command.\nmake test You can also run a specific file with the go test command\ngo test \u0026lt;path to package or file\u0026gt; End-to-End tests Running end-to-end tests is a bit more complicated than unit and integration tests. First of all we will need a complete ocis setup with ocis-hello running. For that refer to this guide.\nAfter that, We need to set the proper test environment. To run the end-to-end tests, first-of-all we need the phoenix repository where all the test infrastructure exists. So, clone the phoenix repository in your system in any location.\ngit clone https://github.com/owncloud/phoenix $HOME/phoenix Next we will need to start the selenium server which will control the browser. There is a script in the phoenix repo that starts the selenium server, just run that to start selenium.\ncd $HOME/phoenix yarn run selenium Now we can run the tests. The tests will take several configuration variables which can be found here. Without configuration, most of the defaults will work. We just need make sure to set these values through env variable.\nexport PHOENIX_PATH=$HOME/phoenix export OCIS_SKELETON_DIR=\u0026lt;path to the skeleton directory\u0026gt; export PHOENIX_CONFIG=\u0026lt;path to the config.json file used by phoenix\u0026gt; The phoenix path should be set to the directory where the phoenix source files are. Our tests use the existing infrastructure from the phoenix directory to run the tests.\nThe skeleton directory for the webui tests can be found in the testing app. You can just clone that repository in your local machine and point the env variable to the correct path.\nWhile running ocis we should always use a config file for phoenix because our tests will read this file and sometimes even change it which cannot be done if you use env variables or the default values.\nWith all this in place we can just run the tests with a simple make command. First go to the ocis-hello repository\ncd \u0026lt;path to ocis-hello\u0026gt; Then Simply run\nmake test-acceptance-webui To run just one feature you can run\nmake test-acceptance-webui \u0026lt;path-to-feature file\u0026gt;:\u0026lt;line-number\u0026gt; "});index.add({'id':72,'href':'/extensions/settings/values/','title':"Settings Values",'parent':"Settings",'content':"A Settings Value is the value an authenticated user has chosen for a specific setting, defined in a settings bundle. For choosing settings values as a user the sole entry point is the ocis-web extension provided by this service.\nIdentifying settings values A settings value is uniquely identified by four attributes. Three of them are coming from the definition of the setting within it\u0026rsquo;s settings bundle (see Settings Bundles for an example). The fourth identifies the user.\n extension: Key of the extension that registered the settings bundle, bundleKey: Key of the settings bundle, settingKey: Key of the setting as defined within the bundle, accountUuid: The UUID of the authenticated user who has saved the setting. When requests are going through ocis-proxy, the accountUuid attribute can be set to the static keyword me instead of using a real UUID. ocis-proxy will take care of minting the UUID of the authenticated user into a JWT, providing it in the HTTP header as x-access-token. That UUID is then used in this service, to replace me with the actual UUID of the authenticated user. Example of stored settings values { \u0026#34;values\u0026#34;: { \u0026#34;language\u0026#34;: { \u0026#34;identifier\u0026#34;: { \u0026#34;extension\u0026#34;: \u0026#34;ocis-accounts\u0026#34;, \u0026#34;bundleKey\u0026#34;: \u0026#34;profile\u0026#34;, \u0026#34;settingKey\u0026#34;: \u0026#34;language\u0026#34;, \u0026#34;accountUuid\u0026#34;: \u0026#34;5681371f-4a6e-43bc-8bb5-9c9237fa9c58\u0026#34; }, \u0026#34;listValue\u0026#34;: { \u0026#34;values\u0026#34;: [ { \u0026#34;stringValue\u0026#34;: \u0026#34;de\u0026#34; } ] } }, \u0026#34;timezone\u0026#34;: { \u0026#34;identifier\u0026#34;: { \u0026#34;extension\u0026#34;: \u0026#34;ocis-accounts\u0026#34;, \u0026#34;bundleKey\u0026#34;: \u0026#34;profile\u0026#34;, \u0026#34;settingKey\u0026#34;: \u0026#34;timezone\u0026#34;, \u0026#34;accountUuid\u0026#34;: \u0026#34;5681371f-4a6e-43bc-8bb5-9c9237fa9c58\u0026#34; }, \u0026#34;listValue\u0026#34;: { \u0026#34;values\u0026#34;: [ { \u0026#34;stringValue\u0026#34;: \u0026#34;Europe/Berlin\u0026#34; } ] } } } } gRPC endpoints The obvious way of modifying settings is the ocis-web extension, as described earlier. However, services can use the respective gRPC endpoints of the ValueService to query and modify settings values as well. The gRPC endpoints require the same identifier attributes as described above, so for making a request to the ValueService you will have to make sure that the accountUuid of the authenticated user is available in your service at the time of the request.\n"});index.add({'id':73,'href':'/ocis/development/tracing/','title':"Tracing",'parent':"Development",'content':" By default, we use Jaeger for request tracing within oCIS. You can follow these steps to get started:\n Start Jaeger by using the all-in-one docker image: docker run -d --name jaeger \\ -e COLLECTOR_ZIPKIN_HTTP_PORT=9411 \\ -p 5775:5775/udp \\ -p 6831:6831/udp \\ -p 6832:6832/udp \\ -p 5778:5778 \\ -p 16686:16686 \\ -p 14268:14268 \\ -p 14250:14250 \\ -p 9411:9411 \\ jaegertracing/all-in-one:1.17 Every single oCIS service has its own environment variables for enabling and configuring tracing. You can enable and configure tracing on each service individually. For example, enable tracing in Reva when starting the oCIS single binary like this: REVA_TRACING_ENABLED=true \\ REVA_TRACING_ENDPOINT=localhost:6831 \\ REVA_TRACING_COLLECTOR=http://localhost:14268/api/traces \\ ./bin/ocis server Enabling and configuring tracing on oCIS itself will forward the configuration to all services: OCIS_TRACING_ENABLED=true \\ OCIS_TRACING_ENDPOINT=localhost:6831 \\ OCIS_TRACING_COLLECTOR=http://localhost:14268/api/traces \\ ./bin/ocis server If you want to set individual tracing configuration for each service, make sure to set OCIS_TRACING_ENABLED=false.\n Make the actual request that you want to trace. Open up the Jaeger UI to analyze request traces. For more information on Jaeger, please refer to their Documentation.\n"});index.add({'id':74,'href':'/clients/web/deployments/','title':"Deployments",'parent':"ownCloud Web",'content':"Showcases of different scenarios of deploying ownCloud Web.\n"});index.add({'id':75,'href':'/extensions/storage/releasing/','title':"Releasing",'parent':"Storage",'content':" Preparation Release To release a new version of the storage submodule, you have to follow a few simple steps.\nPreparation Before releasing, make sure that reva has been updated to the desired version Release Check out master git checkout master git pull origin master Create a new tag (preferably signed) and replace the version number accordingly. Prefix the tag with the submodule storage/v. git tag -s storage/vx.x.x -m \u0026#34;release vx.x.x\u0026#34; git push origin storage/vx.x.x Wait for CI and check that the GitHub release was published. Congratulations, you just released the storage submodule!\n"});index.add({'id':76,'href':'/clients/web/testing/','title':"Running acceptance tests",'parent':"ownCloud Web",'content':" Setting up Selenium Setup using Docker Setup using Docker Desktop for Mac Setup using standalone Selenium server Run tests with ownCloud 10 backend with OCIS backend the quick way (all automated) the manual way (e.g. to run from an existing ocis location) Available settings to be set by environment variables Tips too many open files Acceptance Tests in CI 1. web Repo 2. ocis Repo Setting up Selenium There are multiple ways to run Selenium:\n Setup using Docker Setup using Docker Desktop for Mac Setup using a standalone Selenium server Setup using Docker Set the environment variables SELENIUM_HOST as localhost and SERVER_HOST in the format http://\u0026lt;ip_addr\u0026gt;:9100. Run yarn run selenium (available only on Linux) If you are a Mac user, you can run yarn run selenium:mac This command creates a docker container which uses port forwarding instead of host networking which is not supported on Mac Setup using Docker Desktop for Mac In order to run acceptance tests with selenium running in Docker Desktop for Mac while having ownCloud Server and Web running as services on the host machine, localhost will not work as URL. Use the Docker host ip 172.17.0.1 or its alias host.docker.internal instead. This requires adjusting all relevant config files to use host.docker.internal instead of localhost (config.json in Web and config/config.php in oC10) and changing the web OIDC-callback url. Set the SERVER_HOST and BACKEND_HOST environment variables accordingly. In order to use the same url for development on the host machine, define it as an alias to 127.0.0.1 in /etc/hosts. After all these changes Web will be accessible at http://host.docker.internal:8300 for both development and acceptance tests.\nSetup using standalone Selenium server When running a standalone Selenium server, make sure to set the environment variable SELENIUM_HOST, SELENIUM_PORT and LOCAL_UPLOAD_DIR accordingly.\nRun tests with ownCloud 10 backend setup the ownCloud 10 backend clone and install the testing app into ownCloud build Web start the Web server set SERVER_HOST to point at the URL where the Web web pages are served, for example \u0026ldquo;http://localhost:8300\u0026rdquo; set BACKEND_HOST to point to the URL of the backend, for example \u0026ldquo;http://localhost/owncloud/\u0026rdquo; to be able to run federation tests, additional setup is needed: Install and setup a second ownCloud server-instance that is accessible by a different URL. That second server-instance must have its own database and data directory. clone and install the testing app into the second ownCloud server-instance from http://github.com/owncloud/testing . when running the acceptance tests use REMOTE_BACKEND_HOST environment variable to define its address, for example, REMOTE_BACKEND_HOST=http://\u0026lt;ip_address_of_second_ownCloud_server-instance\u0026gt; yarn run acceptance-tests \u0026lt;feature-files-to-test\u0026gt; . -set the SELENIUM_HOST environment variable to your host that runs selenium, mostly localhost -set the SELENIUM_PORT environment variable to your selenium port, mostly 4444 Run yarn run acceptance-tests \u0026lt;feature-files-to-test\u0026gt;.\nThe feature files are located in the \u0026ldquo;tests/acceptance/features\u0026rdquo; subdirectories.\nsee available settings for further setup if needed\nwith OCIS backend build Web create a new web config.json file and copy it into the dist folder, even though running web in the default ocis environment does not need a config.json file, some tests rely on it being present. As a starting point and example that should work when running every service on localhost use Linux: config.json.sample-ocis Mac: tests/acceptance/ocis-mac-config.json the quick way (all automated) run yarn run test-requirements:ocis (yarn run test-requirements:ocis:mac for Mac users) to install, configure and run all ocis requirements run yarn run acceptance-tests-ocis \u0026lt;feature-files-to-test\u0026gt; to run the tests. The feature files are located in the \u0026ldquo;tests/acceptance/features\u0026rdquo; subdirectories. To separate ocis log output from the tests output, run the command in a separate console. after the tests finish, run yarn run killall to stop all created docker containers, and the ocis services the manual way (e.g. to run from an existing ocis location) clone and build ocis\n From inside the web directory run yarn run testing-app to get the testing-app, it\u0026rsquo;s needed to have the skeleton folder for the tests\n Run redis server using docker\nyarn run redis-server Run the OCIS server with the necessary configurations\nexport WEB_ASSET_PATH=\u0026#39;\u0026lt;path-to-web-clone\u0026gt;/dist\u0026#39; export WEB_UI_CONFIG=\u0026#39;\u0026lt;path-to-web-clone\u0026gt;/dist/config.json\u0026#39; export STORAGE_HOME_DRIVER=owncloud export STORAGE_USERS_DRIVER=owncloud export PROXY_ENABLE_BASIC_AUTH=true note: WEB_UI_CONFIG should point to the same config file you have created earlier. note: currently it\u0026rsquo;s not possible to run the UI tests with OCIS \u0026amp; OWNCLOUD storage-driver\nrun the server:\nbin/ocis server Run yarn run acceptance-tests-ocis \u0026lt;feature-files-to-test\u0026gt;. The feature files are located in the \u0026ldquo;tests/acceptance/features\u0026rdquo; subdirectories.\n see available settings for further setup if needed\nAvailable settings to be set by environment variables These values can be set using the environment variables to configure yarn run acceptance-tests and yarn run acceptance-tests-ocis to match your local test environment.\n setting meaning default SERVER_HOST web URL http://localhost:8300 BACKEND_HOST ownCloud server URL (or reva service url for running with OCIS) http://localhost:8080 BACKEND_USERNAME ownCloud administrator username admin BACKEND_PASSWORD ownCloud administrator password admin SELENIUM_HOST selenium server host, if not set yarn will start selenium automaticallyif running the selenium docker container as mentioned above set to localhost SELENIUM_PORT port of selenium server 4444 SCREEN_RESOLUTION width and height in px to set the browser resolution to e.g. 375x812 empty = fullscreen REMOTE_UPLOAD_DIR path to filesForUpload directory, used when uploading files through api ./tests/acceptance/filesForUpload LOCAL_UPLOAD_DIR filesForUpload directory available for selenium for direct uploadsIf using selenium-docker and example above, set it as /uploads.If running local selenium, set value same as REMOTE_UPLOAD_DIR (please, remember to use absolute path) /uploads REMOTE_BACKEND_HOST ownCloud remote server URL http://localhost:8080 RUN_ON_OCIS Running the tests using the OCIS backend false OCIS_REVA_DATA_ROOT Data directory of OCIS /var/tmp/reva OCIS_SKELETON_DIR Skeleton files directory for new users - WEB_UI_CONFIG Path for the web config file (usually in the dist folder) - Tips too many open files If tests were running fine and then suddenly start to fail your system might run into open file limits. In that case you will see messages in the OCIS log output that look like this:\n2020-05-12 11:33:43.974552 I | http: Accept error: accept tcp [::]:9200: accept4: too many open files; retrying in 1s\nIn that case increase the open file limits, how to do that would be beyond the scope of this documentation.\nAcceptance Tests in CI In the CI we run the UI tests using different backends on different repos. We use commit IDs to indicate the version of the backend or testrunner we want to use. These commit IDs should be regularly updated in the .drone.star file to keep the CI up to date. We run web UI tests in the following repos in the CI.\n1. web Repo In the owncloud/web repo, we run the tests using both the oc10 backend and the OCIS backend. For the oc10 backend, we use the owncloudci/core docker image which runs the latest daily-master-qa version of owncloud.\nFor the OCIS backend, we use the Commit ID from the owncloud/ocis repo to indicate which version of backend to use. This can be specified in the .drone.star file in the config.defaults section.\n\u0026#39;defaults\u0026#39;: { \u0026#39;acceptance\u0026#39;: { \u0026#39;ocisBranch\u0026#39;: \u0026#39;master\u0026#39;, \u0026#39;ocisCommit\u0026#39;: \u0026#39;284a9996dffa912cc1382e259b748c56ddc4aa0f\u0026#39;, } }, If the version you want to run is on a different branch from master, you also need to change the branch name.\nIn order to check if new tests are compatible with OCIS, after changing the commit id and the branch name, we can create a draft PR in owncloud/web which triggers the CI, and we can see the result there.\n2. ocis Repo We follow the same approach in the owncloud/ocis repo too. In order to run the UI tests in CI we use commit IDs from web which can be changed in the .drone.star file.\n\u0026#39;uiTests\u0026#39;: { \u0026#39;webBranch\u0026#39;: \u0026#39;master\u0026#39;, \u0026#39;webCommit\u0026#39;: \u0026#39;492e6a663efad67f770ba4ac405c4d9983d00cd3\u0026#39;, ... } This is the commit ID of web indicating the version of testrunner we want to use. If the version is on a branch other than master, we will also need to change the branch name.\n"});index.add({'id':77,'href':'/extensions/settings/glossary/','title':"Glossary",'parent':"Settings",'content':"In the context of this extension and oCIS in general, we are using the following terminology.\nConfiguration System configuration e.g. service host names and ports Changes need to be propagated to other services Typically modified on the CLI Settings Application level settings e.g. default language Can be modified at runtime without restarting the service Typically modified in the UI Preferences User settings Subset of \u0026ldquo;Settings\u0026rdquo; e.g. preferred language of a user Settings Bundle Collection of related settings Registered by an oCIS extension Settings Value Manifestation of a setting for a specific user E.g. used for customization (at runtime) in ocis-web ocis-web-settings extension for modifying settings values is provided by this service Can be queried and modified by other ocis extensions "});index.add({'id':78,'href':'/extensions/ocis_hello/license/','title':"License",'parent':"Hello",'content':"This project is licensed under the Apache 2.0 license. For the license of the used libraries you have to check the respective sources.\n"});index.add({'id':79,'href':'/ocis/development/build-docs/','title':"Documentation",'parent':"Development",'content':" Build the documentation Add changes to the documentation Build the documentation Just run make -C docs docs-serve from within the root level of the oCIS git repository.\nAdd changes to the documentation Please keep this documentation in sync with the oCIS source code.\nChanges on the documentation are automatically applied to this site when merged to the master branch.\n"});index.add({'id':80,'href':'/ocis/development/continuous-integration/','title':"Continuous Integration",'parent':"Development",'content':" Concepts Things done in CI Flags in commit message and PR title Knowledge base oCIS uses DRONE as CI system. You can find the pipeline logs here or in your PR.\nConcepts The pipeline is defined in Starlark and transformed to YAML upon pipeline run. This enables us to do a highly dynamic and non repeating pipeline configuration.\nUpon running the pipeline, your branch gets merged to the master branch. This ensures that we always test your changeset if as it was applied to the master of oCIS. Please note that this does not apply to the pipeline definition (.drone.star).\nThings done in CI static code analysis linting running UI tests running ownCloud 10 test suite against oCIS build and release docker images build and release binaries build and release documentation Flags in commit message and PR title You may add flags to your commit message or PR title in order to speed up pipeline runs and take load from the CI runners.\n [CI SKIP]: no ci is run on the commit or PR\n [docs-only]: please add this flag, if you only changed documentation. This will only trigger documentation related CI steps.\n [tests-only]: please add this flag, if you only changed tests or test-related tooling. You do not need to add a changelog for tests-only changes.\n [with-benchmarks]: please add this flag, if you want benchmarks to be run in CI.\n Knowledge base My pipeline fails because some CI related files or commands are missing.\nPlease make sure to rebase your branch onto the lastest master of oCIS. It could be that the pipeline definition (.drone.star) was changed on the master branch. This is the only file, that will not be auto merged to master upon pipeline run. So things could be out of sync.\n How can I see the YAML drone pipeline definition?\nIn order to see the Yaml pipeline definition you can use the drone-cli to convert the Starlark file.\ndrone starlark If you experience a \u0026quot;build\u0026quot; struct has no .title attribute error you need a patched drone-cli binary. You need to build it yourself from this source code. (There is also an open PR for that on drone-cli) "});index.add({'id':81,'href':'/ocis/license/','title':"License",'parent':"oCIS - ownCloud Infinite Scale",'content':"This project is licensed under the Apache 2.0 license. For the license of the used libraries you have to check the respective sources.\n"});index.add({'id':82,'href':'/extensions/','title':"Extensions",'parent':"ownCloud",'content':""});index.add({'id':83,'href':'/','title':"ownCloud",'parent':'','content':" Developer Documentation We love open source Join us Developer Documentation Welcome to our developer documentation. Here you can find developer documentation on:\n oCIS server oCIS extensions Clients, like: ownCloud Web - the new web frontend for oCIS and ownCloud ownCloud Android app ownCloud iOS app ownCloud Desktop Syncing Client Integrations We love open source The oCIS server is Apache v2 licensed. The lower storage layer of oCIS is defined by the CS3 APIs and implemented in the REVA project. Our goal is to develop the CS3 APIs to an open standard and collaborate on the open source REVA reference implementation for CS3 APIs.\nYou can also find all client sources on github.\nJoin us The oCIS server repository on github is a good entry point for you to join the project. But we also develop clients for iOS, Android, Desktop and Web.\nFor communication on development you can join our public chat talk.owncloud.com\nIf you want to help and improve ownCloud or oCIS, start coding or open issues on github in the related repository.\nWe are very happy to hear your feedback and ideas!\n"});index.add({'id':84,'href':'/ocis/release_notes/','title':"Release Notes",'parent':"oCIS - ownCloud Infinite Scale",'content':"ownCloud Infinite Scale 1.0.0 Technology Preview We are pleased to announce the availability of ownCloud Infinite Scale 1.0.0 Technology Preview which is released as the first public version of the new Infinite Scale platform.\nMicroservice architecture ownCloud Infinite Scale is following the microservices architectural pattern. It is implemented as a set of microservices which are independent of each other. They are coupled with well-defined APIs. This architecture fosters a lot of benefits that we were aiming for with the new design for oCIS:\n Every service is independent, comparably small and brings it\u0026rsquo;s own webserver, backend/APIs and frontend components Each service runs as a separate service on the system, increasing security and stability Scalability: High performance demands can be fulfilled by scaling and distributing of services Testability: Each service can be tested on its own due to well-defined APIs and functionality Protocol-driven development using protobuf High-performance communication between services through gRPC Multi-platform support powered by Golang - only minimal dependency on platform packages Cloud-native deployment, update, monitoring, logging, tracing and orchestration strategies Key figures The all-new ownCloud Web frontend is shipped as part of the platform OpenID Connect is the future-proof technology choice for authentication An Identity Provider is bundled to ease deployment and operations. It can be replaced with an external OpenID IdP, if desired Automatically built and fully maintained Docker containers are available Flexible configuration through environment variables, config files or command-line flags Database-less architecture - metadata and data are kept together in the storage as a single source of truth Native storage capabilities are used where like native versioning and trashbin Public APIs like WebDAV and OCS have been kept compatible with ownCloud 10 A secure and flexible framework to create extensions Supported platforms Linux-amd64 Darwin-amd64 Experimental: Windows, ARM (e.g., Raspberry Pi, Termux on Android) Client support All official ownCloud Clients support the Infinite Scale server with the following versions:\n Desktop \u0026gt;= 2.7 Android \u0026gt;= 2.15 iOS \u0026gt;= 1.2 Architecture components ownCloud Infinite Scale is built as a modular framework in which components can be scaled individually. It consists of\n a user management service a settings service a frontend service a storage backend service a built-in IdP an application gateway/proxy These components can be deployed in a multi-tier deployment architecture. See the documentation for an overview of the services.\nOperation modes Standalone mode (with oCIS storage driver) In standalone mode oCIS uses its built-in orchestrator to start all necessary services. This allows you to run oCIS on a single node without any outside dependencies like docker-compose, kubernetes or even a webserver. It will start an OpenID IdP and create a self-signed certificate. You can start right away by navigating to https://localhost:9200.\nSingle services scaleout oCIS allows you to scale individual services using well-known orchestration frameworks like docker-compose, dockerSwarm and kubernetes.\nBridge mode with ownCloud 10 backend For the product transition phase, ownCloud Infinite Scale comes with an operation mode (\u0026ldquo;bridge mode\u0026rdquo;) that allows a hybrid deployment, between both server generations to operate the new web frontend with ownCloud 10 and Infinite Scale in parallel. This setup allows the ownCloud Web frontend to operate with both server generations and provides the foundation to migrate users gradually to the new backend.\nRequirements for the bridge mode\n ownCloud Server \u0026gt;= 10.6 Open ID Connect is used for user authentication The Graph API app is installed on ownCloud Server The latest client versions are rolled-out to users (required for OpenID Connect support). See the documentation for more information. See the documentation on how to deploy Infinite Scale in bridge mode.\nTechnology Preview\nownCloud Infinite Scale is currently in Technology Preview. The bridge mode should only be used in non-production environments.\n What to expect? This is the first promoted public release of ownCloud Infinite Scale, released as \u0026ldquo;Technical Preview\u0026rdquo;. Infinite Scale is not yet ready for production installations. Technical audiences will be able to get a good understanding of the potential of ownCloud\u0026rsquo;s new platform.\nVersion 1.0.0 comes with the base functionality for sync and share with a much higher performance-, stability- and security-level compared to all available platforms. Based on ten years of experience in enterprise sync and share and a long standing collaboration with the biggest global science organizations this new platform will exceed what content collaboration is today.\nHow to get started? One of the most important objectives for oCIS was to ease the setup of a working instance dramatically. Since oCIS is built with Google\u0026rsquo;s powerful Go language it supports the single-file-deployment: Installing oCIS 1.0.0 is as easy as downloading a single file, applying execution permission to it and get started. No more fiddling around with complicated LAMP stacks.\nDeployment Options Given the architecture of oCIS, there are various deployment options based on the users requirements. In our experience setting up the LAMP stack for ownCloud 10 was difficult for many users. Therefore a big emphasis was put on easy yet functional deployment strategies.\nSingle binary Delivery as single binary The single binary is the best option to test the new ownCloud Infinite Scale 1.0.0 Technical Preview release on a local machine. Follow these instructions to get the platform running in the most simple way:\n Download the binary\nLinux curl https://download.owncloud.com/ocis/ocis/1.0.0/ocis-1.0.0-linux-amd64 -o ocis\nMacOS curl https://download.owncloud.com/ocis/ocis/1.0.0/ocis-1.0.0-darwin-amd64 -o ocis\n Make it executable\nchmod +x ocis\n Run it\n./ocis server\n Navigate to https://localhost:9200 and log in to ownCloud Web (admin:admin)\n Production environments will need a more sophisticated setup, see https://owncloud.github.io/ocis/deployment/ for more information.\n Docker Containerized Setup For more sophisticated setups we recommend using one of our docker setup examples. See the documentation for a setup with Traefik as a reverse proxy which also includes automated SSL certificate provisioning using Letsencrypt tools. ownCloud Web Features Framework Framework User avatars (compatible with oC 10 API) Alerts for information/errors Notifications (bell icon, compatible with oC 10 API) Extension points Available extensions Media Viewer (images and videos) Draw.io Files Files Listing and browsing the hierarchy Sorting by columns (name/size/updated) Breadcrumb Thumbnail previews for images (compatible with oC 10 API and Thumbnails service API) Upload (file/folder), using the TUS protocol for reliable uploads Download (file) Rename Copy Move Delete Indicators for resources shared with people (including subfiles and subfolders) Indicators for resources shared by link (including subfiles and subfolders) Quick actions Add people Create public link on-the-fly and copy it to the clipboard Favorites (view + add/remove) Shared with me (view) Shared with others (view) Deleted files Versions (list/restore/download/delete) File/folder search Sharing Sharing with People (user/group shares) Adding people to a resource Adding multiple people at once (users and groups) Autocomplete search to find users Roles: Viewer / Editor (folder) / Advanced permissions (granular permissions) Expiration date Listing people who have access to a resource People can be listed when a resource is directly shared and when it\u0026rsquo;s indirectly shared via a parent folder When listing people of an indirectly shared resource, there is a \u0026ldquo;via\u0026rdquo; indicator that guides to the directly shared parent Every person can recognize the owner of a resource Every person can recognize their role The owner of a resource can recognize persons that added other people (reshare indicator) Editing persons Removing persons Links Sharing with Links Private links (copy) Public links Adding public links on single files and folders Roles: Viewer / Editor (folder) / Contributor (folder) / Uploader (folder) Password-protection Expiration date Listing public links Public links can be listed when a resource is directly shared and when it\u0026rsquo;s indirectly shared via a parent folder When listing public links of an indirectly shared resource, there is a \u0026ldquo;via\u0026rdquo; indicator that guides to the directly shared parent Copying existing public links Editing existing public links Removing existing public links Viewing public links User Profile User Profile Display basic profile information (user name, display name, e-mail, group memberships) \u0026ldquo;Edit\u0026rdquo; button guides to ownCloud 10 user settings (when used with oC 10) User Settings Basic user settings Language of the web interface oCIS Backend Features Storage Storage The default oCIS storage driver deconstructs a filesystem to be able to efficiently look up files by fileid as well as path. It stores all folders and files by a uuid and persists share and other metadata using extended attributes. This allows using the linux VFS cache using stat syscalls instead of a database or key/value store. The driver implements trash, versions and sharing. It not only serves as the current default storage driver, but also as a blueprint for future storage driver implementations. IDM User and group management Functionality available via API and frontend (\u0026ldquo;Accounts\u0026rdquo; extension) User listing (API/FE) User creation (API/FE) User deletion (API/FE) User activation/blocking (API/FE) Role assignment for users (API/FE) User editing (API) Multi-select in the frontend (delete \u0026amp; block/activate) Group creation (API) Add/remove users to/from groups (API) Group deletion (API) Create/read/update/delete users and groups (CLI) Settings Settings The settings service provides APIs for other services for registering a set of settings as Bundle. It also provides a pluggable extension for ownCloud Web which provides dynamically built web forms, so that users can customize their own settings. Some well known settings are directly used by ownCloud Web for adapted user experience, e.g. the UI language. Services can query the users\u0026rsquo; chosen settings for customized backend and frontend operations as needed.\nRoles \u0026amp; Permissions System Infinite Scale follows a role-based access control model. Based on permissions for actions which are provided by the system and by extensions, roles can be composed. Ultimately, these roles can be assigned to users to define what users are permitted to do. This model allows a segregation of duties for administration and allows granular control of how different types of users (e.g., Guests) can use the platform.\n Currently available permissions: Manage accounts (gives access to the internal user management) The current roles are exemplary default roles which are used for demonstration purposes \u0026ldquo;Admin\u0026rdquo;: Has the permission to \u0026ldquo;manage accounts\u0026rdquo; \u0026ldquo;User\u0026rdquo;: Does not have any dedicated permission \u0026ldquo;Guest\u0026rdquo;: Does not have any dedicated permission Currently a user can only have one role Users with the role \u0026ldquo;Admin\u0026rdquo; can assign/unassign roles to/from other users (as part of the permission to \u0026ldquo;manage roles\u0026rdquo;) APIs APIs WebDAV OCS Known issues There are feature differences depending on the operation mode, e.g., no user management with ownCloud Web and oC 10 backend Public links do not yet respect the given role (a recipient has full permissions no matter which role has been set) Resharing does not yet work as expected Share recipients can create public links with higher permissions than they originally had Share recipients can add other people but they will not be able to access the data Sharing indicators in the file list will only be shown after opening the right sidebar for a resource Users can\u0026rsquo;t change their password yet Folder sizes will not be calculated Cleanups are not yet available (e.g., shares of a deleted user will not be removed) Sharing from the desktop client does not work yet There are no notifications yet There can be issues with access tokens not being refreshed correctly, leading to interruptings, e.g., during uploads Deleting non-empty folders from the trash bin does not work Emptying the whole trash bin does not work For feedback and bug reports, please use the public issue tracker.\n"});index.add({'id':85,'href':'/integration/','title':"Integrations",'parent':"ownCloud",'content':""});index.add({'id':86,'href':'/clients/','title':"Clients",'parent':"ownCloud",'content':""});index.add({'id':87,'href':'/ocis/getting-started/','title':"Getting Started",'parent':"oCIS - ownCloud Infinite Scale",'content':" Run oCIS Binaries Docker Usage Login to ownCloud Web Basic Management Commands Run oCIS We are distributing oCIS as binaries and Docker images.\nYou can find more deployments examples in the deployment section\nBinaries The binaries for different platforms are downloadable at our download mirror or on GitHub. Latest binaries from the master branch can be found at our download mirrors testing section.\n# for mac curl https://download.owncloud.com/ocis/ocis/testing/ocis-testing-darwin-amd64 --output ocis # for linux curl https://download.owncloud.com/ocis/ocis/testing/ocis-testing-linux-amd64 --output ocis # make binary executable chmod +x ocis ./ocis server The default primary storage location is /var/tmp/ocis. You can change that value by configuration.\nDocker Docker images for oCIS are available on Docker Hub.\nThe latest tag always reflects the current master branch.\ndocker pull owncloud/ocis docker run --rm -ti -p 9200:9200 owncloud/ocis Usage Login to ownCloud Web Open https://localhost:9200 and login using one of the demo accounts:\neinstein:relativity marie:radioactivity richard:superfluidity There are admin demo accounts:\nmoss:vista admin:admin Basic Management Commands The oCIS single binary contains multiple extensions and the ocis command helps you to manage them. You already used ocis server to run all available extensions in the Run oCIS section. We now will show you some more management commands, which you may also explore by typing ocis --help or going to the docs.\nTo start oCIS server:\nocis server The list command prints all running oCIS extensions. ocis list\nTo stop a particular extension: ocis kill web\nTo start a particular extension: ocis run web\nThe version command prints the version of your installed oCIS. ocis --version\nThe health command is used to execute a health check, if the exit code equals zero the service should be up and running, if the exist code is greater than zero the service is not in a healthy state. Generally this command is used within our Docker containers, it could also be used within Kubernetes.\nocis health --help "});index.add({'id':88,'href':'/extensions/ocis_hello/','title':"Hello",'parent':"Extensions",'content':"\nAbstract When getting started with ocis development developers need to learn about the building blocks of ocis extensions. Without guidance or orientation of the why and what of an extension they may start feeling lost. The ocis-hello repository serves as a blueprint for ocis extensions. It allows developers to get started with ocis extension development by looking at the code, configuration and documentation.\n document.addEventListener(\"DOMContentLoaded\", function(event) { mermaid.initialize({ flowchart: { useMaxWidth: true } }); }); graph TD subgraph ow[ocis-web] owh[ocis-web-hello] end owh ---|\"greet()\"| ows[ocis-hello-server] ocis-hello provides a simple hello world example with\n a protobuf based greeter API a grpc service implementing the API a vue.js frontend using the API It can be integrated into ocis web as documented in the extensions docs.\nTable of Contents Getting Started Building Running Settings Testing License "});index.add({'id':89,'href':'/categories/','title':"Categories",'parent':"ownCloud",'content':""});index.add({'id':90,'href':'/tags/','title':"Tags",'parent':"ownCloud",'content':""});})(); \ No newline at end of file diff --git a/js/en.search.min.36e2a3daa1a7d9d1a933e76363bd1cadad789d8474329428a44ff2517a93eed4.js b/js/en.search.min.8e63005e83f25e0b9e559c19ffd0a3a4d3a56a39a0240179a13c8d978c7db9e6.js similarity index 89% rename from js/en.search.min.36e2a3daa1a7d9d1a933e76363bd1cadad789d8474329428a44ff2517a93eed4.js rename to js/en.search.min.8e63005e83f25e0b9e559c19ffd0a3a4d3a56a39a0240179a13c8d978c7db9e6.js index d8bc3c858aa..93ba3fdad8a 100644 --- a/js/en.search.min.36e2a3daa1a7d9d1a933e76363bd1cadad789d8474329428a44ff2517a93eed4.js +++ b/js/en.search.min.8e63005e83f25e0b9e559c19ffd0a3a4d3a56a39a0240179a13c8d978c7db9e6.js @@ -1,4 +1,4 @@ -'use strict';(function(){const input=document.querySelector('#gdoc-search-input');const results=document.querySelector('#gdoc-search-results');input.addEventListener('focus',init);input.addEventListener('keyup',search);function init(){input.removeEventListener('focus',init);input.required=true;loadScript('/js/flexsearch-ad47a5e1ee.min.js');loadScript('/js/en.search-data.min.3ccf11e25ef498d481a7400a165ad118b95ffbc2521983e042421266b9a4e057.js',function(){input.required=false;search();});} +'use strict';(function(){const input=document.querySelector('#gdoc-search-input');const results=document.querySelector('#gdoc-search-results');input.addEventListener('focus',init);input.addEventListener('keyup',search);function init(){input.removeEventListener('focus',init);input.required=true;loadScript('/js/flexsearch-ad47a5e1ee.min.js');loadScript('/js/en.search-data.min.91704021600fa95e2ca21db96917c50670d23f43919eef331fca6cd0f4b51912.js',function(){input.required=false;search();});} function search(){while(results.firstChild){results.removeChild(results.firstChild);} if(!input.value){console.log("empty") results.classList.remove("has-hits");return;} diff --git a/ocis/configuration/index.html b/ocis/configuration/index.html index 8799022cf0e..ebd4488ef3c 100644 --- a/ocis/configuration/index.html +++ b/ocis/configuration/index.html @@ -2625,35 +2625,35 @@

    Configuration

  • Root Command
  • Sub Commands @@ -2684,7 +2684,7 @@

    Configuration

    –log-level | $OCIS_LOG_LEVEL
    Set logging level. Default: info.
    –log-pretty | $OCIS_LOG_PRETTY
    -
    Enable pretty logging. Default: true.
    +
    Enable pretty logging. Default: false.
    –log-color | $OCIS_LOG_COLOR
    Enable colored logging. Default: true.
    –tracing-enabled | $OCIS_TRACING_ENABLED
    @@ -2701,9 +2701,19 @@

    Configuration

    Used to dismantle the access token, should equal reva’s jwt-secret. Default: Pive-Fumkiu4.

    Sub Commands

    +

    ocis list

    +

    Lists running ocis extensions

    +

    Usage: ocis list [command options] [arguments...]

    ocis run

    Runs an extension

    Usage: ocis run [command options] [arguments...]

    +

    ocis health

    +

    Check health status

    +

    Usage: ocis health [command options] [arguments...]

    +
    +
    –debug-addr | $OCIS_DEBUG_ADDR
    +
    Address to debug endpoint. Default: 0.0.0.0:9010.
    +

    ocis server

    Start fullstack server

    Usage: ocis server [command options] [arguments...]

    @@ -2723,65 +2733,55 @@

    Configuration

    –grpc-addr | $OCIS_GRPC_ADDR
    Address to bind grpc server. Default: 0.0.0.0:9001.
    -

    ocis list

    -

    Lists running ocis extensions

    -

    Usage: ocis list [command options] [arguments...]

    -

    ocis health

    -

    Check health status

    -

    Usage: ocis health [command options] [arguments...]

    -
    -
    –debug-addr | $OCIS_DEBUG_ADDR
    -
    Address to debug endpoint. Default: 0.0.0.0:9010.
    -

    ocis kill

    Kill an extension by name

    Usage: ocis kill [command options] [arguments...]

    List of available Extension subcommands

    There are more subcommands to start the individual extensions. Please check the documentation about their usage and options in the dedicated section of the documentation.

    +

    ocis accounts

    +

    Start accounts server

    ocis thumbnails

    Start thumbnails server

    -

    ocis ocs

    -

    Start ocs server

    -

    ocis version

    -

    Lists running services with version

    -

    ocis storage-gateway

    -

    Start storage gateway

    -

    ocis storage-auth-basic

    -

    Start storage auth-basic service

    -

    ocis glauth

    -

    Start glauth server

    -

    ocis konnectd

    -

    Start konnectd server

    ocis webdav

    Start webdav server

    -

    ocis storage-frontend

    -

    Start storage frontend

    -

    ocis storage-home

    -

    Start storage and data provider for /home mount

    +

    ocis settings

    +

    Start settings server

    ocis storage-metadata

    Start storage and data service for metadata

    -

    ocis onlyoffice

    -

    Start onlyoffice server

    -

    ocis storage-users

    -

    Start storage and data provider for /users mount

    -

    ocis web

    -

    Start web server

    ocis storage-userprovider

    Start storage userprovider service

    +

    ocis konnectd

    +

    Start konnectd server

    ocis store

    Start a go-micro store

    -

    ocis settings

    -

    Start settings server

    -
    -

    Start storage public link storage

    +

    ocis ocs

    +

    Start ocs server

    ocis storage-auth-bearer

    Start storage auth-bearer service

    -

    ocis proxy

    -

    Start proxy server

    -

    ocis accounts

    -

    Start accounts server

    +

    ocis storage-users

    +

    Start storage and data provider for /users mount

    ocis storage-sharing

    Start storage sharing service

    +

    ocis glauth

    +

    Start glauth server

    +

    ocis proxy

    +

    Start proxy server

    +

    ocis web

    +

    Start web server

    +

    ocis storage-frontend

    +

    Start storage frontend

    +

    ocis onlyoffice

    +

    Start onlyoffice server

    +

    ocis storage-home

    +

    Start storage and data provider for /home mount

    +

    ocis version

    +

    Lists running services with version

    +
    +

    Start storage public link storage

    +

    ocis storage-gateway

    +

    Start storage gateway

    +

    ocis storage-auth-basic

    +

    Start storage auth-basic service

    @@ -2838,7 +2838,7 @@

    Configuration

    - + diff --git a/ocis/deployment/basic-remote-setup/index.html b/ocis/deployment/basic-remote-setup/index.html index 386355fcea0..aeb71921e26 100644 --- a/ocis/deployment/basic-remote-setup/index.html +++ b/ocis/deployment/basic-remote-setup/index.html @@ -2784,7 +2784,7 @@

    Basic Remote Setup

    - + diff --git a/ocis/deployment/bridge/index.html b/ocis/deployment/bridge/index.html index 1015d7fbd72..c62abca23e9 100644 --- a/ocis/deployment/bridge/index.html +++ b/ocis/deployment/bridge/index.html @@ -2893,7 +2893,7 @@

    Bridge

    - + diff --git a/ocis/deployment/index.html b/ocis/deployment/index.html index 2f17e3761ad..c684c176f22 100644 --- a/ocis/deployment/index.html +++ b/ocis/deployment/index.html @@ -2696,7 +2696,7 @@

    Deployment

    - + diff --git a/ocis/deployment/ocis_keycloak/index.html b/ocis/deployment/ocis_keycloak/index.html index c87eab4bd7c..5bc1a0114b3 100644 --- a/ocis/deployment/ocis_keycloak/index.html +++ b/ocis/deployment/ocis_keycloak/index.html @@ -2796,7 +2796,7 @@

    oCIS with Keycloak

    - + diff --git a/ocis/deployment/ocis_traefik/index.html b/ocis/deployment/ocis_traefik/index.html index a7317415402..5fbae59cd9a 100644 --- a/ocis/deployment/ocis_traefik/index.html +++ b/ocis/deployment/ocis_traefik/index.html @@ -2764,7 +2764,7 @@

    oCIS with Traefik

    - + diff --git a/ocis/deployment/owncloud10_with_oc_web/index.html b/ocis/deployment/owncloud10_with_oc_web/index.html index d85fe7c9183..b370a19631b 100644 --- a/ocis/deployment/owncloud10_with_oc_web/index.html +++ b/ocis/deployment/owncloud10_with_oc_web/index.html @@ -2781,7 +2781,7 @@

    ownCloud 10 with ownCloud Web

    - + diff --git a/ocis/deployment/preparing_server/index.html b/ocis/deployment/preparing_server/index.html index f86583897d1..16b6367255d 100644 --- a/ocis/deployment/preparing_server/index.html +++ b/ocis/deployment/preparing_server/index.html @@ -2740,7 +2740,7 @@

    Preparing a server

    - + diff --git a/ocis/development/build-docs/index.html b/ocis/development/build-docs/index.html index f2980100c33..68be6d81d38 100644 --- a/ocis/development/build-docs/index.html +++ b/ocis/development/build-docs/index.html @@ -2688,7 +2688,7 @@

    Documentation

    - + diff --git a/ocis/development/build/index.html b/ocis/development/build/index.html index 5637a34a2cd..f5d2a0f1a6b 100644 --- a/ocis/development/build/index.html +++ b/ocis/development/build/index.html @@ -2702,7 +2702,7 @@

    Build

    - + diff --git a/ocis/development/continuous-integration/index.html b/ocis/development/continuous-integration/index.html index c89a2a4c22f..13e8d474623 100644 --- a/ocis/development/continuous-integration/index.html +++ b/ocis/development/continuous-integration/index.html @@ -2736,7 +2736,7 @@

    Continuous Integration

    - + diff --git a/ocis/development/debugging/index.html b/ocis/development/debugging/index.html index 83444bd936a..1970b3ef8e9 100644 --- a/ocis/development/debugging/index.html +++ b/ocis/development/debugging/index.html @@ -2859,7 +2859,7 @@

    Debugging

    - + diff --git a/ocis/development/extensions/index.html b/ocis/development/extensions/index.html index a75d03f756c..8b6f338f789 100644 --- a/ocis/development/extensions/index.html +++ b/ocis/development/extensions/index.html @@ -2879,7 +2879,7 @@

    Extensions

    - + diff --git a/ocis/development/getting-started/index.html b/ocis/development/getting-started/index.html index ef3b8b548ed..6ad0916d94c 100644 --- a/ocis/development/getting-started/index.html +++ b/ocis/development/getting-started/index.html @@ -2720,7 +2720,7 @@

    Getting Started

    - + diff --git a/ocis/development/index.html b/ocis/development/index.html index c8b0e0fae1e..c598af744af 100644 --- a/ocis/development/index.html +++ b/ocis/development/index.html @@ -2667,7 +2667,7 @@

    Development

    - + diff --git a/ocis/development/testing/index.html b/ocis/development/testing/index.html index 96ef27c2f7d..d72073e1157 100644 --- a/ocis/development/testing/index.html +++ b/ocis/development/testing/index.html @@ -2814,7 +2814,7 @@

    Testing

    - + diff --git a/ocis/development/tracing/index.html b/ocis/development/tracing/index.html index 6a147b47f9e..c09c4e8db42 100644 --- a/ocis/development/tracing/index.html +++ b/ocis/development/tracing/index.html @@ -2719,7 +2719,7 @@

    Tracing

    - + diff --git a/ocis/flow-docs/index.html b/ocis/flow-docs/index.html index 82cbef596cb..532ced5b0e0 100644 --- a/ocis/flow-docs/index.html +++ b/ocis/flow-docs/index.html @@ -2667,7 +2667,7 @@

    Flow documentation

    - + diff --git a/ocis/flow-docs/login-flow/index.html b/ocis/flow-docs/login-flow/index.html index 4c82dc76bad..e8b95d9947d 100644 --- a/ocis/flow-docs/login-flow/index.html +++ b/ocis/flow-docs/login-flow/index.html @@ -2761,7 +2761,7 @@

    Login Flow

    - + diff --git a/ocis/flow-docs/public-upload-flow/index.html b/ocis/flow-docs/public-upload-flow/index.html index 45491c477da..a2f48a515fd 100644 --- a/ocis/flow-docs/public-upload-flow/index.html +++ b/ocis/flow-docs/public-upload-flow/index.html @@ -2683,7 +2683,7 @@

    Public upload Flow

    - + diff --git a/ocis/flow-docs/request-flow/index.html b/ocis/flow-docs/request-flow/index.html index a3ed8044002..d38f551d72e 100644 --- a/ocis/flow-docs/request-flow/index.html +++ b/ocis/flow-docs/request-flow/index.html @@ -2772,7 +2772,7 @@

    Request Flow

    - + diff --git a/ocis/getting-started/index.html b/ocis/getting-started/index.html index 207bd53b089..60971a567f7 100644 --- a/ocis/getting-started/index.html +++ b/ocis/getting-started/index.html @@ -2727,7 +2727,7 @@

    Getting Started

    - + diff --git a/ocis/index.html b/ocis/index.html index 91619a59fcd..d2ca8b1b51d 100644 --- a/ocis/index.html +++ b/ocis/index.html @@ -2695,7 +2695,7 @@

    oCIS - ownCloud Infinite Scale

    - + diff --git a/ocis/index.xml b/ocis/index.xml index d4a3615bd57..ebc7c3c550f 100644 --- a/ocis/index.xml +++ b/ocis/index.xml @@ -14,10 +14,10 @@ Configuration https://owncloud.github.io/ocis/configuration/ - Thu, 17 Dec 2020 21:01:21 +0000 + Fri, 18 Dec 2020 01:09:36 +0000 https://owncloud.github.io/ocis/configuration/ - Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands ocis run ocis server ocis list ocis health ocis kill List of available Extension subcommands ocis thumbnails ocis ocs ocis version ocis storage-gateway ocis storage-auth-basic ocis glauth ocis konnectd ocis webdav ocis storage-frontend ocis storage-home ocis storage-metadata ocis onlyoffice ocis storage-users ocis web ocis storage-userprovider ocis store ocis settings ocis storage-public-link ocis storage-auth-bearer ocis proxy ocis accounts ocis storage-sharing Configuration oCIS Single Binary is not responsible for configuring extensions. + Configuration Configuration using config files Environment variables Commandline flags Root Command Sub Commands ocis list ocis run ocis health ocis server ocis kill List of available Extension subcommands ocis accounts ocis thumbnails ocis webdav ocis settings ocis storage-metadata ocis storage-userprovider ocis konnectd ocis store ocis ocs ocis storage-auth-bearer ocis storage-users ocis storage-sharing ocis glauth ocis proxy ocis web ocis storage-frontend ocis onlyoffice ocis storage-home ocis version ocis storage-public-link ocis storage-gateway ocis storage-auth-basic Configuration oCIS Single Binary is not responsible for configuring extensions. diff --git a/ocis/license/index.html b/ocis/license/index.html index b2a3a788057..b9dbd4ad669 100644 --- a/ocis/license/index.html +++ b/ocis/license/index.html @@ -2668,7 +2668,7 @@

    License

    - + diff --git a/ocis/metrics/index.html b/ocis/metrics/index.html index 55f5e3be396..a6f65d0abbd 100644 --- a/ocis/metrics/index.html +++ b/ocis/metrics/index.html @@ -2735,7 +2735,7 @@

    Metrics

    - + diff --git a/ocis/release_notes/index.html b/ocis/release_notes/index.html index 5d2b8f73ecf..656a2f234c3 100644 --- a/ocis/release_notes/index.html +++ b/ocis/release_notes/index.html @@ -3057,7 +3057,7 @@

    Release Notes

    - + diff --git a/ocis/storage-backends/eos/index.html b/ocis/storage-backends/eos/index.html index d805fdf3d9f..f51b76849fd 100644 --- a/ocis/storage-backends/eos/index.html +++ b/ocis/storage-backends/eos/index.html @@ -2868,7 +2868,7 @@

    EOS

    - + diff --git a/ocis/storage-backends/index.html b/ocis/storage-backends/index.html index 8a8b5f3414f..f5dfb99c2e5 100644 --- a/ocis/storage-backends/index.html +++ b/ocis/storage-backends/index.html @@ -2667,7 +2667,7 @@

    Storage backends

    - + diff --git a/sitemap.xml b/sitemap.xml index e857bac2e89..15a0403a025 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -24,7 +24,7 @@ https://owncloud.github.io/ocis/configuration/ - 2020-12-17T21:01:21+00:00 + 2020-12-18T01:09:36+00:00 @@ -79,72 +79,72 @@ https://owncloud.github.io/extensions/onlyoffice/configuration/ - 2020-12-17T21:01:29+00:00 + 2020-12-18T01:09:45+00:00 https://owncloud.github.io/extensions/webdav/configuration/ - 2020-12-17T21:01:28+00:00 + 2020-12-18T01:09:44+00:00 https://owncloud.github.io/extensions/thumbnails/configuration/ - 2020-12-17T21:01:27+00:00 + 2020-12-18T01:09:43+00:00 https://owncloud.github.io/extensions/store/configuration/ - 2020-12-17T21:01:26+00:00 + 2020-12-18T01:09:42+00:00 - https://owncloud.github.io/extensions/settings/configuration/ - 2020-12-17T21:01:25+00:00 + https://owncloud.github.io/extensions/storage/configuration/ + 2020-12-18T01:09:41+00:00 - https://owncloud.github.io/extensions/storage/configuration/ - 2020-12-17T21:01:25+00:00 + https://owncloud.github.io/extensions/settings/configuration/ + 2020-12-18T01:09:40+00:00 https://owncloud.github.io/extensions/proxy/configuration/ - 2020-12-17T21:01:24+00:00 + 2020-12-18T01:09:39+00:00 https://owncloud.github.io/extensions/proxy/ - 2020-12-17T21:01:24+00:00 + 2020-12-18T01:09:39+00:00 https://owncloud.github.io/extensions/ocs/configuration/ - 2020-12-17T21:01:23+00:00 + 2020-12-18T01:09:38+00:00 https://owncloud.github.io/extensions/web/configuration/ - 2020-12-17T21:01:22+00:00 + 2020-12-18T01:09:37+00:00 https://owncloud.github.io/extensions/konnectd/configuration/ - 2020-12-17T21:01:19+00:00 + 2020-12-18T01:09:34+00:00 https://owncloud.github.io/extensions/konnectd/ - 2020-12-17T21:01:19+00:00 + 2020-12-18T01:09:34+00:00 https://owncloud.github.io/extensions/glauth/configuration/ - 2020-12-17T21:01:17+00:00 + 2020-12-18T01:09:33+00:00 https://owncloud.github.io/extensions/accounts/configuration/ - 2020-12-17T21:01:15+00:00 + 2020-12-18T01:09:31+00:00 @@ -412,12 +412,12 @@ https://owncloud.github.io/extensions/ - 2020-12-17T21:01:29+00:00 + 2020-12-18T01:09:45+00:00 https://owncloud.github.io/ - 2020-12-17T21:01:29+00:00 + 2020-12-18T01:09:45+00:00