Введение
В этой статье я расскажу, как настроить производительный web сервер на базе популярного стека технологий — nginx и php-fpm. В связи с выходом нового релиза Centos 8, многие статьи на эту тему стали не актуальны, так как версии софта в базовых репозиториях обновились и тот же php нет смысла ставить из стороннего репозитория.
В самом конце я покажу, как настроить SELinux применительно к данному веб серверу. Приведу список правил, которые нужно будет применить конкретно к моей статье. Правила не универсальные. В зависимости от настройки web сервера, они будут отличаться. Если вам не хочется тратить на это свое время, или вам он не нужен, то просто отключите selinux. Если же нужен, то пока только добавляйте конфиги, но ничего не запускайте, пока не дойдете до самого конца. С включенным и не настроенным SELinux все равно ничего не заработает.
В своей тестовой среде я буду использовать следующие сущности.
| z.serveradmin.ru | имя тестового виртуального хоста и сайта |
| /web/sites | директория для размещения виртуальных хостов |
| 75.37.225.138 | внешний ip адрес сервера |
| pma.serveradmin.ru | имя виртуального хоста для phpmyadmin |
Подопытным сервером будет выступать виртуальная машина от ihor, характеристики следующие:
| Процессор | 4 ядра |
| Память | 4 Gb |
| Диск | 80 Gb SSD |
Статистика веб-сервера
Для веб-серверов можно воспользоваться служебной страницей просмотра статуса. Она может показать статистику запросов к веб-серверу.
Apache
Для Apache необходим модуль mod_status, который идет в комплекте с данным веб-сервером. Проверить подключение модуля можно в конфигурационном файле httpd.conf (в разных Linux системах может находится в различных каталогах).
По умолчанию, server-status не активен. Создаем конфигурационный файл.
Для CentOS / Red Hat:
vi /etc/httpd/conf.d/server-status.conf
Для Ubuntu / Debian:
vi /etc/apache2/sites-enabled/server-status.conf
* где 2 — используемая версия apache.
В открытый конфигурационный файл добавим:
ExtendedStatus on
<VirtualHost *:80>
servername 111.111.111.111
<Location /server-status>
Sethandler server-status
</Location>
</VirtualHost>
<Location /server-status>
SetHandler server-status
</Location>
* где 111.111.111.111 — IP-адрес нашего веб-сервера; 80 — порт, на котором слушает apache.* в данном примере мы прописали два варианта просмотра статистики: первый — обращение в браузере к серверу по IP-адресу + /server-status; второй — обращение к любому сайту + /server-status. Разные способы оправданы для разных настроек самих сайтов и используемых CMS.
Проверим корректность внесенных данных и перезапустим веб-сервер apache:
apachectl configtest
systemctl restart httpd || systemctl restart apache2
Теперь открываем браузер и вводим название сайта + /server-status, например, http://www.dmosk.ru/server-status. Или обращаемся к серверу по IP-адресу, например, http://111.111.111.111/server-status.
NGINX + PHP-FPM
Открываем конфигурационный файл nginx:
vi /etc/nginx/nginx.conf
В секцию http добавляем:
…
server {
listen 80;
server_name 111.111.111.111;
location /server-status {
stub_status on;
}
}
…
* где 111.111.111.111 — IP-адрес нашего веб-сервера.
Проверяем корректность настройки и перезапускаем nginx:
nginx -t
systemctl restart nginx
Открываем браузер и заходим на страницу 111.111.111.111/server-status. Мы должны увидеть статистику использования сервера:
Теперь настроим статистику для php-fpm. В конфигурационном файле nginx в нашу директиву server добавим:
vi /etc/nginx/nginx.conf
…
server {
listen 80;
server_name 78.110.63.31;
location /server-status {
stub_status on;
}
location /status {
access_log off;
include fastcgi_params;
#fastcgi_pass unix:/var/run/php-fpm/php5-fpm.sock;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
…
* обратите внимание на закомментированную строку и строку под ней. В зависимости от того, как настроен php-fpm (слушает на порту или через сокетный файл) необходимо настроить nginx
В данном примере подразумевается, что php-fpm слушает на 9000 порту.
Открываем конфигурационный файл php-fpm:
vi /etc/php-fpm.d/www.conf
Снимаем комментарий со следующей строки:
pm.status_path = /status
Проверяем настройку nginx, перезапускаем его и php-fpm:
nginx -t
systemctl restart nginx
systemctl restart php-fpm
Открываем браузер и заходим на страницу 111.111.111.111/server-status. Мы должны увидеть статистику использования сервера:
Установка phpmyadmin
Кратко расскажу про установку phpmyadmin в контексте данной статьи. Подробно не буду останавливаться на этом, так как статья и так получается очень объемная, а я еще не все рассказал. Вопрос настройки phpmyadmin я очень подробно рассмотрел отдельно. За подробностями можно сходить туда.
Устанавливаем phpmyadmin через yum. Если ранее все сделали правильно, то конфликтов с зависимостями быть не должно.
# yum install phpmyadmin
Phpmyadmin по-умолчанию сконфигурирована для работы с httpd. Для того, чтобы в будущем автоматически обновлять ее, просто сделаем символьную ссылку из директории с исходниками панели в наш виртуальный хост.
# rm -df /web/sites/p1m2a.zeroxzed.ru/www # ln -s /usr/share/phpMyAdmin /web/sites/p1m2a.zeroxzed.ru/www
Выставляем правильные права на директорию с php сессиями. Без этого работать phpmyadmin не будет.
# chown nginx:nginx /var/lib/php/session/
Можно заходить и проверять работу phpmyadmin. Ее установка закончена.
Nginx Configuration and Optimizing Tips and Tricks
Nginx Tip 1. – Organize Nginx Configuration Files
Normally Nginx configuration files are located under /etc/nginx path.
One good way to organize configuration files is use Debian/Ubuntu Apache style setup:
Virtualhost files have 2 paths, because sites-available directory can contain any stuff, like test configs, just copied/created configs, old configs and so on. And sites-enabled contains only really enabled configurations, actually just only symbolic links to sites-available directory.
Remember add following includes at the end of your nginx.conf file:
Nginx Tip 2. – Determine Nginx worker_processes and worker_connections
Default setup is okay for worker_processes and worker_connections, but these values could be little bit optimized:max_clients = worker_processes * worker_connections
Just Nginx basic setup can handle hundreds of concurrent connection:
Normally 1000 concurrent connection / per one server is good, but sometimes other parts like disks on server might be slow, and it causes that the Nginx is locked on I/O operations. To avoid locking use example following setup: one worker_precess / per processor core, like:Worker Processes
To check how many processor cores do you have, run following command:
So here is 4 cores and worker_processes final setup could be following:
Worker Connections
Personally I stick with 1024 worker connections, because I don’t have any reason to raise this value. But if example 4096 connections per second is not enough then it’s possible to try to double this and set 2048 connections per process.
worker_processes final setup could be following:
I have seen some configurations where server admins are used too much Apache and think if I set Nginx worker_processes to 50 and worker_connections to 20000 then my server could handle all traffic once what we get monthly…but yes it’s not true. It’s just wasting of resources and might cause some serious problems…
Nginx Tip 3. – Hide Nginx Server Tokens / Hide Nginx version number
This is good for security reasons hide server tokens / hide Nginx version number, especially, if run some outdated version of Nginx. This is very easy to do just set server_tokens off under http/server/location section, like:
Nginx Tip 4. – Nginx Request / Upload Max Body Size (client_max_body_size)
If you want to allow users upload something or upload personally something over the HTTP then you should maybe increase post size. It can be done with client_max_body_size value which goes under http/server/location section. On default it’s 1 Mb, but it can be set example to 20 Mb and also increase buffer size with following configuration:
If you get following error, then you know that client_max_body_size is too low:
“Request Entity Too Large” (413)
Nginx Tip 5. – Nginx Cache Control for Static Files (Browser Cache Control Directives)
Browser caching is import if you want save resources and bandwith. It’s easy setup with Nginx, following is very basic setup where logging (access log and not found log) is turned off and expires headers are set to 360 days.
If you want more complicated headers or some other expiration by filetypes then you could configure those separately.
Nginx Tip 6. – Nginx Pass PHP requests to PHP-FPM
Here you could use default tpc/ip stack or use directly Unix socket connection. You have to also setup PHP-FPM listen exactly same ip:port or unix socket (with Unix socket also socket permission have to be right). Default setup is use ip:port (127.0.0.1:9000) you could of course change ips and ports what PHP-FPM listens. Here is very basic configuration with Unix socket example commented out:
It’s also possible to run PHP-FPM another server and Nginx another.
Nginx Tip 7. – Prevent (deny) Access to Hidden Files with Nginx
It’s very common that server root or other public directories have hidden files, which starts with dot (.) and normally those is not intended to site users. Public directories can contain version control files and directories, like .svn, some IDE properties files and .htaccess files. Following deny access and turn off logging for all hidden files.
Настройка SELinux для web сервера
Раздел для тех, кто хочет настроить SELinux на своем web сервере. Сначала ставим пакет policycoreutils-python-utils если он еще не установлен. Он нам нужен для утилиты semanage.
Дальше нам нужно подготовить набор правил для selinux при нашей текущей конфигурации web сервера. Общий смысл их следующий:
- У нас нестандартная директория для сайтов — /web/sites, по-умолчанию запросы будут блокироваться.
- Надо разрешить nginx взаимодействовать с сокетом.
- Позволить nginx управлять параметром rlimit_nofile.
- И еще некоторое количество запретов, которые сможете сами проверить.
Суть описываемой дальше настройки selinux сводится к тому, чтобы следить за ограничениями, которые он накладывает на работу сервиса и добавлять исключения в правила, если вы с ними согласны. Методом нескольких итераций готовится набор правил selinux.
Я для этого пользуюсь следующими командами. Просмотр сработавших блокировок selinux для nginx.
Можете внимательно посмотреть суть блокировок. На первый взгляд выглядит не понятно, но в целом все гуглится. Можно разобраться, если есть желание. Подробно этот процесс описан в статье на сайте nginx.com.
Сформировать список правил для selinux.
Этот файл можно потом вручную дополнять или изменять. После того, как все правила будут собраны в один файл, готовлю модуль для selinux.
В конце загружаю этот модуль в selinx.
Можно не собирать правила самому, а сразу получить готовый модуль для загрузки и установить его.
Потом повторите все то же самое для php-fpm и можно проверять работу web сервера. Если в процессе проверки окажется, что что-то еще не работает, опять смотрите audit.log и добавляйте новые правила, пересобирайте и загружайте модуль. Так, через несколько итераций, получится рабочий набор правил для selinux.
Убедиться, что модуль загружен, можно командой.
В целом, по selinux все. Мы просто разрешили все, что веб сервер просил. По идее, надо вдумчиво во всех правилах разбираться и разрешать только то, что считаешь нужным. Я честно скажу, что selinux знаю не очень хорошо. Дальше загрузки готовых модулей и автоматического создания модулей с помощью audit2allow я не двигался. Руками модули никогда не писал. Если есть какой-то более осмысленный и правильный способ настройки selinux на кастомной конфигурации веб сервера, буду рад полезной информации.
Хорошая практическая статья по ручной настройке selinux для web сервера — https://habr.com/ru/post/322904/. Там же есть ссылки на другие статьи автора на тему selinux. Написано содержательно и наглядно, рекомендую для тех, кто будет знакомиться с технологией.
Подключение Nginx к PHP-FPM
Чтобы принимать запросы FastCGI от Nginx, PHP-FPM может прослушивать сокет TCP/IP или UNIX сокет. Сокеты UNIX являются средством межпроцессного взаимодействия, которое обеспечивает эффективный обмен данными между процессами, работающими в одной и той же операционной системе, в то время как сокеты TCP/IP позволяют процессам обмениваться данными по сети.
В отличие от сокета TCP/IP, который идентифицирует сервер по IP-адресу и порту (например, 127.0.0.1:9000), вы можете привязать сервер к сокету UNIX, используя путь к файлу (например, /run/php-fpm/www.sock), который виден в файловой системе.
Сокет UNIX — это особый тип файла — к нему применяются разрешения на доступ к файлам и каталогам (как в случае с любым другим типом файла UNIX), и его можно использовать для ограничения того, какие процессы на хосте могут читать и записывать в файл, (и, таким образом, общаться с внутренним сервером).
Таким образом, сокет UNIX является безопасным, поскольку его могут использовать только процессы на локальном хосте. Сокет TCP/IP может быть доступен из Интернета, и это может представлять угрозу безопасности, если не будут приняты дополнительные меры безопасности, такие как настройка брандмауэра.
Настройка PHP-FPM для прослушивания на сокете UNIX
Чтобы настроить PHP-FPM на прослушивание сокета UNIX, откройте файл конфигурации пула PHP-FPM по умолчанию, используя свой любимый текстовый редактор при помощи команды:
Затем найдите директиву listen и задайте для нее путь к файлу сокета UNIX следующим образом — listen = /run/php/php7.4-fpm.sock
Если вы используете сокет UNIX, вам также необходимо установить соответствующие разрешения на чтение/запись для файла, чтобы разрешить подключения с веб-сервера NGINX. По умолчанию Nginx работает как пользователь www-data в Ubuntu.
Найдите параметры listen.owner и listen.group и задайте им значение www-data. Также установите режим на 0660, для параметра listen.mode.
Настройка PHP-FPM для прослушивания через сокет TCP/IP
Хотя сокет UNIX быстрее сокета TCP/IP, он менее масштабируем, поскольку он может поддерживать межпроцессное взаимодействие только в одной и той же ОС. Если Nginx и внутренний сервер приложений (PHP-FPM) работают в разных системах, вам придется настроить php-fpm для прослушивания сокетов TCP/IP для удаленного подключения.
В файле конфигурации пула php-fpm установите адрес прослушивания, например: 127.0.0.1:9000. Убедитесь, что выбранный вами порт не используется другим процессом или службой в той же системе.
Найдите параметр listen и пропишите адрес — 127.0.0.1:9000:
Сохраните изменения и закройте файл. Установка Nginx php fpm практически завершена.
Настройка Nginx для работы php-fpm
После того, как вы настроили адрес, который прослушивает PHP-FPM, вам нужно настроить Nginx для запроса прокси к нему через этот адрес, используя параметр конфигурации fastcgi_pass, который располагается в файле конфигурации блока виртуального хоста.
Для примера, возьмем файл конфигурации стандартной странички сайта nginx которая открывается при первом запуске nginx, расположенный по следующему пути — /etc/nginx/conf.d/default.conf, откроем его для редактирования:
Если вы настроили PHP-FPM для прослушивания на сокете UNIX, найдите блок местоположения для обработки файлов .php и установите следующие параметры для fastcgi:
Если используется TCP/IP сокет, замените значение в параметре fastcgi_pass на IP-адрес и порт сервера, на котором работает PHP-FPM FastCGI:
После внесения изменений в конфигурации Nginx проверьте правильность синтаксиса при помощи команды:
Далее вам необходимо перезапустить службы, чтобы применить изменения, используя для этого команды:
После перезапуска служб, подключение считается выполненным успешно. Можно создать файл index.php со следующим содержимым:
Затем можно попытаться открыть эту страницу в браузере. Для этого в адресную строку надо ввести http://localhost/index.php. Если всё было настроено верно, перед вами откроется такая страница:
Для дальнейшей настройки PHP-FPM воспользуйтесь статьей по настройке PHP-FPM на Ubuntu 20.04 – Настройка PHP-FPM
Дашборд Zabbix для Web сервера
Как и обещал, в завершении статьи по настройке мониторинга web сервера, показываю пример своего дашборда в zabbix для мониторинга bitrix сайта. Картинка очень большая, по клику открывается полная версия, если открыть в новой вкладке.
В самом верху список текущих проблем. В настоящий момент висит активный триггер о ssh подключению к серверу. Описание его настройки — мониторинг ssh подключений. Справа от списка проблем — мониторинг бэкапов в zabbix.
Ниже идут метрики с мониторинга web сайта. Выбирается контрольный набор из нескольких страниц (обычно 3-5) и настраивается мониторинг времени ответа и скорости загрузки этих страниц. Для этих параметров настроены триггеры, так как они очень важны. По сути, это ключевые метрики. Если с ними проблемы, надо внимательно смотреть web сервер и разбираться, в чем проблема. Мониторинг web сайта нужно настраивать минимум с двух независимых серверов zabbix, иначе вы не сможете отличить проблемы доступа с сервера мониторинга к сайту от реальных проблем сайта. Только если оба сервера мониторинга сигнализируют о проблемах, можно сделать однозначный вывод о том, что с сайтом и web сервером что-то не так.
Дальше идут метрики из шаблонов, которые я рассмотрел в этой статье. Если у вас вместо apache используется php-fpm, то все примерно то же самое, только в самом низу метрики от php-fpm. Не буду приводить пример с ним, чтобы не загромождать статью. Думаю, приведенного дашборда и так достаточно.
В принципе, сюда можно было бы добавить информацию по I/O дисков, инфу с сетевого стека, данные Mysql. Не стал этого делать, так как это обзорный dashboard, который беглым просмотром позволяет оценить состояние сервера. Так же этот дашборд можно показать заказчику. Для более глубокого анализа проблем, нужно собирать отдельную панель.
Установка phpmyadmin
Для того, чтобы установить phpmyadmin на наш web сервер, достаточно просто распаковать в директроию с виртуальным хостом исходники панели. Все остальные настройки у нас уже готовы, в том числе виртуальный хост с tls сертификатом.
Идем на сайт https://www.phpmyadmin.net и копируем ссылку на последнюю версию панели. Затем загружаем ее через консоль.
Архив упакован в zip. Если у вас нет на сервере пакета unzip, установите его.
Распаковываем исходники в директорию виртуального хоста.
Можно заходить и проверять работу phpmyadmin, пройдя по адресу pma.serveradmin.ru. Ее установка закончена.
Более подробно вопрос установки и настройки phpmyadmin я рассматривал отдельно. Можете зайти в панель и создать базу mysql для тестового сайта, например, wordpress. Затем через консоль загрузить исходники cms и распаковать их.
После этого открывайте в браузере страницу z.serveradmin.ru и увидите приветсвие установщика wordpress.
На этом основная настройка web сервера завершена. Он уже полностью работоспособен. Если вам достаочно этого функционала, то можете сразу переходить к настройке ротации логов.
Установка NGINX
Устанавливаем NGINX:
apt-get install nginx
Внесем изменение в файл nginx.conf:
vi /etc/nginx/nginx.conf
http {
…
server_names_hash_bucket_size 64;
….
}
* в данном примере мы сняли комментарий со строчки server_names_hash_bucket_size 64;* на практике, может встретиться ошибка could not build server_names_hash, you should increase server_names_hash_bucket_size: 32. Она возникает при большом количестве виртуальных серверов или если один из них будет иметь длинное название. Данная строка в конфиге исправит ситуацию.
Перезапускаем nginx:
systemctl enable nginx
systemctl restart nginx
* в процессе запуска мы можем увидим ошибку — возможно, в системе работает другой веб-сервер и занимает 80 порт. Как правило, это apache. Чтобы его выключить (на данном этапе он нам не нужен) вводим команду systemctl stop apache2.
Проверим работу веб-сервера. Открываем браузер и вводим в адресной строке http://<IP-адрес сервера>. В итоге мы должны увидеть заголовок «Welcome to nginx!»:
Если стартовая страница не загружается, проверяем состояние сервиса:
systemctl status nginx
Apache
Для поддержки файла .htaccess, который используется многими сайтами, необходимо установить и настроить веб-сервер Apache.
Устанавливаем apache и модуль для php:
apt-get install apache2 libapache2-mod-php
Заходим в настройки портов:
vi /etc/apache2/ports.conf
И редактируем следующее:
Listen 8080
#<IfModule ssl_module>
# Listen 443
#</IfModule>
#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>
* мы настроили прослушивание на порту 8080, так как на 80 уже работает NGINX. Также мы закомментировали прослушивание по 443, так как и он будет слушаться NGINX.
Теперь открываем настройку следующего модуля:
vi /etc/apache2/mods-available/dir.conf
И добавляем впереди индексных файлов index.php:
<IfModule dir_module>
DirectoryIndex index.php index.html …
</IfModule>
* если не указан конкретный скрипт, сначала веб-сервер пытается найти и запустить index.php, затем index.html и так далее.
Открываем основной конфигурационный файл для apache:
vi /etc/apache2/apache2.conf
Рядом с опциями Directory дописываем:
<Directory /var/www/*/www>
AllowOverride All
Options Indexes ExecCGI FollowSymLinks
Require all granted
</Directory>
* где Directory указывает на путь, для которого мы хотим задать настройки; AllowOverride — позволит переопределить все настройки с помощью файла .htaccess; Options задает некоторые настройки: Indexes разрешает списки каталогов, ExecCGI разрешает запуск cgi скриптов, Require all granted — предоставляет всем доступ к сайтам в данном каталоге.
Ниже допишем:
<IfModule setenvif_module>
SetEnvIf X-Forwarded-Proto https HTTPS=on
</IfModule>
* этой настройкой мы при получении заголовка X-Forwarded-Proto со значением https задаем переменную $_SERVER равную on. Данная настройки критична для функционирования некоторых CMS.
Запрещаем mpm_event:
a2dismod mpm_event
* по умолчанию, apache2 может быть установлен с модулем мультипроцессовой обработки mpm_event. Данный модуль не поддерживает php 7 и выше.
Разрешаем модуль мультипроцессовой обработки mpm_prefork:
a2enmod mpm_prefork
Разрешаем модуль php:
a2enmod php7.4
* в данном примере установлен php версии 7.4.
Разрешаем модуль setenvif:
a2enmod setenvif
Разрешаем модуль rewrite:
a2enmod rewrite
В процессе включения модулей, если мы видим «Module … already enabled», значит модуль уже включен.
Разрешаем автозапуск Apache и перезапускаем службу:
systemctl enable apache2
systemctl restart apache2
Открываем браузер и вводим в адресную строку http://<IP-адрес сервера>:8080. Мы должны увидеть привычную страницу:
* в разделе Server API мы должны увидеть Apache.
NGINX + Apache
Ранее мы настроили связку nginx + php-fpm. Теперь настроим nginx + apache. Открываем конфигурационный файл nginx для сайта по умолчанию:
vi /etc/nginx/sites-enabled/default
Находим наш настроенный location для php-fpm:
…
location ~ \.php$ {
set $root_path /var/www/html;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
…
и меняем на:
…
location ~ \.php$ {
proxy_pass http://127.0.0.1:8080;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
…
Проверяем и перезапускаем nginx:
nginx -t
systemctl restart nginx
Пробуем открыть в браузере http://<IP-адрес сервера> — должна открыться та же страница, что при проверке Apache (с добавлением 8080):
Apache Real IP
Запросы на apache приходят от NGINX, и они воспринимаются первым как от IP-адреса 127.0.0.1. На практике, это может привести к проблемам, так как некоторым сайтам необходимы реальные адреса посетителей. Для решения проблемы будем использовать модуль remoteip.
Создаем конфигурационный файл со следующим содержимым:
vi /etc/apache2/mods-available/remoteip.conf
<IfModule remoteip_module>
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 127.0.0.1/8
</IfModule>
Активируем модуль:
a2enmod remoteip
Перезапускаем apache:
systemctl restart apache2
Для проверки настройки открываем браузер и вводим в адресную строку http://<IP-адрес сервера>, где откроется наша страница phpinfo. В разделе Apache Environment мы должны увидеть внешний адрес компьютера, с которого обращаемся к серверу в опции REMOTE_ADDR.
Работа с сайтами разных пользователей на одном веб сервере
Самый простой способ решить проблему с правами доступа, это сделать владельцем папки с сайтом пользователя, который подключается по sftp. Тогда он сможет нормально работать с файлами, загружать и удалять их. Если доступ в качестве группы установить для nginx, то в целом все будет работать. Для каких-то сайтов такой вариант может оказаться подходящим. То есть сделать надо вот так:
И не забываем обратно вернуть владельца на наш chroot каталог, иначе не подключимся по sftp.
Но при такой схеме будут проблемы с движками сайтов, которые автоматом что-то к себе загружают, потому что php-fpm работает от пользователя nginx, а у нас права nginx только на группу стоят, где нет прав на запись. К примеру, wordpress не сможет автоматически загружать плагины, будет просить доступ к ftp. Это можно исправить просто выставив права 0775 на все каталоги, но это путь костылей. В общем, могут возникнуть некоторые неудобства. Сейчас мы их исправим.
Еще раз обращаю внимание на важный нюанс. Chroot доступ для sftp не будет работать, если владельцем директории, куда чрутимся, будет не root
Будете получать ошибку.
Возвращаем обратно рута владельцем корня chroot.
Обращаю внимание, что сначала мы рекурсивно назначаем права на все содержимое директорий, а потом возвращаем владельца root только на корень домашнего каталога пользователя z.serveradmin.ru. Добавляем пользователя nginx в группу z.serveradmin.ru, чтобы web сервер имел доступ на чтение всех файлов виртуального хоста
Добавляем пользователя nginx в группу z.serveradmin.ru, чтобы web сервер имел доступ на чтение всех файлов виртуального хоста.
Создаем отдельный pool для php-fpm, который будет обслуживать сайт z.serveradmin.ru и будет запускаться от этого пользователя. Для этого копируем существующий конфиг /etc/php-fpm.d/www.conf и изменяем в нем несколько строк.
Мы поменяли название пула, запустили его от отдельного пользователя и назначили ему отдельный сокет. Теперь идем в настройки этого виртуального хоста в nginx — /etc/nginx/conf.d/z.serveradmin.ru.conf и везде меняем старое значение сокета
на новое
Перезапускаем nginx и php-fpm и проверяем работу сайта от отдельного пользователя.
Я рекомендую подключиться по sftp, закинуть еще раз исходники wordpress уже по sftp, установить его и добавить новую тему, чтобы проверить, что все корректно работает. По аналогии проделанные выше действия повторяются для всех остальных сайтов.
Ротация логов веб сервера nginx
Последний штрих в настройке web сервера — ротация логов виртуальных хостов. Если этого не сделать, то через какое-то, обычно продолжительное, время возникает проблема в связи с огромным размером лог файла.
У нас уже будет файл конфигурации logrotate для nginx, который был создан во время установки — /etc/logrotate.d/nginx. Приведем его к следующему виду:
На этом все. Я рассмотрел все основные моменты, которые необходимы для установки и настройки производительного web сервера на основе nginx и php-fpm последних версий. При этом рассказал о некоторых вещах, которые повышают удобство и гибкость эксплуатации сервера.
Дополнительные материалы по Freebsd
Онлайн курс по Linux
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Administrator Linux. Professional» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Что даст вам этот курс:
- Знание архитектуры Linux.
- Освоение современных методов и инструментов анализа и обработки данных.
- Умение подбирать конфигурацию под необходимые задачи, управлять процессами и обеспечивать безопасность системы.
- Владение основными рабочими инструментами системного администратора.
- Понимание особенностей развертывания, настройки и обслуживания сетей, построенных на базе Linux.
- Способность быстро решать возникающие проблемы и обеспечивать стабильную и бесперебойную работу системы.
Проверьте себя на вступительном тесте и смотрите подробнее программу по .
| Рекомендую полезные материалы по Freebsd: |
Описание установки Freebsd 11 на одиночный диск, либо на софтовый raid1, сделанный средствами zfs, которые поддерживает стандартный установщик. Базовая настройка Freebsd, которую можно выполнить после установки сервера общего назначения. Представлены некоторые рекомендации по повышению удобства пользования и безопасности. Описание и нюансы обновления системы Freebsd с помощью утилиты freebsd-update. Показано пошагово на конкретном примере обновления. Настройка Freebsd шлюза для обеспечения выхода в интернет. Используется ipfw и ядерный нат, dnsmasq в качестве dhcp и dns сервера. Мониторинг сетевой активности с помощью iftop. Подробная настройка на Freebsd прокси сервера squid + sams2 — панели управления для удобного администрирования. Настройка максимально быстрого web сервера на базе Freebsd и nginx + php-fpm. Существенный прирост производительности по сравнению с классическим apache. Настройка web сервера на Freebsd в связке с apache, nginx, php и mysql. Пошаговая установка и настройка каждого компонента. |
