tech-tips/Программное обеспечение/LEMP-стек/Настройка LEMP сервера для простых проектов. Инструкция для самых маленьких/Часть 3.md

---
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
```

В нашем случае его содержимое будет выглядеть следующим образом:

```
<VirtualHost *:81>
    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

    <Directory "/var/www/DOMAIN_NAME/data">
        AllowOverride  All
        Options FollowSymLinks
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>
```

За работу веб-сервера от пользователя здесь отвечает параметр `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, а также ведем дискуссии на различные темы.