nginx: Verschiedene Webseiten auf einer Domain per Subdomain zugänglich machen?

TSKNF

Lieutenant
Registriert
Dez. 2013
Beiträge
631
Moin :) Ich hoffe ich bin hier richtig. Ich würde gerne eine eigene Nextcloud betreiben. Ich würde es gerne so einrichten, das netdata, postfixadmin und roundcube per subdomain erreichbar sind. Optional wäre auch webmin per subdomain toll ;)

Die Themen Linux und VPS sind für mich echt totales Neuland aber ich habe viele viele Server die letzten 2 Wochen aufgesetzt und es macht schon Spaß. Aber ich stoße immer wieder auf Probleme, die mich zum Umdenken bringen.

Momentan bin ich bei Debian 11 mit nginx als Webserver. Nextcloud, postfix und postfixadmin sind installiert. Jetzt würde ich gerne, als nächsten Schritt, die Nextcloud über http/s://example.com und postfixadmin über http/s://admin.example.com erreichbar machen. Mit einer Weiterleitung von http auf https. Wenn das klappt, sollen danach noch netdata und roundcube, auf die selbe Art und Weise, intregriert werden. Die Domain ist konfiguriert und funktioniert. Habe leider nur eine feste IPv4 und einen kleinen Bereich von IPv6 Afdressen.

Die installationen sind nicht im /var/www/html/ Ordner. Bis jetzt sind nexcloud und postfixadmin in /var/ und das würde ich auch gerne so lassen.

/var/nextcloud
/var/postfixadmin

Die Frage die ich habe. Ist dies mit nginx ohne weiteres möglich? Ich habe dafür kein gutes Tutorial gefunden und eigentlich bin ich endlich mit meiner arbeit in Linux halbwegs zufrieden. Ich bin über eine Lösung mit nginx reverse proxy gestolpert. Aber bei dem Thema haben sich erstmal nur noch viel mehr fragen aufgetan als sich beantwortet haben. Ausserdem konnte ich die Schritte auch nicht fehlerfrei reproduzieren.

Oder bin ich hier einfach nur falsch mit nginx und müsste auf Apache wechseln. Auch in diesem Fall währe ich für ein gutes Tutorial wirkllich dankbar.

Softwaretechnisch würde ich gerne bei Debian Lemp postfix roundcube und nextcloud bleiben. Für gute Vorschläge aber auch immer offen.

Mit freundlichen Grüßen
 
Subdomains werden wie Domains behandelt.
Irgendwo in deinem conf.d-Ordner (normalerweise in sites-enabled) hast du eine Config für deine Haupt-Domain, und nach dem gleichem Prinzip baust du jeweils eine für die ganzen Subdomains.

Wenn du auf dem Server Certbot laufen hast und ein Zertifikat für die Subdomain erstellst fragt dich der Bot auch schon direkt ob du HTTP zu HTTPS redirecten willst.

So ne grundlegende Config sieht dann so aus
NGINX:
server {
    server_name subdomain.example.com;
 
    # andere includes und optionen und location blöcke

    error_log  /var/log/nginx/...;
    access_log /var/log/nginx/...;

    listen [::]:443 ssl http2; # managed by Certbot
    listen 443 ssl http2; # managed by Certbot

    ssl_certificate /etc/letsencrypt/live/...; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/...; # managed by Certbot
}

