Nextcloud zusammen mit EGroupware auf der gleichen VM

[lendl]

Hallo zusammen,

ist es möglich zusammen mit einer EGroupware Installation (Docker) auch noch eine Nextcloud (Docker) laufen zu lassen und wie verhält es sich dann mit dem Let’s Encrypt Zertifikat

Hintergrund:
Ich habe eine VM auf einem Linuxrechner mit KVM am laufen und darauf die EGroupware (Docker Container). Das Zertifikat ist von Let’s Encrypt. Das Ganze ist die Standardinstallation aus der Anleitung hier. Allerdings nutze ich die EGroupware nur privat und hinter einer Fritzbox mit einer dynamischen IP-Adresse und einem DynDNS Dienst (Selfhost). Das funktioniert soweit super.

Jetzt würde ich aber gerne noch eine Nextcloud installieren und am besten ebenfalls mit einem Let’s Encrypt Zertifikat. Eine zweite VM für die Nextcloud funktioniert dann aber meines Wissens nicht, weil ja für Let’s Encrypt der Port 80 offen sein muss und der ist ja schon für die EGroupware VM weitergeleitet. Daher die Überlegung die Nextcloud über Docker einfach auf der EGroupware VM laufen zu lassen. Dann müsste es ja auch keine Probleme mit dem Zertifikat geben, weil der Certbot ja schon auf der EGroupware VM läuft, oder?

Hat jemand von Euch da Erfahrungen und kann mir da weiterhelfen? Ich hoffe ich habe es einigermaßen verständlich erklärt.

Vielen Dank vorab für Eure Unterstützung!

Michael

[StefanU]

Hi lendl.

Das sollte eigentlich machbar sein.
Wir steuern ja Docker per docker-compose. Dara anlehnend könntest du den NC erst einmal zum laufene bekommen.
Wir binden mitgelieferte Konfigurationen für den Reverse-Proxy ein. Du müsstest hat eine für den Reverse-Proxy anlegen.
All das ist vorhanden und du brauchst dich “nur” daran orientieren. Ist eigentlich alles Standard.

SSL wird dann weiterhin auf dem Reverse-Proxy geregelt. Wie bestehend.

---

Aber:
Warum willst du NC neben EGw betreiben?

Stefan

[Yann_Lehmann]

Das sollte eigentlich machbar sein.
Wir steuern ja Docker per docker-compose. Dara anlehnend könntest du den NC erst einmal zum laufene bekommen.
Wir binden mitgelieferte Konfigurationen für den Reverse-Proxy ein. Du müsstest hat eine für den Reverse-Proxy anlegen.
All das ist vorhanden und du brauchst dich “nur” daran orientieren. Ist eigentlich alles Standard.

SSL wird dann weiterhin auf dem Reverse-Proxy geregelt. Wie bestehend.

Wir haben nebst EGroupware eine zweite Web-Anwendung auf der gleichen VM (auch in einem Docker Container), und die “teilen sich” das Let’s encrypt Zertifikat. Letzteres kann man mit weiteren Domains erweitern.

Und wie Stefan schrieb wird SSL auf dem Reverse-Proxy geregelt. Für die Conf-Datei der zweiten App habe ich mich an diejenigen von EGroupware orientiert.

[lendl]

Vielen Dank für die schnelle Antwort!
Das hört sich ja schon mal ganz gut an.
Dann werde ich mein Glück mal versuchen.

Um die Frage nach dem “Warum” zu beantworten:
Ich nutze aktuell eine gehostete Nextcloud die ich ablösen möchte um sie auf meinem eigenen Rechner zu betreiben.
Ich teile damit gelegentlich Bilder, aber das könnte die EGroupware natürlich auch.
Hauptgrund für mich ist aber die Deck-App, also das Kanban-Board von Nextcloud. Ich organisieren mich seit 2 Jahren komplett damit und das funktioniert für mich super gut. Ich habe lange gebraucht irgendwas zu finden das für mich passt und mit dem ich auch meine vielen ToDo-Listen und sonstige Zettel ordentlich organisieren kann. Ich würde ungern nochmal auf die Suche gehen…

Aber anscheinend funktioniert das ja auch selbst gehostet und dann werde ich das einfach mal testen.

Nochmal tausend Dank an Euch für die Unterstützung!

Viele Grüße!
Michael

[StefanU]

Kanban nutze ich auch.

https://www.youtube.com/watch?v=q1a18a6-ZS0

Stefan

[lendl]

Hallo zusammen.

