ISPConfig mit nginx und NextCloud (Hub 9)

P

pilgrims

Member
Hallo,

ich habe mich seit Wochen festgebissen und komme einfach nicht weiter... Bisher habe ich NextCloud mit ISPConfig+apache2 ohne Probleme hinbekommen. Aber nun hatte ich die tolle Idee, mal auf nginx umzusteigen. Da kenne ich mich noch nicht aus und taste mich Stück für Stück ran.

Also einen Test-Server (Debian 12.8) installiert mit
Code: 
wget -O - https://get.ispconfig.org | sh -s -- --use-ftp-ports=40110-40210 --use-nginx --unattended-upgrades=autoclean,reboot --no-mail --no-mailman --no-roundcube --monit --monit-alert-email=xxxxx@xxxx.xxxt --use-php=8.2,8.3 --no-dns

Webserver angelegt. Läuft. NextCloud Hub 9 (30.0.4.1) installiert und dann angefangen die passenden Direktiven zu finden, um DEN Muster-Weg zu dokumentieren.
Aber ich komme mit den Direktiven nicht weiter.

Egal, was ich auch versuche, um den möglichen Fehler einzukreisen, ich komme nicht drauf, was anzupassen ist. Ausgangspunkt ist die Aktuelle nginx-Webserverkonfiguration auf help.nextcloud.com.
Da ich aber "nur" die Direktiven brauche und nicht die komplette Webserverkonfiguration, stecke ich nun fest, wie die Direktive so sein muss, damit ISPConfig sie verarbeiten kann.
Hat jemand einen Tipp für mich?

Ich habe verschiedene Varianten durchgeführt (mit ##subroot /nextcloud ## root-Directory geändert und überall in der Direktive die Verzeichnisangabe entfernt), aber ich komme nicht weiter.

So sieht meine aktuelle nginx-Direktive aus, die aber von ISPConfig nicht genommen wird und eine *.vhost.err produziert:

Code: 
location ^~ /nextcloud {
    # set max upload size and increase upload timeout:
    client_max_body_size 800M;
    client_body_timeout 1800s;
    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 text/javascript application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/wasm 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;

    # The settings allows you to optimize the HTTP2 bandwidth.
    # See https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/
    # for tuning hints
   
    client_body_buffer_size 512k;
   
    # HTTP response headers borrowed from Nextcloud .htaccess
    add_header Referrer-Policy                   "no-referrer"       always;
    add_header X-Content-Type-Options            "nosniff"           always;
    add_header X-Frame-Options                   "SAMEORIGIN"        always;
    add_header X-Permitted-Cross-Domain-Policies "none"              always;
    add_header X-Robots-Tag                      "noindex, nofollow" 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;
   
    # Set .mjs and .wasm MIME types
    include mime.types;
    types {
         text/javascript js mjs;
         application/wasm wasm;
    }
   
    # Rule borrowed from `.htaccess` to handle Microsoft DAV clients
    location = /nextcloud {
        if ( $http_user_agent ~ ^DavClnt ) {
            return 302 /nextcloud/remote.php/webdav/$is_args$args;
        }
    }

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

    # Make a regex exception for `/.well-known` so that clients can still
    # access it despite the existence of the regex rule
    # `location ~ /(\.|autotest|...)` which would otherwise handle requests
    # for `/.well-known`.
    location ^~ /.well-known {
        # The rules in this block are an adaptation of the rules
        # in `.htaccess` that concern `/.well-known`.

        location = /.well-known/carddav { return 301 /nextcloud/remote.php/dav/; }
        location = /.well-known/caldav  { return 301 /nextcloud/remote.php/dav/; }

        location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
        location /.well-known/pki-validation    { try_files $uri $uri/ =404; }

        # Let Nextcloud's API for `/.well-known` URIs handle all other
        # requests by passing them to the front-end controller.
        return 301 /nextcloud/index.php$request_uri;
    }


    # Rules borrowed from `.htaccess` to hide certain paths from clients
    location ~ ^/nextcloud/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/)  { return 404; }
    location ~ ^/nextcloud/(?:\.|autotest|occ|issue|indie|db_|console)                { return 404; }

   # Ensure this block, which passes PHP files to the PHP process, is above the blocks
    # which handle static assets (as seen below). If this block is not declared first,
    # then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
    # to the URI, resulting in a HTTP 500 error response.
    location ~ \.php(?:$|/) {
        # Required for legacy support
        rewrite ^/nextcloud/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|ocs-provider\/.+|.+\/richdocumentscode(_arm64)?\/proxy) /index.php$request_uri;

        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;

        fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
        fastcgi_param front_controller_active true;     # Enable pretty urls
        fastcgi_pass php-handler;

        fastcgi_intercept_errors on;
        fastcgi_request_buffering off;

        fastcgi_max_temp_file_size 0;
    }


    # Serve static files
    location ~ \.(?:css|js|mjs|svg|gif|ico|jpg|png|webp|wasm|tflite|map|ogg|flac)$ {
        try_files $uri /nextcloud/index.php$request_uri;
        # HTTP response headers borrowed from Nextcloud `.htaccess`
        add_header Cache-Control                     "public, max-age=15778463$asset_immutable";
        add_header Referrer-Policy                   "no-referrer"       always;
        add_header X-Content-Type-Options            "nosniff"           always;
        add_header X-Frame-Options                   "SAMEORIGIN"        always;
        add_header X-Permitted-Cross-Domain-Policies "none"              always;
        add_header X-Robots-Tag                      "noindex, nofollow" always;
        add_header X-XSS-Protection                  "1; mode=block"     always;
        access_log off;     # Optional: Don't log access to assets
    }

    location ~ \.(otf|woff2?)$ {
        try_files $uri /nextcloud/index.php$request_uri;
        expires 7d;         # Cache-Control policy borrowed from `.htaccess`
        access_log off;     # Optional: Don't log access to assets
    }

    # Rule borrowed from `.htaccess`
    location /nextcloud/remote {
        return 301 /nextcloud/remote.php$request_uri;
    }

    location /nextcloud {
        try_files $uri $uri/ /nextcloud/index.php$request_uri;
    }
}
 