server {
    if ($host = subdomain.example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    listen 80;
    listen [::]:80;

    server_name subdomain.example.com;
    return 404; # managed by Certbot
}


Reverse Proxy brauchst du eigentlich nur wenn du Container benutzt.
Container sind (meist) nur innerhalb des Rechners erreichbar, damit diese Container von extern erreichbar sind benutzt man reverse Proxies (neben Nginx gibt es noch Traefik oder Caddy, aber ist das gleiche Prinzip).

Ein Nextcloud-Container läuft intern z.B. auf Port 1337, aber damit der aus dem Internet erreichbar ist musst du einen reverse Proxy haben der den internen 1337 Port auf den externen 443 (bzw. 80 für HTTP) umleitet.

NGINX:
    location / {
        proxy_pass http://127.0.0.1:1337;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

Das ist die ganze Magie von reverse Proxies in Nginx, SSL wird dann ganz normal per Nginx (bzw. Certbot) gemacht.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Malaclypse17 und TSKNF
Vielen Dank für die Bestätigung. Ich habe viele Stunden hinter mir und ich möchte einfach nur nicht Leute belästigen nur weil ich zu Faul bin mich damit auseinander zu setzen. Ausserdem macht es viel mehr Spaß wenn man es versteht.

Bei den Proxys habe ich auf den ersten Blick nicht verstanden wo man den Proxy verlinkt. Dann kämmen natürlich direkt die Ports noch dazu und das hat mich wieder sehr verunsichert.

Wie gesagt, eigentlich ist das alles noch recht neu für mich.

Aber das es so funktionieren kann, wie ich mir das wünsche, ist erstmal schön zu wissen.

Morgen schaue ich Mal weiter.

Mfg
 
Für die Installation von Nextcloud kann ich dir auch den Blog von Carsten Rieger sehr empfehlen.
https://www.c-rieger.de/nextcloud-installationsanleitung/

Dort erklärt er was er wo macht inklusive der Konfigurationsdateien für nginx & co. Fallst du noch zu Nginx Literatur brauchst, kann ich was beisteuern :).
 
Richtig, Reverse Proxy ist das korrekte Stichwort.

Joshinator schrieb:
Reverse Proxy brauchst du eigentlich nur wenn du Container benutzt.
Das braucht man immer sobald man mehr als einen Webserver hinter einer öffentlichen IP stehen haben will... egal wie die Webserver selbst dann angelegt sind.

TSKNF schrieb:
Morgen schaue ich Mal weiter.
Die erste relevante Frage wäre erstmal - willst du alle diese Systeme auf demselben Server installiert haben, oder verteilst du das auf verschiedene VMs?

Je mehr du auf dasselbe System packst, desto höher die Chance, das ein 'oops' Moment alles mit in den Tod reißt, so meine Meinung...


Hier ist z.B. eine Anleitung wie man zumindest Grundfunktion in kürzester Zeit herstellen kann indem man den nginx reverse Proxy per Docker installiert:
https://apfelcast.com/nginx-proxy-manager-reverse-proxy-mit-grafischer-oberflaeche-gui/
(Bei Apfelcast fehlt allerdings immer der Feinschliff, den muss man sich im Anschluss in Eigeninitiative aneignen oder schauen ob es einen Teil 2 des Videos für seine Patreons gibt...)
 
Ich habe versucht eine gutes Tutorial zu finden. Um mein Problem so einfach wie möglich zu halten, habe ich mich dazu entschlossen, im ersten Schritt einfach nur webmin in die Domain unter webmin.Domain.Com einzubinden. Es läuft nur die nextcloud.conf (weil ich schreibfaul bin heisst sie im System einfach nur cloud. ist das ein Problem?) in /etc/nginx/sites-enabled/. Und die läuft ohne Probleme. unter domain.com ist die Nextcloud erreichbar. Es wird direkt auf https umgeleitet. Das wird sicher wegen der ssl verschlüsselung sein.

Die nextcloud.conf habe ich von hier.
Code:
upstream php-handler {
    #server 127.0.0.1:9000;
    server unix:/var/run/php/php7.4-fpm.sock;
}

server {
    listen 80;
    listen [::]:80;
    server_name cloud.hakase-labs.io;
    # enforce https
    return 301 https://$server_name:443$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name cloud.hakase-labs.io;

    # Use Mozilla's guidelines for SSL/TLS settings
    # https://mozilla.github.io/server-side-tls/ssl-config-generator/
    # NOTE: some settings below might be redundant
    ssl_certificate /etc/letsencrypt/live/cloud.hakase-labs.io/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/cloud.hakase-labs.io/privkey.pem;

    # 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/nextcloud;

    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 512M;
    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)$ {
        try_files $uri /index.php$request_uri;
        # Optional: Don't log access to other assets
        access_log off;
    }
}
Als einfachstes, dachte ich mir, wird es wohl sein, webmin einzubinden. Durch den Port 10000 tat es sich hervor aber ich bin mir recht sicher das es falsch ist. Also das ich es sicher falsch Verstanden habe.

Dieses Tutorial konnte mir bes jetzt am Besten helfen. Die dort verlinkte reverse-proxy.conf hat mir sehr geholfen. Mit dem einfachen aufbau kann ich etwas erreichen.
Code:
map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

server {
  listen 80;
  server_name subdomain.example.com;
  return 301 https://$host$request_uri;
}

# SSL configuration
server {
  listen 443 ssl;
  server_name subdomain.example.com;
  ssl_certificate      /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key  /etc/letsencrypt/live/example.com/privkey.pem;

  # Improve HTTPS performance with session resumption
  ssl_session_cache shared:SSL:10m;
  ssl_session_timeout 5m;

  # Enable server-side protection against BEAST attacks
  ssl_prefer_server_ciphers on;
  ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;

  # Disable SSLv3
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

  # Diffie-Hellman parameter for DHE ciphersuites
  ssl_dhparam /etc/ssl/certs/dhparam.pem;

  # Enable HSTS (https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security)
  add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";

  # Enable OCSP stapling (http://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox)
  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
  resolver 8.8.8.8 8.8.4.4 valid=300s;
  resolver_timeout 5s;

  location / {
    proxy_pass http://webmail.domain.com:10000;
    proxy_set_header Host $host;
    proxy_redirect http:// https://;
    proxy_http_version 1.1;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
  }
}

Ich habe dann nach diesem Vorbild eine webmin.conf (einfach nur webmin) angelegt. den Resolver habe ich auf 127.0.0.1 gesetzt. als proxy_pass habe http://webmail.domain.com:10000 gesetzt.

Wenn beide Conf Dateien online sind, ist die nextcloud.conf dominanter. Also auch beim Aufrufen der webmin.domain.com wird man auf die domain.com nextcloud umgeleitet.

Ist die nextcloud.conf deaktiviert, funktioniert webmin.domain.com fast gut. es erscheint eine Meldung das der Server im SSL Modus ist und das man die die Domain https//webmin.domain.com:10000 aufrufen soll (während man selbst auf: https//webmin.domain.com ist). klickt man auf den Link geht es.

Das sind jetzt die beiden Baustellen:

Wie sorge ich dafür, das beide Seiten wie gewünscht aufrufbar sind und wie beseitige ich die Fehlermeldung in der Webmin Weiterleitung. Also das ich auch wirklich am richtigen Port ankomme.

Danach werde ich versuchen Netdata einzubinden. Ich weiß noch nicht wie ich dann in diesem Fall einen Port angeben kann. Wie ich Netdata einen Port zuweise bzw.
 
Zurück
Oben