morgeshtern 19 янв 2022 в 16:53

Настройка LEMP сервера для простых проектов. Инструкция для самых маленьких. Часть третья

16 мин

11K

Введение

Приветствую читателей! В рамках текущей серии статей я рассказываю о том, как настроить сервер для простых проектов. Имеется ввиду сервер для работы нескольих сайтов, с небольшой нагрузкой под наиболее популярной CMS такой например как Bitrix. Основная цель статьи указать на ошибки допускаемых младшими специалистами при выполнении подобной настройки. Также указать на какие то вещи, которые сделают troubleshooting простым и удобным.

Это не совсем стэк LEMP, так как здесь используется Apache2, но вы можете использовать PHP-FPM вместо этого, если разработчик не против внедрения такого решения.

В комментариях к статьям я часто вижу сообщения, о том, что Apache2 уже не актуален и вместо него можно поднять другое ПО. От себя могу сказать, что до сих пор большое количество небольших и средних организаций, встающих на обслуживание используют Apache2 и файлы .htaccess, поэтому я не согласен с данным утверждением. Но опять же если вы опытный администратор, понимающий как работает эта связка, вы можете пропустить эту статью и поднять то, что вашей душе угодно.

Статья написана не с целью взять и бездумно скопировать все команды и получить готовый сервер для размещения площадки. Также если в вашей конкретной компании используется другой стэк, я очень за вас рад, но это не отменяет того факта, что то ПО которое описано в этой статье все еще популярно, используется и администрируется без каких-либо проблем.

Предыдущие части статей доступны по следующим ссылкам:

https://habr.com/ru/company/nixys/blog/645451/ - первая часть
https://habr.com/ru/company/nixys/blog/646023/ - вторая часть

Рекомендую ознакомиться перед прочтением данного материала.

Ну что же, приступим.

В первой и второй частях серии статей мы выполнили следующие действия:

Установили базовые пакеты
Настроили git autocommit для фиксации изменений в системных конфигурациях
Выполнили базовую настройку exim4, ssh, ftpd
Дали администратору соответвующие права для администрирования сервера
Выполнили базовую настройку Apache2, Nginx, MySQL.

В текущей статье будет описано:

Установка и настройка PHP
Создание виртуальных хостов для площадок
Настройка отправки почты
Выдача разработчикам доступов к площадке

Установка и настройка PHP

Приступим к установке PHP. Наша площадка будет базироваться на PHP 7.4, однако вы можете развернуть любую требуемую версию.

Устанавливаем пакеты, необходимые для установки gpg ключа:

apt -y install lsb-release apt-transport-https ca-certificates

Скачиваем ключ репозитория sury и прописываем его в apt:

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 и его базовых модулей:

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 используется команда:

apt-cache search 'php7.4'

Если необходимых вам модулей нет в репозитории sury, вы можете выполнить их установку через pecl, для его установки вы можете воспользоваться следующей статьей:

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 следующие:

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

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 можно считать завершенной.

Все минимально необходимые компоненты для работы площадки были установлены, теперь мы можем приступить к созданию площадки.

Создание виртуальных хостов

В нашей конфигурации каждая площадка сервера будет работать от своего пользователя системы. При такой настройке площадки будут изолированы друг от друга, соответсвенно при доступе к коду сайта при обнаружении какой либо уязвимости, злоумышленник не сможет получить доступ к остальным площадкам сервера, как в случае, если бы все площадки работали от одного пользователя.

Создадим пользователя системы:

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:

mkdir -p /var/www/DOMAIN_NAME

После перейдем в директорию площадки и создадим каталог для файлов площадки:

cd /var/www/DOMAIN_NAME
mkdir data

Далее также создадим каталог для временных файлов, каталог для хранения логов и каталог для хранения файлов сессий:

mkdir log sess tmp upload log/apache2 log/nginx

После присвоим площадке права и владельца. В нашем случае права на файлы стандартны 644, права на директории 755, при этом права на основной каталог /var/www/DOMAIN_NAME будут 751, для ограничения пользователей не являющимися владельцами и не входящих в группу площадки:

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. Создаем файл виртуального хоста:

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
в третьем же случае вы можете задать параметры на уровне виртуального хоста Apahce2, такие параметры будут применяться только к php окружению для Apache2 соответвенно, то есть будут применяться только для обращений по http/https. При этом если вы задаете параметры через функцию php_value, то такие параметры по приоритету будут равны параметрам заданным в php.ini, но относительно них будут выше. Если же параметр PHP задаваемый внутри виртуального хоста задается через php_admin_value то он будет иметь наивысший приоритет для apahche2 окружения. То есть параметр заданный в 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

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

