Cookbook: Multi-Tenancy with Aggregated Search & Browse

[bondjimbond]

This configuration will allow multiple Islandora 8 sites to share single installations of Fedora and Solr, replicating the multi-site capabilities of Islandora 7. Each site's repository objects are segregated within Fedora, use their own Solr cores, and are indexed by a "parent" site that can search and display content from all of the child sites together, without duplicating media.

Addresses or relates to the following extant Islandora 8 issues:

• Meta-Issue: Multi-tenancy in Fedora: #926
• Use case: Equivalent of "namespacing" Fedora to accommodate multisites: #396
• Ability to distinguish different types of content and content that belongs to different institutions: #478

Workflow

---

The Components

---

• Fedora:
  • Single installation
  • Separate Root containers for each tenant site
• Solr:
  • Separate cores: one per tenant
  • One aggregate core that indexes all tenant sites' content
  • Optional: Multiple installations (one for tenant sites, separate one for aggregate)
• Multiple Drupal 8 sites:
  • Can be separate Drupal installations or a multisite structure
  • Each child site configured to use a different Fedora root
  • Parent site can be configured with the main Fedora root, but will (probably) not write to Fedora at all
  • Each child site configured to read from its own Solr core, and write to both its own core and the aggregate core
  • Parent site configured to read from the aggregate core

Fedora Configuration

---

Fedora must be configured with separate containers (roots) for each tenant. 

1. In site setup, when a new site is established, a new basic container is created in Fedora off the root, something like <http://localhost:8080/fcrepo/rest/site1>. This should be added to the playbook.

2. Prepend that site1 path to all requests to place objects into that root like <http://localhost:8080/fcrepo/rest/site1/lo/ng/ur/lgoeshere>. This could be handled by adjusting the fedora_base_url and the crayfish_fedora_base_url in the playbook.

   • Probable approach: Change the settings.php for flysystem to tell it to look at the new root, and to pass the root into the mintFedoraUrl function in gemini so that the url gets passed to fedora reflects the new root.

Solr Configuration

---

The Islandora 8 installation playbook must be modified to include a new configuration option to spin up a multi-tenancy implementation. These steps should be added to the playbook, but are also included below for manual implementation.

Create a new Solr core for your new tenant (site1)

1. cd /var/solr/data

2. mkdir site1

3. Copy the conf directory from an existing Solr core to the new directory.

   • E.g. cp -r CLAW/conf site1/conf

Create an aggregate Solr core, following the same steps above (Site_All).

Drupal Configuration

---

Using the CLAW Playbook, install the Parent/Aggregate site first.

Then modify variables in the CLAW playbook to create separate child site installs according to your needs.

The Parent site is configured to use an aggregated Solr core.

The Child sites are configured to write simultaneously to both their own cores, and to the aggregate core.

Child sites will display only their own content, while the Parent site can display everything.

Individual Tenants

Setup (multisite or individual installs)

• Create a new Drupal install
  • You can use portions of the playbook
  • You may choose to install a separate Solr instance for the parent site, and a shared instance for the tenants
• Specify the Fedora root you created for this tenant site. Change variables: 
  • fedora_base_url
  • crayfish_base_url
• If not using the playbook, this is more involved. So don't do it.

Fedora configuration

• Specify your Fedora root for your new tenant site.
  • This must be done in the Playbook
  • DESIRED DEVELOPMENT: Select the Fedora root within the Drupal UI.
  • Possible path forward: Change the settings.php for flysystem and tell it to look at the new root, then pass the root into the mintFedoraUrl function in gemini so that the url gets passed to fedora reflects the new root (this requires a PR)

Solr configuration

Configure Solr to write to both Site1 core and Site_All core:

• Add new core:
  • Configuration -> Search and Metadata -> Search API
  • Add Server
  • Give it a name (Aggregate Core), select "Solr" as backend
  • Solr Connector: Standard
  • Select the new Solr core (Site_All)
• Create an Index:
  • Configuration -> Search and Metadata -> Search API
  • Add Index
  • Give it a name
  • Data sources: Content
  • Server: Select the new server (Aggregate Core)
• Fields tab:
  • Must re-create the configuration from the main search server
  • Rather than adding fields manually, copy the configuration:
    • Export the existing config (/admin/config/development/configuration/single/export)
      • Configuration Type: Search Index
      • Configuration Name: Default Solr content index
      • Copy the result
      • Paste the result into a document
      • Copy the field_settings section
    • Open the new config
      • Replace the field_settings section with your copy
      • Copy the whole config
  • Click the Import tab
    • Configuration Type: Search Index
    • Paste your new config
• Search results:
  • No configuration needed; the default search only uses the default core.
• If creating new views:
  • Choose "Index <aggregate index>" instead of Default Solr Content Index.

Security and Access Control: DEVELOPMENT NEEDED

• Access control for individual objects in Islandora 8 is not yet developed.

  • Migrating XACML access control restrictions: #1159)
  • Meta-Issue: Access Restrictions and Embargoes: #928)
  • AuthZ: Permit metadata access but deny (some) file access: #412)

• Multi-Tenancy Considerations:

  • Individual object access control permissions must be written to Solr.
  • Example: https://drupal.stackexchange.com/questions/202122/building-a-search-view-that-respects-access-control

Parent/Aggregate Site

Setup

• Create a standard Islandora site
• Go to the Search API settings
• Edit the Solr search server and change to the aggregate core 
• Reindex if needed

Security and Access Control

• We are expecting that access control rules will be available in Solr.
• Filters will be set up to respect those rules in the Search and Browse views.

Search configuration

• UNKNOWN: Will this display thumbnails? Or can we just grab them via URLs in the returned Solr fields?

Browse configuration: DEVELOPMENT NEEDED

• Create a stock View that provides Browsing functionality:
  • Can be done with pretty standard Views
  • THE DIFFICULT PART: Display objects as if they lived in the parent site
  • Embed media and metadata display in the View page

FUTURE DEVELOPMENT: Manage objects from parent site

A valuable feature of Islandora 7 multisites is that an administrator can edit and otherwise manage objects from within the parent site. We could use the REST API to replicate this functionality.

• Using the REST API, retrieve the object with all of its media and fields.
• Generate an editing form using a dynamic Javascript tool such as ViewJS.
• POST the JSON and/or updated media back to the child site via the REST API.

[elizoller]

^correction to above, you probably wouldn't want to change crayfish_fedora_base_url and rather rely on the minter to handle fedora urls including a root

[whikloj]

My suggestion is that we accept the Fedora base URI as part of the request to Milliner. Then a configuration change on the Drupal side would affect the URIs minted and where (i.e. the URI of Fedora) Milliner pushes to.

[bondjimbond]

@whikloj I don't know what Milliner is, but your suggestion sounds good.

[whikloj]

Milliner is the Crayfish microservice that PUTs RDF into Fedora. https://github.com/Islandora-CLAW/Crayfish/tree/dev/Milliner

[bondjimbond]

Then that sounds excellent. The more configuration we can make part of the Drupal UI, the better.

[bondjimbond]

Another thought on browse mode: we need to sort out a recommended Matomo configuration for tracking the usage of objects across both the individual sites and the aggregator site.

[bryjbrown]

@bondjimbond You could do that by setting up Matomo to send a unique identifier (UUID?) as part of the tracking, and then set up a Matomo custom API where you can request data for that specific unique identifier aggregated from all the sites.