leider ist es mit der Config von EGroupware und Nextcloud auf einer VM doch nicht so einfach, bzw. übersteigt es meine Kompetenzen

Ich habe die Nextcloud mit folgender Compose Datei ans Laufen bekommen:

version: '3'
 
volumes:
 data:
 config:
 db:
 
services:
 nextcloud-db:
  image: mariadb
  container_name: nextcloud-db
  restart: always
  volumes:
   - ./db:/var/lib/mysql
  environment:
   - MYSQL_ROOT_PASSWORD=passwort
   - MYSQL_PASSWORD=passwort
   - MYSQL_DATABASE=nextcloud
   - MYSQL_USER=nextcloud
 nextcloud:
  image: nextcloud
  container_name: nextcloud
  restart: always
  ports:
   - 8081:80
  depends_on:
   - nextcloud-db
  volumes:
   - ./config:/var/www/html/config
   - /nextcloud-data:/var/www/html/data
   - ./apps:/var/www/html/apps
   - ./custom_apps:/var/www/html/custom_apps

und sie ist unter der IP der VM und Port 8081 erreichbar: http://192.168.1.201:8081/index.php/apps/dashboard/

So weit so gut.

Jetzt dachte ich, ich kann sie, ebenso wie meine EGroupware unter meiner DNS erreichen, z.B. https://meinDNSname.selfhost.bz/nextcloud

Dazu habe ich, naiv wie ich bin, in der /etc/egroupware-docker/nginx.conf
einfach folgenden Eintrag ergänzt:

    }

    location /nextcloud {
            proxy_pass http://127.0.0.1:8081;
            include proxy_params;
            # to allow longer running requests like eg. backup or restore
            proxy_read_timeout    60m;
            # required for push / websocket
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "Upgrade";
    }

Aber das geht schon mal nicht.

Außerdem gibt es ja auch noch eine /etc/egroupware-docker/apache.conf
von der ich nicht weiss was sie macht, aber bei der ich dann folgenden Eintrag gesetzt habe:

ProxyPass /nextcloud/ http://127.0.0.1:8081/ timeout=4000 connectiontimeout=600 acquire=3000 retry=6
ProxyPassReverse /nextcloud/ http://127.0.0.1:8081/

Auch hier Fehlanzeige.

Ich habe also festgestellt, dass ich erstens keine Ahnung habe und zweitens ein Verständnisproblem wie die Anfrage von https://meinDNSname.selfhost.bz/egroupware
über die VM überhaupt weitergeroutet wird.

Vielleicht kann mir ja jemand von Euch sagen wo ich falsch liege oder ob ich lieber gleich die Finger davon lassen soll

Tausend Dank vorab!
Michael

[RalfBecker]

Hallo Michael,

die erste Frage ist: verwendest Du auf dem Host einen Nginx (default bei EGroupware), oder einen Apache?

Das Ändern der nginx.conf Datei alleine reicht nicht, Du musst den Nginx neu starten:

