Nextcloud AIO, talk, notify-push, reverse proxy (not on the same host),

[apleschu]

So, I have been successful in getting a AIO instance, with office and talk and almost everything up and running. Our instance is behind a Nginx reverse proxy which runs on a different VM, behind a firewall.

There are still a few nagging problems before I can let my users start using it.

1. in Safari on MAC the setting regarding the audio and video devices do not seem to stick. Every time I log back in they are gone again.
2. I cannot seem to get notify-push to work. it starts, reports healthy but no notifications are forthcoming.
3. I’m unable to get the real IP addresses of my clients to next cloud. NGINX is configured to set X-forwarded-for (and does so) but apparently the built in apache does away with that and without digging deep into the containers I have not found or seen a solution to make apache hand the x-forwarded-for header through
4. every time the system restarts it comes up apparently in the wrong order. Then I have to ‘docker stop nextcloud-aio-apache; docker stop nextcloud-aio-nextcloud’ and restart the containers with ‘docker start nextcloud-aio-apache; sleep 60; docker start nextcloud-aio-nextcloud’ They “just” seem to start in the wrong order.

Does anybody have solutions for those problems? (4) is the least of a problem because I am not restarting often enough, that’s just a nuisance for now, although it could be a problem in the future, but the issue with the notify push is a show stopper, because if my users are not informed that calls are coming in or that chat messages are coming in the whole talk server is more or less worthless.

[apleschu]

Short answer to myself, and maybe this is going to help some other dude/dudette looking for the same/similar problem.

As it seems the X-Forwarded-For Header is being used by both, the Nginx instance at the ingress point into our local network as well as from the apache instance inside AIO. → No bueno, that way you don’t get the real IP.

What does help though is the combination of

'forwarded_for_headers' => array('HTTP_X_FORWARDED_HOST',),

in the config file, for AIO. Which in our system (Debian Linux) can be found in the host filesystem in

/var/lib/docker/volumes/nextcloud_aio_nextcloud/_data/config/config.php

and Nginx needs to be configured:

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

server {

        server_name nextcloud.<your TLD here> ;

        location / {
                proxy_set_header  Host $host;
                proxy_set_header  X-Real-IP $remote_addr;
                proxy_set_header  X-Forwarded-Proto https;
                proxy_set_header  X-Forwarded-Host $remote_addr;
                proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_pass http://172.31.1.247:11000$request_uri;
                proxy_request_buffering off;
                client_max_body_size 0;

                # Websocket
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
        }

        location /.well-known/carddav {
                return 301 $scheme://$host/remote.php/dav;
        }

        location /.well-known/caldav {
                return 301 $scheme://$host/remote.php/dav;
        }

        location ^~ /push/ {
                proxy_pass http://172.31.1.247:7867/;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "Upgrade";
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                }

    listen [::]:443 ssl; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/wildcard-cert/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/wildcard-cert/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    ssl_session_cache shared:MozSSL:10m; # about 40000 sessions

}


server {
    if ($host = nextcloud.ple.org) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80;
        listen [::]:80;

        server_name nextcloud.ple.org ;
    return 404; # managed by Certbot

That still leaves the notify-push and the devices that don’t stick before I can roll that installation out. I really hope there is some knowledge here.