Repo-sync

Containers/apache/Caddyfile

@@ -51,9 +51,6 @@ https://{$ADDITIONAL_TRUSTED_DOMAIN}:443,
         reverse_proxy {$TALK_HOST}:8081
     }
 
-    # Others
-    import /mnt/data/caddy-imports/*
-
     # Nextcloud
     route {
         rewrite /.well-known/carddav /remote.php/dav/

Containers/apache/start.sh

@@ -63,15 +63,6 @@ caddy fmt --overwrite /tmp/Caddyfile
 # Add caddy path
 mkdir -p /mnt/data/caddy/
 
-# Add caddy import path
-mkdir -p /mnt/data/caddy-imports
-
-# Remove falsely added Nextcloud conf
-rm -f /mnt/data/caddy-imports/nextcloud
-
-# Make sure that the caddy-imports dir is not empty
-echo "# empty file so that caddy does not print a warning" > /mnt/data/caddy-imports/empty
-
 # Fix apache startup
 rm -f /usr/local/apache2/logs/httpd.pid
 

Containers/nextcloud/Dockerfile

@@ -7,7 +7,7 @@ ENV PHP_MAX_TIME 3600
 ENV SOURCE_LOCATION /usr/src/nextcloud
 
 # AIO settings start # Do not remove or change this line!
-ENV NEXTCLOUD_VERSION 28.0.5
+ENV NEXTCLOUD_VERSION 28.0.6
 ENV AIO_TOKEN 123456
 ENV AIO_URL localhost
 # AIO settings end # Do not remove or change this line!

Containers/talk/Dockerfile

@@ -1,7 +1,7 @@
 # syntax=docker/dockerfile:latest
 FROM nats:2.10.16-scratch as nats
 FROM eturnal/eturnal:1.12.0 AS eturnal
-FROM strukturag/nextcloud-spreed-signaling:1.3.0 as signaling
+FROM strukturag/nextcloud-spreed-signaling:1.3.1 as signaling
 FROM alpine:3.19.1 as janus
 
 ARG JANUS_VERSION=v0.14.2

Containers/talk/server.conf.in

@@ -35,7 +35,8 @@ debug = false
 #allowsubscribeany = false
 
 # Comma separated list of trusted proxies (IPs or CIDR networks) that may set
-# the "X-Real-Ip" or "X-Forwarded-For" headers.
+# the "X-Real-Ip" or "X-Forwarded-For" headers. If both are provided, the
+# "X-Real-Ip" header will take precedence (if valid).
 # Leave empty to allow loopback and local addresses.
 #trustedproxies =
 

multiple-instances.md

@@ -214,7 +214,7 @@ apt install --no-install-recommends qemu-system qemu-utils libvirt-clients libvi
             <li>You can easily connect to a VM to perform maintenance using this command (<strong>on the host physical machine</strong>): <pre><code>virsh console --domain [VM_NAME]</code></pre></li>
             <li>If you chose to install an SSH Server, you can SSH in using this command (<strong>on the host physical machine</strong>): <pre><code>ssh [NONROOT_USER]@[IP_ADDRESS] # By default, OpenSSH does not allow logging in as root</code></pre></li>
             <li>If you mess up the configuration of a VM, you may wish to completely delete it and start fresh with a new one. <strong>THIS WILL DELETE ALL DATA ASSOCIATED WITH THE VM INCLUDING ANYTHING IN YOUR AIO DATADIR!</strong> If you are sure you would like to do this, run (<strong>on the host physical machine</strong>): <pre><code>virsh destroy --domain [VM_NAME] ; virsh undefine --nvram --domain [VM_NAME] && rm -rfi /var/lib/libvirt/images/[VM_NAME].qcow2</code></pre></li>
-            <li>Using Nextcloud Talk will require some extra configuration. Back when you set up your VMs, they were (by default) configured with NAT, meaning they are in their own subnet. The VMs must each instead be bridged, so that your router may directly "see" them (as if they were real, physical devices on your network), and each AIO instance inside each VM must be configured with a different Talk port (like 3478, 3479, etc.). You should have already set these port numbers (back when you first configured the VM in step 4 above), but if you still need to set (or want to change) these values, you can remove the mastercontainer and re-run the initial "docker run" command with a modified Talk port <a href="https://github.com/nextcloud/all-in-one?tab=readme-ov-file#how-to-adjust-the-talk-port">like so</a>. Then, the Talk port for EACH instance needs to be forwarded in your router's settings DIRECTLY to the VM hosting the instance (completely bypassing your host physical machine/reverse proxy). And finally, inside an admin-privileged account (such as the default "admin" account) in each instance, you must visit <strong>https://[DOMAIN_NAME]/settings/admin/talk</strong> then find the STUN/TURN Settings, and from there set the proper values. If this is too complicated, it may be easier to use public STUN/TURN servers, but I have not tested any of this, rather I'm just sharing what I have found so far (more info available <a href="https://github.com/nextcloud/all-in-one/discussions/2517">here</a>). If you have figured this out or if any of this information is incorrect, please edit this section!</li>
+            <li>Using Nextcloud Talk will require some extra configuration. Back when you set up your VMs, they were (by default) configured with NAT, meaning they are in their own subnet. The VMs must each instead be bridged, so that your router may directly "see" them (as if they were real, physical devices on your network), and each AIO instance inside each VM must be configured with a different Talk port (like 3478, 3479, etc.). You should have already set these port numbers (back when you first configured the VM in step 4 above), but if you still need to set (or want to change) these values, you can remove the mastercontainer and re-run the initial "docker run" command with a modified Talk port <a href="https://github.com/nextcloud/all-in-one#how-to-adjust-the-talk-port">like so</a>. Then, the Talk port for EACH instance needs to be forwarded in your router's settings DIRECTLY to the VM hosting the instance (completely bypassing your host physical machine/reverse proxy). And finally, inside an admin-privileged account (such as the default "admin" account) in each instance, you must visit <strong>https://[DOMAIN_NAME]/settings/admin/talk</strong> then find the STUN/TURN Settings, and from there set the proper values. If this is too complicated, it may be easier to use public STUN/TURN servers, but I have not tested any of this, rather I'm just sharing what I have found so far (more info available <a href="https://github.com/nextcloud/all-in-one/discussions/2517">here</a>). If you have figured this out or if any of this information is incorrect, please edit this section!</li>
             <li>Configuring daily automatic backups is a bit more involved with this setup. But for the occasional manual borg backup, you can connect a physical SSD/HDD via a cheap USB SATA adapter/dock to a free USB port on your host physical machine, and then use these commands to pass the disk through to a VM of your choosing (<strong>on the host physical machine and on the VM</strong>): <pre><code>virsh attach-device --live --domain [VM_NAME] --file [USB_DEVICE_DEFINITION.xml]
    virsh console --domain [VM_NAME]
    # (Login to the VM with root privileges)