island hopping

Continuing from yesterday’s post I’ve been working through figuring out my deployment of Archipelago. I decided to go down what I thought was the simple route of reverse proxying to the Docker container with NGINX, and initially Drupal cooperated without issue. The snag came with the IIIF image server, i.e. Cantaloupe. At first I tried copying the config of our Islandora server at work:

upstream cantaloupe {
  server  127.0.0.1:8182;
}

server { #standard server stuff left out here

location /iiif/2/ { proxy_read_timeout 90; proxy_connect_timeout 90; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Port $server_port; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; if ($request_uri ~* "/(.*)") { proxy_pass http://cantaloupe/$1; } } #below here is the base location, i.e. reverse proxy to Drupal }

I had some trouble with that if section, but I think ultimately this would have worked just fine. The problem was that the upstream server had assets at its root that conflicted with Drupal. So no problem, reverse proxy the whole image server from its own subdomain, right? womp womp. Hello CORS issues. Fine then, I’ll just copypasta some NGINX CORS lines to wildcard subdomain. Foiled again. Double CORS header errors in the browser. Turns out Drupal sets its own default CORS options in its config. Final answer:

  1. Copy default.services.yml to services.yml in Drupal’s web/sites/default folder.
  2. Change the default cors.config to the following (for example).
  cors.config:
    enabled: true
    # Specify allowed headers, like 'x-allowed-header'.
    allowedHeaders: ['x-csrf-token','authorization','content-type','accept','origin','x-requested-with', 'access-control-allow-origin','x-allowed-header']
    # Specify allowed request methods, specify ['*'] to allow all possible ones.
    allowedMethods: ['GET']
    # Configure requests allowed from specific origins.
    allowedOrigins: ['*.albertmin.com']
    #I left defaults for the rest of the configuration below here.

Done and done. Onto the next set of troubles.

my islandora for an archipelago

Around this time last year I deployed Islandora 8 on my server and created a few objects with the intention of exploring the stack further. I never quite got around to the getting-any-further part, and now a new open source digital repository (developed mostly by the indefatigable Diego Pino, a major contributor to Islandora) is on the verge of being released. I’ve decided, both for work purposes and also out of personal curiosity, to give it a go, and since there are port conflicts in running both together, I’ve halted the vagrant box that was Islandora 8, and deployed the docker container that is Archipelago 1.0.0-RC1. Anyway, here is the same audio recording I ingested then as an Archipelago file:

How It’s Made

This blog is built using an open-source static site generator called Hugo, which is built with an open-source programming language called Go, and it’s hosted on my home server, which is an early 2011 MacBook Pro running Ubuntu. I’m right now writing this in an Android app called Markor (a document editor with Markdown preview capability), and once saved, I’ll run a Bash script with a terminal emulator (Termux) widget (which sits on my Pixel 3 home screen) that will copy that file via ssh to the server. The server then runs an inotify script that updates the static site and re-indexes the lunr.js module index.

A few years ago I wouldn’t have been able to tell you what any of the above meant. But I guess this is my life now.

this is fine meme


All Teh Taaaaaaaags