Skip to content
Menu
TechDudes.de
  • Allgemein
  • Server
  • Linux
  • Impressum
TechDudes.de

Reverse Proxy, NextCloud, MailCow Server installieren

Posted on 1. Mai 202016. Januar 2022 by Beat

Der Titel lässt es schon vermuten hier will ich eine neuen Personal Cloud Server aufsetzen. Dieser soll mir als E-Mail, Kalender, Kontakt Server und Daten Cloud dienen. Das ganze ist als Docker System Konfiguration gedacht.

Die Architektur sieht vor, dass es vorne dran einen Reverse Proxy gibt der die Anfragen für verschiedene Seiten empfängt und an die verschiedene Docker Container verteilt.

Server Update

Zunächst habe ich ein Server-Update durchgeführt. Der frische Server war zwar ein 18.04 Ubuntu aber da innerhalb dieses Monats schon das offiziele Release der 20.04er Version kommen soll spare ich mir das spätere Systemupdaten.

Der Befehl zum Updaten lautet:

sudo do-release-upgrade -d

Danach werden verschiedene Prüfungen durchgeführt, dabei ist darauf zu achten, dass die alten Config-Files behalten werden müssen.

Docker Installation

Als nächstes installieren wir Docker.

sudo apt install docker.io

Docker sollten wir zum automatischen Start nach einem Reboot hinzufügen:

sudo systemctl enable --now docker

Die Docker Version kann mit folgenden Befehl überprüft werden:

docker --version

Als nächstes brauchen wir noch Docker Compose

sudo apt install docker-compose

ReverseProxy Installation

Nachdem wir nun eine lauffähige Dockerumgebung haben machen wir uns an unseren Reverse Proxy. Dieser steht vor unserer Mailcow und Nextcloud Installation welche in ihren eigenen Netzwerken laufen und generiert für diese jeweils auch die HTTPS Zertifikate.

cd /opt
mkdir nginx-rproxy
cd nginx-rproxy

In diesem Verzeichnis schreiben wir unsere docker-compose.yml, um die entsprechende Container des ReverseProxy Verbunds aufzubauen.

nano docker-compose.yml

Hier geben wir folgende Infos ein:

version: "3"

services:
  nginx-proxy:
    image: jwilder/nginx-proxy:alpine
    container_name: nginx-proxy
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - /opt/nginx-rproxy/nginx-certs:/etc/nginx/certs
      - /opt/nginx-rproxy/nginx-vhost:/etc/nginx/vhost.d
      - /opt/nginx-rproxy/nginx-html:/usr/share/nginx/html
      - /opt/nginx-rproxy/uploadsize.conf:/etc/nginx/conf.d/uploadsize.conf
    networks:
      service_network:

  nginx-proxy-letsencrypt:
    image: jrcs/letsencrypt-nginx-proxy-companion
    environment:
      NGINX_PROXY_CONTAINER: "nginx-proxy"
    networks:
      service_network:
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro                                                             
      - /opt/nginx-rproxy/nginx-certs:/etc/nginx/certs                                                                        
      - /opt/nginx-rproxy/nginx-vhost:/etc/nginx/vhost.d
      - /opt/nginx-rproxy/nginx-html:/usr/share/nginx/html

networks:
  service_network:

Des weiteren brauchen wir noch eine kleine Datei damit Nextcloud auch größere Dateien verarbeiten kann.

nano uploadsize.conf

Ihr Inhalt ist:

client_max_body_size 10G;
proxy_request_buffering off;

Jetzt starten wir den Containerverbund mit

docker-compose pull
docker-compose up -d

Ich habe mich für diese zwei vorkonfigurierten Container (jwilder/nginx-proxy, jrcs/letsencrypt-nginx-proxy-companion) entschieden, weil sie mir ermöglichen durch ein paar wenige Zeilen neue Service verfügbar zu machen. Hier die wenigen Zeilen:

        - VIRTUAL_HOST={HOSTNAME_FQDN}
        - VIRTUAL_PORT=8080
        - VIRTUAL_PROTO=http
        - LETSENCRYPT_HOST={HOSTNAME_FQDN}
        - LETSENCRYPT_EMAIL=mail@example.org

MailCow Server Installation

Nun machen wir uns an die Installation von MailCow. Als erstes prüfen wir ober unsere User Mask gleich 0022 ist und holen uns dann die MailCow Daten.

umask
# 0022
cd /opt
git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized

Wir generieren zunächste ein Konfigurationsdatei. Bitte benutzt dazu eine FQDN (host.domain.tld) als hostname wenn ihr gefragt werdet. Diese Domain muss nicht die Mail Domain sein. Es ist aber die Domain die ihr dann in eurem E-Mailclient eintragt.

./generate_config.sh

Nun kommt aus meiner Sicht der wichtigste Schritt, dass ändern der Konfigurationsdatei.

nano mailcow.conf

Da wir unsere Mailcow hinter einem Reverse Proxy verwenden wollen ändern wir die Daten von HTTPS zu 127.0.0.1 auf Port 8443 und HTTP zu 127.0.0.1 auf Port 8080.

HTTP_PORT=8080 
HTTP_BIND=127.0.0.1 
HTTPS_PORT=8443 
HTTPS_BIND=127.0.0.1 

SKIP_LETS_ENCRYPT=y

Des weiteren passen wir noch die docker-compose.yml an. Damit unser Reverse Proxy zum einem die Container kennt und an diese den Datenverkehr weiterleitet und weiterhin wird unser Reverseproxy auch die Zertifikate generieren. Diese Zertifikate müssen aber auch in den Containern eingetragen werden.

nano docker-compose.yml

Dort suchen wir nach dem nginx Container „nginx-mailcow“ und fügen folgende Zeile hinzu bzw. ändern diese. Ersetz bitte die Stelle {deine gewählte FQDN} mit der vorher angegebenen Domain.

...
    nginx-mailcow:
...
      environment:
...
        - VIRTUAL_HOST=${MAILCOW_HOSTNAME}
        - VIRTUAL_PORT=8080
        - VIRTUAL_PROTO=http
        - LETSENCRYPT_HOST=${MAILCOW_HOSTNAME}
        - LETSENCRYPT_EMAIL=mail@example.org
...
      volumes:
        - /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/fullchain.pem:/etc/ssl/mail/cert.pem:ro
        - /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/key.pem:/etc/ssl/mail/key.pem:ro
...
#      ports:
#        - "${HTTPS_BIND:-0.0.0.0}:${HTTPS_PORT:-443}:${HTTPS_PORT:-443}"
#        - "${HTTP_BIND:-0.0.0.0}:${HTTP_PORT:-80}:${HTTP_PORT:-80}"
      expose:
         - "8080"
...
      networks:
        mailcow-network:
          aliases:
            - nginx
        nginx-rproxy_service_network:
          aliases:
            - mail.example.org

In der gleichen Datei fügen wir noch bei zwei Container (Postfix, Dovecot) die Zertifikatsänderungen ein.

...
    postfix-mailcow
...
      volumes:
        - /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/fullchain.pem:/etc/ssl/mail/cert.pem:ro
        - /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/key.pem:/etc/ssl/mail/key.pem:ro
...
    dovecot-mailcow
...
      volumes:
        - /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/fullchain.pem:/etc/ssl/mail/cert.pem:ro
        - /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/key.pem:/etc/ssl/mail/key.pem:ro

Achtung:

Es kann dazu kommen, dass er eine Fehlermeldung wirft, dass etwas nicht da ist.

Das Problem sind die folgenden Zeilen in der docker-compose.yml des Mailcow Dienstes:
volumes:

– /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/fullchain.pem:/etc/ssl/mail/cert.pem:ro
– /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/key.pem:/etc/ssl/mail/key.pem:ro
...

Da die Zertifikate erst generiert werden wenn die Container das erste Mal starten sind diese beim initialen docker-compose up -d nicht vorhanden. Daher erstellt Docker Folder an Stelle der Dateien. Daher der Fehler.

Lösung: Die Zeilen in allen Services kommentieren und einmal starten. Dann wieder auskommentieren und nochmal ein docker-compose up -d machen. — Vielen Dank Vincent

Als letzte Änderung machen wir unserem späteren Reverse Proxy das Mailcow Netzwerk bekannt.

...
networks:
...
  nginx-rproxy_service_network:
    external: true

Als letzten Schritt starten wir die ganze Container Bande mit

docker-compose pull
docker-compose up -d

Nextcloud Installation

Für die Nextcloud habe ich wieder einen eigenen Ordner angelegt.

cd /opt
mkdir nextcloud
cd nextcloud

In diesem Verzeichnis schreiben wir wieder unsere docker-compose.yml, um die entsprechende Container des Nextclouds Verbunds aufzubauen.

