Today’s quest… to build a new Handle.net server for Digital.Grinnell, preferably one that is “Dockerized”. I’m going to start by forking datacite/docker-handle, a project that looks promising, and following it along with the documentation in chapter 3 of the HANDLE.NET (version 9) Technical Manual. The aforementioned fork can now be found in DigitalGrinnell/docker-handle.

The digital7 Saga

My old friend and server (or should that be servant?), digital7, used to be the home of Digital.Grinnell in Islandora v7, before Docker and ISLE came along. It’s an Ubuntu 14.04.5 LTS server, and in addition to hosting Digital.Grinnell, it also used to host our HANDLE.NET server. Hmmm…

I tried valiantly to upgrade old digital7 from the OS on up, but failed. In the end, digital7 was retired, and its IP address assigned to a new CentOS 7 server named DGDocker3. So, I’ll be making a new home for HANDLE.NET services on DGDocker1, instead.

Port Status

The next step in my quest was to check some ports on DGDocker1, so I found you get signal’s Port Forwarding Tester, entered the IP address assigned to the host and then tested the two ports that HANDLE.NET demands. Rats! Neither was open, so I dispatched a help desk ticket to open them up. About a week later… they’re open.

docker-handle

I took my fork of the aforementioned datacite/docker-handle for a spin on DGDocker1, but honestly, it looks like a train wreck. I could not fathom how to make it work since most of the .env variables documented in the README.md file don’t seem to do anything in the configuration. 😕 I also found https://github.com/horizon-institute/handle.net-server-docker but it’s a Handle v8 instance, and I’m aiming for v9.

A Quick Solution

So, on 18-Sep-2019 I set out to install a non-Dockerized Handle server on DGDocker1. Installation followed the standard guidance found in Technical Manual, Handle.Net Version 9 and my instance now lives in /hs/handle-9.2.0 and /hs/svr_1 on the DGDocker1 host. In order to make my iduH tools work, I had to modify the /opt/ISLE/docker-compose.yml file so that it contains the following additional volume bind-mount:

   # Next line added 19-Sep-2019 so that batch jobs for the HANDLE server at the host's /hs directory can run properly.
   - /hs:/hs
That line maps the host's /hs folder into the isle-apache-dg container as the same path, enabling Handle batch and other commands to run within the container itself.

After these additions I tweaked the iduH command parameters found in idu_constants.inc, then I opened a shell into the Apache container on DGDocker1 via docker exec -it isle-apache-dg bash, and did:

cd /var/www/html/sites/default
drush -u 1 iduH grinnell:2-5000 MODIFY; drush -u 1 iduF grinnell:2-5000 SelfTransform --reorder
# Repeat drush... for other PID ranges

It worked! Note that in some instances a command of the form drush -u 1 iduH grinnell:2-5000 CREATE was necessary instead of “MODIFY”.

Restarting the Handle Server

Unfortunately, DGDocker1 sometimes has to be rebooted, and when that is necessary I also have to restart the Handle server using a command sequence (with output) like this, as root:

[root@dgdocker1 handle-9.2.0]# pwd
/hs/handle-9.2.0
[root@dgdocker1 handle-9.2.0]# ./bin/hdl-server /hs/svr_1
Handle.Net Server Software version 9.2.0
Enter the passphrase for this server's authentication private key:
Note: Your passphrase will be displayed as it is entered
>>>>> my super secret handle server password here <<<<<
HTTP handle Request Listener:
   address: 132.161.132.103
      port: 8000
Starting HTTP server...
TCP handle Request Listener:
   address: 132.161.132.103
      port: 2641
UDP handle Request Listener:
   address: 132.161.132.103
      port: 2641
Starting UDP request handlers...
Starting TCP request handlers...
^Z
[3]+  Stopped                 ./bin/hdl-server /hs/svr_1
[root@dgdocker1 handle-9.2.0]# bg
[3]+ ./bin/hdl-server /hs/svr_1 &
[root@dgdocker1 handle-9.2.0]# exit
exit
There are stopped jobs.

And that’s a wrap good place for a break… until I return to formally “Dockerize” this effort. 😄