diff --git a/multiple-instances.md b/multiple-instances.md index 32e1a462..f98f867a 100644 --- a/multiple-instances.md +++ b/multiple-instances.md @@ -214,7 +214,7 @@ apt install --no-install-recommends qemu-system qemu-utils libvirt-clients libvi
  • You can easily connect to a VM to perform maintenance using this command (on the host physical machine):
    virsh console --domain [VM_NAME]
  • If you chose to install an SSH Server, you can SSH in using this command (on the host physical machine):
    ssh [NONROOT_USER]@[IP_ADDRESS] # By default, OpenSSH does not allow logging in as root
  • If you mess up the configuration of a VM, you may wish to completely delete it and start fresh with a new one. THIS WILL DELETE ALL DATA ASSOCIATED WITH THE VM INCLUDING ANYTHING IN YOUR AIO DATADIR! If you are sure you would like to do this, run (on the host physical machine):
    virsh destroy --domain [VM_NAME] ; virsh undefine --nvram --domain [VM_NAME] && rm -rfi /var/lib/libvirt/images/[VM_NAME].qcow2
  • -
  • 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 like so. 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 https://[DOMAIN_NAME]/settings/admin/talk 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 here). If you have figured this out or if any of this information is incorrect, please edit this section!
  • +
  • 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 like so. 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 https://[DOMAIN_NAME]/settings/admin/talk 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 here). If you have figured this out or if any of this information is incorrect, please edit this section!
  • 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 (on the host physical machine and on the VM):
    virsh attach-device --live --domain [VM_NAME] --file [USB_DEVICE_DEFINITION.xml]
        virsh console --domain [VM_NAME]
        # (Login to the VM with root privileges)
    diff --git a/php/templates/containers.twig b/php/templates/containers.twig
    index 3fb1ddae..bb9d7356 100644
    --- a/php/templates/containers.twig
    +++ b/php/templates/containers.twig
    @@ -666,6 +666,10 @@
                         {% endif %}
                     {% endif %}
                 {% endif %}
    +            {% if is_backup_container_running == false %}
    +                

    How to reset the AIO instance?

    + If something should be going wrong, for example during the initial installation, you can reset the instance by following this documentation. Make sure to create a backup first and note down the path as well as the encryption password if this instance is already productively used so that you can restore your data on a fresh AIO instance.

    + {% endif %} {% endif %} {% if isApacheStarting == true or is_backup_container_running == true or isWatchtowerRunning == true or is_daily_backup_running == true %}