Snapping Nextcloud: The memcache

In the previous post of this series, we discussed the process of and lessons learned from building MySQL for the Nextcloud snap. The last piece of infrastructure we need to introduce is the memcache, for which we’ll use Redis. Nextcloud supports a number of memcache backends; I chose Redis because it can provide both a local cache as well as file locking, so for this post that’s what we’ll focus on getting into the snap.

Since I was already building all the other components from source, I decided to do the same for Redis. I hit Lesson 4 again (DESTIR is not standard) so I wrote a dead simple local plugin for it to call make install PREFIX=<installdir>, but hardly anything worth mentioning. However, I encountered what was very nearly a deal-breaking problem:

Lesson 6: Not all projects support environment variables in their configuration files

Redis is pretty neat in that it’ll happily run using a default configuration, but I didn’t like its default configuration. I didn’t want to listen on the network, I wanted to use unix sockets. I wanted to log and dump the database into $SNAP_DATA/redis/. You get the idea. But Redis doesn’t evaluate environment variables in its config file, so it was throwing errors complaining about not being able to open the file “${SNAP_DATA}/redis/redis.log”, etc.

So I took a careful look at its help page, and noticed this little nugget:

$ ./redis-server -h
Usage: <snip>
      ./redis-server - (read config from stdin)
      <snip>

So I decided to rewrite the config file on the fly, evaluating the environment variables myself, and hand it to its stdin:

#!/bin/sh

envsubst < "$SNAP/config/redis/redis.conf" | redis-server -

All that was left was to update the Nextcloud configuration to use Redis as the backend for the memcache and file locking, and voila!

The next (and final) post in the series will discuss the Nextcloud web application itself.