nano /opt/nextcloud/docker-compose.yml

Hier geben wir folgende Infos ein.
Bitte ersetzt {mysql root passwort} mit einem entsprechend starkem Passwort und {HOSTNAME_FQDN} wie auch {HOSTNAME_EMAIL} mit eurer (Sub-)Domain und E-Mail.

version: '3'

services:
  db:
    image: mariadb
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    restart: always
    volumes:
      - db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD={mysql root passwort}
    env_file:
      - db.env
    networks:
      nextcloud-network:
        aliases:
          - nextcloud-mariadb

  redis:
    image: redis:alpine
    restart: always
    networks:
      nextcloud-network:
        aliases:
          - nextcloud-redis

  app:
    image: nextcloud:fpm-alpine
    restart: always
    volumes:
      - nextcloud:/var/www/html
    environment:
      - MYSQL_HOST=db
      - REDIS_HOST=redis
    env_file:
      - db.env
    depends_on:
      - db
      - redis
    networks:
      nextcloud-network:
        aliases:
          - nextcloud-app

  web:
    image: nginx:alpine
    restart: always
    volumes:
      - nextcloud:/var/www/html:ro
      - /opt/nextcloud/nginx.conf:/etc/nginx/nginx.conf:ro
    environment:
      - VIRTUAL_HOST={HOSTNAME_FQDN}
      - LETSENCRYPT_HOST={HOSTNAME_FQDN}
      - LETSENCRYPT_EMAIL={HOSTNAME_EMAIL}
    depends_on:
      - app
    networks:
      nextcloud-network:
        aliases:
          - nextcloud
      nginx-rproxy_service_network:
        aliases:
          - nextcloud

  cron:
    image: nextcloud:fpm-alpine
    restart: always
    volumes:
      - nextcloud:/var/www/html
    entrypoint: /cron.sh
    depends_on:
      - db
      - redis
    networks:
      nextcloud-network:
        aliases:
          - nextcloud-cron


volumes:
  db:
  nextcloud:

networks:
  nginx-rproxy_service_network:
    external: true
  nextcloud-network:
    driver: bridge
    driver_opts:
      com.docker.network.bridge.name: br-nextcloud

Wie ihr seht sind da einige Container drin. Hierbei habe ich mich an dem Standard Beispiel von Nextcloud orientiert. Folgende Dateien werden dazu noch benötigt:

/opt/nextcloud/nginx.conf:

