Everything Must Go

EOS Is Complicated

If you want to follow ownCloud's recommendations to deploy oCIS along with EOS for large environments, you have to take some more steps. EOS not only adds to the amount of required hardware and increases the complexity of the whole environment, it's also a slightly bigger task to set up. To help, you will find separate and concise EOS documentation from CERN [3] and a step-by-step guide from ownCloud [11].

In a nutshell, users have to get and start EOS and oCIS containers; configure LDAP support; and kill home, user, and metadata storage before starting the EOS configuration. The Accounts service needs to be set up to work with EOS, too. All of these steps are docker compose commands, which are covered in the documentation.

The Storage backends | EOS page in the oCIS documentation also provides information on verification and troubleshooting and has a command reference for the built-in EOS shell. Said documentation also gives an impression into why dealing with oCIS is likely interesting only for large oCIS environments.

Data Paths

Although it is relatively easy to imagine the flow of data through ownCloud 10 with Apache and PHP, the great number of components in oCIS makes imagining the path of data more difficult. ownCloud therefore provides a diagram that explains the flow of data in detail [12]. Before working with oCIS for the first time, you should have a look at that document for a better understanding of data flow.

Initially, a file coming from a client will hit the oCIS proxy component, which is part of Traefik and ensures smooth load balancing across the different instances of oCIS components. The incoming request – in this example, a file upload – is then forwarded to one of the available Reva storage front ends.

From the administrator's point of view, it will look as if data disappears at this point. Reva comprises a number of microservices itself: a gateway for incoming requests, a DAV-speaking component that initially deals with incoming requests, and its own registry. The DAV component supplies the oCIS proxy with all relevant information for placing a file in the environment. Once Reva has successfully determined where the file needs to go, it reports that information back to the oCIS proxy, which finally puts the file into the desired location.

What looks like a side note here is in fact something very important to note: Just like ownCloud 10, oCIS continues to use the DAV interface for external clients. Therefore, any existing clients for ownCloud, including the project's very own iOS and Android applications, will continue to work with oCIS. It also allows ownCloud to create a bridge mode between ownCloud 10 and oCIS, making migrations from one system to the other much easier.

oCIS Configuration

Administrators familiar with ownCloud 10 or earlier are used to the tedious configuration process, because it is an application running inside a web server with PHP. Parts of the settings required affect PHP directly and must go into the PHP configuration file. Other settings are Apache-related and must be in the web server's configuration file (even there, you have different options, e.g., the VirtualHost or httpd configuration). Moreover, some ownCloud-specific configuration files define parameters such as the database connection to use. Tuning ownCloud 10 to the maximum accordingly requires a number of configuration file changes. Because these settings can be different on different Linux distributions, automating ownCloud has been a tedious task in the past.

oCIS changes the scene. Because ownCloud no longer requires Apache or PHP, their configuration files are absent. Instead, you are expected to use the ocis binary as the central command to control behavior. Understanding the power of that tool is tricky at first glance, though, so a closer look is necessary.