mirror of
https://github.com/opencloud-eu/opencloud.git
synced 2026-05-01 00:10:17 -05:00
Merge branch 'master' into config-adr
This commit is contained in:
A.Unger
@@ -6,8 +6,6 @@ geekdocEditPath: edit/master/docs/ocis/adr
|
||||
geekdocFilePath: 0004-support-hot-migration.md
|
||||
---
|
||||
|
||||
# 4. Support Hot Migration
|
||||
|
||||
* Status: proposed
|
||||
* Deciders: @butonic, @micbar, @dragotin, @hodyroff, @pmaier1
|
||||
* Date: 2021-03-16
|
||||
@@ -78,4 +76,4 @@ The migration happens in subsequent stages while the service is online.
|
||||
## Links
|
||||
|
||||
|
||||
- [Clarify responsibilities of share providers and storage providers · Issue #1377 · cs3org/reva (github.com)](https://github.com/cs3org/reva/issues/1377) because the share manager for oCIS should store share information on the storage system. And [storageprovider should persist share creator · Issue #93 · cs3org/cs3apis (github.com)](https://github.com/cs3org/cs3apis/issues/93) finally: [eos: store share id in inherited xattr · Issue #543 · cs3org/reva (github.com)](https://github.com/cs3org/reva/issues/543)
|
||||
- [Clarify responsibilities of share providers and storage providers · Issue #1377 · cs3org/reva (github.com)](https://github.com/cs3org/reva/issues/1377) because the share manager for oCIS should store share information on the storage system. And [storageprovider should persist share creator · Issue #93 · cs3org/cs3apis (github.com)](https://github.com/cs3org/cs3apis/issues/93) finally: [eos: store share id in inherited xattr · Issue #543 · cs3org/reva (github.com)](https://github.com/cs3org/reva/issues/543)
|
||||
|
||||
@@ -3,11 +3,9 @@ title: "5. Account Management through CS3 API"
|
||||
date: 2021-04-12T15:00:00+01:00
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/ocis/adr
|
||||
geekdocFilePath: 0004-cs3api-user-management.md
|
||||
geekdocFilePath: 0005-cs3api-user-management.md
|
||||
---
|
||||
|
||||
# 5. Account Management via CS3 API
|
||||
|
||||
* Status: proposed
|
||||
* Deciders: @refs, @butonic, @micbar, @dragotin, @pmaier1
|
||||
* Date: 2021-04-12
|
||||
|
||||
@@ -6,9 +6,7 @@ geekdocEditPath: edit/master/docs/ocis/adr
|
||||
geekdocFilePath: 0006-service-discovery.md
|
||||
---
|
||||
|
||||
# 6. Service Discovery within oCIS and Reva
|
||||
|
||||
* Status: proposed
|
||||
* Status: accepted
|
||||
* Deciders: @refs, @butonic, @micbar, @dragotin, @pmaier1
|
||||
* Date: 2021-04-19
|
||||
|
||||
|
||||
@@ -1,6 +1,12 @@
|
||||
# 5. Graph API for Spaces
|
||||
---
|
||||
title: "7. Open Graph API for oCIS File Spaces"
|
||||
date: 2021-05-03T09:00:00+01:00
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/ocis/adr
|
||||
geekdocFilePath: 0007-api-for-spaces.md
|
||||
---
|
||||
|
||||
* Status: proposed
|
||||
* Status: accepted
|
||||
* Deciders: @butonic, @micbar, @dragotin, @hodyroff, @pmaier1
|
||||
* Date: 2021-03-19
|
||||
|
||||
@@ -38,6 +44,8 @@ This the DRAFT for the API.
|
||||
|
||||
ownCloud servers provide an API to query for available spaces of an user.
|
||||
|
||||
See the openAPI Specification for the [open Graph API](https://owncloud.dev/open-graph-api/).
|
||||
|
||||
Most important, the API returns the WebDAV endpoint for each space. With that, clients do not have to make assumptions about WebDAV routes any more.
|
||||
|
||||
See [Drive item in Microsoft Graph API](https://docs.microsoft.com/en-us/graph/api/resources/onedrive?view=graph-rest-1.0) for an overview of `drive` and `driveItem` resources. The concrete list of drives / spaces a user has access to can be obtained on multiple endpoints.
|
||||
@@ -98,7 +106,7 @@ Other space types such as backup, hidden etc. can be added later as requested.
|
||||
|
||||
The (*) marked types are not defined in the official MS API. They are prefixed with `oc` to avoid namespace clashes.
|
||||
|
||||
The `root` object equals a [driveItem](https://docs.microsoft.com/de-de/graph/api/resources/driveitem?view=graph-rest-1.0) and contains information about the root resource (directory) of the space.
|
||||
The `root` object equals a [driveItem](https://docs.microsoft.com/de-de/graph/api/resources/driveitem?view=graph-rest-1.0) and contains information about the root resource (directory) of the space.
|
||||
|
||||
This is an example object as it can be expected as `root` element. It is not complete, as not all elements will be implemented so far.
|
||||
|
||||
@@ -127,7 +135,7 @@ Meaningful fields of the root element in the context of the Open Graph API:
|
||||
4. **cTag** - an identifier that changes automatically if the content of the root node or of one of the underlying resources changes.
|
||||
5. **webUrl** - The URL to make this space visible in the browser.
|
||||
|
||||
> Note: To indicate that only the metadata of a resource has changed, the eTag has changed, but the cTag not.
|
||||
> Note: To indicate that only the metadata of a resource has changed, the eTag has changed, but the cTag not.
|
||||
|
||||
### Positive Consequences
|
||||
|
||||
|
||||
@@ -19,6 +19,7 @@ oCIS deployments are super simple, yet there are many configurations possible fo
|
||||
- [Basic oCIS setup]({{< ref "basic-remote-setup" >}}) - configure domain, certificates and port
|
||||
- [oCIS setup with Traefik for SSL termination]({{< ref "ocis_traefik" >}})
|
||||
- [oCIS setup with Keycloak as identity provider]({{< ref "ocis_keycloak" >}})
|
||||
- [oCIS setup with WOPI server to open office documents in your browser]({{< ref "ocis_wopi" >}})
|
||||
|
||||
### 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.
|
||||
|
||||
@@ -168,7 +168,6 @@ Now we need to configure a client we can later use to configure the ownCloud 10
|
||||
clients:
|
||||
- id: ocis
|
||||
name: ownCloud Infinite Scale
|
||||
insecure: yes
|
||||
application_type: web
|
||||
redirect_uris:
|
||||
- https://cloud.example.com/apps/openidconnect/redirect
|
||||
@@ -176,8 +175,6 @@ clients:
|
||||
- http://localhost:9100
|
||||
- http://localhost:9100/
|
||||
```
|
||||
You will need the `insecure: yes` if you are using self signed certificates.
|
||||
|
||||
Replace `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.
|
||||
|
||||
|
||||
@@ -10,6 +10,7 @@ geekdocFilePath: continuous_deployment.md
|
||||
{{< toc >}}
|
||||
|
||||
We are continuously deploying the following deployment examples. Every example is deployed in two flavors:
|
||||
|
||||
- Latest: reflects the current master branch state of oCIS and will be updated with every commit to master
|
||||
- Released: reflects the newest release state (currently latest release of version 1) and will be updated with every release
|
||||
|
||||
@@ -18,6 +19,7 @@ The configuration for the continuous deployment can be found in the [oCIS reposi
|
||||
# oCIS with Traefik
|
||||
|
||||
Credentials:
|
||||
|
||||
- oCIS: see [default demo users]({{< ref "../getting-started#login-to-owncloud-web" >}})
|
||||
|
||||
## Latest
|
||||
@@ -28,13 +30,38 @@ Credentials:
|
||||
|
||||
- oCIS: [ocis.ocis-traefik.released.owncloud.works](https://ocis.ocis-traefik.released.owncloud.works)
|
||||
|
||||
# oCIS with WOPI server
|
||||
|
||||
Credentials:
|
||||
|
||||
- oCIS: see [default demo users]({{< ref "../getting-started#login-to-owncloud-web" >}})
|
||||
|
||||
## Latest
|
||||
|
||||
- oCIS: [ocis.ocis-wopi.latest.owncloud.works](https://ocis.ocis-wopi.latest.owncloud.works)
|
||||
|
||||
## Released
|
||||
|
||||
- oCIS: [ocis.ocis-wopi.released.owncloud.works](https://ocis.ocis-wopi.released.owncloud.works)
|
||||
|
||||
# oCIS with latest ownCloud Web
|
||||
|
||||
Credentials:
|
||||
|
||||
- oCIS: see [default demo users]({{< ref "../getting-started#login-to-owncloud-web" >}})
|
||||
|
||||
## Latest
|
||||
|
||||
- oCIS: [ocis.ocis-web.latest.owncloud.works](https://ocis.ocis-web.latest.owncloud.works)
|
||||
|
||||
# oCIS with Keycloak
|
||||
|
||||
Credentials:
|
||||
|
||||
- oCIS: see [default demo users]({{< ref "../getting-started#login-to-owncloud-web" >}})
|
||||
- Keycloak:
|
||||
- username: admin
|
||||
- password: admin
|
||||
- username: admin
|
||||
- password: admin
|
||||
|
||||
## Latest
|
||||
|
||||
@@ -46,13 +73,38 @@ Credentials:
|
||||
- oCIS: [ocis.ocis-keycloak.released.owncloud.works](https://ocis.ocis-keycloak.released.owncloud.works)
|
||||
- Keycloak: [keycloak.ocis-keycloak.released.owncloud.works](https://keycloak.ocis-keycloak.released.owncloud.works)
|
||||
|
||||
# oCIS with Hello extension
|
||||
|
||||
Credentials:
|
||||
|
||||
- oCIS: see [default demo users]({{< ref "../getting-started#login-to-owncloud-web" >}})
|
||||
|
||||
## Latest
|
||||
|
||||
- oCIS: [ocis.ocis-hello.latest.owncloud.works](https://ocis.ocis-hello.latest.owncloud.works)
|
||||
|
||||
# oCIS with S3 storage backend (MinIO)
|
||||
|
||||
Credentials:
|
||||
|
||||
- oCIS: see [default demo users]({{< ref "../getting-started#login-to-owncloud-web" >}})
|
||||
- MinIO:
|
||||
- access key: ocis
|
||||
- secret access key: ocis-secret-key
|
||||
|
||||
## Latest
|
||||
|
||||
- oCIS: [ocis.ocis-s3.latest.owncloud.works](https://ocis.ocis-s3.latest.owncloud.works)
|
||||
- MinIO: [minio.ocis-s3.latest.owncloud.works](https://minio.ocis-s3.latest.owncloud.works)
|
||||
|
||||
# oCIS with CS3 users
|
||||
|
||||
Credentials:
|
||||
|
||||
- oCIS: see [default demo users]({{< ref "../getting-started#login-to-owncloud-web" >}})
|
||||
- LDAP admin:
|
||||
- username: cn=admin,dc=owncloud,dc=com
|
||||
- password: admin
|
||||
- LDAP admin:
|
||||
- username: cn=admin,dc=owncloud,dc=com
|
||||
- password: admin
|
||||
|
||||
## Latest
|
||||
|
||||
|
||||
@@ -0,0 +1,125 @@
|
||||
---
|
||||
title: "oCIS with Hello extension"
|
||||
date: 2020-10-12T14:04:00+01:00
|
||||
weight: 24
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/ocis/deployment
|
||||
geekdocFilePath: ocis_wopi.md
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## Overview
|
||||
|
||||
- oCIS running behind Traefik as reverse proxy
|
||||
- oCIS Hello extension runs beside the main oCIS stack and providing the Hello functionality
|
||||
- Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup
|
||||
|
||||
[Find this example on GitHub](https://github.com/owncloud/ocis/tree/master/deployments/examples/ocis_hello)
|
||||
|
||||
The docker stack consists of 3 containers. One of them is Traefik, a proxy which is terminating SSL and forwards the requests to oCIS in the internal docker network.
|
||||
|
||||
The next container is oCIS itself in a configuration like the [oCIS with Traefik example]({{< ref "ocis_traefik" >}}), except that for this example a custom proxy and web UI configuration is used to enable the oCIS Hello extension.
|
||||
|
||||
The oCIS Hello extension is running in another container and enables you to use its' functionality from within ownCloud Web.
|
||||
|
||||
## Server 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]({{< ref "preparing_server" >}})
|
||||
|
||||
### Install oCIS and Traefik
|
||||
|
||||
- Clone oCIS repository
|
||||
|
||||
`git clone https://github.com/owncloud/ocis.git`
|
||||
|
||||
- Go to the deployment example
|
||||
|
||||
`cd ocis/deployment/examples/ocis_hello
|
||||
|
||||
- Open the `.env` file in a text editor
|
||||
The file by default looks like this:
|
||||
|
||||
```bash
|
||||
# If you'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 ###
|
||||
# Serve Treafik dashboard. Defaults to "false".
|
||||
TRAEFIK_DASHBOARD=
|
||||
# Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
|
||||
TRAEFIK_DOMAIN=
|
||||
# Basic authentication for the dashboard. Defaults to user "admin" and password "admin"
|
||||
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 "latest"
|
||||
OCIS_DOCKER_TAG=
|
||||
# Domain of oCIS, where you can find the frontend. Defaults to "ocis.owncloud.test"
|
||||
OCIS_DOMAIN=
|
||||
# IDP LDAP bind password. Must be changed in order to have a secure oCIS. Defaults to "idp".
|
||||
IDP_LDAP_BIND_PASSWORD=
|
||||
# Storage LDAP bind password. Must be changed in order to have a secure oCIS. Defaults to "reva".
|
||||
STORAGE_LDAP_BIND_PASSWORD=
|
||||
# JWT secret which is used for the storage provider. Must be changed in order to have a secure oCIS. Defaults to "Pive-Fumkiu4"
|
||||
OCIS_JWT_SECRET=
|
||||
|
||||
### oCIS Hello settings ###
|
||||
# oCIS Hello version. Defaults to "latest"
|
||||
OCIS_HELLO_DOCKER_TAG=
|
||||
```
|
||||
|
||||
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`.
|
||||
|
||||
If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` eg. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
|
||||
|
||||
The Traefik dashboard 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](https://htpasswdgenerator.de/) or a cli tool).
|
||||
|
||||
Traefik will issue certificates with LetsEncrypt and therefore you must set an email address in `TRAEFIK_ACME_MAIL=`.
|
||||
|
||||
By 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](https://hub.docker.com/r/owncloud/ocis/tags?page=1&ordering=last_updated).
|
||||
|
||||
Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, eg. `OCIS_DOMAIN=ocis.owncloud.test`.
|
||||
|
||||
You also must override three default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD` and `OCIS_JWT_SECRET` in order to secure your oCIS instance. Choose some random strings eg. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
|
||||
|
||||
By default the oCIS Hello extension will be started in the `latest` version. If you want to start a specific version of oCIS Hello set the version to `OCIS_HELLO_DOCKER_TAG=`. Available versions can be found on [Docker Hub](https://hub.docker.com/r/owncloud/ocis-hello/tags?page=1&ordering=last_updated).
|
||||
|
||||
Now you have configured everything and can save the file.
|
||||
|
||||
- Start the docker stack
|
||||
|
||||
`docker-compose up -d`
|
||||
|
||||
- You now can visit oCIS and are able to switch to the Hello extension by using the application switcher on the top right corner of ownCloud Web.
|
||||
|
||||
## Local setup
|
||||
|
||||
For a more simple local ocis setup see [Getting started]({{< ref "../getting-started" >}})
|
||||
|
||||
This 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.
|
||||
|
||||
On Linux and macOS you can add them to your `/etc/hosts` files like this:
|
||||
|
||||
```
|
||||
127.0.0.1 ocis.owncloud.test
|
||||
127.0.0.1 traefik.owncloud.testt
|
||||
```
|
||||
|
||||
After that you're ready to start the application stack:
|
||||
|
||||
`docker-compose up -d`
|
||||
|
||||
Open https://collabora.owncloud.test and https://wopisever.owncloud.test in your browser and accept the invalid certificate warning.
|
||||
|
||||
Open https://ocis.owncloud.test in your browser and accept the invalid certificate warning. You are now able to switch to the Hello extension by using the application switcher on the top right corner of ownCloud Web.
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
title: "oCIS with S3 storage backend (MinIO)"
|
||||
date: 2020-10-12T14:04:00+01:00
|
||||
weight: 24
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/ocis/deployment
|
||||
geekdocFilePath: ocis_wopi.md
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## Overview
|
||||
|
||||
* oCIS running behind Traefik as reverse proxy
|
||||
* MinIO as S3 compatible storage provider
|
||||
* oCIS is configured to use S3 as user storage provider
|
||||
* Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup
|
||||
|
||||
[Find this example on GitHub](https://github.com/owncloud/ocis/tree/master/deployments/examples/ocis_wopi)
|
||||
|
||||
The docker stack consists 3 containers. One of them is Traefik, a proxy which is terminating SSL and forwards the requests to oCIS in the internal docker network.
|
||||
|
||||
The next container is oCIS itself in a configuration like the [oCIS with Traefik example]({{< ref "ocis_traefik" >}}), except that it will use S3 as user storage.
|
||||
|
||||
The last container is MinIO, providing a S3 compatible API, where oCIS will store its' data.
|
||||
|
||||
## Server Deployment
|
||||
|
||||
### Requirements
|
||||
|
||||
* Linux server with docker and docker-compose installed
|
||||
* Three domains set up and pointing to your server
|
||||
- ocis.* for serving oCIS
|
||||
- minio.* for accessing the MinIO S3 bucket in the browser
|
||||
- traefik.* for serving the Traefik dashboard
|
||||
|
||||
See also [example server setup]({{< ref "preparing_server" >}})
|
||||
|
||||
|
||||
### Install oCIS and Traefik
|
||||
|
||||
* Clone oCIS repository
|
||||
|
||||
`git clone https://github.com/owncloud/ocis.git`
|
||||
|
||||
* Go to the deployment example
|
||||
|
||||
`cd ocis/deployment/examples/ocis_s3
|
||||
|
||||
* Open the `.env` file in a text editor
|
||||
The file by default looks like this:
|
||||
```bash
|
||||
# If you'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 ###
|
||||
# Serve Treafik dashboard. Defaults to "false".
|
||||
TRAEFIK_DASHBOARD=
|
||||
# Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
|
||||
TRAEFIK_DOMAIN=
|
||||
# Basic authentication for the dashboard. Defaults to user "admin" and password "admin"
|
||||
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 "latest"
|
||||
OCIS_DOCKER_TAG=
|
||||
# Domain of oCIS, where you can find the frontend. Defaults to "ocis.owncloud.test"
|
||||
OCIS_DOMAIN=
|
||||
# IDP LDAP bind password. Must be changed in order to have a secure oCIS. Defaults to "idp".
|
||||
IDP_LDAP_BIND_PASSWORD=
|
||||
# Storage LDAP bind password. Must be changed in order to have a secure oCIS. Defaults to "reva".
|
||||
STORAGE_LDAP_BIND_PASSWORD=
|
||||
# JWT secret which is used for the storage provider. Must be changed in order to have a secure oCIS. Defaults to "Pive-Fumkiu4"
|
||||
OCIS_JWT_SECRET=
|
||||
|
||||
### MINIO / S3 settings ###
|
||||
# Domain of MinIO where the Web UI is accessible. Defaults to "minio.owncloud.test".
|
||||
MINIO_DOMAIN=
|
||||
# S3 bucket name, where oCIS stores its data in. Defaults to "ocis-bucket".
|
||||
MINIO_BUCKET=
|
||||
# S3 bucket access key, which oCIS uses to authenticate. Defaults to "ocis".
|
||||
MINIO_ACCESS_KEY=
|
||||
# S3 bucket access key secret, which oCIS uses to authenticate. Defaults to "ocis-secret-key".
|
||||
MINIO_SECRET_KEY=
|
||||
|
||||
```
|
||||
|
||||
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`.
|
||||
|
||||
If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` eg. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
|
||||
|
||||
The Traefik dashboard 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](https://htpasswdgenerator.de/) or a cli tool).
|
||||
|
||||
Traefik will issue certificates with LetsEncrypt and therefore you must set an email address in `TRAEFIK_ACME_MAIL=`.
|
||||
|
||||
By 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](https://hub.docker.com/r/owncloud/ocis/tags?page=1&ordering=last_updated).
|
||||
|
||||
Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, eg. `OCIS_DOMAIN=ocis.owncloud.test`.
|
||||
|
||||
You also must override three default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD` and `OCIS_JWT_SECRET` in order to secure your oCIS instance. Choose some random strings eg. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
|
||||
|
||||
Set your domain for the MinIO frontend in `MINIO_DOMAIN=`, eg. `MINIO_DOMAIN=minio.owncloud.test`. If you are using other S3-compatible providers you need to configure the respective endpoint here.
|
||||
|
||||
If you like you can change the default name of the S3 bucket by setting `MINIO_BUCKET=` to a different value.
|
||||
|
||||
You also must override the S3 bucket credentials in `MINIO_ACCESS_KEY` and `MINIO_SECRET_KEY` in order to secure your MinIO instance. Choose some random strings eg. from the output of `openssl rand -base64 32`.
|
||||
|
||||
Now you have configured everything and can save the file.
|
||||
|
||||
* Start the docker stack
|
||||
|
||||
`docker-compose up -d`
|
||||
|
||||
* You now can visit oCIS and are able to use it just normally. If you log into the web UI of MinIO, you will see blobs of files you uploaded.
|
||||
|
||||
## Local setup
|
||||
For a more simple local ocis setup see [Getting started]({{< ref "../getting-started" >}})
|
||||
|
||||
This 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.
|
||||
|
||||
On Linux and macOS you can add them to your `/etc/hosts` files like this:
|
||||
```
|
||||
127.0.0.1 ocis.owncloud.test
|
||||
127.0.0.1 traefik.owncloud.test
|
||||
127.0.0.1 minio.owncloud.test
|
||||
```
|
||||
|
||||
After that you're ready to start the application stack:
|
||||
|
||||
`docker-compose up -d`
|
||||
|
||||
Open https://ocis.owncloud.test in your browser and accept the invalid certificate warning. You now can use oCIS normally and should now upload a file. Open https://minio.owncloud.test in your browser and accept the invalid certificate warning, after that you will see blobs of files you have uploaded to oCIS.
|
||||
@@ -0,0 +1,157 @@
|
||||
---
|
||||
title: "oCIS with WOPI server"
|
||||
date: 2020-10-12T14:04:00+01:00
|
||||
weight: 24
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/ocis/deployment
|
||||
geekdocFilePath: ocis_wopi.md
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## Overview
|
||||
|
||||
* oCIS, Wopi server and Collabora running behind Traefik as reverse proxy
|
||||
* Collabora enables you to edit text documents in your browser
|
||||
* Wopi server acts as a bridge to make the oCIS storage accessible to Collabora
|
||||
* Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup
|
||||
|
||||
[Find this example on GitHub](https://github.com/owncloud/ocis/tree/master/deployments/examples/ocis_wopi)
|
||||
|
||||
The docker stack consists 5 containers. One of them is Traefik, a proxy which is terminating SSL and forwards the requests to oCIS in the internal docker network.
|
||||
|
||||
The next container is oCIS itself in a configuration like the [oCIS with Traefik example]({{< ref "ocis_traefik" >}}), except that for this example a custom proxy and web UI configuration is used to enable the oCIS Wopi extension.
|
||||
|
||||
The oCIS WOPI server extension is running in another container and enables you to open files in Collabora from within ownCloud Web.
|
||||
|
||||
The last two containers are the WOPI server and Collabora.
|
||||
|
||||
## Server Deployment
|
||||
|
||||
### Requirements
|
||||
|
||||
* Linux server with docker and docker-compose installed
|
||||
* Three domains set up and pointing to your server
|
||||
- ocis.* for serving oCIS
|
||||
- collabora.* for serving Collabora
|
||||
- wopiserver.* for serving the WOPI server
|
||||
- traefik.* for serving the Traefik dashboard
|
||||
|
||||
See also [example server setup]({{< ref "preparing_server" >}})
|
||||
|
||||
|
||||
### Install oCIS and Traefik
|
||||
|
||||
* Clone oCIS repository
|
||||
|
||||
`git clone https://github.com/owncloud/ocis.git`
|
||||
|
||||
* Go to the deployment example
|
||||
|
||||
`cd ocis/deployments/examples/ocis_wopi`
|
||||
|
||||
* Open the `.env` file in a text editor
|
||||
The file by default looks like this:
|
||||
```bash
|
||||
# If you'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 ###
|
||||
# Serve Treafik dashboard. Defaults to "false".
|
||||
TRAEFIK_DASHBOARD=
|
||||
# Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
|
||||
TRAEFIK_DOMAIN=
|
||||
# Basic authentication for the dashboard. Defaults to user "admin" and password "admin"
|
||||
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 "latest"
|
||||
OCIS_DOCKER_TAG=
|
||||
# Domain of oCIS, where you can find the frontend. Defaults to "ocis.owncloud.test"
|
||||
OCIS_DOMAIN=
|
||||
# IDP LDAP bind password. Must be changed in order to have a secure oCIS. Defaults to "idp".
|
||||
IDP_LDAP_BIND_PASSWORD=
|
||||
# Storage LDAP bind password. Must be changed in order to have a secure oCIS. Defaults to "reva".
|
||||
STORAGE_LDAP_BIND_PASSWORD=
|
||||
# JWT secret which is used for the storage provider. Must be changed in order to have a secure oCIS. Defaults to "Pive-Fumkiu4"
|
||||
OCIS_JWT_SECRET=
|
||||
|
||||
### Wopi server settings ###
|
||||
# oCIS Wopi server version. Defaults to "latest"
|
||||
OCIS_WOPISERVER_DOCKER_TAG=
|
||||
# cs3org wopi server version. Defaults to "latest"
|
||||
CS3ORG_WOPISERVER_DOCKER_TAG=
|
||||
# cs3org wopi server domain. Defaults to "wopiserver.owncloud.test"
|
||||
WOPISERVER_DOMAIN=
|
||||
# JWT secret which is used for the documents to be request by the Wopi client from the cs3org Wopi server. Must be change in order to have a secure Wopi server. Defaults to "LoremIpsum567"
|
||||
WOPI_JWT_SECRET=
|
||||
# JWT secret which is used for the documents to be request by the Wopi client from the cs3org Wopi server. Must be change in order to have a secure Wopi server. Defaults to "LoremIpsum123"
|
||||
WOPI_IOP_SECRET=
|
||||
|
||||
### Collabora settings ###
|
||||
# Domain of Collabora, where you can find the frontend. Defaults to "collabora.owncloud.test"
|
||||
COLLABORA_DOMAIN=
|
||||
# Admin user for Collabora. Defaults to blank, provide one to enable access
|
||||
COLLABORA_ADMIN_USER=
|
||||
# Admin password for COllabora. Defaults to blank, provide one to enable access
|
||||
COLLABORA_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`.
|
||||
|
||||
If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` eg. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
|
||||
|
||||
The Traefik dashboard 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](https://htpasswdgenerator.de/) or a cli tool).
|
||||
|
||||
Traefik will issue certificates with LetsEncrypt and therefore you must set an email address in `TRAEFIK_ACME_MAIL=`.
|
||||
|
||||
By 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](https://hub.docker.com/r/owncloud/ocis/tags?page=1&ordering=last_updated).
|
||||
|
||||
Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, eg. `OCIS_DOMAIN=ocis.owncloud.test`.
|
||||
|
||||
You also must override three default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD` and `OCIS_JWT_SECRET` in order to secure your oCIS instance. Choose some random strings eg. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
|
||||
|
||||
By default the oCIS WOPI server extension will be started in the `latest` version. If you want to start a specific version of oCIS WOPI server set the version to `OCIS_WOPISERVER_DOCKER_TAG=`. Available versions can be found on [Docker Hub](https://hub.docker.com/r/owncloud/ocis-wopiserver/tags?page=1&ordering=last_updated).
|
||||
|
||||
By default the CS3Org WOPI server will also be started in the `latest` version. If you want to start a specific version of it, you can set the version to `CS3ORG_WOPISERVER_DOCKER_TAG=`. Available versions can be found on [Docker Hub](https://hub.docker.com/r/cs3org/wopiserver/tags?page=1&ordering=last_updated).
|
||||
|
||||
Set your domain for the CS3Org WOPI server in `WOPISERVER_DOMAIN=`, where Collabora can download the files.
|
||||
|
||||
You also must override the default WOPI JWT secret and the WOPI IOP secret, in order to have a secure setup. Do this by setting `WOPI_JWT_SECRET` and `WOPI_IOP_SECRET` to a long and random string.
|
||||
|
||||
Now it's time to set up Collabora and you need to configure the Domain of Collabora in `COLLABORA_DOMAIN=`.
|
||||
|
||||
If you want to use the Collabora admin panel you need to set user name and passwort for in `COLLABORA_ADMIN_USER=` and `COLLABORA_ADMIN_PASSWORD=`.
|
||||
|
||||
Now you have configured everything and can save the file.
|
||||
|
||||
* Start the docker stack
|
||||
|
||||
`docker-compose up -d`
|
||||
|
||||
* You now can visit oCIS and are able to open an office document in your browser.
|
||||
|
||||
## Local setup
|
||||
For a more simple local ocis setup see [Getting started]({{< ref "../getting-started" >}})
|
||||
|
||||
This 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.
|
||||
|
||||
On Linux and macOS you can add them to your `/etc/hosts` files like this:
|
||||
```
|
||||
127.0.0.1 ocis.owncloud.test
|
||||
127.0.0.1 traefik.owncloud.test
|
||||
127.0.0.1 collabora.owncloud.test
|
||||
127.0.0.1 wopiserver.owncloud.test
|
||||
```
|
||||
|
||||
After that you're ready to start the application stack:
|
||||
|
||||
`docker-compose up -d`
|
||||
|
||||
Open https://collabora.owncloud.test and https://wopiserver.owncloud.test in your browser and accept the invalid certificate warning.
|
||||
|
||||
Open https://ocis.owncloud.test in your browser and accept the invalid certificate warning. You are now able to open an office document in your browser.
|
||||
@@ -13,7 +13,7 @@ oCIS uses [DRONE](https://www.drone.io/) as CI system. You can find the pipeline
|
||||
|
||||
## Concepts
|
||||
|
||||
The pipeline is defined in [Starlark](https://github.com/bazelbuild/starlark) and transformed to YAML upon pipeline run. This enables us to do a highly dynamic and non repeating pipeline configuration.
|
||||
The pipeline is defined in [Starlark](https://github.com/bazelbuild/starlark) and transformed to YAML upon pipeline run. This enables us to do a highly dynamic and non repeating pipeline configuration. We enforce Starlark format guidelines with Bazel Buildifier. You can format the .drone.star file by running `make ci-format`.
|
||||
|
||||
Upon 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`).
|
||||
|
||||
|
||||
@@ -7,227 +7,59 @@ geekdocEditPath: edit/master/docs/ocis/development
|
||||
geekdocFilePath: extensions.md
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
oCIS is all about files, sync and share - but most of the time there is more you want to do with your files, e.g. having a different view on your photo collection or editing your offices files in an online file editor. ownCloud 10 faced the same problem and solved it with `applications`, which can extend the functionality of ownCloud 10 in a wide range. Since oCIS is different in its architecture compared to ownCloud 10, we had to come up with a similiar (yet slightly different) solution. To extend the functionality of oCIS, you can write or install `extensions`. An extension is basically any running code which integrates into oCIS and provides functionality to oCIS and its users. Because extensions are just microservices providing an API, you can technically choose any programming language you like - a huge improvement to ownCloud 10, where it was nearly impossible to use a different programming language than PHP.
|
||||
|
||||
## How to build and run ocis-simple
|
||||
We will now introduce you to the oCIS extension system and show you how you can create a custom extension yourself.
|
||||
|
||||
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:
|
||||
## Extension examples
|
||||
|
||||
```console
|
||||
mkdir ocis-extension-workshop && ocis-extension-workshop
|
||||
```
|
||||
Technically every service in oCIS is an extension, even if oCIS would not really work without some of them. Therefore, you can draw inspiration from any of the plenty of extensions in the [oCIS monorepo](https://github.com/owncloud/ocis).
|
||||
|
||||
Following https://github.com/owncloud/ocis
|
||||
Besides these "default" extensions in the oCIS monorepo, there are two more extensions you should be aware of:
|
||||
|
||||
```console
|
||||
git clone https://github.com/owncloud/ocis.git
|
||||
cd ocis
|
||||
- [Hello](https://github.com/owncloud/ocis-hello)
|
||||
- [WOPI server](https://github.com/owncloud/ocis-wopiserver)
|
||||
|
||||
TAGS=simple make generate build
|
||||
```
|
||||
Differences between the extensions maintained inside the oCIS monorepo and the ones maintained in their own repository are:
|
||||
|
||||
*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](https://github.com/owncloud/ocis/blob/master/web/pkg/assets/embed.go) which is currently not automatically updated. We'll see how to use a custom ownCloud Web later.*
|
||||
- extensions inside the [oCIS monorepo](https://github.com/owncloud/ocis) are all written in Go, whereas other extensions may choose the programming language freely
|
||||
- extensions inside the oCIS monorepo heavily share tooling to reduce maintenance efforts, whereas other extensions may use different tooling (e.g. a different CI system)
|
||||
- extensions inside the oCIS monorepo will be all build into one binary and started with the `ocis server` command. All other extensions must be started individually besides oCIS.
|
||||
|
||||
`bin/ocis server`
|
||||
|
||||
Open the browser at https://localhost:9200
|
||||
For quickstart purposes we also offer a [template project](https://github.com/owncloud/boilr-ocis-extension) which can be used to generate all the boilerplate code for you. But you also can decide to use your own project layout or even a different programming language.
|
||||
|
||||
1. You land on the login screen. click login
|
||||
2. You are redirected to an idp at https://localhost:9200/signin/v1/identifier with a login mask. Use `einstein:relativity` (one of the three demo users) to log in
|
||||
3. You are redirected to http://localhost:9100/#/hello the ocis-hello app
|
||||
4. 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.*
|
||||
## Integration into oCIS
|
||||
|
||||
## Hacking ocis-hello
|
||||
|
||||
go back to the ocis-extension-workshop folder
|
||||
|
||||
```console
|
||||
cd ..
|
||||
```
|
||||
|
||||
Following https://github.com/owncloud/ocis-hello
|
||||
|
||||
```
|
||||
git 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:
|
||||
1. run only the necessary services from ocis and ocis-hello independently
|
||||
2. compile ocis with the updated ocis-hello
|
||||
|
||||
### Option 1:
|
||||
get a list of ocis services:
|
||||
|
||||
```console
|
||||
ps ax | grep ocis
|
||||
```
|
||||
|
||||
Try to kill `ocis hello`
|
||||
|
||||
Remember: For now, killing a service will cause ocis to restart it. This is subject to change.
|
||||
|
||||
In order to be able to manage the processes ourselves we need to start them independently:
|
||||
|
||||
`bin/ocis server` starts the same services as:
|
||||
|
||||
```
|
||||
bin/ocis micro &
|
||||
bin/ocis web &
|
||||
bin/ocis hello &
|
||||
bin/ocis reva &
|
||||
```
|
||||
|
||||
Now we can kill the `ocis hello` and use our custom built ocis-hello binary:
|
||||
|
||||
```console
|
||||
cd ../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
|
||||
|
||||
```
|
||||
git clone https://github.com/owncloud/web.git
|
||||
cd web
|
||||
|
||||
yarn install
|
||||
yarn dist
|
||||
```
|
||||
|
||||
We can tell ocis to use the compiled assets:
|
||||
|
||||
Kill `ocis web`, then use the compiled assets when starting ownCloud Web.
|
||||
|
||||
```console
|
||||
cd ../ocis
|
||||
WEB_ASSET_PATH="`pwd`/../web/dist" bin/ocis web
|
||||
```
|
||||
|
||||
## The ownCloud design system
|
||||
|
||||
The [ownCloud design system](https://owncloud.design/) contains a set of ownCloud vue components for ownCloud Web or your own ocis extensions. Please use it for a consistent look and feel.
|
||||
|
||||
## External ownCloud Web apps
|
||||
|
||||
This is what hello is: copy and extend!
|
||||
|
||||
1. ownCloud Web is configured using the config.json which is served by the ocis-web service (either `bin/ocis web` or `bin/web server`)
|
||||
|
||||
2. point ocis-web to the web config which you extended with an external app:
|
||||
`WEB_UI_CONFIG="`pwd`/../web/config.json" ASSET_PATH="`pwd`/../web/dist" bin/ocis web`
|
||||
|
||||
```json
|
||||
{
|
||||
"server": "https://localhost:9200",
|
||||
"theme": "owncloud",
|
||||
"version": "0.1.0",
|
||||
"openIdConnect": {
|
||||
"metadata_url": "https://localhost:9200/.well-known/openid-configuration",
|
||||
"authority": "https://localhost:9200",
|
||||
"client_id": "web",
|
||||
"response_type": "code",
|
||||
"scope": "openid profile email"
|
||||
},
|
||||
"apps": [],
|
||||
"external_apps": [
|
||||
{
|
||||
"id": "hello",
|
||||
"path": "http://localhost:9105/hello.js",
|
||||
"config": {
|
||||
"url": "http://localhost:9105"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "myapp",
|
||||
"path": "http://localhost:6789/superapp.js",
|
||||
"config": {
|
||||
"backend": "http://someserver:1234",
|
||||
"myconfig": "is awesome"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## ownCloud Web extension points
|
||||
|
||||
{{< hint info >}}
|
||||
For an up to date list check out [the ownCloud Web documentation](https://github.com/owncloud/web/issues/2423).
|
||||
{{< /hint >}}
|
||||
|
||||
Several ones available:
|
||||
Depending on the functionality of your extension, you might need to integrate with one or multiple of the components of oCIS mentioned below.
|
||||
|
||||
### ownCloud 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)
|
||||
If your extension is not just doing something in the background, you will need a UI in order to allow the user to interact with your extension. You could just provide your own web frontend for that purpose, but for a better user experience you can easily integrate into the web frontend of oCIS, the new [ownCloud Web](https://github.com/owncloud/web).
|
||||
|
||||
Example of a file action in the `app.js`:
|
||||
```js
|
||||
const appInfo = {
|
||||
name: 'MarkdownEditor',
|
||||
id: 'markdown-editor',
|
||||
icon: 'text',
|
||||
isFileEditor: true,
|
||||
extensions: [{
|
||||
extension: 'txt',
|
||||
newFileMenu: {
|
||||
menuTitle ($gettext) {
|
||||
return $gettext('Create new plain text file…')
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
extension: 'md',
|
||||
newFileMenu: {
|
||||
menuTitle ($gettext) {
|
||||
return $gettext('Create new mark-down file…')
|
||||
}
|
||||
}
|
||||
}]
|
||||
}
|
||||
```
|
||||
ownCloud Web allows you to write an extension for itself and therefore offers a seamless user experience. Upon login, the user will be able to use the application switcher to switch between the files view, settings and other available and installed extensions, yours included. Furthermore it is also possible to register your extension for different file actions. As an example, you could offer your extension to the user for creating and editing office documents. The user will then be able to create or open a file with your application directly from the files view. How to provide create an extension for ownCloud Web can be seen best in [the Hello extension](https://github.com/owncloud/ocis-hello/blob/master/ui/app.js), whereas plain file handling without any web frontend is available in the [WOPI server extension](https://github.com/owncloud/ocis-wopiserver/blob/master/ui/app.js).
|
||||
|
||||
For the side bar have a look at the files app, `defaults.js` & `fileSideBars`
|
||||
To make ownCloud Web pick up your extension, you need to activate it in the configuration like seen in the [Hello extension](https://owncloud.dev/extensions/ocis_hello/running/#configure-and-start-ocis).
|
||||
|
||||
## API driven development
|
||||
For a consistent look and feel, ownCloud Web uses a external design library, the [ownCloud design system](https://github.com/owncloud/owncloud-design-system). Since its classes and components are available through the wrapping `web runtime`, we highly recommend you to leverage it in your extension as well.
|
||||
|
||||
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?
|
||||
### Settings
|
||||
|
||||
Short answer: any way you like
|
||||
An extension likely has some behaviour which the user can configure. Fundamental configuration will often be done by administrators during deployment, via configuration files or by setting environment variables. But for other settings, which are supposed to change more often or which are even user specific, this is not a viable way. Therefore you need to offer the users a UI where they can configure your extension to their liking. Because implementing something like this is a repetitive task among extensions, oCIS already offers the settings extensions which does that for your extension. Your extension just needs to register settings bundles, respective permissions and finally read the current values from the settings service. You can read more on that on the [settings extension]({{< ref "../../extensions/settings" >}}) and see how [oCIS Hello uses these settings](https://owncloud.dev/extensions/ocis_hello/settings/).
|
||||
|
||||
Long answer: micro and ocis-hello follow a protocol driven development:
|
||||
### Proxy
|
||||
|
||||
- specify the API using protobuf
|
||||
- generate client and server code
|
||||
- evolve based on the protocol
|
||||
The Proxy is an API gateway and acts as the single connection point where all external request from users and devices need to pass through.
|
||||
|
||||
- CS3 api uses protobuf as well and uses GRPC
|
||||
To make sure that requests can reach your extension's API, you need to register one or multiple endpoints at the proxy. The registration is a easy task and can be seen best on the [oCIS Hello example](https://owncloud.dev/extensions/ocis_hello/running/#configure-and-start-ocis).
|
||||
|
||||
- ocis uses go-micro, which provides http and grpc gateways
|
||||
- the gateways and protocols are optional
|
||||
As files in ownCloud must always stay private (unless you share them with your friends or coworkers), requests to oCIS have an authenticated user context. This user context is also available to your extension and can be used to interact with the user's files. How to get the user context and authentication can be seen on the [oCIS Hello example](https://owncloud.dev/extensions/ocis_hello/settings/#account-uuid).
|
||||
|
||||
- owncloud and kopano are looking into a [MS graph](https://developer.microsoft.com/de-de/graph) like api to handle ownCloud Web requests.
|
||||
- they might be about user, contacts, calendars ... which is covered by the graph api
|
||||
- we want to integrate with eg. kopano and provide a common api (file sync and share is covered as well)
|
||||
### Storage
|
||||
|
||||
- as an example for protobuf take a look at [ocis-hello](https://github.com/owncloud/ocis-hello/tree/master/pkg/proto/v0)
|
||||
oCIS leverages the CS3 APIs and [CS3 REVA](https://github.com/cs3org/reva) as a storage system because it offers a very flexible setup and supports a variety of storage backends like EOS, S3 and of course your local hard drive. REVA makes it easy to support more storage backends as needed.
|
||||
|
||||
If you need to interact with files directly, you have the full power of the [CS3 APIs](https://cs3org.github.io/cs3apis/) in your hand. With the user context and the user's authentication token, which your extensions gets from the proxy, your extension can make these request in behalf of the user.
|
||||
|
||||
If your extension needs to store persistent data which is not supposed to live in the user's home folder, there is also a so-called metadata storage, intended for exactly that purpose. You should always use the metadata storage in favor of the local filesystem for persistent files, because your extension will then automatically use the storage backend the oCIS admin decides to use. For a temporary cache it is perfectly fine to use the local filesystem.
|
||||
|
||||
@@ -16,7 +16,7 @@ So we are trying to reflect this in the tooling. It should be kept simple and qu
|
||||
|
||||
Besides standard development tools like git and a text editor, you need the following software for development:
|
||||
|
||||
- Go >= v1.15 ([install instructions](https://golang.org/doc/install))
|
||||
- Go >= v1.16 ([install instructions](https://golang.org/doc/install))
|
||||
- Yarn ([install instructions](https://classic.yarnpkg.com/en/docs/install))
|
||||
- docker ([install instructions](https://docs.docker.com/get-docker/))
|
||||
- docker-compose ([install instructions](https://docs.docker.com/compose/install/))
|
||||
|
||||
@@ -118,7 +118,6 @@ make test-acceptance-api \
|
||||
TEST_SERVER_URL=https://localhost:9200 \
|
||||
TEST_OCIS=true \
|
||||
SKELETON_DIR=apps/testing/data/apiSkeleton \
|
||||
DELETE_USER_DATA_CMD='rm -rf /var/tmp/ocis/storage/users/nodes/root/* /var/tmp/ocis/storage/users/nodes/*-*-*-*' \
|
||||
BEHAT_FILTER_TAGS='~@notToImplementOnOCIS&&~@toImplementOnOCIS'
|
||||
```
|
||||
|
||||
@@ -158,7 +157,6 @@ If you want to work on a specific issue
|
||||
make test-acceptance-api \
|
||||
TEST_SERVER_URL=https://localhost:9200 \
|
||||
TEST_OCIS=true \
|
||||
DELETE_USER_DATA_CMD='rm -rf /var/tmp/ocis/storage/users/nodes/root/* /var/tmp/ocis/storage/users/nodes/*-*-*-*' \
|
||||
BEHAT_FEATURE='tests/acceptance/features/apiComments/comments.feature:123'
|
||||
```
|
||||
|
||||
|
||||
@@ -9,6 +9,12 @@ geekdocFilePath: _index.md
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## oCIS online demo
|
||||
|
||||
We have an oCIS demo instance running on [ocis.owncloud.com](https://ocis.owncloud.com) where you can get a first impression of it.
|
||||
|
||||
We also have some more variations of oCIS running and [continuously deployed]({{< ref "../deployment/continuous_deployment" >}}) to reflect different scenarios in that oCIS might be used.
|
||||
|
||||
## Run oCIS
|
||||
|
||||
We are distributing oCIS as binaries and Docker images.
|
||||
@@ -16,15 +22,16 @@ We are distributing oCIS as binaries and Docker images.
|
||||
You can find more deployment examples in the [deployment section]({{< ref "../deployment" >}}).
|
||||
|
||||
### Binaries
|
||||
|
||||
You can find the latest official release of oCIS at [our download mirror](https://download.owncloud.com/ocis/ocis/) or on [GitHub](https://github.com/owncloud/ocis/releases).
|
||||
The latest build from the master branch can be found at [our download mirrors testing section](https://download.owncloud.com/ocis/ocis/testing/).
|
||||
|
||||
To run oCIS as binary you need to download it first and then run the following commands.
|
||||
For this example, assuming version 1.5.0 of oCIS running on a Linux AMD64 host:
|
||||
For this example, assuming version 1.7.0 of oCIS running on a Linux AMD64 host:
|
||||
|
||||
```console
|
||||
# download
|
||||
curl https://download.owncloud.com/ocis/ocis/1.5.0/ocis-1.5.0-linux-amd64 --output ocis
|
||||
curl https://download.owncloud.com/ocis/ocis/1.7.0/ocis-1.7.0-linux-amd64 --output ocis
|
||||
|
||||
# make binary executable
|
||||
chmod +x ocis
|
||||
@@ -39,7 +46,6 @@ The default primary storage location is `/var/tmp/ocis`. You can change that val
|
||||
oCIS by default relies on Multicast DNS (mDNS), usually via avahi-daemon. If your system has a firewall, make sure mDNS is allowed in your active zone.
|
||||
{{< /hint >}}
|
||||
|
||||
|
||||
### Docker
|
||||
|
||||
Docker images for oCIS are available on [Docker Hub](https://hub.docker.com/r/owncloud/ocis).
|
||||
|
||||
+461
-47
@@ -9,39 +9,161 @@ geekdocFilePath: migration.md
|
||||
|
||||
The migration happens in subsequent stages while the service is online. First all users need to migrate to the new architecture, then the global namespace needs to be introduced. Finally, the data on disk can be migrated user by user by switching the storage driver.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
{{< hint warning >}}
|
||||
@jfd: It might be easier to introduce the spaces api in oc10 and then migrate to ocis. We cannot migrate both at the same time, the architecture to ocis (which will change fileids) and introduce a global namespace (which requires stable fileids to let clients handle moves without redownloading). Either we implement arbitrary mounting of shares in ocis / reva or we make clients and oc10 spaces aware.
|
||||
@jfd: It might be easier to introduce the spaces api in oc10 and then migrate to oCIS. We cannot migrate both at the same time, the architecture to oCIS (which will change fileids) and introduce a global namespace (which requires stable fileids to let clients handle moves without redownloading). Either we implement arbitrary mounting of shares in oCIS / reva or we make clients and oc10 spaces aware.
|
||||
{{< /hint >}}
|
||||
|
||||
## User Stories
|
||||
- As an admin, I need to avoid downtime.
|
||||
- As an admin, I want to migrate certain groups of users before others.
|
||||
- As a user, I need a seamless migration and not lose data by any chance.
|
||||
</div>
|
||||
|
||||
## Migration Stages
|
||||
|
||||
### Stage-0
|
||||
### Stage 0: pre migration
|
||||
Is the pre-migration stage when having a functional ownCloud 10 instance.
|
||||
|
||||
### Stage-1
|
||||
Introduce OpenID Connect to ownCloud 10 server and clients.
|
||||
<div class="editpage">
|
||||
|
||||
### Stage-2
|
||||
Install and introduce ownCloud Web and let users test it voluntarily.
|
||||
#### FAQ
|
||||
_Feel free to add your question as a PR to this document using the link at the top of this page!_
|
||||
|
||||
</div>
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### Stage 1: introduce ownCloud Web
|
||||
Install and introduce [ownCloud Web](https://github.com/owncloud/web/) and let users test it voluntarily to gain early feedback on the new UI.
|
||||
|
||||
#### Steps
|
||||
Deploy web and enable switching to and from it.
|
||||
For more details see: [ownCloud 10 with ownCloud Web]({{< ref "deployment/owncloud10_with_oc_web.md" >}})
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
_TODO allow limiting the web ui switch to an 'early adopters' group_
|
||||
|
||||
</div>
|
||||
|
||||
#### Validation
|
||||
Ensure switching back an forth between the classic ownCloud 10 web UI and ownCloud web works as at our https://demo.owncloud.com.
|
||||
|
||||
#### Rollback
|
||||
Should there be problems with ownCloud web at this point it can simply be removed from the menu and be undeployed.
|
||||
|
||||
#### Notes
|
||||
<div style="break-after: avoid"></div>
|
||||
The ownCloud 10 demo instance uses OAuth to obtain a token for ownCloud web and currently always requires explicit consent. In oCIS the token is provided by the OpenID Connect Identity Provider, which may skip the consent step for trusted clients for a more seamless login experience. You may want to introduce OpenID Connect before enabling the new web UI.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
_TODO make oauth2 in oc10 trust the new web ui, based on `redirect_uri` and CSRF so no explicit consent is needed_
|
||||
|
||||
#### FAQ
|
||||
_Feel free to add your question as a PR to this document using the link at the top of this page!_
|
||||
|
||||
</div>
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### Stage 2: introduce OpenID Connect
|
||||
|
||||
Basic auth requires us to properly store and manage user credentials. Something we would rather like to delegate to a tool specifically built for that task.
|
||||
While SAML and Shibboleth are protocols that solve that problem, they are limited to web clients. Desktop and mobile clients were an afterthought and keep running into timeouts. For these reasons, we decided to move to [OpenID Connect as our primary authentication protocol](https://owncloud.com/news/openid-connect-oidc-app/).
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
_TODO @butonic add ADR for OpenID Connect_
|
||||
|
||||
</div>
|
||||
|
||||
#### User impact
|
||||
When introducing OpenID Connect, the clients will detect the new authentication scheme when their current way of authenticating returns an error. Users will then have to
|
||||
reauthorize at the OpenID Connecd IdP, which again, may be configured to skip the consent step for trusted clients.
|
||||
|
||||
#### Steps
|
||||
1. There are multiple products that can be used as an OpenID Connect IdP. We test with [kopano konnect](https://stash.kopano.io/projects/KC/repos/konnect/browse), which is also [embedded in oCIS](https://github.com/owncloud/web/). Other alternatives include [Keycloak](https://www.keycloak.org/) or [Ping](https://www.pingidentity.com/). Please refer to the corresponding setup instructions for the product you intent to use.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
_TODO @butonic flesh out oCIS IDP documentation_
|
||||
|
||||
</div>
|
||||
|
||||
2. Add [Openid Connect (OIDC)](https://doc.owncloud.com/server/admin_manual/configuration/user/oidc/) support to ownCloud 10.
|
||||
|
||||
#### Validation
|
||||
When OpenID Connect support is enabled verify that all clients can login:
|
||||
- web classic
|
||||
- ownCloud web
|
||||
- desktop
|
||||
- android
|
||||
- iOS
|
||||
|
||||
#### Rollback
|
||||
Should there be problems with OpenID Connect at this point you can disable the app. Users will have to reauthenticate in this case.
|
||||
|
||||
#### Notes
|
||||
<div style="break-after: avoid"></div>
|
||||
Legacy clients relying on Basic auth or app passwords need to be migrated to OpenId Connect to work with oCIS. For a transition period Basic auth in oCIS can be enabled with `PROXY_ENABLE_BASIC_AUTH=true`, but we strongly recommend adopting OpenID Connect for other tools as well.
|
||||
|
||||
While OpenID Connect providers will send an `iss` and `sub` claim that relying parties (services like oCIS or ownCloud 10) can use to identify users we recommend introducing a dedicated, globally unique, persistent, non-reassignable user identifier like a UUID for every user. This `ownclouduuid` shold be sent as an additional claim to save additional lookups on the server side. It will become the user id in oCIS, e.g. when searching for recipients the `ownclouduuid` will be used to persist permissions with the share manager. It has a different purpose than the ownCloud 10 username, which is used to login. Using UUIDs we can not only mitigate username collisions when merging multiple instances but also allow renaming usernames after the migration to oCIS has been completed.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
#### FAQ
|
||||
_Feel free to add your question as a PR to this document using the link at the top of this page!_
|
||||
|
||||
</div>
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### Stage 3: introduce oCIS interally
|
||||
|
||||
Befor letting oCIS handle end user requests we will first make it available in the internal network. By subsequently adding services we can add functionality and verify the services work as intended.
|
||||
|
||||
Start oCIS backend and make read only tests on existing data using the `owncloudsql` storage driver which will read (and write)
|
||||
- blobs from the same datadirectory layout as in ownCloud 10
|
||||
- metadata from the ownCloud 10 database:
|
||||
The oCIS share manager will read share information from the ownCloud database using an `owncloud` driver as well.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
_TODO @butonic add guide on how to configure `owncloudsql`_
|
||||
|
||||
_TODO we need a share manager that can read from the ownCloud 10 database as well as from whatever new backend will be used for a pure oCIS setup. Currently, that would be the json file. Or that is migrated after all users have switched to oCIS. -- jfd_
|
||||
|
||||
</div>
|
||||
|
||||
#### User impact
|
||||
None, only administrators will be able to explore oCIS during this stage.
|
||||
|
||||
#### Steps and verifications
|
||||
|
||||
We are going to run and explore a series of services that will together handle the same requests as ownCloud 10. For initial exploration the oCIS binary is recommended. The services can later be deployed using a single oCIS runtime or in multiple cotainers.
|
||||
|
||||
|
||||
##### Storage provider for file metadata
|
||||
1. Deploy OCIS storage provider with owncloudsql driver.
|
||||
2. Set `read_only: true` in the storage provider config. <div class="editpage">_TODO @butonic add read only flag to storage drivers_</div>
|
||||
3. Use cli tool to list files using the CS3 api
|
||||
|
||||
##### File ID alternatives
|
||||
Multiple ownCloud instances can be merged into one oCIS instance. To prevent the numeric ids from colliding, the file ids will be prefixed with a new storage space id which is used by oCIS to route requests to the correct storage provider. See Stage 8 below.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
{{< hint warning >}}
|
||||
**Alternative 1**
|
||||
Add a routable prefix to fileids in oc10, and replicate the prefix in ocis.
|
||||
### Stage-2.1
|
||||
Add a routable prefix to fileids in oc10, and replicate the prefix in oCIS.
|
||||
### Stage-3.1
|
||||
Let oc10 render file ids with prefixes: `<instance name>$<numeric storageid>!<fileid>`. This will allow clients to handle moved files.
|
||||
|
||||
### Stage-2.2
|
||||
### Stage-3.2
|
||||
Roll out new clients that understand the spaces API and know how to convert local sync pairs for legacy oc10 `/webdav` or `/dav/files/<username>` home folders into multiple sync pairs.
|
||||
One pair for `/webdav/home` or `/dav/files/<username>/home` and another pair for every accepted share. The shares will be accessible at `/webdav/shares/` when the server side enables the spaces API.
|
||||
Files can be identified using `<instance name>$<numeric storageid>!<fileid>` and moved to the correct sync pair.
|
||||
|
||||
### Stage-2.3
|
||||
### Stage-3.3
|
||||
Enable spaces API in oc10:
|
||||
- New clients will get a response from the spaces API and can set up new sync pairs.
|
||||
- Legacy clients will still poll `/webdav` or `/dav/files/<username>` where they will see new subfolders instead of the users home. They will move down the users files into `/home` and shares into `/shares`. Custom sync pairs will no longer be available, causing the legacy client to leave local files in place. They can be picked up manually when installing a new client.
|
||||
@@ -51,48 +173,307 @@ Enable spaces API in oc10:
|
||||
{{< hint warning >}}
|
||||
**Alternative 2**
|
||||
An additional `uuid` property used only to detect moves. A lookup by uuid is not necessary for this. The `/dav/meta` endpoint would still take the fileid. Clients would use the `uuid` to detect moves and set up new sync pairs when migrating to a global namespace.
|
||||
### Stage-2.1
|
||||
### Stage-3.1
|
||||
Generate a `uuid` for every file as a file property. Clients can submit a `uuid` when creating files. The server will create a `uuid` if the client did not provide one.
|
||||
|
||||
### Stage-2.2
|
||||
### Stage-3.2
|
||||
Roll out new clients that understand the spaces API and know how to convert local sync pairs for legacy oc10 `/webdav` or `/dav/files/<username>` home folders into multiple sync pairs.
|
||||
One pair for `/webdav/home` or `/dav/files/<username>/home` and another pair for every accepted share. The shares will be accessible at `/webdav/shares/` when the server side enables the spaces API. Files can be identified using the `uuid` and moved to the correct sync pair.
|
||||
|
||||
### Stage-3.1
|
||||
When reading the files from ocis return the same `uuid`. It can be migrated to an extended attribute or it can be read from oc10. If users change it the client will not be able to detect a move and maybe other weird stuff happens. *What if the uuid gets lost on the server side due to a partial restore?*
|
||||
### Stage-4.1
|
||||
When reading the files from oCIS return the same `uuid`. It can be migrated to an extended attribute or it can be read from oc10. If users change it the client will not be able to detect a move and maybe other weird stuff happens. *What if the uuid gets lost on the server side due to a partial restore?*
|
||||
|
||||
{{< /hint >}}
|
||||
</div>
|
||||
|
||||
### Stage-3
|
||||
Start oCIS backend and make read only tests on existing data using the `owncloud` storage driver which will read (and write)
|
||||
- blobs from the same datadirectory layout as in ownCloud 10
|
||||
- metadata from the ownCloud 10 database:
|
||||
The oCIS share manager will read share information from the ownCloud database as well.
|
||||
|
||||
Therefore we need:
|
||||
- [ ] *a share manager that can read from the ownCloud 10 database as well as from whatever new backend will be used for a pure oCIS setup. Currently, that would be the json file. Or that is migrated after all users have switched to oCIS. -- jfd*
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### Stage-4
|
||||
Test writing data with oCIS into the existing ownCloud 10 data directory using the `owncloud` storage driver.
|
||||
##### graph API endpoint
|
||||
1. Deploy graph api to list spaces
|
||||
2. Use curl to list spaces using graph drives endpoint
|
||||
|
||||
### Stage-5
|
||||
Introduce reverse proxy and switch over early adopters, let admins gain trust in the new backend by comparing metrics of the two systems and having it running in parallel.
|
||||
##### owncloud flavoured WebDAV endpoint
|
||||
1. Deploy Ocdav
|
||||
2. Use curl to send PROPFIND
|
||||
|
||||
### Stage-6
|
||||
Voluntary transition period and subsequent hard deadline for all users
|
||||
##### data provider for up and download
|
||||
1. Deploy dataprovider
|
||||
2. Use curl to up and download files
|
||||
3. Use tus to upload files
|
||||
|
||||
### Stage-7
|
||||
Deploy ...
|
||||
|
||||
##### share manager
|
||||
Deploy share manager with owncloud driver
|
||||
|
||||
##### reva gateway
|
||||
1. Deploy gateway to authenticate requests? I guess we need that first... Or we need the to mint a token. Might be a good exercise.
|
||||
|
||||
##### automated deployment
|
||||
Finally, deploy OCIS with a config to set up everything running in a single oCIS runtime or in multiple containers.
|
||||
|
||||
#### Rollback
|
||||
You can stop the oCIS process at any time.
|
||||
|
||||
#### Notes
|
||||
<div style="break-after: avoid"></div>
|
||||
Multiple ownCloud instances can be merged into one oCIS instance. The file ids will be prefixed with a new storage space id which is used to route requests to the correct storage provider.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
#### FAQ
|
||||
_Feel free to add your question as a PR to this document using the link at the top of this page!_
|
||||
|
||||
</div>
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### Stage 4: internal write access with oCIS
|
||||
Test writing data with oCIS into the existing ownCloud 10 data directory using the `owncloudsql` storage driver.
|
||||
|
||||
#### User impact
|
||||
Only administrators will be able to explore oCIS during this stage. End users should not be affected if the testing is limited to test users.
|
||||
|
||||
#### Steps
|
||||
Set `read_only: false` in the storage provider config.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
_TODO @butonic add read only flag to storage drivers_
|
||||
|
||||
</div>
|
||||
|
||||
#### Verification
|
||||
#### Rollback
|
||||
Set `read_only: true` in the storage provider config.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
_TODO @butonic add read only flag to storage drivers_
|
||||
|
||||
</div>
|
||||
|
||||
#### Notes
|
||||
<div style="break-after: avoid"></div>
|
||||
With write access it becomes possible to manipulate existing files and shares.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
#### FAQ
|
||||
_Feel free to add your question as a PR to this document using the link at the top of this page!_
|
||||
|
||||
</div>
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### Stage-5: introduce user aware proxy
|
||||
In the previous stages oCIS was only accessible for administrators with access to the network. To expose only a single service to the internet, oCIS comes with a user aware proxy that can be used to route requests to the existing ownCloud 10 installation or oCIS, based on the authenticated user. The proxy uses OIDC to identify the logged in user and route them to the configured backend.
|
||||
|
||||
#### User impact
|
||||
The IP address of the ownCloud host changes. There is no change for the file sync and share functionality when requests are handled by the oCIS codebase as it uses the same database and storage system as owncloud 10.
|
||||
|
||||
#### Steps and verifications
|
||||
|
||||
##### Deploy oCIS proxy
|
||||
1. Deploy the `ocis proxy`
|
||||
2. Verify the requests are routed based on the ownCloud 10 routing policy `oc10` by default
|
||||
|
||||
##### Test user based routing
|
||||
1. Change the routing policy for a user or an early adoptors group to `ocis` <div class="editpage">_TODO @butonic currently, the migration selector will use the `ocis` policy for users that have been added to the accounts service. IMO we need to evaluate a claim from the IdP._</div>
|
||||
2. Verify the requests are routed based on the oCIS routing policy `oc10` for 'migrated' users.
|
||||
|
||||
At this point you are ready to rock & roll!
|
||||
|
||||
##### Let ownCloud domain point to proxy
|
||||
1. Update the dns to use the oCIS proxy instead of the ownCloud application servers directly.
|
||||
2. Let DNS propagate the change and monitor requests moving from the ownCloud application servers to the oCIS proxy.
|
||||
3. Verify the DNS change has propagated sufficiently. All requests should now use the oCIS Proxy.
|
||||
|
||||
#### Rollback
|
||||
Should there be a problem with the oCIS routes the user can be routed to ownCloud by changing his routing policy. In case of unfixable problems with the proxy the DNS needs to be updated to use the ownCloud 10 application servers directly. This could also be done in a load balancer.
|
||||
|
||||
#### Notes
|
||||
<div style="break-after: avoid"></div>
|
||||
The proxy is stateless, multiple instances can be deployed as needed.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
#### FAQ
|
||||
_Feel free to add your question as a PR to this document using the link at the top of this page!_
|
||||
|
||||
</div>
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### Stage-6: parallel deployment
|
||||
Running ownCloud 10 and oCIS in parallel is a crucial stage for the migration: it allows users access to group shares regardless of the system that is being used to to access the data. A user by user migration with multiple domains would technically break group shares when users vanish because they (and their data) are no longer available in the old system.
|
||||
|
||||
Depending on the amount of power users on an instance, the admin may want to allow users to voluntarily migrate to the oCIS backend. A monitoring system can be used to visualize the behavior for the two systems and gain trust in the overall stability and performance.
|
||||
|
||||
#### User impact
|
||||
Since the underling data is still stored in the same systems, a similar or performance can be expected.
|
||||
<div class="editpage">
|
||||
|
||||
See _TODO hmpf outdated didn't we want to run them nightly? ..._
|
||||
_TODO @butonic update performance comparisons nightly_
|
||||
|
||||
</div>
|
||||
|
||||
#### Steps
|
||||
There are several options to move users to the oCIS backend:
|
||||
- Use a canary app to let users decide thamselves
|
||||
- Use an early adoptors group with an opt in
|
||||
- Force migrate users in batch or one by one at the administrators will
|
||||
|
||||
#### Verification
|
||||
The same verification steps as for the internal testing stage apply. Just from the outside.
|
||||
|
||||
#### Rollback
|
||||
Until now, the oCIS configuration mimics ownCloud 10 and uses the old data directory layout and the ownCloud 10 database. Users can seamlessly be switched from ownCloud 10 to oCIS and back again.
|
||||
<div class="editpage">
|
||||
|
||||
_TODO @butonic we need a canary app that allows users to decide for themself which backend to use_
|
||||
|
||||
</div>
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
#### Notes
|
||||
Running the two systems in parallel stage
|
||||
Try to keep the duration of this stage short. Until now we only added services and made the system more complex. oCIS aims to reduce the maintenance cost of an ownCloud instance. You will not get there if you keep both systems alive.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
#### FAQ
|
||||
_Feel free to add your question as a PR to this document using the link at the top of this page!_
|
||||
|
||||
</div>
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### Stage-7: shut down ownCloud 10
|
||||
Disable ownCloud 10 in the proxy, all requests are now handled by oCIS, shut down oc10 web servers and redis (or keep for calendar & contacts only? rip out files from oCIS?)
|
||||
|
||||
### Stage-8
|
||||
User by user storage migration from `owncloud` driver to `ocis`/`s3ng`/`cephfs`...
|
||||
#### User impact
|
||||
All users are already sent to the oCIS backend. Shutting down ownCloud 10 will remove the old web UI, apps and functionality that is not yet present in ownCloud web. For example contacts and calendar.
|
||||
|
||||
### Stage-9
|
||||
Migrate share data to <yet to determine> share manager backend and shut down ownCloud database
|
||||
<div class="editpage">
|
||||
|
||||
_TODO @butonic recommend alternatives_
|
||||
|
||||
</div>
|
||||
|
||||
#### Steps
|
||||
1. Shut down the apache servers that are running the ownCloud 10 PHP code.
|
||||
2. DO NOT SHUT DOWN THE DATABASE, YET!
|
||||
|
||||
#### Verification
|
||||
The ownCloud 10 classic web UI should no longer be reachable.
|
||||
|
||||
#### Rollback
|
||||
Redeploy ownCloud 10.
|
||||
|
||||
#### Notes
|
||||
<div style="break-after: avoid"></div>
|
||||
The database needs to remain online until the storage layer and share metadata have been migrated as well. One thing at a time.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
#### FAQ
|
||||
_Feel free to add your question as a PR to this document using the link at the top of this page!_
|
||||
|
||||
</div>
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### Stage 8: storage migration
|
||||
To get rid of the database we will move the metadata from the old ownCloud 10 database into dedicated storage providers. This can happen in a user by user fashion. group drives can properly be migrated to group, project or workspaces in this stage.
|
||||
|
||||
#### User impact
|
||||
Noticeable performance improvements because we effectively shard the storage logic and persistence layer.
|
||||
|
||||
#### Steps
|
||||
1. User by user storage migration from `owncloud` or `ownclouds3` driver to `ocis`/`s3ng`/`cephfs`... currently this means copying the metadata from one storage provider to another using the cs3 api.
|
||||
2. Change the responsible storage provider for a storage space (e.g. a user home, a group or project space are a workspace) in the storage registry.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
_TODO @butonic implement `ownclouds3` based on `s3ng`_
|
||||
_TODO @butonic implement tiered storage provider for seamless migration_
|
||||
_TODO @butonic document how to manually do that until the storge registry can discover that on its own._
|
||||
|
||||
</div>
|
||||
|
||||
#### Verification
|
||||
Start with a test user, then move to early adoptors and finally migrate all users.
|
||||
|
||||
#### Rollback
|
||||
To switch the storage provider again the same storage space migration can be performed again: copy medatata and blob data using the CS3 api, then change the responsible storage provider in the storage registry.
|
||||
|
||||
#### Notes
|
||||
<div style="break-after: avoid"></div>
|
||||
Multiple ownCloud instances can be merged into one oCIS instance. The file ids will be prefixed with a new storage space id which is used to route requests to the correct storage provider.
|
||||
|
||||
The storage space migration will become a seamless feature in the future that allows administrators to move users to storage systems with different capabilities, to implement premium features, deprovisioning strategies or archiving.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
#### FAQ
|
||||
_Feel free to add your question as a PR to this document using the link at the top of this page!_
|
||||
|
||||
</div>
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### Stage-9: share metadata migration
|
||||
Migrate share data to _yet to determine_ share manager backend and shut down ownCloud database.
|
||||
|
||||
The ownCloud 10 database still holds share information in the `oc_share` and `oc_share_external` tables. They are used to efficiently answer queries about who shared what with whom. In oCIS shares are persisted using a share manager and if desired these grants are also sent to the storage provider so it can set ACLs if possible. Only one system should be responsible for the shares, which in case of treating the storage as the primary source effectively turns the share manager into a cache.
|
||||
|
||||
#### User impact
|
||||
Depending on chosen the share manager provider some sharing requests should be faster: listing incoming and outgoing shares is no longer bound to the ownCloud 10 database but to whatever technology is used by the share provdier:
|
||||
- For non HA scenarios they can be served from memory, backed by a simple json file.
|
||||
- TODO: implement share manager with redis / nats / ... key value store backend: use the micro store interface please ...
|
||||
|
||||
#### Steps
|
||||
1. Start new share manager
|
||||
2. Migrate metadata using the CS3 API (copy from old to new)
|
||||
3. Shut down old share manager
|
||||
4. Shut down ownCloud 10 database
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
_TODO for HA implement share manager with redis / nats / ... key value store backend: use the micro store interface please ..._
|
||||
_TODO for batch migration implement share data migration cli with progress that reads all shares via the cs3 api from one provider and writes them into another provider_
|
||||
_TODO for seamless migration implement tiered/chained share provider that reads share data from the old provider and writes newc shares to the new one_
|
||||
_TODO for storage provider as source of truth persist ALL share data in the storage provider. Currently, part is stored in the share manager, part is in the storage provider. We can keep both, but the the share manager should directly persist its metadata to the storage system used by the storage provider so metadata is kept in sync_
|
||||
|
||||
</div>
|
||||
|
||||
#### Verification
|
||||
After copying all metadata start a dedicated gateway and change the configuration to use the new share manager. Route a test user, a test group and early adoptors to the new gateway. When no problems occur you can stirt the desired number of share managers and roll out the change to all gateways.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
_TODO let the gateway write updates to multiple share managers ... or rely on the tiered/chained share manager provider to persist to both providers_
|
||||
|
||||
</div>
|
||||
|
||||
#### Rollback
|
||||
To switch the share manager to the database one revert routing users to the new share manager. If you already shut down the old share manager start it again. Use the tiered/chained share manager provider in reverse configuration (new share provider as read only, old as write) and migrate the shares again. You can alse restore a database backup if needed.
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
### Stage-10
|
||||
Profit! (db for file metadata no longer necessary, less maintenance effort)
|
||||
Profit! Well, on the one hand you do not need to maintain a clustered database setup and can rely on the storage system. On the other hand you are now in microservice wonderland and will have to relearn how to identify bottlenecks and scale oCIS accordingly. The good thing is that tools like jaeger and prometheus have evolved and will help you understand what is going on. But this is a different Topic. See you on the other side!
|
||||
|
||||
#### FAQ
|
||||
_Feel free to add your question as a PR to this document using the link at the top of this page!_
|
||||
|
||||
</div>
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
## Architectural differences
|
||||
|
||||
@@ -156,9 +537,11 @@ The three types of blobs we need to migrate are stored in
|
||||
- `files_trashbin` for trashed files (and their versions) and
|
||||
- `files_versions` for file blobs of older versions.
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### Filecache table
|
||||
|
||||
In both cases the file metadata, including a full replication of the file tree, is stored in the `oc_filecache` table of an ownCloud 10 database. The primary key of a row is the file id. It is used to attach additional metadata like shares, tags, favorites or arbitrary file properties.
|
||||
In both cases the file metadata, including a full replication of the file tree, is stored in the `oc_filecache` table of an ownCloud 10 database. The primary key of a row is the file id. It is used to attach additional metadata like shares, tags, favorites or arbitrary file properties.
|
||||
|
||||
The `filecache` table itself has more metadata:
|
||||
|
||||
@@ -184,6 +567,8 @@ The `filecache` table itself has more metadata:
|
||||
|
||||
> Note: for EOS a hot migration only works seamlessly if file ids in oc10 are already read from eos. otherwise either a mapping from the oc10 filecache file id to the new eos file id has to be created under the assumption that these id sets do not intersect or files and corresponding shares need to be exported and imported offline to generate a new set of ids. While this will preserve public links, user, group and even federated shares, old internal links may still point to different files because they contain the oc10 fileid
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### share table
|
||||
|
||||
used to store
|
||||
@@ -202,7 +587,7 @@ used to store
|
||||
| `item_type` | varchar(64) | NO | MUL | | | | `Share.resource_id` [`ResourceId`](https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId) |
|
||||
| `item_source` | varchar(255) | YES | MUL | NULL | | | `Share.resource_id` [`ResourceId`](https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId) |
|
||||
| `item_target` | varchar(255) | YES | | NULL | | | `Share.resource_id` [`ResourceId`](https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId) |
|
||||
| `file_source` | bigint(20) | YES | MUL | NULL | | *cannot store uuid style file ids from ocis. when all users have migrated to ocis the share manager needs to be updated / migrated to a version that does.* | `Share.resource_id` [`ResourceId`](https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId) |
|
||||
| `file_source` | bigint(20) | YES | MUL | NULL | | *cannot store uuid style file ids from oCIS. when all users have migrated to oCIS the share manager needs to be updated / migrated to a version that does.* | `Share.resource_id` [`ResourceId`](https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId) |
|
||||
| `file_target` | varchar(512) | YES | | NULL | | | `Share.resource_id` [`ResourceId`](https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId) |
|
||||
| `permissions` | smallint(6) | NO | | 0 | | | `Share.Permissions` [`SharePermissions`](https://cs3org.github.io/cs3apis/#cs3.sharing.ocm.v1beta1.SharePermissions) |
|
||||
| `stime` | bigint(20) | NO | | 0 | | | `Share.ctime`, `Share.mtime` |
|
||||
@@ -220,6 +605,8 @@ In the CS3 API
|
||||
3. federated shares are handled by the OcmShareProvider using the [OCM Share Provider AP](https://cs3org.github.io/cs3apis/#cs3.sharing.ocm.v1beta1.OcmAPI) aka. Open Cloud Mesh.
|
||||
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### share_external
|
||||
|
||||
Used to store additional metadata for federated shares.
|
||||
@@ -238,7 +625,13 @@ Used to store additional metadata for federated shares.
|
||||
| `remote_id` | varchar(255) | NO | | -1 | | |
|
||||
| `accepted` | int(11) | NO | | 0 | | |
|
||||
|
||||
*TODO document how the reva OCM service currently persists the data*
|
||||
<div class="editpage">
|
||||
|
||||
_TODO document how the reva OCM service currently persists the data_
|
||||
|
||||
</div>
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### trusted_servers
|
||||
|
||||
@@ -254,16 +647,26 @@ used to determine if federated shares can automatically be accepted
|
||||
| `status` | int(11) | NO | | 2 | | current status of the connection |
|
||||
| `sync_token` | varchar(512) | YES | | NULL | | cardDav sync token |
|
||||
|
||||
*TODO clarify how OCM handles this and where we store / configure this. It seems related to trusted IdPs*
|
||||
<div class="editpage">
|
||||
|
||||
_TODO clarify how OCM handles this and where we store / configure this. It seems related to trusted IdPs_
|
||||
|
||||
</div>
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### user data
|
||||
|
||||
Users are migrated in two steps:
|
||||
1. They should all be authenticated using openid connect, which already moves them to a common identity management system.
|
||||
1. They should all be authenticated using OpenID Connect, which already moves them to a common identity management system.
|
||||
2. To search share recipients, both, ownCloud 10 and oCIS need access to the same user directory using eg. LDAP.
|
||||
|
||||
*TODO: add state to CS3 API, so we can 'disable' users*
|
||||
*TODO: how do we map (sub) admins? -> map to roles & permissions*
|
||||
<div class="editpage">
|
||||
|
||||
_TODO add state to CS3 API, so we can 'disable' users_
|
||||
_TODO how do we map (sub) admins? -> map to roles & permissions_
|
||||
|
||||
</div>
|
||||
|
||||
accounts:
|
||||
|
||||
@@ -296,13 +699,22 @@ The groups table really only contains the group name.
|
||||
|-------|-------------|------|-----|---------|-------|
|
||||
| `gid` | varchar(64) | NO | PRI | | |
|
||||
|
||||
<div style="break-after: page"></div>
|
||||
|
||||
### LDAP
|
||||
|
||||
TODO clarify if metadata from ldap & user_shibboleth needs to be migrated
|
||||
- the `dn` -> *owncloud internal username* mapping that currently lives in the `oc_ldap_user_mapping` table needs to move into a dedicated ownclouduuid attribute in the LDAP server. The idp should send it as a claim so the proxy does not have to look up the user using LDAP again. The username cannot be changed in ownCloud 10 and the oCIS provisioning API will not allow changing it as well. When we introduce the graph api we may allow changing usernames when all clients have moved to that api.
|
||||
<div class="editpage">
|
||||
|
||||
The problem is that the username in owncloud 10 and in oCIS also need to be the same, which might not be the case when the ldap mapping used a different column. In that case we should add another owncloudusername attribute to the ldap server ...
|
||||
_TODO clarify if metadata from ldap & user_shibboleth needs to be migrated_
|
||||
|
||||
</div>
|
||||
|
||||
The `dn` -> *owncloud internal username* mapping that currently lives in the `oc_ldap_user_mapping` table needs to move into a dedicated ownclouduuid attribute in the LDAP server. The idp should send it as a claim so the proxy does not have to look up the user using LDAP again. The username cannot be changed in ownCloud 10 and the oCIS provisioning API will not allow changing it as well. When we introduce the graph api we may allow changing usernames when all clients have moved to that api.
|
||||
|
||||
The problem is that the username in owncloud 10 and in oCIS also need to be the same, which might not be the case when the ldap mapping used a different column. In that case we should add another owncloudusername attribute to the ldap server.
|
||||
|
||||
|
||||
<div class="editpage">
|
||||
|
||||
### activities
|
||||
|
||||
@@ -329,3 +741,5 @@ The problem is that the username in owncloud 10 and in oCIS also need to be the
|
||||
## Links
|
||||
|
||||
The [data_exporter](https://github.com/owncloud/data_exporter) has logic that allows exporting and importing users, including shares. The [model classes](https://github.com/owncloud/data_exporter/tree/master/lib/Model) contain the exact mapping.
|
||||
|
||||
</div>
|
||||
+100
-5
@@ -7,6 +7,101 @@ geekdocEditPath: edit/master/docs/ocis
|
||||
geekdocFilePath: release_notes.md
|
||||
---
|
||||
|
||||
## ownCloud Infinite Scale 1.8.0 Technology Preview
|
||||
|
||||
Version 1.8.0 is a maintenance and bug fix release. ownCloud Web 3.3.0 has received further performance and major accessibility improvements.
|
||||
|
||||
The most prominent changes in version 1.8.0 comprise:
|
||||
|
||||
- ownCloud Web is now fully translatable on Transifex [#5042](https://github.com/owncloud/web/pull/5042)
|
||||
- ownCloud Web now supports keyboard navigation [#4937](https://github.com/owncloud/web/pull/4937) [#5013](https://github.com/owncloud/web/pull/5013) [#5027](https://github.com/owncloud/web/pull/5027) [#5147](https://github.com/owncloud/web/pull/5147)
|
||||
- ownCloud Web now supports screenreaders [#5182](https://github.com/owncloud/web/pull/5182) [#5166](https://github.com/owncloud/web/pull/5166) [#5058](https://github.com/owncloud/web/pull/5058) [#5046](https://github.com/owncloud/web/pull/5046) [#5010](https://github.com/owncloud/web/pull/5010)
|
||||
- ownCloud Web has received many performance improvements (image cache, fixes to avoid duplicate resource loading, asynchronous image loading) [#5194](https://github.com/owncloud/web/pull/5194)
|
||||
- The file lists in ownCloud Web are now paginated to control loading times [#5224](https://github.com/owncloud/web/pull/5224) [#5309](https://github.com/owncloud/web/pull/5309)
|
||||
- ownCloud Web now supports TypeScript [#5194](https://github.com/owncloud/web/pull/5194)
|
||||
|
||||
You can also read the full [ownCloud Infinite Scale changelog](https://github.com/owncloud/ocis/releases/tag/v1.8.0) and [ownCloud Web changelog](https://github.com/owncloud/web/releases/tag/v3.3.0) for further details on what has changed.
|
||||
|
||||
### Breaking changes
|
||||
{{< hint warning >}}
|
||||
We are currently in a Tech Preview state and breaking changes may occur at any time. For more information see our [release roadmap]({{< ref "./release_roadmap" >}})
|
||||
{{< /hint >}}
|
||||
|
||||
## ownCloud Infinite Scale 1.7.0 Technology Preview
|
||||
|
||||
Version 1.7.0 is a maintenance and bug fix release. ownCloud Web 3.2.0 has received further performance improvements and minor usability tweaks.
|
||||
|
||||
The most prominent changes in version 1.7.0 comprise:
|
||||
|
||||
- The S3 storage driver can now be used for testing using the configuration values in the [documentation](https://owncloud.dev/extensions/storage/configuration/#s3ng-driver) [#1886](https://github.com/owncloud/ocis/pull/1886)
|
||||
- A confirmation dialog for public link deletion has been added [#5125](https://github.com/owncloud/web/pull/5125)
|
||||
- To improve performance, the file types which are being rendered as previews can now be specified using an [allow list in config.json](https://owncloud.dev/clients/web/getting-started/#options) [#5159](https://github.com/owncloud/web/pull/5159)
|
||||
- A warning has been added when a user tries to leave the page while an operation is in progress (e.g., an upload) [#2590](https://github.com/owncloud/web/issues/2590)
|
||||
|
||||
You can also read the full [ownCloud Infinite Scale changelog](https://github.com/owncloud/ocis/releases/tag/v1.7.0) and [ownCloud Web changelog](https://github.com/owncloud/web/releases/tag/v3.2.0) for further details on what has changed.
|
||||
|
||||
### Breaking changes
|
||||
{{< hint warning >}}
|
||||
We are currently in a Tech Preview state and breaking changes may occur at any time. For more information see our [release roadmap]({{< ref "./release_roadmap" >}})
|
||||
{{< /hint >}}
|
||||
|
||||
## ownCloud Infinite Scale 1.6.0 Technology Preview
|
||||
|
||||
To get the full potential out of the microservice architecture, version 1.6.0 introduces a dynamic service registry to ownCloud Infinite Scale. The dynamic service registry facilitates the configuration and contributes to the scalability of the platform. ownCloud Web 3.1.0 has received further improvements for accessibility like keyboard navigation and it comes with performance improvements by loading certain elements asynchronously.
|
||||
|
||||
The most prominent changes in version 1.6.0 comprise:
|
||||
|
||||
- Introducing a dynamic service registry: The dynamic service registry takes care of dynamically assigning network addresses between the oCIS services and enables the services to find and work with each other automatically. It replaces the previous hardcoded service configuration which simplifies the initial setup and makes distributed, scale-out environments a lot easier to handle. [#1509](https://github.com/cs3org/reva/pull/1509)
|
||||
- User avatars are now fetched asynchronously, enabling a non-blocking loading of the file list and improving user experience [#1295](https://github.com/owncloud/owncloud-design-system/pull/1295)
|
||||
- Further accessibility and keyboard navigation improvements have been added [#1979](https://github.com/owncloud/ocis/pull/1979) [#1991](https://github.com/owncloud/ocis/pull/1991) [#4942](https://github.com/owncloud/web/pull/4942) [#4965](https://github.com/owncloud/web/pull/4965) [#4991](https://github.com/owncloud/web/pull/4991)
|
||||
- The OCS user deprovisioning endpoint has been added, enabling a full user deprovisioning including storage. [#1962](https://github.com/owncloud/ocis/pull/1962)
|
||||
- Text files (.txt) now have previews (thumbnails) [#1988](https://github.com/owncloud/ocis/pull/1988)
|
||||
- The translations in the Settings and Accounts extensions have been improved [#2003](https://github.com/owncloud/ocis/pull/2003)
|
||||
|
||||
You can also read the full [ownCloud Infinite Scale changelog](https://github.com/owncloud/ocis/releases/tag/v1.6.0) and [ownCloud Web changelog](https://github.com/owncloud/web/releases/tag/v3.1.0) for further details on what has changed.
|
||||
|
||||
### Breaking changes
|
||||
{{< hint warning >}}
|
||||
We are currently in a Tech Preview state and breaking changes may occur at any time. For more information see our [release roadmap]({{< ref "./release_roadmap" >}})
|
||||
{{< /hint >}}
|
||||
|
||||
#### Changed oCIS JSON share driver storage format
|
||||
|
||||
Related: [#1655](https://github.com/cs3org/reva/pull/1655)
|
||||
|
||||
The storage format of the oCIS JSON share driver has changed. You will be affected if you plan to update from a previous version of oCIS to oCIS 1.6.0, you have shared files or folders with users or groups and you are using the oCIS JSON share driver, which is currently the default share driver.
|
||||
|
||||
Implications:
|
||||
- manual action required
|
||||
|
||||
Our recommended update strategy to oCIS 1.6.0 is:
|
||||
1. let users note all their shares with users and groups they set up in oCIS
|
||||
1. stop oCIS
|
||||
1. move / delete the JSON share driver storage file `/var/tmp/ocis/storage/shares.json`
|
||||
1. update to oCIS 1.6.0
|
||||
1. let users recreate their shares
|
||||
|
||||
#### Fixed / changed oCIS metadata storage driver filesystem path
|
||||
Related: [#1956](https://github.com/owncloud/ocis/pull/1956)
|
||||
|
||||
The filesystem path of the oCIS metadata storage driver has changed (been fixed). You will be affected if you plan to update from a previous version of oCIS to oCIS 1.6.0 and are using the oCIS storage driver for metadata storage.
|
||||
|
||||
Implications:
|
||||
- manual action required
|
||||
|
||||
Our recommended update strategy to oCIS 1.6.0 is:
|
||||
1. let users backup all their data stored in oCIS
|
||||
1. stop oCIS
|
||||
1. prune all oCIS data in `/var/tmp/ocis`
|
||||
1. update to oCIS 1.6.0
|
||||
1. recreate user accounts (can be skipped if an external IDP is used)
|
||||
1. let users upload all their data again
|
||||
1. let users recreate their shares
|
||||
|
||||
If you want to use oCIS 1.6.0 without following our recommended update strategy, you can also keep the pre 1.6.0 behaviour by setting this environment variable:
|
||||
`export STORAGE_METADATA_ROOT=/var/tmp/ocis/storage/users`
|
||||
This may lead to faulty behaviour since both the metadata and user storage driver will be storing their data in the same filesystem path.
|
||||
|
||||
## ownCloud Infinite Scale 1.5.0 Technology Preview
|
||||
|
||||
Version 1.5.0 is a maintenance release for the Infinite Scale backend with a number of bug fixes and smaller improvements. For ownCloud Web it brings further accessibility improvements and a whole bunch of new features. The web interface can now be branded and there is a new, dedicated view in the left sidebar to list all link shares of a user.
|
||||
@@ -20,7 +115,7 @@ The most prominent changes in version 1.5.0 comprise:
|
||||
- User storage quotas will now be enforced [#1557](https://github.com/cs3org/reva/pull/1557)
|
||||
- The "owncloud" storage driver now supports file integrity checking with checksums [#1629](https://github.com/cs3org/reva/pull/1629)
|
||||
|
||||
You can also read the full [ownCloud Infinite Scale changelog](https://github.com/owncloud/ocis/blob/master/CHANGELOG.md) and [ownCloud Web changelog](https://github.com/owncloud/web/blob/master/CHANGELOG.md) for further details on what has changed.
|
||||
You can also read the full [ownCloud Infinite Scale changelog](https://github.com/owncloud/ocis/releases/tag/v1.5.0) and [ownCloud Web changelog](https://github.com/owncloud/web/releases/tag/v3.0.0) for further details on what has changed.
|
||||
|
||||
### Breaking changes
|
||||
{{< hint warning >}}
|
||||
@@ -42,7 +137,7 @@ The most prominent changes in version 1.4.0 comprise:
|
||||
- Added GIF and JPEG file types for thumbnail generation (allows to display thumbnails and use the media viewer for GIF/JPEG images) [#1791](https://github.com/owncloud/ocis/pull/1791)
|
||||
- Fixes for the trash bin feature [#1552](https://github.com/cs3org/reva/pull/1552)
|
||||
|
||||
You can also read the full [ownCloud Infinite Scale changelog](https://github.com/owncloud/ocis/blob/master/CHANGELOG.md) and [ownCloud Web changelog](https://github.com/owncloud/web/blob/master/CHANGELOG.md#changelog-for-owncloud-web-200-2021-02-16) for further details on what has changed.
|
||||
You can also read the full [ownCloud Infinite Scale changelog](https://github.com/owncloud/ocis/releases/tag/v1.4.0) and [ownCloud Web changelog](https://github.com/owncloud/web/releases/tag/v2.1.0) for further details on what has changed.
|
||||
|
||||
### Breaking changes
|
||||
{{< hint warning >}}
|
||||
@@ -102,7 +197,7 @@ These are the major changes in oCIS:
|
||||
- Enhancement - Update reva to v1.6.1-0.20210223065028-53f39499762e: [#1683](https://github.com/owncloud/ocis/pull/1683)
|
||||
- Enhancement - Add initial nats and kubernetes registry support: [#1697](https://github.com/owncloud/ocis/pull/1697)
|
||||
|
||||
More details about this release can be found in the full [ownCloud Infinite Scale changelog](https://github.com/owncloud/ocis/blob/master/CHANGELOG.md) and [ownCloud Web changelog](https://github.com/owncloud/web/blob/master/CHANGELOG.md#changelog-for-owncloud-web-202-2021-03-08).
|
||||
More details about this release can be found in the full [ownCloud Infinite Scale changelog](https://github.com/owncloud/ocis/releases/tag/v1.3.0) and [ownCloud Web changelog](https://github.com/owncloud/web/releases/tag/v2.0.2).
|
||||
|
||||
### Breaking changes
|
||||
{{< hint warning >}}
|
||||
@@ -120,7 +215,7 @@ The most prominent changes in version 1.2.0 comprise:
|
||||
- File integrity checking has been introduced: When uploading files, Infinite Scale now makes sure that the file integrity is protected between server and clients by comparing checksums [#1400](https://github.com/cs3org/reva/issues/1400)
|
||||
- Public link passwords are now stored as hashes to improve security [#1462](https://github.com/cs3org/reva/issues/1462)
|
||||
|
||||
You can also read the full [ownCloud Infinite Scale changelog](https://github.com/owncloud/ocis/blob/master/CHANGELOG.md) and [ownCloud Web changelog](https://github.com/owncloud/web/blob/master/CHANGELOG.md#changelog-for-owncloud-web-200-2021-02-16) for further details on what has changed.
|
||||
You can also read the full [ownCloud Infinite Scale changelog](https://github.com/owncloud/ocis/releases/tag/v1.2.0) and [ownCloud Web changelog](https://github.com/owncloud/web/releases/tag/v2.0.0) for further details on what has changed.
|
||||
|
||||
### Breaking changes
|
||||
{{< hint warning >}}
|
||||
@@ -173,7 +268,7 @@ The most prominent changes in version 1.1.0 comprise
|
||||
- Update ownCloud web to [v1.0.1](https://github.com/owncloud/web/releases/tag/v1.0.1)
|
||||
- Update reva to [v1.5.1](https://github.com/cs3org/reva/releases/tag/v1.5.1)
|
||||
|
||||
You can also read the full [ownCloud Infinite Scale changelog](https://github.com/owncloud/ocis/blob/master/CHANGELOG.md) for further details on what has changed.
|
||||
You can also read the full [ownCloud Infinite Scale changelog](https://github.com/owncloud/ocis/releases/tag/v1.1.0) for further details on what has changed.
|
||||
|
||||
## ownCloud Infinite Scale 1.0.0 Technology Preview
|
||||
|
||||
|
||||
Reference in New Issue
Block a user