worker_processes auto;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    set_real_ip_from  10.0.0.0/8;
    set_real_ip_from  172.16.0.0/12;
    set_real_ip_from  192.168.0.0/16;
    real_ip_header    X-Real-IP;

    #gzip  on;

    upstream php-handler {
        server app:9000;
    }

    server {
        listen 80;

        # Add headers to serve security related headers
        # Before enabling Strict-Transport-Security headers please read into this
        # topic first.
        #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
        #
        # WARNING: Only add the preload option once you read about
        # the consequences in https://hstspreload.org/. This option
        # will add the domain to a hardcoded list that is shipped
        # in all major browsers and getting removed from this list
        # could take several months.
        add_header Referrer-Policy "no-referrer" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header X-Download-Options "noopen" always;
        add_header X-Frame-Options "SAMEORIGIN" always;
        add_header X-Permitted-Cross-Domain-Policies "none" always;
        add_header X-Robots-Tag "none" always;
        add_header X-XSS-Protection "1; mode=block" always;

        # Remove X-Powered-By, which is an information leak
        fastcgi_hide_header X-Powered-By;

        # Path to the root of your installation
        root /var/www/html;

        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
        }

        # The following 2 rules are only needed for the user_webfinger app.
        # Uncomment it if you're planning to use this app.
        #rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
        #rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

        # The following rule is only needed for the Social app.
        # Uncomment it if you're planning to use this app.
        #rewrite ^/.well-known/webfinger /public.php?service=webfinger last;

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

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

        # set max upload size
        client_max_body_size 10G;
        fastcgi_buffers 64 4K;

        # Enable gzip but do not remove ETag headers
        gzip on;
        gzip_vary on;
        gzip_comp_level 4;
        gzip_min_length 256;
        gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
        gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

        # Uncomment if your server is build with the ngx_pagespeed module
        # This module is currently not supported.
        #pagespeed off;

        location / {
            rewrite ^ /index.php;
        }

        location ~ ^\/(?:build|tests|config|lib|3rdparty|templates|data)\/ {
            deny all;
        }
        location ~ ^\/(?:\.|autotest|occ|issue|indie|db_|console) {
            deny all;
        }

        location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+)\.php(?:$|\/) {
            fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
            set $path_info $fastcgi_path_info;
            try_files $fastcgi_script_name =404;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            # fastcgi_param HTTPS on;

            # Avoid sending the security headers twice
            fastcgi_param modHeadersAvailable true;

            # Enable pretty urls
            fastcgi_param front_controller_active true;
            fastcgi_pass php-handler;
            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;
        }

        location ~ ^\/(?:updater|oc[ms]-provider)(?:$|\/) {
            try_files $uri/ =404;
            index index.php;
        }

        # Adding the cache control header for js, css and map files
        # Make sure it is BELOW the PHP block
        location ~ \.(?:css|js|woff2?|svg|gif|map)$ {
            try_files $uri /index.php$request_uri;
            add_header Cache-Control "public, max-age=15778463";
            # Add headers to serve security related headers (It is intended to
            # have those duplicated to the ones above)
            # Before enabling Strict-Transport-Security headers please read into
            # this topic first.
            #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
            #
            # WARNING: Only add the preload option once you read about
            # the consequences in https://hstspreload.org/. This option
            # will add the domain to a hardcoded list that is shipped
            # in all major browsers and getting removed from this list
            # could take several months.
            add_header Referrer-Policy "no-referrer" always;
            add_header X-Content-Type-Options "nosniff" always;
            add_header X-Download-Options "noopen" always;
            add_header X-Frame-Options "SAMEORIGIN" always;
            add_header X-Permitted-Cross-Domain-Policies "none" always;
            add_header X-Robots-Tag "none" always;
            add_header X-XSS-Protection "1; mode=block" always;

            # Optional: Don't log access to assets
            access_log off;
        }

        location ~ \.(?:png|html|ttf|ico|jpg|jpeg|bcmap|mp4|webm)$ {
            try_files $uri /index.php$request_uri;
            # Optional: Don't log access to other assets
            access_log off;
        }
    }
}

Und die Passwortdatei für die Datenbank
/opt/nextcloud/db.env

MYSQL_PASSWORD={starkes Passwort}
MYSQL_DATABASE=nextcloud
MYSQL_USER=nextcloud

Jetzt starten wir den letzten Containerverbund mit

docker-compose pull
docker-compose up -d

Was fehlt noch?

Mir fehlt jetzt noch der Docker Watchtower der mir die Container neustartet falls sie sich mal aufgehängt haben.

Links

Folgende Guides haben mir dabei geholfen das ganze umzusetzen:

https://dev.to/adamkdean/automatic-ssl-with-let-s-encrypt-nginx-4nfk
https://mailcow.github.io/mailcow-dockerized-docs/i_u_m_install/
https://forum.netcup.de/administration-eines-server-vserver/vserver-server-kvm-server/p121991-docker-mailcow-nginx-reverse-proxy-wordpress/#post121991

