Php nginx

FPM

SAPI, он же Server API. В php есть несколько таких API для разных вариантов его работы:

  • CLI SAPI — в качестве консольной команды `php` для запуска наших кронов и других cli-программ (Command Line Interface)

  • apxs2 SAPI — в качестве модуля к apache2

  • CGI SAPI — в качестве запускаемого на каждом запросе CGI (сейчас так почти никто не делает)

  • FPM SAPI — Fast Process Manager написанный для PHP разработчиками из комании Badoo и теперь поддерживаемый сообществом

Работа с FPM отличается от работы с Apache в первую очередь тем, что FPM — это только PHP. Это не веб-сервер, не что-то умное. Это наоборот — максимально простой, легкий и быстрый менеджер процессов для PHP. В отличие от апача он даже не используется http-протокол, а работает со специальным fastcgi-протоколом. В первую очередь FPM быстрее обрабатывает запросы благодаря его легковесности и простоте.


Во вторую очередь FPM действительно умный менеджер процессов. Он контролирует количество работающих PHP-процессов, частоту их перезапуска для борьбы с утечками памяти (да, модули php как и всегда текут) и прочие простые вещи, необходимые для контроля сервера.

Нужно помнить, что независимо от того, какое SAPI вы используете, будь то модуль Apache, CGI или PHP-FPM — это не отнимает ни каких особенностей php. А первая его особенность:

  • Один процесс одновременно обрабатывает один запрос. Это абсолютно так же свойственно для PHP-FPM, как и для Apache.

  • Количество процессов определяет сколько одновременно может «висеть» запросов в обработке.

  • Точно также, как и Apache, FPM подвержен DoS-атакам путем «длительных запросов». Допустим у Вас на сервере работает не более 50и процессов PHP-FPM, а это значит, что если 50 пользователей одновременно начнут делать upload файла (пусть даже небольшого, но главное чтобы они делали это медленно) — пятьдесят первый пользователь получит ошибку 504, т.к. FPM не возьмет его запрос на обработку, пока не разберется с теми что у него уже есть.

NGINX

Nginx — это разработанный Игорем Сысоевым http-proxy-сервер (он сам чаще называет его proxy-сервером, чем web-сервером). Это и есть его основное отличие от Apache (обычно к nginx приходят те кто испытывает проблемы с Apache). Благодаря тому что Nginx, сам не выполняет никакой тяжелой работы — Игорь смог заложить в него прекрасную асинхронную событийную архитектуру.


Благодаря этой архитектуре nginx на порядки быстрее обрабатывает запросы, чем любой другой сервер и благодаря ей же потребляет при этом сильно меньше ресурсов. Как это происходит?

Один рабочий процесс nginx — обрабатывает не один запрос пользователя (как apache), а тысячи этих запросов. Ввиду того, что nginx — это proxy-сервер, для него не составляет никакого труда получить запрос пользователя, отправить его на backend (например php-fpm), а пока бакенд занят трудом — обрабатывать остальные запросы пользователей, когда FPM ответит Nginx-у о том что тот самый первый запрос обработан и отдаст ответ, nginx передаст ответ назад пользователю.

Nginx работает как конвеер — он просто быстро перекладывает запросы и ответы между backend и пользователями.

В эту схему отлично вписалась асинхронная работа со статическими файлами. Благодаря тому что в современном мире с файлами можно работать почти так же асинхронно, как и с backend — Nginx отлично разделяет работу на две части — статику отдает с диска, динамику обрабатывает в PHP-FPM.

В чем выигрыш?

Возьмем тот же Apache (prefork или itk). Мы выставили у него максимальное количество рабочих процессов равное 35. Что это значит? Это значит что мы сможем одновременно обработать только 35 запросов пользователей и это не важно — запрос это за статикой или за динамикой. 35 всего.


У вас на странице 100 картинок+js+css-ок? Значит большая их часть будет висеть в очереди внутри сервера Apache и ждать когда пользователь получит предыдущие 35 ответов. 

В случае с Nginx + PHP-FPM важнее всего количество процессов PHP-FPM. Мы можем поставить его таким же равным тридцати пяти. Что это значит? Это значит что мы можем одновременно обрабатывать 35 запросов к динамике, запросы же к статике nginx разгребет своими силами в количестве 3000+ одновременных почти на любой слабой VPS.

Расход оперативной памяти при использовании Nginx+PHP-FPM меньше чем на «голом» Apache, при равном количестве процессов (FPM и Apache). Скорость обработки запросов выше.

На расход CPU внутри PHP замена Apache на FPM никак не скажется. CPU в первую очередь кушает Ваш PHP-код, а пока его никто не оптимизирует — работать быстрее и экономичнее он не начнет.

Итог

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

  • Появляется возможность перелопачивать тонны запросов за статикой, которой нет в Apache.

  • Вы экономите оперативную память, что сказывается на цене оборудования или VPS.

  • Появляется море приятного функционала самого Nginx.

  • Пропадает возможность использовать htaccess, но честно скажу — конфигурация nginx куда более простая и понятная, чем htaccess.


perfect-inc.com

Здравствуй, уважаемый пользователь Хабрахабра. Мое повествование будет о том, как подготовить почву для локальной веб-разработки проектов в операционной системе Ubuntu 16.04.1 LTS.

В данной статье хочется развеять и разъяснить возможные трудности связанные с установкой и настройкой ПО, которое требуется для современной веб-разработки, с которыми возможно сталкиваются начинающие разработчики и не только.

Технологии которые будут использованы в статье: nginx, php-fpm.

Перед началом повествования, хочу отметить, что я проделывал все эти действия на «голой» системе.
Я буду работать с пакетным менеджером aptitude. Так же рекомендую обновить индекс пакетов и сами пакеты перед установкой ПО. В статье мы проделаем эти действия вместе.

Поехали!

Установка пакетного менеджера aptitude, обновление индекса и пакетов

Устанавливаем:

sudo apt install aptitude

Обновляем индекс.

sudo aptitude update

