Implement internal mode

[docjyJ]

It allows you not to expose AIO servers when you use reverse proxy attach in the docker aio network.

It is useful for filtered all AIO services access (with Forward Auth and Community Container).
And it prevents the proxy from bypass.

Sample compose.yaml:

services:
  nextcloud-aio-mastercontainer:
    image: nextcloud/all-in-one:latest
    init: true
    restart: always
    container_name: nextcloud-aio-mastercontainer
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - 127.0.0.1:8080:8080
    environment:
      - APACHE_IP_BINDING=@INTERNAL
      - APACHE_PORT=80
    networks:
      - nextcloud-aio

  caddy:
    image: caddy:alpine
    restart: always
    container_name: caddy
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
    ports:
      - 80:80
      - 433:433
    networks:
      - nextcloud-aio

volumes:
 nextcloud_aio_mastercontainer:
   name: nextcloud_aio_mastercontainer

networks:
  nextcloud-aio:
    name: nextcloud-aio

I do not think that services exposed on the host is a real issue, but in terms of security and isolation it is an appropriate improvement.

[szaimen]

Hi, thanks for the PR!

    environment:
      - APACHE_IP_BINDING=@INTERNAL
      - APACHE_PORT=80

I fear this is only going to work if you skip the domain validation.

Also I think this is currently going to break here:

all-in-one/Containers/mastercontainer/start.sh

Lines 182 to 186 in 3c8cb2b

	if [ -n "$APACHE_IP_BINDING" ]; then
	if ! echo "$APACHE_IP_BINDING" | grep -q '^[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+$\|^[0-9a-f:]\+$'; then
	print_red "You provided an ip-address for the apache container's ip-binding but it was not a valid ip-address.
	It is set to '$APACHE_IP_BINDING'."
	exit 1

[docjyJ]

Also I think this is currently going to break here:

all-in-one/Containers/mastercontainer/start.sh

Lines 182 to 186 in b3977ed

	if [ -n "$APACHE_IP_BINDING" ]; then
	if ! echo "$APACHE_IP_BINDING" | grep -q '^[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+$\|^[0-9a-f:]\+$\|^@INTERNAL$'; then
	print_red "You provided an ip-address for the apache container's ip-binding but it was not a valid ip-address.
	It is set to '$APACHE_IP_BINDING'."
	exit 1

Fix

[docjyJ]

According :

• all-in-one/php/templates/containers.twig

  Line 121 in 52cb90a

  If you run into issues with your domain being accepted, see <a href="https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md#6-how-to-debug-things">these steps</a> for how to debug things. <br /><br/>

• all-in-one/reverse-proxy.md

  Line 738 in 52cb90a

  1. Make sure that all ports to which your reverse proxy is pointing match the chosen `APACHE_PORT`.

If reverse proxy points correctly to http://nextcloud-aio-apache:$APACHE_PORT/ from https://exemple.com:443/, it should work.

But, Caddy Community Container is set up after validation, so it will not work. Reverse proxy must be configured before validation.

[szaimen]

If reverse proxy points correctly to http://nextcloud-aio-apache:$APACHE_PORT/ from https://exemple.com:443/, it should work.

No, it will not because it would need to point at http://nextcloud-aio-domaincheck:$APACHE_PORT/ during the domain validation. However this makes the domain validation useless because the container gets replaced after the validation by the apache container...

But, Caddy Community Container is set up after validation, so it will not work. Reverse proxy must be configured before validation.

Yes, the caddy community works differently...

[docjyJ]

What is the purpose of the domaine validations ?

[matteoipri]

Hi all,
I'll add my experience to this thread.

On my Arch Linux server, I am running several docker compose stacks and one of them is NC AiO and another one is for HAProxy to serve as reverse proxy in front of all web services, including TLS termination.
Every stack has its own docker network and then I have an additional network created outside of docker compose to connect all frontends with HAProxy.
My HAProxy stack is also connected to the NC AiO docker network.

