📑 Конфигурация Nginx для Owncloud 8

С выходом восьмой версии распространенной системы OwnCloud — приватного, корпоративного облака, немного поменялся конфигурационный файл для nginx. В принципе можно работать и со старым, но будут вылезать ошибки. Разработчики рекомендуют следующую конфигурацию:

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/owncloud/;
  # set max upload size
  client_max_body_size 10G;
  fastcgi_buffers 64 4K;

  # 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 ^/caldav(.*)$ /remote.php/caldav$1 redirect;
  rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
  rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;

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

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

  location ~ ^/(?:\.htaccess|data|config|db_structure\.xml|README){
    deny all;
  }

  location / {
    # The following 2 rules are only needed with webfinger
    rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
    rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

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

    rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;

    try_files $uri $uri/ /index.php;
  }

  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_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;
  }
}

Здесь сразу дана конфигурация с HTTPS, так как разработчики (да и здравый смысл) настоятельно рекомендуют использовать именно его.

И немного о часто встречающихся ошибках.

Неправильно обрабатываются JavaScript (.js) или CSS (.css).

Наиболее часто встречающаяся ошибка, когда JavaScript (.js) или CSS (.css) неправильно обрабатываются nginx, что приводит к сообщениям 404 (File not found) или искаженному отображению на экране.

Это может быть вызвано тем, что блок:

location ~* \.(?:css|js)$ {

находится перед, а не после блока:

location ~ \.php(?:$|/) {

Если ошибка не пропадет, разработчики советуют убрать (запретить) кэширование JavaScript (.js) или CSS (.css) файлов или убрать сжатие их gzip в конфигурационном файле.

В логах появляются бессмысленные сообщения об ошибках

Иногда в логах сыпятся сообщения об ошибках, совсем не относящиеся к nginx, например:

client denied by server configuration: /var/www/data/htaccesstest.txt

Вместо того, чтобы исправить это, разработчики рекомендуют добавить в файл конфигурации запрет логирования:

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