Обновляем пакеты (команда обновит все пакеты, для которых есть новые версии, если потребуется удаление пакетов, то оно будет выполнено).

sudo aptitude full-upgrade

Установка и настройка nginx (версия >= 1.10.0)

Устанавливаем.

sudo aptitude install nginx     

Запускаем.

sudo service nginx start

Проверяем версию, чтобы убедиться что не установили старую, то есть ниже 1.10.0.

nginx -v

Php nginx

Установку и запуск произвели, теперь пойдем в каталог туда куда установлен наш nginx и посмотрим на его структуру. Каталог nginx находится по такому пути:

cd /etc/nginx/

Посмотреть содержимое директории можно командой ls, с флагами -la будет удобнее просматривать содержимое каталога (в действительности эту команду с конкретными флагами можно описать детальнее и вернее, но у нас сегодня другая тема).

ls -la 

Наc интересуют в данный момент два каталога, которые вы видите на скриншоте. Это каталоги sites-available и sites-enabled.

Php nginx

Давайте перейдем в каталог sites-available и начнем конфигурировать наш виртуальный хост (сайт).

cd /etc/nginx/sites-available

Перед началом создания конфигурационного файла, проверим что лежит у нас в данном каталоге. В моей случае каталог не пустой, в нем уже есть конфигурационные файлы, я их затер, чтобы не вводить вас в заблуждение.

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

ls -la    

Php nginx

Создадим свой конфигурационный файл, который будет соответствовать названию домена нашего локального сайта (или реального, если уже знаете его название). Это удобно, в будущем, когда будет много конфигурационных файлов, то это избавит вас от путаницы в них. У меня этот файл будет называться project.local.

sudo touch project.local

Посмотрим что получилось.

Php nginx

Теперь откроем его в редакторе, я открою его в nano.

sudo nano project.local

Видим что он у нас пустой. Теперь перейдем к формированию нашего файла. Нужно привести конфигурацию к такому виду, как написано ниже. Я опишу только жизненно важные директивы этого файла, описывать остальное не буду, так как это не является на данный момент важным, все-таки у нас тема базовой настройки. Этих настроек с «горкой» хватит для разработки проектов локально, не только мелких, но и довольно крупных. В следующих статьях опишу отдельно каждые использованные директивы (именно так называются строки, например server_name) этого файла.