P

pilgrims

Member
Mit dieser Direktive komme ich ein ordentliches Stück weiter, weicht aber von der Nextcloud-Anleitung ab und es gibt noch 2 Fehler (WebDAV und webfinger):

Code: 
##subroot /nextcloud ##


# set max upload size and increase upload timeout:
client_max_body_size 2G;
client_body_timeout 1800s;
fastcgi_buffers 64 4K;

location ~ \.php$ { ##delete##
}
location @php { ##delete##
}
location ~ /\. { ##delete##
}

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

# HTTP response headers borrowed from Nextcloud .htaccess
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                         "noindex, nofollow"          always;
add_header X-XSS-Protection                     "1; mode=block" always;
add_header Strict-Transport-Security            "max-age=15552000; includeSubDomains";

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

index index.php index.html /index.php$request_uri;

#location / {
#    rewrite ^ /index.php;
#}  

include mime.types;
types {
   text/javascript js mjs;
   application/wasm wasm;
}
   
# Rule borrowed from `.htaccess` to handle Microsoft DAV clients
location = / {
    if ( $http_user_agent ~ ^DavClnt ) {
        return 302 /nextcloud/remote.php/webdav/$is_args$args;
    }
}

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

# Make a regex exception for `/.well-known` so that clients can still
# access it despite the existence of the regex rule
# `location ~ /(\.|autotest|...)` which would otherwise handle requests
# for `/.well-known`.
location ^~ /.well-known {
    # The rules in this block are an adaptation of the rules
    # in `.htaccess` that concern `/.well-known`.

    location = /.well-known/carddav { return 301 /nextcloud/remote.php/dav/; }
    location = /.well-known/caldav  { return 301 /nextcloud/remote.php/dav/; }
   
    location = /.well-known/webfinger   { return 301 /index.php$uri; }
    location = /.well-known/nodeinfo   { return 301 /index.php$uri; }

    location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
    location /.well-known/pki-validation    { try_files $uri $uri/ =404; }

    # Let Nextcloud's API for `/.well-known` URIs handle all other
    # requests by passing them to the front-end controller.
    return 301 /index.php$request_uri;
}

# Rules borrowed from .htaccess to hide certain paths from clients
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/)  { return 404; }
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console)                { return 404; }

location ~ /\.(?!well-known)(?!file) {
    deny all;
}

# Ensure this block, which passes PHP files to the PHP process, is above the blocks
# which handle static assets (as seen below). If this block is not declared first,
# then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
# to the URI, resulting in a HTTP 500 error response.
location ~ \.php(?:$|/) {
        # Required for legacy support
        rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

  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;

    fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
    fastcgi_param front_controller_active true;     # Enable pretty urls
    {FASTCGIPASS}
    #fastcgi_pass php-handler;
    fastcgi_intercept_errors on;
    fastcgi_request_buffering off;
  fastcgi_read_timeout 1800s;
  fastcgi_connect_timeout 1800s;

    fastcgi_max_temp_file_size 0;
}

location ~ \.(?:css|js|svg|gif|png|jpg|ico|wasm|tflite|map)$ {
    try_files $uri /index.php$request_uri;
    add_header Cache-Control "public, max-age=15778463, immutable";
    access_log off;     # Optional: Don't log access to assets

    location ~ \.wasm$ {
        default_type application/wasm;
    }
}

location ~ \.woff2?$ {
    try_files $uri /index.php$request_uri;
    expires 7d;         # Cache-Control policy borrowed from `.htaccess`
    access_log off;     # Optional: Don't log access to assets
}

# Rule borrowed from .htaccess
location /remote {
    return 301 /nextcloud/remote.php$request_uri;
}

location / {
    try_files $uri $uri/ /index.php$request_uri;
}

Laut Mustervorlage von nextcloud.com wird folgendes noch genannt:

Code: 
# Set the `immutable` cache control options only for assets with a cache busting `v` argument
map $arg_v $asset_immutable {
    "" "";
    default ", immutable";
}


Aber dieser Teil wird von ISPConfig nicht akzeptiert/verarbeitet. Ich hatte es daher erst einmal weggelassen, weil das Wichtigste funktioniert. Nur die beiden ausstehenden Fehlermeldungen sorgen dafür, dass eine WebDAV-Verbindung nicht möglich ist.
Falls jemand eine Idee hat, was mir noch fehlt... :)
 
Zuletzt bearbeitet:
P

pilgrims

Member
Ich habe zum Vergleich einen neuen Test-Server mit apache2 und allen anderen aktuellen Paketen (PHP, Redis, ...) installiert. Ergebnis: alles hat im Grunde sofort funktioniert, ohne Fehlermeldungen.

Fazit:
Meine Recherchen, Anfragen und Versuche zeigen, NextCloud und nginx funktionieren in standardisierten Umgebungen nicht zusammen. NextCloud scheint oft nicht zu erkennen, dass benötigte Einstellungen durchgeführt und tatsächlich vorhanden sind.

Damit ist die Angelegenheit für mich bis auf Weiteres beendet.

Es hat viel Zeit gekostet, um dieses Ergebnis zu erhalten, aber so weiß ich jetzt, dass eine Migration meiner bestehenden NextCloud/apache2-Installationen nach NextCloud/nginx nicht erfolgen sollte.

Damit kann dieser Thread geschlossen werden.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Werbung

Top