nginx -s reload`

Die Konfig sieht soweit gut aus.

Frage ist natürlich auch, was brauchst Du von der Nextcloud, das die EGroupware nicht auch schon mitbringt …

Ralf

[lendl]

Hallo Ralf,

Danke für die Info!
Ich habe die EGroupware im Standard mit Docker installiert:

nextcloud
collabora/code
egroupware/egroupware
phpswoole/swoole
mariadb
nginx
mariadb
quay.io/egroupware/collabora-key
containrrr/watchtower
phpswoole/swoole

Ich habe den nginx neu gestartet, das hat aber auch nichts gebracht.

Ich verstehe zu wenig von Docker oder von Reverse Proxys, aber ich vermute mal, dass in der /etc/egroupware-docker/nginx.conf doch irgendwas falsch ist.
Hier mal die komplette Datei:

client_max_body_size 1g;

map $http_x_forwarded_proto $redirectscheme {
default $scheme;
https https;
}

server {
server_name MeinDNS.selfhost.bz;
root /var/www/html;

    index index.php index.nginx-debian.html index.html index.htm;

    # include other EGroupware parts like Collabora
    include app.d/egroupware*.conf;

    # proxy into EGroupware container
   location /egroupware {
            proxy_pass http://127.0.0.1:8080;
            include proxy_params;
            # to allow longer running requests like eg. backup or restore
            proxy_read_timeout    60m;
            # required for push / websocket
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "Upgrade";
    }

    location /nextcloud {
            proxy_pass http://127.0.0.1:8081;
            include proxy_params;
            # to allow longer running requests like eg. backup or restore
            proxy_read_timeout    60m;
            # required for push / websocket
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "Upgrade";
    }
    location = /status {
    proxy_pass http://127.0.0.1:8080;
    include proxy_params;
}

    # ActiveSync support
    location /Microsoft-Server-ActiveSync {
            proxy_pass http://127.0.0.1:8080;
            include proxy_params;
            # RB changed to 60m (from 20m) because that is length of zPush ping requests
            proxy_read_timeout    60m;
    }
    # CalDAV/CardDAV & OpenID Connect autoconfig
    location ~ ^/.well-known/(caldav|carddav|openid-configuration)$ {
            proxy_pass http://127.0.0.1:8080;
    include proxy_params;
    }
    location ~ ^(/principals/users/.*)$ {
            return 301 $redirectscheme://$host/egroupware/groupdav.php$1;
    }
    # Nginx does NOT use index for OPTIONS requests breakng WebDAV
    # for Windows, which sends OPTIONS / and stalls on Nginx 405 response!
    # This also redirects all requests to root to EGroupware.
    location = / {
            return 301 $redirectscheme://$host/egroupware/index.php;
    }
    # redirect /egroupware to /egroupware/
    location = /egroupware {
            return 301 $redirectscheme://$host/egroupware/index.php;
    }

listen 443 http2 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/MeinDNS.selfhost.bz/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/MeinDNS.selfhost.bz/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

}
server {
if ($host = MeinDNS.selfhost.bz) {
return 301 https://$host$request_uri;
} # managed by Certbot

    listen 80 default_server;

    server_name MeinDNS.selfhost.bz;
return 404; # managed by Certbot

}

Um die Frage zu beantworten was ich mit Nextcloud mache, was nicht auch mit EGroupware geht:
Kanban mache ich darüber mit der Android Deck App.
Aber ich nutze das ganze System ja rein privat, ist also auch nicht so schlimm wenn es nicht mehr funktioniert. Dann suche ich mir was neues. Hauptsache die EGroupware geht, die finde ich deutlich besser als Kopano!

Vielen Dank und viele Grüße!
Michael

[StefanU]

Ich habe den nginx neu gestartet, das hat aber auch nichts gebracht.

Der Docker-Nginx ist NICHT der Reverse-Proxy!
Der für EGroupware als Webserver aus.

Der Reverse-Proxy-Nginx ist auf deinem Host installiert und läuft dort als Dienst. Den müsstest du neu Starten um die Konfigurationsänderungen wirksam werden zu lassen.

---

Lesenswert dazu:
https://help.egroupware.org/t/de-uk-folien-vortrag-slides-lecture-kielux-2021-docker-fur-egroupware/76230
Folien Seite 26
Das Video zu schauen schadet auch nicht das Thema Docker+EGroupware besser zu verstehen.

Stefan

[lendl]

Hallo Stefan,

danke für die Info.
Hab ich mir durchgelesen und angeschaut, aber vermutlich nicht alles verstanden…

Ich habe jetzt nochmal die Konfig vom Reverse Proxy geändert (nachdem ich jetzt weiss, dass der lokal auf der VM läuft) aber ich komme trotzdem nicht weiter.

client_max_body_size 1g;

map $http_x_forwarded_proto $redirectscheme {
default $scheme;
https https;
}

server {
server_name myDNS.selfhost.bz;
root /var/www/html;

index index.php index.nginx-debian.html index.html index.htm;

 location /nextcloud {
        proxy_pass http://127.0.0.1:8081;
        include proxy_params;
        # to allow longer running requests like eg. backup or restore
        proxy_read_timeout    60m;
        # required for push / websocket
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
}

}

server {

server_name myDNS.selfhost.bz;
root /var/www/html;

index index.php index.nginx-debian.html index.html index.htm;

# include other EGroupware parts like Collabora
include app.d/egroupware*.conf;

# proxy into EGroupware container
location /egroupware {
        proxy_pass http://127.0.0.1:8080;
        include proxy_params;
        # to allow longer running requests like eg. backup or restore
        proxy_read_timeout    60m;
        # required for push / websocket
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
}

# PHP in docroot
#location ~ \.php {
#       fastcgi_pass unix:/run/php/php7.0-fpm.sock;
#       include fastcgi_params;
#}

location = /status {
proxy_pass http://127.0.0.1:8080;
include proxy_params;
}

# ActiveSync support
location /Microsoft-Server-ActiveSync {
        proxy_pass http://127.0.0.1:8080;
        include proxy_params;
        # RB changed to 60m (from 20m) because that is length of zPush ping requests
        proxy_read_timeout    60m;
}
# CalDAV/CardDAV & OpenID Connect autoconfig
location ~ ^/.well-known/(caldav|carddav|openid-configuration)$ {
        proxy_pass http://127.0.0.1:8080;
include proxy_params;
}
location ~ ^(/principals/users/.*)$ {
        return 301 $redirectscheme://$host/egroupware/groupdav.php$1;
}
# Nginx does NOT use index for OPTIONS requests breakng WebDAV
# for Windows, which sends OPTIONS / and stalls on Nginx 405 response!
# This also redirects all requests to root to EGroupware.
location = / {
        return 301 $redirectscheme://$host/egroupware/index.php;
}
# redirect /egroupware to /egroupware/
location = /egroupware {
        return 301 $redirectscheme://$host/egroupware/index.php;
}

listen 443 http2 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/myDNS.selfhost.bz/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/myDNS.selfhost.bz/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

}

server {
if ($host = myDNS.selfhost.bz) {
return 301 https://$host$request_uri;
} # managed by Certbot

listen 80 default_server;

server_name myDNS.selfhost.bz;

return 404; # managed by Certbot
}

Falls noch jemand ne zündende Idee für mich hat, wäre ich dankbar, ansonsten gebe ich das Vorhaben auf.

Vielen Dank vorab und viele Grüße!
Michael

[StefanU]

@Yann_Lehmann
Hättest du für ihn mal deine
/etc/egroupware-docker/nginx.conf
als Beispiel?
Oder hast du die Konfig für den weiteren Dienst an anderer Stelle hinzu gefügt?

@lendl
Ich habe mal ein wenig gestöbert… NC in einem /nextcloud laufen zu lassen scheint nicht ganz so einfach. Schau mal:
https://github.com/nextcloud/docker/issues/2276

Stefan

[Yann_Lehmann]

@Yann_Lehmann
Hättest du für ihn mal deine
/etc/egroupware-docker/nginx.conf
als Beispiel?
Oder hast du die Konfig für den weiteren Dienst an anderer Stelle hinzu gefügt?

Bei uns läuft es ein Bisschen anders. Die andere App ist Roundcube (für Mail-User die keine EGroupware Account haben) und die wird als subdomain direkt aufgerufen (roundcube.beispiel.xyz). Dafür haben wir auf dem Reverse-Proxy eine entsprechende conf-Datei, die sehr von derjenige für EGroupware inspiriert ist.
Wie ich oben geschrieben habe enthält unser Let’s encrypt Zertifikat egroupware und roundcube (und eine dritte subdomain für eine App auf einem anderen Server).

Hier die conf-Datei für roundcube, die in /etc/nginx/sites-available und sites-enabled verlinkt ist (als txt umbenannt zum Uploaden):

nginx.conf.txt (1.8 KB)

[Yann_Lehmann]

@lendl
Ich habe mal ein wenig gestöbert… NC in einem /nextcloud laufen zu lassen scheint nicht ganz so einfach. Schau mal:
https://github.com/nextcloud/docker/issues/2276

Mit der Lösung oben würde das Problem mit NC im Unterverzeichnis umgegangen, da direkt aufgerufen (mit nextcloud.beispiel.xyz).

[lendl]

Super, vielen Dank Euch beiden!

Das bedeutet aber, dass es zwei .conf Dateien für den Reverse Proxy gibt, oder?
Eine für RoundCube und eine für die EGroupware, richtig?

Ich werde mal einen anderen Docker Container laden und schauen, ob ich den erreichen kann.
Vielleicht liegt es ja auch wirklich an der Nextcloud.

Vielen Dank und viele Grüße!
Michael

[Yann_Lehmann]

Das bedeutet aber, dass es zwei .conf Dateien für den Reverse Proxy gibt, oder?
Eine für RoundCube und eine für die EGroupware, richtig?

Ja, und die für EGroupware bleibt gleich.

[lendl]

Der Vollständigkeit halber noch die Rückmeldung, dass ich es nicht hinbekommen habe.
Ich denke, dass es funktioniert hätte, wenn ich die Nextcloud statt unter http://localhost unter http://localhost/nextcloud zum Laufen gebracht hätte. Hab ich aber nicht.
Mehr Zeit wollte ich jetzt einfach nicht mehr investieren.
Ich habe mir jetzt eine andere VM mit einer Nextcloud Snap Installation gemacht und kopiere das Let’s Encrypt Zertifikat da rein. Dann habe ich dort auch keine Zertifikatsfehlermeldung.
Vielen Dank nochmal für Eure Unterstützung!
Viele Grüße!
Michael