Смотрите комментарии прям в конфигурационном файле.

   
server { listen 80; # порт, прослушивающий nginx server_name project.local; # доменное имя, относящиеся к текущему виртуальному хосту root /home/stavanger/code/project.local; # каталог в котором лежит проект, путь к точке входа index index.php; # add_header Access-Control-Allow-Origin *; # serve static files directly location ~* .(jpg|jpeg|gif|css|png|js|ico|html)$ { access_log off; expires max; log_not_found off; } location / { # add_header Access-Control-Allow-Origin *; try_files $uri $uri/ /index.php?$query_string; } location ~* .php$ { try_files $uri = 404; fastcgi_split_path_info ^(.+.php)(/.+)$; fastcgi_pass unix:/var/run/php/php7.0-fpm.sock; # подключаем сокет php-fpm fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~ /.ht { deny all; } }

Сохраняем файл. Теперь нам надо проверить, нет ли в нем ошибок. Сделать мы это можем командой.

sudo nginx -t

Если видим такую информацию как на скриншоте, значит у нас все верно, может продолжать настройку. Если вы получаете какие-либо ошибки, стоит перепроверить конфигурационный файл.

Php nginx

Теперь нам надо активировать конфигурационный файл, в каталоге /etc/nginx/sites-enabled/ необходимо создать симлинк (символическая ссылка). Если у вас nginx был установлен «с нуля», то в этом каталоге есть симлинк на файл default, про который рассказывалось выше, его можно удалить, если он вам не требуется. Переходим в нужный каталог.

cd /etc/nginx/sites-enabled/    

Теперь мы в нужном каталоге. Давайте создадим наш симлинк. Для создания используется команда ln с флагом -s, далее мы укажем путь до нашего конфига project.local.

sudo ln -s /etc/nginx/sites-available/project.local

Посмотрим на наш созданный симлинк.

Php nginx

Чтобы убедиться что мы делаем еще все верно опять запустим команду.

sudo nginx -t

Если все ок, едем дальше.

Файл hosts

Этот файл находится по пути /etc/hosts. Наличие в нем записей, позволяет запускать nginx с использованием в качестве домена localhost. В этом файле можно присваивать альтернативные псевдонимы, например для нашего проекта project.local, мы присвоим домен project.local.

Открываем файл в редакторе nano.

sudo nano /etc/hosts

У вас в этом файле будет и другая информация, просто игнорируйте ее. Вам всего лишь нужно добавить строку как на моем скриншоте.

Php nginx

Не забываем сохранить файл. На этом настройка файла hosts закончена.

Установка php-fpm (>=7.0)

sudo aptitude install php-fpm    

Проверяем установленную версию, на всякий случай, хотя в Ubuntu 16.04.1 в репозиториях лежит именно 7.0 версия.

php-fpm7.0 -v

Php nginx

Убеждаемся что все ок. Стартуем php-fpm.

sudo service php7.0-fpm start

Если будете править конфиги, то не забывайте рестартовать демон. Это делает так. Но нам это не потребуется.

sudo service php7.0-fpm restart

На этом установка и настройка php-fpm закончена. Правда, это все. Это не магия, путь до сокета php-fpm у нас уже был прописан в конфигурационном файле. Конечно, вам могут понадобиться какие-либо расширения php для разработки личных проектов, но их вы можете поставить по мере того как они будут требоваться.

Теперь пойдем для в каталог с нашим проектом, у меня он лежит по такому пути.

cd /home/stavanger/code/project.local

Поднимемся на каталог выше и сделаем права 777 (то есть мы будем делать полные права каталогу с нашим проектом project.local). В будущем это избавим нас от лишних проблем.

cd .. sudo chmod -R 777 project.local    

На этом настройка ПО завершена, давайте создадим тестовый файл в нашем рабочем каталоге project.local и убедимся что все работает. Я создам файл index.php с таким содержанием.

<?php  echo "Hello Habrahabr!";

Идем в браузер и видим что у нас все прекрасно работает! Интерпретатор php в том числе.

Php nginx

С уважением к читателям, Stavanger.

habr.com

Классической связкой для работы сайтов написанных на php считается apache + mod_php. Так как mod_php по умолчанию требует prefork_mpm, то apache для обработки каждого отдельного соединения создает отдельный процесс, что сильно не экономно с точки зрения расходования оперативной памяти.

Потом появился nginx — легковесный проксирующий веб-сервер и его начали ставить перед apache чтобы он занимался выдачей статики и не беспокоил apache по мелочам. Следующим логичным шагом является выключение из цепочки nginx — apache — php посредника в лице apache, чем мы и займемся.

php-fpm позволяет демонизировать php дабы избежать затрат на запуск процессов (чем страдает CGI) что умеет и FastCGI. Но php-fpm дает также другие полезные возможности:

  • запуск пулов обработчиков от имени заданных пользователей,
  • динамическое управление количеством запущенных обработчиков,
  • возможность перезапуска обработчиков в случае, если с ними что-то не так,
  • ведение лога медленных запросов по аналогии с mysql,
  • страницы статуса и пинга,
  • прочее.

Установка php-fpm в Debian крайне проста:

aptitude install php5-fpm

После чего можно править два конфигурационных файла, которые достаточно хорошо документированы сами по себе, но большое количество слов может также мешать найти за ними суть. Первый (/etc/php5/fpm/php-fpm.conf) позволяет задать общие настройки:

include — из какой директории инклудить дополнительные конфиги,
pid — путь до файла с идентификатором процесса,
error_log — путь до лога ошибок,
syslog.facility — позволяет указать в какой лог писать,
syslog.ident — каким именем помечать записи в системном логе,
log_level — уровень лога от алерта до дебага,

В принципе указанные выше параметры можно оставить по умолчанию, если не требуется дебаг, к примеру. Дальше более интересные параметры:

emergency_restart_threshold — позволяет задать при каком количестве вылетов процессов с сигналами SIGSEGV или SIGBUS за указанный промежуток времени необходимо мягко перезапустить php-fpm,
emergency_restart_interval — заданный промежуток времени.
process_control_timeout — как долго потомкам ждать от мастера реакции на сигналы,
process.max — максимальное количество процессов для всех пулов,
process.priority — можно указать приоритет мастер-процесса,
daemonize — демонизировать или нет. Может пригодиться для дебага,
rlimit_files — количество доступных для мастер-процесса файловых дескрипторов,
rlimit_core — не осознал,
events.mechanism — в linux однозначно epoll,
systemd_interval — если ваша ос использует systemd, то можно задать периодичность отчетов о состоянии процессов. Будет актуально в Debian 8.

Второй конфиг является базовым для настройки пулов и находится по пути /etc/php5/fpm/pool.d/www.conf. В этом файле можно задать еще больше параметров и все они хорошо документированы в нем. Мы же удалим или переименуем этот файл и создадим свой конфигурационный файл.

Интересно, что в конфиге пула можно использовать имя пула в виде переменной $pool. За счет этого можно создать унифицированный конфигурационный файл и использовать его в качестве основы для новых пулов. Имя пула задается в квадратный скобках и предваряет собой блок параметров. Фактически все пулы можно описать в одном файле, но, кажется, так делать не стоит. Пример конфигурационного файла:

[webpanels]
prefix = /var/www/$pool

user = $pool
group = $pool

listen = /var/run/phpfpm-$pool.sock
listen.owner = $pool
listen.group = www-data
listen.mode = 0660

pm = dynamic
pm.max_children = 16
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4

pm.status_path = /fpmstat

request_slowlog_timeout = 3s
slowlog = /var/www/logs/$pool.slow.log

При необходимости:

access.log = /var/www/logs/$pool.access.log

Разберем параметры:

prefix — позволяет задать путь по умолчанию, который может использоваться в параметрах slowlog, listen, chroot, chdir, php_values, php_admin_values.
user и group — задает владельца и группу запускаемых процессов.
listen — указывает на каком сокете слушать. Поддерживаются как UNIX, так и TCP-сокеты. В случае, если веб-сервер и php-обработчики находятся на одном сервере, то лучше использовать UNIX-сокеты, так как это потенциально быстрее, так как нет оверхеда связанного с генерацией пакетов.
listen.owner, listen.group, listen.mode — позволяют задать параметры доступа к сокету. В качестве владельца указано имя совпадающее с именем пула. Необходимо создать соответствующего пользователя и убедиться, что для него нет ssh-доступа, конечно, если у вас не виртуальный хостинг. Группа указана www-data вследствие того, что под ней работает nginx и необходимо предоставить ему доступ к файлу сокета. Закрыть доступ остальным позволяют права 660.
pm — указывает как менеджер процессов будет управлять количеством дочерних процессов. Может быть статическим (постоянное количество процессов), динамическим (количество процессов может варьироваться в заданных пределах) и по требованию (когда нужно процесс запускается и убивается по истечении таймаута).
pm.max_children — максимальное количество дочерних процессов.
pm.start_servers — сколько процессов запускается при запуске php-fpm.
pm.min_spare_servers — минимальное количество ожидающих процессов. Если процессов меньше, чем значение параметра, то новые процессы будут созданы.
pm.max_spare_servers — максимальное количество ожидающих процессов. Если ожидающих процессов больше, чем значение параметра, то лишние процессы будут убиты.
pm.status_path — путь к странице статуса.
request_slowlog_timeout — время по прошествии которого запрос считается медленным.
slowlog — путь до файла лога медленных запросов.
access.log — путь до файла с логом доступа.

Другие интересные параметры:

pm.max_requests — количество обработанных запросов после которых процесс нужно перезапустить. Позволяет бороться с утечками памяти.
process.priority — задает приоритет процессов данного пула.
chroot — позволяет зачрутить процессы в указанную директорию. Однако все пути используемые php будут действовать относительно указанной директории, что требует дополнительной настройки.
security.limit_extensions — позволяет указать список расширений файлов для обработки php-fpm.

Также можно переопределять переменные окружения, к примеру:

env[TMP] = /tmp

и переопределять параметры из php.ini почти как это делается в .htaccess:

php_flag[display_errors] = off

То есть мы можем настраивать множество параметров php индивидуально для каждого пула.

Кстати говоря, для изменения параметров php можно использовать файл .user.ini в директории сайта.

debian-help.ru

nginx-php-fpm-mysql-debian-000.pngNginx — простой, но в тоже время быстрый и надежный веб-сервер, не перегруженный лишними функциями и отлично подходящий для работы в высоконагруженных системах. Особую популярность он завоевал как кеширующий прокси, позволяя существенно снизить нагрузку, на стоящий за ним веб-сервер, чаще всего Apache, но сегодня он все чаще используется как самостоятельный сервер. В нашей статье мы расскажем, как настроить Nginх для работы с PHP-приложениями при помощи менеджера процессов PHP-FPM на платформе Debian/Ubuntu.

Сразу охладим некоторые горячие головы — бытует мнение что Nginx быстрее Apache и вообще является чуть ли не панацеей от всех проблем. Но это не так. Nginx первоначально разрабатывался как кеширующий прокси и поэтому отлично справляется со своей основной задачей — кешированием и отдачей статического содержимого, что в общем-то и является основной задачей веб-сервера. В силу своей архитектуры он показывает выдающуюся производительность при множественных запросах даже в условиях ограниченных ресурсов.

В тоже время Nginx не умеет обрабатывать динамическое содержимое, для этого он должен отдать запрос серверу приложений одним из поддерживаемых способов, например, через FastCGI, дождаться и получить ответ, а затем уже отдать его клиенту. В среднем, что касается производительности PHP, то FastCGI будет в среднем в 10-15% медленнее, чем Apache + mod-php. Поэтому, если производительность вашего сервера упирается в производительность PHP, то никакой Nginx вам не поможет, а наоборот, только усугубит ситуацию.

Кроме того, работа с Nginx более сложна, чем с Apache, если с последним все популярные веб-движки работают из коробки, то для полноценной работы с Nginх может потребоваться дополнительная настройка. Исходя из этого мы не рекомендуем использовать Nginx, как самостоятельный веб-сервер, начинающим веб-мастерам, так как при отсутствии опыта и квалификации довольно трудно понять, связана ошибка с веб-приложением или веб-сервером. Да и на форумах для новичков вам вряд ли кто-нибудь подскажет по такой связке, а там, где «тусуются» работающие с Nginx специалисты подобные вопросы обычно не поднимаются, так как участники давно их «переросли».

Если вам нужен просто работающий веб-сервер, и вы не готовы глубоко вникать в тему, то лучше обратите свое внимание на Apache, если же вы готовы потратить некоторое время и силы на изучение и настройку, а также готовы самостоятельно решать возникающие проблемы, то добро пожаловать!

Установка Nginx

Несмотря на то, что Nginх присутствует в репозиториях основных дистрибутивов, мы рекомендуем использовать версию от разработчиков, это позволит более оперативно получать новые версии и новые возможности. Существует две ветки Nginx, основная и стабильная, первая имеет нечетную, вторая четную нумерацию. Разработка происходит следующим образом, все изменения основной ветки, скажем 1.7 фиксируются и переходят в стабильную 1.8, которая перестает разрабатываться и получает только обновления безопасности, основная ветка после этого получает номер 1.9 и в нее вносятся все изменения.

Сами разработчики рекомендуют использовать основную ветку, если только нет каких-то особых требований по совместимости. По своему опыту можем сказать, что основная ветка достаточно стабильна и может быть использована на рабочих серверах.

Для подключения репозиториев Nginx создадим в папке /etc/apt/sources.list.d файл nginx.list:

touch /etc/apt/sources.list.d/nginx.list

Потом добавим в него строки. Для Debian:

deb http://nginx.org/packages/mainline/debian/ codename nginx
deb-src http://nginx.org/packages/mainline/debian/ codename nginx

Для Ubuntu

deb http://nginx.org/packages/mainline/ubuntu/ codename nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ codename nginx

где codename — кодовое имя дистрибутива, например, jessie для Debian 8 или trusty для Ubuntu 14.04. Если вам не нужны исходные тексты, то репозитории deb-src можно не подключать (т.е. не добавлять эти строки).

Затем скачаем и установим PGP-ключ, необходимый для проверки подлинности:

cd
wget http://nginx.org/keys/nginx_signing.key
apt-key add nginx_signing.key

После чего можно обновить список пакетов и установить nginx:

apt-get update
apt-get install nginx

Теперь, если набрать в браузере адрес нашего сервера, вы увидите стандартную заглушку Nginx.

nginx-php-fpm-mysql-debian-001.pngТакже проверить состояние веб-сервера можно командой:

service nginx status

nginx-php-fpm-mysql-debian-002.pngТеперь перейдем к настройке. Для этого перейдем в папку /etc/nginx и откроем файл nginx.conf, мы будем перечислять настройки в порядке их нахождения в файле, если данной опции нет — ее следует добавить.

Прежде всего изменим пользователя, от имени которого работает nginx, в Debian/Ubuntu веб-сервер работает от пользователя www-data и чтобы избежать в будущем возможных коллизий с правами доступа приведем строку к виду:

user www-data;

Затем укажем количество рабочих процессов, рекомендуется выбирать их количество по числу доступных процессорных ядер, в нашем случае 2:

worker_processes 2;

Приведем секцию events к виду:

events {
worker_connections 1024;
use epoll;
}

Первая опция задает количество соединений на рабочий процесс, вторая задает метод обработки соединений, явно укажем наиболее эффективный для Linux.

Теперь перейдем в секцию http и после строки

access_log /var/log/nginx/access.log main;

зададим следующие опции:

client_header_timeout 30;
client_body_timeout 30;
reset_timedout_connection on;

Они задают таймаут (в секундах) на чтение клиентом тела и заголовка запроса, последняя опция разрешает сброс соединений по таймауту.

client_max_body_size 32m;
client_body_buffer_size 128k;

Эти параметры ограничивают максимальный размер тела запроса клиента и задают буфер для чтения заголовка запроса. Максимальный размер тела запроса ограничивает размер файла, который может быть загружен веб-сервером.

sendfile on;
tcp_nopush on;

Также разрешим передачу файлов и оптимизируем этот процесс.

Изменим параметр:

keepalive_timeout 30;

Он задает таймаут постоянных (keep-alive) соединений, которые позволяют повысить производительность протокола HTTP/1.1, но незакрытое соединений впустую использует ресурсы сервера и поэтому такие соединения следует принудительно завершать.

Ниже зададим параметры gzip-сжатия:

gzip on;
gzip_disable "msie6";
gzip_proxied any;
gzip_min_length 1024;
gzip_comp_level 4;
gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript application/atom+xml application/rdf+xml;

Первая опция включает gzip-сжатие, затем отключаем его для младших версий IE (6 и ниже), если такие вдруг зайдут на наш сервер, разрешим сжимать проксированные запросы, это нужно для сжатия динамического содержимого, затем укажем минимальный размер сжимаемого ответа, чтобы не тратить ресурсы сервера на сжатие коротких ответов. Ниже задается уровень сжатия и типы сжимаемых данных.

В самом конце, после

include /etc/nginx/conf.d/*.conf;

добавим

include /etc/nginx/sites-enabled/*;

Это позволит подключать конфигурации виртуальных хостов из папки sites-enabled.

Сохраним и проверим конфиг командой:

nginx -t

После чего можно перезапустить nginx:

service nginx restart

Теперь можно перейти к настройке виртуальных хостов, создадим две папки:

mkdir /etc/nginx/sites-available
mkdir /etc/nginx/sites-enabled

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

Перед тем как описывать виртуальные хосты, создадим структуру папок для их хранения:

mkdir /var/www
mkdir /var/www/example.org

Затем создадим конфигурационный файл для нашего первого сайта:

touch /etc/nginx/sites-available/example.org.conf

Какого-либо стандарта по названию файлов у nginx нет, поэтому можете придерживаться своей системы, главное, чтобы вам было понятно, какой файл за какой сайт отвечает. Теперь откроем его и внесем следующий текст:

server {
listen 80;

server_name example.org;
charset utf-8;

root /var/www/example.org;
index index.html index.htm index.php;

access_log /var/log/nginx/example.org_access.log;
error_log /var/log/nginx/example.org_error.log;
}

server {

listen 80;

server_name www.example.org;
rewrite ^(.*) http://example.org$1 permanent;
}

Его синтаксис достаточно прост и понятен, первая секция server задает основные параметры сайта, его имя, кодировку, расположение корневой директории и файлов логов. Вторая секция нужна для перенаправления сайта с www на без www.

Если вы хотите сделать данный виртуальный хост сайтом по умолчанию, т.е. тем на который будут переадресовываться все запросы, для которых nginx не нашел подходящего виртуального хоста или без имени сервера вообще, например, по IP-адресу, то добавьте к директиве listen опцию default, начиная с версии 0.8.1 можно использовать опцию default_server:

 listen 80 default;

Директива index указывает индексные файлы, которые будет искать в данном расположении веб-сервер в порядке их перечисления, так если в директории имеются одновременно index.html и index.php — использоваться всегда будет первый. Указанная конструкция универсальна, но на практике лучше указать один тип индексного файла, тот что реально используется.

Сохраняем конфигурацию и подключаем ее к nginx:

ln -s /etc/nginx/sites-available/example.org.conf /etc/nginx/sites-enabled/

Проверяем конфигурацию и заставим nginx ее перечитать:

nginx -t
service nginx reload

Теперь поместим в корневую директорию сайта файл index.html со следующим содержимым:

<body><h1>OK!</h1></body>

Теперь набираем в браузере имя нашего сайта и убеждаемся, что все работает.

nginx-php-fpm-mysql-debian-003.pngУстанавливаем PHP-FPM

Для работы с современными веб-приложениями вам потребуется поддержка популярного скриптового языка PHP, Nginx поддерживает работу через FastCGI, но не имеет собственного менеджера процессов, поэтому мы будем использовать для этой цели PHP-FPM.

Важно! В современных дистрибутивах используется более новая версия PHP 7, чтобы работать с новой версией языка вместо php5 в приведенных ниже командах следует указывать php7.0, например, вместо php5-imagick нужно набрать php7.0-imagick

Установим его:

apt-get install php5-fpm

Все необходимые пакеты и интерпретатор PHP будут установлены по зависимостям. Также имеет смысл сразу установить некоторые модули PHP, например, для работы с графикой:

apt-get install php5-gd php5-imagick

Настройки PHP-FPM по умолчанию достаточно оптимальны и никаких вмешательств в них не требуется, однако следует подправить некоторые опции PHP, для этого откроем /etc/php5/fpm/php.ini и найдем там следующие опции:

post_max_size = 8M

этот параметр задает максимальный размер данных загружаемых методом POST, влияет, например, на размер загружаемых средствами PHP файлов. По умолчанию 8 МБ, можем изменить по собственным потребностям.

Если вы будете использовать PHP-приложения (CMS) работающие в кодировке отличной от UTF-8, то приведите к следующему виду опцию:

default_charset = ""

Затем раскоменнтируйте и установите опцию:

cgi.fix_pathinfo=0

Это закроет возможную уязвимость в PHP.

Еще ниже надо найти и увеличить размер максимально загружаемого файла:

upload_max_filesize = 8M

Данное значение должно быть больше или равно значению post_max_size, иначе вы будете ограничены в загрузке файлов меньшим из указанных в этих опциях размером.

Сохраним изменения и перезапустим PHP-FPM:

service php5-fpm restart

Теперь следует научить Nginx работать с PHP-FPM, для этого в файл конфигурации виртуального хоста нужно добавить настройки, которые будут перенаправлять (проксировать) все запросы к динамическому содержимому на FastCGI-шлюз.

Если сайтов несколько, то аналогичные настройки потребуется добавить каждому виртуальному хосту, поэтому, чтобы не делать лишних действий, имеет смысл вынести данные настройки в шаблон и подключать к виртуальному хосту уже его. Такой подход имеет еще один плюс, если вам потребуется изменить настройки, то делать это придется только в одном месте.

Создадим директорию для хранения шаблонов:

mkdir /etc/nginx/templates

После чего создадим в ней шаблон для работы с PHP-FPM:

touch /etc/nginx/templates/php-fpm.conf

Откроем его и добавим следующий текст:

location ~ .php$ {
try_files $uri =404;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Указанный нами блок location будет обрабатывать все запросы к php-файлам, первая директива в нем проверяет наличие запрошенного файла, в противном случае отдавая ошибку 404. Вторая устанавливает параметры соединения с FastCGI-шлюзом, в нашем случае с PHP-FPM, соединение устанавливается через UNIX-сокет, как наиболее производительный способ соединения. Затем указывается индексный файл и подгружаются настройки Nginx для FastCGI.

Важно! Обратите внимание, что PHP 7 имеет иной путь к UNIX-сокету, поэтому следует указывать /var/run/php/php7.0-fpm.sock

В принципе этого уже достаточно, чтобы работать с динамическим содержимым, но не будем спешить и добавим в файл еще несколько блоков.

location ~ /.ht {
deny all;
}

Несмотря на то, что Nginx не использует htaccess-файлы, они, вместе с файлами htpasswd могут находиться в директории сайта, особенно если до этого он работал на Apache и будет правильно запретить доступ к ним в целях безопасности.

Также следует настроить кэширование статического содержимого:

location ~* .(gif|jpeg|jpg|txt|png|tif|tiff|ico|jng|bmp|doc|pdf|rtf|xls|ppt|rar|rpm|swf|zip|bin|exe|dll|deb|cur)$ {
expires 168h;
}

Данная конструкция включает кэширование на стороне браузера, сообщая тому, что «срок годности» указанных файлов — 168 часов (1 неделя) и при последующих обращениях на ваш сайт данные файлы следует брать из локального кэша. Мы привели примерный список, вы можете самостоятельно добавить в него нужные расширения файлов.

Также зададим кэширование для скриптов и стилей:

location ~* .(css|js)$ {
expires 180m;
}

Для них установим срок кэширования в 3 часа, что позволит соблюсти баланс между скоростью применения возможных изменений в этих файлах и уменьшением количества запросов к вашему сайту.

Теперь откроем файл конфигурации виртуального хоста и в конце первой секции server добавим строку подключения шаблона:

include /etc/nginx/templates/php-fpm.conf;

Сохраним все настройки, проверим конфигурацию и перезапустим Nginx.

nginx -t
service nginx reload

Чтобы проверить работу PHP создадим в корневой директории сайта файл test.php со следующим содержимым:

<?php
phpinfo();
?>

Теперь, если обратиться к данному файлу через браузер вы должны увидеть стандартную страницу с информацией о PHP.

interface31.ru

1. Установка Nginx

Для начала добавим репозиторий проекта Nginx:

 sudo vim /etc/apt/sources.list 

Добавим туда, официальное зеркало Nginx, то в каком виде представлен данный пакет, отражает видение его разработчиков:

 #for nginx deb http://nginx.org/packages/ubuntu/ precise nginx deb-src http://nginx.org/packages/ubuntu/ precise nginx 

Теперь нам нужно скачать GPG ключ:

 wget http://nginx.org/keys/nginx_signing.key 

Установим GPG ключ:

 sudo apt-key add nginx_signing.key 

Обновим список пакетов:

 sudo apt-get update 

Установим Nginx:

 sudo apt-get install nginx 

После установки nginx должен сразу стартануть. Если стартанул без ошибок, сразу переходим к пункту 2 установка php-fpm.

Если уже стоит апач, который по умолчанию слушает порт 80, то после установки nginx вывалятся ошибки:

 Обрабатываются триггеры для ureadahead ... ureadahead will be reprofiled on next reboot Настраивается пакет nginx (1.2.7-1~precise) ... nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) nginx: [emerg] still could not bind() invoke-rc.d: initscript nginx, action "start" failed. 

Узнаём, что у нас на порту 80:

 sudo netstat -lnp|grep :80 
 eugene@eugene:~$ sudo netstat -lnp|grep :80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 5557/apache2 

Видим, что действительно это apache2 уже слушает порт 80.

Тогда стопим apache, потом перезапускаем nginx.

 sudo service apache2 stop sudo service nginx restart 
 eugene@eugene:~$ sudo service nginx restart * Restarting nginx ngin [ OK ] 

2. Установка PHP-FPM

 sudo apt-get install php5-cli php5-common php5-mysql php5-fpm php-pear 

Нам необходимо устранить уязвимость PHP:

 sudo vim /etc/php5/fpm/php.ini 

Находим строку:

 ;cgi.fix_pathinfo = 1 

Приводим ее к виду:

 cgi.fix_pathinfo = 0 

Сохраняем изменения и перезапустим PHP-FPM:

 sudo /etc/init.d/php5-fpm restart 

3. Создадим виртуальный хост Nginx

Директория для всех сайтов у меня /var/www/. Вы можете выбрать любую, главное чтобы у nginx`а был доступ в эту директорию. Расположение сайтов, например сайт test:

  • /var/www/test/www — корневая директория
  • /var/log/nginx — access и error logs сайта test

 

Настаиваем первый виртуальный хост Nginx, назовем его test

 sudo vim /etc/nginx/conf.d/test.conf 

Содержимое файла /etc/nginx/conf.d/test.conf (Здесь я привожу только базовые настройки, чтобы работало, если нужно добавить что-то дополнительно, то вы сделаете это сами, исходя из ваших задач)

 server {  listen 80; # какой порт слушает  root /var/www/test/www; # корневая директория   access_log /var/log/nginx/test.access.log; #расположение логов данного хоста  error_log /var/log/nginx/test.error.log;   server_name test www.test;   location / {  index index.php index.html index.htm;  }   location ~ .php$ {  fastcgi_pass 127.0.0.1:9000;  fastcgi_index index.php;  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;  include fastcgi_params;  } } 

Обращаю внимание! Все виртуальные хосты должны иметь в названии расширение .conf, иначе виртуальный хост не будет загружен.

Создадим тестовый файл, чтобы проверить работоспособность PHP5:

 vim /var/www/test/www/index.php 

С содержимым:

 <?php  phpinfo(); 

Перезапустим Nginx, чтобы изменения вступили в силу:

 sudo /etc/init.d/nginx restart 

Не зыбываем прописать в /etc/hosts

 127.0.0.1 test 

Переходим по тестовому адресу http://test/index.php или http://test/. Получаем вывод phpinfo(). Если у вас при этом ошибка 502, то читаем ниже как исправить. А здесь нас интересует строка Server API, в ней указывается, кто у нас обрабатывает скрипты PHP.

phpinfo()

Возможные ошибки конфигурации nginx с php-fpm

502 Bad Gateway — если код ошибки 502, заменяем строку (listen = ..) в файле /etc/php5/fpm/pool.d/www.conf

 listen = /var/run/php5-fpm.sock #эту строку заменяем на следующую: listen = 127.0.0.1:9000 

После этого не забываем сделать restart php5-fpm. Ошибки 502 больше быть не должно.

Параметры, поддерживаемые командной строкой nginx

Nginx поддерживает следующие параметры:

 -c файл — указывает использовать конфигурационный файл файл вместо файла по умолчанию. -g — задаёт глобальные директивы конфигурации, например, nginx -g "pid /var/run/nginx.pid; worker_processes `sysctl -n hw.ncpu`;" -t — тестировать конфигурацию. nginx проверяет синтаксическую правильность конфигурации, а затем пытается открыть файлы, описанные в конфигурации. -v — показать версию nginx. -V — показать версию nginx, версию компилятора и параметры конфигурации сборки.

 

jeka.by

Nginx to CentOS, Debian and Gentoo

FastCGI это высокопроизводительный и масштабируемый интерфейс для взаимодействия веб-сервера и приложений, дальнейшее развитие технологии CGI, однако CGI-скрипты перезапускаются с каждым запросом сервера, что существенно снижает производительность; FastCGI оставляет процессы запущенными и только передает им новые запросы.

nginx имеет собственную поддержку технологии FastCGI для работы с внешними серверами и утилитами. PHP тоже поддерживает FastCGI и может быть использован для обработки FastCGI-запросов от nginx.

В данном примере мы рассмотрим связку nginx и PHP-FPM. Для начала необходимо их установить, в большинстве дистрибутивах для установки есть пакеты с одноимёнными названиями. Или, например в Gentoo, для установки необходим USE флаг fpm, более подробно смотрите в документации к своему дистрибутиву.

Есть много руководств по настройке nginx для работы с PHP FPM, но многие из них являются неполными (неправильно обрабатывается переменная PATH_INFO) или содержат ошибки в обработке сценариев безопасности (отсутствует проверка наличия PHP кода в php файле).

Настроить подключение nginx и PHP-FPM можно двумя способами — либо через TCP‑порт (127.0.0.1:9000), либо unix сокет (/var/run/php-fpm.sock).

FastCGI параметры

Первая рекомендация — храните все типовые настройки FastCGI в отдельном файле и, при необходимости, импортируйте их.

Например для Debian и Ubuntu настройки по умолчанию находятся в файле /etc/nginx/fastcgi_params, который должен выглядеть следующим образом:

Подключаем Nginx к PHP FPM

Тут мы должны сказать Nginx`у, чтобы проксировал запросы к PHP FPM через протокол FCGI:

В параметрах php-fpm.conf за подключение отвечает параметр listen.

В варианте подключения через unix сокет fastcgi_pass будет таким:

А параметр listen вот так:

После изменения настроек перезапустите nginx.

Тестирование

Создайте файл test.php в корневом каталоге nginx следующего содержания:

В браузере сделайте запрос:

Обратите внимание на значение REQUEST_URI, SCRIPT_NAME, PATH_INFO и PHP_SELF.

Вот правильный вывод для

Необходимые условия:
— Требования к PHP — версия 5.3.3 или выше.
— В php.ini значение cgi.fix_pathinfo = 1 (в некоторых мануалах советуют cgi.fix_pathinfo = 0 что может привести к не правильной обработке переменной PHP_SELF не равной DOCUMENT_URI).
— Регулярное выражение fastcgi_split_path_info должно корректно обрабатывать запросы, такие как /test.php/foo/blah.php или /test.php/.
— Необходимо разрешить nginx’у проверку *.php файлов чтобы предотвратить возможность передачи любых других файлов через PHP-FPM (например загруженные картинки).

Ознакомиться с более подробной информацией о FastCGI вы можете на официальном сайте.

Оригинал.

nixway.org

Здравствуйте!

Apache – король веб-серверов, если можно так сказать. Но на пятки ему наступает даже не IIS от Microsoft, не lighttpd, а nginx (произносится как Энджин-Икс, engine с английского мотор, двигатель) нашего соотечественника Сысоева.

Чем он хорош? Говорят, что статика отдаётся гораздо быстрее, чем у Апача, да и динамика я думаю тоже. Он жрёт меньше ресурсов, что может быть критически важно для нагруженных серверов. Раньше мнгоие применял связку nginx+Apache – nginx для отдачи статики (рисунков, js/css etc.), а Апач – для отдачи динамики (PHP/Perl/Python/Ruby etc.). Но теперь nginx можно применять без Апача, так как для него появилось куча плагинов и дополнений, поэтому вместо связки nginx+Apache+PHP (мы тут говорим о PHP-среде) легко настроить просто nginx+php-fpm. Ладно, об нём написано куча литературы, не буду повторяться, опишу лишь процесс установки nginx+php-fpm под Виндовс (Windows).

Хотя, конечно, nginx органичней всего чувствует себя в FreeBSD и Linux (любой Unix-среде, наверное), под Винду он тоже неплохо работает, по крайней мере я его у себя на домашнем компе установил, чтобы тестировать некоторые штуки.

Итак, процесс установки/первичной настройки. Этот процесс расписан здесь: http://nginx.org/ru/docs/windows.html
я приведу лишь выжимку.

Смотрим доступные версии nginx под windows здесь: http://nginx.org/en/download.html
Сейчас есть версия 1.8.0, несколько месяцев назад я устанавливал 1.6.2, которая и сейчас у меня работает.
Итак, скачиваем текущую версию под windows: http://nginx.org/download/nginx-1.8.0.zip

Для удобства примем то, что я пользую сейчас:
Создаём папку C:usr. Заходим в неё и распаковываем nginx-1.8.0.zip здесь (это можно проделать через GUI-интерфэйс).
Затем запускам териминал и заходим:

Тут Виньда может выкинуть окошко с предупреждением (см. скриншот), что nginx пытается получить доступ в сеть. Мы конечно же разрешаем.

allow nginx to network

Проверяем, запущен ли nginx и видим результат:

Остановим nginx нормально: nginx -s quit. Есть ещё несколько полезных команд для nginx:
nginx -s stop – останов nginx в любом случае (применяется, если nginx -s quit не сработает).
nginx -s reload – перезагрузка .conf файлов (конфигурации)
nginx -s reopen – переоткрытие .log файлов (полезна, если мы удалили или переместили логи при работающем nginx).

Итак, мы остановили nginx сейчас, так как прежде чем его запускать, надо правильно настроить .conf файлы. Они расположены в папке conf. Стандартный файл настройки – nginx.conf, из него директивой include могут подсоединяться другие файлы из этой (впрочем, и из любой другой) папки.
Например, директива include mime.types; в секции http присоединит файл mime.types, в котором находится определения всех стандартных MIME-типов. Впрочем, сам конфиг я обсуждать здесь не буду, о нем много написано в инете, приведу лишь пример своего конфига с краткими пояснениями.

Предупреждение: это конфиг для моей домашней тестовой среды. Для рабочего сервера требуется более тонкая настройка.

  worker_processes 1;    error_log logs/error.log;  #error_log logs/error.log notice;  #error_log logs/error.log info;    events {   worker_connections 1024;  }      http {   include mime.types;   default_type application/octet-stream;      #   # Формат лога делаем как у Апача   #   log_format main '$remote_addr - $remote_user [$time_local] "$request" '   '$status $body_bytes_sent "$http_referer" '   '"$http_user_agent" "$http_x_forwarded_for"';   access_log logs/access.log main;     # sendfile on;   #tcp_nopush on;      keepalive_timeout 65;     # Сжатие gzip на лету   gzip on;     server {   # listen 801;   server_name localhost;  				autoindex on; # allow dir listing  				root E:/sites;  				   #charset koi8-r;   #access_log logs/host.access.log main;    	#   # запретим доступ ко всем файлам, начинающимся с точки   	#   location ~ /. {   deny all;   }     location / {   root E:/sites;   index index.html index.htm index.php;   }     #error_page 404 /404.html;     # redirect server error pages to the static page /50x.html   #   error_page 500 502 503 504 /50x.html;   location = /50x.html {   root html;   }    	#   # передаем все PHP скрипты серверу FastCGI, слушающему на 127.0.0.1:9123   #   location ~ .php$ {   root E:/sites;   fastcgi_pass 127.0.0.1:9123;   fastcgi_index index.php;   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;   include fastcgi_params;   }   }  }    

Итак, в этом конфиге большинство настроек оставлено по умолчанию, а корень сайтов у нас в E:sites, что в первую очередь делает команда root E:/sites. Обратите внимание на прямые слэши в стиле Unix в пути к папкам и файлам – это требование nginx, даже для Windows-версии.

Теперь можно запускать nginx (start nginx), если мы его останавливали перед этим, либо применить команду nginx -s reload, чтобы сервер перечитал конфиги без остановки своей работы, что полезно при работающем внешнем сайте.

Итак, теперь надо настроить PHP-FPM для Windows. Учтите, что мы уже в нашем конфиге сделали его поддержку на порту 9123 (под-секция location ~ .php$)

1. Скачиваем свежий (или версию по выбору) .zip-архивчик с http://windows.php.net/download/. Архивчик должен быть VC11/VC9, что содержит в себе FastCGI-файл (phpcgi.exe).
2. Создаем папку в C:usr, например с именем php-5.6.9 и распаковываем в неё содержимое архива.
3. Редактируем файл php.ini в соотв. со своими предпочтениями, единственное, убедиться, что у нас есть такая строка:

  # nginx security setting  cgi.fix_pathinfo=0  

Она закрывает одну из старых уязвимостей nginx. Далее можно подключить PHP-модули по вкусу, расскоментировав их в соотв. секции и произвести другие настройки.

4. Теперь создадим .bat-файл, например php-fpm-start.bat с таким содержимым:

и запустим его. Если мы его запускаем из GUI, то появится окно консоли и останется открытым, придётся с этим смириться.

Всё, наш сервер мы уже давно настроили на соединение с этим PHP процессом.

Для проверки создаём файл index.php в папке E:sites с таким содержимым:

Теперь направляем наш любимый браузер на http://localhost и видим такую примерно картину:

phpinfo() начало

phpinfo

phpinfo() с версией nginx

phpinfo nginx

Здесь же можно посмортеь переменные среды и подключаемые модули. Для совместимости nginx создет переменные среды, совместимые с апачевскими, например _SERVER[“SERVER_NAME”], _SERVER[“DOCUMENT_ROOT”], _SERVER[“REQUEST_URI”], _SERVER[“SCRIPT_NAME”] и т.д., и мы можем использовать их в своих PHP-сценариях, как делали это в случае с Апачем.

До свидания!

atzar.ru

Прежде всего, следует открыть файл «/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

help.ubuntu.ru


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Adblock
detector