ISLE Workflow Test
ISLE v1.3.0 has been running on my staging server, DGDockerX
, for about 6 weeks now and it seems to be performing as-expected with one exception… when I try to import a batch of objects using IMI, the Islandora Multi-Importer, I get the following error:
The website encountered an unexpected error. Please try again later.
An examination of Recent log messages shows…
GuzzleHttp\Exception\ConnectException: cURL error 6: Could not resolve host: sheets.googleapis.com (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) in GuzzleHttp\Handler\CurlFactory::createRejection() (line 200 of /var/www/html/sites/all/modules/islandora/islandora_multi_importer/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php).
Engaging the Local Workflow
Since I’m not at all sure what’s wrong, I feel like I need to rewind my process a bit and try to reproduce the same configuration, and error, on a local instance of this ISLE stack. This post will chronicle the steps I take to do so.
Directories
I’ll begin by opening a terminal on my workstation/host, MA8660
as user mcfatem
. Then I very carefully (note the use of the --recursive
flags!) clone the aforementioned projects to the host’s ~/GitHub
directory like so:
Host Commands |
---|
cd ~/GitHub git clone –recursive https://github.com/Digital-Grinnell/dg-isle.git git clone –recursive https://github.com/Digital-Grinnell/dg-islandora.git cd dg-isle |
Launch the dg.localdomain Stack
I’m modifying the .env
file in the dg-isle
directory so that “local” is my target environment. Having done that, I will launch the local stack using:
Host Commands |
---|
cd ~/GitHub/dg-isle git checkout master docker-compose up -d docker logs -f isle-apache-dg |
The startup will take a couple of minutes, and it does not “signal” when it’s done, so that’s the reason for the last command above. The -f
option will keep the output spooling to your terminal so that you don’t have to keep repeating the command over and over again. You will know the startup is complete when you see something like the following at the bottom of the log output:
...
Done setting proper permissions on files and directories
XDEBUG OFF
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.20.0.7. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.20.0.7. Set the 'ServerName' directive globally to suppress this message
[Mon Feb 03 22:16:46.898249 2020] [mpm_prefork:notice] [pid 12698] AH00163: Apache/2.4.41 (Ubuntu) configured -- resuming normal operations
[Mon Feb 03 22:16:46.898652 2020] [core:notice] [pid 12698] AH00094: Command line: '/usr/sbin/apache2 -D FOREGROUND
Press ctrl-c
to interrupt the docker logs...
command and get your terminal back.
A visit to https://dg.localdomain yields a very incomplete Bartik-themed site, and it looks like we are far from creating a local Digital.Grinnell. So, the next logical step is to backup the database from https://isle-stage.grinnell.edu, and import it here.
Backup the Site Database
Let’s begin by visiting the site’s home page and using the Quick Backup
block at the bottom of the right-hand sidebar. Normally I would select a Backup Destination: Manual Backups Directory
option to save the database backup on the server, but in this case it will be advantageous to have the backup in-hand, locally. So, I choose Backup Destination: Download
instead, and the result is in my local ~/Downloads
directory, specifically:
/Users/markmcfate/Downloads/DigitalGrinnell-2020-02-03T14-33-13.mysql.gz
Import the Database Backup Locally
This is as simple as:
- Opening
https://dg.localdomain
in my browser, - Logging in as a system admin,
- Open https://dg.localdomain/node#overlay=admin/module and enable the
Backup and Migrate
module, - Save the configuration change,
- Open https://dg.localdomain/node#overlay=admin/config/system/backup_migrate/restore,
Browse
to the aforementioned database backup.gz
file, and- Click
Restore now
White Screen of Death
Not good, when I visit https://dg.localdomain now I get a dreaded WSOD. So I peek at the Apache container logs using docker logs isle-apache-ld
and find this:
[Mon Feb 03 20:41:55.684244 2020] [php7:error] [pid 13002] [client 172.20.0.4:43034] PHP Fatal error: require_once(): Failed opening required '/var/www/html/sites/all/modules/islandora/islandora_multi_importer/vendor/autoload.php' (include_path='.:/usr/share/php') in /var/www/html/sites/all/modules/islandora/islandora_multi_importer/islandora_multi_importer.module on line 19, referer: https://dg.localdomain/admin/config/system/backup_migrate/restore?render=overlay
172.20.0.4 - - [03/Feb/2020:20:41:52 +0000] "GET /admin/config/system/backup_migrate/restore?render=overlay HTTP/1.1" 500 333 "https://dg.localdomain/admin/config/system/backup_migrate/restore?render=overlay" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:72.0) Gecko/20100101 Firefox/72.0
Bottom line, there are critical issues with IMI, the Islandora Multi-Importer, just as there were in staging. Hmm, what to do now?
Fixing IMI
I open a terminal into the Apache container and attempt to repair/re-install IMI like so:
Apache Container Commands |
---|
cd /var/www/html/sites/all/modules/islandora/islandora_multi-importer git remote -v git status composer install |
The commands and output from all of this are reflected in this gist.
Is It Fixed? Yes, Sort Of
A browser visit to https://dg.localdomain demonstrates that the site is back! However, the site is currently showing Operating in maintenance mode. Go online
, and there are multiple warnings indicating:
User warning: The following module is missing from the file system: islandora_binary_object.
When I click the Go online
link and complete the operation, the site does indeed respond by showing me an almost-proper home page, complete with numerous collection objects. I says it’s “almost-proper” because in addition to the top-level collections, the site is also showing a host of individual objects. This should NOT be the case, but I can think of a handful of remedies, including:
- Using the
Development
menuClear cache
link to do just what the name says.
Ok, so that actually worked; no need to go farther.
Will the Same Fixes Work on Staging?
Only one way to find out. First, I’m going to snapshot the DGDockerX
staging server. Done. Then…
Apache Container Commands |
---|
cd /var/www/html/sites/all/modules/islandora/islandora_multi-importer composer install |
And the output this time says:
root@60ccb7d0ae42:/var/www/html/sites/all/modules/islandora/islandora_multi_importer# composer install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Package phpoffice/phpexcel is abandoned, you should avoid using it. Use phpoffice/phpspreadsheet instead.
Package silex/silex is abandoned, you should avoid using it. Use symfony/flex instead.
Generating autoload file
So, to fix this I tried, and got back this:
root@60ccb7d0ae42:/var/www/html/sites/all/modules/islandora/islandora_multi_importer# composer install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Package phpoffice/phpexcel is abandoned, you should avoid using it. Use phpoffice/phpspreadsheet instead.
Package silex/silex is abandoned, you should avoid using it. Use symfony/flex instead.
Generating autoload files
root@60ccb7d0ae42:/var/www/html/sites/all/modules/islandora/islandora_multi_importer#
root@60ccb7d0ae42:/var/www/html/sites/all/modules/islandora/islandora_multi_importer#
root@60ccb7d0ae42:/var/www/html/sites/all/modules/islandora/islandora_multi_importer#
root@60ccb7d0ae42:/var/www/html/sites/all/modules/islandora/islandora_multi_importer# composer remove phpoffice/phpexcel silex/silex
Loading composer repositories with package information
The "https://repo.packagist.org/packages.json" file could not be downloaded: php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution
failed to open stream: php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution
https://repo.packagist.org could not be fully loaded, package information was loaded from the local cache and may be out of date
Updating dependencies (including require-dev)
[Composer\Downloader\TransportException]
The "http://repo.packagist.org/p/cache/taggable-cache%247eb77da84984bd6522fb9e3e91f4f82107555cba862c9f161cd3ff697dcc6f7c.json" file could not be downloaded: php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution
failed to open stream: php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution
remove [--dev] [--no-progress] [--no-update] [--no-scripts] [--update-no-dev] [--update-with-dependencies] [--no-update-with-dependencies] [--ignore-platform-reqs] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--] <packages> (<packages>)...
Next stop… a staging copy of Digital.Grinnell on DigitalOcean? Yup, headed there now. 😦 But the address will be https://staging.summittservices.com, when it’s ready.
That’s a wrap. Until next time…