вступление
Хорошо, у меня довольно сложная проблема (по крайней мере, для меня) с моей скоро новой производственной сетью. Я ищу совета от более опытных пользователей Linux, особенно совета по безопасным способам настройки netwerk, который я собираюсь описать. Я все еще новичок во всем этом, и все же теперь я отвечаю за настройку этой новой сети.
В настоящее время я использую около 150+ веб-сайтов с одним балансировщиком нагрузки, тремя веб-серверами и сервером данных в apache. На данный момент все в порядке, однако я пытаюсь настроить новую сеть с nginx в новом debian из-за огромного увеличения производительности.
Я прочитал много-много информации о nginx и apache, провел десятки тестов для сравнения производительности в обеих ситуациях и пришел к выводу, что nginx под высоким давлением (мы запускаем почти только сайты WordPress) обрабатывает запросы намного быстрее, чем apache, в основном из-за статических файлов (иногда более 100 на одной странице, которые браузер явно может обналичить, но все же).
Текущая настройка
У меня есть все данные с веб-сайтов, смонтированные в каталоге / sites на каждом веб-сервере. Файлы конфигурации для nginx и fpm также находятся в каталоге конфигурации. Каждый веб-сайт (я буду использовать example.com) имеет своего собственного пользователя (аутентифицированного через ldap) и входит в группу веб-сайтов (также в ldap). Таким образом, каждый пользователь имеет свой домашний каталог в папке / sites с разрешениями 700 владельца example.com и группы сайтов. Это сделано для того, чтобы каждый веб-сайт работал на своем изолированном «острове».
Это означает, что для каждой конфигурации веб-сайта у меня есть конфигурация php fpm, которая использует разные сокеты для каждого пользователя. Это означает, что он может запускать php-файлы только в собственном каталоге веб-сайта, верно? Для PHP это работает нормально, и я предпочитаю не менять эту конфигурацию.
Проблема
Здесь возникает проблема: nginx работает быстрее, потому что он обслуживает статические файлы напрямую по сравнению с apache, который (как мы настроили его ранее) с модулем mpm-itk создает отдельные процессы для каждого пользователя, которые затем обслуживают статические файлы или PHP.
Nginx делает это по-другому, используя php fpm с разными сокетами для каждого пользователя, которого я достиг (по крайней мере, с php), так же, как модуль mpm-itk для apache. Однако nginx не может этого сделать и пытается обслуживать все статические файлы, поскольку пользователь nginx запускается как (www-data по умолчанию). Таким образом, вывод генерируется PHP (отлично работает), но у nginx нет разрешений на отображение статических файлов.
Я пытался найти решение более суток и пришел к нескольким другим выводам.
Запуск от root
Мой коллега сказал, что запуск nginx от имени root решит проблему, конечно, но мне это не кажется безопасным. Могу также удалить всю политику «каждый веб-сайт имеет своего пользователя», если я на ней.
Добавить www-данные в группу сайтов
Если бы я мог добавить пользователя unix (в данном случае www-data) в группу ldap (что, по-видимому, я не могу), я мог бы дать группе (веб-сайтам) права на чтение (вместо текущих 700), чтобы она могла читать статические файлы где угодно. Единственная проблема в том, что веб-сайты могут читать файлы друг от друга, чего я стараюсь избегать. Так что это тоже не кажется подходящим решением.
SELinux
Я прочитал некоторую документацию и вводную информацию о SELinux, и мне кажется, что это сложный способ исправить эту проблему. Я никогда не работал с ним, и запускать это в производственной сети вроде этого не кажется хорошей идеей, поскольку я понятия не имею, что я с этим делаю.
Вывод
Итак, откуда я сейчас нахожусь, какой путь выберет более опытный пользователь? Проведите дополнительные исследования в SELinux? AppArmor? Или есть другой более простой способ получить те же апачи безопасности, которые предлагает mpm_itk.
Это последняя проблема, которая у меня есть, и я не ищу все файлы конфигурации для ее настройки и точные команды, которые мне нужно выполнить, и все готово.
Я надеюсь, что кто-то с большим опытом может дать мне совет или указать правильное направление. В любом случае это очень ценится!
SELinux стоит потраченного времени. ИМХО, на самом деле это не так сложно, как кажется, когда вы просто хотите закрепить права на папки.
Но позвольте мне бросить вызов ... Если это в основном Wordpress, я бы выбрал Litespeed Webserver с плагином Wordpress Cache. Вы получаете невероятно быстрый Wordpress за счет кеширования на уровне веб-сервера:
https://www.litespeedtech.com/products/cache-plugins/wordpress-acceleration
А в Litespeed есть простая в реализации встроенная функция chroot, которая позаботится о ваших проблемах безопасности:
https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:config:chroot
«Chroot» - это функция в Unix-подобной системе, которая может изменять корневой каталог процесса. Измененный корневой процесс и его дочерний процесс не могут получить доступ ни к одному файлу за пределами нового корневого каталога. Это похоже на помещение процесса в тюрьму с физическими границами доступа к файлам, и причина, по которой этот механизм часто называют «chroot-тюрьмой».
Конечно, с Nginx также возможно chroot:
https://gir.me.uk/posts/nginx-php-fpm-with-chroot.html
Графический интерфейс администратора Litespeed просто делает его очень простым, возможно, более подходящим для вашего уровня опыта, чем выполнение всего из интерфейса командной строки.
Помимо Chroot, у вас также есть опция SuEXEC:
https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:config:suexec-mode
SuEXEC - это функция, которая позволяет веб-серверу LiteSpeed запускать CGI / FastCGI / LSAPI / PHP / Ruby или любые внешние веб-приложения под UID (идентификатором пользователя), отличным от UID процесса веб-сервера.
Это помогает решить ваши основные проблемы, связанные с запуском Nginx от имени пользователя root.
В настоящее время я использую как Nginx, так и Litespeed для создания сайтов Wordpress. В описанных вами ситуациях с высокой посещаемостью я бы рекомендовал Litespeed со специальным плагином в любое время. Кроме того, вы получаете все другие преимущества быстрого обслуживания файлов, которые отделяют Nginx и Litespeed от Apache.