My HAProxy config has the following lines in the HTTPS frontend

  acl host_nc hdr_beg(host) -i nc
  use_backend nextcloud if host_nc

and the following backend

backend nextcloud
  server nextcloud-aio-apache nextcloud-aio-apache:11000 check init-addr none resolvers dockerdns
  server nextcloud-aio-domaincheck nextcloud-aio-domaincheck:11000 check init-addr none resolvers dockerdns

With this setup, I got AiO installed, including the domain verification, using HAProxy as a reverse proxy running on the same host in a different container.

I would say that things work, the only issue that I still encounter is the login rate limit, which I do not know if it is legitimate (I am under brute force attack) or if it is due to my setup.

Your remote address was identified as "fd12:3456:789a:2::a" and is brute-force throttled at the moment  
slowing down the performance of various requests. If the remote address is not your address this can be  
an indication that a proxy is not configured correctly. For more details see the documentation ↗.

Can my setup inspire a solution for this topic?
How can I fix the login throttling?

Thanks,
Matteo

[docjyJ]

Can my setup inspire a solution for this topic?
How can I fix the login throttling?

I dont know how resolve this issue.

Disable https://apps.nextcloud.com/apps/bruteforcesettings fix the warning message.

I don't know if you've read it yet, but it might help:
https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html

Static IP for docker containers : https://www.baeldung.com/ops/docker-assign-static-ip-container

[docjyJ]

Sample (Not tested):

services:
  nextcloud-aio-mastercontainer:
    image: nextcloud/all-in-one:latest
    init: true
    restart: always
    container_name: nextcloud-aio-mastercontainer
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - 127.0.0.1:8080:8080
    environment:
      - APACHE_IP_BINDING=@INTERNAL
      - APACHE_PORT=80
    networks:
      - nextcloud-aio

  caddy:
    image: caddy:alpine
    restart: always
    container_name: my-caddy
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
    ports:
      - 80:80
      - 433:433
    networks:
      nextcloud-aio:
        ipv4_address: 10.9.8.7

volumes:
 nextcloud_aio_mastercontainer:
   name: nextcloud_aio_mastercontainer

networks:
  nextcloud-aio:
    name: nextcloud-aio
    driver: bridge
    ipam:
      config:
        - subnet: 10.9.8.0/24
          gateway: 10.9.8.1

https://mycloud.com:443 {
  reverse_proxy {
    to http://nextcloud-aio-apache:80 http://nextcloud-aio-domaincheck:80
    lb_policy first
    health_uri /
    health_port 80
    health_interval 60s
  }
}

$CONFIG = array (
  'trusted_proxies'   => ['10.9.8.7'],
  'overwritehost'     => 'my-caddy',
  'overwriteprotocol' => 'http'
);

[ManOki]

@matteoipri I have a similar setup (swag instead of HAProxy) including an additional network just for frontends.

client -1-> swag -2-> caddy -3-> nextcloud

1 LAN/WAN
2 swag-network
3 nextcloud-aio-network

While caddy is automatically marked as a trusted proxy, this ain't the case for your HAProxy.
https://github.com/nextcloud/all-in-one/blob/main/Containers/nextcloud/entrypoint.sh#L563C73-L563C97
You have to setup ADDITIONAL_TRUSTED_PROXY environment variable for your nextcloud-aio-nextcloud container.

[szaimen]

So my problem with this in general is that the reverse proxy documentation is already very complicated because it offers many options. Adding yet another method will not make it easier to understand...

We can add this but lets not document this for now.

[szaimen]

LGTM. Thanks a lot @docjyJ!

[szaimen]

This is now released with v9.2.0 Beta. Testing and feedback is welcome! See https://github.com/nextcloud/all-in-one#how-to-switch-the-channel

[docjyJ]

This is now released with v9.2.0 Beta. Testing and feedback is welcome! See https://github.com/nextcloud/all-in-one#how-to-switch-the-channel

Work without domain validation