Собственный веб-сервер для сайтов
Рано или поздно каждый уважающий себя веб-разработчик приходит к осознанию факта о том, что иметь свой собственный хостинг под разрабатываемые сайты гораздо удобнее иметь свой собственный хостинг, где есть всё необходимое: веб-сервер, PHP разных версий, MySQL и, даже, среда разработки Node.js.
Ну а если говорить не о веб-разработчиках, а о системных администраторах, то всегда удобно иметь под рукой веб-сервер, на котором можно проверить и «обкатать» разные корпоративные решения, доработки корпоративных сайтов, обновления, дополнения и разные прочие -ия.
Сложно ли это? Нет. Дорого? Лет 10-15 назад это еще можно было считать относительно дорогим удовольствием. Сегодня — скорее, вопрос уровня профессионализма. Чем метаться от одного бесплатного хостинга к другому, или вечно скакать между хостинг-провайдерами в поисках более выгодных демо-тарифов, лучше бы немного раскошелиться на VPS/VDS-хостинг, ну, или, на худой конец, у себя на компьютере на виртуальной машине «поднять» такой сервер. Сегодня это может сделать любой счастливый обладатель компьютера с Windows 10/11 Pro. Гипервизор Hyper-V сегодня является одним из стандартных компонентов Windows.
Подготовка сервера
Мы создадим сервер на виртуальной машине в гипервизоре Proxmox. Для виртуальной машины установлены следующие параметры:
- Операционная система: Ubuntu Server 22.04;
- BIOS: OVMF (UEFI);
- Использование TPM;
- Накопитель: виртуальный SATA-диск с эмуляцией SSD на 64 ГБ, тип кэширования Write back;
- Процессор: 1 сокет, 2 ядра, тип Host c активным флагом aes;
- Оперативная память: 6ГБ.
Для подключения к виртуальной машине мы используем PuTTY, а авторизация пользователей происходит с помощью RSA-ключей. Можем переходить к настройке сервисов на нашем сервере.
Необходимые приложения
После первого запуска сервера нужно установить приложения, без которых не обойтись. Мы используем файловый менеджер Midnight Commander, чего и вам желаем.
# Устанавливаем доступные обновления для пакетов и приложений
sudo apt update
sudo apt upgrade
# Для отслеживания нагрузки и отправки почты из терминала
sudo apt install -y mytop mailutils
# Установка часового пояса
sudo timedatectl set-timezone Europe/Moscow
# Файловый менеджер Midnight Commander
sudo apt install -y mc
Устанавливаем веб-сервер Nginx
Запросы к нашему серверу на 80 и 443 порты будет обрабатывать Nginx. Некоторые CMS лучше себя «чувствуют», если за их работу несёт ответственность Apache, поэтому в каких-то случаях такие запросы Nginx будет проксировать на Apache.
# Устанавливаем nginx
sudo apt install -y nginx
# Останавливаем nginx
systemctl stop nginx
Устанавливаем веб-сервер Apache
Apache на нашем сервере будет работать как бэкенд для Nginx. Поэтому на прямые запросы к серверу на 80 и 443 порты он отвечать не будет.
# Устанавливаем apache2
sudo apt install -y apache2
# Останавливаем Apache2
systemctl stop apache2
Устанавливаем интерпретатор PHP
PHP мы будем использовать в режиме FPM. Устанавливать будем версию 8.2.
# Устанавливаем требуемые зависимости
sudo apt install -y software-properties-common
# Подключаем репозиторий с доступным PHP 8.2
sudo add-apt-repository ppa:ondrej/php -y
# Обвноляем перечень доступных пакетов
sudo apt update
# Обвноляем установленные пакеты
sudo apt upgrade
# Устанавливаем PHP и требуемые для него дополнительные пакеты
sudo apt install -y \
php8.2-fpm \
php8.2-cli \
php8.2-common \
php8.2-mysql \
php8.2-curl \
php8.2-gd \
php8.2-mbstring \
php8.2-xml \
php8.2-zip \
php8.2-bz2 \
php8.2-intl \
php8.2-soap \
php8.2-opcache \
php8.2-readline \
php8.2-sqlite3 \
php8.2-xsl \
php8.2-ldap \
php8.2-gmp \
php8.2-imap \
php8.2-apcu \
php8.2-imagick
# После установки останавливаем PHP FPM
sudo systemctl stop php8.2-fpm
Устанавливаем СУБД MariaDB
Мы будем использовать не СУБД MySQL, а её форк — MariaDB.
# Устанавливаем требуемые пакеты для работы СУБД
sudo apt install -y mariadb-server mariadb-client mariadb-tools
# После установки запускаем начальную настройку СУБД
sudo mysql_secure_installation
После запуска скрипта первоначальной настройки вам будет предложено ответить на несколько вопросов. Ничего сложного и непонятного в них нет. Мы приведем пример с нашими ответами на них.
##########################
# Сначала будет предложено установить пароль для суперпользователя СУБД
##########################
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!
In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
haven't set the root password yet, you should just press enter here.
Enter current password for root (enter for none):
OK, successfully used password, moving on...
##########################
# Так как мы установили пароль суперпользователя, можно не использовать аутентификацию через UNIX-сокет
##########################
Setting the root password or using the unix_socket ensures that nobody
can log into the MariaDB root user without the proper authorisation.
You already have your root account protected, so you can safely answer 'n'.
Switch to unix_socket authentication [Y/n]
... skipping.
##########################
# Удаляем всех анонимных пользователей СУБД
##########################
By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.
Remove anonymous users? [Y/n]
... Success!
##########################
# Отключаем возможность авторизации суперпользователя с удаленных серверов
##########################
Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n]
... Success!
##########################
# Удаляем тестовую базу данных MariaDB
##########################
By default, MariaDB comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.
Remove test database and access to it? [Y/n]
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!
##########################
# Применяем сделанные изменения
##########################
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
Reload privilege tables now? [Y/n]
... Success!
Cleaning up...
#########################
# Первоначальная настройка СУБД окончена
#########################
All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.
Thanks for using MariaDB!
После этого, так как мы ограничили возможность работы с MariaDB для суперпользователя, нам необходимо создать учетную запись, у которой будут полномочия, аналогичные суперпользователю.
# Подключаемся к консоли mysql
sudo mysql -u root -p
Enter password:
После подключения к консоли mysql вам потребуется выполнить несколько запросов
--- Не забудьте заменить значения на логин и пароль для вашей учётной записи
CREATE USER 'super_user'@'localhost' IDENTIFIED BY 'StrongPassword123!';
-- Базовые административные права (без создания пользователей)
GRANT ALL PRIVILEGES ON *.* TO 'super_user'@'localhost' WITH GRANT OPTION;
--- После этого
FLUSH PRIVILEGES;
EXIT;
Проверяем вход от имени нового пользователя СУБД
mysql -u super_user -p
Enter password:
Для выхода из консоли необходимо использовать команды консоли mysql quit;
или exit;
# Запускаем mariadb при старте системы
sudo systemctl enable mariadb
Настраиваем Apache как бэкенд для Nginx
Чтобы Apache работал как бэкенд для Nginx, ему нужно изменить прослушиваемые порты: 8080 для http и 8443 для https. Можете установить свои значения портов.
# Редактируем файл с перечнем прослушиваемых apache2 портов
sudo mcedit /etc/apache2/ports.conf
# Меняем…
Listen 80 -> Listen 8080
Listen 443 -> Listen 8443
# Сохраняем файл, закрываем его
# Открываем основной файл конфигурации Apache
sudo mcedit /etc/apache2/apache2.conf
# Нужно убедиться, что в нем присутствует директива
AccessFileName .htaccess
# Добавляем в конец файла
ServerName localhost
Даллее нам требуется подключить требуемые модули Apache
sudo a2enmod \
access_compat \
alias \
auth_basic \
authn_core \
authn_file \
authz_core \
authz_host \
authz_user \
autoindex \
deflate \
dir \
env \
filter \
headers \
mime \
mpm_prefork \
negotiation \
proxy \
proxy_fcgi \
remoteip \
reqtimeout \
rewrite \
setenvif \
socache_shmcb \
ssl \
status
# Включаем запуск apache2 при старте системы
sudo systemctl enable apache2
# Запускаем службу
sudo systemctl start apache2
Теперь нам нужно убедиться в том, что Apache слушает требуемые для нас порты.
sudo ss -tulnp | grep apache
# Должны увидеть примерно следующиий ответ
tcp LISTEN 0 511 *:8443 *:* users:(("apache2",pid=33747,fd=6),("apache2",pid=33746,fd=6),("apache2",pid=33745,fd=6))
tcp LISTEN 0 511 *:8080 *:* users:(("apache2",pid=33747,fd=4),("apache2",pid=33746,fd=4),("apache2",pid=33745,fd=4))
Запускаем PHP 8.2 FPM
# Включаем запуск сервиса при старте системы
sudo systemctl enable php8.2-fpm
# Запускаем сервис
sudo systemctl start php8.2-fpm
# Проверяем, работает ли fpm-сокет
sudo ls -la /var/run/php/php-fpm.sock
# Должны увидеть примерно следующиий ответ
lrwxrwxrwx 1 root root 30 Jun 17 08:54 /var/run/php/php-fpm.sock -> /etc/alternatives/php-fpm.sock
Установка Let's Encrypt для получения SSL-сертификатов
Чтобы была возможность получения SSL-сертификатов для ваших сайтов, если у вас нет собственной PKI-инфраструктуры или приобретенного коммерческого SSL-сертификата, установим certbot от Let's Encrypt.
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
Настройка веб-сервера Nginx
# Редактируем основной конфигурационный файл nginx
sudo mcedit /etc/nginx/nginx.conf
# Добавляем директивы в секцию http
client_max_body_size 16M;
upstream apache_backend {
server 127.0.0.1:8443;
}
# В раздел для SSL добавляем
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
# Сохраняем файл, закрываем его
# Включаем запуск nginx при старте системы
sudo systemctl enable nginx
# Запускаем сервис nginx
sudo systemctl start nginx
# Проверяем, какие порты слушает nginx
sudo ss -tulnp | grep nginx
# Ответ должен быть примерно таким
tcp LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=34576,fd=6),("nginx",pid=34575,fd=6),("nginx",pid=34574,fd=6))
tcp LISTEN 0 511 [::]:80 [::]:* users:(("nginx",pid=34576,fd=7),("nginx",pid=34575,fd=7),("nginx",pid=34574,fd=7))
# Прослушивание порта 443 будем включать для виртуальных хостов отдельно
Для каждого из обслуживаемых доменов будем создавать внутри свой каталог. Если обслуживается домен третьего уровня, внутри каталога домена создаем его каталог с префиксом __.
Внутри каждого каталога виртуального хоста будут каталоги:
- logs – для логов веб-сервера;
- php – для подключаемых файлов сценариев через директиву include_path;
- ssl – сертификаты виртуального хоста;
- www – для исходных файлов сайтов;
У нас на сервере, пока что, будут работать только два сайта: тестовый сайт (на локальном домене waf.lezh.loc) и сайт для работы phpMyAdmin (на локальном домене pma.waf.lezh.loc). Создаем необходимую структуру каталогов.
# Для виртуального хоста waf.lezh.loc
mkdir -p /var/www/lezh.loc/__waf
# Каталоги для логов, исходных файлов сайта и прочие
mkdir -p /var/www/lezh.loc/__waf/{logs,php,ssl,www}
# Для виртуального хоста pma.waf.lezh.loc
mkdir -p /var/www/lezh.loc/__waf/__pma
# Каталоги для логов, исходных файлов сайта и прочие
mkdir -p /var/www/lezh.loc/__waf/__pma/{logs,php,ssl,www}
# Устанавливаем владельца каталогов рекурсивно
chown -R www-data:www-data /var/www/lezh.loc
Установка phpMyAdmin
Для удоства взаимодействия с СУБД и администрирования баз данных мы будем использовать phpMyAdmin.
# Переходим в каталог исходных файлов сайта для phpMyAdmin
cd /var/www/lezh.loc/__waf/__pma/www
# Скачиваем phpMyAdmin
sudo wget https://files.phpmyadmin.net/phpMyAdmin/5.2.2/phpMyAdmin-5.2.2-all-languages.tar.gz
# Распаковываем архив
sudo tar -xvf phpMyAdmin-5.2.2-all-languages.tar.gz
# Удаляем файл архива после распаковки
sudo rm phpMyAdmin-5.2.2-all-languages.tar.gz
# Перемещаем все файлы phpMyAdmin в корень сайта
sudo mv phpMyAdmin-5.2.2-all-languages/* ./
# Удаляем ненужный каталог скачанных ранее исходников phpMyAdmin
sudo rm -rf phpMyAdmin-5.2.2-all-languages
Создаем виртуальный хост Nginx для phpMyAdmin.
phpMyAdmin у нас будет работать только через Nginx. Ему Apache не требуется.
# Создаем виртуальный хост Nginx для phpMyAdmin
sudo mcedit /etc/nginx/sites-available/pma.lezh.loc
# Записываем в него такой конфиг
# Секция для обработки http-запросов
server {
# Для ответов на запросы к 80-му порту
listen 80;
# Отвечаем на запросы такого доменного имени
server_name pma.waf.lezh.loc;
# Ведём запись ошибок и доступа в отдельные файлы логов
access_log /var/www/lezh.loc/__waf/__pma/logs/nginx.access.log;
error_log /var/www/lezh.loc/__waf/__pma/logs/nginx.error.log;
# Путь к корневому каталогу сайта phpMyAdmin
root /var/www/lezh.loc/__waf/__pma/www;
# Указываемый индексный файл
index index.php;
# Обрабатываем все запросы к серверу
location / {
try_files $uri $uri/ =404;
}
# Все запросы к файлам .php-сценариев передаем в PHP 8.2 FPM
location ~ \.php$ {
include snippets/fastcgi-php.conf;
# PHP 8.2 FPM у нас работает на UNIX-сокете
fastcgi_pass unix:/var/run/php/php-fpm.sock;
}
}
# Секция для обработки https-запросов
server {
# Для ответов на запросы к 443 порту
listen 443 ssl http2;
# Отвечаем на запрос этого доменного имени
server_name pma.waf.lezh.loc;
# Пути к файлам SSL-сертификата и файлу закрытого ключа для сайта
ssl_certificate /var/www/lezh.loc/__waf/__pma/ssl/fullchain.pem;
ssl_certificate_key /var/www/lezh.loc/__waf/__pma/ssl/privkey.pem;
# Ведём запись ошибок и доступа в отдельные файлы логов
access_log /var/www/lezh.loc/__waf/__pma/logs/nginx.access-ssl.log;
error_log /var/www/lezh.loc/__waf/__pma/logs/nginx.error-ssl.log;
# Путь к корневому каталогу сайта
root /var/www/lezh.loc/__waf/__pma/www;
# Указываем индексный файл для сервера
index index.php;
# Обрабатываем все запросы к серверу
location / {
try_files $uri $uri/ =404;
}
# Все запросы к файлам .php-сценариев передаем в PHP 8.2 FPM
location ~ \.php$ {
include snippets/fastcgi-php.conf;
# PHP 8.2 FPM у нас работает на UNIX-сокете
fastcgi_pass unix:/var/run/php/php-fpm.sock;
}
}
# Сохраняем файл, закрываем его
Подключаем виртуальный хост phpMyAdmin к работе Nginx.
sudo ln -s /etc/nginx/sites-available/pma.lezh.loc /etc/nginx/sites-enabled/
# Проверяем конфиг
nginx -t
# Должны увидеть примерно следующиий ответ
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# Если есть ошибки, исправьте их. Если ошибок нет, перезапускаем Nginx
sudo systemctl restart nginx
# Убедимся, что запущен и php8.2-fpm
sudo systemctl status php8.2-fpm
После этого можно открыть в браузере: http://pma.waf.lezh.loc/setup/ или https://pma.waf.lezh.loc/setup/. Откроется страница настройки phpMyAdmin.
Создаем Новый сервер.
Основные настройки
Указываем пользовательское имя: pma.waf.lezh.loc
Параметры сервера
Отключаем вход для root
Хранение конфигурации
Указываем рекомендуемые параметры, а в полях для пользователя укажите ту учетную запись и её пароль, которую вы создавали для MySQL.
Нажимаем Применить.
Если есть ошибки, исправьте их. Если ошибок нет, переименуйте или удалите каталог setup внутри файлов сайта для phpMyAdmin.
Всего этого хватит для работы phpMyAdmin. Можно переходить по адресу https://pma.waf.lezh.loc, авторизоваться, и работать с СУБД.
Создаем виртуальные хосты для тестового сайта
Теперь создадим виртуальный хост для сайта, куда установим CMS 1С-Битрикс.
В отличие от сайта для phpMyAdmin этот виртуальный хост будет использовать Apache как бэкенд.
# Сначала создаем конфиг виртуального хоста Nginx
sudo mcedit /etc/nginx/sites-available/waf.lezh.loc
# Записываем в него такой конфиг
# Секция для обработки http-запросов
server {
# Отвечаем на запросы к 80 порту
listen 80;
# Обрабатываем запросы к этим доменным именам
server_name waf.lezh.loc www.waf.lezh.loc;
# Ведём запись доступа и ошибок в отдельные файлы логов
access_log /var/www/lezh.loc/__waf/logs/nginx.access.log;
error_log /var/www/lezh.loc/__waf/logs/nginx.error.log;
# Указываем путь к корневому каталогу сайта
root /var/www/lezh.loc/__waf/www;
# Указываем инлексный файл
index index.php;
# Заставляем пользовательские браузеры строго следовать полученному MIME-типу файлов
add_header X-Content-Type-Options nosniff;
# Ограничиваем максимальный размер тела запроса к веб-серверу
client_max_body_size 256M;
# Обрабатываем все запросы к серверу, передавая их в бэкенд
location / {
try_files $uri/ =404 @proxy_to_apache;
}
# Описываем параметры бэкенда
location @proxy_to_apache {
proxy_pass http://127.0.0.1:8080; # Куда передаём запрос
proxy_set_header Host $host; # Устанавливаем заголовок Host
proxy_set_header X-Real-IP $remote_addr; # Передаем в заголовке реальный IP-адрес пользовательского запроса
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # IP-адрес оригинального клиента при проксировании запросов
# Значения таймаутов для проксируемых запросов
proxy_connect_timeout 120;
proxy_read_timeout 120;
}
}
# Секция для обработки https-запросов
server {
# Отвечаем на запросы к 443 порту
listen 443 ssl http2;
# Отвечаем на запросы к этим доменным именам
server_name waf.lezh.loc www.waf.lezh.loc;
# Ведём запись доступа и ошибок в отдельные файлы логов
access_log /var/www/lezh.loc/__waf/logs/nginx.access-ssl.log;
error_log /var/www/lezh.loc/__waf/logs/nginx.error-ssl.log;
# Указываем путь к файлам SSL-сертификата и закрытого ключа сертификата для сайта
ssl_certificate /var/www/lezh.loc/__waf/ssl/fullchain.pem;
ssl_certificate_key /var/www/lezh.loc/__waf/ssl/privkey.pem;
# Путь к корневому каталогу сайта
root /var/www/lezh.loc/__waf/www;
# Указываем индексный файл
index index.php;
# Заставляем пользовательские браузеры строго следовать полученному MIME-типу файлов
add_header X-Content-Type-Options nosniff;
# Ограничиваем максимальный размер тела запроса к веб-серверу
client_max_body_size 256M;
# Обрабатываем все запросы к серверу, передавая их в бэкенд
location / {
try_files $uri/ =404 @proxy_to_apache;
}
# Статический контент сайта отдаем сразу средствами Nginx
location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|ttf|eot|pdf)$ {
access_log off;
expires 30d;
add_header Cache-Control public;
# Все файлы, что не удалось отдать, передаём в бэкенд
try_files $uri @proxy_to_apache;
}
# Параметры бэкенда
location @proxy_to_apache {
proxy_pass https://127.0.0.1:8443; # Куда передаём запрос
proxy_set_header Host $host; # Устанавливаем заголовок Host
proxy_set_header X-Real-IP $remote_addr; # Передаем в заголовке реальный IP-адрес пользовательского запроса
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # IP-адрес оригинального клиента при проксировании запросов
# Значения таймаутов для проксируемых запросов
proxy_connect_timeout 120;
proxy_read_timeout 120;
}
}
# Сохраняем файл, закрываем его.
Подключам виртуальный хост нашего тестового сайта к работе Nginx.
ln -s /etc/nginx/sites-available/waf.lezh.loc /etc/nginx/sites-enabled/
# Проверяем на отсутствие ошибок, перезапускаем nginx
nginx -t
# Должны увидеть примерно следующиий ответ
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Переходим к созданию виртуального хоста тестового сайта для Apache.
# Создаем конфиг виртуального хоста Apache
sudo mcedit /etc/apache2/sites-available/waf.lezh.loc.conf
# Записываем в него такое содержимое
# Для обработки http-запросов
<VirtualHost *:8080>
# Заголовок для определения реального IP клиента
RemoteIPHeader X-Real-IP
# Адрес 127.0.0.1 является внутренним прокси
RemoteIPInternalProxy 127.0.0.1
# Сервер отвечает на следующие доменные имена
ServerName waf.lezh.loc
ServerAlias www.waf.lezh.loc
# Путь к корневому каталогу сервера
DocumentRoot /var/www/lezh.loc/__waf/www
# Ведем запись доступ и ошибок в отдельные файлы логов
CustomLog "/var/www/lezh.loc/__waf/logs/apache.access.log" common
ErrorLog "/var/www/lezh.loc/__waf/logs/apache.error.log"
# Устанавливаем таймаут для ответа
Timeout 118
# Ограничиваем максимальный разме тела запроса
LimitRequestBody 262144
# Файлы php-сценариев обрабатываем с помощью PHP 8.2 FPM
<FilesMatch \.php$>
SetHandler "proxy:unix:/var/run/php/php-fpm.sock|fcgi://localhost"
</FilesMatch>
# Для получения ответа от PHP 8.2 FPM устанавливаем таймаут
<Proxy "unix:/var/run/php/php-fpm.sock|fcgi://localhost">
ProxySet connectiontimeout=115 timeout=115
</Proxy>
# Настраиваем корневой каталог сайта
<Directory /var/www/lezh.loc/__waf/www >
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted
AddDefaultCharset utf-8
DirectoryIndex index.html index.php
# Блокировка доступа к .git
RedirectMatch 403 \/\.git(\/|$)
# Блокировка файлов внутри .git (например, config, HEAD)
<FilesMatch "\.(git|gitignore|gitmodules|gitattributes)$">
Require all denied
</FilesMatch>
</Directory>
</VirtualHost>
# Для обработки https-запросов
<VirtualHost *:8443>
# Заголовок для определения реального IP клиента
RemoteIPHeader X-Real-IP
# Адрес 127.0.0.1 является внутренним прокси
RemoteIPInternalProxy 127.0.0.1
# Сервер отвечает на следующие доменные имена
ServerName waf.lezh.loc
ServerAlias www.waf.lezh.loc
# Путь к корневому каталогу сервера
DocumentRoot /var/www/lezh.loc/__waf/www
# Ведем запись доступ и ошибок в отдельные файлы логов
CustomLog "/var/www/lezh.loc/__waf/logs/apache.access-ssl.log" common
ErrorLog "/var/www/lezh.loc/__waf/logs/apache.error-ssl.log"
# Устанавливаем таймаут для ответа
Timeout 118
# Ограничиваем максимальный разме тела запроса
LimitRequestBody 262144
# Включаем работу модуля SSL
SSLEngine on
# Указываем путь к файлам SSL-сертификата и закрытого ключа для сертификата сайта
SSLCertificateFile /var/www/lezh.loc/__waf/ssl/fullchain.pem
SSLCertificateKeyFile /var/www/lezh.loc/__waf/ssl/privkey.pem
# Файлы php-сценариев обрабатываем с помощью PHP 8.2 FPM
<FilesMatch \.php$>
SetHandler "proxy:unix:/var/run/php/php-fpm.sock|fcgi://localhost"
</FilesMatch>
# Для получения ответа от PHP 8.2 FPM устанавливаем таймаут
<Proxy "unix:/var/run/php/php-fpm.sock|fcgi://localhost">
ProxySet connectiontimeout=115 timeout=115
</Proxy>
# Настраиваем корневой каталог сайта
<Directory /var/www/lezh.loc/__waf/www >
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted
AddDefaultCharset utf-8
DirectoryIndex index.html index.php
# Блокировка доступа к .git
RedirectMatch 403 \/\.git(\/|$)
# Блокировка файлов внутри .git (например, config, HEAD)
<FilesMatch "\.(git|gitignore|gitmodules|gitattributes)$">
Require all denied
</FilesMatch>
</Directory>
</VirtualHost>
# Сохраняем файл, закрываем.
Подключаем виртуальных хост к Apache.
sudo a2ensite waf.lezh.loc
# Проверяем на отсутствие ошибок. Если ошибок нет, перезапускаем Apache
sudo apachectl configtest
sudo systemctl restart apache2
Установка CMS 1С-Битрикс на виртуальный хост
на наш виртуальный хост для тестового сайта мы установим экземпляр CMS 1С-Битрикс в редакции Стандарт.
# Переходим в корневой каталог тестового сайта
sudo cd /var/www/lezh.loc/__waf/www
# Скачиваем CMS 1С-Битрикс Стандарт
sudo wget https://www.1c-bitrix.ru/download/standard_encode.tar.gz
# Распаковываем архив
sudo tar -xzf standard_encode.tar.gz
# Удаляем файл архива
sudo rm standard_encode.tar.gz
# Устанавливаем владельца каталогов всех сайтов рекурсивно
sudo chown -R www-data:www-data /var/www/lezh.loc
Теперь можно открыть в браузере: http://waf.lezh.loc/
И если вы видите в браузере следующее...
short_open_tag value must be turned on in you php.ini or .htaccess file.
Please modify the server's configuration or contact administrator of your hosting.
...не занимаемся ерундой, следуя вредному совету про файл .htaccesss
, а включаем соответствующий параметр в php.ini
.
#
sudo mcedit /etc/php/8.2/fpm/php.ini
# Делаем так:
short_open_tag = On
# Заодно включаем директиву include_path, и добавляем в нее путь ../php
# В дефолтном php.ini выглядит так:
include_path = “.:/usr/share/php”
# Нужно написать таким образом:
include_path = “.:/usr/share/php:../php”
# Помимо этого меняем и другие директивы в файле php.ini
opcache.revalidate_freq = 0
memory_limit = 1G
upload_max_filesize = 32M
post_max_size = 32M
date.timezone = "Europe/Moscow"
# Перезапускаем PHP
sudo systemctl restart php8.2-fpm
Снова открываем http://waf.lezh.loc/ в браузере. Устанавливаем CMS 1С-Битрикс с помощью мастера установки. Мы от регистрации продукта отказались. Внесите изменения в конфигурацию вашего PHP если того требует этап предварительной проверки мастера установки.
Не забывайте перезапускать службы nginx, apache2 или php8.2-fpm, если вносите изменения в их конфигурационные файлы.
Для этапа мастера установи CMS 1С-Битрикс «Создание базы данных» мы в MySQL создали отдельного пользователя bitrix_sql_user, у которого на сервере не будет никаких прав, кроме прав на всё, что попадает под шаблон bitrix_sql_user_
Для этого переходим на страницу phpMyAdmin. В верхнем меню открываем «Учетные записи пользователей». Жмём «Добавить учётную запись пользователя». Указываем логин bitrix_sql_user. Генерируем пароль, сохраняем его где-нибудь временно. Включаем чекбокс «Предоставить все привилегии на то, что подпадает под шаблон (имя пользователя\_%)». Больше ничего не отмечаем, и внизу страницы жмём «Вперёд». В верхнем меню переходим в «Базы данных». Создаём новую БД с именем bitrix_sql_user_website.
Возвращаемся к мастеру установки CMS 1С-Битрикс.
Сервер: localhost
Пользователь базы данных: существующий
Имя пользователя: bitrix_sql_user
Пароль: тот, что создали в phpMyAdmin для него
База данных: существующая
Новая база данных: bitrix_sql_user_website
В раздлеле «Параметры администратора базы данных» указываем логин и пароль пользователя MySQL с полномочиями работу со структурой СУБД.
Жмём «Далее», и после этого мастер установки установит CMS 1С-Битрикс на сайт. В теории, конечно же. Если возникнут ошибки, с ними придётся разобраться.
После окончания установки мастер предложит создать администратора CMS. Создавайте.
На следующих этапах определитесь с тем, какой шаблон сайта вы будете использовать. И после этого вы сможете перейти на только что установленный сайт.
Можно это сделать через административную часть сайта, но, честно говоря, мы не можем знать, позаботились ли разработчики шаблона для сайта о том, чтобы все внутренние ссылки правильно были указаны (какие-то могут быть заданы по-идиотски жестко, вроде <a href=”http://domain.ru/catalog/”>каталог товаров</a>).
Для надёжности нам необходимо будет в конфиге виртуального хоста nginx сделать так:
# Открываем файл конфигурации виртуального хоста Nginx
sudo mcedit /etc/nginx/sites-enabled/waf.lezh.loc
#####################################
# Теперь сделаем ещё так, чтобы все запросы вели на адрес www.lezh.loc
# Для этого разделим наш конфиг nginx для ssl-соединений на два отдельных
# И вот как теперь выглядит весь конфиг виртуального хоста
#####################################
# Все http-запросы перенаправляются на 443 порт
server {
listen 80;
server_name waf.lezh.loc www.waf.lezh.loc;
access_log /var/www/lezh.loc/__waf/logs/nginx.access.log;
error_log /var/www/lezh.loc/__waf/logs/nginx.error.log;
# Перенаправляем запросы на домен www.waf.lezh.loc
if ($host = waf.lezh.loc) {
return 301 https://www.waf.lezh.loc$request_uri;
}
# Все http-запросы перенаправляем на 443 порт
return 301 https://$host$request_uri;
}
# Все https-запросы на домен waf.lezh.loc перенаправляются на домен www.waf.lezh.loc
server {
listen 443 ssl http2;
server_name waf.lezh.loc;
ssl_certificate /var/www/lezh.loc/__waf/ssl/fullchain.pem;
ssl_certificate_key /var/www/lezh.loc/__waf/ssl/privkey.pem;
return 301 https://www.waf.lezh.loc$request_uri;
}
# Обрабатываем все https-запросы
server {
listen 443 ssl http2;
server_name www.waf.lezh.loc;
access_log /var/www/lezh.loc/__waf/logs/nginx.access-ssl.log;
error_log /var/www/lezh.loc/__waf/logs/nginx.error-ssl.log;
ssl_certificate /var/www/lezh.loc/__waf/ssl/fullchain.pem;
ssl_certificate_key /var/www/lezh.loc/__waf/ssl/privkey.pem;
root /var/www/lezh.loc/__waf/www;
index index.php;
add_header X-Content-Type-Options nosniff;
client_max_body_size 256M;
location / {
try_files $uri/ =404 @proxy_to_apache;
}
# Статический контент сайта отдаем сразу средствами Nginx
location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|ttf|eot|pdf)$ {
access_log off;
expires 30d;
add_header Cache-Control public;
# Все файлы, что не удалось отдать, передаём в бэкенд
try_files $uri @proxy_to_apache;
}
location @proxy_to_apache {
proxy_pass https://127.0.0.1:8443;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 120;
proxy_read_timeout 120;
}
}
# Сохраняем, закрываем редактор
# Проверяем конфиг, перезапускаем nginx
nginx -t && sudo systemctl restart nginx