Just a quick cheatsheet-ish post as I figure out how to move my home server off nginx and onto caddy-docker-proxy, which I hope will make configuration easier in the long run. Figuring out what labels to attach to get Caddy to do what I want is a minor stumbling block.

In this case, it’s working with the Collabora server that my Nextcloud instance uses to enable online editing of office-type files. The sticking point is that the server complains if Nextcloud connects over plain HTTP, but Caddy (though which Nextcloud will connect) complained about the Collabora server’s self-signed SSL certificate.

This docker-compose.yml is what I ended up using:

services:
  collabora:
    image: collabora/code
    container_name: collabora
    restart: unless-stopped
    environment:
      extra_params: --o:ssl.enable=true
    networks:
      - www
    labels:
      caddy: collabora.alfter.us
      caddy.reverse_proxy: https://collabora.www:9980
      caddy.reverse_proxy.transport: http 
      caddy.reverse_proxy.transport.tls_insecure_skip_verify:
      
networks:
  www:
    name: www
    external: true

The “www” network connects Nginx and Caddy (eventually just Caddy) to all of the containers to be proxied. The first two labels are pretty normal, but the last two are what tell Caddy to ignore Collabora’s self-signed certificate. The part of the Caddyfile that handles collabora.alfter.us ends up looking something like this:

collabora.alfter.us {
  reverse_proxy https://collabora.www {
    transport http {
      tls_insecure_skip_verify
    }
  }
}

Nothing like changing the default behavior of a program in a point release so that users then wonder why it’s not behaving as it should:

ownCloud 8.2 Release Notes

Changes in 8.2

filesystem_check_changes in config.php is set to 0 by default. This prevents unnecessary update checks and improves performance. If you are using external storage mounts such as NFS on a remote storage server, set this to 1 so that ownCloud will detect remote file changes.

Nearly all of the files on my ownCloud server are accessed from Samba shares on the same server; ownCloud is basically how I access my files away from home.  If it’s not monitoring filesystem changes, it will rapidly fall behind on which files have been created and deleted.

Until v8.1, it monitored filesystem changes in the default configuration.  I upgraded to v8.2 over the weekend, which no longer does that unless you add an option to the config file to reenable it.  Grr.

I’ve had most of my stuff either backed up to Tarsnap or archived to BD-R for a while now, with two exceptions: the contacts and calendars I have stored in ownCloud.  It’s not much information sizewise, but losing everyone’s phone numbers would be a royal pain in the ass.

Backing up contacts is relatively simple; ownCloud provides a URL that grabs them in one shot. Calendars are a bit more problematic, as you probably have more than one. HTTrack is used to grab all of the calendars, which are then concatenated and compressed (except for the contact birthdays calendar, which is auto-generated from your contacts). In my case, the backup is stored in a directory that gets sent to Tarsnap by another script; you could do whatever you want with your backup files.

Set this up as a cronjob; set it to run maybe a half-hour before your backup job. (12345 isn’t really my ownCloud password; I only use that on my luggage. :-) )

#!/bin/bash

source /etc/profile
cd $HOME

# script settings: ownCloud server address, username, password, 
# backup destination

OWNCLOUD=https://home.alfter.us/owncloud
USERNAME=salfter
PASSWORD=12345
DEST=/mnt/files/documents

PREFIX=`echo $OWNCLOUD | sed "s/\/\//\/\/$USERNAME:$PASSWORD@/"`

# retrieve all contacts from ownCloud and concatenate them into one
# compressed file, which then gets sent to Tarsnap with the rest of
# our documents

rm /mnt/files/documents/contacts.vcf* 
wget $PREFIX/remote.php/carddav/addressbooks/$USERNAME/contacts\?export -O "$DEST"/contacts.vcf && \
xz -z9 "$DEST"/contacts.vcf

# do the same with calendars...use httrack instead of wget as there's no
# way AFAICT to enumerate calendars so we can export them

httrack $PREFIX/remote.php/caldav/calendars/$USERNAME -O calendars && \
for i in `find calendars -mindepth 7 -type d | grep -v contact_birthdays`
do
  cat `find $i -name \*.ics` | xz -9 >"$DEST"/calendar-`basename $i`.ics.xz
done
rm -r calendars

I just got done getting my settings restored to my router after letting it try to update to the latest version. Version 3.0.0.4.378.4585 killed the web interface, making it unconfigurable.  Restoring the previous version from a TFTP client running on Linux wouldn’t work to set it right, either.  Good thing I had recently added Windows 7 to the empty space on my main computer’s SSD, as a Windows-based unfsck-my-router utility provided by Asus (only downloaded after I had swapped in my trusty old WRT54GL temporarily) was the only thing that would get the router running right again.

I even tried using the aforementioned unfsck-my-router utility to try installing the newer firmware, instead of letting the router update itself again.  That didn’t work either.  The only conclusion I can come to is that something is pretty badly broken in this latest release.  It won’t damage your router (it’s harder to brick than most devices), but rolling it back to working firmware is a bit of a hassle.  I’d recommend skipping this update and hold off for the next release.