После создаем файл с описанием доступа пользователя:

touch /etc/vsftp/vsusers/DOMAIN_NAME

Содержащий строки:

chroot_local_user=YES

local_root=/var/www/DOMAIN_NAME
local_umask=022

После, перезапустить FTP-сервер

/etc/init.d/vsftpd restart

И проверить статус работы:

/etc/init.d/vsftpd status

После выполнения всех действий необходимо создать пароль для пользователя площадки:

генерируем пароль от 15 символов:

pwgen 15 1

присваиваем этот пароль пользователю площадки в системе:

passwd DOMAIN_NAME

Обязательным пунктом настройки доступов является проверка их корректности, для начала зайдем на свою машину и проверим возможность подключения по SSH:

SSH EXTERNAL_IP@DOMAIN_NAME

Если подключение прошло корректно, значит проблем нет и можно проверить соедиение по FTP, для этих целей проще всего использовать ПО с графическим интерфейсом, например FileZilla, устанавливаем программу на любую ОС, вводим реквизиты подключения и проверяем. В случае, если подключение по каким-либо причинам не проходит, то, вероятно вы где то допустили ошибку ранее.

Настройка отправки почты с сервер

После создания площадки и выдачи доступов, переходим к настройке отправки почты с сервера. Настройку можно считать завершенной, после получения наибольшего балла спам фильтра, самой распространенный СПАМ фильтр на текущий момент это SpamAssassin.

Тестировать отправку почты с сервера возможно с помощью сайта www.mail-tester.com, который проанализирует ваше письмо и выдаст всю необходимую информацию и недочеты. Целью нашей настройки будет получение 10 балов на данном ресурсе.

Для корректной отправки почты, нам потребуется создать ряд записей в DNS зоне домена, а именно DKIM ( публичный ключ), SPF, DMARC. Также потребуется попросить саппорт дата-центра указать PTR запись в обратной зоне, или сделать это самостоятельно, если функционал вашего ДЦ предусматривает такую функцию.

Начнем с DKIM:

Для выпуска ключа DKIM нам потребуется установить пакет opendkim-tools, пакет доступен в стандартных репозиториях, для его установки дополнительных действий не требуется

apt update
apt install opendkim-tools

Далее создадим директорию в exim для хранения всех наших ключей DKIM:

mkdir /etc/exim4/dkim

И перейдем в нее:

cd /etc/exim/dkim

Далее генерируем публичный и приватный ключ DKIM:

opendkim-genkey -D /etc/exim4/dkim/ -d DOMAIN.RU -s DKIM_SELECTOR -b 1024

где DKIM_SELECTOR является указателем, для поиска публичной части ключа (как правило, это mail).

В текущей директории будет создано два файла mail.private (приватный ключ) и mail.txt (публичный ключ, который потребуется прописать в DNS зоне домена. Для удобства и дальнейшего применения в конфигурации exim4, переименуем оба файла:

mv /etc/exim4/dkim/mail.private /etc/exim4/dkim/DOMAIN.RU.key
mv /etc/exim4/dkim/mail.txt /etc/exim4/dkim/DOMAIN.RU.txt

В целях безопасности меняем права на части ключа и директорию хранения:

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

После выполняем удаление уже не нужного ключа:

rm -f /etc/exim4/dkim/DOMAIN.RU.txt

Перезапускаем exim4 и проверяем его работу:

service exim4 restart
service exim4 status

Обновление DNS записей происходит в течении 72 часов, однако для большинства DNS серверов запись обычно появляется в течении часа. В качестве теста мы можем проверить наличие записи у DNS серверов Google:

dig @8.8.8.8 +short -ttxt DKIM_SELECTOR._domainkey.DOMAIN.RU

В случае, если на запрос dig, вы получаете публичный ключ, значит все настройки выполнены верно. Также вы можете отправить письмо на любой почтовый ящик, для которого не осуществляется фильтрация входящей почты. С сервера это делается с помощью команды вида:

echo "Hello there" | mail -s "world" -r test@DOMAIN_NAME address@recipient

Пример отправки письма для домена site.ru, на почтовый ящик test@gmail.com:

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/.

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

Теги:

Хабы: