diff --git a/docs/clients/rclone/webdav-sync-basic-auth.md b/docs/clients/rclone/webdav-sync-basic-auth.md index e30e93f9b5..e922a156f3 100644 --- a/docs/clients/rclone/webdav-sync-basic-auth.md +++ b/docs/clients/rclone/webdav-sync-basic-auth.md @@ -12,7 +12,7 @@ geekdocCollapseSection: true ## WebDAV with Basic Authentication {{< hint danger >}} -Basic Authentication is disabled by default in oCIS because of security considerations. In order to make the following Rclone commands work the oCIS administrator needs to enable Basic Authentication eg. by setting the the environment variable `PROXY_ENABLE_BASIC_AUTH` to `true`. +Basic Authentication is disabled by default in oCIS because of security considerations. In order to make the following Rclone commands work the oCIS administrator needs to enable Basic Authentication e.g. by setting the environment variable `PROXY_ENABLE_BASIC_AUTH` to `true`. Please consider to use [Rclone with OpenID Connect]({{< ref "webdav-sync-oidc.md" >}}) instead. {{< /hint >}} @@ -43,4 +43,4 @@ We now can use Rclone to sync the local folder `/tmp/test` to `/test` in your oC rclone sync :local:/tmp :webdav:/test ``` -If your oCIS doesn't use valid SSL certificates, you may need to use `rclone --no-check-certificate sync ...`. +If your oCIS doesn't use valid SSL certificates, you may need to use `rclone --no-check-certificate sync ...`. diff --git a/docs/ocis/development/testing.md b/docs/ocis/development/testing.md index f86bfc568b..5d6a5d3495 100644 --- a/docs/ocis/development/testing.md +++ b/docs/ocis/development/testing.md @@ -28,7 +28,7 @@ Basically we have two sources for feature tests and test suites: At the moment both can be applied to oCIS since the api of oCIS is designed to be compatible to ownCloud. -Since we have to offer an migration path to existing users of ownCloud, you can use your existing ownCloud as storage backend for oCIS. As another storage backend we offer oCIS native storage, also called "oCIS". This stores files directly on disk. Which storage backend is used is also reflected in the tests, there are always different tests for oCIS storage and ownCloud storage. +Since we have to offer a migration path to existing users of ownCloud, you can use your existing ownCloud as storage backend for oCIS. As another storage backend we offer oCIS native storage, also called "oCIS". This stores files directly on disk. Which storage backend is used is also reflected in the tests, there are always different tests for oCIS storage and ownCloud storage. You can invoke two types of test suite runs: @@ -55,7 +55,7 @@ This must be pointing to a valid feature definition. ### oCIS image to be tested (or: skip build and take existing image) -By default the tests will be run against docker image built from your current working state of the oCIS repository. For some purposes it might also be handy to use a oCIS image from Docker Hub. Therefore you can provide the optional flag `OCIS_IMAGE_TAG=...` which must contain an available docker tag of the [owncloud/ocis registry on Docker Hub](https://hub.docker.com/r/owncloud/ocis) (eg. 'latest'). +By default, the tests will be run against the docker image built from your current working state of the oCIS repository. For some purposes it might also be handy to use a oCIS image from Docker Hub. Therefore you can provide the optional flag `OCIS_IMAGE_TAG=...` which must contain an available docker tag of the [owncloud/ocis registry on Docker Hub](https://hub.docker.com/r/owncloud/ocis) (eg. 'latest'). ``` make -C tests/acceptance/docker localApiTests-apiAccountsHashDifficulty-ocis OCIS_IMAGE_TAG=latest @@ -75,7 +75,7 @@ The log output is opened in `less`. You can navigate up and down with your curso ### Cleanup -During testing we start an redis and oCIS docker container. These will not be stopped automatically. You can stop them with: +During testing we start a redis and oCIS docker container. These will not be stopped automatically. You can stop them with: ``` make -C tests/acceptance/docker clean diff --git a/docs/ocis/getting-started/_index.md b/docs/ocis/getting-started/_index.md index 72478eff2a..9ee621d590 100644 --- a/docs/ocis/getting-started/_index.md +++ b/docs/ocis/getting-started/_index.md @@ -22,7 +22,7 @@ We are distributing oCIS as binaries and Docker images. {{< hint warning >}} The examples in this document assume that oCIS is accessed from the same host as it is running on (`localhost`). If you would like to access oCIS remotely please refer to the [Basic Remote Setup]({{< ref "../deployment/basic-remote-setup" >}}) section. Especially -to the notes about setting the `PROXY_HTTP_ADDR` and `OCIS_URL` enviroment variables. +to the notes about setting the `PROXY_HTTP_ADDR` and `OCIS_URL` environment variables. {{< /hint >}} You can find more deployment examples in the [deployment section]({{< ref "../deployment" >}}). @@ -113,7 +113,7 @@ The version command prints the version of your installed oCIS. ocis --version {{< / highlight >}} -The health command is used to execute a health check, if the exit code equals zero the service should be up and running, if the exist code is greater than zero the service is not in a healthy state. Generally this command is used within our Docker containers, it could also be used within Kubernetes. +The health command is used to execute a health check, if the exit code equals zero the service should be up and running, if the exit code is greater than zero the service is not in a healthy state. Generally this command is used within our Docker containers, it could also be used within Kubernetes. {{< highlight txt >}} ocis health --help diff --git a/docs/ocis/migration.md b/docs/ocis/migration.md index f11fca320d..75fecff6c0 100644 --- a/docs/ocis/migration.md +++ b/docs/ocis/migration.md @@ -45,7 +45,7 @@ _TODO allow limiting the web ui switch to an 'early adopters' group_ #### Validation -Ensure switching back an forth between the classic ownCloud 10 web UI and ownCloud web works as at our https://demo.owncloud.com. +Ensure switching back and 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. @@ -82,7 +82,7 @@ When introducing OpenID Connect, the clients will detect the new authentication reauthorize at the OpenID Connect 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 [LibreGraph Connect](https://github.com/libregraph/lico), 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. +1. There are multiple products that can be used as an OpenID Connect IdP. We test with [LibreGraph Connect](https://github.com/libregraph/lico), 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 intend to use.
@@ -308,7 +308,7 @@ _Feel free to add your question as a PR to this document using the link at the t
### 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. +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 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. @@ -324,7 +324,7 @@ _TODO @butonic update performance comparisons nightly_ #### Steps There are several options to move users to the oCIS backend: - Use a canary app to let users decide themselves -- Use an early adopters group with an opt in +- Use an early adopters group with an opt-in - Force migrate users in batch or one by one at the administrators will #### Verification @@ -469,8 +469,8 @@ Depending on chosen the share manager provider some sharing requests should be f _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_ +_TODO for seamless migration implement tiered/chained share provider that reads share data from the old provider and writes new 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 share manager should directly persist its metadata to the storage system used by the storage provider so metadata is kept in sync_
@@ -588,7 +588,7 @@ The `filecache` table itself has more metadata: | `checksum` | varchar(255) | YES | | NULL | | *same as blob checksum* | SHOULD become the checksum in the storage provider. eos calculates it itself, `ocis` driver stores it in extended attributes | -> 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 +> 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
@@ -682,7 +682,7 @@ _TODO clarify how OCM handles this and where we store / configure this. It seems 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. -2. To search share recipients, both, ownCloud 10 and oCIS need access to the same user directory using eg. LDAP. +2. To search share recipients, both, ownCloud 10 and oCIS need access to the same user directory using e.g. LDAP.