ResourceSpace v. 9.x, Synology NAS ...

[Daniel Bridgman]

Below's how I wrestled ResourceSpace v.9.2 onto a Synology NAS, got it working properly (phew!).

Installing RS onto headless (GPU-less, display-less) hosts is not for the squeamish; Synology’s NAS boxes are no exception, however, they proffer advantages, shortcuts worth leveraging.

My quest led me to a ready-made Docker image that links services as a functional, containerized, appliance.

Docker became my solution of choice because it promised what I was seeking: a robust, self-contained, staging apparatus where services start/stop, risky maneuvers are executed with minimal pain, like taking older databases and shoving them into recent RS versions (versions 9.2, 9.5, for instance).

For those who've monitored this topic (as I did since 2015), here’s where things stand (in 2021):

Required: a mid-range Synology NAS box that’s clocked less than 6 years of general service; also update to Synology’s DSM 6.2.x (Disk Station) operating system because it brings an improved Package Manager that'll spin up Docker asap. Benefits of Docker GUI on Synology include: (besides fully developed and free) “packagized" setup that's dead simple. Once a vanilla Docker's running in Synology's GUI it accelerates apprehension of what containers are capable of, avoids lengthy apprenticeships in numerous hyper-specialized technical-niche areas. But like everything, being able to massage fine points via command line's a huge plus–hence resort to docker-compose below.

Once installed Docker exposes its Registry where one can search ready-made online ResourceSpace source images. There are 4 or 5 RS images available (YMMV), but as one discovers most lack sufficient explanation of how particulars must be modified prior to spinning them into service–making them workhorse containers (that’s why command-line tricks play a subtle, yet essential role below).

I discovered creecros ResourceSpace v. 9.2 container as the most serviceable candidate, both because it includes a soupçon of documentation (environment variables, etc.), and more importantly its posting triggered followup discussion on user fora, including <https://www.synoforum.com/> where I sussed out crucial multi-container setting info that improve behavior on headless NAS's.

In 2019 one forum-poster (One-Eyed-King <https://www.synoforum.com/threads/installing-resourcespace.859/#post-3269> ) worked out adjustments to creecros's image so it plays relatively sanely on Synology–although minor glitches persisted. One-Eyed-King determined creecros's ResourceSpace image lacked volumes so mysql data persists across starts/stops. I incorporated his suggested volumes, but also had to make a series of alterations to his base script to get all containers successfully humming, pull services into functional harmony and awareness of one another. Needless to say the original bare-bones creecros was never outfitted with data persistence upper most, it went public as not quite "ready-for-primetime.” ResourceSpace without data persistence is indeed a proof-of-concept, however, it's not serviceable for most practical purposes.

I should state up front: deploying complex inter-operating containers (on any) hardware's a challenge, this is the case with Docker Synology as well. But it works phenomenally well when deployed via docker-compose (for myriad reasons) so using a yaml config's the sweet spot in my estimation.

Here’s One-Eyed-King’s docker-compose.yml, a script that spins ResourcesSpace v.9.2 into a neat multi-service container space–that is, when the script runs to completion. When this works ResourceSpace v. 9.x's ready for browser connection, setup.php's primed to initialize, which is what you want:

 

YAML

version: '2.2'

services:

  resourcespace-app:

    image: creecros/resourcespace-docker:latest

    restart: unless-stopped

    container_name: resourcespace

    ports:

      # change host port 8888 to whatever you need

      # host:container/protocol

      - 8888:80/tcp

    volumes:

      - include:/include

      - filestore:/filestore

  resourcespace-mysql:

    image: mysql:5.6

    restart: unless-stopped

    container_name: resourcespace-mysql

    environment:

      MYSQL_DATABASE: resourcespace

      MYSQL_ROOT_PASSWORD: Un1c0rn

    volumes:

      - database:/var/lib/mysql

volumes:

  filestore:

    driver: local

    driver_opts:

      type: none

      # change path in device to an existing path on your diskstation!

      device: /volume1/docker/resourcespace/filestore

      o: bind

  include:

    driver: local

    driver_opts:

      type: none

      # change path in device to an existing path on your diskstation!

      device: /volume1/docker/resourcespace/include

      o: bind

  database:

    driver: local

    driver_opts:

      type: none

      # change path in device to an existing path on your diskstation!

      device: /volume1/docker/resourcespace/database

      o: bind

The recipe above retains quirks, or at least it did in my tests on multiple Synology boxes: could not get MySQL 5.6 or 5.7 to run properly on 2 vintage (2014, 2017) Synology NAS, so ditched MySQL 5.x for MariaDB10 in One-Eye's database container  labelled "resourcespace-mysql.” To be fair MySQL 5.6 may work on other platforms, however, it broke on my test hardware. MariadDB 10, on the other hand, worked flawlessly.

Another show-stopper: when re-connecting to initialize ResourceSpace v.9.2 (via setup.php’s script) http://localhost:3306 (or even  http://127.0.0.1:3306!) the URL the script (conjectures will work, and so) supplies didn't, Because an appliance is patched together out of an array of sub-containers, the physical host's web-server knows not how to negotiate queries targeted at localhost:3306 (or combined with any port)–this is because each container reserves localhost for its own internal workings–collectively they respond only to labelled service announcements.So the (physical) box’s localhost socket’s off-limits for use in the MYSQL_URL variable. (i.e, localhost:3306 is the default setup.php supplies). 

I was unable to get past setup.php's self-test resets for ages. Eventually research revealed enough about Docker's virtual network behavior, how it can or cannot co-operate with the (physical) outer network fabric; this led to a viable env variable for MYSQL_URL, one that RS setup.php accepts. In my case: resourcespace-mysql:3306. N.B: entry to ResourceSpace's setup page is via the NAS’s FQDN or its IP address followed by port 8888. Once the form loads you’re operating inside "container world.”

This can be disorienting.

Many other refinements can augment Synology's Docker virtual container-verse: images like Portainer, Dozzle, etc. These utilities allow the operator to penetrate/diagnose missing containers, broken pipes, service errors inside Docker entities. In other words such utilities are vital for sanity-proofing Docker containerization.

Cheers,

Daniel

Smith College