by 0 comments on "nginx-Konfiguration: Owncloud im Unterordner des Webroot betreiben"

nginx-Konfiguration: Owncloud im Unterordner des Webroot betreiben

Update 17.06.2016: Mittlerweile ist eine offizielle Konfiguration für das Betreiben von Owncloud mit nginx in einem Unterordner verfügbar. In diese sind auch einige Verbesserungen eingeflossen (die in der Apache-Konfiguration schon länger enthalten waren), so dass ich empfehle diese Konfiguration anstatt meiner zu benutzen:
https://doc.owncloud.org/server/8.2/admin_manual/installation/nginx_owncloud_8x.html#owncloud-in-a-subdir-of-nginx

Es folgt der ursprüngliche Beitrag, der zu einem Zeitpunkt geschrieben wurde, als es die oben genannte offizielle Konfiguration noch nicht gab.

Will man neben Owncloud noch andere Webdienste auf seinem Server laufen lassen, ist es sinnvoll, Owncloud in einem Unterordner (subfolder, subdirectory) des Webroot zu betreiben. Für den Webserver nginx findet sich in der Owncloud-Dokumentation für diesen Fall nur der Hinweis, die Konfiguration entsprechend anzupassen. Da bei der Anpassung ein paar Stolpersteine lauern, lohnt es sich systematisch vorzugehen.

Update 11.03.2016: Diese Anleitung gilt für Owncloud 8.2, die weiterhin als Grundlage für eine aktualisierte Anleitung für Owncloud 9.0 gilt. Diese aktualisierte Anleitung ist hier zu finden:
nginx-Konfiguration: Owncloud 9.0 im Unterordner des Webroot betreiben

1. Grundlage

Als Grundlage dient die offizielle nginx-Konfiguration der Owncloud-Webseite für Owncloud 8.2:
https://doc.owncloud.org/server/8.2/admin_manual/installation/nginx_configuration.html

Alle Änderungen dieser Anleitung erfolgen nur im ssl-Server-Block – also unterhalb der Zeilen:

server {
  listen 443 ssl;

2. Anweisungen in einen eigenen Owncloud-Location-Block verschieben

Zunächst wird fast alles von der ssl-Serverkonfiguration in einen eigenen location-Block mit Unterblöcken verschoben, damit es nicht zu „Interferenzen“ mit location-Blöcken von anderen Webdiensten auf demselben Server kommt. Folgendes muss allerdings im Server-Kontext stehen bleiben und wird nicht verschoben:

  • grundlegende Servereinstellungen:
    listen 443 ssl;
server_name cloud.example.com;
ssl_certificate /etc/ssl/nginx/cloud.example.com.crt;
ssl_certificate_key /etc/ssl/nginx/cloud.example.com.key;
# Path to the root of your installation
root /var/www/owncloud/;


Beim Verschieben wird wie folgt vorgegangen:

Die Zeile:
location / {
wird umbenannt in:
location ^~ /owncloud/ {
In diesen location-Block werden alle oben nicht genannten Textblöcke aus dem server-Kontext verschoben.

Anmerkung: durch das eingefügte ^~ werden Seitenaufrufe auf den Owncloud-Unterordner etwas beschleunigt, denn nginx beginnt sofort mit der Bearbeitung der Anfrage und sucht nicht noch weiter nach Treffern mit regulären Ausdrücken:
http://nginx.org/en/docs/http/ngx_http_core_module.html#location

3. Pfadangaben an Unterordner anpassen

Diese Verzeichnisstruktur kommt zur Anwendung:
/var/www/ – das Root-Verzeichnis des Webservers.
/var/www/owncloud/ – der Ordner, in dem Owncloud liegt.

Folgende Pfade werden angepasst:

  • Das root-Verzeichnis: root /var/www/;
  • rewrite /.well-known/...-Weiterleitungen (4x):
    da diese URIs im root-Verzeichnis auffindbar sein müssen, wird nur beim Ziel der Weiterleitung ein /owncloud vorangestellt. Beispiel:rewrite ^/.well-known/carddav /owncloud/remote.php/carddav/ permanent;
  • Die Zeile: rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;
    wird zu : rewrite ^(/owncloud/core/doc/[^\/]+/)$ $1/index.html;
  • Jeder anderen Pfadangabe innerhalb von location ^~ /owncloud/ {...}wird ein /owncloud voran gestellt. Steht vor der Pfadangabe ein ^, dann wird /owncloud direkt danach (ohne Leerzeichen!) eingefügt.

Das Ergebnis sieht dann so aus:

upstream php-handler {
  server 127.0.0.1:9000;
  #server unix:/var/run/php5-fpm.sock;
}

server {
  listen 80;
  server_name cloud.example.com;
  # enforce https
  return 301 https://$server_name$request_uri;
}

server {
  listen 443 ssl;
  server_name cloud.example.com;

  ssl_certificate /etc/ssl/nginx/cloud.example.com.crt;
  ssl_certificate_key /etc/ssl/nginx/cloud.example.com.key;

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

  # Disable gzip to avoid the removal of the ETag header
  gzip off;

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

  rewrite ^/.well-known/carddav /owncloud/remote.php/carddav/ permanent;
  rewrite ^/.well-known/caldav /owncloud/remote.php/caldav/ permanent;

  # 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 /owncloud/public.php?service=host-meta last;
  #rewrite ^/.well-known/host-meta.json /owncloud/public.php?service=host-meta-json last;

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

  location ^~ /owncloud/ {

    # Add headers to serve security related headers
    add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;

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

    index index.php;
    error_page 403 /owncloud/core/templates/403.php;
    error_page 404 /owncloud/core/templates/404.php;

    rewrite ^/owncloud/remote/(.*) /owncloud/remote.php last;
    rewrite ^(/owncloud/core/doc/[^\/]+/)$ $1/index.html;

    try_files $uri $uri/ =404;

    location ~ ^/owncloud/(build|tests|config|lib|3rdparty|templates|data)/ {
      deny all;
    }

    location ~ ^/owncloud/(?:\.|autotest|occ|issue|indie|db_|console) {
      deny all;
    }

    location ~ \.php(?:$|/) {
      fastcgi_split_path_info ^(.+\.php)(/.+)$;
      include fastcgi_params;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      fastcgi_param PATH_INFO $fastcgi_path_info;
      fastcgi_param HTTPS on;
      fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice
      fastcgi_pass php-handler;
      fastcgi_intercept_errors on;
    }

    # Adding the cache control header for js and css files
    # Make sure it is BELOW the location ~ \.php(?:$|/) { block
    location ~* \.(?:css|js)$ {
      add_header Cache-Control "public, max-age=7200";
      # Add headers to serve security related headers
      add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
      add_header X-Content-Type-Options nosniff;
      add_header X-Frame-Options "SAMEORIGIN";
      add_header X-XSS-Protection "1; mode=block";
      add_header X-Robots-Tag none;
      # Optional: Don't log access to assets
      access_log off;
    }

    # Optional: Don't log access to other assets
    location ~* \.(?:jpg|jpeg|gif|bmp|ico|png|swf)$ {
      access_log off;
    }
  }
}

4. Servereinstellungen den eigenen Gegebenheiten anpassen

Die folgenden 4 Angaben müssen an die eigenen Servergegebenheiten angepasst werden:

server_name cloud.example.com;
ssl_certificate /etc/ssl/nginx/cloud.example.com.crt;
ssl_certificate_key /etc/ssl/nginx/cloud.example.com.key;
# Path to the root of your installation
root /var/www/;

Nachdem nginx mit nginx -s reload die Konfiguration neu eingelesen hat, müsste Owncloud im entsprechenden Unterverzeichnis aufgerufen werden können.

5. Hinweis: Vererbungssystem von nginx beachten

In einer nginx-Konfiguration werden Einträge an untergeordnete Ebenen vererbt (siehe https://blog.martinfjordvald.com/2012/08/understanding-the-nginx-configuration-inheritance-model/). Falls es neben dem Block location ^~ /owncloud/ {...} noch andere location-Blöcke (z.B. von anderen Webdiensten) gibt, sollten Einstellungen daher am Besten in der höchstmöglichen Ebene vorgenommen werden, um Dopplungen zu vermeiden. Eine Erklärung dazu findet sich auch unter: https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#multiple-index-directives

Achtung: Arrays werden nur dann vom übergeordneten Level weitervererbt, wenn keine Direktiven im aktuellen Level definiert sind (betrifft hier add_header und fastcgi_param) – daher gibt es die add_header-Dopplungen:

  • unter location /owncloud/
  • und im untergordneten location ~* \.(?:css|js)$) mit einer zusätzlichen Angabe bezüglich Caching.

6. Optional: letzte kosmetische Maßnahmen

Um das ganze etwas weiter zu verschlanken, könnten diese beiden Zeilen:

include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

ersetzt werden durch:

include fastcgi.conf;

Details hierzu finden sich im Blog des nginx Entwicklers Martin Fjordvald:
https://blog.martinfjordvald.com/2013/04/nginx-config-history-fastcgi_params-versus-fastcgi-conf/

Außerdem könnten diese add_header-Direktiven:

# Add headers to serve security related headers
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;

in eine externe Datei (z.B. mit dem Namen add_header.conf) auslagert und dann an den erforderlichen Stellen (2x) per include eingebunden werden. Man müsste dann allerdings darauf achten, dass im Block
location ~* \.(?:css|js)$
zusätzlich zu dem neuen
include add_header.conf;
auch diese Zeile enthalten sein sollte:
add_header Cache-Control "public, max-age=7200";

Diese letzten beiden Maßnahmen bringen – abgesehen von eventuell mehr Übersichtlichkeit – keine weiteren Vorteile mit sich.

7. Fazit

Mit dieser Anleitung sollte die Umstellung von Owncloud in einen Unterordner auch ohne tiefergehendes nginx-Wissen möglich sein. Wer sich weiter in nginx einarbeiten möchte, findet in der offiziellen Dokumentation eine gute erste Anlaufstelle: http://nginx.org/en/docs/

Schreibe einen Kommentar

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

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.