Migrating from ownCloud 10 to Infinite Scale

If you already have an ownCloud 10 running and want to start using Infinite Scale in parallel, either to find out if you want to migrate or to prepare for migration, proceed as follows.

New ownCloud Web

Start using the new ownCloud Web on your ownCloud 10 server to get familiar with the new look & feel. Switch back and forth, play around, then enable it for your users as well.

OpenID Connect

Introduce OpenID Connect, our primary authentication protocol. You can install the app from the ownCloud marketplace. Clients will detect the new authentication scheme when their current way of authenticating returns an error. Users will then have to reauthorize at the OpenID Connect IdP, which again, may be configured to skip the consent step for trusted clients.

There are multiple products that can be used as an OpenID Connect IdP. LibreGraph Connect is embedded in Infinite Scale. Alternatives include Keycloak or Ping. Refer to the corresponding setup instructions for the product you intend to use.

When OpenID Connect support is enabled verify that all clients can login:

  • Classic Web UI

  • ownCloud Web

  • Desktop client

  • Android client

  • iOS client

Legacy clients relying on Basic auth or app passwords need to be migrated to OpenId Connect to work with Infinite Scale. For a transition period Basic auth in Infinite Scale can be enabled with PROXY_ENABLE_BASIC_AUTH=true, but we strongly recommend adopting OpenID Connect for other tools as well.

While OpenID Connect providers will send an iss and sub claim that relying parties (services like Infinite Scale or ownCloud 10) can use to identify users, we recommend introducing a dedicated, globally unique, persistent, non-reassignable user identifier like a UUID for every user. This ownclouduuid should be sent as an additional claim to save additional lookups on the server side. It will become the user id in Infinite Scale, e.g. when searching for recipients, the ownclouduuid will be used to persist permissions with the share manager. It serves a different purpose than the ownCloud 10 username, which is used to log in. Using UUIDs we can not only mitigate username collisions when merging multiple instances but also allow renaming users after the migration to Infinite Scale has been completed.

Use Infinite Scale internally

Before letting Infinite Scale handle end user requests, make it available in the internal network first. By subsequently adding services, you can add functionality and verify the services work as intended.

Start Infinite Scale backend and make read-only tests on existing data using the owncloudsql storage driver which will read (and write):

  • blobs from the same data directory layout as in ownCloud 10,

  • metadata from the ownCloud 10 database, i.e. the Infinite Scale share manager will read share information from the ownCloud database using an ownCloud driver.

Deploy Infinite Scale storage provider with owncloudsql driver. Set read_only: true in the storage provider config and use the command line tool to list files using the CS3 API.

Multiple ownCloud instances can be merged into one Infinite Scale instance. To prevent a numeric ID collision, the file IDs will be prefixed with a new storage space ID which is used by Infinite Scale to route requests to the correct storage provider. See Stage 8 below.