Настройка сжатия Gzip
Сжатие контента необходимо, чтобы уменьшить размер загружаемых браузером данных. Это ускоряет загрузку сайта, но добавляет дополнительную нагрузку на процессор сервера. Чтобы включить сжатие в секции http нужно добавить параметр:
gzip on
Эту директиву можно использовать также в секции server, тогда она будет работать только для указного виртуального домена. Дальше настраиваем параметры сжатия настраиваются с помощью следующих опций:
- gzip_min_length — минимальная длина страницы в байтах, при которой нужно использовать сжатие, например, 1000 (1 кб)
- gzip_proxied — нужно ли сжимать проксированые запросы, any говорит, что нужно сжимать все.
- gzip_types — типы файлов, которые нужно сжимать, например: text/plain application/xml application/x-javascript text/javascript text/css text/json;
- gzip_disable «msie6» — в IE 6 сжатие не поддерживается, поэтому отключаем.
- gzip_comp_level — уровень сжатия, доступны варианты от 1 до 10. 1 — минимальное, 10 — максимальное сжатие.
Проверка безопасности и параметров
Для корректной работы системы выполним дополнительную настройку системы. После входа в nextcloud под администратором, переходим в настройки для пользователя:
В разделе «Параметры сервера» переходим в Основные сведения:
В разделе «Проверка безопасности и параметров» мы можем увидеть список проблем:
Рассмотрим процесс решения некоторых из них.
1. PHP не настроен правильно для получения переменных системного окружения
Открываем файл php.ini. При нашей установке, это:
vi /etc/php-fpm.d/www.conf
Снимаем комментарий с параметра PATH:
env = /usr/local/bin:/usr/bin:/bin
Перезапускаем php-fpm:
systemctl restart php-fpm
Открываем на редактирование файл:
vi /etc/php.ini
Меняем настройку для memory_limit:
memory_limit = 512M
Перезапускаем php-fpm:
systemctl restart php-fpm
Выполним команду для индексирования баз:
sudo -u apache php /var/www/nextcloud/occ db:add-missing-indices
4. Некоторые индексы базы данных не были преобразованы в тип big int
Выполним команду для преобразования в тип big int:
sudo -u apache php /var/www/nextcloud/occ db:convert-filecache-bigint
На запрос Continue with the conversion отвечаем утвердительно:
Continue with the conversion (y/n)? y
5. В системе не установлены рекомендуемые модули PHP
Данная ошибка устраняется в зависимости от списка модулей, которых не хватает системе. Чаще всего, подходит команда:
dnf install php-<название модуля>
Установка некоторых модулей может вызвать затрудение. Например, imagick в CentOS 8 устанавливается по инструкции ниже.
Установим ImageMagick:
dnf —enablerepo=PowerTools install ImageMagick ImageMagick-devel
После устанавливаем пакеты, необходимые для сборки imagick:
dnf install php-devel php-pear make
Собираем imagick:
pecl install imagick
Создаем файл с расширением php:
vi /etc/php.d/20-imagick.ini
extension=imagick.so
Перезапускаем php-fpm:
systemctl restart php-fpm
6. Не загружен модуль OPcache
Устанавливаем модуль opcache командой:
dnf install php-opcache
Открываем конфигурационный файл:
vi /etc/php.d/10-opcache.ini
Редактируем следующее:
…
opcache.max_accelerated_files=10000
…
opcache.save_comments=1
…
opcache.revalidate_freq=1
…
Перезапускаем php-fpm:
systemctl restart php-fpm
7. Не настроена система кеширования
Для решения проблемы мы должны установить и настроить одно из средств кэширования:
- APCu
- Redis
- Memcached
Мы рассмотрим последний вариант. Для этого выполняем установку модуля по инструкции Установка и настройка memcached на CentOS.
После этого открываем конфигурационный файл для nextcloud:
vi /var/www/nextcloud/config/config.php
И добавим:
…
‘memcache.local’ => ‘\\OC\\Memcache\\Memcached’,
‘memcache.distributed’ => ‘\\OC\\Memcache\\Memcached’,
‘memcached_servers’ =>
array (
0 =>
array (
0 => ‘localhost’,
1 => 11211,
),
),
…
Настройка СУБД
Заходим в оболочку mysql:
mysql -uroot -p
Смотрим значение для переменной innodb_file_format:
> show variables like ‘innodb_file_format’;
Если видим значение «Antelope», меняем его на Barracuda:
> SET GLOBAL innodb_file_format=Barracuda;
Выходим из оболочки:
> quit
Настройка Nextcloud
Переводим Nextcloud в режим обслуживания:
sudo -u apache php /var/www/nextcloud/occ maintenance:mode —on
Перезагружаем mariadb (если на первом шаге нам пришлось менять значение для переменной innodb_file_format):
systemctl restart mariadb
Редактирование базы данных
Снова подключаемся к консоли управления СУБД:
mysql -uroot -p
Меняем кодировку для базы данных:
> ALTER DATABASE nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
* где nextcloud — имя созданной нами базы данных.
Выходим из mariadb:
> quit
Также задаем новую кодировку для nextcloud
sudo -u apache php /var/www/nextcloud/occ config:system:set mysql.utf8mb4 —type boolean —value=»true»
Преобразуем все таблицы в базе:
sudo -u apache php /var/www/nextcloud/occ maintenance:repair
Завершаем режим обслужавания:
sudo -u apache php /var/www/nextcloud/occ maintenance:mode —off
Шаг 11 — Обслуживание статических файлов с помощью Nginx (необязательно)
Когда Nginx перенаправляет запросы доменов Apache через прокси-сервер, каждый запрос файла этого домена отправляется в Apache. Nginx обслуживает статические файлы, такие как изображения, JavaScript и таблицы стилей, быстрее Apache. Поэтому мы настроим файл виртуального хоста Nginx для прямого обслуживания статических файлов и перенаправления запросов PHP в Apache.
Откройте в своем редакторе файл :
Вам потребуется добавить два дополнительных блока в каждый блок server, а также изменить существующие разделы . Кроме того, вам нужно будет указать Nginx, где можно найти статические файлы для каждого сайта.
Если вы решили не использовать сертификаты SSL и TLS, измените свой файл, чтобы он выглядел следующим образом:
/etc/nginx/sites-available/apache
Если вы также хотите обеспечить доступность HTTPS, используйте следующую конфигурацию:
/etc/nginx/sites-available/apache
Директива указывает Nginx искать файлы в корне документа document root и выводить их напрямую. Если файл имеет расширение , запрос перенаправляется в Apache. Даже если файл отсутствует в document root, запрос перенаправляется в Apache, чтобы функции приложения (например, постоянные ссылки) работали без проблем.
Предупреждение. Директива очень важна, поскольку она не дает Nginx выводить содержимое файлов конфигурации Apache с важными данными, таких как и .
Сохраните файл и проведите тест конфигурации:
Если тест завершается успешно, перезагрузите Nginx:
Чтобы убедиться, что все работает, вы можете просмотреть файлы журнала Apache в каталоге и посмотреть запросы для файлов сайтов и . Используйте команду для просмотра последних нескольких строк файла и параметр для просмотра изменений файла:
Теперь откройте в браузере и посмотрите на результаты вывода журнала. Вы увидите ответ Apache:
Затем откройте страницы каждого сайта, и вы не увидите записи журнала Apache. Их обслуживает Nginx.
Завершив изучение файла журнала, нажмите чтобы остановить отслеживание.
При такой настройке Apache не сможет ограничивать доступ к статическим файлам. Контроль доступа к статическим файлам должен быть настроен в файле виртуального хоста Nginx, однако это не входит в содержание настоящего обучающего руководства.
Создание второго файла server block (виртуального хоста) конфигурации
Копируем дефолтный файл настроек для второго веб-сайта.
Редактируем файл siteprimer.ru
Из «listen» убираем опцию «default_server», так как она стоит для первого сайта. Убираем ipv6only=on.
Укажем коневой каталог.
Установим server_name
Итоговая конфигурация второго веб-сайта:
Активация
После настройки конфигурации для виртуальных хостов (server block), необходимо активировать их.
В веб-сервере есть два каталога sites-available и sites-enabled.
В sites-available хранятся конфигурации всех хостов.
В sites-enabled — символические ссылки, которые веб-сервер считывает при загрузки.
Создадим ссылки для каталога sites-enabled.
Теперь при запуске веб-сервера, nginx активирует символические ссылки. Однако, хост default еще активирован и мы на выходе получим ошибку, так как параметр default_server запущен два раза.
Первый раз в конфиге default, второй в vseprolinux.ru.
Убрать это ошибку просто — удалим символическую ссылку default из каталога sites-enabled, тем самым server block не будет активироваться.
Далее открываем главный конфиг nginx.conf
Нужно раскомментировать (убрать #) строчку:
Параметр server_names_hash_bucket_size устанавливает размер корзины в хэш-таблицах имен серверов.
Перезапускаем сервис.
Настройка корневой системы для сайтов
Сделаем удобную корневую систему сайтов таким образом, что каждый каталог соответствует названию сайта.
И все файлы будут храниться в директории «/var/www/название домена/html».
Создадим каталоги для двух доменов: vseprolinux.ru; siteprimer.ru.
Аргумент «-p» говорит, чтобы директории создавались в любом случаи, если даже их не существует.
Права на html
Передадим права на папку html обычному пользователю, таким образом, чтобы мы могли создавать новые элементы, а пользователи сайта — нет.
Для этого будем использовать переменную окружения «$USER», чтобы не вводить имя своего логина.
Права на каталог www.
5: Настройка виртуального хоста (рекомендуется)
На веб-сервере Nginx вы можете использовать виртуальные хосты (также они называются блоками server) для изоляции настроек и размещения нескольких доменов на одном сервере. Здесь используется условный домен example.com, но вы должны заменить его собственным доменом.
Nginx в Ubuntu 18.04 по умолчанию предоставляет один включенный виртуальный хост, который обслуживает каталог /var/www/html. Этого хватит для обслуживания одного сайта, но если вы хотите разместить несколько сайтов, вам нужно создать новые виртуальные хосты. Создайте структуру каталогов в /var/www для сайта example.com, а /var/www/html оставьте как каталог по умолчанию, который будет обслуживаться, если запрос клиента не соответствует другим сайтам.
Создайте каталог example.com, используя флаг -p для создания всех необходимых родительских каталогов:
Затем определите права на каталог с помощью переменной $USER:
Права должны быть установлены верно, если вы не меняли unmask, но на всякий случай вы можете их проверить:
Затем создайте образец страницы index.html с помощью nano или другого редактора:
Вставьте в файл:
Сохраните и закройте файл.
Чтобы Nginx мог обслуживать этот контент, необходимо создать файл виртуального хоста с правильными директивами. Вместо того чтобы напрямую изменять файл конфигурации по умолчанию, создайте новый файл /etc/nginx/sites-available/example.com.
Вставьте в файл следующие конфигурации. Они похожи на конфигурации по умолчанию, но содержат правильный домен и каталог:
Обратите внимание, что root содержит путь нового каталога, а server_name – новый домен, example.com. Сохраните и закройте файл
Сохраните и закройте файл.
Включите файл, создав симлинк в каталоге sites-enabled:
Теперь у вас есть два виртуальных хоста, которые будут обслуживать запросы клиентов на основе директив listen и server_name:
- example.com будет обслуживать запросы для www.example.com и example.com.
- default будет отвечать на запросы по порту 80, если они не соответствуют остальным виртуальным хостам.
Чтобы избежать возможных проблем с памятью, которые могут возникнуть в результате добавления дополнительных имен серверов, необходимо отредактировать одно значение в файле /etc/nginx/nginx.conf. Откройте файл:
Найдите строку server_names_hash_bucket_size и раскомментируйте ее, удалив символ #:
Проверьте ошибки в конфигурации Nginx:
Сохраните и закройте файл.
Перезапустите Nginx, чтобы активировать новые параметры:
Теперь Nginx обслуживает домен вашего сайта. Чтобы убедиться в этом, откройте ссылку http://example.com.
Общая настройка системы
Установка пакетов
1. Обновляем CentOS:
dnf update
2. Устанавливаем репозиторий EPEL и дополнительные пакеты для загрузки и распаковки:
dnf install epel-release wget unzip
Время
1. Устанавливаем часовой пояс:
\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime
* данной командой мы установим часовой пояс по московскому времени.
2. Устанавливаем и запускаем службу для автоматической синхронизации времени:
dnf install chrony
systemctl enable chronyd
systemctl start chronyd
Настройка безопасности
1. Отключаем SELinux:
sed -i «s/SELINUX=enforcing/SELINUX=disabled/» /etc/selinux/config
setenforce 0
* первая команда редактирует конфигурационный файл, чтобы SELinux не запускался автоматически, вторая — отключает его разово. Подробнее читайте статью Как отключить SELinux.
2. Открываем необходимые порты в брандмауэре:
firewall-cmd —permanent —add-port={80,443,8080}/tcp
firewall-cmd —permanent —add-port={20,21,60000-65535}/tcp
firewall-cmd —permanent —add-port={25,465,587}/tcp
firewall-cmd —reload
* 80, 443 и 8080 порты для веб-сервера; 20, 21 порты нужны для работы FTP; 60000-65535 также необходимы для работы FTP (динамические порты для пассивного режима); 25, 465 и 587 порты нужны для работы почтового сервера по SMTP; последняя команда перезапускает firewalld, чтобы применить новые правила. Подробнее про настройку firewalld.
Установка компонентов
Первым делом нужно установить сам веб-сервер в систему. Программа есть в официальных репозиториях, но ее версия уже немного устарела, поэтому если хотите самую новую версию, нужно добавить PPA:
Сейчас в официальных репозиториях доступна версия 1.10.0, а в стабильной PPA уже доступна 1.10.1. Если для вас версия не нужна можно обойтись и без PPA. Дальше обновите списки пакетов из репозиториев:
И устанавливаем ngnix:
После того как установка сервера Nginx будет завершена добавим программу в автозагрузку, чтобы она запускалась автоматически:
Если вы уже сейчас откроете браузер, то увидите работающий nginx, но нам предстоит его еще настроить.
9: Поддержка HTTPS с помощью Let’s Encrypt (опционально)
Теперь нужно создать SSL-сертификаты для сайтов Apache. Получите бесплатные доверенные сертификаты от Let’s Encrypt.
Nginx поддерживает терминацию SSL, потому можно настроить SSL, не изменяя настроек Apache.
Модуль mod_rpaf установит все переменные Apache, необходимые для поддержки SSL.
Для начала создайте для обоих доменов блок server {…}, чтобы у каждого из них был свой сертификат. Откройте /etc/nginx/sites-available/apache:
Отредактируйте файл, создав блок server для foobar.net and test.io:
Сертификаты TLS/SSL можно сгенерировать с помощью Certbot. Его плагин для Nginx автоматически перенастроит веб-сервер и обновит конфиг.
Установите официальный репозиторий Certbot:
Чтобы подтвердить действие, нажмите ввод. Затем обновите индекс пакетов.
Теперь можно установить Certbot для Nginx:
Затем используйте команду certbot, чтобы сгенерировать сертификаты для foobar.net и www.foobar.net:
С помощью этой команды Certbot сможет использовать плагин nginx; флаг –d позволяет указать домены, для которых предназначен сертификат.
Если это ваш первый запуск certbot, вам будет предложено ввести адрес электронной почты и согласиться с условиями обслуживания. После этого certbot свяжется с сервером Let’s Encrypt, а затем запустит проверку, чтобы убедиться, что домен, для которого вы запрашиваете сертификат, действительно принадлежит вам.
Затем Certbot спросит, нужно ли настроить HTTPS:
Сделайте свой выбор и нажмите ввод. Конфигурации обновятся, а Nginx будет перезапущен. Теперь запустите команду для второго домена:
Попробуйте открыть один из этих сайтов в браузере с префиксом https://.
На появившейся странице найдите раздел PHP Variables. Для переменной SERVER_PORT установлено значение 443, а HTTPS – on, как если бы веб-сервер Apache был напрямую доступен через HTTPS.
Теперь давайте отключим прямой доступ к Apache.
Шаг #4: Создание и настройка сервер-блоков Nginx
Для создания возможности обработки нескольких доменов на одном ip-адресе, веб-сервер Apache использует виртуальные хосты — это специальные файлы конфигурации веб-сервера, которые настраиваются отдельно для каждого домена. В веб-сервере Nginx также присутствует такая возможность, однако в терминологии Nginx виртуальные хосты называются сервер-блоками.
Создание директорий для сайта
По умолчанию, Nginx создает один сервер-блок настроенный для обработки файлов из директории , однако для создания самостоятельных сервер-блоков для каждого отдельного домена рекомендуется использовать директорию . Внутри каталога создадим новый каталог с именем вашего домена, внутри которого также добавим нужные подкаталоги — , где будут хранится файлы сайта и , где будут хранится логи работы веб-сервера.
Созданным директориям нужно присвоить владельца. Владельцем чаще всего назначается сам веб-сервер т.к. именно он проводит большинство операций с файлами.
Установка веб-сервера в качестве владельца особенно важна при установки каких-либо CMS-систем, например WordPress.
Так как нашим веб сервером будет Nginx, то и установим его в качестве владельца и группы. При необходимости группу можно будет заменить на любую удобную вам.
Также настроим права доступа для
Создание тестовой страницы.
Для проверки работоспособности будущего сервер-блока создадим главную страницу сайта — . При желании, вы можете создать полноценную html-разметку, однако я ограничусь простым текстом, которым заполню файл с помощью команды — echo.
Создание сервер-блока
Изначально Nginx содержит только один сервер-блок с именем — , его мы будет использовать в качестве шаблона для наших собственных сервер-блоков.
Создадим необходимые для работы каталоги и файл для настроек сервер-блока:
Файл может содержать следующие настройки:
server {
listen 80;
server_name example.ru www.example.ru;
set $root_path ‘/var/www/example.ru/www’;
root $root_path;
index index.php index.html;
location / {
try_files $uri $uri/ $uri.html $uri.php$is_args$query_string;
}
error_page 500 502 503 504 /50x.html;
error_page 404 /404.php;
location = /50x.html {root /usr/share/nginx/html;}
#location = /404.php {root $root_path;}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $request_filename;
include fastcgi_params;
fastcgi_intercept_errors on;
}
error_log /var/www/example.ru/log/nginx-error.log error;
}
|
1 |
server{ listen80; server_name example.ruwww.example.ru; set$root_path’/var/www/example.ru/www’; root$root_path; index index.phpindex.html; location{ try_files$uri$uri$uri.html$uri.php$is_args$query_string; } error_page50050250350450x.html; error_page404404.php; location=50x.html{rootusrsharenginxhtml;} #location = /404.php {root $root_path;} location~\.php${ fastcgi_pass127.0.0.19000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME$request_filename; include fastcgi_params; fastcgi_intercept_errors on; } error_logvarwwwexample.rulognginx-error.logerror; } |
Включение сервер-блоков
Теперь когда созданы сервер-блоки их нужно активировать, чтобы Nginx мог начать с ними работать.
Сделать это можно путем создания символической ссылки:
Убедитесь, что все конфигурационные файлы, для каждого домена, подключены в главном конфиге Nginx. Для этого в файле должна присутствовать следующая строка.
Теперь, если все предыдущие этапы выполнены без ошибок, то вы можете зайти на страницу сайта, введя имя домена в адресную строку, в моем случае это example.ru.
Nginx выдал страницу для сайта example.ru
10: Блокирование прямого доступа к Apache (опционально)
Apache слушает порт 8080 на внешнем IP-адресе, потому доступ к нему может получить любой желающий. Этот доступ можно заблокировать с помощью брандмауэра IPtables.
Примечание: Вместо your_server_ip укажите IP-адрес сервера.
Теперь порт 8080 блокируется брандмауэром, и доступ к Apache закрыт.
Откройте браузер и попробуйте получить доступ к одному из сайтов Apache.
Браузер должен выдать сообщение об ошибке Unable to connect или Webpage is not available. Директива tcp-reset позволяет скрыть от посторонних разницу между портами.
Примечание: Правила IPtables сбрасываются при каждой перезагрузке сервера. Чтобы сохранить их, используйте iptables-persistent.
2: Настройка брандмауэра
Прежде чем протестировать Nginx, нужно разблокировать его трафик в брандмауэре ufw. Во время установки Nginx регистрирует в ufw профиль своего сервиса, потому открыть его трафик будет несложно.
Откройте список доступных профилей ufw:
В этом списке вы найдете три профиля Nginx:
- Nginx Full: открывает порт 80 (незашифрованный сетевой трафик) и 443 (зашифрованный трафик TLS/SSL).
- Nginx HTTP: открывает незашифрованный трафик HTTP на порт 80.
- Nginx HTTPS: для зашифрованного трафика TLS/SSL на порт 443.
Лучше использовать профиль, который поддерживает шифрование. Но поскольку на свежем сервере ещё не настроен SSL, мы можем открыть только порт 80.
Чтобы включить соответствующий профиль, введите:
Убедитесь в том, что профиль включился:
Команда должна показать, что трафик HTTP разблокирован:
Настройка серверных блоков NGINX
Если вы хотите разместить несколько веб-сайтов на одном веб-сервере NGINX, то вам нужно будет настроить серверные блоки. Серверные блоки также называются виртуальными хостами (в основном в Apache).
NGINX предварительно сконфигурирован только с одним блоком сервера. И именно там хранятся сведения о конфигурации для веб—сайта по умолчанию (/etc/nginx/sites-available) (/var/www/html).
Давайте посмотрим:
Выполните следующую команду, для того чтоб отобразить содержимое файла блока сервера по умолчанию.
Нажмите пробел на клавиатуре, чтобы прокрутить страницу вниз. Вы увидите сведения о конфигурации сервера по умолчанию. Например такие данные как номер порта прослушивания, корневой каталог документа (т. е. базовая папка для хранения содержимого веб-сайта), индексный файл и имя сервера.
Вы также должны увидеть раздел под названием конфигурация виртуального хоста, как показано ниже.
Вы можете настроить свой дополнительный веб-сайт здесь, но лучше создать отдельный файл блока сервера и оставить файл по умолчанию как есть.
А пока скопируйте приведенный выше пример конфигурации и сохраните его в текстовом редакторе. Так как мы будем использовать эту информацию в ближайшее время.
Создать корень сайта
Далее вам нужно будет создать корневую папку в разделе /var / www . Это делается для хранения содержимого вашего дополнительного веб-сайта. Например, я собираюсь создать папку с именем domain1.com.
Создание индексного файла
Индексный файл — это главная веб-страница, которая отображается при открытии веб-сайта. Выполните следующую команду, чтобы создать индексный файл для вашего дополнительного веб-сайта.
В этом примере я использую nano, но вы можете использовать свой любимый текстовый редактор. Вы можете скопировать и вставить следующий HTML код для тестирования.
Сохраните изменения и закройте текстовый редактор.
Создание серверного блока
Следующим шагом является создание файла серверного блока. Предназначен он для хранения сведений о конфигурации дополнительного веб-сайта. Выполните следующую команду.
Скопируйте пример конфигурации виртуального хоста сохраненного ранее и вставьте его в новый файл. Начиная со строки «server», убедитесь, что вы удалили все символы #. Чтобы раскомментировать директивы. Кроме того, не забудьте заменить “domain1” на ваше собственное зарегистрированное доменное имя соответственно.
Сохраните изменения и закройте этот файл.
Включить серверный блок
Чтобы NGINX знал, что дополнительный веб-сайт доступен, выполните следующую команду для создания символической ссылки на файл блока сервера.
Проверьте свою конфигурацию
Запустите sudo nginx-t, чтобы проверить конфигурацию блока сервера. Вы должны увидеть сообщение, указывающее, что все в порядке.
Вы можете запустить sudo service nginx reload, чтобы перезагрузить файлы конфигов.
Протестируйте свой новый сайт
Откройте веб-браузер и введите свой новый адрес веб-сайта. Вы должны увидеть содержимое индексного файла, созданного для вашего нового веб-сайта. А не веб-страницу NGINX по умолчанию.
Хостинг дополнительного сайта с использованием серверного блока
Настройка хостинга
На предыдущем шаге представлена ссылка на статью, по которой мы сконфигурировали полноценный веб-сервер. Но для хостинга необходимо внести некоторые дополнительные настройки.
Общий пользователь
Так как к одним и тем же каталогам необходимы права доступа для nginx и apache, создаем общую группу и добавим в нее учетные записи, от которых работают данные веб-сервисы.
Добавим группу virtwww:
groupadd virtwww
Задаем созданную группу как дополнительную для apache и nginx:
usermod apache -G virtwww
usermod nginx -G virtwww
Запуск виртуальных доменов от определенного пользователя
Чтобы каждый виртуальный домен apache мог работать от отдельного пользователя, устанавливаем модуль httpd-itk:
yum install httpd-itk
После открываем следующий файл:
vi /etc/httpd/conf.modules.d/00-mpm-itk.conf
и снимаем комментарий для LoadModule — получится:
LoadModule mpm_itk_module modules/mod_mpm_itk.so
Настройка Apache
Добавим разрешения на каталоги, в которых будут храниться файлы сайтов:
vi /etc/httpd/conf/httpd.conf
<Directory /var/www/*/*/www>
AllowOverride All
Options Indexes ExecCGI FollowSymLinks
Require all granted
</Directory>
<Directory /var/www/*/*/cgi>
AllowOverride All
Options Indexes ExecCGI FollowSymLinks
Require all granted
</Directory>
* по предложенной статье права были выданы на каталоги /var/www/*/www, для хостинга мы будем использовать немного другую вложенность.
Тюнинг веб-сервера
PHP
Открываем на редактирование следующий файл:
vi /etc/php.ini
И правим следующее:
upload_max_filesize = 256M
post_max_size = 256M
short_open_tag = On
date.timezone = «Europe/Moscow»
Перезапускаем php-fpm и httpd:
systemctl restart php-fpm
systemctl restart httpd
NGINX
Открываем на редактирование следующий файл:
vi /etc/nginx/nginx.conf
И правим следующее:
worker_processes auto;
И внутри секции http добавляем:
client_max_body_size 256M;
После перезапускаем nginx:
systemctl restart nginx
Подробнее про тюнинг NGINX в статье Практические советы по тюнингу веб-сервера NGINX.
Postfix
Чтобы отправляемая почта меньше попадала в СПАМ, необходимо выполнить следующие шаги:
- Прописать PTR-запись.
- Создать запись SPF.
- Настроить DKIM.
Apache (httpd)
Несмотря на то, что мы установили и настроили PHP-FPM, Apache нам понадобится, как минимум, по двум причинам. Во-первых, многие сайты используют файл .htaccess, который читает только Apache. Во-вторых, последний включает большое число модулей, которые может использовать портал.
В некоторых случаях, можно обойтись без Apache, но в данной инструкции мы опишем процедуру его установки и настройки.
И так, устанавливаем httpd:
yum install httpd
Заходим в настройки:
vi /etc/httpd/conf/httpd.conf
И редактируем следующее:
Listen 8080
* наш веб-сервер будет слушать на порту 8080, так как на 80 уже работает NGINX.
<IfModule dir_module>
DirectoryIndex index.php index.html
</IfModule>
* если не указан конкретный скрипт, сначала веб-сервер пытается найти и запустить index.php, затем index.html
Добавляем:
<Directory /var/www/*/www>
AllowOverride All
Options Indexes ExecCGI FollowSymLinks
Require all granted
</Directory>
* где Directory — разрешенные каталоги для запуска из apache; Options — разрешенные опции; Require — с каких IP-адресов можно открывать сайты, определенные в данном каталоге. Итого, мы разрешаем все каталоги в /var/www, но только если следующий каталог будет www; разрешаем опции Indexes (возвращает список файлов, если нет индексного файла, например, index.php), ExecCGI (разрешены сценарии CGI), FollowSymLinks (включены символические ссылки в этом каталоге); доступ для данных каталого разрешен со всех адресов (all granted).
Проверяем синтаксис конфигурационного файла httpd:
apachectl configtest
Разрешаем автозапуск и запускаем службу:
systemctl enable httpd —now
Создаем php-файл со следующим содержимым:
vi /var/www/html/index.php
<?php phpinfo(); ?>
Открываем браузер и вводим в адресную строку IP-адрес нашего сервера и добавляем :8080. Мы должны увидеть привычную страницу:
NGINX + Apache
Ранее нами была настроена связка nginx + php-fpm. Теперь проверяем совместную работу первого с apache.
Открываем конфигурационный файл nginx:
vi /etc/nginx/conf.d/default.conf
* если при настройке nginx мы редактировали файл /etc/nginx/nginx.conf, то необходимо открыть его.
Находим наш настроенный location для php-fpm:
…
location ~ \.php$ {
fastcgi_pass unix:/run/php-fpm/www.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
Пробуем открыть в браузере IP-адрес нашего сервера — должна открыться та же страница, что при проверке Apache (с добавлением 8080):
Apache Real IP
Так как все запросы на httpd приходят от NGINX, они воспринимаются как от IP-адреса 127.0.0.1. На практике, это может привести к проблемам, так как некоторым сайтам необходимы реальные адреса посетителей.
Для решения проблемы будем использовать модуль mod_rpaf. Устанавливаем набор разработчика для apache:
yum install httpd-devel gcc unzip
Переходим в каталог /usr/local/src:
cd /usr/local/src
Скачиваем модуль:
wget https://github.com/gnif/mod_rpaf/archive/stable.zip
Распаковываем его:
unzip stable.zip
Переходим в распакованный каталог:
cd mod_rpaf-stable/
Собираем модуль и устанавливаем его:
make
make install
* при возникновении ошибки ./apxs.sh: line 15: -c: command not found, необходимо поставить which командой yum install which.
Создаем конфигурационный файл со следующим содержимым:
vi /etc/httpd/conf.d/mod_rpaf.conf
LoadModule rpaf_module modules/mod_rpaf.so
RPAF_Enable On
RPAF_ProxyIPs 127.0.0.1
RPAF_SetHostName On
RPAF_SetHTTPS On
RPAF_SetPort On
RPAF_ForbidIfNotProxy Off
Перезапускаем httpd:
systemctl restart httpd
Для проверки настройки открываем на редактирование созданный index-файл для httpd:
vi /var/www/html/index.php
И редактируем содержимое на:
<?php echo $_SERVER ?>
Открываем браузер и вводим в адресную строку IP-адрес нашего сервера. Мы должны увидеть внешний адрес компьютера, с которого обращаемся к серверу.
