--- source: https://habr.com/ru/company/nixys/blog/646545 tags: [lemp, mariadb] --- > [!seealso] Все части > * [Часть 1](Часть%201.md) > * [Часть 2](Часть%202.md) > * [Часть 3](Часть%203.md) ![[0ef87c5f0844ba468622bc0e24aaecb0.jpg]] ## Введение Приветствую читателей! В рамках текущей серии статей я рассказываю о том, как настроить сервер для простых проектов. Имеется ввиду сервер для работы нескольих сайтов, с небольшой нагрузкой под наиболее популярной CMS такой например как Bitrix. Основная цель статьи указать на ошибки допускаемых младшими специалистами при выполнении подобной настройки. Также указать на какие то вещи, которые сделают troubleshooting простым и удобным. Это не совсем стэк LEMP, так как здесь используется apache2, но вы можете использовать php-fpm вместо этого, если разработчик не против внедрения такого решения. В комментариях к статьям я часто вижу сообщения, о том, что apache2 уже не актуален и вместо него можно поднять другое ПО. От себя могу сказать, что до сих пор большое количество небольших и средних организаций, встающих на обслуживание используют apache2 и файлы .htaccess, поэтому я не согласен с данным утверждением. Но опять же если вы опытный администратор, понимающий как работает эта связка, вы можете пропустить эту статью и поднять то, что вашей душе угодно. Статья написана не с целью взять и бездумно скопировать все команды и получить готовый сервер для размещения площадки. Также если в вашей конкретной компании используется другой стэк, я очень за вас рад, но это не отменяет того факта, что то ПО которое описано в этой статье все еще популярно, используется и администрируется без каких-либо проблем. Ну что же, приступим. В первой и второй частях серии статей мы выполнили следующие действия: - Установили базовые пакеты - Настроили git autocommit для фиксации изменений в системных конфигурациях - Выполнили базовую настройку exim4, ssh, ftpd - Дали администратору соответвующие права для администрирования сервера - Выполнили базовую настройку apache2, nginx, MySQL. В текущей статье будет описано: - Установка и настройка php - Создание виртуальных хостов для площадок - Настройка отправки почты - Выдача разработчикам доступов к площадке ## Установка и настройка php Приступим к установке php. Наша площадка будет базироваться на php7.4 однако вы можете развернуть любую требуемую версию. Устанавливаем пакеты, необходимые для установки gpg ключа: ```shell apt -y install lsb-release apt-transport-https ca-certificates ``` Скачиваем ключ репозитория **sury** и прописываем его в **apt**: ```shell wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | tee /etc/apt/sources.list.d/php.list ``` Можно переходить к установке php и его базовых модулей: ```shell apt-get update && apt-get install php7.4 php7.4-cli php7.4-common php7.4-curl php7.4-gd php7.4-geoip php7.4-imagick php7.4-imap php7.4-intl php7.4-mcrypt php7.4-mysql php7.4-apc ``` После выполнения всех действия проверяем версию php: ``` php -v php 7.4.27 (cli) (built: Dec 20 2021 21:32:33) ( NTS ) Copyright (c) The php Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.27, Copyright (c), by Zend Technologies ``` Также проверяем установленные на данный момент модули php: ``` php -m [php Modules] apc apcu calendar Core ctype curl date exif FFI fileinfo filter ftp gd geoip gettext hash iconv imagick imap intl json libxml mcrypt mysqli mysqlnd openssl pcntl pcre PDO pdo_mysql Phar posix readline Reflection session shmop sockets sodium SPL standard sysvmsg sysvsem sysvshm tokenizer Zend OPcache zlib [Zend Modules] Zend OPcache ``` Вы всегда можете установить дополнительные модули под ваш проект, здесь речь идет только о базовых модулях. Для просмотра доступных модулей php, которые можно установить через apt используется команда: ```shell apt-cache search 'php7.4' ``` Если необходимых вам модулей нет в репозитории sury, вы можете выполнить их установку через pecl, для его установки вы можете воспользоваться следующей статьей: [https://www.mkfoster.com/2009/01/04/how-to-install-a-php-pecl-extensionmodule-on-ubuntu/](https://www.mkfoster.com/2009/01/04/how-to-install-a-php-pecl-extensionmodule-on-ubuntu/) Приступим к установке базовых параметров php. У нас имеется два окружения cli и apache2 (в нашем случае), для каждого окружения имеется свой `php.ini` файл: ``` /etc/php/7.4/apache2/php.ini /etc/php/7.4/cli/php.ini ``` Файл `php.ini` расположенный в apache2 отвечает за настройки php используемые при передаче скриптов на обработку apache2, в нашем случае это будут настройки при использовании площадки клиентами на сайте. Файл `php.ini` расположенный в cli используется при выполнении скриптов из консоли и крон задач при вызове скриптов через php обработчик. Мы будем вносить изменения в оба файла. Стандартные изменения для бызовой работы php следующие: ```diff -short_open_tag = Off +short_open_tag = On -post_max_size = 8M +post_max_size = 128M -upload_max_filesize = 2M +upload_max_filesize = 64M -;date.timezone = +date.timezone = Europe/Moscow -session.gc_probability = 0 +session.gc_probability = 10 -session.gc_divisor = 1000 +session.gc_divisor = 100 -session.gc_maxlifetime = 1440 +session.gc_maxlifetime = 14400 ``` Я не буду подробно останавливаться на данных настройках, так как все они достаточно подробно описаны в мануале php. Для работы php с минимально возможными досутпами в системе потребуется задачть следующие права на директории: ```shell chmod -R o-rwx /etc/php/7.4 chmod 751 /etc/php/7.4 chmod -R o+rX /etc/php/7.4/cli chmod -R o+rX /etc/php/7.4/apache2 chmod -R o+rX /etc/php/7.4/mods-available ``` На данном пункте установку и базовую настройку php можно считать завершенной. Все минимально необходимые компоненты для работы площадки были установлены, теперь мы можем приступить к созданию площадки. ## Создание виртуальных хостов В нашей конфигурации каждая площадка сервера будет работать от своего пользователя системы. При такой настройке площадки будут изолированы друг от друга, соответсвенно при доступе к коду сайта при обнаружении какой либо уязвимости, злоумышленник не сможет получить доступ к остальным площадкам сервера, как в случае, если бы все площадки работали от одного пользователя. Создадим пользователя системы: ```shell groupadd -g 10002 DOMAIN_NAME useradd -g 10002 -u 10002 -s /bin/bash -d /var/www/DOMAIN_NAME DOMAIN_NAME ``` Где `DOMAIN_NAME` это имя площадки, например `site.ru`. Далее создадим каталог площадки, по стандартам все площадки будут расположены в `/var/www`: ```shell mkdir -p /var/www/DOMAIN_NAME ``` После перейдем в директорию площадки и создадим каталог для файлов площадки: ```shell cd /var/www/DOMAIN_NAME mkdir data ``` Далее также создадим каталог для временных файлов, каталог для хранения логов и каталог для хранения файлов сессий: ```shell mkdir log sess tmp upload log/apache2 log/nginx ``` После присвоим площадке права и владельца. В нашем случае права на файлы стандартны `644`, права на директории `755`, при этом права на основной каталог `/var/www/DOMAIN_NAME` будут `751`, для ограничения пользователей не являющимися владельцами и не входящих в группу площадки: ```shell chown -R DOMAIN_NAME: /var/www/DOMAIN_NAME chmod 751 /var/www/DOMAIN_NAME chmod -R o-rwx /var/www/DOMAIN_NAME/* chmod o+x data log log/nginx ``` После того, как были созданы все необходимые директории, потребуется создать виртаульные хосты `nginx` и apache2, начнем со второго. Создаем файл виртульного хоста apache2. Создаем файл виртуального хоста: ```shell touch etc/apache2/sites-available/DOMAIN_NAME.conf ``` В нашем случае его содержимое будет выглядеть следующим образом: ``` ServerAdmin webmaster@DOMAIN_NAME DocumentRoot /var/www/DOMAIN_NAME/data ServerName DOMAIN_NAME ServerAlias www.DOMAIN_NAME AssignUserId DOMAIN_NAME DOMAIN_NAME php_admin_value session.save_path "/var/www/DOMAIN_NAME/sess" php_admin_value upload_tmp_dir "/var/www/DOMAIN_NAME/upload" php_admin_value open_basedir "/var/www/DOMAIN_NAME:." CustomLog /var/www/DOMAIN_NAME/log/apache2/access.log combined ErrorLog /var/www/DOMAIN_NAME/log/apache2/error.log LogLevel error AllowOverride All Options FollowSymLinks Order allow,deny Allow from all ``` За работу веб-сервера от пользователя здесь отвечает параметр `AssignUserId`, в котором мы указываем имя и группу пользователя площадки. По-скольку имя пользователя и имя площадки идентичны, то во всех случаях это будет название площадки. Здесь же мы задаем директорию файлов сессий, временных файлов и базовую директорию, ограничивающую обращения веб-сервера для конкретной площадки: ``` php_admin_value session.save_path "/var/www/DOMAIN_NAME/sess" php_admin_value upload_tmp_dir "/var/www/DOMAIN_NAME/upload" php_admin_value open_basedir "/var/www/DOMAIN_NAME:." ``` Хочется сразу отметить, что параметры php можно задать в трех местах, так как на этот вопрос вызывает большое количество проблем на собеседовании на вакансию **junior**: - в первом случае параметры php задаются в `.htaccess` файлах площадки параметры php заданные здесь будут действовать только для директории в которой размещён такой файл. Параметры имеют обычный приоритет. - во втором случае вы можете задать параметры php внутри файла `php.ini` для соотвтетствующего окружения, как мы делали выше. Эти параметры будут также иметь обычный приоритет. При этом если будут осуществляться обращения к скриптам, то параметры указанные в `.htaccess` будут иметь приоритет выше чем параметры заданые в `php.ini` - в третьем же случае вы можете задать параметры на уровне виртуального хоста `apache2`, такие параметры будут применяться только к php окружению для apache2 соответвенно, то есть будут применяться только для обращений по http/https. При этом если вы задаете параметры через функцию `php_value`, то такие параметры по приоритету будут равны параметрам заданным в `php.ini`, но относительно них будут выше. Если же параметр php задаваемый внутри виртуального хоста задается через `php_admin_value` то он будет иметь наивысший приоритет для `apache2` окружения. То есть параметр заданный в `php_admin_value` будет игнорировать все идентичные параметры заданные в других местах (`.htaccess` или `php.ini`) Использование `php_admin_value` позволяет задать особенные настройки для отдельной площадки. Чаще всего через данную функцию задаются директории или, например функция отправки почты, для конкретной площадки. После создания виртуального хоста apache2 его необходимо применить с помощью команды: ``` a2ensite DOMAIN_NAME ``` Данная команда создаст символьную ссылку из директории `/sites-available` в директорию `/sites-enabled` После обязательно тестируем синтаксис `Aapche2` на наличие ошибок и перечитываем файлы конфигурации веб-сервера: ``` apache2ctl -t Service apache2 reload ``` После создания виртуального хоста для apache2 приступим к созданию виртуального хоста для `nginx`: Создаем файл виртуального хоста: ``` touch /etc/nginx/sites-available/DOMAIN_NAME ``` В базовой конфигурации такой файл будет иметь следующее содержание: ``` server { listen 80; server_name DOMAIN_NAME www.DOMAIN_NAME; access_log /var/www/DOMAIN_NAME/log/nginx/access.log nixys; error_log /var/www/DOMAIN_NAME/log/nginx/error.log; location ~ /\.(svn|git|hg) { deny all; } location ~* ^.+\.(css|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf)$ { root /var/www/DOMAIN_NAME/data; expires max; access_log off; } location / { proxy_pass http://127.0.0.1:81; # apache proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; client_max_body_size 10m; client_body_buffer_size 1280k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; } } ``` `location` вида: ``` location ~* ^.+\.(css|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf)$ { root /var/www/DOMAIN_NAME/data; expires max; access_log off; } ``` Отвечает за обработку статики на уровне `nginx`. В `location` перечислены форматы файлов для обработки, в случае если среди файлов площадки есть статика других форматов, достаточно просто дописать формат в `location` и перечитать конфигурацию веб-сервера. В предудыщей статье меня спрашивали как будет разделена обработка статики на уровне nginx и передача запросов php к apache2, за счет этого `location` осуществляется передача подобных запросов. Все остальные запросы будут прокcированы на apache2, а именно на `81` порт серверa: ``` proxy_pass http://127.0.0.1:81; # apache ``` На этом настройку виртуального хоста `nginx` можно считать завершенной. Создадим символьную ссылку виртуального хоста в `sites-enabled`: ``` ln -s /etc/nginx/sites-available/DOMAIN_NAME /etc/nginx/sites-enabled/DOMAIN_NAME ``` Протестируем конфигурацию nginx и перечитаем ее: ``` nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful ``` ``` service nginx reload ``` После обязательно проверим, что веб-сервер запущен ``` service nginx status ``` Создание базового виртуального хоста для `nginx` можно считать завершенной. Также нам потребуется создать БД для будущей площадки, для этого переходим в консоль управления MySQL и создаем БД и пользователя для нее: ``` mysql ``` ```sql CREATE DATABASE DOMAIN_NAME_db CHARSET utf8; GRANT ALL ON DOMAIN_NAME_db.* TO 'DOMAIN_NAME_usr'@'localhost' IDENTIFIED BY 'XXXXXXXXXXXXXX'; FLUSH PRIVILEGES; ``` Для того что бы не возникло путаницы среди большого количества БД, мы рекомендуем создавать продакшн БД для сайта по следюущему принципу, если сайт имеет доменное имя `site.ru`, то имя БД должно быть `site_db`, а имя пользователя `site_usr`. Пароль в данном случае это случайная последовательность символов от 15 штук, мы выпускали его ранее в предыдущих частях статьи. ## Обеспечение доступа к файлам площадки разработчикам После выполнения всех операций, необходимо выдать нашему пользователю площадки возможность подключения по SSH и FTP: Для выдачи доступов по SSH необходимо будет добавить имя пользователя в файл `/etc/ssh/sshd_config`, секция ``` AllowUsers DOMAIN_NAME ``` После, перезапускаем SSH ``` /etc/init.d/ssh restart ``` И проверяем статус: ``` /etc/init.d/ssh status ``` Далее приступим к настройке FTP, так как ранее мы настроили `vsftpd`, нам потребуется просто добавить имя пользователя площадки в системе в файлы: ``` /etc/vsftp/vsftpd.chroot_list /etc/vsftp/vsftpd.user_list ``` После создаем файл с описанием доступа пользователя: ```shell touch /etc/vsftp/vsusers/DOMAIN_NAME ``` Содержащий строки: ``` chroot_local_user=YES local_root=/var/www/DOMAIN_NAME local_umask=022 ``` После, перезапустить FTP-сервер ```shell /etc/init.d/vsftpd restart ``` И проверить статус работы: ```shell /etc/init.d/vsftpd status ``` После выполнения всех действий необходимо создать пароль для пользователя площадки: - генерируем пароль от 15 символов: ```shell pwgen 15 1 ``` - присваиваем этот пароль пользователю площадки в системе: ```shell passwd DOMAIN_NAME ``` Обязательным пунктом настройки доступов является проверка их корректности, для начала зайдем на свою машину и проверим возможность подключения по SSH: ``` SSH EXTERNAL_IP@DOMAIN_NAME ``` Если подключение прошло корректно, значит проблем нет и можно проверить соедиение по FTP, для этих целей проще всего использовать ПО с графическим интерфейсом, например **FileZilla**, устанавливаем программу на любую ОС, вводим реквизиты подключения и проверяем. В случае, если подключение по каким-либо причинам не проходит, то, вероятно вы где то допустили ошибку ранее. ## Настройка отправки почты с сервер После создания площадки и выдачи доступов, переходим к настройке отправки почты с сервера. Настройку можно считать завершенной, после получения наибольшего балла спам фильтра, самой распространенный СПАМ фильтр на текущий момент это **SpamAssassin**. Тестировать отправку почты с сервера возможно с помощью сайта [www.mail-tester.com](http://www.mail-tester.com/), который проанализирует ваше письмо и выдаст всю необходимую информацию и недочеты. Целью нашей настройки будет получение 10 балов на данном ресурсе. Для корректной отправки почты, нам потребуется создать ряд записей в DNS зоне домена, а именно DKIM (публичный ключ), SPF, DMARC. Также потребуется попросить саппорт дата-центра указать PTR запись в обратной зоне, или сделать это самостоятельно, если функционал вашего ДЦ предусматривает такую функцию. - Начнем с DKIM: Для выпуска ключа DKIM нам потребуется установить пакет `opendkim-tools`, пакет доступен в стандартных репозиториях, для его установки дополнительных действий не требуется ```shell apt update apt install opendkim-tools ``` Далее создадим директорию в exim для хранения всех наших ключей DKIM: ```shell mkdir /etc/exim4/dkim ``` И перейдем в нее: ```shell cd /etc/exim/dkim ``` Далее генерируем публичный и приватный ключ DKIM: ```shell opendkim-genkey -D /etc/exim4/dkim/ -d DOMAIN.RU -s DKIM_SELECTOR -b 1024 ``` где `DKIM_SELECTOR` является указателем, для поиска публичной части ключа (как правило, это `mail`). В текущей директории будет создано два файла `mail.private` (приватный ключ) и `mail.txt` (публичный ключ, который потребуется прописать в DNS зоне домена. Для удобства и дальнейшего применения в конфигурации `exim4`, переименуем оба файла: ```shell mv /etc/exim4/dkim/mail.private /etc/exim4/dkim/DOMAIN.RU.key mv /etc/exim4/dkim/mail.txt /etc/exim4/dkim/DOMAIN.RU.txt ``` В целях безопасности меняем права на части ключа и директорию хранения: ```shell chown -R root:Debian-exim /etc/exim4/dkim chmod 750 /etc/exim4/dkim chmod 640 /etc/exim4/dkim/DOMAIN.RU.key chmod 640 /etc/exim4/dkim/DOMAIN.RU.txt ``` Теперь, когда у нас созданы ключи, необходимо указать конфигурации `exim4` их расположение, для этого добавляем в начало файла `/etc/exim4/exim4.conf.template` строки: ``` # DKIM settings DKIM_DOMAIN = ${lc:${domain:$h_from:}} DKIM_FILE = /etc/exim4/dkim/${lc:${domain:$h_from:}}.key DKIM_PRIVATE_KEY = ${if exists{DKIM_FILE}{DKIM_FILE}{0}} ``` Также добавляем в блок `remote_smtp` в файле `/etc/exim4/exim4.conf.template` следующие записи: ``` remote_smtp: driver = smtp dkim_domain = DKIM_DOMAIN dkim_selector = $DKIM_SELECTOR dkim_private_key = DKIM_PRIVATE_KEY ``` где в качестве `$DKIM_SELECTOR` необходимо подставить `selector`, заданный при создании ключа. Параметры `DKIM_DOMAIN` и `DKIM_PRIVATE_KEY` здесь являются переменными, и имеют точно такой же вид в файле как описаны в статье. Также хотелось бы уточнить, что почтовый сервер в дальнейшем сможет работать только с одним селектором `DKIM`. Соответственно, если подпись для первого домена указана mail, то она должна быть таковой для всех последующих доменов, для которых будет осуществляться генерация DKIM ключа. После нам потребуется добавить TXT запись в DNS зону домена, содержимое записи указано в файле `DOMAIN.RU.txt`. Пример записи: ``` DKIM_SELECTOR._domainkey IN TXT ( "v=DKIM1; h=sha256; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCWtRUr0hse/k2csH1KtA3YrM2hrSiDxyhRDEV53LvDxjcN8rH5913j0N/5P48kotw0tVKlyaW6x9sJJPs7fjCsuoSQNQUpwjJrPKjH/r7fTBESFMOx6SHMpIC57GadCCmQfGEiI0IHPG0zqakDNUKtLaWBc71BLdRAApsbZ97ooQIDAQAB" ) ; ----- DKIM key DKIM_SELECTOR for DOMAIN.RU ``` После выполняем удаление уже не нужного ключа: ```shell rm -f /etc/exim4/dkim/DOMAIN.RU.txt ``` Перезапускаем `exim4` и проверяем его работу: ```shell service exim4 restart service exim4 status ``` Обновление DNS записей происходит в течении 72 часов, однако для большинства DNS серверов запись обычно появляется в течении часа. В качестве теста мы можем проверить наличие записи у DNS серверов Google: ```shell dig @8.8.8.8 +short -ttxt DKIM_SELECTOR._domainkey.DOMAIN.RU ``` В случае, если на запрос `dig`, вы получаете публичный ключ, значит все настройки выполнены верно. Также вы можете отправить письмо на любой почтовый ящик, для которого не осуществляется фильтрация входящей почты. С сервера это делается с помощью команды вида: ```shell echo "Hello there" | mail -s "world" -r test@DOMAIN_NAME address@recipient ``` Пример отправки письма для домена `site.ru`, на почтовый ящик `test@gmail.com`: ```shell echo "Hello there" | mail -s "world" -r test@site.ru test@gmail.com ``` После вам потребуется найти письмо в почтовом ящике и открыть его полную текстовую версию, если вы видите там строку вида: ``` dkim=pass ``` Значит заголовок письма был подписан приватным ключом со стороны `exim4` сервера и дешифрован с помощью публичного ключа, прописанного в DNS зоне. Иными словами все работает корректно. После приступим на стройке SPF записи. SPF запись это запись указывающая на те сервера, с которых можно отправлять почту для данного домена. Я не буду углубляться в работу SPF записи, так как для нашей площадки необходима только отправка почты для конкретного сервера, поэтому создадим `TXT` запись, в DNS зоне нашего домена вида ``` DOMAIN.RU. IN TXT "v=spf1 +a +mx ip4:EXTERNAL_IP ~all" ``` Где `EXTERNAL_IP` внешний IP адрес нашего сервера соответсвенно. Важный момент, в DNS зонах также присутвует возможность указать запись типа SPF, данная запись является устаревшей, для применения SPF записи она должна иметь именно `TXT` формат. После указания SPF записи выполним запрос с помощью `dig` и проверим, что все верно: ``` dig TXT DOMAIN_NAME ``` Если среди полученных записей имеется ваша SPF запись, то все было добавлено верно. Далее создадим политику `dmarc`. Она указывает принимающему серверу, что делать с письмом, если записи `DKIM` и SPF окажутся некорректны. В нашем случае минимальными требованиями политики будут указаны с помощью следующей `TXT` записи: ``` _dmarc.DOMAIN.RU. IN TXT "v=DMARC1; p=reject; aspf=r; sp=reject" ``` Не советуем отключать политику `dmarc`, как это рекомендует сделать `mail-tester`, так как с отключенной политикой письма могут попадать в СПАМ некоторых почтовых ящиков. Для проверки указания `dmarc` воспользуемся командой: ``` dig +short -ttxt _dmarc.DOMAIN.RU ``` После необходимо будет указать PTR запись. Она используется при отправке письма, когда почтовый сервер представляется каким-либо именем. Она должна связать домен указанный в `primary_hostname` конфигурации `exim4` и внешний IP нашего сервера. По-скольку в нашем случае параметр `primary_hostname` имеет значение основного доменного имени площадки, нам необходимо указать PTR запись вида: ``` DOMAIN.RU. IN TXT "EXTERNAL IP" ``` Где `DOMAIN.RU` это имя домена указанное в `primary_hostname` текущего сервера `exim4`, а `EXTERNAL IP` это внешний IP адрес нашего сервера. Данную запись можно указать в панели управления ДЦ или, если такая функция не предусматривается, попросить указать запись через саппорт дата центра. Для проверки PTR записи используется следующая команда `dig`: ``` dig -x DOMAIN_NAME ``` Как только все записи отражены и указаны, можно приступить к отправке тестового письма на `mail-tester`, отправляем письмо с помощью уже знакомой команды: ``` echo "Hello there" | mail -s "world" -r test@DOMAIN_NAME test-nfl7dosjr@srv1.mail-tester.com ``` После всех выполненных настрое мы должны получить **10/10** балов сервиса `mail-tester`, что является наивысшим результатом. ## Завершающие шаги На этом настройку сервера можно считать завершенной. Вы можете залить код площадки в `/var/www/DOMAIN_NAME/data` (от пользователя площадки!), а также разместить БД площадки в MySQL, указать реквизиты БД на уровне кода и проверить работу сайта. Однако, перед этим обязательно проверьте права и владельца файлов. Для резервирования кода площадок и БД вы можете воспользоваться нашей утилитой `nxs-backup`, описанной в статье [https://habr.com/ru/company/nixys/blog/424717/](https://habr.com/ru/company/nixys/blog/424717/). Обязательно предоставте разработчикам доступы к MySQL пользователя БД площадки, и доступы SSH и FTP для пользователя площадки в системе `(DOMAIN_NAME)`. Плюс работы площадки от пользователя в том, что разработчики кода имеют доступ только к файлам площадки и работают от своего пользователя, при этом площадки абстрагированы друг от друга на уровне системы, так как у каждой площадки свой пользователь системы. Статьи и так получились достаточно грамоздкой в связи с чем я не буду подробно описывать настройку работы домена по https, в сети очень много информации о том как прикрутить SSL сертификат к `nginx`. Могу сказать лишь то, что если вам нужен бесплатный сертификат, вы можете выпустить его с помощью `certbot` на сервере, а после, как пример, в нужном виртуальном хосте `nginx` настроить безусловный редирект с `http` на `https`, для этого в виртуальном хосте в начале дописать: ``` server { listen 80; server_name DOMAIN_NAME www.DOMAIN_NAME; return 301 https://DOMAIN_NAME$request_uri; } ``` А ниже отредактировать теущую конфигурацию для `80` порта, изменив его на `443` и указав собранный сертификат и ключ: ``` server { listen 443 ssl; server_name DOMAIN_NAME www.DOMAIN_NAME; ssl_certificate /etc/nginx/ssl/DOMAIN_NAME/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/DOMAIN_NAME/private.key; ``` ## Заключение Спасибо за внимание, надеюсь, что данные статьи помогут разобраться начинающим системным администраторам уберут множество стандартных вопросов, возникающих во время работы. Также приглашаем всех желающих вступить в наше сообщество в Telegram **DevOps FM** [по ссылке](https://t.me/devops_fm). Где мы выкладываем интересные новости из мира IT, а также ведем дискуссии на различные темы.