anthony/tech-tips
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
master
tech-tips/Программное обеспечение/LEMP-стек/Настройка LEMP сервера для простых проектов. Инструкция для самых маленьких/Часть 1.md

31 KiB
Raw Permalink Blame History

source tags
https://habr.com/ru/company/nixys/blog/645451
lemp
mariadb

[!seealso] Все части

!6ab46f702be837f91acf4e9818b42754.jpg

Введение

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

Целью серии статей является описание подготовки работы сервера со стеком LEMP ( #Linux, #nginx, #MySQL, #PHP), развертывание стэка и поднятие на нем работающих площадок. Инструкция подойдет для небольших #Bitrix проектов, а тажке для проектов развернутых под любой популярной CMS.

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

Большая часть проектов базируется на ОС #Ubuntu, #Debian в статьях будут отражены настройки для этих систем.

Общая схема работы сервера

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

Для удобства ниже представлена схема работы такого сервера со всем необходимым для работы ПО:

!01fb2670c2429e46eee9d4a6fe45f295.png

В нашем случае вместо php-fpm будет развернут #apache2, поэтому данный стэк является не совсем LEMP, но вместо apache2 можно без каких-либо проблем развернуть php-fpm, целью статьи является все же указать на основные базовые моменты при настройке серверов для простых проектов.

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

Базовые пакеты

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

apt-get update && apt-get install dirmngr mc iotop htop telnet tcpdump nmap curl console-cyrillic hexedit sudo zip unzip patch pwgen vim less parted subversion ntp bzip2 lsof strace mutt s-nail ncdu smartmontools tree dnsutils logrotate rsyslog

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

  • dirmngr – необходим для добавления ключей репозиториев. mc – он же Midnight Commander, файловый менеджер, не нуждающийся в представлении
  • iotop – утилита, показывающая каналы ввода/вывода; будет полезной при анализе работы дисков.
  • htop – наше все, могучий монитор ресурсов, отображающий всю информацию о текущем потреблении ресурсов системы. Позволяющий также отправлять системные вызовы процессам, менять их приоритет в системе и многое другое.
  • telnet – на практике, часто используем для проверки доступности удаленных портов. В случае если порт закрыт, мы будем точно знать, что проблема не на нашей стороне.
  • tcpdump и nmap – утилиты для анализа сетевого трафика
  • curl – используем для отправки различных запросов, отладки работы веб-серверов.
  • consoleyrillic** - пакет для русификации консоли (поддержки кириллицы в локальном терминале).
  • hexedit - пакет для редактирования данных, в котором данные представлены как последовательность байтов..
  • zip, unzip, bzip2 – также не нуждаются в представлении, известные архиваторы данных.
  • pwgen – утилита для генерации паролей, будет полезна для оперативного создания доступов любого уровня.
  • strace – утилита для анализа системных вызовов процесса, используется для расширенного анализа работающих в системе процессов. По факту мы используем strace в тех случаях, когда логи сервисов не указывают на конкретную проблему.
  • ncdu – удобный инструмент для быстрого отображения размера данных в директории.
  • logrotate – инструмент для ротации логов в системе, также в отдельном представлении не нуждается.

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

dpkg-reconfigure tzdata

Далее выбираем нужные локали в системе (RU-UTF8, RU-KOI8R, RU-CP1251):

dpkg-reconfigure locales

Применяем локали:

/etc/default/locale

Устанавливаем mc как редактор по умолчанию:

update-alternatives --config editor

где выбираем пункт mcedit.

Настройка git-autocommit

В процессе администрирования мы часто сталкиваемся с тем, что необходимо оперативно выяснить, кто и когда внес изменения в те или иные конфигурационные файлы. Для решения этой проблемы мы используем git-autocommit, который фиксирует изменения в конфигах в локальный git репозиторий сервера. Ниже будет описана его настройка:

Ставим на сервер git:

apt-get install git

Создаем файл конфигурации в корневой директории root пользователя с нужными правами:

touch ~/.gitconfig
chmod 600 ~/.gitconfig

Файл имеет следующее содержание

[user]
name = root
email = root@$HOSTNAME

$HOSTNAME заменяем на соответствующее название сервера в проекте. Далее потребуется создать репозиторий, с помощью команд:

cd
git init && mv .git config.git
chmod 700 /root/config.git
echo "gitdir: /root/config.git" > /.git && chmod 600 /.git

Далее задаем директории, для который автокоммит не должен фиксировать изменения, в файл ~/config.git/info/exclude:

/*
!/etc
!/usr
/usr/*
!/usr/local
/usr/local/*
!/usr/local/scripts
!/var
/var/*
!/var/spool
/var/spool/*
!/var/spool/cron
/var/spool/cron/*
!/var/spool/cron/crontabs

На практике же нас интересуют директории /usr и /etc. В случае, если на проекте есть конфигурации docker контейнеров, не помещенных во внешний git репозиторий, мы также добавляем директорию в которой расположен docker-compose к автокомиту для отслеживания изменений. С недавних пор мы также отслеживаем изменения в пользовательских кронатобов /var/spool/cron/crontabs, так как существует проблема потери крон задач на Битрикс проектах. Также некоторые клиенты могут удалить нужную задачу по невнимательности.

После делаем первый коммит и проверяем:

git add -A && git commit -m 'Создание репозитория @system'

Также мы реализуем постоянное отслеживание установленных пакетов на сервере с помощью git autocommit, для этого записываем все текущие установленные пакеты в файл с помощью крон задачи:

* *      	* * *   	root     	/usr/bin/dpkg -l > /etc/package_list

Сам автокоммит запускается с помощью следующего крона:

* *          	* * *       	root        	sleep 10;cd / && git add -A && git commit -m "Autocommit @system" > /dev/null

Таким образом мы можем посмотреть, какие именно изменения вносились в конфигурации сервиса и в какое время. Пример коммита для файла etc/nginx/nginx.conf вызываем командой:

git log --follow -p /etc/nginx/nginx.conf

Результат:

git log --follow -p /etc/nginx/nginx.conf

Результат: commit be993a2734e9f206ed7cb8ee52f54a52ca642cc9 Author: root Date: Tue Oct 12 14:37:11 2021 +0300

Autocommit @system

diff --git a/etc/nginx/nginx.conf b/etc/nginx/nginx.conf index 8c9ed7c..8d694c9 100644 --- a/etc/nginx/nginx.conf +++ b/etc/nginx/nginx.conf @@ -52,12 +52,12 @@ deny 178.166.163.237; #limit_conn_zone $binary_remote_addr zone=cglob:16m;

  •   map $http_user_agent $spam_bots {

  •        	default '';

  •        	~*(321039152) 1;

  •   }

+# map $http_user_agent $spam_bots { +# default ''; +# ~*(321039152) 1; +# }

  •   limit_req_zone   $spam_bots      	zone=spambots:16m  rate=2r/s;

+# limit_req_zone $spam_bots zone=spambots:16m rate=2r/s;

 	include /etc/nginx/conf.d/*.conf;
 	include /etc/nginx/sites-enabled/*;

commit 2df8332dc97681489e43e9aaa85f9078fc50e321 Author: root Date: Tue Oct 12 14:11:11 2021 +0300

Autocommit @system

diff --git a/etc/nginx/nginx.conf b/etc/nginx/nginx.conf index 8d694c9..8c9ed7c 100644 --- a/etc/nginx/nginx.conf +++ b/etc/nginx/nginx.conf @@ -52,12 +52,12 @@ deny 178.166.163.237; #limit_conn_zone $binary_remote_addr zone=cglob:16m;

-# map $http_user_agent $spam_bots { -# default ''; -# ~*(321039152) 1; -# }

  •   map $http_user_agent $spam_bots {

  •        	default '';

  •        	~*(321039152) 1;

  •   }

-# limit_req_zone $spam_bots zone=spambots:16m rate=2r/s;

  •   limit_req_zone   $spam_bots      	zone=spambots:16m  rate=2r/s;

  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/sites-enabled/*;


Таким образом, мы видим, кто и когда внес изменения. Данное решение крайне полезно при возникновении спорных ситуаций внутри команды или когда проблема в конфигурации всплыла после внесения изменений не сразу, а спустя время.

## Базовая настройка ssh, добавление на сервер администратора

После можно приступить к установке и настройке базовых сервисов. Начнем с ssh. Устанавливаем службу, если по каким-то причинам она не была установлена ранее

```shell
apt update
apt install ssh

На наших серверах мы ограничиваем всех ssh пользователей через директиву AllowUsers, добавляем и удаляем пользователей по мере необходимости:

AllowUsers USERS_NAMES

Сразу же отключаем доступ для пользователя root путем изменения строки в /etc/ssh/sshd_config:

PermitRootLogin no

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

chmod 750 /etc/ssh

Перезапускаем службу для применения изменений:

/etc/init.d/ssh restart

Дальнейший вход на сервер по ssh будет доступен только для пользователей указанных в AllowUsers. Добавление системных администраторов на сервера происходит с помощью наших внутренних утилит, однако я опишу процесс добавления так, если бы это происходило ручным способом:

Для добавления на сервер системного администратора вам потребуется:

Авторизоваться на сервере от пользователя root

Создать пользователя системы и группу (пользователи площадок и администраторы имеют UID и GID от 1000 это общий стандарт для несистемных пользователей):

groupadd -g 10001 v.pupkin
useradd -g 10001 -u 10001 -s /bin/bash -d /home/v.pupkin v.pupkin

Далее создаем домашнюю директорию пользователя и права для него:

mkdir -p /home/v.pupkin v.pupkin
cd /home/v.pupkin v.pupkin
chown -R v.pupkin: /home/v.pupkin v.pupkin
chmod 751 /home/v.pupkin v.pupkin
chmod -R o-rwx /home/v.pupkin v.pupkin/*

После нам останется только прокинуть публичный ssh ключ для пользователя v.pupkin на сервер, а также дать пользователю права на выполнение sudo. Для этого достаточно добавить строку в файл /etc/sudoers вида:

v.pupkin ALL=(ALL) NOPASSWD: ALL

Делать это нужно исключительно путем выполнения команды:

visudo

Она проверит синтаксис файла /etc/sudoers перед сохранением. Так как если отредактируете файл вручную и он будет с синтаксической ошибкой, вы не сможете авторизоваться в системе от нужного пользователя или перейти в /etc/sudoers, что по сути поломает систему.

При этом обязательно в файле /etc/sudoers необходимо закомментировать строку:

%sudo ALL=(ALL) ALL

для ограничения выполнения sudo других пользователей. После внесения всех

После внесения всех изменений администратор v.pupkin сможет попадать на сервер, а для перехода в root достаточно будет ввести команду sudo su -. Обратите внимание на "-" в данной команде, зачастую многие начинающие системные администраторы забывают об этом. Дефис нужен для подтягивания системных окружений, так, например, без него вы не сможете корректно запустить скрипты на сервере.

После внесения всех изменений перейдите в консоль пользователя v.pupkin и сгенерируйте пару ssh ключей**:**

su v.pupkin -
ssh-keygen -t rsa

В завершении обязательно сгенерируйте пароль для пользователя v.pupkin в системе:

pwgen 15 1

Данная команда сгенерирует случайный 15 значный пароль. После примените его, для этого от пользователя root выполните команду:

passwd v.pupkin

На этом настройку ssh и предоставление доступов администратору можно считать завершенной. Дальнейшие администраторы будут добавлены также по этой схеме.

Базовая настройка FTP

Далее переходим к настройке доступа к серверу по FTP. Для этих целей будем использовать пакет vsftpd, который есть в стандартных репозиториях. Устанавливаем пакет:

apt install vsftpd

Стандартный файл конфигурации vsftpd расположен по пути /etc/vsftpd.conf, но хранить конфигурации всех FTP пользователей в одном файле не совсем удобно для администрирования, поэтому мы создадим отдельный каталог для конфигураций службы и создадим символическую ссылку на конфигурационный файл /etc/vsftpd.conf, чтобы предотвратить конфликты в системе.

Удаляем основной файл конфигурации службы:

rm /etc/vsftpd.conf

Создаем новую директорию, которая будет основной для конфигураций сервиса:

mkdir /etc/vsftp/

Далее создаем основной файл конфигурации /etc/vsftp/vsftpd.conf:

touch /etc/vsftp/vsftpd.conf

Со следующим содержимым:

listen=YES
log_ftp_protocol=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
anon_upload_enable=NO
anon_mkdir_write_enable=NO
anon_other_write_enable=NO
dirmessage_enable=YES
pasv_enable=YES
port_enable=NO
connect_from_port_20=NO
pasv_max_port=30005 #
pasv_min_port=30000 #
xferlog_enable=YES
xferlog_file=/var/log/vsftpd.log
ascii_upload_enable=NO
ascii_download_enable=NO
ftpd_banner=Welcome to FTP server.
local_umask=0777
user_config_dir=/etc/vsftp/vsusers
chroot_local_user=NO
chroot_list_enable=YES
chroot_list_file=/etc/vsftp/vsftpd.chroot_list
userlist_file=/etc/vsftp/vsftpd.user_list
userlist_enable=YES
userlist_deny=NO
allow_writeable_chroot=YES
seccomp_sandbox=NO
force_dot_files=YES
pasv_promiscuous=YES

Здесь приведены основные настройки, вы можете их менять в зависимости от своих потребностей. Здесь же мы указываем файлы и директорию, в которых будем описывать FTP пользователей:

/etc/vsftp/vsftpd.chroot_list
/etc/vsftp/vsftpd.user_list
/etc/vsftp/vsusers

Логирование службы вынесено в отдельный файл:

xferlog_file=/var/log/vsftpd.log

Опционально вы можете воспользоваться следующими функциями при необходимости:

Для отображения скрытых файлов в листинге подключения, вне зависимости от настроек FTP-клиента можно использовать параметр force_dot_files:

force_dot_files=YES

Для исключения постоянных проверок соответствия IP адресов соединения и управляющего, чтобы исключить ошибку 425 Security: Bad IP connecting., необходимо добавить в файл /etc/vsftp/vsftpd.conf параметр:

pasv_promiscuous=YES

Далее создадим необходмые файлы и директории:

touch /etc/vsftp/vsftpd.chroot_list
touch /etc/vsftp/vsftpd.user_list
mkdir /etc/vsftp/vsusers

А также создадим символьную ссылку для корректной работы сервиса:

ln -s /etc/vsftp/vsftpd.conf /etc/vsftpd.conf

После вам потребуется открыть 21 и 30000:30005 порты для внешних подключений на уровне файрволла, например, следующим образом:

IPTABLES -A tcp_packets_inet  -p tcp -s 0/0 --dport 30000:30005 -j allowed
IPTABLES -A tcp_packets_inet  -p tcp -s 0/0 --dport 21 -j allowed

Мы рекомендуем открывать порты не для всех адресов, а только для тех IP, которым необходим доступ по FTP.

После выполнения этих действий, применяем права на каталог /etc/vsftp/ в целях безопасности:

chmod 750 /etc/vsftp/

Перезапускаем сервис:

service vsftpd restart

И проверяем, что он работает и запущен:

service vsftpd status
● vsftpd.service - vsftpd FTP server
   Loaded: loaded (/lib/systemd/system/vsftpd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2021-12-19 17:08:13 MSK; 1s ago
  Process: 1285 ExecStartPre=/bin/mkdir -p /var/run/vsftpd/empty (code=exited, status=0/SUCCESS)
 Main PID: 1286 (vsftpd)
    Tasks: 1 (limit: 1171)
   Memory: 608.0K
   CGroup: /system.slice/vsftpd.service
       	└─1286 /usr/sbin/vsftpd /etc/vsftpd.conf
Dec 19 17:08:13 31-31-192-22.cloudvps.regruhosting.ru systemd[1]: Starting vsftpd FTP server...
Dec 19 17:08:13 31-31-192-22.cloudvps.regruhosting.ru systemd[1]: Started vsftpd FTP server.

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

telnet 0.0.0.0 21

Где 0.0.0.0 - внешний IP адрес вашего сервера. Если команда выдает статус connected, то порты открыты корректно и служба vsftpd слушает их.

На данном этапе базовая настройка FTP завершена, как добавить конкретного пользователя я расскажу в третьей части статьи.

Базовая настройка exim4 (smarthost)

После настройки работы по FTP переходим к настройке отправки почты с сервера. Так как у нас простой сервер для небольшого проекта, мы будем настраивать exim4 в конфигурации smarthost. То есть почтовый сервер будет осуществлять только отправку почты с сервера, не более.

Приступим к установке пакета:

apt update
apt install exim4 exim4-base exim4-config exim4-daemon-light

После переходим к редактированию файла /etc/exim4/update-exim4.conf, и приводим его к следующему виду:

dc_eximconfig_configtype='internet'
dc_other_hostnames='DOMAIN.RU'
dc_local_interfaces='127.0.0.1 : EXTERNAL_IP'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets='127.0.0.1 : RELAY_FROM_HOST_IPs'
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

Где:

  1. DOMAIN.RU - Доменное имя сервера, прописанное в обратной зоне.
  2. EXTERNAL_IP - Внешний IP данного сервера
  3. RELAY_FROM_HOST_IPs - IP адреса satellit-серверов, если они есть.

Параметр dc_eximconfig_configtype отвечает за режим работы почтового сервера, по умолчанию он будет установлен в local, что запретит вам отправлять почту на удаленные сервера.

Далее переходим к файлу /etc/exim4/exim4.conf.template и меняем там значения двух строк:

qualify_domain = DOMAIN.RU
primary_hostname = DOMAIN.RU

Здесь также задаем основное доменное имя, к ДНС зоне которого мы имеем доступ. Данные настройки потребуются нам в дальнейшем, при настройке почтовых записей.

Для системного администрирования важно, чтобы уведомления служб сервера для пользователя root отправленные по почте, отправлялись на нужный почтовый ящик, для этого в exim4.conf.template потребуется внести следующие изменения, обеспечивающие доставку почты, адресованной пользователю root:

mail_for_root:
  driver = redirect
  domains = DOMAIN.RU
  condition = ${if eq{$local_part}{root}}
  data = admin@nixys.ru

где:

  • DOMAIN.RU - это название проекта
  • admin@nixys.ru – почтовый ящик администратора сервера

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

service exim4 restart

проверяем, что он запущен:

service exim4 status
● exim4.service - LSB: exim Mail Transport Agent
   Loaded: loaded (/etc/init.d/exim4; generated)
   Active: active (running) since Sun 2021-12-19 18:18:11 MSK; 1s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 943 ExecStart=/etc/init.d/exim4 start (code=exited, status=0/SUCCESS)
    Tasks: 1 (limit: 1171)
   Memory: 2.1M
   CGroup: /system.slice/exim4.service
       	└─1191 /usr/sbin/exim4 -bd -q30m

Проверяем, что права на файлы и каталоги exim следующие:

drwxr-x--- 3 root Debian-exim [...] exim4

Помните, что для работы почтового сервиса в режиме smarthost открытие 25 порта не требуется, так как осуществляется только отправка почты.

На данном этапе вы можете проверить отправку почты из консоли, достаточно будет просто ввести команду вида:

echo "Hello there" | mail -s "world" -r адрес@отправителя адрес@получателя

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

Заключение

Обратите внимание, что в данной статье не описывается настройка фаервола. Вы можете настроить правила фаервола любым из доступных вам решений. Для простых проектов мы используем надстройку над iptables в виде пакета nxs-ferm, в основу которого лег стандартный ferm с небольшими изменениями.

Во второй части статьи мы расскажем о настройке веб-серверов.

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