27 thoughts on “Reverse Proxy, NextCloud, MailCow Server installieren”

  1. Matthias sagt:
    3. Juni 2020 um 17:58 Uhr

    Hallo,

    super Anleitung. Ich bekomme leider beim hochfahren von Mailcow docker-compose immer eine Fehlermeldung für die Volumes, die ich hinzufügen musste.

    ..
    nginx-postfix
    …
    volumes:
    – /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/fullchain.pem:/etc/ssl/mail/cert.pem:ro
    – /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/key.pem:/etc/ssl/mail/key.pem:ro
    …
    nginx-dovecot
    …
    volumes:
    – /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/fullchain.pem:/etc/ssl/mail/cert.pem:ro
    – /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/key.pem:/etc/ssl/mail/key.pem:ro

    Fehlermeldung:

    ERROR: for mailcowdockerized_nginx-mailcow_1 Cannot start service nginx-mailcow: OCI runtime create failed: container_linux.go:349: starting container process caused „process_linux.go:449: container init caused \“rootfs_linux.go:58: mounting \\\“/opt/nginx-rproxy/nginx-certs/xxx.xx.xx/key.pem\\\“ to rootfs \\\“/var/lib/docker/overlay2/de17761ac1340a4a1ac2f37776e24556be700771bd35a40d97b2b21247cbbba8/merged\\\“ at \\\“/var/lib/docker/overlay2/de17761ac1340a4a1ac2f37776e24556be700771bd35a40d97b2b21247cbbba8/merged/etc/ssl/mail/key.pem\\\“ caused \\\“not a directory\\\“\““: unknown: Are you trying to mount a directory onto a

    Es liegt eigentlich nicht an dem Pfad, der Ordner ist da und hat auch Berechtigung. Könnt ihr mir da weiterhelfen?

    Antworten
    1. Beat sagt:
      12. Juni 2020 um 17:10 Uhr

      Hallo Matthias,

      danke für deinen Kommentar. Leider schaffe ich es erst heute auf darauf zu reagieren. So direkt sehe ich keinen Fehler. Ich hatte das Problem auch mal beim experimentieren gehabt. Konnte es aber auch nicht genauer eingrenzen beim zweiten Versuch. Mit neuer docker-compose.yml hat es dann funktioniert.
      Wenn du noch immer das Problem hast melde dich nochmal gerne bei uns.

      Antworten
    2. Vincent sagt:
      23. Juni 2020 um 22:34 Uhr

      Das Problem sind die folgenden Zeilen in der docker-compose.yml des Mailcow Dienstes:
      volumes:
      – /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/fullchain.pem:/etc/ssl/mail/cert.pem:ro
      – /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/key.pem:/etc/ssl/mail/key.pem:ro
      …
      Da die Zertifikate erst generiert werden wenn die Container das erste Mal starten sind diese beim initialen docker-compose up -d nicht vorhanden. Daher erstellt Docker Folder an Stelle der Dateien. Daher der Fehler.

      Lösung: Die Zeilen in allen Services kommentieren und einmal starten. Dann wieder auskommentieren und nochmal ein docker-compose up -d machen.

      Antworten
      1. Beat sagt:
        23. Juni 2020 um 22:40 Uhr

        Danke Vincent, war mir auch noch nicht bewusst gewesen. Das erklärt wieso ich ein ähnliches Verhalten auch hatte.

        Werde dies bei Gelegenheit noch in der Anleitung erweitern.

        Antworten
  2. Marcus Borchert sagt:
    18. August 2020 um 17:20 Uhr

    Hallo, super Anleitung. Leider bekomme ich beim Starten/Abholen des Mailcow-containers eine Fehlermeldung mit der docker-compose.yml. Die beiden container nginx-postfix & nginx-dovecot sind auch nicht enthalten. muss ich diese beiden extra anlegen? Bitte um kurze Anleitung, Hilfe. Vielen Dank.

    Antworten
    1. Beat sagt:
      18. August 2020 um 22:37 Uhr

      Danke für das Lob. Eigentlich sollte er durch das docker compose die Container selbst abholen. Könntest du deine docker-compose.yml und vielleicht deine Fehlermeldung posten?

      Antworten
      1. Marcus Borchert sagt:
        21. August 2020 um 16:14 Uhr

        ich habe die docker-compose.yml noch einmal neu von GitHub gezogen und bei mir ersetzt. ich habe da wohl Fehler gemacht. jetzt kommen diese Meldungen nichtmehr. allerdings habe ich jetzt nun das gleiche problem, welches Matthias hat/hatte….
        wie lange muss ich den container gestartet haben?

        Antworten
    2. Luke sagt:
      20. August 2020 um 05:13 Uhr

      Nein, sie wurden lediglich in postfix-mailcow und dovecot-mailcow umbenannt.

      Antworten
  3. Beat sagt:
    21. August 2020 um 09:48 Uhr

    Anmerkungen von Luke und Vincent sind eingearbeitet. Vielen Dank an dieser Stelle.

    Antworten
  4. Marcel sagt:
    21. August 2020 um 21:08 Uhr

    Hallo zusammen. Nachdem ich beim ersten Mal auch den Fehler von Matthias hatte, habe ich mittlerweile den Rat von Vincent befolgt. Zertifikate werden erst angelegt, wenn ich einmal den Mailcow über den Browser aufrufe. Dann erst kann ich die .yml-Datei abändern und die Kommentierung rausnehmen.

    Leider funktioniert es trotzdem nicht, weil die Mailcow-Webseite nicht angezeigt wird. Versuche ich den host ohne portnummer (alles auf 8082 abgeändert) anzusprechen, erhalte ich eine 502 Fehlermeldung mit dem Hinweis, die logs von php-fpm-mailcow anzusehen, die nur „Waiting for SQL“ enthalten. Der mysql-container läuft aber sauber. Auch der nextcloud-container läuft sauber.

    Was könnte mein Problem sein?

    Antworten
    1. Marcel sagt:
      22. August 2020 um 14:33 Uhr

      Mittlerweile konnte ich das Problem durch etliche andere Hinweise lösen. Mailcow funktioniert. Nextcloud schien auch zu funktionieren. Zickt bei der Installation zwar rum, aber nach dem dritten Mal docker-compose down und up hat er richtig installiert.

      Interessanterweise hat er jedoch Probleme bei der Darstellung mancher Icons und auch eine Warnung wird ausgegeben: Ihr Webserver ist nicht richtig konfiguriert um „/.well-known/caldav“ aufzulösen.

      Dazu eine Frage: Welchen Grund hatte es, in der nextcloud/nginx.conf das Horchen am port 443 für ssl wegzulassen und alles unter http zu setzen? In der originalen Anleitung von nginx.conf stehen sowohl „listen 80“ als auch „listen 443“ für sich als Block.

      Schöne Grüße

      Antworten
      1. Beat sagt:
        22. August 2020 um 16:53 Uhr

        Hallo Marcel,

        das mit dem „/.well-known/caldav“ kenne ich auch und habe ich am ende nicht gelöst bekommen. War mir auch nicht wichtig da die direkten URLs für caldav trotzdem funktionieren. Der Pfad macht es nur leichter in manchen Programme die Einstellungen hin zu bekommen.

        Was das 443 betrifft ist es so, dass du wenn du so willst ein internes Netzwerk innerhalb der Maschine durch Docker konfigurierst. In diesem braucht dann kein SSL Verschlüsselung stattfinden, weil das Netzwerk nicht von aussen erreichbar ist. Weiterhin ist es schwieriger den Server innerhalb des Netzwerkes mit SSL zu konfigurieren.

        Antworten
        1. Marcel sagt:
          28. August 2020 um 15:29 Uhr

          Hi Beat, die Lösung für das Problem mit caldav und cardav war, dass man in der nginx.conf die Portnummern bei den entsprechenden Einträgen löschen muss, dann funktioniert es:

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

          zu

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

          Antworten
    2. Marcel sagt:
      22. August 2020 um 15:18 Uhr

      Zusätzlich bekomme ich in Nextcloud laufend im Protokoll RedisException Errors: ERR AUTH called without any password configured for the default user. Are you sure your configuration is correct?

      Ich habe mich an diese Anleitung hier gehalten: https://github.com/nextcloud/docker/issues/1179

      Änderunge am docker-compose.yml file von nextcloud:
      redis:
      image: redis:alpine
      restart: always
      volumes:
      – ./redis.conf:/usr/local/etc/redis/redis.conf
      command: redis-server /usr/local/etc/redis/redis.conf

      app:
      REDIS_HOST_PASSWORD=

      Erstellen einer redis.conf im nextcloud-Verzeichnis mit Inhalt:
      requirepass

      Zumindest kommt der ERR AUTH Fehler jetzt nicht mehr. Hat wohl damit etwas zu tun, dass Redis upgedated wurde und jetzt ein Passwort benötigt. Die Anleitung sollte das bitte berücksichtigen.

      Antworten
      1. Beat sagt:
        22. August 2020 um 16:54 Uhr

        OK ich schaue, dass ich das übernehme.

        Antworten
  5. Flo sagt:
    11. September 2020 um 18:33 Uhr

    – /opt/nginx-rproxy/nginx-certs/{deine gewählte FQDN}/fullchain.pem:/etc/ssl/mail/cert.pem:ro

    mit was soll hier /mail/ ersetzt werden?
    Oder ist das ein Ordner der sowieso erst erstellt wird durch den mailcow container? Muss das dennoch irgendwo angepasst werden?

    An welcher Stelle werden die Zertifikate erstellt? Und wie interagieren hier mailcow und der ReverseProxy?

    fullchain.pem key.pem <- Sollen das am Ende Ordner oder Dateien sein?

    Bei mir wird immer im rproxy container ausgespuckt:
    Creating/renewal mail.xxx.de certificates… (mail.xxx.de)
    [Errno 21] Is a directory: 'key.pem'

    Wo liegt der Fehler? Warum wird keine Datei erstellt?

    Antworten
  6. Beat sagt:
    5. November 2020 um 11:19 Uhr

    Bei einem Update des Nextcloud Docker kann es Probleme geben weil keine Redis Verbindung mehr funktioniert.
    Fehlermeldung ist: ERR AUTH called without any password configured for the default user. Are you sure your configuration is correct? in /var/www/html/lib/private/RedisFactory.php:94

    Dazu sollten folgende Änderung in der docker-compose.yml gemacht werden:
    app:
    …
    environment:
    REDIS_HOST: redis
    REDIS_HOST_PASSWORD: yourpassword
    depends_on:
    – redis
    – …

    redis:
    image: redis:alpine
    command: redis-server –requirepass yourpassword

    Antworten
  7. Olaf sagt:
    10. November 2020 um 22:10 Uhr

    Moin,
    ich versuche gerade Deine Anleitung um zusetzen.
    Mit dem Befehl docker-compose pull habe ich keine Problem. Wenn ich dann den Befehl docker-compose up -d starte kommt folgeden Fehlermeldung:
    root_nginx-proxy-letsencrypt_1 is up-to-date
    Creating nginx-proxy …
    Creating nginx-proxy … error

    ERROR: for nginx-proxy Cannot create container for service nginx-proxy: Conflict. The container name „/nginx-proxy“ is already in use by container „a818682a01fa04d3cbfbb3f0077bd49344f22bce9855de4208a34973f9e325b9“. You have to remove (or rename) that container to be able to reuse that name.

    ERROR: for nginx-proxy Cannot create container for service nginx-proxy: Conflict. The container name „/nginx-proxy“ is already in use by container „a818682a01fa04d3cbfbb3f0077bd49344f22bce9855de4208a34973f9e325b9“. You have to remove (or rename) that container to be able to reuse that name.
    ERROR: Encountered errors while bringing up the project.

    Was mach ich falsch?

    Gruß

    Antworten
  8. Benedikt sagt:
    28. November 2020 um 14:49 Uhr

    Sehr schönes Tutorial, habe zwar ein bisschen länger gebraucht als erwartet aber mittlerweile läuft alles hervorragend. Noch ein paar Anmerkungen, die mir während des Installationsprozesses aufgefallen sind:
    – Die LetsEncrypt E-Mail muss sowohl in mailcow als auch in nextcloud auf jeden Fall valide (oder etwas anderes als @example.org) sein, da LetsEncrypt ansonsten kein Zertifikat übergibt.
    -Man sollte die Dateien alle mit nano schreiben, ich habe es zuerst über WinSCPs Editor gemacht was zu Fehlern führte. (So wie hier auch angegeben).
    Schöne Grüße

    Antworten
  9. Sascha sagt:
    7. Dezember 2020 um 16:01 Uhr

    Hallo,
    danke für die ausführliche Anleitung.
    Bei mir funktioniert Nextcloud zwar, aber es ist unfassbar langsam und ich bekomme nach 1-2 Seiten auch 502 Bad Gateway.
    Kann mir jemand helfen?
    Mailcow läuft übrigens ohne Probleme und auch schnell….

    Antworten
    1. Az sagt:
      19. Februar 2021 um 12:29 Uhr

      Habe das selbe Problem, hast du es gelöst bekommen?

      Antworten
  10. Marco sagt:
    27. Februar 2021 um 14:01 Uhr

    Hallo,

    vielen dank für das Tutorial. Läuft auch alles sowiet ausser das bei der Nextcloud folgende Fehlermeldungen auftreten. Die ist erst seit der Nextcloud 21.

    Dein Web-Server ist nicht richtig eingerichtet um „/.well-known/webfinger“ aufzulösen. Weitere Informationen findest Du in der Dokumentation.
    Dein Web-Server ist nicht richtig eingerichtet um „/.well-known/nodeinfo“ aufzulösen. Weitere Informationen findest Du in der Dokumentation.

    Weiß jemand eine Lösung ?

    Vielen Dank 🙂

    Antworten
    1. Beat sagt:
      7. März 2021 um 22:41 Uhr

      also ich habe das Problem auch gehabt und konnte es mit folgenen Zeilen in der nginx.conf lösen:

      location = /.well-known/webfinger {
      return 301 $scheme://$host/index.php/.well-known/webfinger;
      }

      location = /.well-known/nodeinfo {
      return 301 $scheme://$host/index.php/.well-known/nodeinfo;
      }

      Antworten
  11. Peter sagt:
    4. April 2021 um 20:11 Uhr

    Hallo,
    vielen Dank für deine Anleitung. Dies ist die Einzige, die auf anhieb klappte und bei der auch wirklich die Dinge so passieren, wie es dort steht 🙂
    Ich habe zuvor 5 andere Anleitungen gelesen und entweder haben diese Verfasser das selbst geschriebene nicht getestet, oder mein Verstand war mit der Ausführung nicht kompatibel 🙂

    Zwei Fragen habe ich jedoch.
    1. Hat es einen bestimmten Grund, dass du das image: jwilder/nginx-proxy:alpine und nicht jwilder/nginx-proxy:latest nutzt?

    2. Ich habe das Problem gehabt (auch bei vielen anderen Docker Compose Dateien), dass immer ein prefix an die Container, Netzwerke, Volumes etc. gehängt wird.
    Aus dem Netzwerk in der jwilder yml Datei wird somit aus service_network: = nginx-rproxy_ service_network.
    Anschließend befanden sich nicht beide Container in diesem Netzwerk.
    Ich habe dann einfach folgende Änderung gemacht, mit der es dann klappte:
    networks:
    service_network:
    name: service_network

    Habe ich da etwas übersehen? Müsste das eigentlich auch ohne diese Änderung laufen?
    Viele Grüße

    Antworten
    1. Beat sagt:
      5. April 2021 um 10:57 Uhr

      Hallo Peter,
      zu deinen Fragen:
      1. Ich benutze alpine, da es die schmalere Distro ist. Alpine wird meines Wissen genauso gepflegt wie latest.
      2. Das scheint mir eine Systemgeschichte/Konfiguration zu sein, aber nach dem alten Prinzip never touch a running system würde ich da nichts ändern.

      VG Bill

      Antworten
  12. André sagt:
    1. November 2021 um 17:18 Uhr

    Hallo zusammen,

    erstmal Kompliment für die tolle Anleitung. Ich habe diese umgesetzt und habe das Problem, dass bei mir die Zertifikate als Ordner angelegt werden und danach nichts weiter passiert. Der Part von Vincent ist aus meiner Sicht nicht klar genug beschrieben. Vor dem ersten Start auskommentieren, Zertifikate werden angelegt und danach Kommentar wieder entfernen und neustarten? Das habe ich probiert, aber es kommen an diesen Pfad keine Zertifikate. Wenn ich es nicht auskommentiere und starte, habe ich die Ordner anstelle der Zertifikate… Wer kann mir hier weiterhelfen?
    VG, André

    Antworten
  13. utzachaka sagt:
    8. Januar 2022 um 15:36 Uhr

    Hallo,

    gibt es hiervon eine aktualisierte Version? Diese scheint nicht mehr zu funktionieren. Mailcow geht nur über http und bei Nextcloud bekomme ich Error 503.
    Den Trick erst ohne die SSL Zertifikate zu starten und dann das auskommentierte wieder dazu zu nehmen, bewirkt nichts, außer, dass ich Mailcow gar nicht fehlerfrei zum laufen bekomme, solange die Zeilen drin sind.

    Antworten

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Neueste Beiträge

  • Smart 451 Schlüsselbatterie wechseln und Schlüssel wieder anlernen
  • VDR Server im LXC-Container unter Proxmox
  • Einen guten Start in 2021
  • Arch Linux in Proxmox LXC – first Steps
  • Pimp your Zbox

Kategorien

  • Allgemein
  • Android
  • Arch Linux
  • Browser
  • Chrome
  • Debian
  • Docker
  • Firefox
  • IBM (Allgemein)
  • IBM (Server)
  • KVM
  • Linux
  • LXC
  • NAS
  • Raspberry Pi
  • Redhat / CentOS
  • Server
  • Sonstiges
  • Sun
  • Thunderbird
  • Toolbox
  • Ubuntu
  • Virtualisierung
  • Windows
  • Xen

Schlagwörter

18.04 451 Acer Android Arch Linux Aspier Batterie wechseln bios bios-mod container denicid docker Dropbox DVB-C dvb-c2 DVB-S2 id4me Install Installation Kubuntu kvm lga Linux LXC mailcow microcode mSATA nextcloud pin-mod Proxmox proxmox-ve pve ReverseProxy Schlüssel Schlüssel anlernen Schlüsselbatterie Smart Smart451 SSD Thunderbird Ubuntu V3-771 V3-771G VDR vt-d
©2025 TechDudes.de | Theme: Wordly by SuperbThemes