diff --git a/modules/ROOT/pages/architecture/architecture.adoc b/modules/ROOT/pages/architecture/architecture.adoc
index 9d09fd880..555525164 100644
--- a/modules/ROOT/pages/architecture/architecture.adoc
+++ b/modules/ROOT/pages/architecture/architecture.adoc
@@ -117,7 +117,7 @@ Every Infinite Scale service uses {ocis-pkg-url}[ocis-pkg], which implements the
==== Go-Micro
-While the {go-micro-url}[go-micro] framework provides abstractions as well as implementations for the different components in a microservice architecture, it uses a more developer-focused runtime philosophy: It is used to download services from a repo, compile them on the fly and start them as individual processes. For Infinite Scale we decided to use a more admin-friendly runtime: You can download a single binary and start the contained Infinite Scale services with a single command: `ocis server`. This also makes packaging easier.
+While the {go-micro-url}[go-micro] framework provides abstractions as well as implementations for the different components in a microservice architecture, it uses a more developer-focused runtime philosophy: It is used to download services from a repo, compile them on the fly and start them as individual processes. For Infinite Scale we decided to use a more admin-friendly runtime: You can download a container that internally uses a single binary, which starts the contained Infinite Scale services with a single command: `ocis server`. This also makes packaging easier.
==== REVA and CS3
diff --git a/modules/ROOT/pages/conf-examples/search/configure-search.adoc b/modules/ROOT/pages/conf-examples/search/configure-search.adoc
index 1acf18742..e684c732d 100644
--- a/modules/ROOT/pages/conf-examples/search/configure-search.adoc
+++ b/modules/ROOT/pages/conf-examples/search/configure-search.adoc
@@ -10,7 +10,7 @@
{description} Using search is a good way to find documents based on various criteria. The search service will return results for documents the searcher is eligible to access. Read the description of the xref:{s-path}/search.adoc[search service] for more details.
-You can use basic search functionality without any configuration as it is preconfigured when using the default binary or container/orchestration deployment.
+You can use basic search functionality without any configuration as it is preconfigured when using the default container deployment.
== Index Data
@@ -96,17 +96,6 @@ image::conf-examples/search/tika-welcome-screen.png[Tika welcome screen, width=4
you can use the container. Finally, you can keep the image when planning to use a container based setup but remove the test container with `docker stop <ID>` and `docker rm <ID>` where ID is the container ID of Tika.
-===== Manual Based
-
-If using the container does not work in your environment, you need to use the server installation of Tika which requires at least Java version 8 installed, check with `java -version` and install java if required. After downloading the https://tika.apache.org/download.html[Tika server .jar] file, you can start the server with:
-
-[source,bash,subs="attributes+"]
-----
-java -jar tika-server-standard-{tika-version}.jar
-----
-
-It is then accessible via `\http://your-server:9998`. Check that the Tika server is automatically started like when using systemd - which is not covered here though you can take xref:depl-examples/small-scale.adoc#setup-the-systemd-service[Setup the systemd Service] from the _Small-Scale Deployment with systemd_ as setup reference.
-
==== Configure Search using the Tika Extractor
As prerequisite, Tika needs to be accessible via `\http://your-server:9998` either using the manual installation or via docker. You can decide to let Tika run on the same or a separate server from where the search service runs. The following configuration assumes that all Infinite Scale services including the search service and Tika run on the same hardware.
diff --git a/modules/ROOT/pages/depl-examples/bare-metal.adoc b/modules/ROOT/pages/depl-examples/bare-metal.adoc
deleted file mode 100644
index 8bfd58534..000000000
--- a/modules/ROOT/pages/depl-examples/bare-metal.adoc
+++ /dev/null
@@ -1,403 +0,0 @@
-= Bare Metal Deployment with systemd
-:toc: right
-:toclevels: 3
-:page-aliases: depl-examples/small-scale.adoc
-:description: This guide describes an installation of Infinite Scale as a systemd service on bare metal. This ranges from a small installation on a Raspberry Pi up to installations on a decent server.
-
-:systemd-url: https://systemd.io/
-:nginx-url: https://www.nginx.com/
-:apache-url: https://www.apache.org
-:certbot-url: https://certbot.eff.org
-:certbot-options-url: https://eff-certbot.readthedocs.io/en/stable/using.html#id36
-:ssl-labs-url: https://www.ssllabs.com/ssltest/
-:apache_http2_url: https://httpd.apache.org/docs/2.4/howto/http2.html
-
-:ocis_bin: /usr/local/bin
-:ocis_env: /etc/ocis
-:ocis_data: /var/lib/ocis
-:ocis_url: ocis.example.com
-:ocis_port: 9200
-
-include::partial$multi-location/compose-version.adoc[]
-
-== Introduction
-
-{description}
-
-This deployment example addresses a small production environment without running online office applications etc. For a minimal test and development environment, see the xref:depl-examples/minimal-bare-metal.adoc[Minimal Bare Metal Deployment]. The main differences between the setup described in this document and a minimal test environment is, the use of systemd, letsencrypt and a reverse proxy. If you intend to run a complete setup using online office, full text search etc., see the *Ubuntu with Docker Compose* deployment examples.
-
-Note that this guide expects that prerequisite of a computer with an installed Linux distribution of choice is met and required software other than Infinite Scale is installed and preconfigured. There is no detailed explanation but, where possible, links for more information are provided.
-
-Note that there is a difference in internal thumbnail processing when using binary vs container deployments. For details see the xref:{s-path}/thumbnails.adoc#thumbnailing-performance[thumbnails] service.
-
-This guide was tested on a Debian 11 (bullseye) host but should work on any other modern Linux system with systemd.
-
-NOTE: The embedded IDM service provides a minimal LDAP service for Infinite Scale and does not replace a LDAP server. See the xref:{s-path}/idm.adoc[IDM Service Configuration] for details.
-
-NOTE: Consider to extend the configuration described based on the information given in xref:{s-path}/storage-users.adoc#graceful-shutdown[Graceful Shutdown].
-
-== Requirements
-
-* A supported filesystem according the xref:prerequisites/prerequisites.adoc#filesystems-and-shared-storage[ocis prerequisites,window=_blank].
-
-* {systemd-url}[systemd]
-* A HTTP reverse proxy, there are examples using {nginx-url}[nginx,window=_blank] and {apache-url}[Apache,window=_blank]
-* {certbot-url}[Certbot,window=_blank] + the nginx or Apache plugin
-+
-[NOTE]
-====
-* For certbot, there are many {certbot-options-url}[command line options,window=_blank] available supporting common tasks like increasing security measures or automatic redirection, the example commands are limited to the minimum issuing a certificate. This includes that configuration files and security measures need to be applied manually.
-* With respect to security, some of the measures are shown in examples but not all possibilities are covered.
-* If using certbot command line options, files may be split by port and content can differ, though the result when combined is the same.
-====
-
-== Excluded Tasks
-
-There are a few steps that are recommended but not covered in this guide:
-
-* Automate the Let's Encrypt certificate renewal via cron jobs
-* Install and set up a firewall
-
-== Used Settings
-
-The following settings were used in this guide. You can change this according your needs:
-
-* The Infinite Scale binary location: `{ocis_bin}` (OS default)
-* The Infinite Scale xref:deployment/general/general-info.adoc#configuration-directory[configuration directory]: `{ocis_env}`
-* The Infinite Scale xref:deployment/general/general-info.adoc#base-data-directory[base data directory]: `{ocis_data}`
-* The URL accessing Infinite Scale: `{ocis_url}` +
-Note that this URL must resolve to the server running this installation.
-* The internal port accessing Infinite Scale: {ocis_port} (default)
-
-== Install and Prepare Infinite Scale
-
-=== Install and Configure the Infinite Scale Binary
-
-* Download and install the Infinite Scale binary. To get the stable binary from ownCloud, visit {ocis-downloadpage-url}/{download-type}/?sort=time&order=desc[download.owncloud.com,window=_blank], select the version and the platform of choice and copy the link of the file. Replace `<file_url>` and `<file_name>` in the commands accordingly.
-+
---
-Download the binary:
-
-[source,bash,subs="attributes+"]
-----
-sudo wget -P {ocis_bin} <file_url>
-----
---
-
-* Make the binary executable with:
-+
-[source,bash,subs="attributes+"]
-----
-sudo chmod a+x {ocis_bin}/<file_name>
-----
-
-* Create a link from the versioned ocis binary name to the final executable named `ocis`: +
-Note when using a symbolic link like this, upgrading and/or testing is much easier.
-+
-[source,bash,subs="attributes+"]
-----
-sudo ln -s -f {ocis_bin}/<file_name> {ocis_bin}/ocis
-----
-
-* Check the version installed:
-+
---
-[source,bash,subs="attributes+"]
-----
-ocis version --skip-services
-----
-
-The output looks like this:
-
-[source,plaintext,subs="attributes+"]
-----
-Version: {compose_version}
-Compiled: {ocis-compiled}
-----
-
-Note that if you omit `--skip-services`, you will get additional information about services printed.
---
-
-NOTE: If you already have a running instance, you must stop and restart the instance to activate the new version.
-
-=== Create a Service User
-
-* In your operating system, create a user and group who will run the ocis service and own all the files of the Infinite Scale service but is not allowed to log in, has no shell and no home directory.
-+
-[source,bash]
-----
-sudo useradd --system --no-create-home --shell=/sbin/nologin ocis
-----
-
-=== Infinite Scale Data Directory
-
-* Create the ocis data directory. All system data will be stored here including all files uploaded by the users.
-+
-[source,bash,subs="attributes+"]
-----
-sudo mkdir -p {ocis_data}
-----
-
-* Make the service user `ocis` the owner of the data directory.
-+
-[source,bash,subs="attributes+"]
-----
-sudo chown ocis:ocis {ocis_data}
-----
-
-=== Infinite Scale Configuration File
-
-* Create a directory and config file necessary for ocis. For security reasons, this user should have restricted permissions for this directory:
-+
---
-[source,bash,subs="attributes+"]
-----
-sudo mkdir -p {ocis_env}
-----
-
-[source,bash,subs="attributes+"]
-----
-sudo touch {ocis_env}/ocis.env
-----
-
-[source,bash,subs="attributes+"]
-----
-sudo chown -R ocis:ocis {ocis_env}
-----
---
-
-* Create the environment file `{ocis_env}/ocis.env` with the following content. Adjust the `OCIS_URL` variable to hold your domain where Infinite Scale will be reachable via `nginx`. Add the correct port to `OCIS_URL` if it deviates from the default port 443 like `\https://{ocis_url}:4242`. See the xref:deployment/general/general-info.adoc[General Information] section for more information about the environment variables used.
-+
---
-[source,bash,subs="attributes+"]
-----
-sudo vi {ocis_env}/ocis.env
-----
-
-[source,plaintext,subs="attributes+"]
-----
-OCIS_URL=https://{ocis_url}
-PROXY_HTTP_ADDR=0.0.0.0:{ocis_port}
-PROXY_TLS=false
-OCIS_INSECURE=false
-
-OCIS_LOG_LEVEL=warn
-
-OCIS_CONFIG_DIR={ocis_env}
-OCIS_BASE_DATA_PATH={ocis_data}
-----
-
-`PROXY_TLS` is set to `false` because xref:deployment/services/tls.adoc#tls-for-the-http-frontend[TLS termination] will be done by the webserver. Though you also can secure the communication between Infinite Scale and the webserver, this is not covered by this document.
---
-
-* Set `OCIS_CONFIG_DIR` and `OCIS_BASE_DATA_PATH`
-+
-IMPORTANT: It is important to set both the `config` and `data` directory environment variables in the `ocis.env` file. If this is omitted, ocis shell commands will not work.
-
-* Setting the correct `OCIS_URL` is essential for the built-in openIDConnect IDP as the xref:{s-path}/idp.adoc[IDP service] needs to be reachable under the same host and port as the reverse proxy is configured. If this has not been configured the same, the IDP service will log errors like `origin does not match request URL`. See the xref:deployment/general/general-info.adoc#using-the-embedded-idp-service[Using the Embedded IDP Service] for configuration notes of the `PROXY_TLS` environment variable.
-+
-IMPORTANT: See the important notes for xref:deployment/general/general-info.adoc#configurations-to-access-the-web-ui[Configurations to Access the Web UI].
-
-* Generate the initial Infinite Scale configuration file, also see xref:deployment/general/ocis-init.adoc[The ocis init Command]:
-+
---
-[source,bash,subs="attributes+"]
-----
-sudo -u ocis ocis init --config-path {ocis_env}
-----
-
-You will be asked if you want to configure Ininite Scale with certificate checking disabled. You can safely answer `yes`. Infinite Scale is composed of several microservices which encrypt the communication between them with TLS. By answering with `yes` the communication is still encrypted but client and server certificates aren't checked for validity. Usually this is good enough. For an extra secure deployment, provide a verifiable TLS certificate and enable certificate checking.
-
-NOTE: The command when run successfully will show you the initial admin user's password. Write it down somewhere safe so that you can log in when the setup is complete. The password can be changed in the UI later on or be reset if forgotten via xref:deployment/general/general-info.adoc#password-reset-for-the-admin-user[Password Reset for the Admin User].
-
-This command will create the configuration file `{ocis_env}/ocis.yaml`.
-
-IMPORTANT: Do NOT delete the `ocis.yaml` file without creating a backup of it first. When you regenerate the `ocis.yaml` file, it will be out of sync with the stored user data in the ocis data directory `{ocis_data}`. If for some reason you still want to regenerate the config file, you first need to empty the data directory but beware if you already have user files stored there. Also see xref:deployment/general/ocis-init.adoc[The ocis init Command] for more details.
---
-
-== Setup the systemd Service
-
-* {empty}
-+
---
-include::partial$deployment/systemd.adoc[]
---
-
-include::partial$deployment/dependent_startup.adoc[leveloffset=+2]
-
-== Nginx as Reverse Proxy
-
-NOTE: Whenever a configuration change has been made, you need to do a configuration check and reload the nginx configuration. This can be done with two methods as described below. Select your preferred one. For ease of writing, the examples show `sudo nginx -s reload`.
-
-* {empty}
-+
---
-[source,bash]
-----
-sudo nginx -s reload
-----
-Note that this command includes checking and reloading the config in the same step.
---
-
-* {empty}
-+
---
-[source,bash]
-----
-sudo nginx -t
-----
-
-[source,bash]
-----
-sudo systemctl reload nginx
-----
-Note that using `systemctl reload nginx` alone will NOT validate your configuration but will execute the command in a clean environment and not in the current user environment.
---
-
-=== Prepare nginx for certbot
-
-* To set up nginx as a reverse proxy with Let's Encrypt TLS certificates, create a file called e.g. `ocis` under `/etc/nginx/sites-available` with the following content:
-+
-include::partial$deployment/nginx_80_example.adoc[]
-
-* Activate the new nginx config:
-+
---
-[source,bash]
-----
-sudo ln -s -f /etc/nginx/sites-available/ocis /etc/nginx/sites-enabled/ocis
-----
---
-
-* Check the config and reload nginx:
-+
---
-[source,bash]
-----
-sudo nginx -s reload
-----
---
-
-=== Issuing a Certificate via certbot for nginx
-
-* Run `certbot` to issue the TLS certificates:
-+
-[source,bash,subs="attributes+"]
-----
-sudo certbot --nginx -d {ocis_url}
-----
-
-=== Finalize the nginx Configuration
-
-* Adapt the config to redirect automatically to https, use the newly generated certificates and add the required proxy configuration. The full config should look like this:
-+
-include::partial$deployment/nginx_proxy_example.adoc[]
-
-* Add the following to the SSL definition above if SSL security should be hardened / improved:
-+
-include::partial$deployment/nginx_harden_ssl.adoc[]
-
-* Check the config and reload nginx:
-+
---
-[source,bash]
-----
-sudo nginx -s reload
-----
---
-
-If the server is accessible from the web, see the free {ssl-labs-url}[SSL Labs] page to check the sites SSL security.
-
-Open a web browser, navigate to your Infinite Scale URL `\https://{ocis_url}` and log in as admin user with the password returned by the `ocis init` command.
-
-== Apache as Reverse Proxy
-
-NOTE: Whenever a configuration change has been made, you need to do a configuration check and reload the Apache configuration. This can be done with two methods as described below. Select your preferred one. For ease of writing, the examples show `sudo apache2ctl -k graceful`.
-
-* {empty}
-+
---
-[source,bash]
-----
-sudo apache2ctl -k graceful
-----
-Note that this command includes checking and reloading the config in the same step.
---
-
-* {empty}
-+
---
-[source,bash]
-----
-sudo apache2ctl -t
-----
-
-[source,bash]
-----
-sudo systemctl reload apache2
-----
-Note that using `systemctl reload apache2` alone will NOT validate your configuration but will execute the command in a clean environment and not in the current user environment.
---
-
-=== Prepare Apache for certbot
-
-* To set up Apache as a reverse proxy with Let's Encrypt TLS certificates, create a file called e.g. `ocis` under `/etc/apache2/sites-available` with the following content:
-+
-include::partial$deployment/apache_80_example.adoc[]
-
-* Activate the new Apache config and reload Apache:
-+
---
-[source,bash]
-----
-sudo ln -s -f /etc/apache2/sites-available/ocis /etc/apache2/sites-enabled/ocis
-----
-
-[source,bash]
-----
-sudo apache2ctl -k graceful
-----
---
-
-=== Issuing a Certificate via certbot for Apache
-
-* Run `certbot` to issue the TLS certificates:
-+
-[source,bash,subs="attributes+"]
-----
-sudo certbot --apache -d {ocis_url}
-----
-
-=== Finalize the Apache Configuration
-
-* Adapt the config to redirect automatically to https, use the newly generated certificates and add the required proxy configuration. The full config should look like this:
-+
-include::partial$deployment/apache_proxy_example.adoc[]
-
-* Add the following to the SSL definition above if SSL security should be hardened / improved:
-+
-include::partial$deployment/apache_harden_ssl.adoc[]
-
-* Reload Apache:
-+
-[source,bash]
-----
-sudo apache2ctl -k graceful
-----
-
-See the linked documentation how to enable the {apache_http2_url}[http2,window=_blank] protocol for Apache.
-
-If the server is accessible from the web, see the free {ssl-labs-url}[SSL Labs] page to check the sites SSL security.
-
-Open a web browser, navigate to your Infinite Scale URL `\https://{ocis_url}` and log in as admin user with the password returned by the `ocis init` command.
-
-== Updating
-
-ifeval::["{version-type}" == "rolling"]
-Note that this deployment can, for the time being, only be updated within Infinite Scale rolling releases.
-endif::[]
-
-If new Infinite Scale releases are available, you *must not* skip any version in between the current running and the latest available release for internal upgrade reasons. All versions need to be downloaded and started one time. For more details see the https://owncloud.dev/ocis/release_roadmap/#updating-and-overlap[Updating and Overlap] description in the developer documentation.
-
-* If there is no release gap, you can update by stopping the runtime via systemd (`sudo systemctl stop ocis`), xref:install-and-configure-the-infinite-scale-binary[update the binary and make it executable] and start the runtime with systemd again (`sudo systemctl start ocis`).
-* For *any* https://owncloud.dev/ocis/release_roadmap/#dates[release gap], you must follow the procedure described above.
diff --git a/modules/ROOT/pages/depl-examples/minimal-bare-metal.adoc b/modules/ROOT/pages/depl-examples/minimal-bare-metal.adoc
deleted file mode 100644
index 875d88849..000000000
--- a/modules/ROOT/pages/depl-examples/minimal-bare-metal.adoc
+++ /dev/null
@@ -1,266 +0,0 @@
-= Minimal Bare Metal Deployment
-:toc: right
-:toclevels: 3
-:page-aliases: deployment/binary/binary-setup.adoc
-:description: This description allows you to have an Infinite Scale system up and running with only a few commands.
-
-:systemd-url: https://systemd.io/
-:traefik-url: https://doc.traefik.io/traefik/getting-started/install-traefik/
-
-:ocis_bin: /usr/local/bin
-:ocis_env: $HOME/.ocis/config/
-:ocis_data: /var/lib/ocis
-:ocis_url: localhost or IP
-:ocis_port: 9200
-
-include::partial$multi-location/compose-version.adoc[]
-
-== Introduction
-
-{description} It does not cover extended deployment tasks, how to manage trusted certificates, run online office applications etc. and is intended to get a first hands-on experience of the system only.
-
-For a small production environment using the binary installation approach, see the xref:depl-examples/bare-metal.adoc[Bare Metal Deployment with systemd]. The main differences between this setup and the small production environment using the binary installation is, in a nutshell, the use of systemd, LetsEncrypt and a reverse proxy.
-
-Note that there is a difference in internal thumbnail processing when using binary vs container deployments. For details see the xref:{s-path}/thumbnails.adoc#thumbnailing-performance[thumbnails] service.
-
-[IMPORTANT]
-====
-This minimal bare metal deployment makes the following assumptions:
-
-* Acccessing Infinite Scale only from the server. +
-Use `\https://localhost:{ocis_port}` as URL and no further configuration is neccesary. +
-To access Infinite Scale via hostname or IP, see xref:accessing-infinite-scale-other-than-localhost[Accessing Infinite Scale Other Than Localhost].
-
-* You are fine in the first step using Infinite Scales internal unsigned certificates. +
-Trusted certificates can be installed later on, see xref:deployment/general/general-info.adoc#handling-certificates[Handling Certificates] for more information.
-====
-
-IMPORTANT: ownCloud highly recommends reading the xref:deployment/general/general-info.adoc[General Information] page first, as it contains valuable information about configuration rules, managing services and default paths - just to mention some of the useful topics.
-
-== Prerequisites
-
-See the xref:prerequisites/prerequisites.adoc#filesystems-and-shared-storage[Prerequisites,window=_blank] section for more details.
-
-== Used Settings
-
-The following settings were used in this guide. You can change this according to your needs:
-
-* The Infinite Scale binary location: `{ocis_bin}` (OS default)
-* The Infinite Scale xref:deployment/general/general-info.adoc#configuration-directory[configuration directory]: `{ocis_env}`
-* The Infinite Scale xref:deployment/general/general-info.adoc#base-data-directory[base data directory]: `{ocis_data}`
-* The URL for accessing Infinite Scale: `localhost`
-* The port for accessing Infinite Scale: `{ocis_port}` (default)
-
-== TL;DR
-
-For those who want to skip reading the full document, use this summary of commands to download, start and access Infinite Scale without any additional information provided. For more details and explanations, we recommend taking the step by step process starting with the next section.
-
-IMPORTANT: With this approach, the system you install Infinite Scale on *must* have a GUI present. A headless system has different requirements and needs an extended setup, see xref:accessing-infinite-scale-other-than-localhost[Accessing Infinite Scale Other Than Localhost].
-
-Define a stable binary to use as replacement for `<file_url>` via {ocis-downloadpage-url}/{download-type}/?sort=time&order=desc[download.owncloud.com,window=_blank], replace `<file_name>` in the command accordingly.
-
-[source,bash,subs="attributes+"]
-----
-sudo wget -P {ocis_bin} <file_url>
-----
-
-[source,bash,subs="attributes+"]
-----
-sudo chmod a+x {ocis_bin}/<file_name>
-----
-
-[source,bash,subs="attributes+"]
-----
-
-sudo ln -s -f {ocis_bin}/<file_name> {ocis_bin}/ocis
-----
-
-[source,bash]
-----
-ocis init
-----
-
-[source,bash]
-----
-ocis server
-----
-
-Open a browser and use as URL: `\https://localhost:{ocis_port}` and the credentials printed by the `ocis init` command to login.
-
-Congratulations, you now have access to your Infinite Scale instance.
-
-== Installation
-
-* To get the stable binary from ownCloud, visit {ocis-downloadpage-url}/{download-type}/?sort=time&order=desc[download.owncloud.com,window=_blank], select the version and the platform of choice and copy the link of the file. Check the sort order on the modification date to get the most recent releases on top. Depending on your system and preferences, you may want to save the binary in `{ocis_bin}`. Replace `<file_url>` and `<file_name>` in the commands accordingly.
-+
---
-Download the binary:
-
-[source,bash,subs="attributes+"]
-----
-sudo wget -P {ocis_bin} <file_url>
-----
---
-
-* Make the binary executable with:
-+
-[source,bash,subs="attributes+"]
-----
-sudo chmod a+x {ocis_bin}/<file_name>
-----
-
-* Create a link from the versioned ocis binary to the final executable named `ocis`: +
-Note when using a symbolic link like this, upgrading and/or testing is much easier.
-+
-[source,bash,subs="attributes+"]
-----
-sudo ln -s -f {ocis_bin}/<file_name> {ocis_bin}/ocis
-----
-
-* Check the version installed:
-+
---
-[source,bash,subs="attributes+"]
-----
-ocis version --skip-services
-----
-
-The output looks like this:
-
-[source,plaintext,subs="attributes+"]
-----
-Version: {compose_version}
-Compiled: {ocis-compiled}
-----
-
-Note that if you omit `--skip-services`, you will get additional information about services printed.
---
-
-NOTE: If you already have a running instance, you must stop and restart the instance to activate the new version.
-
-== Getting Command Line Help
-
-To get a list of available options and commands type:
-
-[source,bash]
-----
-ocis
-----
-
-or
-
-[source,bash]
-----
-ocis --help
-----
-
-== Starting Infinite Scale
-
-Infinite Scale is started in two steps:
-
-* A first time start to initialize the system and
-* a recurring start after initialization.
-
-Refer to the xref:deployment/general/general-info.adoc#default-users-and-groups[Default Users and Groups] section if you want to have demo users created when initializing the system. This step can only be done during initialization.
-
-=== First Time Initializing Infinite Scale
-
-Infinite Scale needs a xref:deployment/general/general-info.adoc#initialize-infinite-scale[first time initialization] to set up the environment. You will need to answer questions as the basis for generating a default `ocis.yaml` file. You can edit this file later. The default location for config files is, if not otherwise defined, `{ocis_env}`. For details see the xref:deployment/general/general-info.adoc#configuration-directory[Configuration Directory] documentation. Type the following command to initialize Infinite Scale.
-
-[source,bash]
-----
-ocis init
-----
-
-On success, you will see a message like:
-
-:init_path: pass:[<your-user>/.ocis/config/ocis.yaml]
-
-include::partial$deployment/ocis_init.adoc[]
-
-[NOTE]
-====
-If you get an error message like the following:
-
-[source,plaintext]
-----
-Could not create config: config in /home/<user-name>/.ocis/config/ocis.yaml already exists
-----
-
-you already have created a configuration once. As you cannot overwrite the existing configuration, you must delete the old configuration first to proceed. For more details, see: xref:deployment/general/general-info.adoc#initialize-infinite-scale[Initialize Infinite Scale].
-====
-
-=== Starting the Infinite Scale Runtime
-
-After initializing Infinite Scale for the first time, you can start the Infinite Scale runtime which includes embedded services.
-
-Starting Infinite Scale::
-The example commands shown below have no environment variables or command line options for ease of reading, add them according to your requirements.
-+
---
-To start the Infinite Scale runtime type:
-
-[source,bash]
-----
-ocis server
-----
-
-Note that this will bind `ocis` to the shell you are running. If you want to detach it and avoid it being stopped when closing the shell or the shell gets disconnected (SIGHUP), use the following command:
-
-.Bash
-[source,bash]
-----
-ocis server & disown -h
-----
-
-.ZSH
-[source,zsh]
-----
-ocis server & disown %%
-----
-
-See the respective shell documentation for how to manage processes respectively detach and re-attach sessions.
---
-
-=== Configuring Infinite Scale
-
-Infinite Scale can be configured via environment variables, see the following sections for more information and details:
-
-* xref:deployment/general/general-info.adoc#start-infinite-scale-with-environment-variables[Starting Infinite Scale With Environment Variables]
-* xref:deployment/general/general-info.adoc#configurations-to-access-the-web-ui[Configurations to Access the Web UI]
-
-NOTE: You cannot instantiate runtime services though you can define which services should start or be excluded from starting. See xref:deployment/general/general-info.adoc#managing-services[Managing Services] for more details.
-
-== Accessing Infinite Scale
-
-When you have configured and started the Infinite Scale runtime as described in the example command above, you can access it via a browser using `\https://localhost:{ocis_port}`. Use the credentials printed from the `ocis init` command.
-
-=== Accessing Infinite Scale Other Than Localhost
-
-include::partial$multi-location/idm-https-reverse-proxy.adoc[]
-
-== List Running Infinite Scale Processes
-
-To list all running ocis processes type:
-
-[source,bash]
-----
-ps ax | grep ocis | grep -v grep
-----
-
-[source,plaintext]
-----
- 221297 pts/1 Sl 0:04 ocis server
- 221706 pts/0 Sl 0:00 ocis notifications
-----
-
-== Stopping Infinite Scale
-
-To properly stop Infinite Scale, the signal `SIGTERM` (15) is used. Note that SIGTERM politely asks a process to terminate. It will terminate gracefully, cleaning up all resources (files, sockets, child processes, etc.), deleting temporary files and so on. Do not use `SIGKILL` (9) as this will initiate a dirty shutdown.
-
-The following command stops the runtime with all its services plus any extra started services which are not part of the runtime and have been started manually. Depending on the user you started `ocis` with and which user you are currently logged in as, you may need to use `sudo` for the killall command for proper permissions.
-
-[source,bash]
-----
-killall -v -s 15 ocis
-----
diff --git a/modules/ROOT/pages/depl-examples/ubuntu-compose/ubuntu-compose-prod.adoc b/modules/ROOT/pages/depl-examples/ubuntu-compose/ubuntu-compose-prod.adoc
index b542e6f45..e354fc14a 100644
--- a/modules/ROOT/pages/depl-examples/ubuntu-compose/ubuntu-compose-prod.adoc
+++ b/modules/ROOT/pages/depl-examples/ubuntu-compose/ubuntu-compose-prod.adoc
@@ -1,6 +1,7 @@
= Install Infinite Scale on a Server
:toc: macro
:toclevels: 3
+:page-aliases: depl-examples/minimal-bare-metal.adoc, depl-examples/bare-metal.adoc, depl-examples/small-scale.adoc
:keywords: docker compose, raspberry pi, install, ocis, infinite scale, letsencrypt
:description: Install Infinite Scale using Docker Compose on a server for production use.
diff --git a/modules/ROOT/pages/deployment/container/orchestration/orchestration.adoc b/modules/ROOT/pages/deployment/container/orchestration/orchestration.adoc
index 41f02fc11..f2e5a16d7 100644
--- a/modules/ROOT/pages/deployment/container/orchestration/orchestration.adoc
+++ b/modules/ROOT/pages/deployment/container/orchestration/orchestration.adoc
@@ -66,9 +66,9 @@ IMPORTANT: ownCloud highly recommends reading the xref:deployment/general/genera
Similar to using _docker run_ and handing over command-line parameters for a single container, you can use a `docker-compose.yml` yaml file which defines all the settings and environment variables for each container in one or more files. This is the next step when having multi-container environments.
-* Consider that when planning to run Infinite Scale via Docker Compose, the degree of freedom is not the same as when using Kubernetes with Helm as you are limited to the same server and other limitations but it usually offers more than running the pure binary when it comes to ease of configuration and maintaining your environment.
+* Consider that when planning to run Infinite Scale via Docker Compose, the degree of freedom is not the same as when using Kubernetes with Helm as you are limited to the same server and other limitations when it comes to ease of configuration and maintaining your environment.
-* Use Docker Compose if you aim at an extended degree of freedom compared to the binary installation but don't need the full capabilities of Kubernetes and Helm.
+* Use Docker Compose if you aim at an extended degree of freedom but don't need the full capabilities of Kubernetes and Helm.
=== Prerequisites
diff --git a/modules/ROOT/pages/deployment/general/general-info.adoc b/modules/ROOT/pages/deployment/general/general-info.adoc
index 035487210..375e8e5ec 100644
--- a/modules/ROOT/pages/deployment/general/general-info.adoc
+++ b/modules/ROOT/pages/deployment/general/general-info.adoc
@@ -10,27 +10,11 @@ include::partial$multi-location/compose-version.adoc[]
IMPORTANT: We highly recommend reading this document first before you start setting up your system. Many obstacles can be avoided when knowing the basic concepts. Though it is tempting to just give things a try - which is totally ok, you will quickly realize that you may have to start again from scratch before the setup meets your requirements.
-The example commands shown need to be adjusted depending on whether you are using the xref:depl-examples/minimal-bare-metal.adoc[Minimal Bare Metal Deployment] or a xref:deployment/container/container-setup.adoc[Container Setup].
-
When using global options on startup, you can always use command line options or environment variables. Run `ocis help` and see xref:start-infinite-scale-with-environment-variables[] for details.
== Embedded Supervisor (Runtime)
-Infinite Scale has an xref:architecture/architecture.adoc#infinite-scale-microservice-runtime[embedded supervisor] for managing the runtime and reducing the memory footprint. In addition, this supervisor takes care that a service will be restarted automatically if it fails. When using an external supervisor like systemd, Kubernetes or others, the embedded supervisor is not needed, the services are managed by the external supervisor.
-
-== Deciding the Startup Mode
-
-The following two mode types do not predefine a particular installation method like the manual or container setup. When using Kubernetes, the embedded supervisor is not necessary, the supervisor of the underlying system is used.
-
-Starting Infinite Scale using the embedded supervisor::
-This mode can be used when scaling is not the primary focus and can be the case if you have a:
-* testing and/or development environment, or
-* small production environment (xref:availability_scaling/availability_scaling.adoc#single-server-setup[Single Server Setup]).
-* See: xref:depl-examples/minimal-bare-metal.adoc[Minimal Bare Metal Deployment] and xref:deployment/container/container-setup.adoc[Container Setup] for more details.
-
-Starting Infinite Scale in unsupervised mode::
-This mode is used when _availability, scaling and the adjustment to dynamically changing requirements_ have a xref:availability_scaling/availability_scaling.adoc#deployment-evolution[high priority]. In this case, an external supervisor like Kubernetes is used to deploy and run Infinite Scale with its services.
-* See: xref:deployment/container/orchestration/orchestration.adoc[Container Orchestration] for more details.
+Infinite Scale has an xref:architecture/architecture.adoc#infinite-scale-microservice-runtime[embedded supervisor] for managing the runtime and reducing the memory footprint. In addition, this supervisor takes care that a service will be restarted automatically if it fails. When using an external supervisor like Kubernetes or others, the embedded supervisor is not needed, the services are managed by the external supervisor.
== Managing Services
@@ -44,9 +28,11 @@ When typing `ocis <service-name> --help`, you will get detailed help regarding t
=== Manage Instances of Services
+Note, to access the `ocis command`, you must enter the shell of the container first.
+
==== Infinite Scale Supervised Services
-In supervised mode, all services are started with one command as you can see below in the example when using the binary setup. Note that the services started with the runtime share the same PID.
+In supervised mode, all services are started with one command as you can see below. Note that services started with the runtime share the same PID.
Start the Infinite Scale Runtime::
+
@@ -63,7 +49,7 @@ ocis list
----
Stopping the Infinite Scale Runtime::
-In supervised mode, you have to stop the `ocis server` which also stops all services. See xref:depl-examples/minimal-bare-metal.adoc#stopping-infinite-scale[Stopping Infinite Scale] for more details.
+In supervised mode, you have to stop `ocis server` with a graceful shutdown, which also stops all services.
==== Unsupervised Services
@@ -121,7 +107,7 @@ Special configuration settings can be the following:
* yaml configurations that use an OS environment variable for the value.
yaml only settings::
-There are certain situations where multiple settings using the same keys apply for a configuration set. This can be like in the xref:{s-path}/app-registry.adoc[app-registry] service where default apps for mimetypes are defined. A single environment variable cannot hold all that information. For this case, a yaml configuration is the only way possible. Note that both installation methods, binary and container, can deal with yaml configuration files.
+There are certain situations where multiple settings using the same keys apply for a configuration set. This can be like in the xref:{s-path}/app-registry.adoc[app-registry] service where default apps for mimetypes are defined. A single environment variable cannot hold all that information. For this case, a yaml configuration is the only way possible.
Using OS environment variables in yaml files::
OS environment variables can be used in yaml config files for Infinite Scale services which will be replaced by the actual value of the environment variable at runtime. This method allows defining a standardized setup, but parameterize it for different use cases. Default values can be specified after a `|` character.
@@ -179,17 +165,6 @@ See xref:using-s3-for-blobs[Using S3 for Blobs] for the S3 configuration.
** For container images (inside the container) +
`/etc/ocis/`
-+
-** For binary releases +
-`$HOME/.ocis/config/`
-+
-[NOTE]
-====
-* Do not replace `$HOME` with `~` (tilde).
-** The code does not resolve `~` to the users home directory.
-* Check that `$HOME` resolves to a valid directory.
-** When using a system user for the runtime, which has no login and therefore no home directory, like in the scenario xref:depl-examples/bare-metal.adoc#setup-the-systemd-service[Setup the systemd Service], you *must* specify a configuration file location.
-====
* You can deviate from the default location and define a custom configuration directory on startup using the environment variable `OCIS_CONFIG_DIR`.
@@ -256,18 +231,6 @@ The following environment variables can overwrite the base data path if required
** For container images (inside the container) +
`/var/lib/ocis`
-** For binary releases +
-`$HOME/.ocis/`
-+
-[NOTE]
-====
-* Do not replace `$HOME` with `~` (tilde).
-** The code does not resolve `~` to the users home directory.
-
-* Check that `$HOME` resolves to a valid directory.
-** When using a system user for the runtime, which has no login and therefore no home directory, like in the generic binary setup scenario xref:depl-examples/bare-metal.adoc#setup-the-systemd-service[Setup the systemd Service] or in the deployment example xref:depl-examples/small-scale.adoc[Small-Scale with systemd], you *must* specify a base directory location because a system user has no logon and therefore no home directory!
-====
-
* You can deviate from the default location and define a custom base directory on startup using the environment variable `OCIS_BASE_DATA_PATH`.
* More Important Notes
@@ -286,7 +249,7 @@ Read the xref:deployment/storage/s3.adoc[S3] documentation for more details on h
== Initialize Infinite Scale
-Infinite Scale can be run by manually defining the environment like you do when using xref:deployment/container/orchestration/orchestration.adoc[Container Orchestration]. When using the xref:depl-examples/minimal-bare-metal.adoc[Minimal Bare Metal Deployment] or the xref:deployment/container/container-setup.adoc[Container Setup], you can prepare Infinite Scale for further configuration and recurring starts. After reading xref:deployment/general/ocis-init.adoc[The ocis init Command] for important details, start the initialization. To do so, run:
+Infinite Scale can be run by manually defining the environment like you do when using xref:deployment/container/orchestration/orchestration.adoc[Container Orchestration]. When using the xref:deployment/container/container-setup.adoc[Container Setup], you can prepare Infinite Scale for further configuration and recurring starts. After reading xref:deployment/general/ocis-init.adoc[The ocis init Command] for important details, start the initialization. To do so, run:
[source,bash]
----
@@ -645,7 +608,6 @@ idm:
====
To reset the admin password, you either must:
-* Shutdown Infinite scale if you are using the binary setup.
* Stop the container if you are using a docker setup.
* Shut down the environment if you are using docker compose. +
Note that the environment must be shut down. Stopping or pausing is not sufficient. +
@@ -657,15 +619,6 @@ This is because the IDM service needs exclusive access to particular backend inf
When the prerequisite from the note above is fulfilled, you can reset the admin password as described below. When finished, the Infinite Scale instance respectively the IDM service can be started again and the new admin password is available.
-==== Binary Setup
-
-Run the following command to reset the admin password, use `--user-name <user>` for ordinary users:
-
-[source,bash]
-----
-ocis idm resetpassword
-----
-
==== Container and Orchestrated Setup
The use of `sudo` depends on if docker has been setup rootless or not.
diff --git a/modules/ROOT/pages/deployment/general/ocis-init.adoc b/modules/ROOT/pages/deployment/general/ocis-init.adoc
index b7a13f84d..32c6b09b2 100644
--- a/modules/ROOT/pages/deployment/general/ocis-init.adoc
+++ b/modules/ROOT/pages/deployment/general/ocis-init.adoc
@@ -10,48 +10,6 @@
In general, the xref:deployment/general/general-info.adoc#initialize-infinite-scale[ocis init] command initializes ocis _for the first run_ and creates an `ocis.yaml` configuration file. See xref:deployment/general/general-info.adoc#configuration-rules[Configuration Rules] for the file location. This command is helpful if you do not provide the necessary settings manually, but some rules apply.
-=== Binary Deployment
-
-When using the binary deployment like described in the xref:depl-examples/minimal-bare-metal.adoc[Minimal Bare Metal Deployment], the command *is recommended* to be run manually once before first usage, though you can also fully configure the initial setup manually.
-
-* The following command line parameters or their equivalent environment variables can be defined to configure the `ocis init` command. When using environment variables the following structure is used; multiple variables are allowed:
-+
-[source,bash]
-----
-<variable1>=<value1> \
-<variable2>=<value2> \
-... \
-ocis init
-----
-
-* `--admin-password` or `--ap` +
-`ADMIN_PASSWORD` or `IDM_ADMIN_PASSWORD`, value=password
-+
-When running `ocis init`, a random admin password will be printed to the shell for first login. Though the password can be changed afterwards in the UI, it is possible to define it right from the start when initializing.
-
-* `--insecure` +
-`OCIS_INSECURE`, value=true|false
-+
-This allows to use transport security, but disables certificate verification. Useful with self-signed certificates to avoid certificate warnings. If set, the value will also be written to the config file. In such a case, when calling `ocis server`, it is not necessary to set the environment variable again with each start.
-
-* `--config-path` +
-`OCIS_CONFIG_DIR`, value=absolute_path
-+
---
-Manually set the xref:deployment/general/general-info.adoc#configuration-directory[config directory] to deviate from the default.
-
-NOTE: If using this setting, the environment variable MUST be used when starting `ocis server`.
---
-
-* `--force-overwrite` or `-f` +
-`OCIS_FORCE_CONFIG_OVERWRITE`, value=true|false
-+
---
-If you already have run `ocis init` and a config has been defined, a consecutive run will cause a warning that a config already exists. Use this if you want to create a new configuration.
-
-WARNING: When setting this environment variable, the existing configuration will get overwritten and the existing installation and its data is no longer accessible. *The use is intended for development purposes only*.
---
-
=== Container Setup
When deploying via `docker run` as described in xref:deployment/container/container-setup.adoc[Container Setup], initialisation needs to be triggered once before the first full start. See the referenced page how to do so.
diff --git a/modules/ROOT/pages/deployment/index.adoc b/modules/ROOT/pages/deployment/index.adoc
index a75bb4595..88927916b 100644
--- a/modules/ROOT/pages/deployment/index.adoc
+++ b/modules/ROOT/pages/deployment/index.adoc
@@ -8,8 +8,6 @@
* The xref:deployment/general/general-info.adoc[General Info] section summarizes general and important information which is not dependent on the way that you install Infinite Scale. Any setup refers to this general information as prerequisite knowledge.
-* If you only want to play around and see what Infinite Scale has to offer, we suggest the quick and easy xref:depl-examples/minimal-bare-metal.adoc[Minimal Bare Metal Deployment] section.
-
* If you have already decided on a container instance with one or more containers, checkout the xref:deployment/container/container-setup.adoc[Container Setup].
* For a more complex or enterprise setup, consider reading xref:deployment/container/orchestration/orchestration.adoc[Container Orchestration]. This document also covers the use of Kubernetes and Helm Charts.
diff --git a/modules/ROOT/pages/deployment/services/env-var-note.adoc b/modules/ROOT/pages/deployment/services/env-var-note.adoc
index 0de6caf61..7c02b88bc 100644
--- a/modules/ROOT/pages/deployment/services/env-var-note.adoc
+++ b/modules/ROOT/pages/deployment/services/env-var-note.adoc
@@ -39,11 +39,10 @@ Default values containing curly brackets::
In the table showing the environment variables of a service, the _Default Value_ cell can sometimes contain values with curly brackets like `{{.Id.OpaqueId}}`. These are valid defaults.
====
-Note on paths for binary vs. container installations::
+Note on paths for container installations::
If a service offers path customization like the `IDM_LDAPS_CERT` (see the xref:{s-path}/idm.adoc[IDM] documentation), the path set references the environment used. This means:
+
--
-* When using the binary installation, the path is based on the host filesystem.
* When using a container installation, the path references a target inside the container.
+
[NOTE]
diff --git a/modules/ROOT/pages/deployment/services/env-vars-special-scope.adoc b/modules/ROOT/pages/deployment/services/env-vars-special-scope.adoc
index a129eb498..64ada7f09 100644
--- a/modules/ROOT/pages/deployment/services/env-vars-special-scope.adoc
+++ b/modules/ROOT/pages/deployment/services/env-vars-special-scope.adoc
@@ -10,7 +10,7 @@ Examples:
* The global environment variable `OCIS_LOG_LEVEL` is available in multiple services.
* The extended environment variable `OCIS_CONFIG_DIR` can be used with `ocis init`.
-* The special environment variable `OCIS_RUN_SERVICES` is only available with a binary deployment.
+* The special environment variable `OCIS_RUN_SERVICES` defines services to start when the container is started.
== Special Environment Variables
@@ -19,7 +19,7 @@ Examples:
// their source is in: https://github.com/owncloud/ocis/blob/master/ocis-pkg/config/config.go
// at 'type Runtime struct'
-The following environment variables are only available when using a binary deployment. For additional information read the xref:deployment/general/general-info.adoc#start-infinite-scale[Start Infinite Scale] documentation. Read the xref:deployment/services/envvar-types-description.adoc[Environment Variable Types] documentation for important details.
+The following environment variables are only available when using a developer version for Infinite Scale. For additional information read the xref:deployment/general/general-info.adoc#start-infinite-scale[Start Infinite Scale] documentation. Read the xref:deployment/services/envvar-types-description.adoc[Environment Variable Types] documentation for important details.
include::partial$deployment/services/env-and-yaml.adoc[tag=special_envvars]
diff --git a/modules/ROOT/pages/deployment/services/registry.adoc b/modules/ROOT/pages/deployment/services/registry.adoc
index fc318acce..de6375b56 100644
--- a/modules/ROOT/pages/deployment/services/registry.adoc
+++ b/modules/ROOT/pages/deployment/services/registry.adoc
@@ -16,4 +16,4 @@ Set the environment variable to `nats-js-kv` or leave it empty to use a nats-js
NOTE: If not running _built-in nats_, `MICRO_REGISTRY_ADDRESS` needs to be set to the address of the nats-js cluster, which is the same value as `OCIS_EVENTS_ENDPOINT`. Optional: Use `MICRO_REGISTRY_AUTH_USERNAME` and `MICRO_REGISTRY_AUTH_PASSWORD` to authenticate with the nats cluster.
* *memory* +
-Setting the environment variable to memory starts an in-memory registry. This only works with the single binary deployment.
+Setting the environment variable to memory starts an in-memory registry. This only works with the developer version of Infinite Scale.
diff --git a/modules/ROOT/pages/deployment/services/s-list/audit.adoc b/modules/ROOT/pages/deployment/services/s-list/audit.adoc
index 86e8bd32c..2874faf9f 100644
--- a/modules/ROOT/pages/deployment/services/s-list/audit.adoc
+++ b/modules/ROOT/pages/deployment/services/s-list/audit.adoc
@@ -33,7 +33,7 @@ Example json::
{"RemoteAddr":"","User":"user_id","URL":"","Method":"","UserAgent":"","Time":"","App":"admin_audit","Message":"user 'user_id' removed file 'item_id' from trashbin","Action":"file_trash_delete","CLI":false,"Level":1,"Path":"path","Owner":"user_id","FileID":"item_id"}
----
-The audit service is not started automatically when running as single binary started via `ocis server` or when running as docker container and must be started and stopped manually on demand.
+The audit service is not started automatically when started via `ocis server` or when running as docker container and must be started and stopped manually on demand.
Per default, it will be logged to standard out, but can also be configured to write into a file. Note that when a file output is used, it is not part of the standard log file but a separate one.
diff --git a/modules/ROOT/pages/deployment/services/s-list/collaboration.adoc b/modules/ROOT/pages/deployment/services/s-list/collaboration.adoc
index 7bc3a01e2..19840e4bc 100644
--- a/modules/ROOT/pages/deployment/services/s-list/collaboration.adoc
+++ b/modules/ROOT/pages/deployment/services/s-list/collaboration.adoc
@@ -38,7 +38,7 @@ The collaboration service requires the target document server (ONLYOFFICE, Colla
* xref:{s-path}/gateway.adoc[gateway] service.
* xref:{s-path}/app-provider.adoc[app provider] service.
-If any of the named services above have not been started or are not reachable, the collaboration service won't start. For the binary or the docker release of Infinite Scale, check with the xref:deployment/general/general-info.adoc#infinite-scale-supervised-services[List running services] command if they have been started. If not, you must start them manually upfront before starting the collaboration service.
+If any of the named services above have not been started or are not reachable, the collaboration service won't start. Check with the xref:deployment/general/general-info.adoc#infinite-scale-supervised-services[List running services] command if they have been started. If not, you must start them manually upfront before starting the collaboration service.
== WOPI Configuration
diff --git a/modules/ROOT/pages/deployment/services/s-list/postprocessing.adoc b/modules/ROOT/pages/deployment/services/s-list/postprocessing.adoc
index 12fa35a1b..ceffccd84 100644
--- a/modules/ROOT/pages/deployment/services/s-list/postprocessing.adoc
+++ b/modules/ROOT/pages/deployment/services/s-list/postprocessing.adoc
@@ -136,7 +136,7 @@ ocis postprocessing resume -s "virusscan" # Resume all uploads currently in viru
// renders dependent on is_cache or is_store
:is_store: true
-The `postprocessing` service needs to store some metadata about uploads to be able to orchestrate post-processing. When running in single binary mode, the default in-memory implementation will be just fine. In distributed deployments it is recommended to use a persistent store, see below for more details.
+The `postprocessing` service needs to store some metadata about uploads to be able to orchestrate post-processing. In distributed deployments it is recommended to use a persistent store, see below for more details.
// get the complete .adoc page but do not render any contained tag directive when found in the middle
include::partial$multi-location/cache-store.adoc[tag=**]
diff --git a/modules/ROOT/pages/deployment/services/s-list/storage-users.adoc b/modules/ROOT/pages/deployment/services/s-list/storage-users.adoc
index 5c54ca198..64fc76dce 100644
--- a/modules/ROOT/pages/deployment/services/s-list/storage-users.adoc
+++ b/modules/ROOT/pages/deployment/services/s-list/storage-users.adoc
@@ -19,7 +19,7 @@
With Infinite Scale, you can define a graceful shutdown period for the `storage-users` service.
-IMPORTANT: The graceful shutdown period is only applicable if the `storage-users` service runs as standalone service. It does not apply if the `storage-users` service runs as part of the single binary or as single Docker environment. To build an environment where the `storage-users` service runs as a standalone service, you must start two instances, one _without_ the `storage-users` service and one _only with_ the the `storage-users` service. Note that both instances must be able to communicate on the same network.
+IMPORTANT: The graceful shutdown period is only applicable if the `storage-users` service runs as standalone service. It does not apply if the `storage-users` service runs as single Docker environment. To build an environment where the `storage-users` service runs as a standalone service, you must start two instances, one _without_ the `storage-users` service and one _only with_ the the `storage-users` service. Note that both instances must be able to communicate on the same network.
When hard-stopping Infinite Scale, for example with the `kill <pid>` command (SIGKILL), it is possible and likely that not all data from the decomposedfs (metadata) has been written to the storage which may result in an inconsistent decomposedfs. When gracefully shutting down Infinite Scale, using a command like SIGTERM, the process will no longer accept any write requests from _other_ services and will try to write the internal open requests which can take an undefined duration based on many factors. To mitigate that situation, the following things have been implemented:
@@ -225,7 +225,7 @@ ocis storage-users trash-bin purge-expired
The behaviour of the `purge-expired` command can be configured by using the following environment variables.
* `STORAGE_USERS_PURGE_TRASH_BIN_USER_ID` +
-Used to obtain space trash-bin information and takes the system admin user as the default which is the `OCIS_ADMIN_USER_ID` but can be set individually. It should be noted, that the `OCIS_ADMIN_USER_ID` is only assigned automatically when using the single binary deployment and must be manually assigned in all other deployments. The command only considers spaces to which the assigned user has access and delete permission.
+Used to obtain space trash-bin information and takes the system admin user as the default which is the `OCIS_ADMIN_USER_ID` but can be set individually. It should be noted, that the `OCIS_ADMIN_USER_ID` must be manually assigned in all other deployments. The command only considers spaces to which the assigned user has access and delete permission.
* `STORAGE_USERS_PURGE_TRASH_BIN_PERSONAL_DELETE_BEFORE` +
Has a default value of `720h` which equals `30 days`. This means, the command will delete all files older than `30 days`. The value is human-readable, for valid values see the duration type described in the xref:deployment/services/envvar-types-description.adoc[Environment Variable Types]. A value of `0` is equivalent to disable and prevents the deletion of `personal space` trash-bin files.
diff --git a/modules/ROOT/pages/deployment/services/s-list/thumbnails.adoc b/modules/ROOT/pages/deployment/services/s-list/thumbnails.adoc
index 100b3f2ac..28e5c70f0 100644
--- a/modules/ROOT/pages/deployment/services/s-list/thumbnails.adoc
+++ b/modules/ROOT/pages/deployment/services/s-list/thumbnails.adoc
@@ -17,7 +17,7 @@ Note for developers, more information is available with regards to querying thum
== Thumbnailing Performance
-Thumbnail generation can consume considerably resources. For thumbnailing, two libraries are available. One library is embedded in the thumbnail service and statically linked where the other one is an external shared library, dynamically linked and must be available via the OS when accessing. The external shared library is not only much faster, but also provides more possible image types that can be converted. While the embedded library is only available with the binary deployment, the external library is built and preconfigured with the container deployment only. Note, if required, you can manually add the shared library to your OS and build Infinite Scale for the binary deployment on your own. To do so, see the https://owncloud.dev/services/thumbnails/[developer documentation, window=_blank] for more details.
+Thumbnail generation can consume considerably resources. For thumbnailing, two libraries are available. One library is embedded in the thumbnail service and statically linked where the other one is an external shared library, dynamically linked and must be available via the OS when accessing. The external shared library is not only much faster, but also provides more possible image types that can be converted. While the embedded library is only available with the developer version of Infinite Scale, the external library is built and preconfigured with the container deployment only. Note, if required, you can manually add the shared library to your OS and build Infinite Scale for the developer version on your own. To do so, see the https://owncloud.dev/services/thumbnails/[developer documentation, window=_blank] for more details.
== Configuration Hints
diff --git a/modules/ROOT/pages/deployment/storage/general-considerations.adoc b/modules/ROOT/pages/deployment/storage/general-considerations.adoc
index 04939a43d..cd1a5280a 100644
--- a/modules/ROOT/pages/deployment/storage/general-considerations.adoc
+++ b/modules/ROOT/pages/deployment/storage/general-considerations.adoc
@@ -9,7 +9,7 @@
Note that depending on the storage used, special settings can be defined to optimize resources for memory and performance.
-For a quick and rough overview, the following storages are mapped against an expected sizing. Note the way that Infinite Scale is setup like as xref:depl-examples/bare-metal.adoc[binary] or via an xref:deployment/container/orchestration/orchestration.adoc[orchestration] with its variants usually comes along with the expected sizing or usecase:
+For a quick and rough overview, the following storages are mapped against an expected sizing. Note the way that Infinite Scale is setup like via the xref:deployment/container/orchestration/orchestration.adoc[orchestration] with its variants usually comes along with the expected sizing or usecase:
{empty} +
diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc
index deb818ecd..bb163278e 100644
--- a/modules/ROOT/pages/index.adoc
+++ b/modules/ROOT/pages/index.adoc
@@ -14,9 +14,6 @@
// IMPORTANT: this permalink origins to: https://cloud.owncloud.com/index.php/apps/files/?dir=/Shared/owncloud/Product%20Management/Presentations/2023-05-22_Infinite%20Scale%20current%20state&fileid=6005441
-See the following PDF document for a brief
-https://cloud.owncloud.com/index.php/s/S7W9NPfKSHAoEYB[overview of Infinite Scale,window=_blank].
-
=== Target Audience
This documentation addresses administrators and technically-oriented management:
@@ -37,7 +34,7 @@ The key benefits are::
* No need for PHP or a database.
* High performance, flexibility and scalability.
* Extended functionality.
-* Single binary or container delivery, shipped with the user interface `ownCloud Web`.
+* Container delivery, shipped with the user interface `ownCloud Web`.
See the following in-line YouTube video for more details or use the link:{ocis_youtube_long_url}[link, window=_blank] to view it in a separate browser tab.
@@ -65,7 +62,7 @@ With Infinite Scale, not much is needed to run your ownCloud server the way you
=== Deployment
-Infinite Scale can be deployed via container or you can run the binary installed on a physical or virtual machine. Take a look at the xref:deployment/index.adoc[deployment] options for more details.
+Infinite Scale is deployed via container. Take a look at the Deployment Examples section in the navigation for more details.
NOTE: We highly recommend reading the xref:deployment/general/general-info.adoc[General Info] document first before starting to plan or deploy Infinite Scale. This document contains important topics relevant for all deployments.
@@ -81,21 +78,6 @@ You can find more details on changes made in each release published in the https
IMPORTANT: Rolling releases are published in a cycle of 3 weeks. Due to this relative short cycle, you will find the actual development and the current published rolling release documentation *not* separated. They are both part of the `next` segment in the URL. Compared to production releases where the respective release number is used, the actual rolling release number published can be found e.g. in each service description in section "Environment Variables".
-== Try Online
-
-You can try Infinite Scale before you install it locally to get hands-on experience and a feeling for how things work and integrate. Our development provides several instances with different setups to test. The instances are reset on a regular basis. See our https://owncloud.dev/ocis/deployment/continuous_deployment/[Continuous Deployment,window=_blank] page for more details.
-
== End-User License Agreement (EULA)
ownCloud provides an EULA to clarify, among various topics, who can use this software and which conditions apply to the groups of users defined. See the actual {compose_raw_url}{compose_url_component}/assets/End-User-License-Agreement-for-ownCloud-Infinite-Scale.pdf[EULA] for details.
-
-////
-
-=== Maintenance
-
-Since the integrity and sovereignty of your data is the really important thing when it comes to working in a cloud, you'll need to perform regular backups of your data and keep your Infinite Scale up to date. You'll find everything you need to know in the xref:maintenance/index.adoc[Maintenance] section.
-
-== Upgrading from ownCloud 10
-
-If you already have an ownCloud 10 server running, you'll find the xref:migration/index.adoc[Migration] section most interesting.
-////
diff --git a/modules/ROOT/pages/maintenance/b-r/backup.adoc b/modules/ROOT/pages/maintenance/b-r/backup.adoc
index a3d6a8463..7ac5757b5 100644
--- a/modules/ROOT/pages/maintenance/b-r/backup.adoc
+++ b/modules/ROOT/pages/maintenance/b-r/backup.adoc
@@ -42,7 +42,7 @@ Keep in mind that you always have to back up all data sets consistently:
(2) ... For POSIX-only environments, the location for blobs and metadata is the same. When using S3, the location differs. The backup process must include the metadata to be complete, for details see xref:prerequisites/prerequisites.adoc#filesystems-and-shared-storage[Filesystems and Shared Storage].
-As a rule of thumb, consider also to back up the Infinite Scale binary or the container used including the configuration. This avoids difficulties when restoring the instance and possibly using an updated Infinite Scale version compared to the version used when backing up. Restoring and updating should always be different tasks.
+As a rule of thumb, consider also to back up the Infinite Scale container used including the configuration. This avoids difficulties when restoring the instance and possibly using an updated Infinite Scale version compared to the version used when backing up. Restoring and updating should always be different tasks.
== Pure POSIX Setup
diff --git a/modules/ROOT/pages/maintenance/b-r/restore.adoc b/modules/ROOT/pages/maintenance/b-r/restore.adoc
index 46cf10ace..dd0e7d551 100644
--- a/modules/ROOT/pages/maintenance/b-r/restore.adoc
+++ b/modules/ROOT/pages/maintenance/b-r/restore.adoc
@@ -35,7 +35,7 @@ Valid for all restore procedures:
* first check the basic configuration of Infinite Scale on the backup to prepare the necessary volumes, mount points and directories if they are not present on your Infinite Scale instance,
* Infinite Scale must be in stopped state.
-As a rule of thumb, consider also to restore the Infinite Scale binary or the backed-up container. This avoids difficulties after restoring the instance and possibly using an updated Infinite Scale version compared to the version used when backing up. Restoring and updating should always be different tasks.
+As a rule of thumb, consider also to restore the Infinite Scale backed-up container. This avoids difficulties after restoring the instance and possibly using an updated Infinite Scale version compared to the version used when backing up. Restoring and updating should always be different tasks.
== Pure POSIX Setup
diff --git a/modules/ROOT/pages/maintenance/commands/commands.adoc b/modules/ROOT/pages/maintenance/commands/commands.adoc
index 641172e78..9a41bac34 100644
--- a/modules/ROOT/pages/maintenance/commands/commands.adoc
+++ b/modules/ROOT/pages/maintenance/commands/commands.adoc
@@ -8,12 +8,9 @@
[NOTE]
====
-* Calling a service in the examples is made via the single binary.
+* Calling a service in the examples is made by entering the shell of the container first.
* Generic call: +
`ocis <service name> arguments options`.
-* This changes if some services are available as executable on their own, then it would be: +
-`<service name> arguments options`. +
-This could happen if services are developed which are not shipped as part of the single binary.
====
== Changed CLI Commands
diff --git a/modules/ROOT/pages/maintenance/commands/rolling-back-and-forward.adoc b/modules/ROOT/pages/maintenance/commands/rolling-back-and-forward.adoc
index 50d19a153..692a7e62f 100644
--- a/modules/ROOT/pages/maintenance/commands/rolling-back-and-forward.adoc
+++ b/modules/ROOT/pages/maintenance/commands/rolling-back-and-forward.adoc
@@ -2,7 +2,7 @@
WARNING: Use this command with absolute care. It is not intended to play around and should only be used on request and under supervision of ownCloud support.
-It is important to disable clients and users logging in while any migration is in progress. To do so, start Infinite Scale with only two necessary services. The example uses the binary as base:
+It is important to disable clients and users logging in while any migration is in progress. To do so, start Infinite Scale container with only two necessary services:
[source,bash]
----
diff --git a/modules/ROOT/pages/migration/upgrading_7.0.0_7.1.0.adoc b/modules/ROOT/pages/migration/upgrading_7.0.0_7.1.0.adoc
index 6cb826621..c1e27eb0f 100644
--- a/modules/ROOT/pages/migration/upgrading_7.0.0_7.1.0.adoc
+++ b/modules/ROOT/pages/migration/upgrading_7.0.0_7.1.0.adoc
@@ -17,7 +17,7 @@ IMPORTANT: Check below, if you are affected by breaking changes and prepare all
== Upgrade Steps
. Download and install Infinite Scale +
-*Do not start it after downloading the binary or image*!
+*Do not start it after downloading the image*!
. Shut down the Infinite Scale instance
. We strongly recommend doing a backup
. Reconfigure the deployment
@@ -30,10 +30,6 @@ IMPORTANT: Check below, if you are affected by breaking changes and prepare all
Download and install Infinite Scale via:
-=== Binary
-
-Follow the xref:depl-examples/minimal-bare-metal.adoc#installation[Installation] section of the bare metal deployment example.
-
=== Image Based Deployments
* Issue the following command to download the new image:
@@ -47,9 +43,6 @@ docker pull owncloud/ocis:{actual_seven_version}
Depending how you deployed Infinite Scale, you need to shut it down differently.
-* *Binary* +
-For binary deployments, do a graceful shutdown as described in xref:depl-examples/minimal-bare-metal.adoc#stopping-infinite-scale[Stopping Infinite Scale].
-
* *docker run* +
For depoyments using `docker run` do a graceful shutdown as described in xref:depl-examples/container-setup.adoc#stop-a-running-container[Stop a Running Container].
diff --git a/modules/ROOT/pages/prerequisites/prerequisites.adoc b/modules/ROOT/pages/prerequisites/prerequisites.adoc
index 8f31c72f7..f5ae2b265 100644
--- a/modules/ROOT/pages/prerequisites/prerequisites.adoc
+++ b/modules/ROOT/pages/prerequisites/prerequisites.adoc
@@ -24,7 +24,7 @@
{description}
-Note that Infinite Scale is based on a highly dynamic interoperable _microservices_ concept, although it is delivered as a single binary. Of course, this software has to run on hardware, but its ability to adapt to various and maybe dynamic load scenarios across physical boundaries means that you can set up your physical environment flexibly, using modern technology.
+Note that Infinite Scale is based on a highly dynamic interoperable _microservices_ concept, although it is delivered via a container that uses a single binary. Of course, this software has to run on hardware, but its ability to adapt to various and maybe dynamic load scenarios across physical boundaries means that you can set up your physical environment flexibly, using modern technology.
The following sections are fundamental to understanding the general prerequisites, but their implementation is very dependent on your use-case. To support your decision about the environment, we recommend reading the documents about xref:architecture/architecture.adoc[Architecture and Concepts] and xref:availability_scaling/availability_scaling.adoc[Availability and Scalability] first.
@@ -252,7 +252,7 @@ It is strongly recommend to use a reverse proxy for:
. load balancing and
. high availability.
-The Infinite Scale documentation will use *traefik* for examples, but you can use NGINX, Apache or others too. All three products provide either a binary or docker file to download.
+The Infinite Scale documentation will use *traefik* for deployment examples.
[quote, '(C) {traefik_github_url}[Traefik Labs, The Cloud Native Application Proxy]']
____
diff --git a/modules/ROOT/pages/quickguide/quickguide.adoc b/modules/ROOT/pages/quickguide/quickguide.adoc
deleted file mode 100644
index 46dff15e0..000000000
--- a/modules/ROOT/pages/quickguide/quickguide.adoc
+++ /dev/null
@@ -1,46 +0,0 @@
-= Quick Guide
-:toc:right
-:description: This quick guide provides copy and paste commands to have an Infinite Scale instance up and running within minutes for hands on use. Read the documentation for details before you dive down and plan to deploy into production.
-
-include::partial$multi-location/compose-version.adoc[]
-
-== Introduction
-
-{description}
-
-Using this guide will get a minimal configured environment including demo users up and running but can by nature not go into depth. Note that the binary used is based on `linux-amd-64bit`.
-
-We recommend reading the xref:deployment/index.adoc[Deployment] section of the documentation as the next step for more information on setup and configuration possibilities.
-
-== Setup
-
-Open a shell and copy/paste the following commands:
-
-[source,bash,subs="attributes+"]
-----
-sudo wget -O /usr/local/bin/ocis \
- {ocis-downloadpage-url}/{download-type}/{compose_version}/ocis-{compose_version}-linux-amd64
-----
-
-[source,bash]
-----
-sudo chmod +x /usr/local/bin/ocis
-----
-
-[source,bash]
-----
-ocis init
-----
-
-[source,bash]
-----
-OCIS_INSECURE=true \
-IDM_CREATE_DEMO_USERS=true \
-PROXY_HTTP_ADDR=0.0.0.0:9200 \
-OCIS_URL=https://localhost:9200 \
-ocis server
-----
-
-After installing and starting Infinite Scale, you can access the web UI via `\https://localhost:9200`
-
-include::partial$multi-location/idm-https-reverse-proxy.adoc[]
diff --git a/modules/ROOT/partials/deployment/apache_80_example.adoc b/modules/ROOT/partials/deployment/apache_80_example.adoc
deleted file mode 100644
index 4cffaa217..000000000
--- a/modules/ROOT/partials/deployment/apache_80_example.adoc
+++ /dev/null
@@ -1,8 +0,0 @@
-[source,apache,subs="attributes+"]
-----
-<IfModule mod_rewrite.c>
- <VirtualHost *:80>
- ServerName {ocis_url}
- </VirtualHost>
-</IfModule>
-----
diff --git a/modules/ROOT/partials/deployment/apache_harden_ssl.adoc b/modules/ROOT/partials/deployment/apache_harden_ssl.adoc
deleted file mode 100644
index f4c3fab78..000000000
--- a/modules/ROOT/partials/deployment/apache_harden_ssl.adoc
+++ /dev/null
@@ -1,15 +0,0 @@
-[source,apache]
-----
-# restrict ciphers
-SSLCipherSUite "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:!SHA1:!SHA256:!SHA384:!RC4:!aNULL:!eNULL:!Medium:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!SEED"
-
-# use multiple curves (only if dhparams file is used)
-SSLOpenSSLConfCmd Curves secp521r1:secp384r1
-
-# add strict transport security
-SSLOptions +StrictRequire
-Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
-
-# disable ssl compression
-SSLCompression off
-----
diff --git a/modules/ROOT/partials/deployment/apache_proxy_example.adoc b/modules/ROOT/partials/deployment/apache_proxy_example.adoc
deleted file mode 100644
index c02fef51e..000000000
--- a/modules/ROOT/partials/deployment/apache_proxy_example.adoc
+++ /dev/null
@@ -1,39 +0,0 @@
-[source,apache,subs="attributes+"]
-----
-<IfModule mod_rewrite.c>
- <VirtualHost *:80>
- ServerName {ocis_url}
-
- # redirect all http urls to https
- RewriteEngine On
- RewriteCond %\{HTTPS} off
- RewriteRule (.*) https://%\{HTTP_HOST}%\{REQUEST_URI} [R=302,L,QSA]
-
- </VirtualHost>
-</IfModule>
-
-<IfModule mod_ssl.c>
- <VirtualHost *:443>
- ServerName {ocis_url}
-
- SSLProxyEngine on
- SSLProxyVerify none
- SSLProxyCheckPeerCN off
- SSLProxyCheckPeerName off
- SSLProxyCheckPeerExpire off
-
- ProxyPass / http://localhost:{ocis_port}/
- ProxyPassReverse / http://localhost:{ocis_port}/
-
- #important, otherwise 400 errors from idp
- ProxyPreserveHost on
-
- ## Actual values to be added by certbot
- # SSLCertificateFile /etc/letsencrypt/live/{ocis_url}/fullchain.pem
- # SSLCertificateKeyFile /etc/letsencrypt/live/{ocis_url}/privkey.pem
-
- # Include /etc/letsencrypt/options-ssl-apache.conf
- # SSLOpenSSLConfCmd DHParameters /etc/letsencrypt/ssl-dhparams.pem
- </VirtualHost>
-</IfModule>
-----
diff --git a/modules/ROOT/partials/deployment/dependent_startup.adoc b/modules/ROOT/partials/deployment/dependent_startup.adoc
deleted file mode 100644
index 22440cb11..000000000
--- a/modules/ROOT/partials/deployment/dependent_startup.adoc
+++ /dev/null
@@ -1,5 +0,0 @@
-= Dependent Infinite Scale Service Startup
-
-If you want to ensure that you have a necessary service like a NFS mount point up and running _before_ the Infinite Scale service starts up, see xref:deployment/tips/useful_mount_tip.adoc[Start a Service After a Resource is Mounted].
-
-NOTE: This step can be an important measure, because if the Infinite Scale service starts up but the necessary mount point is not available, you may be in an undefined Infinite Scale operating state.
diff --git a/modules/ROOT/partials/deployment/nginx_80_example.adoc b/modules/ROOT/partials/deployment/nginx_80_example.adoc
deleted file mode 100644
index 5c931e958..000000000
--- a/modules/ROOT/partials/deployment/nginx_80_example.adoc
+++ /dev/null
@@ -1,9 +0,0 @@
-[source,nginx,subs="attributes+"]
-----
-server {
- listen 80 ;
- listen [::]:80 ;
-
- server_name {ocis_url};
-}
-----
diff --git a/modules/ROOT/partials/deployment/nginx_harden_ssl.adoc b/modules/ROOT/partials/deployment/nginx_harden_ssl.adoc
deleted file mode 100644
index 1e51cdeab..000000000
--- a/modules/ROOT/partials/deployment/nginx_harden_ssl.adoc
+++ /dev/null
@@ -1,22 +0,0 @@
-[source,nginx]
-----
- # protocol, session timout, server cipers
- # NOTE: ssl cache is handled by certbot
- # also see: https://github.com/certbot/certbot/blob/master/certbot-nginx/certbot_nginx/_internal/tls_configs/options-ssl-nginx.conf
-
- # restrict ciphers
- #
- # IMPORTANT: depending on your setup, it is possible that certbot will also define the ciphers used.
- # this can lead to a nginx error about already defined ciphers. in such a case, you can comment out
- # the cipher definition here.
- ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:!SHA1:!SHA256:!SHA384:!RC4:!aNULL:!eNULL:!Medium:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!SEED";
-
- # use multiple curves (only if dhparams file is used)
- ssl_ecdh_curve secp521r1:secp384r1;
-
- # reduce time to first byte
- ssl_buffer_size 4k;
-
- # add strict transport security
- add_header Strict-Transport-Security "max-age=15768000; must-revalidate; includeSubDomains; preload;" always;
-----
diff --git a/modules/ROOT/partials/deployment/nginx_proxy_example.adoc b/modules/ROOT/partials/deployment/nginx_proxy_example.adoc
deleted file mode 100644
index febf12b79..000000000
--- a/modules/ROOT/partials/deployment/nginx_proxy_example.adoc
+++ /dev/null
@@ -1,44 +0,0 @@
-[source,nginx,subs="attributes+"]
-----
-server {
- listen 80 ;
- listen [::]:80 ;
-
- server_name {ocis_url};
-
- # location to redirect to https
- location / {
- # add port if deviates via OCIS_URL
- return 301 https://$server_name$request_uri;
- }
-}
-
-server {
- # default 443 but can deviate if set in OCIS_URL
- listen 443 ssl http2;
- listen [::]:443 ssl http2;
-
- server_name {ocis_url};
-
- # certificates managed by Certbot
- ssl_certificate /etc/letsencrypt/live/{ocis_url}/fullchain.pem;
- ssl_certificate_key /etc/letsencrypt/live/{ocis_url}/privkey.pem;
-
- # options and dhparams managed by Certbot
- include /etc/letsencrypt/options-ssl-nginx.conf;
- ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
-
- location / {
- # OIDC Tokens in headers are quite large and can exceed default limits of reverse proxies
- proxy_buffers 4 256k;
- proxy_buffer_size 128k;
- proxy_busy_buffers_size 256k;
-
- # Disable checking of client request body size
- client_max_body_size 0;
-
- proxy_pass http://localhost:{ocis_port};
- proxy_set_header Host $host;
- }
-}
-----
diff --git a/modules/ROOT/partials/deployment/services/env-and-yaml.adoc b/modules/ROOT/partials/deployment/services/env-and-yaml.adoc
index f8ffa3206..b0f093dc5 100644
--- a/modules/ROOT/partials/deployment/services/env-and-yaml.adoc
+++ b/modules/ROOT/partials/deployment/services/env-and-yaml.adoc
@@ -27,7 +27,7 @@ include::partial$multi-location/tab-text.adoc[]
+
--
[caption=]
-.Environment variables only available for binary deployments
+.Environment variables to define services when starting the container
[width="100%",cols="30%,70%",options="header"]
|===
| Name
diff --git a/modules/ROOT/partials/deployment/systemd.adoc b/modules/ROOT/partials/deployment/systemd.adoc
deleted file mode 100644
index 7b841cbf8..000000000
--- a/modules/ROOT/partials/deployment/systemd.adoc
+++ /dev/null
@@ -1,57 +0,0 @@
-To run the *Infinite Scale runtime* as a {systemd-url}[systemd,window=_blank] service, create the file `/etc/systemd/system/ocis.service` with the content provided below. The easiest way to do this is with the following command:
-
-[source,bash]
-----
-sudo systemctl edit --force --full ocis.service
-----
-
-Then copy the content of the systemd file below into the editor and save it.
-[caption=]
-.systemd file
-[source,plaintext,subs="attributes+"]
-----
-[Unit]
-Description=OCIS server
-
-[Service]
-Type=simple
-User=ocis
-Group=ocis
-EnvironmentFile={ocis_env}/ocis.env
-ExecStart={ocis_bin}/ocis server
-Restart=always
-
-[Install]
-WantedBy=multi-user.target
-----
-
-Run the following command to apply your changes:
-
-[source,bash]
-----
-sudo systemctl daemon-reload
-----
-
-Now you can run Infinite Scale as a systemd service. Start it with:
-
-[source,bash]
-----
-sudo systemctl enable --now ocis
-----
-
-With this setup, Infinite Scale is also restarted automatically after a reboot.
-
-If you need to restart Infinite Scale because of configuration changes in `/etc/ocis/ocis.env`, run:
-
-[source,bash]
-----
-sudo systemctl restart ocis
-----
-
-The systemd logs of Infinite Scale can be displayed by issuing:
-
-[source,bash]
-----
-sudo journalctl -f -u ocis
-----
-
diff --git a/modules/ROOT/partials/multi-location/event-bus.adoc b/modules/ROOT/partials/multi-location/event-bus.adoc
index ab599b987..e64324b8e 100644
--- a/modules/ROOT/partials/multi-location/event-bus.adoc
+++ b/modules/ROOT/partials/multi-location/event-bus.adoc
@@ -8,8 +8,6 @@ The Infinite Scale event bus can be configured by a set of environment variables
[NOTE]
====
-* If you are using a binary installation as described in xref:depl-examples/minimal-bare-metal.adoc[Minimal Bare Metal Deployment] or xref:depl-examples/bare-metal.adoc[Bare Metal with systemd], the address of the event bus `OCIS_EVENTS_ENDPOINT` is predefined as localhost address without the need for further configuration, but changeable on demand.
-
* In case of an orchestrated installation like with Docker or Kubernetes, the event bus must be an external service for scalability like a `Redis Sentinel cluster` or a key-value-store https://docs.nats.io/nats-concepts/jetstream/key-value-store[NATS JetStream]. Both named stores are supported and also used in xref:deployment/services/caching.adoc[Caching and Persistence]. The store used is not part of the Infinite Scale installation and must be separately provided and configured.
* Note that from a configuration point of view, caching and persistence are independent of the event bus configuration.
diff --git a/modules/ROOT/partials/multi-location/idm-https-reverse-proxy.adoc b/modules/ROOT/partials/multi-location/idm-https-reverse-proxy.adoc
index e9edd9341..f828ad901 100644
--- a/modules/ROOT/partials/multi-location/idm-https-reverse-proxy.adoc
+++ b/modules/ROOT/partials/multi-location/idm-https-reverse-proxy.adoc
@@ -11,5 +11,5 @@ See the following sections for more details and information:
*** xref:deployment/general/general-info.adoc#configurations-to-access-the-web-ui[Configurations to Access the Web UI].
* When accessing the server using a dedicated domain name:
-** You *must* use a reverse proxy. When Infinite Scale is accessed, it forwards requests to the embedded xref:{s-path}/idp.adoc[IDP service] which requires a secure connection and a domain name that matches the reverse proxy settings. See the xref:depl-examples/bare-metal.adoc[Bare Metal Deployment with systemd] for more details on using a reverse proxy setup.
+** You *must* use a reverse proxy. When Infinite Scale is accessed, it forwards requests to the embedded xref:{s-path}/idp.adoc[IDP service] which requires a secure connection and a domain name that matches the reverse proxy settings.
====
diff --git a/modules/ROOT/partials/nav.adoc b/modules/ROOT/partials/nav.adoc
index 3d493acdc..1cac4c871 100644
--- a/modules/ROOT/partials/nav.adoc
+++ b/modules/ROOT/partials/nav.adoc
@@ -1,5 +1,4 @@
* xref:index.adoc[Introduction]
-** xref:quickguide/quickguide.adoc[Quick Guide]
* Infinite Scale Overview
** xref:architecture/architecture.adoc[Architecture and Concepts]
** xref:availability_scaling/availability_scaling.adoc[Availability and Scalability]
@@ -92,8 +91,6 @@
** xref:conf-examples/office/office-integration.adoc[Office Integration]
** xref:conf-examples/search/configure-search.adoc[Search]
* Deployment Examples
-** xref:depl-examples/minimal-bare-metal.adoc[Minimal Bare Metal]
-** xref:depl-examples/bare-metal.adoc[Bare Metal with systemd]
** xref:depl-examples/container-setup.adoc[Container Setup]
** Ubuntu with Docker Compose
*** xref:depl-examples/ubuntu-compose/ubuntu-compose-prod.adoc[Local Production Setup]