mirror of
https://github.com/opencloud-eu/opencloud.git
synced 2026-04-24 04:58:31 -05:00
Merge branch 'master' into add_release_info
This commit is contained in:
Willy Kloucek
+3
-3
@@ -22,14 +22,14 @@ Welcome to our developer documentation. Here you can find developer documentatio
|
||||
The oCIS server is Apache v2 licensed.
|
||||
The lower storage layer of oCIS is defined by the CS3 APIs and implemented in the REVA project. Our goal is to develop the CS3 APIs to an open standard and collaborate on the open source REVA reference implementation for CS3 APIs.
|
||||
|
||||
You can also find all client sources on github.
|
||||
You can also find all client sources on GitHub.
|
||||
|
||||
## Join us
|
||||
|
||||
The oCIS server repository on github is a good entry point for you to join the project. But we also develop clients for iOS, Android, Desktop and Web.
|
||||
The oCIS server repository on GitHub is a good entry point for you to join the project. But we also develop clients for iOS, Android, Desktop and Web.
|
||||
|
||||
For communication on development you can join our public chat [talk.owncloud.com](https://talk.owncloud.com)
|
||||
|
||||
If you want to help and improve ownCloud or oCIS, start coding or open issues on github in the related repository.
|
||||
If you want to help and improve ownCloud or oCIS, start coding or open issues on GitHub in the related repository.
|
||||
|
||||
We are very happy to hear your feedback and ideas!
|
||||
|
||||
@@ -8,6 +8,6 @@ geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
This service provides a [glauth](https://github.com/glauth/glauth) based LDAP proxy for ocis which can be used by clients or other extensions. It allows applications relying on LDAP to access the accounts stored in the ocis accounts service. It can be used to make firewalls or identity providers aware of all users, including guest accounts.
|
||||
This service provides a [glauth](https://github.com/glauth/glauth) based LDAP proxy for oCIS which can be used by clients or other extensions. It allows applications relying on LDAP to access the accounts stored in the oCIS accounts service. It can be used to make firewalls or identity providers aware of all users, including guest accounts.
|
||||
|
||||
We are using it to make eos aware of all accounts so the native ACLs can be used to persist share information in the storage.
|
||||
|
||||
@@ -168,7 +168,7 @@ If you prefer to configure the service with commandline flags you can see the av
|
||||
|
||||
### Configuration file
|
||||
|
||||
So far we support the file formats `JSON` and `YAML`, if you want to get a full example configuration just take a look at [our repository](https://github.com/owncloud/ocis/onlyoffice/tree/master/config), there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it's placed at `/etc/ocis/onlyoffice.yml`, `${HOME}/.ocis/onlyoffice.yml` or `$(pwd)/config/onlyoffice.yml`.
|
||||
So far we support the file formats `JSON` and `YAML`, if you want to get a full example configuration just take a look at [our repository](https://github.com/owncloud/ocis/tree/master/onlyoffice/config), there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it's placed at `/etc/ocis/onlyoffice.yml`, `${HOME}/.ocis/onlyoffice.yml` or `$(pwd)/config/onlyoffice.yml`.
|
||||
|
||||
## Usage
|
||||
|
||||
|
||||
@@ -39,4 +39,4 @@ In the context of this extension and oCIS in general, we are using the following
|
||||
- Manifestation of a setting for a specific user
|
||||
- E.g. used for customization (at runtime) in `ocis-web`
|
||||
- `ocis-web-settings` extension for modifying settings values is provided by this service
|
||||
- Can be queried and modified by other ocis extensions
|
||||
- Can be queried and modified by other oCIS extensions
|
||||
|
||||
@@ -8,7 +8,7 @@ geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
This service provides an ocis extension that wraps [reva](https://github.com/cs3org/reva/) and adds an opinionated configuration to it.
|
||||
This service provides an oCIS extension that wraps [reva](https://github.com/cs3org/reva/) and adds an opinionated configuration to it.
|
||||
|
||||
It uses the port range 9140-9179 to preconfigure several services.
|
||||
|
||||
@@ -43,4 +43,4 @@ It uses the port range 9140-9179 to preconfigure several services.
|
||||
| 9165 | storage oc data debug |
|
||||
| 9166-9177 | reserved for s3, wnd, custom + data providers |
|
||||
| 9178 | storage public link |
|
||||
| 9179 | storage public link data |
|
||||
| 9179 | storage public link data |
|
||||
|
||||
@@ -13,11 +13,11 @@ geekdocFilePath: storages.md
|
||||
|
||||
## Storage providers
|
||||
|
||||
To manage the file tree ocis uses storage *storage providers* that are accessing the underlying storage using a *storage driver*. The driver can be used to change the implementation of a storage aspect to better reflect the actual underlying storage capabilities. As an example a move operation on a POSIX filesystem ([theoretically](https://danluu.com/deconstruct-files/)) is an atomic operation. When trying to implement a file tree on top of S3 there is no native move operation that can be used. A naive implementation might fall back on a COPY and DELETE. Some S3 implementations provide a COPY operation that uses an existing key as the source, so the file at least does not need to be reuploaded. In the worst case scenario, which is renaming a folder with hundreds of thousands of objects, a reupload for every file has to be made. Instead of hiding this complexity a better choice might be to disable renaming of files or at least folders on S3. There are however implementations of filesystems on top of S3 that store the tree metadata in dedicated objects or use a completely different persistence mechanism like a distributed key value store to implement the file tree aspect of a storage.
|
||||
To manage the file tree oCIS uses *storage providers* that are accessing the underlying storage using a *storage driver*. The driver can be used to change the implementation of a storage aspect to better reflect the actual underlying storage capabilities. As an example a move operation on a POSIX filesystem ([theoretically](https://danluu.com/deconstruct-files/)) is an atomic operation. When trying to implement a file tree on top of S3 there is no native move operation that can be used. A naive implementation might fall back on a COPY and DELETE. Some S3 implementations provide a COPY operation that uses an existing key as the source, so the file at least does not need to be reuploaded. In the worst case scenario, which is renaming a folder with hundreds of thousands of objects, a reupload for every file has to be made. Instead of hiding this complexity a better choice might be to disable renaming of files or at least folders on S3. There are however implementations of filesystems on top of S3 that store the tree metadata in dedicated objects or use a completely different persistence mechanism like a distributed key value store to implement the file tree aspect of a storage.
|
||||
|
||||
|
||||
{{< hint info >}}
|
||||
While the *storage provider* is responsible for managing the tree, file up and download is delegated to a dedicated *data provider*. See below.
|
||||
While the *storage provider* is responsible for managing the tree, file up- and downloads are delegated to a dedicated *data provider*. See below.
|
||||
{{< /hint >}}
|
||||
|
||||
## Storage aspects
|
||||
|
||||
@@ -9,13 +9,13 @@ geekdocFilePath: basic-remote-setup.md
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
Out of the box the ocis single binary and the `owncloud/ocis` docker image are configured to run on localhost for quick testing and development.
|
||||
Out of the box the oCIS single binary and the `owncloud/ocis` docker image are configured to run on localhost for quick testing and development.
|
||||
|
||||
If you need to access ocis on a VM or a remote machine e.g. when testing a mobile client you need to configure ocis to run on a different host.
|
||||
If you need to access oCIS on a VM or a remote machine e.g. when testing a mobile client you need to configure oCIS to run on a different host.
|
||||
|
||||
## Use the binary
|
||||
|
||||
If you start the ocis fullstack for the first time with `./bin/ocis server` it will generate a file `identifier-registration.yml` in the config folder relative to its location. This file is used to configure the clients for the built-in Identity Provider.
|
||||
If you start the oCIS fullstack for the first time with `./bin/ocis server` it will generate a file `identifier-registration.yml` in the config folder relative to its location. This file is used to configure the clients for the built-in Identity Provider.
|
||||
|
||||
{{< hint warning >}}
|
||||
**Outdated version**\
|
||||
@@ -52,11 +52,11 @@ clients:
|
||||
|
||||
In this example we do not change the default port (`9200`). But this could be changed to another port.
|
||||
|
||||
### Start the ocis fullstack server
|
||||
### Start the oCIS fullstack server
|
||||
|
||||
You need to configure `your-host` in some services to provide the needed public resources.
|
||||
|
||||
This snippet will start the ocis server with auto generated self signed certificates:
|
||||
This snippet will start the oCIS server with auto generated self signed certificates:
|
||||
|
||||
```bash
|
||||
PROXY_HTTP_ADDR=0.0.0.0:9200 \
|
||||
@@ -65,7 +65,7 @@ KONNECTD_TLS=0 \
|
||||
./bin/ocis server
|
||||
```
|
||||
|
||||
For more configuration options check the configuration section in [ocis](https://owncloud.github.io/ocis/configuration/) and every ocis extension.
|
||||
For more configuration options check the configuration section in [ocis](https://owncloud.github.io/ocis/configuration/) and every oCIS extension.
|
||||
|
||||
{{< hint info >}}
|
||||
**TLS Certificate**\
|
||||
|
||||
@@ -91,7 +91,7 @@ See also [example server setup]({{< ref "preparing_server.md" >}})
|
||||
|
||||
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).
|
||||
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`.
|
||||
|
||||
|
||||
@@ -139,7 +139,7 @@ bin/ocis --log-level=$LOG_LEVEL proxy &
|
||||
|
||||
### Gather error messages
|
||||
|
||||
We recommend you collect all related information in a single file or in a github issue. Let us start with an error that pops up in the Web UI:
|
||||
We recommend you collect all related information in a single file or in a GitHub issue. Let us start with an error that pops up in the Web UI:
|
||||
|
||||
> Error while sharing.
|
||||
> error sending a grpc stat request
|
||||
|
||||
@@ -39,7 +39,7 @@ You can invoke two types of test suite runs:
|
||||
|
||||
The names of the full test suite make targets have the same naming as in the CI pipeline.
|
||||
|
||||
For example `make -C tests/acceptance/docker localApiTests-apiOcisSpecific-ocis` runs the same tests as the `localApiTests-apiOcisSpecific-ocis` CI pipeline, which runs the oCIS test suite "apiOcisSpecific" against an oCIS with oCIS storage.
|
||||
For example `make -C tests/acceptance/docker localApiTests-apiBugDemonstration-ocis` runs the same tests as the `localApiTests-apiBugDemonstration-ocis` CI pipeline, which runs the oCIS test suite "apiBugDemonstration" against an oCIS with oCIS storage.
|
||||
|
||||
For example `make -C tests/acceptance/docker Core-API-Tests-owncloud-storage-3`runs the same tests as the `Core-API-Tests-owncloud-storage-3` CI pipeline, which runs the third (out of ten) ownCloud test suite against an oCIS with owncloud storage.
|
||||
|
||||
@@ -48,7 +48,7 @@ For example `make -C tests/acceptance/docker Core-API-Tests-owncloud-storage-3`r
|
||||
The single feature tests can also be run against the different storage backends. Therefore multiple make targets with the schema test-<test source>-feature-<storage backend> exists. For selecting a single feature test you have to add an additional `BEHAT_FEATURE=...` parameter when invoking the make command:
|
||||
|
||||
```
|
||||
make -C tests/acceptance/docker test-ocis-feature-ocis BEHAT_FEATURE='tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsDELETEAuth.feature'
|
||||
make -C tests/acceptance/docker test-ocis-feature-ocis BEHAT_FEATURE='tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsDELETEAuth.feature'
|
||||
```
|
||||
|
||||
This must be pointing to a valid feature definition.
|
||||
@@ -58,7 +58,7 @@ This must be pointing to a valid feature definition.
|
||||
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').
|
||||
|
||||
```
|
||||
make -C tests/acceptance/docker localApiTests-apiOcisSpecific-ocis OCIS_IMAGE_TAG=latest
|
||||
make -C tests/acceptance/docker localApiTests-apiBugDemonstration-ocis OCIS_IMAGE_TAG=latest
|
||||
```
|
||||
|
||||
### Test log output
|
||||
@@ -138,7 +138,7 @@ Those scenarios are run in the ordinary acceptance test pipeline in CI. The scen
|
||||
expected failures. If there are any differences then the CI pipeline fails.
|
||||
Similarly, scenarios that do not work in oCIS with EOS storage are listed in `tests/acceptance/expected-failures-on-EOS-storage.txt`.
|
||||
Additionally, some issues have scenarios that demonstrate the current buggy behaviour in ocis(reva).
|
||||
Those scenarios are in this ocis repository in `tests/acceptance/features/apiOcisSpecific`.
|
||||
Those scenarios are in this ocis repository in `tests/acceptance/features/apiBugDemonstration`.
|
||||
Have a look into the [documentation](https://doc.owncloud.com/server/developer_manual/testing/acceptance-tests.html#writing-scenarios-for-bugs) to understand why we are writing those tests.
|
||||
|
||||
If you want to work on a specific issue
|
||||
|
||||
@@ -19,8 +19,8 @@ You can find more deployments examples in the [deployment section](https://owncl
|
||||
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.1.0 of ocis running on a Linux AMD64 host:
|
||||
To run oCIS as binary you need to download it first and then run the following commands.
|
||||
For this example, assuming version 1.1.0 of oCIS running on a Linux AMD64 host:
|
||||
|
||||
```console
|
||||
# download
|
||||
|
||||
Reference in New Issue
Block a user