1. Caddy version (caddy version
):
# caddy version
v2.4.3 h1:Y1FaV2N4WO3rBqxSYA8UZsZTQdN+PwcoOcAiZTM8C0I=
2. How I run Caddy:
a. System environment:
Fedora CoreOS, systemd, podman
b. Command:
podman-compose up
c. Service/unit/compose file:
version: '3.7'
services:
caddy:
image: caddy
restart: unless-stopped
ports:
- "****:80"
volumes:
- ${PWD}/Caddyfile:/etc/caddy/Caddyfile:ro,Z
- caddy_data:/data
- caddy_config:/config
- nc_data:/var/www/html
networks:
- caddynet
depends_on:
- nc
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost/status.php"]
interval: 1m30s
timeout: 10s
retries: 3
start_period: 40s
labels:
- io.containers.autoupdate=registry
nc:
image: nextcloud:22-fpm
restart: unless-stopped
volumes: &nextcloud_volumes
- nc_data:/var/www/html
# […]
networks:
- caddynet
# […]
expose:
- 9000
# […]
# [… more nextcloud stuff …]
volumes:
# […]
nc_data:
caddy_data:
caddy_config:
networks:
caddynet:
# […]
d. My complete Caddyfile or JSON config:
http://:80 {
root * /var/www/html
file_server
php_fastcgi nc:9000 {
env front_controller_active true # Remove index.php form url
}
header {
# enable HSTS
# Strict-Transport-Security max-age=31536000;
}
redir /.well-known/carddav /remote.php/dav permanent
redir /.well-known/caldav /remote.php/dav permanent
# .htaccess / data / config / ... shouldn't be accessible from outside
@forbidden {
path /.htaccess
path /data/*
path /config/*
path /db_structure
path /.xml
path /README
path /3rdparty/*
path /lib/*
path /templates/*
path /occ
path /console.php
}
respond @forbidden 404
}
(It’s reverse-proxied, so the HTTP/80 is okay.)
3. The problem I’m having:
As explained here both the old Caddy example file and many nginx configuration examples/suggestions such as the official nginx Nextcloud doc.
So how can these rewrites all be ported to the new Caddy syntax?
Important note: Note I’d like to avoid introducing security vulnerabilities by trying to fiddle something in there, whichcan then have bad side effects. The reason is Nextcloud itself had a vulnerability report suggesting to adjust the nginx configuration (CVE-2019-11043), which was some remote code execution vulnerability. It was an issue in php-fpm ultimately, but the workaround/mitigation suggested by Nextcloud were nginx config adjustments.
Just that to explain some background of why I’m a little “wary” here…
4. Error messages and/or full log output:
N/A
5. What I already tried:
see above
6. Links to relevant resources:
already linked