Mounting //STORAGE for IMI Ingest in Digital.Grinnell
2 min read
•
Jul 22, 2019
• Updated: Nov 12, 2020 08:30
• Mark A. McFate
Claiming another small victory today! Why? Well, the Digital.Grinnell instance of IMI (Islandora Multi-Importer) module is customized so that choosing “*local” as an object ingest source invokes a hook function I created in our DG7 module. That hook enables IMI to “find” named files/content (things like PDFs, images, etc.) in the Grinnell College //STORAGE
server. //STORAGE
can be mounted as a CIFS (Common Internet File System) and used to drive ingest if the right package/drivers are made available to Islandora. That can be a little tricky in ISLE, but it’s manageable.
My process for providing CIFS access to //STORAGE
and for mounting the objects went like this:
- Some time ago my colleagues and I created a directory on the server named
//STORAGE/MEDIADB/DGIngest
. It is password protected, as is all of//STORAGE
, and URL-accessible. - The aforementioned IMI ‘hook’ in
DG7
is programmed to find content in a “local” directory named/mnt/storage
. The code is such that it can find a named file within ANY path subordinate to this directory. So… - Today I opened a terminal to my ISLE production host,
DGDocker1.Grinnell.edu
, and subsequently opened a terminal into its Apache container like so:docker exec -it isle-apache-dg bash
. - Inside the Aapache container terminal I executed the following, as “root”, to install a
CIFS
package:apt-get update; apt install -y cifs-utils
. This was a success and need not be repeated unless I ever have to recreate the Apache container. - Still in the Apache container terminal I mounted the target share using:
mount -t cifs -o username=mcfatem //storage.grinnell.edu/MEDIADB/DGIngest /mnt/storage
. I was subsequently prompted for my password and provided it. - Eureka! It worked. My subsequent IMI ingests were able to successfully find content stored in the aforementioned directory and its subordinates.
And that’s a wrap. Until next time…