Это старая версия документа.
Содержание
Существуют различные схемы построения веб-серверов для передачи данных по протоколу HTTP. Среди них достойное место по производительности занимают схемы с использованием «Nginx» в качестве внешнего (кэширующего, front-end) сервера. «Nginx» разработан для отдачи статических данных, при этом, он показывает высокое быстродействие и нагрузочную способность (см. Nginx vs Cherokee vs Apache vs Lighttpd), генерировать же динамическое содержимое он не способен. Поэтому, он часто применяется в связке с внутренним (back-end) сервером для обработки динамических данных которые потом отдаются «Nginx» как статические без участия внутреннего сервера. В качестве внутреннего сервера может применяться «Apache2» или, что и рассматривается в данной статье, «PHP-FPM».
Установка
Сервер «Nginx» поставляется в одноименном пакете «nginx» и его установка производится, например, командой в терминале
sudo apt-get install nginx nginx-extras
Установку же «PHP-FPM» можно произвести, например, командой
sudo apt-get install php5-cli php5-common php5-mysql php5-gd php5-fpm php5-cgi php5-fpm php-pear php5-mcrypt
Безопасность
Наряду с уязвимостями присущими ПО сервера, присутствуют также те, что обусловлены неосторожностью администратора сервера. Для их устранения следует соблюдать меры предосторожности:
- Должно быть запрещено выполнение PHP-кода из открытых для записи директорий. Например, директории для загрузки аватаров, файлов или директории доступные также FTP-серверу, который позволяет произвести запись в них.
- Следует следить за логами работы сервера, это позволяет выявить попытку взлома как можно раньше и минимизировать угрозу дальнейшего ущерба.
- Необходимо обновлять ПО (в том числе «CMS» — системы управления содержимым сайтов), но не обязательно тогда когда выходят новые версии (они тоже могут содержать новые уязвимости), а, прежде всего, тогда, когда обновление связано с устранением серьезной уязвимости.
- Обязательное наличие файлов для отката состояния сервера (в том числе, конфигурационных файлов).
- Осторожное и осмотрительное следование подобным инструкциям (см. Don’t trust the tutorials: check your configuration!)
Настройка
Настройка состоит из двух этапов — настройки «Nginx» и «PHP-FPM». Для начала необходимо остановить процессы (демоны) «Nginx» и «PHP-FPM», например, командами
sudo service nginx stop sudo service php5-fpm stop
Настройка PHP-FPM
Прежде всего, следует открыть файл «/etc/php5/fpm/php.ini» для редактирования, например, командой
sudo nano /etc/php5/fpm/php.ini
после чего, найти строчку содержащую «cgi.fix_pathinfo», которая по-умолчанию выглядит так (закомментирована)
;cgi.fix_pathinfo = 1
и привести её к виду
cgi.fix_pathinfo = 0
Это призвано устранить опасность неправильно трактования (и возникающей уязвимости) запросов вида «/image.gif/foo.php» (см. Don’t trust the tutorials: check your configuration!, Nginx 0day exploit for nginx + fastcgi PHP).
Если планируется загрузка больших файлов (важно для ownCloud версий < 8, в новой версии 8 и выше имеется отдельный файл для этих настроек), то можно увеличить максимальный объем загружаемых данных, например, до 200 МБ
post_max_size = 200M
и ниже
upload_max_filesize = 200M
Затем сохранить изменения в файле.
Далее, необходимо отрыть для редактирования файл «/etc/php5/fpm/pool.d/www.conf», например, командой
sudo nano /etc/php5/fpm/pool.d/www.conf
найти строчку с параметров «security.limit_extensions» и привести её к виду
security.limit_extensions = .php .php3 .php4 .php5
Эта настройка ограничит выполнение файлов по расширению имени. В этом же файле найти строчку с параметром «listen» и привести её к виду
listen = /var/run/php5-fpm.sock
Это определит файл для связи «Nginx» с «PHP-FPM» (сокет). В целях безопасности запрещаем какой-попало программе писать в сокет (см. Обновление PHP 5.5.12 с устранением уязвимости в PHP-FPM ) путём указания прав доступа к сокету. Находим строчки с описанием параметров «listen.owner», «listen.group» и «listen.mode» (по-умолчанию они закомментированы) и приводим их к виду
listen.owner = www-data listen.group = www-data listen.mode = 0660
Следует сохранить изменения в файле и перезапустить «PHP-FPM», например, командой
sudo service php5-fpm restart
Можно убедится в том, что права доступа к сокету установлены верно:
ls -la /var/run/php5-fpm.sock
Права доступа должны быть «srw-rw—-», владелец «www-data» (группа «www-data»), например,
srw-rw---- 1 www-data www-data 0 May 2 16:36 /var/run/php5-fpm.sock
Настройка Nginx
Основные настройки «Nginx» хранятся в файле «/etc/nginx/nginx.conf». Настройки базового сайта хранятся в файле «/etc/nginx/sites-available/default». Базовый конфигурационный файл сайта принято помещать в папку «/etc/nginx/sites-available/» и затем включить его путём добавления символической ссылки на этот файл в папке «/etc/nginx/sites-enabled/». Например, создадим конфигурационный файл для сайта с доменным именем (для примера выбрано «example.com») в названии для удобства
sudo touch /etc/nginx/sites-available/example.com sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
и откроем его для редактирования
sudo nano /etc/nginx/sites-available/example.com
Описывать конфигурацию сайта в одном файле не очень удобно, для увеличения читабельности конфигурационного файла и гибкости настройки можно воспользоваться директивой «include» позволяющей указать «Nginx», что следует загрузить другой конфигурационный файл и затем продолжить чтение текущего. Создадим в папке «/etc/nginx/» каталог «common», где будут хранится общие настройки для сайта, которые затем будут подгружаться из основного конфигурационного файла «/etc/nginx/sites-available/example.com» с помощью директивы «include»
sudo mkdir /etc/nginx/common
Некоторые запросы «Nginx» будет перенаправлять к «PHP-FPM», который в данном случае называется сервером выгрузки данных (upstream). Укажем как следует это делать. Создадим файл конфигурации с описанием серверов выгрузки данных
sudo touch /etc/nginx/common/upstream
и откроем его для редактирования
sudo nano /etc/nginx/common/upstream
и добавим в него строчки
upstream php-fpm { # PHP5-FPM сервер server unix:/var/run/php5-fpm.sock; }
где «php-fpm» – название для сервера выгрузки данных, для удобства.
Редактируем файл «/etc/nginx/sites-available/example.com». Добавляем строчку
include common/upstream;
для загрузки созданого выше конфигурационного файла. Как можно видеть – допускается указание относительного пути к файлу.
Далее описываем перенаправление от HTTP к HTTPS, если, конечно, это планируется. В таком случае необходимо наличие сертификатов для HTTPS (см. Сертификаты)
server { listen 80; server_name example.com www.example.com; return 301 https://$server_name$request_uri; }
иначе, можно опустить эти строчки.
Начинаем описывать конфигурацию сайта
server {
Сетевой порт для приема соединений: 80 — обычный HTTP; 443 — HTTPS (см. выше)
# Порты listen 80; listen 443 ssl; # использовать шифрование для этого порта
Корневая директория сайта работающего на данном сервере
root /var/www;
Возможные имена индексных файлов (их «Nginx» пытается открыть если он получил запрос вида «example.com/», вместо явного «example.com/index.html»)
index index.php index.html index.htm;
Имя сервера – обычно доменное имя Вашего сервера
server_name example.com www.example.com;
Настройка шифрования SSL
Необходимо наличие сертификата «*.crt» или «*.pem» и приватного секретного ключа «*.key» (см. Сертификаты). Самоподписанный сертификат можно сгенерировать командой в терминале (см. man openssl, man req)
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout example.com_nginx.key -out example.com_nginx.crt
При этом программа запросит данные, среди них «commmon name» — следует указать доменное имя сервера. Можно использовать шаблон, если необходимо учесть домены нижнего уровня, например, «*example.com». Иначе могут возникнуть проблемы с некоторыми программами, например, «davfs2» (см man davfs2.conf).
Но можно пойти дальше и воспользоваться сервисом «StartSSL» где выдают бесплатные сертификаты для личного пользования (см. startssl.com и Получение и установка бесплатного SSL-сертификата), но сам приватный ключ (который нельзя никому показывать) лучше сгенерировать самому, например, так
openssl genrsa -out example_nginx.com.key 4096
затем сформировать файл запроса на подпись (при этом прийдётся вводить те же данные что и для генерации самоподписанного сертификата, но это не важно, т.к. сервис «StartSSL» проигнорирует все кроме публичного ключа)
openssl req -new -sha256 -key example.com_nginx.key -out example.com.csr
открыть полученный файл текстовым редактором
nano example.com.csr
и скопировать его содержимое в текстовое поле на сайте «StartSSL» для запроса сертификата (см. ссылки на подробные инструкции выше). Файл *.csr больше не нужен. Затем загружаем подписанный сертификат (например, файл называется signed.crt) и объединяем его с сертификатом того кто этот сертификат подписал
wget https://www.startssl.com/certs/sub.class1.server.ca.pem cat signed.crt sub.class1.server.ca.pem > example.com_nginx.crt
Файл «signed.crt» можно удалить.
Копируем секретный ключ в системную папку и выставляем права доступа
sudo cp example.com_nginx.key /etc/ssl/private/ sudo chown www-data:www-data /etc/ssl/private/example.com_nginx.key sudo chmod 400 /etc/ssl/private/example.com_nginx.key
И в соседнюю папку сам сертификат
sudo cp example.com_nginx.crt /etc/ssl/certs/
Для пущей надежности можно сгенерировать ключ Диффи-Хеллмана (тоже секретный файл который очень долго генерируется)
openssl dhparam -out example.com.dh.key 4096 sudo cp example.com_nginx.dh.key /etc/ssl/private/ chown www-data:www-data example.com_nginx.dh.key chmod 400 example.com_nginx.dh.key
Продолжаем редактировать конфигурационные файлы.
Для удобства описываем настройки шифрования во внешнем файле «/etc/nginx/common/ssl»
sudo touch /etc/nginx/common/ssl
Редактируем файл «/etc/nginx/common/ssl»
sudo nano /etc/nginx/common/ssl
Файлы сертификатов для «HTTPS»
ssl_certificate /etc/ssl/certs/example.com_nginx.crt; # сертификат (можно свободно распространять) ssl_certificate_key /etc/ssl/private/example.com_nginx.key; # приватный ключ (секретный файл - НИКОМУ НЕ ПОКАЗЫВАТЬ)
Дополнительные параметры требуемые для «HTTPS»
ssl_dhparam /etc/ssl/private/example.com_nginx.dh.key; # писать эту строчку только если файл есть ssl_session_timeout 20m; # время 20 минут ssl_session_cache shared:SSL:20m; # размер кеша 20МБ ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK;
На этом настройки «SSL» в «Nginx» завершены, сохраняем и закрываем файл. После завершения описания конфигурации (см. ниже) можно будет проверить надежность сервисом «SSLLabs»
Продолжаем редактировать файл «/etc/nginx/sites-available/example.com». Подгружаем созданный выше конфигурационный файл с описанием настроек SSL
# Настройка шифрования SSL include common/ssl;
Различные настройки
Указание максимального размера запроса – необходимо если сервер будет использоваться для загрузки больших файлов (например, для построения небольшого облачного хранилища на основе «ownCloud», эта строчка по сути делает то же что и указанные выше при настройке «PHP-FPM», только теперь для «Nginx»)
client_max_body_size 200m; # увеличение максимального объема файла для загрузки до 200МБ
Ещё одна опция
# Buffers fastcgi_buffers 64 4K;
Настройки безопасности
Опишем настройки безопасности в отдельном файле
sudo touch /etc/nginx/common/security sudo nano /etc/nginx/common/security
И укажем в нём
add_header X-Frame-Options "SAMEORIGIN"; add_header X-Content-Type-Options "nosniff";
Сохраним и закроем файл, а затем подключим его строкой
include common/security;
Сжатие
Для экономии трафика лучше включить сжатие (иногда со влючённым сжатием могут возникать проблемы, например, у «ownCloud», см. ниже). Опишем настройки сжатия в отдельном файле
sudo touch /etc/nginx/common/gzip sudo nano /etc/nginx/common/gzip
и введём
gzip on; gzip_disable "msie6"; gzip_comp_level 6; gzip_min_length 1100; gzip_buffers 16 8k; gzip_proxied any; gzip_types text/plain application/xml text/css text/js text/xml application/x-javascript text/javascript application/javascript application/json application/xml+rss;
Следует сохранить, закрыть и затем подключить этот файл срочкой
include common/gzip;
Описание директорий сайта
Далее указание директорий сайта и правил работы с ними с использованием директив «location». Данная директива может обрабатывать регулярные выражения «Perl» (см. Регулярные выражения (шаблоны))
Корневая директория
location "/" { index index.php index.html index.htm; # варианты индексных файлов если имя файла в запросе не задано try_files $uri $uri/ =404; # проверить есть ли файл из запроса на диске, иначе - вернуть ошибку 404 }
К примеру, если хочется построить сайт на основе «WordPress», то можно описать корневую директорию так
location "/" { index index.php index.html index.htm; try_files $uri $uri/ /wordpress/; # проверяем существования файла или папки, иначе перенаправляем к example.com/wordpress rewrite "^/$" "/wordpress/" redirect; # перенаправляем запрос example.com/ к example.com/wordpress }
Соответственно сам сайт должен размещаться в каталоге «/var/www/wordpress/»
Некая директория «/var/www/restricted» доступная только авторизованным пользователям сервера. Создадим для неё файл конфигурации «/etc/nginx/common/locations/restricted»
sudo mkdir /etc/nginx/common/locations sudo touch /etc/nginx/common/locations/restricted sudo nano /etc/nginx/common/locations/restricted
со строчками
location ^~ "/restricted/" { auth_basic "Access to this forlder is restricted"; auth_basic_user_file htpasswd; autoindex on; allow all; try_files $uri $uri/ =404; }
Синтаксис «^~» указывает, что при совпадении регулярные выражения ниже проверятся не будут. Это необходимо, иначе возможно выполнение PHP-скриптов внутри этой папки без запроса пароля.
Этот конфигурационный файл подключим в «/etc/nginx/sites-available/example.com»
# Restricted include common/locations/restricted;
Для сайта на основе Wordpress
Для более полной информации по настройке «Nginx» для «WordPress» следует обратиться к официальной документации (см. codex.wordpress.org/Nginx и wiki.nginx.org/WordPress)
Натройки «Wordpress», который, в данном примере, находится в папке «/var/www/wordpress» будут описаны в файле «/etc/nginx/common/locations/wordpress»
sudo touch /etc/nginx/common/locations/wordpress sudo nano /etc/nginx/common/locations/wordpress
Ограничиваем доступ к секретной информации
location ~* "^/wordpress/(wp-config.php)((/.*)?)$" { deny all; return 404; }
Описываем директорию «example.com/wordpress»
location "/wordpress/" { index index.php; try_files $uri $uri/ @wordpress; # попробовать прочитать файл или папку # если не существует, то перенаправить запрос к WordPress }
где «@wordpress» – виртуальный путь, который используется для удобства и читабельности и описан ниже как
location @wordpress { # Перенаправление rewrite "^/wordpress/(.*)$" "/wordpress/index.php?q=$1" last; }
Подключаем этот конфигурационный файл строчкой
include common/locations/wordpress;
в файле «/etc/nginx/sites-available/example.com».
Для сайта на основе Dokuwiki
Ограничение доступа к базе данных и настройкам «Dokuwiki» (см. Web Access Security), который, к примеру, находится в папке «/var/www/dokuwiki»
location ~* "^/dokuwiki/(data|conf|bin|inc)((/.*)?)$" { deny all; # запретить все для всех return 404; # вернуть код ошибки index /dokuwiki/doku.php; # индексный файл }
Для сайта на основе MediaWiki
Ограничение доступа к файлам «MediaWiki» который, к примеру, находится в папке «/var/www/mediawiki»
location ~* "^/mediawiki/(cache|maintenance|includes|tests|serialized|extensions/Math/math|languages)((/.*)?)$" { deny all; # запретить все для всех return 404; # вернуть код ошибки }
Для сайта на основе SMF
Ограничение доступа к файлам «Simple Machines Forum», который, к примеру, находится в папке «/var/www/smf»
location ~* "^/smf/(cache|Packages|attachments)((/.*)?)$" { deny all; # запретить все для всех return 404; # вернуть код ошибки }
Для сайта на основе phpBB
Ограничение доступа к файлам «phpBB», который, к примеру, находится в папке «/var/www/phpbb»
location ~* "^/phpbb/(images/avatars/upload|files|cache|includes|store|config.php|common.php)((/.*)?)$" { deny all; # запретить все для всех return 404; # вернуть код ошибки }
Для сайта на основе Drupal
Настройки для сайта на основе «Drupal», который, к примеру, находится в папке «/var/www/drupal» и ограничение доступа к его файлам
location "/drupal/" { index /drupal/index.php; # индексный файл try_files $uri $uri/ =404; # проверить есть ли файл из запроса на диске, иначе - вернуть ошибку error_page 404 /drupal/index.php; # разрешить PHP сайту самому обрабатывать ошибку } location ~* "^/drupal/(.*\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)|(\..*|Entries.*|Repository|Root|Tag|Template))((/.*)?)$" { deny all; # запретить все для всех error_page 404 /drupal/index.php; # разрешить PHP сайту самому обрабатывать ошибку return 404; # вернуть код ошибки }
Для облачного хранилища на основе ownCloud
Для наиболее полной информации следует обратится к официальному руководству «OwnCloud» (см. Nginx Configuration). К примеру, «ownCloud» находится в папке «/var/www/owncloud».
Создадим файл настроек для «ownCloud» и отредактируем его
sudo touch /etc/nginx/common/locations/owncloud sudo nano /etc/nginx/common/locations/owncloud
Добавим строчки базовых настроек
location "/owncloud/" { index index.php index.html index.htm; try_files $uri $uri/ =404; error_page 403 /owncloud/core/templates/403.php; error_page 404 /owncloud/core/templates/404.php; }
И также строчки для ограничения доступа
location ~* "^/owncloud/(data|config|db_structure\.xml|README)((/.*)?)$" { deny all; error_page 403 /owncloud/core/templates/403.php; error_page 404 /owncloud/core/templates/404.php; return 404; }
Иначе пользователь может загрузить php-скрипт в «/owncloud/data/files/user/» и выполнить его вызвав «example.com/owncloud/data/user/files/foo.php».
Подключаем этот конфигурационный файл строчкой
include common/locations/owncloud;
в файле «/etc/nginx/sites-available/example.com».
Начиная с версии «ownCloud» 8 появился отдельный файл для переопределения некоторых настроек «PHP-FPM» взамен указанных в «/etc/php5/fpm/php.ini». Открыть его можно командой
sudo nano /var/www/owncloud/.user.ini
и в нем найти строчки
upload_max_filesize=513M post_max_size=513M
и поменять значения на требуемые.
Базовые ограничения доступа
Далее идет запрет доступа к определенным каталогам, подкаталогам и файлам сайта (или «CMS», на основе которых он построен). Опишем это в конфигурационном файле «/etc/nginx/common/locations/deny»
sudo touch /etc/nginx/common/locations/deny sudo nano /etc/nginx/common/locations/deny
# Ограничение доступа к разным файлам и папкам которые часто используются для хранения важной информации location ~* "/(engine|inc|data|conf|config|bin|info|install|module|profile|theme)((/.*)?)$" { deny all; return 404; } # Запрет доступа к .htaccess и .htpasswd файлам location ~* "/\.(htaccess|htpasswd)$" { deny all; # запретить все для всех return 404; # вернуть код ошибки }
Следует переписать все файлы «.htaccess» в директивы «Nginx». Найти эти файлы среди файлов сайта можно, например, командой
sudo find /var/www/ -name .htaccess
Подключаем этот конфигурационный файл строчкой
include common/locations/deny;
в файле «/etc/nginx/sites-available/example.com».
На этом описание директорий завершено
Перенаправление обработки php-скриптов внутреннему серверу «PHP-FPM»
Далее идет перенаправление обработки php-скриптов внутреннему серверу «PHP-FPM»
Добавляем в файл «/etc/nginx/sites-available/example.com» строчки, к примеру
# Направление PHP-скрипта для обработки FastCGI или PHP-FPM серверу location ~ "^(/index\.php|/info\.php|/(wordpress|owncloud)/.+?\.php)(/.*)?$" { # Решение проблемы с уязвимостью (см. http://forum.nginx.org/read.php?2,88845,page=3) # Не будет работать (ошибка 404) если файлы хранятся на другом сервере try_files $1 $uri $uri/ $uri/index.php?q=$uri&$args $uri/index.php =404;
где «$1» – отсылка к 1-й скобке регулярного выражения в директиве «location …» и т.д.
Создаём файл с описанием настроек перенаправления к «PHP-FPM»
sudo touch /etc/nginx/common/php-fpm sudo nano /etc/nginx/common/php-fpm
И в него добавляем строчки
# Настройки порта или сокета PHP-FPM производятся в файле "/etc/php5/fpm/pool.d/www.conf" fastcgi_pass php-fpm; # Порядок важен - строчка "include fastcgi_params" должна быть первой include fastcgi_params; fastcgi_split_path_info ^(.+?\.php)(/.*)?$; # Вместо переменной "$document_root" можно указать адрес к корневому каталогу сервера и это желательно (см. http://wiki.nginx.org/Pitfalls) fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name; # См. http://trac.nginx.org/nginx/ticket/321 set $path_info $fastcgi_path_info; fastcgi_param PATH_INFO $path_info; # Указание дополнительных переменных окружения PHP fastcgi_param SERVER_ADMIN admin@example.com; fastcgi_param SERVER_SIGNATURE nginx/$nginx_version; fastcgi_index index.php;
Сохраняем и закрываем файл, подключаем его строчкой
include common/php-fpm;
в файле «/etc/nginx/sites-available/example.com». Закрываем фигурные скобки директивы «location»
}
Доступ к Nagios через Nginx
Если на сервере используется система мониторинга «Nagios», то обеспечение работы её веб-интерфейса тоже можно возложить на «Nginx», точнее на связку «Nginx+PHP-FPM/FastCGIWrap». Установим дополнительное ПО «FastCGIWrap»
sudo apt-get install fcgiwrap
это позволит открывать «*.cgi» файлы.
Открываем описанный выше файл со списком серверов выгрузки данных (upstream)
sudo nano /etc/nginx/common/upstream
и добавим в него строчки
upstream fcgiwrap { # FastCGIWrap сервер server unix:/var/run/fcgiwrap.socket; }
Создаём файл с параметрами для «FastCGIWrap»
sudo touch /etc/nginx/common/fcgiwrap sudo nano /etc/nginx/common/fcgiwrap
где укажем
# Отключаем сжатие для быстродействия gzip off; # Стандартные параметры include fastcgi_params; # Доп. параметры fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name; fastcgi_param SERVER_ADMIN admin@example.com; fastcgi_param SERVER_SIGNATURE nginx/$nginx_version; # Направление запроса к upstream-серверу fastcgi_pass fcgiwrap;
Создаём файл с описанием настроек для «Nagios»
sudo touch /etc/nginx/common/locations/nagios
и откроем его для редактирования
sudo nano /etc/nginx/common/locations/nagios
И укажем необдимые параметры. В «Ubuntu» «Nagios» устанавливается в разные папки, «PHP»-файлы веб-интерфейса обычно находятся в «/usr/share/nagios3/htdocs/»
location "/nagios/" { index index.php index.html; try_files $uri $uri/ /nagios/index.php; alias "/usr/share/nagios3/htdocs/"; }
«CSS»-файлы для веб-инрфейса находятся в «/etc/nagios3/stylesheets/»
location ^~ "/nagios/stylesheets/" { alias "/etc/nagios3/stylesheets/"; } location ^~ "/nagios3/stylesheets/" { alias "/etc/nagios3/stylesheets/"; }
Картинки тоже прийдется описать отдельно
location ^~ "/nagios/images/" { alias "/usr/share/nagios3/htdocs/images/"; } location ^~ "/nagios3/images/" { alias "/usr/share/nagios3/htdocs/images/"; }
«JS»-скрипты
location ^~ "/nagios/js/" { alias "/usr/share/nagios3/htdocs/js/"; } location ^~ "/nagios3/js/" { alias "/usr/share/nagios3/htdocs/js/"; }
Перенаправление «PHP»-скриптов уже было описано выше, но тут требуется сделать дополнительные настройки, опишем все заново
location ~ "^/nagios/(.+?\.php)(/.*)?$" { # Папки nagios в /var/www нет, так что требуется сделать внутренне перенаправление в папку /usr/share/nagios3/htdocs/ root "/usr/share/nagios3/htdocs/"; # Проверка существования файла на диске # $1 - отсылка к первой скобке регулярного выражения в location # Если ничего не найдено, то открыть /nagios/index.php (можно поменять на =404) try_files $1 $uri $uri/ /nagios/index.php; # Собственно перенаправление rewrite "^/nagios/(.+?\.php)(/.*)?$" /$1$2 break; # Авторизация auth_basic "Authorization required to access Nagios"; auth_basic_user_file htpasswd; # Перенаправление запросов к PHP-FPM include common/php-fpm; }
Подобным образом описываем перенаправление запросов к «CGI»-сприптам серверу «FastCGIWarp»
location ~* ^/cgi-bin/nagios3/(.+?\.cgi)$ { root "/usr/lib/cgi-bin/nagios3"; try_files $1 $uri $uri/ =404; rewrite "^/cgi-bin/nagios3/(.+?\.cgi)$" /$1 break; auth_basic "Authorization required to access Nagios"; auth_basic_user_file htpasswd; # Передаём скрипту параметры аутентификации fastcgi_param AUTH_USER $remote_user; fastcgi_param REMOTE_USER $remote_user; include common/fcgiwrap; }
Сохраняем и закрываем файл.
А в файле «/etc/nginx/sites-available/example.com» дописываем
# Nagios include common/locations/nagios;
Выше были описаны параметры аутентификации для доступа к «Nagios», однако сам файл с пользователем и хеш-суммой от пароля хранится в неизвестном для «Nginx» файле «/etc/nagios3/htpasswd.users». Просто перенесём эти настройки в известный для «Nginx» файл «/etc/nginx/htpasswd», например, командой выполненной от корневого пользователя «root»
cat /etc/nagios3/htpasswd.users >> /etc/nginx/htpasswd
хотя, конечно, лучше это сделать вручную.
Кеширование
Сайт работает значительно лучше когда часть контента сохранена на стороне клиента с прошлого посещения сайта. Не все файлы можно кешировать. Поэтому описание кеширования производится в самом конце (т.е. эти настройки будут иметь наименьший приоритет и есть шанс что это не повлияет на правильную работу сайта). Создаём файл с параметрами для кеширования
sudo touch /etc/nginx/common/cache sudo nano /etc/nginx/common/cache
где укажем
location ~* ".+\.(?:ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|css|swf|js|atom|jpe?g|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$" { access_log off; log_not_found off; expires max; }
и указываем считывать этот файл строчкой в «/etc/nginx/sites-available/example.com»
include common/cache;
Завершение редактирования конфигурации
Закрываем фигурные скобки директивы «server» в «/etc/nginx/sites-available/example.com»
}
На этом правка файла «/etc/nginx/sites-available/example.com» завершена. Убедитесь в том, что все фигурные скобки «{ }» закрыты корректно и части файла верно вложены друг в друга («location» внутри «server» и т.п.).
Сохраняем все изменённые файлы.
Теперь можно перезапустить демоны
sudo service nginx restart sudo service php5-fpm restart
Ссылки
- Обсуждение статьи на форуме forum.ubuntu.ru
- Сравнение быстродействия и нагрузочной способности веб-серверов Nginx vs Cherokee vs Apache vs Lighttpd
- Рекомендации по безопасности при развертывании веб-сервера на основе «Nginx» и «PHP-FPM» Don’t trust the tutorials: check your configuration!
- Синтаксис конфигурации «Nginx» HttpCoreModule
- Пример настройки связки «Nginx + PHP-FastCGI» PHPFcgiExample
- Рекомендации по написанию удачной конфигурации для «Nginx» Pitfalls
- Работа с сертификатами в «Ubuntu» Сертификаты
- Рекомендации по обеспечению безопасности при работе с сайтом на основе «Dokuwiki» Web Access Security
- Рекомендации по обеспечению безопасности при настройке облачного хранилища на основе «ownCloud» Webserver Notes