Collabora + Caddy reverse proxy (in Docker)

Hello all,

I’m trying to set up Nextcloud and Collabora, with Caddy providing secure connections. All 3 are running in separate docker containers and can see each other, Caddy has port 80 and 443 exposed to the outside world and sends connections from two subdomains to either Nextcloud or Collabora.

What is working: Caddy is proxying connections from subdomains to the right services and Nextcloud is working like a charm.

The problem: CODE is returning 502s for every request. Caddy reports for example 04/Dec/2016:12:16:33 +0000 [ERROR 502 /hosting/discovery] EOF.


Specific versions used:

  • (on the host: Arch Linux 4.8.11, Docker 1.12.3, Docker-compose 1.9.0)
  • Nextcloud 10.0
  • Collabora Online connector 1.1.15
  • Collabora CODE 2.0
  • Caddy 0.9.3

(Hopefully all the) relevant parts of docker-compose.yml:

caddy:
  image: abiosoft/caddy
  restart: always
  environment:
    CADDYPATH: "/etc/caddycerts"
  volumes:
    - ./Caddyfile:/etc/Caddyfile
    - caddy-certs:/etc/caddycerts
    - caddy-web:/srv
  ports:
    - "80:80"
    - "443:443"

nextcloud:
  image: wonderfall/nextcloud
  restart: always
  depends_on:
    - nextcloud-db
  environment:
    - UID=1000
    - GID=1000
    - UPLOAD_MAX_SIZE=10G
    - APC_SHM_SIZE=128M
    - OPCACHE_MEM_SIZE=128
    - REDIS_MAX_MEMORY=64mb
    - CRON_PERIOD=15m
    - TZ=Europe/Amsterdam
    - ADMIN_USER=<somenameB>
    - ADMIN_PASSWORD=<somepasswordB>
    - DB_TYPE=mysql
    - DB_NAME=<somedbA>
    - DB_USER=<somenameA>
    - DB_PASSWORD=<somepasswordA>
    - DB_HOST=nextcloud-db
  depends_on:
    - nextcloud-db
  volumes:
    - nextcloud-data:/data
    - nextcloud-config:/config
    - nextcloud-apps:/apps2

collabora:
  image: collabora/code
  restart: always
  depends_on:
    - nextcloud
  environment:
    domain: "nextcloud\\.<somedomainA>"
  cap_add:
    - MKNOD
  expose:
    - "9980"

nextcloud-db:
  image: mariadb
  restart: always
  volumes:
    - nextcloud-db-data:/var/lib/mysql
  environment:
    - MYSQL_ROOT_PASSWORD=<somepasswordC>
    - MYSQL_DATABASE=<somedbA>
    - MYSQL_USER=<somenameA>
    - MYSQL_PASSWORD=<somepasswordA>

Relevant parts of the Caddyfile:

nextcloud.<somedomainA> {
  proxy / http://nextcloud:8888 {
    transparent
  }
}

collabora.<somedomainA> {
  errors stdout #for debug purposes
  log stdout    #for debug purposes

  proxy / collabora:9980 {
    transparent
    websocket
  }
}

And finally the setting in the plugin:
Server: https://collabora.<somedomainA>

Note that the domains are internet-facing, so Caddy builds certificates with Let’s Encrypt.


One thing I found while making this thread and haven’t tried yet, is specifying the VIRTUAL_HOST and friends for the collabora environment. This didn’t help.
Do CODE and Nextcloud have to communicate internally? If so, how does one specify the address they should use (assuming the services can’t communicate with each other using the domain names)?

1 Like

Did you figure it out? I’m having the exact same issue

I’d love to know too as this is the setup I’m using.

Good news everyone!

It’s working with a new setup. The relevant changes are: switching the collabora proxy to https and ignoring that certificate’s validity.
Since other changes may have side effects that make it work (e.g. using the FPM container for nextcloud), I’ll list the whole setup below. Replace everything between < angle brackets > and all full domain names with your own of course.


docker-compose.yml:

version: '3'

volumes:
  caddy-web:
  caddy-certs:
  nextcloud-db-data:
  nextcloud-data:
  collabora-loolwsd:

services:
  caddy:
    image: abiosoft/caddy
    links:
      - nextcloud
      - collabora
    environment:
      CADDYPATH: "/etc/caddycerts"
    volumes:
      - ./Caddyfile:/etc/Caddyfile
      - caddy-certs:/etc/caddycerts
      - nextcloud-data:<nextcloud root>:ro
      - caddy-web:<other sites>:ro
    ports:
      - "80:80"
      - "443:443"

  nextcloud-db:
    image: postgres
    volumes:
      - nextcloud-db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=nextcloud
      - POSTGRES_PASSWORD=<nextcloud db password>

  nextcloud:
    image: nextcloud:fpm
    links:
      - nextcloud-db
    volumes:
      - nextcloud-data:/var/www/html

  collabora:
    image: collabora/code
    depends_on:
      - nextcloud
    environment:
      domain: "my\\.nextcloud\\.domain"
      cert_domain: "collabora"
    cap_add:
      - MKNOD
    volumes:
      - collabora-loolwsd:/etc/loolwsd

Caddyfile (FPM directives based on this example, collabora directives based on the official guide and ignoring its certificate):

my.other.domain {
  root <other sites>
}

my.nextcloud.domain {
  root <nextcloud root>

### begin nextcloud fpm settings ###
  fastcgi / nextcloud:9000 php {
    root /var/www/html
  }

  rewrite {
    r ^/index.php/.*$
    to /index.php?{query}
  }

# client support (e.g. os x calendar / contacts)
  redir /.well-known/carddav /remote.php/carddav 301
  redir /.well-known/caldav /remote.php/caldav 301

# remove trailing / as it causes errors with php-fpm
  rewrite {
    r ^/remote.php/(webdav|caldav|carddav|dav)(\/?)$
    to /remote.php/{1}
  }

  rewrite {
    r ^/remote.php/(webdav|caldav|carddav|dav)/(.+?)(\/?)$
    to /remote.php/{1}/{2}
  }

# .htaccess / data / config / ... shouldn't be accessible from outside
  status 403 {
    /.htacces
    /data
    /config
    /db_structure
    /.xml
    /README
  }
### end nextcloud fpm settings ###
}

my.collabora.domain {
### begin collabora proxy settings ###
  proxy /loleaflet https://collabora:9980 {
    insecure_skip_verify
    transparent
  }

  proxy /hosting/discovery https://collabora:9980 {
    insecure_skip_verify
    transparent
  }

  proxy /lool https://collabora:9980 {
    insecure_skip_verify
    transparent
    websocket
  }
### end collabora proxy settings ###
}

And finally the setting in the Collabora Online plugin:
Server: https://my.collabora.domain

[edit] Trusting the collabora certificate in nextcloud was not necessary after all. It was just a remnant from earlier tests. Good, because it presented a potential security hole: if you’re doing federated cloud stuff or have plugins that do requests to the outside, a MITM can generate a self-signed certificate just like the collabora VM and use it for an attack.

2 Likes

Does this configuration still work for you? Especially in Firefox?
With the current Caddy, Nextcloud and Collabora with the same Collabora section in my Caddyfile, Firefox loads the ui of the editor, but no document shows up. It has trouble connecting to the main socket.

Edit: I figured out, that the cache directive I added currently has some issues with websockets. Removing it makes it Firefox-compatible.