1. Установка и первичная настройка базового образа CentOS 7/8

а) Установка системы

Установка описана в основном для CentOS 7, но для CentOS 8 всё аналогично: где надо - сделано уточнение, а если нет уточнения - всё аналогично, только в качестве утилиты работы с пакетами в CentOS 8 используется dnf (в CentOS 7 был yum), поэтому для установки ПО надо использовать dnf, вместо указанного yum (хотя можно и yum: это в CentOS 8 лишь алиас для dnf).
Устанавливаем сервер с образа сетевой установки CentOS 7/8 x86_64. Для создания сервера-шаблона используем "жёсткий диск" размером 50ГБ (в дальнейшем можно расширять под конкретные задачи).
На первой закладке язык установки оставляем "по умолчанию", т.е. "English (United States)".
В следующем окне:
1) в "Localization" выбираем временную зону ("Date & Time"), поддерживаемые языки и их порядок ("Language Support") и клавиатурные раскладки ("Keyboard");
2) в "System" включаем подключение к сети (в "Network & Hostname" указываем имя сервера, включаем сетевой интерфейс (если получаем адрес по DHCP) или настраиваем адрес и потом включаем (если статический адрес));
3) так же в "System" выбираем, на как[ой|ие] накопител[ь|и] будем ставить систему ("Installation Destination"); при этом рекомендуется оставить использование LVM и организовать такую структуру логических томов и точек их монтирования (размеры примерные: на практике выбираются исходя из задач):


Логический том Объём / Комментарий / 25 ГБ /boot 1 ГБ /home 2 ГБ /var 2 ГБ /var/log 2 ГБ /var/log/audit 1 ГБ /opt всё оставшееся свободное место /tmp * используя tmpfs (описано в 'Дополнительные действия') /var/tmp * в /tmp через mount --bind (описано в 'Дополнительные действия')

* - переводить на TMPFS в пониманием: некоторое прикладное ПО может не работать. Но, по возможности, это применять рекомендуется, т.к. позволяет немного ускорить работу системы и снизить "засорение" системы. Иногда /tmp переводится на TMPFS, а /var/tmp оставляется, как есть.


б) Настройка сети

Отключаем поддержку IPv6 (при необходимости), указав в файле /boot/grub2/grub.cfg новый параметр ядра:


ipv6.disable=1

Либо добавив его в файле (обычно рекомендуют) /etc/default/grub в параметр GRUB_CMDLINE_LINUX и сгенерировав новый файл /boot/grub2/grub.cfg командой:


$ grub2-mkconfig -o /boot/grub2/grub.cfg

Так же можно отключить новое именование сетевых интерфейсов (чтобы было классическое eth0, eth1 и т.д.),


net.ifnames=0

В файл /etc/sysctl.conf добавляем строки:


net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1

Перезагружаем систему для принятия изменений.
Если адрес получается по DHCP, то действий с настройкой делать не нужно.
Но на серверах динамическая адресация не приветствуется, поэтому создаём интерфейс с наименованием "LAN" и требуемой адресацией:


# предварительно сменим название сетевого профиля # (в примере "System eth0" на "LAN") $ nmcli connection modify "System eth0" connection.id LAN # назначаем целевые сетевые параметры $ nmcli connection add con-name "LAN" ifname eth0 autoconnect yes type ethernet ip4 192.168.1.21/24 gw4 192.168.1.1 $ nmcli connection modify "LAN" ipv4.method manual $ nmcli connection modify "LAN" ipv4.dns 192.168.1.2 # если необходимо добавить ещё IP и DNS $ nmcli connection modify "LAN" +ipv4.addresses 192.168.22.4/24 $ nmcli connection modify "LAN" +ipv4.dns 8.8.8.8 # для принятия изменений $ nmcli connection down id "LAN" $ nmcli connection up "LAN"

При необходимости смены уже назначенной адресации:


$ nmcli connection down id "LAN" $ nmcli connection modify "LAN" ipv4.addresses 192.168.1.23/24 $ nmcli connection up id "LAN" # связывание конфигурации с интерфейсом $ nmcli connection modify "LAN" connection.interface-name eth0

Т.к. настройку системы напрямую в консоли сервера производить не очень удобно (тем более, если этой виртуальный сервер, размещённый удалённо), то поднимем SSH сервер (обычно он настроен на автозапуск при установке):


$ systemctl enable ssh $ systemctl start ssh

Всю дальнейшую настройку будем производить удалённо:


$ ssh username@192.168.1.21

На данном этапе сетевые настройки при использовании статического IP-адреса достаточны.



в) Установка и настройка репозиториев и обновление системы

Чистим все кэши установочной утилиты yum (хотя в чистой системе и так всё чисто) и формируем актуальный кэш:


$ yum clean all && yum makecache

Устанавливаем репозитории из пакетов (EPEL, ElRepo, PostgreSQL, Remi (PHP), Zabbix) исключая ненужные при необходимости:


### Основные # CentOS 7 $ yum install http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm \ https://www.elrepo.org/elrepo-release-7.0-4.el7.elrepo.noarch.rpm \ https://repo.zabbix.com/zabbix/4.4/rhel/7/x86_64/zabbix-release-4.4-1.el7.noarch.rpm # CentOS 8 $ dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm \ https://www.elrepo.org/elrepo-release-8.0-2.el8.elrepo.noarch.rpm \ https://repo.zabbix.com/zabbix/4.4/rhel/8/x86_64/zabbix-release-4.4-1.el8.noarch.rpm ### PostgreSQL # CentOS 7 $ yum install https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm # CentOS 8 $ dnf install https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-8-x86_64/pgdg-redhat-repo-42.0-5.noarch.rpm ### Дополнительные (устанавливать по необходимости) # CentOS 7 yum install http://repo.iotti.biz/CentOS/7/noarch/lux-release-7-1.noarch.rpm \ http://rpms.famillecollet.com/enterprise/remi-release-7.rpm \ http://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-5.el7.nux.noarch.rpm \ https://download1.rpmfusion.org/free/el/rpmfusion-free-release-7.noarch.rpm \ https://download1.rpmfusion.org/nonfree/el/rpmfusion-nonfree-release-7.noarch.rpm # CentOS 8 dnf install http://repo.iotti.biz/CentOS/7/noarch/lux-release-7-1.noarch.rpm \ http://rpms.famillecollet.com/enterprise/remi-release-8.rpm \ http://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-5.el7.nux.noarch.rpm \ https://download1.rpmfusion.org/free/el/rpmfusion-free-release-8.noarch.rpm \ https://download1.rpmfusion.org/nonfree/el/rpmfusion-nonfree-release-8.noarch.rpm

По инструкции добавляем (если надо) репозиторий Nginx:
а) создаём файл /etc/yum.repos.d/nginx.repo:


[nginx-stable] name=nginx stable repo baseurl=http://nginx.org/packages/centos/$releasever/$basearch/ gpgcheck=1 enabled=1 gpgkey=https://nginx.org/keys/nginx_signing.key [nginx-mainline] name=nginx mainline repo baseurl=http://nginx.org/packages/mainline/centos/$releasever/$basearch/ gpgcheck=1 enabled=0 gpgkey=https://nginx.org/keys/nginx_signing.key

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


$ yum-config-manager --enable nginx-mainline

б) скачиваем и импортируем файл ключа:


$ wget http://nginx.org/keys/nginx_signing.key -O /etc/pki/rpm-gpg/RPM-GPG-KEY-nginx $ rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-nginx

Все необходимые репозитории установлены, но надо их настроить. Для этого в каталоге /etc/yum.repos.d во всех файлах для включаемых репозиториев в параметре enabled ставим 1:


enabled=1

Из указанного списка оставляем такие:


# CentOS 7 base centosplus elrepo elrepo-extras epel extras fasttrack updates zabbix # CentOS 8 AppStream BaseOS centosplus elrepo elrepo-extras epel epel-playground extras fasttrack zabbix

Если планируется установка Nginx, PostgreSQL и PHP последних версий (Zabbix-агента рекомендую ставить последних версий), то включаем следующие репозитории:


nginx pgdg11 remi-php72 remi-safe repos

Информация о доступных репозиториях - на сайте проекта.
Теперь обновляем систему полностью:


# CentOS 7 $ yum clean all && yum makecache && yum upgrade # CentOS 8 $ dnf clean all && dnf upgrade --refresh

И ставим необходимый (для меня) список базовых пакетов:


### Основные # CentOS 7 $ yum install net-tools mc nano screen htop iotop atop dnstop bind-utils traceroute telnet nano wget curl lsof policycoreutils-python mailx unzip gzip redhat-lsb-core \ bash-completion yum-utils device-mapper-persistent-data lvm2 $ yum install zabbix-agent zabbix-get zabbix-sender # CentOS 8 $ dnf install net-tools mc nano screen htop iotop atop dnstop bind-utils traceroute telnet nano wget lsof policycoreutils-python-utils mailx unzip redhat-lsb-core \ bash-completion dnf-utils $ dnf install zabbix-agent zabbix-get zabbix-sender ### Дополнительно (при необходимости) # добавляем UnRAR $ yum install unrar --enablerepo=nux-dextop # если в консоли вместо кириллицы отображаются квадратики (нечитаемое) $ yum install http://mirror.yandex.ru/fedora/russianfedora/russianfedora/free/fedora/releases/27/Everything/x86_64/os//workaround-cyrillic-console-1.1-3.fc23.R.noarch.rpm

На серверах, тем более на которых функционируют сервисы в промышленной эксплуатации, необходимо контролировать установку обновлений системного и прикладного ПО. Поэтому отключаем автоматическую установку обновлений, но разрешаем ежедневную проверку и их скачивание, исправив в файле yum-cron.conf параметры:


update_messages = yes download_updates = yes apply_updates = no

В файле yum-cron-hourly.conf все эти параметры устанавливаем в "no". Если, конечно, нам не нужно ежечасная проверка обновлений.
По окончании настройки yum-cron перезапускаем его для принятия конфигурации:


$ systemctl restart yum-cron.service

г) Почтовое оповещение

Сервер должен не только обеспечивать работу требуемого ПО, но и сообщать о собственном состоянии. Для этого классически используются почтовые сообщения. В качестве почтового агента (MTA) в Scientific Linux / CetnOS 7 используется postfix. Его и настраиваем.
В файл /etc/aliases добавляем email админа сервера в качестве алиаса к root:


root: admin_email@mydomain.ru

И из него обновляем /etc/aliases.db:


$ newaliases

Создаём файл /etc/postfix/virtual_aliases и кроме root, при необходимости, добавляем адреса, с которых отправляют сообщения прикладные программы, например, GitLab (в отличии от /etc/aliases здесь не нужны двоеточия):


root admin_email@mydomain.ru root@mydomain.ru admin_email@mydomain.ru admin admin_email@mydomain.ru

И обновляем соответствующий db файл:


$ postmap /etc/postfix/virtual_aliases

Теперь займёмся основным конфигурационным файлом posfix-а. Сохраним старый:


$ mv /etc/postfix/main.cf /etc/postfix/main.cf-base

А качестве нового /etc/postfix/main.cf впишем следующее (изменив параметры отправки почты на свои):


queue_directory = /var/spool/postfix command_directory = /usr/sbin daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix mail_owner = postfix myhostname = servername.mydomain.ru mydomain = mydomain.ru myorigin = $mydomain inet_interfaces = localhost inet_protocols = ipv4 mydestination = $myhostname, localhost.$mydomain, localhost unknown_local_recipient_reject_code = 550 relayhost = smtp-relay.gmail.com #relaydomain = mydomain.ru alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases disable_vrfy_command = yes debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 sendmail_path = /usr/sbin/sendmail.postfix newaliases_path = /usr/bin/newaliases.postfix mailq_path = /usr/bin/mailq.postfix setgid_group = postdrop html_directory = no manpage_directory = /usr/share/man sample_directory = /usr/share/doc/postfix-2.10.1/examples readme_directory = /usr/share/doc/postfix-2.10.1/README-Postfix-SASL-RedHat.txt virtual_alias_maps = hash:/etc/postfix/virtual_aliases

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


$ systemctl restart postfix.service $ echo "TestMail from server servername.mydomain.ru" | mail -s TestMail root

Если всё нормально, то на адрес админа admin_email@mydomain.ru придёт это письмо. В случае проблем смотрим в логах почтовой системы: /var/log/maillog.
Может возникнуть необходимость перейти с Posfix на альтернативный MTA (или наоборот, после, например, обновления ОС новым MTA может стать msmtp). Для переключения необходимо:


$ отобразить, какая альтернатива MTA используется alternatives --display mta $ выбрать из доступного MTA alternatives из командной строки alternatives --config mta $ установить Postfix в качестве почтовой системы по умолчанию alternatives --set mta

Т.к. здесь рассматривался только вариант отправки сообщений от локальных систем, то на межсетевом экране firewalld ничего не надо открывать: исходящие соединения "по умолчанию" не блокируются.
Для контроля использования команды sudo добавим отсылку соответствующих сообщений в её файл конфигурации /etc/sudoers:


###=-- Доп.конфигурации Defaults mail_always Defaults mailto = "admin_email@mydomain.ru" %wheel ALL=NOPASSWD:/usr/bin/htop

Можно сделать настройки более детальные, например:


User_Alias NoMail = goodboy, goodgirl User_Alias MailUsers = ALL, !NoMail Defaults mailto="omgsudo@example.com" Defaults:MailUsers mail_always Defaults:NoMail !mail_badpass

Для отслеживания статистики неудачных и удачных попыток авторизации создадим скрипт /etc/cron.daily/Auth_info.sh:


#!/bin/bash #============================================= # Статистика авторизации v0.1 - 2017.12.11 #============================================= DATE=`date "+%Y-%m-%d"` HOSTNAME=`hostname` echo "> ===========================================" > /tmp/_aureport-daily.out echo "> Статистика авторизации" >> /tmp/_aureport-daily.out echo "> Дата формирования: "${DATE} >> /tmp/_aureport-daily.out echo "> Имя сервера: "${HOSTNAME} >> /tmp/_aureport-daily.out echo "> -------------------------------------------" >> /tmp/_aureport-daily.out aureport -au --summary -i --failed >> /tmp/_aureport-daily.out echo "> -------------------------------------------" >> /tmp/_aureport-daily.out aureport -au --summary -i --success >> /tmp/_aureport-daily.out echo "> ===========================================" >> /tmp/_aureport-daily.out cat /tmp/_aureport-daily.out | mail -s ${HOSTNAME}": Статистика авторизации" root rm /tmp/_aureport-daily.out

На почтовый адрес админа (root) ежедневно будут приходить сообщения статистики.



д) Установка VMware tools

Если сервер установлен в виртуальной среде VMware, то для корректного управления им из этой среды необходимо установить утилиты для гостевых систем: VMware tools.
Возможны два варианта:
Вариант 1 (рекомендуемый VMware): установить открытые утилиты из репозиториев ОС:


$ yum install open-vm-tools

Вариант 2: скомпилировать и установить утилиты из оф.пакета со средой виртуализации.
Первоначально необходимо подключить ISO образ диска с пакетом утилит: в VMware vSphere client в контекстном меню на данной виртуалке выбираем пункт "Guest / Install/Upgrade VMware Tools".
Далее - всё делается в гостевой.
Ставим необходимы пакеты:


$ yum install kernel-devel gcc dracut make perl eject binutils

Монтируем CD/DVD:


# создаём папку монтирования CD/DVD $ mkdir /mnt/cdrom # и монтируем в созданную папку наш диск $ mount /dev/cdrom /mnt/cdrom

Распаковываем и компилируем утилиты под наш сервер:


$ tar -xvf /mnt/cdrom/VMwareTools*.tar.gz -C /tmp # запускаем установочный файл $ cd /tmp/vmware-tools-distrib $ ./vmware-install.pl

Далее следуем появляющимся сообщениям, внимательно читая их.



е) Конфигурация межсетевого экрана firewalld

Т.к. серверы чаще всего используются на работе, то рекомендуется настроить межсетевой экран (МСЭ) firewalld:


# установит зону по умолчанию $ firewall-cmd --set-default-zone=work # добавим, при необходимости, в эту зону сетевой интерфейс, # если их несколько (если он один - добавится автоматически) $ firewall-cmd --zone=work --add-interface=eth0 # посмотрим список сервисов, открытых в зоне work $ firewall-cmd --zone=work --list-services # создадим сервис zabbix-agent, если его нет (вероятней всего) # если zabbix не используется - пропускаем эти две строки $ firewall-cmd --permanent --new-service=zabbix-agent $ firewall-cmd --permanent --service=zabbix-agent --add-port=10050/tcp # добавим нужные сервисы и отключим ненужные $ firewall-cmd --permanent --zone=work --add-service=zabbix-agent --add-service=ssh $ firewall-cmd --permanent --zone=work --remove-service=dhcpv6-client # перезагрузим созданную конфигурацию $ firewall-cmd --reload

Дополнительная информация: FirewallD/ru.



ё) Настройка SELinux

№1 - Сброс контекста
При получении подготовленного кем-то иным сервера для дальнейшей настройки поинтересуйтесь, есть ли там специфические настройки подсистемы SELinux. Если всё "по умолчанию", но не лишним будет после установки обновлений и перезагрузки пересобрать политику и на её основе восстановить все контексты:


# пересобираем политику $ semodule -B # выставляем метку для автоматического восстановления контекстов при перезагрузке: $ touch /.autorelabel

Для проверки наличия проблем из-за срабатывания SELinux изучается файл /var/log/audit/audit.log:


$ cat /var/log/audit/audit.log | grep denied

В случае, например, проблем с zabbix-agent на основе этого журнала возможно создание политики (не очень хорошее дело, т.к. не контролируется необходимость всех пунктов):


$ cat /var/log/audit/audit.log | grep zabbix_agent | grep denied | audit2allow -M zabbix_agent_setrlimit $ semodule -i zabbix_agent_setrlimit.pp

Можно вообще отключить SELinux, изменив в файл /etc/selinux/config соответствующий параметр:


SELINUX=disabled

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

№2 - Настройка для web-сервера
Если планируется установка web-сервера и использовать его на нестандартном порту, а файлы сайтов будут размещаться в нестандартном каталоге, то надо сообщить SELinux об этом, чтобы он выставил необходимые контексты.
В случае с каталогом:


# Смотрим все контектсты, связанные с web (при необходимости - grep-им глубже) $ semanage fcontext -l | grep httpd # Устанавливает для нашего каталога /opt/frontend (и всех вложенных каталогов) # контекст httpd_sys_content_t $ semanage fcontext -a -t httpd_sys_content_t "/opt/frontend(/.*)?" # Для каталога загрузки файлов через web устанавливаем контекст # httpd_sys_rw_content_t с разрешением чтения и записи $ semanage fcontext -a -t httpd_sys_rw_content_t '/opt/frontend(/.*)?/uploads(/.*)?' # Для каталога журналов $ semanage fcontext -a -t httpd_log_t "/opt/frontend/logs(/.*)?" # Для каталога кэша $ semanage fcontext -a -t httpd_cache_t "/opt/frontend/cache(/.*)?" # Устанавливаем нашим каталогам созданные контексты $ resotecon -R -v /opt/frontend/

При использовании нестандартного порта:


# Посмотреть текущий список HTTP портов $ semanage port -l | grep ^http_port_t # если нашего порта нет - добавить в этот список $ semanage port -a -t http_port_t -p tcp 9003

При необходимости предоставить дополнительные разрешения Zabbix агенту:


$ setsebool -P zabbix_can_network 1 $ semanage permissive -a zabbix_agent_t

Дополнительных действий не требуется.



ж) Настройка SSH

Сервер SSH по умолчанию в системе запущен и доступен на порту 22/tcp.
Для его настройки внесём необходимые корректировки конфигурационного файла сервера /etc/ssh/sshd_config), указав (раскомментировав и исправив) следующие параметры:


Port 22 # оставляем стандартный, если сервер # не будет доступен через сеть Интернет Protocol 2 # более старые версии не безопасны PermitRootLogin no # запрет авторизации root-а AllowUsers UserName # разрешённые пользователи (если будут ограничения) # если требуется обязательная авторизация по ключу PasswordAuthentication no ChallengeResponseAuthentication no

Перед перезапуском сервиса убеждаемся, что у нас есть авторизационные данные, по которым мы момжем подключиться (ниже описало добавление пользователя и настройка ему доступа по ключу).
Перезапускаем сервис:


$ systemctl restart sshd

Теперь для получения полных прав (суперпользователя root) необходимо двойная авторизация:
1) авторизованным зарегистрированным пользователей по ключу;
2) этим же пользователем (если он добавлен к группу wheel) посредством команды sudo.
Если мы настраиваем систему, полученную клонированием ранее настроенной, то необходимо произвести действия, описанные в
и) Дополнительные действия / №2 - При донастройке сервера-клона.



з) Синхронизация времени

Вместе с systemd в Linux пришла замена для демона синхронизации времени ntpd: теперь это chrony, который очень сильно похож на ntpd (в том числе и конфигурированием).
Установим его и включим автозапуск:


$ yum install chrony $ systemctl enable chronyd

Конфигурационный файл /etc/chrony.conf приведём к следующему виду (указан адрес для собственного, внутреннего, сервера времени: при необходимости использования внешних - указываем их, или оставляем серверы, указанные в файле по умолчанию):


server 192.168.1.1 driftfile /var/lib/chrony/drift logdir /var/log/chrony makestep 1.0 3 rtcsync # allow 192.168.0.0/16 deny all

Если надо, чтобы демон chronyd был сервером времени для других серверов, что настроим права доступа (пример: последние две строки).
Остаётся запустить и проверить работу сервиса:


$ systemctl start chronyd $ chronyc sources

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



и) Дополнительные действия

№1 - Подключения TMPFS
Для подключения по tmpfs каталогов /tmp и /var/tmp, описанных в п.1. добавляем в /etc/fstab:


tmpfs /tmp tmpfs size=512m,exec,nosuid 0 0 /tmp /var/tmp bind rw,bind 0 0

Вместо первой строчки (создание /tmp в tmpfs) можно запустить соответствующий сервис (размер /tmp быдет выбран автоматически исходя из размеров доступной памяти):


# проверка состояния автозапуска сервиса $ systemctl is-enabled tmp.mount # включение автозапуска $ systemctl enable tmp.mount # включение $ systemctl start tmp.mount

Иных действий делать не надо в это случае.

№2 - При донастройке сервера-клона
2.1) В случае настройки системы, полученной клонированием ранее уже настроенной (например, из сервера-шаблона) необходимо:
1) сменить на сервере-копии ключи сервера SSH (перезапускать SSH не обязательно: для новых подключений будут использоваться новые ключи.):


# Удаляем старые $ rm /etc/ssh/ssh_host_*_key* # Генерируем новые $ ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N '' $ ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -N '' $ ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N '' # восстанавливаем контекст SELinux для новых файлов $ restorecon -Rv /etc/ssh

2) сменить Machine ID:


$ rm /etc/machine-id $ systemd-machine-id-setup

Естественно, не забываем сменить hostname. :-D
2.2) В случае использования всё таки динамической адресации (DHCP), когда используется к качестве DHCP клиента dhclient необходимо настроить его файл конфигурации, чтобы адрес получался только с основного ("физического") сетевого интерфейса (что может быть полезно, когда в системе много виртуальных, например, при установленной на сервере системе контейнеризации Docker).
Создаём (отсутствует по умолчанию) файл /etc/dhcp/dhclient.conf:


timeout 60; retry 60; reboot 10; select-timeout 5; initial-interval 2; # reject 192.168.1.9; interface "eth0" { send host-name "srv-name.mydomain.local"; supersede domain-search "mydomain.local", "mydomain.loc"; # можно жёстко задать IP адрес static ip_address=192.168.1.18/22 # prepend domain-name-servers 127.0.0.1; request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name; require subnet-mask, domain-name-servers; # script "/usr/sbin/dhclient-script"; } alias { interface "eth0"; fixed-address 192.168.1.18; option subnet-mask 255.255.252.0; }

fixed-address - адрес, получаемый от DHCP сервера;
option subnet-mask - маска сети, получаемая от DHCP сервера.
Перегружаем сервер.

№4 - Создание пользователей
Для добавления пользователя:


# Создаём профиль пользователя NewUser $ useradd -m -s /bin/bash NewUser # добавляем его в группы users,wheel $ usermod -aG users,wheel NewUser # назначаем пароль (временный)... $ passwd NewUser # ... и указываем, что при первом входе # пользователь обязан его сменить $ chage -d 0 NewUser # генерируем себе пару ключей c с именем id_myserver (сохраняем, например, на зашифрованной "флешке", # чтобы никто, кроме нас не мог воспользоваться имя для доступа) $ ssh-keygen -t ecdsa -f id_myserver # создаём для авторизации по ключу файл авторизации $ mkdir -p /home/NewUser/.ssh/ # ... и указываем СОДЕРЖИМОЕ открытой части сгенерированного ключа: id_myserver.pub $ echo "<id_myserver.pub>" > /home/NewUser/.ssh/authorized_keys $ chmod -R 600 /home/NewUser/ $ find /home/NewUser/ -type d -exec chmod 700 {} \; $ chown -R NewUser:NewUser /home/NewUser/ $ chattr +i /home/NewUser/.ssh/authorized_keys

Всё, добавлен пользователь NewUser с возможностью входа в систему с правами суперпользователя через утилиту sudo. Передаём пользователю профиля NewUser имя профиля и назначенный пароль.



к) Дополнительная информация

Настройка Network Manager в консоли



2. Настройка обозревателя FireFox

Вход в конфигурационное меню - через адрес:


about:config

Далее - конфигурационные параметры:
1) возврат адресной строке её функцию: отключение отправки введённого текста поисковым системам:


keyword.enabled=false

2) отмена преобразования shortname в www.shortname.com:


browser.fixup.alternate.enabled=false

а) Сжатие баз sqlite в профиле FireFox

FireFox все данные в профиле хранит (кроме кэша) в базах SQLite. И, естественно, со временем файлы баз распухают и ОгнеЛис всё медленней загружается и работает. Для исключения этого данные базы надо периодически "сжимать", удаляя освободившееся место физически из файлов.
Всё делается самим SQLite-ом::


$ cd ~/.mozilla/firefox/*.default/ $ for i in *.sqlite; do echo "VACUUM;" | sqlite3 $i ; done

… или ещё один вариант в одну строчку:


$ find ~/.mozilla/firefox -type f -name *.sqlite -exec sh -c 'echo VACUUM\; | sqlite3 {}' \;

Результат: сильно "похудевшие" файлы баз.



б) Настройки безопасности FireFox/SeaMonkey

№1. Общие моменты
Вызываем скрытые настройки по about:config в адресной строке, ищем параметр и выставляем его в false. Есть исключения, но они указываются конкретно.
Отключаем WebRTC, позволяющего отслеживать реальный IP


media.peerconnection.enabled

Google Safe Browsing
Который сливает историю сёрфинга в Google. Требуется предупреждение, что отключение Safe Browsing повышает риск подхватить заражения в результате посещения вредоносного сайта.


browser.safebrowsing.enabled browser.safebrowsing.downloads.enabled browser.safebrowsing.downloads.remote.enabled services.sync.prefs.sync.browser.safebrowsing.enabled services.sync.prefs.sync.browser.safebrowsing.malware.enabled browser.safebrowsing.malware.enabled

Статистика Firefox
Отправляет в Mozilla отчёты о стабильности и производительности.


datareporting.healthreport.service.enabled datareporting.healthreport.uploadEnabled

Статистика использования


toolkit.telemetry.enabled

Encrypted Media Extensions (DRM)
Бинарный плагин с неизвестным исходным кодом, который поставляется вместе с Firefox, начиная с версииv 38. Позволяет воспроизводить зашифрованный медиаконтент и использовать Netflix и др. без Microsoft Silverlight. Для полного удаления плагина нужно установить версию EME-free браузера Firefox.


media.eme.enabled media.gmp-eme-adobe.enabled

Firefox Hello
Firefox подключается к сторонним серверам (Telefonica) без разрешения.


loop.enabled

Интеграция с Pocket
Сторонний сервис для управления списком статей, отложенных для прочтения.


browser.pocket.enabled

Геолокация


geo.enabled

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


browser.search.suggest.enabled

Защита от слежки со стороны сайтов
В отличие от всех перечисленных выше, эту опцию, наоборот, следует включить. Это нужно для активной блокировки сайтов, которые известны своим некорректным поведением в отношении слежки за пользователями. Не путать с DNT, которая только «просит» сайты не отслеживать вас. Здесь же осуществляется принудительная блокировка.


privacy.trackingprotection.enabled services.sync.prefs.sync.privacy.trackingprotection.enabled

С обновлением FireFox/SeaMonkey данные параметры могут изменяться или даже даже вообще исчезать.
Так же между этими браузерами эти параметры могут отличаться и отличаются.
№2. DNS over HTTP
Необходимо установить следующие параметры:
а) network.security.esni.enabled = true;
б) network.trr.bootstrapAddress = 1.1.1.1 (или 8.8.8.8);
в) network.trr.mode = 2 (или 3):
  1 - используется DNS или DoH, в зависимости от того, что быстрее;
  2 - используется DoH по умолчанию, а DNS как запасной вариант;
  3 - используется только DoH (пока не работает, дорабатывается);
  4 - режим зеркалирования при котором DoH и DNS задействованы параллельно;
  5 - явное отключение DoH.
в) network.trr.custom_uri = https://dns.google.com/experimental;
г) network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query ("по умолчанию"):
  - https://dns.google.com/experimental;
  - https://cloudflare-dns.com/dns-query;
  - https://dns.quad9.net/dns-query (он же https://9.9.9.9/dns-query);
  - https://doh.powerdns.org;
  - https://doh.cleanbrowsing.org/doh/family-filter/ (с родительским контролем);
  - https://doh2.dnswarden.com (с родительским контролем);
  - https://dns.dnsoverhttps.net/dns-query (проброс запросов через tor);
  - https://doh.securedns.eu/dns-query (заявлено об отсутствии ведения логов);
  - https://doh.crypto.sx/dns-query (на базе doh-proxy);
  - https://doh-de.blahdns.com/dns-query (используется реализация на Go);
  - https://dns.dns-over-https.com/dns-query (используется реализация на Go);
  - https://commons.host (реализация на Node.js).
Для проверки работы есть специальный сайт: Browsing Experience Security Check.



3. Установка и настройка CGroup

Устанавливаем утилиты поддержки CGroup:


$ dnf install libcgroup-tools

Запускаем сервис CGroup:


$ systemctl enable cgconfig.service $ systemctl start cgconfig.service

Создаём файл /etc/cgconfig.conf следующего содержания:


mount { memory = /cgroup/mem_lim; } group limit_mem { memory { # вначале memory.limit_in_bytes, потом memory.memsw.limit_in_bytes memory.limit_in_bytes = 5368709120; memory.memsw.limit_in_bytes = 9663676416; } }

Запускаем сервис CGroup:


$ systemctl restart cgconfig.service

Fedora. Документация | Глава 2. Работа с контрольными группами
RedHat | ⁠Chapter 3. Subsystems and Tunable Parameters
CGroups - вводная. Базовые практические примеры



4. Система полнотекстового поиска Sphinx

Установка и настройка на CentOS 7 и индексацией данных из СУБД PostgreSQL и MS SQL.
Устанавливаем необходимые дополнительные пакеты...


# для PostgreSQL $ yum install postgresql-libs # для MS SQL $ yum install unixODBC freetds freetds-devel

... и сам Sphinx ():


$ yum install http://sphinxsearch.com/files/sphinx-2.2.11-1.rhel7.x86_64.rpm

При необходимости подключаемся к нашей СУБД утилитой psql и создаём БД:


$ sudo -u postgres psql [...]

Или загружаем БД из файла:


$ cat sphinx_test.sql | psql -U uzabbix -d db_zabbix

В нашем случае мы индексируем таблицу evets базы данных db_zabbix, используемой системой мониторинга Zabbix (для теста).
Для созданных/выбранных БД и таблицы создаём файл конфигурации Sphinx-а.


$ mv /etc/sphinx/sphinx.conf /etc/sphinx/sphinx.conf-0 $ touch /etc/sphinx/sphinx.conf

И корректируем


# общие параметры searchd { listen = 9312:sphinx # SphinxAPI port listen = 9306:mysql41 # SphinxQL port # для корректной работы со Sphinx коннекторов MySQL в Visual Studio # http://chakrygin.ru/2013/05/sphinx-and-dot-net.html mysql_version_string = 5.0.37 pid_file = /var/run/sphinx/searchd.pid log = /var/log/sphinx/searchd.log query_log = /var/log/sphinx/query.log query_log_format = sphinxql binlog_path = /var/lib/sphinx/ read_timeout = 5 max_children = 100 persistent_connections_limit = 90 seamless_rotate = 1 preopen_indexes = 1 unlink_old = 1 workers = threads rt_flush_period = 3600 } # источники данных #-------------------------- source src_zabbixevents { # тип СУБД - PostgreSQL type = pgsql # параметры подключения sql_host = 192.168.1.5 # или localhost sql_port = 5432 sql_user = <USER_NAME> sql_pass = <PAS$W0RD> # используемая БД, запрос и атрибуты sql_db = <DB_NAME> sql_query = SELECT eventid, object, objectid, clock, value, acknowledged FROM events sql_attr_bigint = eventid sql_attr_uint = object sql_attr_bigint = objectid sql_attr_uint = clock sql_attr_uint = acknowledged } source src_mssql_connect { # тип СУБД - MS SQL через ODBC драйвер FreeTDS type = odbc # строка подключения ODBC драйвера odbc_dsn = DSN=MSSQL-Sphinx;Driver={/etc/odbc.ini};Uid=<USER_NAME>;Pwd=<PAS$W0RD> # в случае подключения к MS Azure # odbc_dsn = DSN=MSSQL-Azure;Driver={/etc/odbc.ini};Uid=<USER_NAME>@<SERVER_NAME>;Pwd=<PAS$W0RD> } source src_orgclients : src_mssql_connect { sql_query = SELECT Id AS Iid, ClientGUID, ClientName, ClientType, FIndex, FCity, FAddress FROM dbo.orgClients sql_attr_string = ClientGUID sql_attr_uint = ClientType sql_attr_string = JIndex sql_attr_string = FIndex } source src_cargoservicecompany : src_mssql_connect { sql_query = SELECT OrgGuid AS Id, OrgGuid, CompanyName, UserGuid, RouteType FROM OrdersCargoServiceCompany WHERE UserGuid IS NOT NULL AND RouteType IS NOT NULL sql_attr_string = OrgGuid sql_attr_string = UserGuid sql_attr_uint = RouteType } # индексы источников данных #-------------------------- index idx_zabbixevents { source = src_zabbixevents path = /var/lib/sphinx/zabbixevents/index min_infix_len = 2 index_exact_words = 1 } index idx_orgclients { source = src_orgclients path = /var/lib/sphinx/orgclients/index # http://sphinxsearch.com/docs/current.html#conf-morphology morphology = stem_enru # параметры для поиска по частям слова # https://ruhighload.com/post/Wildcard+поиск+в+Sphinx # dict = keywords # параметр устарел min_prefix_len = 2 expand_keywords = 1 index_exact_words = 1 # для индексации с учётом китайского языка # http://sphinxsearch.com/forum/view.html?id=587 min_word_len = 1 charset_type = utf-8 charset_table = U+FF10..U+FF19->0..9, 0..9, U+FF41..U+FF5A->a..z, U+FF21..U+FF3A->a..z, A..Z->a..z, a..z, U+0149, U+017F, U+0138, U+00DF, U+00FF, U+00C0..U+00D6->U+00E0..U+00F6, U+00E0..U+00F6, U+00D8..U+00DE->U+00F8..U+00FE, U+00F8..U+00FE, U+0100->U+0101, U+0101, U+0102->U+0103, U+0103, U+0104->U+0105, U+0105, U+0106->U+0107, U+0107, U+0108->U+0109, U+0109, U+010A->U+010B, U+010B, U+010C->U+010D, U+010D, U+010E->U+010F, U+010F, U+0110->U+0111, U+0111, U+0112->U+0113, U+0113, U+0114->U+0115, U+0115, U+0116->U+0117, U+0117, U+0118->U+0119, U+0119, U+011A->U+011B, U+011B, U+011C->U+011D, U+011D, U+011E->U+011F, U+011F, U+0130->U+0131, U+0131, U+0132->U+0133, U+0133, U+0134->U+0135, U+0135, U+0136->U+0137, U+0137, U+0139->U+013A, U+013A, U+013B->U+013C, U+013C, U+013D->U+013E, U+013E, U+013F->U+0140, U+0140, U+0141->U+0142, U+0142, U+0143->U+0144, U+0144, U+0145->U+0146, U+0146, U+0147->U+0148, U+0148, U+014A->U+014B, U+014B, U+014C->U+014D, U+014D, U+014E->U+014F, U+014F, U+0150->U+0151, U+0151, U+0152->U+0153, U+0153, U+0154->U+0155, U+0155, U+0156->U+0157, U+0157, U+0158->U+0159, U+0159, U+015A->U+015B, U+015B, U+015C->U+015D, U+015D, U+015E->U+015F, U+015F, U+0160->U+0161, U+0161, U+0162->U+0163, U+0163, U+0164->U+0165, U+0165, U+0166->U+0167, U+0167, U+0168->U+0169, U+0169, U+016A->U+016B, U+016B, U+016C->U+016D, U+016D, U+016E->U+016F, U+016F, U+0170->U+0171, U+0171, U+0172->U+0173, U+0173, U+0174->U+0175, U+0175, U+0176->U+0177, U+0177, U+0178->U+00FF, U+00FF, U+0179->U+017A, U+017A, U+017B->U+017C, U+017C, U+017D->U+017E, U+017E, U+0410..U+042F->U+0430..U+044F, U+0430..U+044F, U+05D0..U+05EA, U+0531..U+0556->U+0561..U+0586, U+0561..U+0587, U+0621..U+063A, U+01B9, U+01BF, U+0640..U+064A, U+0660..U+0669, U+066E, U+066F, U+0671..U+06D3, U+06F0..U+06FF, U+0904..U+0939, U+0958..U+095F, U+0960..U+0963, U+0966..U+096F, U+097B..U+097F, U+0985..U+09B9, U+09CE, U+09DC..U+09E3, U+09E6..U+09EF, U+0A05..U+0A39, U+0A59..U+0A5E, U+0A66..U+0A6F, U+0A85..U+0AB9, U+0AE0..U+0AE3, U+0AE6..U+0AEF, U+0B05..U+0B39, U+0B5C..U+0B61, U+0B66..U+0B6F, U+0B71, U+0B85..U+0BB9, U+0BE6..U+0BF2, U+0C05..U+0C39, U+0C66..U+0C6F, U+0C85..U+0CB9, U+0CDE..U+0CE3, U+0CE6..U+0CEF, U+0D05..U+0D39, U+0D60, U+0D61, U+0D66..U+0D6F, U+0D85..U+0DC6, U+1900..U+1938, U+1946..U+194F, U+A800..U+A805, U+A807..U+A822, U+0386->U+03B1, U+03AC->U+03B1, U+0388->U+03B5, U+03AD->U+03B5, U+0389->U+03B7, U+03AE->U+03B7, U+038A->U+03B9, U+0390->U+03B9, U+03AA->U+03B9, U+03AF->U+03B9, U+03CA->U+03B9, U+038C->U+03BF, U+03CC->U+03BF, U+038E->U+03C5, U+03AB->U+03C5, U+03B0->U+03C5, U+03CB->U+03C5, U+03CD->U+03C5, U+038F->U+03C9, U+03CE->U+03C9, U+03C2->U+03C3, U+0391..U+03A1->U+03B1..U+03C1, U+03A3..U+03A9->U+03C3..U+03C9, U+03B1..U+03C1, U+03C3..U+03C9, U+0E01..U+0E2E, U+0E30..U+0E3A, U+0E40..U+0E45, U+0E47, U+0E50..U+0E59, U+A000..U+A48F, U+4E00..U+9FBF, U+3400..U+4DBF, U+20000..U+2A6DF, U+F900..U+FAFF, U+2F800..U+2FA1F, U+2E80..U+2EFF, U+2F00..U+2FDF, U+3100..U+312F, U+31A0..U+31BF, U+3040..U+309F, U+30A0..U+30FF, U+31F0..U+31FF, U+AC00..U+D7AF, U+1100..U+11FF, U+3130..U+318F, U+A000..U+A48F, U+A490..U+A4CF ngram_len = 1 # Параметр ngrams_chars так же может использоваться при работе в кодировке UTF-8. # При этом коды символов не должны пересекаться с кодами в параметре charset_table # http://sphinxsearch.com/forum/view.html?id=15219 } # индексация с realtime-индексом index idx_cargoservicecompany_base { source = src_cargoservicecompany path = /var/lib/sphinx/cargoservicecompany/index morphology = lemmatize_ru min_prefix_len = 2 expand_keywords = 1 index_exact_words = 1 } index idx_cargoservicecompany_realtime { type = rt path = /var/lib/sphinx/cargoservicecompany/index_rt rt_mem_limit = 256M rt_field = CompanyName rt_attr_string = OrgGuid rt_attr_string = UserGuid morphology = lemmatize_ru min_prefix_len = 2 expand_keywords = 1 index_exact_words = 1 } index idx_cargoservicecompany { type = distributed local = idx_cargoservicecompany_base local = idx_cargoservicecompany_realtime }

$ tsql -LH MSSRV-SQL.mydomain.com
     ServerName MSSRV-SQL
   InstanceName SQLEXPRESS
    IsClustered No
	Version 11.0.2100.60
	    tcp 1433
	     np \\MSSRV-SQL\pipe\MSSQL$SQLEXPRESS\sql\query

     ServerName MSSRV-SQL
   InstanceName SQLSERVER
    IsClustered No
	Version 13.0.1601.5
	    tcp 1433
	     np \\MSSRV-SQL\pipe\MSSQL$SQLSERVER\sql\query

В данном случае видно, что есть два экземпляра (instance): SQLEXPRESS и SQLEXPRESS, поэтому правильней будет использовать для подключения не порт 1433, а наименование экземпляра. Наша БД обслуживается экземпляром SQLEXPRESS, поэтому будем указывать его наименование.


$ TDSVER=7.2 tsql -H MSSRV-SQL -p 1433 -U <USER_NAME>
Password:
locale is "ru_RU.utf8"
locale charset is "UTF-8"
using default charset "UTF-8"
1> exit

Можно указать пароль в команде (добавив параметр -P <PAS$W0RD>), но это не безопасно.
Для подключения к БД в MS Azure необходимо имя пользователя указывать в формате <USER_NAME>@<SERVER_NAME>, иначе будет возникать ошибка:


$ TDSVER=7.3 tsql -H MS-SQL-Azure -p 1433 -U user_azure Password: locale is "ru_RU.utf8" locale charset is "UTF-8" using default charset "utf8" Msg 40532 (severity 20, state 1) from MS-SQL-Azure: "Cannot open server "MS-SQL-Azure" requested by the login. The login failed." Error 20002 (severity 9) "Adaptive Server connection failed" There was a problem connecting to the server

Для отладки подключения можно указать файл журнала, использовав переменную TDSDUMP:


$ TDSDUMP=~/freetds.log TDSVER=7.3 tsql -H MS-SQL-Azure -p 1433 -U user_azure

Проверим, где находится библиотека TDS:


$ find /* -name libtdsodbc.so /usr/lib64/libtdsodbc.so

В файл /etc/freetds.conf добавляем блок описания целевого MS SQL сервера:


[MS-SQL-2016] host = MSSRV-SQL # port = 1433 instance = SQLSERVER # tds version = auto tds version = 7.3 # указываем кодировку, выданную командой tsql (выше) client charset = utf8

В файл /etc/odbcinst.ini добавляем описание TDS драйвера:


[FreeTDS] Description = v0.95.81 with protocol v8.0 Driver64 = /usr/lib64/libtdsodbc.so UsageCount = 2

В файл /etc/odbc.ini добавляем подключение к вашим серверу/базе:


[MSSQL-Sphinx] Driver = FreeTDS Description = MS SQL 2016 - Corp. Trace = No Servername = MS-SQL-2016 Database = <DB_NAME>

Снова проверяем подключение к БД серверу утилитой tsql, но уже через созданную конфигурацию:


$ TDSVER=7.2 tsql -S MS-SQL-2016 -I /etc/freetds.conf -U <USER_NAME> -D <DB_NAME> Password: locale is "ru_RU.utf8" locale charset is "UTF-8" using default charset "UTF-8" Setting <DB_NAME> as default database in login packet 1> exit

Если подключение произошло нормально - можно пробовать индексировать наши таблицы.

Снова общие действия для обеих СУБД
Создаём каталог для нашего индекса и назначаем права на него для пользователя, из под которого будет работать демон Sphinx-а:


$ mkdir /var/lib/sphinx/zabbixevents/ $ mkdir /var/lib/sphinx/vclients/ $ chown -R sphinx:sphinx /var/lib/sphinx/ $ chmod -R 770 /var/lib/sphinx/

Производим первичную индексацию:


$ sudo -u sphinx /usr/bin/indexer --all

Если никаких ошибок не выявилось, запускаем Shpinx:


# запускаем демон $ systemctl start searchd # ставим в автоматическую загрузку $ systemctl enable searchd

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


$ sudo -u sphinx /usr/bin/indexer --rotate --config /etc/sphinx/sphinx.conf --all

Т.к. переиндексация должна производиться постоянно с определённым периодом, то в /etc/crontab добавляем (два варианта):


# для ежечасной переиндексации одного конкретного индекса @hourly sphinx /usr/bin/indexer --rotate zabbixevents > /dev/null 2>&1 # для переиндексации каждые полчаса всех индексов */30 * * * * sphinx /usr/bin/indexer --rotate --config /etc/sphinx/sphinx.conf --all > /dev/null 2>&1 # для переиндексации дистрибьютного индекса, содержащего realtime индекс # при переиндексации основного индекса надо "зачищать" (truncate) реалтаймовый. */5 * * * * sphinx mysql -h 127.0.0.1 -P 9306 -e "TRUNCATE RTINDEX idx_cargoservicecompany_realtime" ; /usr/bin/indexer --rotate --config /etc/sphinx/sphinx.conf idx_cargoservicecompany_base > /dev/null 2>&1

Для доступа к серверу извне необходимо открыть на межсетевом экране порты 9306 и 9312, указанные к конфигурационном файле:


$ firewall-cmd --permanent --new-service=sphinx $ firewall-cmd --permanent --service=sphinx --add-port=9306/tcp $ firewall-cmd --permanent --service=sphinx --add-port=9312/tcp $ firewall-cmd --permanent --zone=public --add-service=sphinx $ firewall-cmd --reload

Для проверки работы подключимся клиентом MySQL/MariaDB с удалённой машины:


$ dnf install mariadb $ mysql -h 192.168.1.5 -P 9306

И осталось сделать запрос по нашему индексу:


$ mysql -h 192.168.1.5 -P 9306 Welcome to the MariaDB monitor. Commands end with ; or \g. Your MySQL connection id is 1 Server version: 5.0.37 Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MySQL [(none)]> select * from idx_zabbixevents -> ; +------+--------+----------+------------+--------------+ | id | object | objectid | clock | acknowledged | +------+--------+----------+------------+--------------+ | 1 | 0 | 13491 | 1508713591 | 0 | | 2 | 4 | 23261 | 1508713601 | 0 | | 3 | 0 | 13476 | 1508713601 | 0 | | 4 | 4 | 23262 | 1508713602 | 0 | | 5 | 0 | 13477 | 1508713602 | 0 | | 6 | 4 | 23328 | 1508713608 | 0 | | 7 | 0 | 13436 | 1508713608 | 0 | | 8 | 4 | 23635 | 1508713615 | 0 | | 9 | 0 | 13537 | 1508713615 | 0 | | 10 | 0 | 13491 | 1508713890 | 0 | | 11 | 0 | 13491 | 1508713890 | 0 | +------+--------+----------+------------+--------------+ 20 rows in set (0.03 sec)

Таблица тестовая, данных на момент проверки почти нет, но проверить нам хватило.
Остаётся поставить сервер на мониторинг в систему Zabbix. Для этого ставим агента и локально MySQL/MariaDB:


$ yum install mariadb zabbix-agent

Создаём файлы конфигураций zabbix-agenta:
1) основной /etc/zabbix/zabbix_agentd.conf:


PidFile=/var/run/zabbix/zabbix_agentd.pid LogFile=/var/log/zabbix/zabbix_agentd.log LogFileSize=0 DebugLevel=1 EnableRemoteCommands=1 # Адреса сервера Zabbix Server=192.168.1.101 ServerActive=192.168.1.101 Hostname=sphinx.myserver.ru Timeout=30 Include=/etc/zabbix/zabbix_agentd.d/*.conf

2) мониторинга Sphinx-а /etc/zabbix/zabbix_agentd.d/sphinx.conf:


# Get internal sphinx2 statistics UserParameter=sphinx2.uptime,mysql -s -h 127.0.0.1 -P 9306 -e "show status" | grep -w ^uptime | awk '{print $2}' UserParameter=sphinx2.connections,mysql -s -h 127.0.0.1 -P 9306 -e "show status" | grep -w ^connections | awk '{print $2}' UserParameter=sphinx2.cmd_search,mysql -s -h 127.0.0.1 -P 9306 -e "show status" | grep -w ^command_search | awk '{print $2}' UserParameter=sphinx2.cmd_update,mysql -s -h 127.0.0.1 -P 9306 -e "show status" | grep -w ^command_update | awk '{print $2}' UserParameter=sphinx2.queries,mysql -s -h 127.0.0.1 -P 9306 -e "show status" | grep -w ^queries | awk '{print $2}'

В систему мониторинга Zabbix добавляем шаблон sphinx2-template с GitHub. Переименовываем его в Zabbix-а для идентичности с другими в "Template App Sphinx2".
Создаём узел мониторинга sphinx.myserver.ru, к которому подключаем шаблоны "Template OS Linux" и "Template App Sphinx2".



Дополнительная информация

1) Конвейер обработки текста в Sphinx
2) Sphinx 2.2.11-release reference manual
3) Sphinx - Источники данных, индексы, поля и атрибуты
4) Sphinx - Индексация базы данных и дельта-индексы
5) Sphinx. Установка и первичная настройка
6) Создание ознакомительного поискового движка на Sphinx + php
7) Запросы из Постгреса в Сфинкс через интерфейс мускуля
8) Руководство: Установка и настройка Sphinx на Windows + MS SQL (Часть 1. Установка)
9) FreeTDS: User Guide
10) FreeTDS: Подключение к Microsoft SQL из linux (с помощью FreeTDS)
11) FreeTDS: How to install and configure FreeTDS as an ODBC connector to Microsoft SQL Server on CentOS/RHEL for Lasso 9
12) Microsoft SQL server (MSSQL)
13) Установка Microsoft ODBC Driver for SQL Server для Linux и MacOS



5. Сервер мониторинга Zabbix 3.4 с СУБД PostgreSQL 10

В качестве базовой системы берём установленную и настроенную по п.1.
Устанавливаем необходимые пакеты (PHP, Nginx, PostgreSQL и сам Zabbix):


$ yum install php-fpm zabbix-agent zabbix-server-pgsql zabbix-web-pgsql zabbix-get nginx postgresql10-server

Если надо будет использовать ODBC для работы с БД, доставляем соответствующие пакеты:


$ yum install unixODBC unixODBC-devel # для подключения к БД, не являющиемся нативными для Linux # например, MS SQL $ yum install freetds freetds-devel # для подключения к MySQL / MariaDB $ yum install mysql-connector-odbc # для подключения к PostgreSQL $ yum install postgresql-libs

Инициализируем кластер нашей СУБД:


# с системной кодировкой $ /usr/pgsql-10/bin/postgresql-10-setup initdb postgresql-10 --datadir=/var/lib/pgsql/10/data # или с локалью ru_RU.UTF-8 $ /usr/pgsql-10/bin/postgresql-10-setup initdb postgresql-10 --datadir=/var/lib/pgsql/10/data --locale=ru_RU.UTF-8

Создаём каталог для логов:


$ mkdir /var/log/postgresql/ $ chown -R postgres:postgres /var/log/postgresql/

Корректируем файл основной конфигурации /var/lib/pgsql/10/data/postgresql.conf:


###=-- Подключение ---------------------------------- #listen_addresses = 'localhost' listen_addresses = '*' port = 5432 max_connections = 100 unix_socket_directories = '/var/run/postgresql' unix_socket_permissions = 0777 bonjour = off ###=-- Безопасность и аутентификация ---------------- authentication_timeout = 1min ssl = off password_encryption = on ###=-- Параметры работы в памятью ------------------- shared_buffers = 128MB dynamic_shared_memory_type = posix ###=-- Журналирование ------------------------------- log_destination = 'stderr' logging_collector = on log_directory = '/var/log/postgresql' log_filename = 'postgresql-%a.log' log_truncate_on_rotation = on log_rotation_age = 1d log_rotation_size = 0 #log_line_prefix = '< %m > ' log_line_prefix = '%m [%p] ' log_timezone = 'Europe/Moscow' # syslog_facility = 'LOCAL0' # syslog_ident = 'postgres' # syslog_sequence_numbers = on # syslog_split_messages = on ###=-- Установки времени и локализации -------------- datestyle = 'iso, mdy' timezone = 'Europe/Moscow' lc_messages = 'ru_RU.UTF-8' lc_monetary = 'ru_RU.UTF-8' lc_numeric = 'ru_RU.UTF-8' lc_time = 'ru_RU.UTF-8' # default_text_search_config = 'pg_catalog.english' default_text_search_config = 'pg_catalog.russian' ###=-- Автоматическая 'уборка мусора' (AUTOVACUUM) -- autovacuum = on # log_autovacuum_min_duration = -1 # autovacuum_work_mem = -1 # autovacuum_max_workers = 3 # autovacuum_naptime = 1min # autovacuum_vacuum_threshold = 50 # autovacuum_analyze_threshold = 50 # autovacuum_vacuum_scale_factor = 0.2 # autovacuum_analyze_scale_factor = 0.1 # autovacuum_freeze_max_age = 200000000 # autovacuum_multixact_freeze_max_age = 400000000 # autovacuum_vacuum_cost_delay = 20ms # autovacuum_vacuum_cost_limit = -1 ###=-- РАЗНОЕ --------------------------------------- vacuum_freeze_table_age = 0

Корректируем файл доступа /var/lib/pgsql/10/data/pg_hba.conf, разрешая локальные подключения (для удобства, но при опасении за защищённость - меняем на соответствующую проверку):


# TYPE DATABASE USER ADDRESS METHOD ###=-- "local" is for Unix domain socket connections only local all all trust ###=-- IPv4 local connections: host all all 127.0.0.1/32 trust ###=-- IPv6 local connections: host all all ::1/128 trust

Запускаем PostgreSQL:


$ systemctl start postgresql-10 $ systemctl enable postgresql-10

# Запускать pg_ctl от имени root нельзя
$ su postgres
$ PGDATA=/var/lib/pgsql/10/data/ /usr/pgsql-10/bin/pg_ctl reload
# или 
$ PATH=$PATH:/usr/pgsql-10/bin && PGDATA=/var/lib/pgsql/10/data pg_ctl reload
сигнал отправлен серверу
$ exit

$ sudo -u postgres psql
# или
$ su postgres
$ psql -U postgres
psql (10.1)
Введите "help", чтобы получить справку.

postgres=#

В полученной консоли вводим SQL команды (заменяя строку звёздочек на пароли соответствующих пользователей):


CREATE DATABASE db_zabbix; CREATE USER u_zabbix WITH CREATEDB LOGIN ENCRYPTED PASSWORD '***********'; ALTER USER postgres LOGIN ENCRYPTED PASSWORD '***********'; ALTER DATABASE db_zabbix OWNER TO u_zabbix; GRANT ALL privileges ON DATABASE db_zabbix TO u_zabbix;

"По умолчанию" для создания базы используется шаблон template1, в котором нельзя менять локали и кодировку. Подробней о шаблонах баз - в соответствующем разделе документации: 22.3. Шаблоны баз данных.
Основные команды для управления сервером:


\? - помощь по командам psql \c db_zabbix - сменитьактивную базу на db_zabbix \dt - список сущностей активной базы \du - список ролей (пользователей) с указанием прав \q - выход

Сразу импортируем структуру БД системы Zabbix:


# если перед этим вышли из под пользователя postgres $ su postgres $ zcat /usr/share/doc/zabbix-server-pgsql-3.4.3/create.sql.gz | psql --dbname=db_zabbix --username=u_zabbix

   /etc/php.ini
   /etc/php-fpm.conf
mv /etc/php-fpm.d/www.conf /etc/php-fpm.d/www.conf-base
   /etc/php-fpm.d/zabbix.conf
systemctl enable php-fpm
systemctl start php-fpm

mkdir ~/_Scripts
mkdir ~/_Config
ln -s /etc/php-fpm.d ~/_Config/php-fpm.d
ln -s /etc/nginx ~/_Config/nginx
ln -s /etc/zabbix ~/_Config/zabbix
ln -s /var/log ~/_Logs
ln -s /var/lib/pgsql/10/data ~/_Config/pgsql

chown -R nginx. /etc/zabbix/web
chown -R nginx. /usr/share/zabbix

nginx -t
systemctl start nginx
systemctl enable nginx

firewall-cmd --get-default-zone
firewall-cmd --get-zones
firewall-cmd --set-default-zone=work

firewall-cmd --zone=work --add-interface=eth0

firewall-cmd --get-services

firewall-cmd --zone=work --list-services

firewall-cmd --permanent --new-service=zabbix
firewall-cmd --permanent --service=zabbix --add-port=10050/tcp
firewall-cmd --permanent --service=zabbix --add-port=10051/tcp

firewall-cmd --permanent --zone=work --add-service=zabbix --add-service=http --add-service=postgresql
firewall-cmd --permanent --zone=work --remove-service=dhcpv6-client
firewall-cmd --reload

mkdir /var/log/snmptrap/
touch /var/log/snmptrap/snmptrap.log

systemctl start zabbix-server
systemctl enable zabbix-server
--------------------------------------------

$ cat Мониторинг\ ESXi.txt
1. Установить community string (public (по умолчанию) заменяем на VIro) командой:
# esxcli system snmp set --communities TKro
2. Установить сервер мониторинга (SNMP target), который включает адрес и порт, а также community string:
# esxcli system snmp set --targets 192.168.1.15@161/TKro
3. Включить сервис SNMP на хосте ESXi:
# esxcli system snmp set --enable true
4. Протестировать конфигурацию:
# esxcli system snmp test
Для того, чтобы протестировать SNMP со стороны таргета можно использовать команду (для версии 2):
$ snmpwalk -v2c -c TKro 192.168.88.15



Возможные проблемы

№1 Ошибка "Zabbix poller processes more than 75% busy"
Решается просто – необходимо добавить больше zabbix_server процессов Увеличение процессов ведет к увеличению потребления ресурсов.


StartPollers=20

Перезапускаем zabbix_server и радуемся.



Дополнительная информация

Выражение триггера
Поддерживаемые функции триггеров



6. Система коллективной разработки GitLab Community Edition (Omnibus)

В качестве базовой системы берём систему, установленную по данной инструкции.



а) Новая установка

Устанавливаем необходимые пакеты (они уже должны быть, но перестраховка):


$ yum install curl policycoreutils-python openssh-server postfix

На межсетевом экране firewalld открываем порт HTTP:


$ firewall-cmd --permanent --add-service=http $ firewall-cmd --reload

Запускаем базовый скрипт для предварительной подготовки системы (подключения репозитариев и т.д.):


$ curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash

Изменяя имя сервера на своё запускаем установку основного пакета:


$ EXTERNAL_URL="http://gitlab.mydomain.ru" yum install gitlab-ce

По окончании установки запускаем первичную инициализацию (в последних версиях, возможно, исполнится автоматически):


$ gitlab-ctl reconfigure

Теперь можно войти на сайт http://gitlab.mydomain.ru/ и система сразу предложит установить пароль для администратора. После назначения пароля можем войти в систему, авторизовавшись, как


root / <назначенный_пароль>

б) Перенос на другой сервер с обновлением версии

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


$ gitlab-rake gitlab:backup:create STRATEGY=copy

Архив сохраняется в каталоге, прописанном в файле /var/opt/gitlab/gitlab-rails/etc/gitlab.yml, "по умолчанию" это
/var/opt/gitlab/backups/.
Скопируем файл архива и файл ключей /etc/gitlab/gitlab-secrets.json (без него данные будут недоступны зашифрованные файлы проектов) на новый сервер.
При переносе сервера первоначально надо восстановить ту же версию GitLab, какая стоит на старом сервере: восстановление резервной копии на другой версии невозможно.
Предположим, что у нас установлена версия 8.17.4.
Идём в архив пакетов и ищем там пакет для (в моём примере) версии 8.17.4 для Scientific Linux 7. Здесь указаны команды установки выбранной версии.
Запускаем установку:


$ curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash $ EXTERNAL_URL="http://gitlabnew.mydomain.ru" yum install gitlab-ce-8.17.4-ce.0.el7.x86_64

Первый старт (настройка и запуск):


$ gitlab-ctl reconfigure

Для восстановления копируем файл архива в /var/opt/gitlab/backups/:


$ cd 1512247683_2017_12_02_gitlab_backup.tar /var/opt/gitlab/backups/

Делаем доп.команды:


# останавливаем требуемые сервисы $ gitlab-ctl stop unicorn $ gitlab-ctl stop sidekiq # Проверяем $ gitlab-ctl status

Запускаем непосредственно восстановление:


$ gitlab-rake gitlab:backup:restore BACKUP=1512406478_2017_12_04

, где 1512406478_2017_12_04 - наименование архива без расширения.
Восстанавливаем файл ключей


$ cp gitlab-secrets.json /etc/gitlab/gitlab-secrets.json

Перезапускаем GitLab и проверяем конфигурацию:


$ gitlab-ctl restart $ gitlab-rake gitlab:check SANITIZE=true

Корректировка /etc/gitlab/gitlab.rb (при необходимости) и загрузка измененной конфигурации:


$ gitlab-ctl reconfigure

Пробуем зайти на сервер браузером и проверим работу, зайдя по ссылке: http://gitlabnew.mydomain.ru.
Обновляем сервер PostgreSQL и сам GitLab:


$ gitlab-ctl pg-upgrade $ yum install gitlab-ce

При смене имени сервера меняем имя сервера в конфиге /etc/gitlab/gitlab.rb:


external_url 'http://gitlab2.mydomain.ru/'

и /var/opt/gitlab/nginx/conf/gitlab-http.conf:


server_name gitlab2.mydomain.ru;

Перезапускаем GitLab:


$ gitlab-ctl reconfigure $ gitlab-ctl restart

Для проверки работы почты используем консоль Гита:


# применяем конфигурацию $ gitlab-ctl reconfigure # запускаем консоль и пишем там $ gitlab-rails console Notify.test_email('mymail@mail.ru', 'Message Subject', 'Message Body').deliver_now

Для подключения к PostgreSQL, используемому в GitLab:


$ sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql -h /var/opt/gitlab/postgresql -d gitlabhq_production

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ
Backing up and restoring GitLab
Maintenance commands
Omnibus GitLab documentation
Архив версий GitLab CE
Архив пакетов GitLab CE
Сброс пароля администратора через rails консоль



7. Брокер сообщений RabbitMQ

а) Установка и первичная настройка

Откроем на firewalld необходимые порты:


$ firewall-cmd --permanent --new-service=rabbitmq $ firewall-cmd --permanent --service=rabbitmq --add-port=5672/tcp $ firewall-cmd --permanent --service=rabbitmq --add-port=15672/tcp $ firewall-cmd --permanent --zone=work --add-service=rabbitmq $ firewall-cmd --reload

В документации описаны все порты, используемые RabbitMQ, но здесь мы используем только основные: 5672/tcp - AMQP (собственно основной протокол обмена для RabbitMQ) и 15672/tcp - HTTP (встроенный web-сервер для панели управления).
Перед установкой RabbitMQ необходимо установить Erlang. В документации описывается три варианта установки.
Можно воспользоваться Erlang из репозитория EPEL:


$ yum install erlang

Но актуальные версии RabbitMQ требуют актуальных версий Erlang (для 3.7 потребовался Erlang >= 19.3, которого ещё не было в EPEL), поэтому воспользуемся репозиторием Erlang от проекта RabbitMQ:


$ curl -s https://packagecloud.io/install/repositories/rabbitmq/erlang/script.rpm.sh | sudo bash

И устанавливаем Erlang:


$ yum install erlang

Для установки непосредственно сервера RabbitMQ воспользуемся официальным репозиторием. Установим его согласно официальной инструкции:


$ curl -s https://packagecloud.io/install/repositories/rabbitmq/rabbitmq-server/script.rpm.sh | sudo bash

После установки репозитория сам сервер RabbitMQ устанавливается обычно:


$ yum install rabbitmq-server

Актуальная версия на момент написания инструкции - 3.7.
Для доставки отсроченных (delayed) сообщений установим расширение rabbitmq_delayed_message_exchange по инструкции:
1) скачиваем с официального реестра расширений нужный нам (для версии RabbitMQ 3.7):


$ mkdir /root/_Soft/RabbitMQ $ wget https://dl.bintray.com/rabbitmq/community-plugins/3.7.x/rabbitmq_delayed_message_exchange/rabbitmq_delayed_message_exchange-20171201-3.7.x.zip \ -O /root/_Soft/RabbitMQ/rabbitmq_delayed_message_exchange-20171201-3.7.x.zip

2) создаём каталог для дополнительных расширений и распаковываем туда скачанный архив:


$ mkdir /usr/lib/rabbitmq/plugins $ unzip -x /root/_Soft/RabbitMQ/rabbitmq_delayed_message_exchange-20171201-3.7.x.zip -d /usr/lib/rabbitmq/plugins

Запускаем наш сервер:


$ systemctl start rabbitmq-server.service # если всё нормально - в автозапуск $ systemctl enable rabbitmq-server.service

Активируем дополнительные расширения (plugins):


$ rabbitmq-plugins enable rabbitmq_management $ rabbitmq-plugins enable rabbitmq_delayed_message_exchange # проверяем, загружены ли указанные расширения $ rabbitmq-plugins list -E # если передумали, то можем отключить расширение $ rabbitmq-plugins disable rabbitmq_delayed_message_exchange

Добавляем виртуальный узел:


$ rabbitmqctl add_vhost Queue.MyCompany

Управление пользователями:


# Создание учётной записи администратора $ rabbitmqctl add_user admin ********** $ rabbitmqctl set_user_tags admin administrator $ rabbitmqctl set_permissions -p Queue.MyCompany admin ".*" ".*" ".*" # Удаление гостевой учётной записи $ rabbitmqctl delete_user guest

Всё, сервер можно вводить в работу.



б) Сборка кластера

Предположим, что у нас три сервера (rmq1.domain.local (192.168.100.101), rmq2.domain.local (192.168.100.102), rmq3.domain.local) (192.168.100.103), которые мы хотим объединить в один кластер.
Настроенным, как описано выше, необходим только один сервер, который будем master. В данному случае это rmq1.domain.local.
Пропишем необходимые системные переменные в файл /etc/sysctl.conf:


net.ipv4.ip_forward = 1 net.ipv4.ip_nonlocal_bind = 1

Для применения этим параметров надо перезагрузить сервер или выполнить команду


$ sysctl -p

Надёжность работы кластера RabbitMQ (собственно это так же важно для любых кластеров практически любого ПО) зависит от правильности настройки и работы серверов DNS. Но для перестраховки внесём список наших серверов в файлы /etc/hosts всех трёх серверов:


192.168.100.101 rmq1 rmq1.domain.local 192.168.100.102 rmq2 rmq2.domain.local 192.168.100.103 rmq3 rmq3.domain.local

Отключим (временно) SELinux на всех серверах:


$ setenforce 0

Открываем порты, необходимые для работы кластера (4369/tcp, 25672/tcp):


# описывает сервис rabbitmq-cluster $ firewall-cmd --permanent --new-service=rabbitmq-cluster $ firewall-cmd --permanent --service=rabbitmq-cluster --add-port=4369/tcp $ firewall-cmd --permanent --service=rabbitmq-cluster --add-port=25672/tcp # ВАРИАНТЫ ДОСТУПА # простой: всё всем $ firewall-cmd --permanent --zone=work --add-service=rabbitmq-cluster # сложнее: только между узлами кластера # указано для узла 192.168.100.101, для других меняем IP на соответствующие $ firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.100.102/32" service name="rabbitmq-cluster" accept' $ firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.100.103/32" service name="rabbitmq-cluster" accept' # перезагружаем конфигурацию firewalld $ firewall-cmd --reload

Копируем с master файл /var/lib/rabbitmq/.erlang.cookie. Копируем его на другие серверы будущего кластера (серверы slave).
Создание кластера проводится выполнением следующих команд на каждом slave (указывать надо короткое имя сервера (без домена), иначе кластер не соберётся):


$ rabbitmqctl stop_app # ПОДКЛЮЧЕНИЕ # если сообщения будут храниться на диске (по умолчанию) $ rabbitmqctl join_cluster rabbit@rmq1 # если сообщения будут храниться в памяти $ rabbitmqctl join_cluster --ram rabbit@rmq1 $ rabbitmqctl start_app

Тип хранения сообщений может быть изменён командой


$ rabbitmqctl change_cluster_node_type disc | ram

В случае:
ram сервер будет быстрее обрабатывать сообщения, но при это теряется надёжность: в случае нештатных ситуаций сообщения могут быть утеряны;
disk сервер обрабатывает сообщения медленней, но риск их утери снижается.
Это же делается указанием в файле конфигурации:


# для rmq2.domain.local {cluster_nodes, {["rabbit@rmq1", "rabbit@rmq2"], disc}} # для rmq3.domain.local {cluster_nodes, {["rabbit@rmq1", "rabbit@rmq3"], disc}}

При необходимости даём имя кластера:


$ rabbitmqctl set_cluster_name rmq_clu

По окончании построения кластера смотрим его статус:


$ rabbitmqctl cluster_status

Если всё нормально, то будет примерно такой ответ:


# rabbitmqctl cluster_status Cluster status of node rabbit@rmq1 ... [{nodes,[{disc,['rabbit@rmq1','rabbit@rmq2','rabbit@rmq3']}]}, {running_nodes,['rabbit@rmq2','rabbit@rmq1','rabbit@rmq3']}, {cluster_name,<<"rmq_clu">>}, {partitions,[]}, {alarms,[{'rabbit@rmq2',[]},{'rabbit@rmq1',[]},{'rabbit@rmq3',[]}]}]

В случае проблем необходимо изучать журналы в каталоге /var/log/rabbitmq/. Например, частая проблема в мире Erlang — "залипший" демон epmd. Если команда:


$ epmd -names

сообщает, что имя rabbitmq зарегистрировано, а точно известно, что сервис остановлен, epmd нужно снять:


$ killall -9 epmd

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


# для виртуального узла (vHost) корня - / $ rabbitmqctl set_policy ha-all "" '{"ha-mode":"all","ha-sync-mode":"automatic"}' # vHost - HA.Queue $ rabbitmqctl set_policy -p HA.Queue ha-all "" '{"ha-mode":"all","ha-sync-mode":"automatic"}' # vHost - / и все очереди ha.* $ rabbitmqctl set_policy ha-all "^ha\." '{"ha-mode":"all"}'

Теперь все сообщения в указанных очередях будут синхронизироваться, т.е. копироваться на все серверы кластера (в память или на диск - в зависимости от узла). Для клиентов сообщения будут доступны только когда эти сообщения будут скопированы на все серверы.
По основным настройкам:
ha-mode: all - все данные храним на всех нодах, снижается скорость обработки сообщений, но увеличивается доступность и сохранность
ha-sync-mode: automatic - синхронизируем данные на всех нодах
queue-mode: lazy - снижаем потребление оперативной памяти, сразу сохраняя все на диск в момент получения сообщения. Если не хотим сохранять сразу, то устанавливаем в конфигах параметр (vm_memory_high_watermark_paging_ratio, 0.5), что означает сохранять на диск при пороге сообщений в 50%
Дополнительные настройки, которые могут быть необходимыми в момент нагрузок:
vm_memory_high_watermark, 0.8 - указываем, что займем только 90% оперативной памяти. Исхожу из того, что Erlang плохо определяет оперативную память и 10% свободного использования будет своего рода буффером
cluster_partition_handling, pause_minority - рекомендация из документации, которая указывает кластеру из 3х нод чтобы сам восстановился
disk_free_limit, "1024MB" - указываем, что как только на диске останется всего 1Гб свободного места, публикация сообщений будет остановлена, доступно будет только потребление сообщений
TTL - нужно решить после анализа каждой очереди, может достаточно и по умолчанию
Кластер RabbitMQ не подразумевает единый адрес доступа, как на кластерах Windows: приложение само должно определять, что узел недоступен и переключаться на другой.
Так же возможно использование дополнительных программ, которые будут обеспечивать переключение единого кластерного IP адреса при проблемах с активным узлом. В данном случае используем keepalived:


$ yum install keepalived

keepalived работает по протоколу VRRPv2, но умеет не только обслуживать кластерный адрес, но и осуществлять балансировку.
В данном случае рассматривается только обслуживание кластерного IP адреса.
Файл конфигурации /etc/keepalived/keepalived.conf для узла master:


### Configuration File for keepalived vrrp_script chk_rabbit-server { script "/etc/keepalived/rmq_test.sh" interval 2 fall 3 rise 3 timeout 2 weight 20 # меняется } global_defs { notification_email { admin@mydomain.ru devops@mydomain.ru } notification_email_from rabbitmq_ha@mydomain.ru script_user keepalived_script enable_script_security smtp_server mail.mydomain.ru smtp_connect_timeout 30 lvs_sync_daemon eth0 router_id LVS_RMQ1 # меняется vrrp_skip_check_adv_addr vrrp_garp_interval 0 vrrp_gna_interval 0 } vrrp_instance VI_1 { debug 4 state MASTER # меняется на BACKUP interface eth0 virtual_router_id 130 priority 33 # меняется advert_int 1 unicast_src_ip 192.168.100.101 # меняется unicast_peer { 192.168.100.102 # меняется 192.168.100.103 # меняется } authentication { auth_type PASS auth_pass P@Ssw0rD } virtual_ipaddress { 192.168.100.100 } track_script { chk_rabbit-server } smtp_alert }

Для узлов slave меняются помеченные параметры на актуальные для данного сервера.
Следует учитывать, что приоритет сервера выбирается из веса узла, определяемого суммой 'priority + weight' (weight прибавляется, когда контролируемый сервис (в данном случае RabbitMQ) работает нормально). Можно выставить неверные пары и долго разбираться, почему не работает передача кластерного IP адреса при сбое сервиса (сам столкнулся). Поэтому прилагаю пары параметров для 3-х серверного варианта:


Узел weight priority rmq1.domain.local 20 33 rmq2.domain.local 15 30 rmq3.domain.local 10 25

Создадим пользователя, от которого будет запускаться скрипт проверки состояния RabbitMQ (может появиться пара строк с предупреждениями, но на них не стоит обращать внимание):


$ useradd -d /dev/null -s /bin/false keepalived_script

Скрипт проверки работоспособности сервера чем отправку/получение сообщения:


#!/bin/bash RMQ_HOSTNAME=$(hostname | sed -e s/\.mydomain\.ru//) RMQ_LOCALNODE=rabbit@${RMQ_HOSTNAME} RMQ_MESSAGE=${RMQ_HOSTNAME} RMQ_USER=UserName RMQ_PASS=P@s$w0rD RMQ_VHOST=HostTest RMQ_PAYLOADFILE=/tmp/payload_file.messages if [[ ("$1" == "install") ]] then rabbitmqadmin --username="${RMQ_USER}" --password="${RMQ_PASS}" declare queue --vhost="${RMQ_VHOST}" \ name="${RMQ_HOSTNAME}" durable="true" auto_delete="true" node="${RMQ_LOCALNODE}" \ arguments='{ "x-message-ttl" : 1500 }' exit 0 else RMQ_STATUS_SEND=$(rabbitmqadmin --username="${RMQ_USER}" --password="${RMQ_PASS}" --vhost="HostTest" \ publish exchange=amq.default routing_key="${RMQ_HOSTNAME}" payload="${RMQ_MESSAGE}") rm -fr ${RMQ_PAYLOADFILE} touch ${RMQ_PAYLOADFILE} rabbitmqadmin --username="${RMQ_USER}" --password="${RMQ_PASS}" --vhost="${RMQ_VHOST}" \ get queue="${RMQ_HOSTNAME}" count=1 payload_file="${RMQ_PAYLOADFILE}" > /dev/null 2>&1 RMQ_STATUS_GET=$(cat ${RMQ_PAYLOADFILE}) rm -fr ${RMQ_PAYLOADFILE} if [[ ("${RMQ_STATUS_SEND}" == "Message published") && ("${RMQ_STATUS_GET}" == "${RMQ_MESSAGE}") ]] then exit 0 else exit 1 fi fi

Для работы скрипта необходима pythton-утилита rabbitmqadmin. Скачиваем и "ставим" её:


$ wget https://raw.githubusercontent.com/rabbitmq/rabbitmq-management/v3.7.7/bin/rabbitmqadmin -O /etc/keepalived/rabbitmqadmin $ chmod +x /etc/keepalived/rabbitmqadmin $ ln -s /etc/keepalived/rabbitmqadmin /usr/bin/rabbitmqadmin

Перед запуском надо создать тестовые очереди, отсылая и получая сообщения в которые скрипт будет определят функционирование сервера (на каждом узле):


$ ./rmq_test.sh-new install

Включим SELinux и настроим его для работы нашего скрипта и keepalived:


$ setenforce 1 $ cat /var/log/audit/audit.log | grep denied | grep keepalived | audit2allow -M keepalived_rmq_test_script $ semodule -i keepalived_rmq_test_script.pp

У меня после второй команды получился файл keepalived_rmq_test_script с таким содержимым:


module keepalived_rmq_test_script 1.0; require { type user_tmp_t; type tmp_t; type systemd_systemctl_exec_t; type gconf_home_t; type hostname_exec_t; type keepalived_t; type amqp_port_t; class tcp_socket name_connect; class dir { add_name remove_name search write }; class file { create execute execute_no_trans getattr open read unlink write }; } #============= keepalived_t ============== #!!!! This avc is allowed in the current policy allow keepalived_t amqp_port_t:tcp_socket name_connect; allow keepalived_t gconf_home_t:dir search; allow keepalived_t hostname_exec_t:file getattr; allow keepalived_t hostname_exec_t:file { execute execute_no_trans open read }; allow keepalived_t systemd_systemctl_exec_t:file getattr; allow keepalived_t tmp_t:dir write; allow keepalived_t tmp_t:dir { add_name remove_name }; allow keepalived_t tmp_t:file { create unlink write }; allow keepalived_t user_tmp_t:file unlink;

Этот файл можно скомпилировать в PP файл командами:


$ checkmodule -M -m -o keepalived_rmq_test_script.mod keepalived_rmq_test_script.te $ semodule_package -o keepalived_rmq_test_script.pp -m keepalived_rmq_test_script.mod

Для запуска скрипта проверки работоспособности RabbitMQ в конфигурационном файле был указан пользователь keepalived_script, которому надо теперь указать разрешения в SELInux-е. Для этого создадим файл keepalived_user_scipt.te:


module keepalived_user_scipt 1.0; require { type keepalived_t; class capability { setgid setuid }; } #============= keepalived_t ============== allow keepalived_t self:capability { setgid setuid };

Его так же скомпилируем и применим:


$ checkmodule -M -m -o keepalived_user_scipt.mod keepalived_user_scipt.te $ semodule_package -o keepalived_user_scipt.pp -m keepalived_user_scipt.mod

Теперь запускаем сервис keepalived:


$ systemctl start keepalived $ systemctl enable keepalived

Ну и смотрим, как работает кластер (останавливаем/запускаем RabbitMQ, keepalived, в том числе и под нагрузкой). И не забываем смотреть логи:
- keepalived пишет в /var/log/messages;
- на случай проблем с SELinux "грепим" по denied лог /var/log/audit/audit.log.
Так же можно посмотреть сетевой траффик, которым обмениваются демоны keepalived:


$ tcpdump -i eth0 -n -nn -ttt '((src host 192.168.100.101 and dst host 192.168.100.102) or (src host 192.168.100.102 and dst host 192.168.100.101)) and not (ip proto \tcp)'

Должны периодически появляться пакеты вида:


00:00:00.922039 IP 192.168.100.101 > 192.168.100.102: VRRPv2, Advertisement, vrid 32, prio 110, authtype simple, intvl 1s, length 20 00:00:00.000478 IP 192.168.100.102 > 192.168.100.101: VRRPv2, Advertisement, vrid 33, prio 100, authtype simple, intvl 1s, length 20

Дополнительная информация:
1) Highly Available кластер RabbitMQ;
2) Highly Available (Mirrored) Queues;
3) Cluster Formation and Peer Discovery;
4) Установка и настройка RabbitMQ-кластера в AWS.



в) Балансировка нагрузки в кластере

Для балансировки нагрузки воспользуемся соответствующим функционалом уже используемого keepalived, добавил в конфигурационный файл /etc/keepalived/keepalived.conf всех трёх узлов дополнительный блок:


virtual_server fwmark 1 { delay_loop 5 lb_algo wrr lb_kind DR protocol TCP real_server 192.168.100.101 5672 { weight 100 inhibit_on_failure TCP_CHECK { connect_port 5672 connect_timeout 3 } } real_server 192.168.100.102 5672 { weight 100 inhibit_on_failure TCP_CHECK { connect_port 5672 connect_timeout 3 } } real_server 192.168.100.102 5672 { weight 100 inhibit_on_failure TCP_CHECK { connect_port 5672 connect_timeout 3 } } }

И перезапустим keeralived:


$ systemctl restart keepalived

Смотреть статистику можно установленной утилитой ipvsadm:


$ ipvsadm -L --stats

Дополнительная информация: Keepalived configuration synopsis.



г) Настройка мониторинга в Zabbix

Считаем, что zabbix-agent на данном сервере уже установлен и настроен. Доустановим необходимые компоненты Zabbix:


$ yum install zabbix-get zabbix-sender

Добавление пользователя для мониторинга в Zabbix:


$ rabbitmqctl add_user zabbix <пароль> $ rabbitmqctl set_user_tags zabbix monitoring $ rabbitmqctl set_permissions -p / zabbix '^aliveness-test$' '^amq\.default$' '^aliveness-test$' $ rabbitmqctl set_permissions -p Queue.MyCompany zabbix '^aliveness-test$' '^amq\.default$' '^aliveness-test$'

Скачиваем с GitHub (jasonmcintosh/rabbitmq-zabbix) скрипты и конфигурационный файл для агента Zabbix.
Конфигурационный файл zabbix-rabbitmq.conf копируем в каталог конфигурации Zabbix-агента:


$ cp ./rabbitmq-zabbix/zabbix_agentd.d/zabbix-rabbitmq.conf /etc/zabbix/zabbix_agentd.d/rabbitmq.conf

Каталог со скриптами так же копируем с каталог конфигурации агента:


$ cp -r ./rabbitmq-zabbix/scripts/ /etc/zabbix

К скриптам добавляем файл /etc/zabbix/scripts/rabbitmq/.rab.auth с таким содержанием (указываем параметры ранее добавленного пользователя zabbix):


USERNAME=zabbix PASSWORD=<пароль> CONF=/etc/zabbix/zabbix_agentd.conf LOGLEVEL=WARNING LOGFILE=/var/log/zabbix/rabbitmq_zabbix.log PORT=15672

В самом Zabbix-е импортируем шаблон ./rabbitmq-zabbix/rabbitmq.template.xml, добавляем его к наблюдаемому узлу и в макросах узла выставляем пороги срабатывания, меняя заданные в шаблоне на необходимые.
При необходимости отладки в файле /etc/zabbix/scripts/rabbitmq/.rab.auth выставляем меняем параметр LOGLEVEL на:


LOGLEVEL=DEBUG

Найденные ещё варианты мониторинга: от thecamels, от sepich.



д) Дополнительная информация

1) Изменение пароля пользователя.


$ rabbitmqctl change_password zabbix <новый_пароль>

2) Просмотр всех конфигурационных переменных


$ rabbitmqctl environment

3) Изменение конфигурационных параметров через файл конфигурации /etc/rabbitmq/rabbitmq.config.
Например, отключим логи и поднимем ограничение на поток сообщений до 1000 сообщений/сек.


[ {rabbit, [ {log_levels, [{channel, none}, {connection, none}, {federation, none}, {mirroring, none}]} ]}, %% {rabbit, [{log_levels, [{channel, error}, {connection, error}]}]} %% {rabbit, [{log_levels, [{connection, error}]}]} {sasl, [ {sasl_error_logger, false} ]}, {lager, [ {error_logger_hwm, 1000}, %% {handlers, [{lager_file_backend, [{level, info}]}]}, {handlers, [{lager_file_backend, [{level, warning}]}]}, %% {rabbit_handlers, [{lager_file_backend, [{level, info}]}]} {rabbit_handlers, [{lager_file_backend, [{level, warning}]}]} ]} ].

Настройки по журналированию сообщений.
4) Низкоуровневые параметры.
По умолчанию в RabbitMQ очень небольшие значения по количеству доступных файловых дескрипторов и сокетов. Поэтому, если система  будет достаточно высоконагруженной, то может стать причиной проблем.
Для увеличения кол-ва доступных файловых дескрипторов (и сокетов: они идут определённым процентом от кол-ва файловых) необходимо изменить systemd-юнит:


$ systemctl edit rabbitmq-server

И внести туда наше новое значение:


[Service] LimitNOFILE=16384

Эти изменения сохранятся в файле /etc/systemd/system/rabbitmq-server.service.d/override.conf.



8. Apache Tomcat

а) Установка

Т.к. Apache Tomcat является контейнером сервлетов Java приложений, то ему необходима поддержка Java. Для данного примера будем ставить Tomcat 8.5 с Java 1.8 и Tomcat 9.0 с Java 11. Ставим обе версии:


## OpenJDK 1.8 # на CentOS 7 yum install java-1.8.0-openjdk-devel # на CentOS 8 dnf install java-1.8.0-openjdk-devel ## OpenJDK 11 # на CentOS 7 yum install java-11-openjdk-devel # на CentOS 8 dnf install java-11-openjdk-devel

Конфигурирование делаем исходя из осознания, что у нас может быть запущено несколько копий Tomcat (в данном примере - 2). Для обозначения каталога установки любой копии Tomcat будет использоваться <TMC>.
Поэтому создаём групповой каталог:


$ mkdir /opt/_Tomcat

Создаём пользователя tomcat и группу tomcat:


$ sudo groupadd tomcat $ sudo useradd -M -s /bin/nologin -g tomcat -d /opt/_Tomcat tomcat

В репозиториях CentOS находится устаревшая версия Tomcat, поэтому скачиваем архив актуальную версию (для примера: в ветке 8.5) с сайта проекта и распаковываем его в каталог /opt/tomcat:


$ wget http://apache.mirrors.ionfish.org/tomcat/tomcat-8/v8.5.54/bin/apache-tomcat-8.5.54.tar.gz $ wget http://apache.mirrors.ionfish.org/tomcat/tomcat-9/v9.0.34/bin/apache-tomcat-9.0.34.tar.gz $ mkdir /opt/_Tomcat/application1 $ mkdir /opt/_Tomcat/application2 $ tar xvf apache-tomcat-8*tar.gz -C /opt/_Tomcat/application1 --strip-components=1 $ tar xvf apache-tomcat-9*tar.gz -C /opt/_Tomcat/application2 --strip-components=1

Установим права доступа:


$ cd /opt/_Tomcat $ chgrp -R tomcat /opt/_Tomcat $ cd /opt/_Tomcat/application1 $ chmod -R g+r conf $ chmod g+x conf $ chown -R tomcat webapps/ work/ temp/ $ cd /opt/_Tomcat/application2 $ chmod -R g+r conf $ chmod g+x conf $ chown -R tomcat webapps/ work/ temp/

Создаём каталоги для журналов:


$ mkdir -p /var/log/tomcat/application1/archiv $ mkdir -p /var/log/tomcat/application2/archiv $ rmdir /opt/_Tomcat/application1/logs $ rmdir /opt/_Tomcat/application2/logs $ ln -s /var/log/tomcat /logs $ ln -s /var/log/tomcat/application1 /opt/_Tomcat/application1/logs $ ln -s /var/log/tomcat/application2 /opt/_Tomcat/application2/logs $ chmod -R 770 /var/log/tomcat $ chown -R tomcat:tomcat /var/log/tomcat $ restorecon -Rv /var/log/tomcat

Создаём скрипт /root/_Scripts/arch_log_date-tomcat.sh для архивации журналов (архивирует все журналы за определённую дату и сохраняет архивы в каталоге <TMC>/logs/archiv в течении недели):


mkdir -p /root/_Scripts/ touch /root/_Scripts/arch_log_date-tomcat.sh

И приводим его к виду:


#!/bin/bash mkdir -p $1/archiv find $1/*$(date --date '-1 day' +%Y-%m-%d)*.* -exec tar -r -f $1/archiv/$(date --date '-1 day' +%Y%m%d).tar --remove-files {} \; && find $1/archiv/*.tar -exec gzip {} \; && find $1/archiv/*. tar.gz -mtime +5 -delete chown $2:$3 $1/archiv/*.tar.gz chmod 640 $1/archiv/*.tar.gz

Для logrotate создаём файл-конфигурацию ротации основного файла журнала Tomcat-а (при активной работе с приложениями в Tomcat он увеличивается очень быстро) /etc/logrotate.d/tomcat следующего содержания:


/var/log/tomcat/application1/catalina.out /var/log/tomcat/application2/catalina.out { rotate 10 size 200M compress notifempty missingok copytruncate su tomcat tomcat } EOF

В файл конфигурации "крона" /etc/crontab добавляем строки:


0 */12 * * * root logrotate --force /etc/logrotate.d/catalina > /dev/null 2>&1 # для Application1 0 1 * * * root /root/_Scripts/arch_log_date-tomcat.sh /var/log/tomcat/application1 tomcat tomcat > /dev/null 2>&1 # для Application2 0 1 * * * root /root/_Scripts/arch_log_date-tomcat.sh /var/log/tomcat/application2 tomcat tomcat > /dev/null 2>&1

По умолчанию в конфигурационных файлах Tomcat в качестве основного порта доступа указан порт 8080. Для одного приложения (Application1) оставляем, как есть, а для Application2 меняем на другие. Для этого в файле конфигурации сервера Tomcat /opt/_Tomcat/application2/conf/server.xml меняем все указанные порты на новые, прибавив 1 к указанному номеру порта (в комментарии - со старым параметром):


# <Server port="8005" <Server port="8006" # <Connector port="8080" protocol="HTTP/1.1" # connectionTimeout="20000" # redirectPort="8443" /> <Connector port="8081" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8444" /> ### В последних версиях Tomcat нижеследующие строки отсутствуют # <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> <Connector port="8010" protocol="AJP/1.3" redirectPort="8444" />

При необходимости настройки работы по HTTPS необходимо добавить дополнительные настройки (для Application1 и Application2 различия только в номере порта):


# для Application1 <Connector port="8443" SSLEnabled="true" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="200" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="/opt/_Tomcat/application1/conf/ssl/keystore.p12" keystorePass="**********" keystoreType="PKCS12" keyAlias="application1"/> # для Application2 <Connector port="8444" SSLEnabled="true" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="200" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="/opt/_Tomcat/application2/conf/ssl/keystore.p12" keystorePass="**********" keystoreType="PKCS12" keyAlias="application2"/>

И создадим сами ключи:


# для Application1 mkdir -p /opt/_Tomcat/application1/conf/ssl keytool -genkeypair -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore keystore.p12 -validity 3650 -alias application1 -file /opt/_Tomcat/application1/conf/ssl/keystore.p12 # для Application2 mkdir -p /opt/_Tomcat/application2/conf/ssl keytool -genkeypair -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore keystore.p12 -validity 3650 -alias application2 -file /opt/_Tomcat/application2/conf/ssl/keystore.p12

Создадим файлы systemd-юнитов для запуска Tomcat-ов в качестве сервиса:
1) для Application1 /etc/systemd/system/tomcat-application1.service:


# Systemd unit file for Tomcat - Application1 [Unit] Description=Apache Tomcat Web Application Container After=syslog.target network.target [Service] Type=forking ###=-- Каталог установки JDK ### OpenJDK - JRE # Environment='JAVA_HOME=/usr/lib/jvm/jre' Environment='JAVA_HOME=/usr/lib/jvm/java-1.8.0' ### OracleJDK - JRE # Environment='JAVA_HOME=/usr/java/latest/jre' Environment=CATALINA_PID=/opt/_Tomcat/application1/temp/tomcat.pid Environment=CATALINA_HOME=/opt/_Tomcat/application1 Environment=CATALINA_BASE=/opt/_Tomcat/application1 Environment='CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC' Environment='JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom' ExecStart=/opt/_Tomcat/application1/bin/startup.sh ExecStop=/bin/kill -15 $MAINPID User=tomcat Group=tomcat UMask=0007 RestartSec=10 Restart=always [Install] WantedBy=multi-user.target

2) для Application2 /etc/systemd/system/tomcat-application2.service:


# Systemd unit file for Tomcat - Application1 [Unit] Description=Apache Tomcat Web Application Container After=syslog.target network.target [Service] Type=forking ###=-- Каталог установки JDK ### OpenJDK - JRE # Environment='JAVA_HOME=/usr/lib/jvm/jre' Environment='JAVA_HOME=/usr/lib/jvm/java-11' ### OracleJDK - JRE # Environment='JAVA_HOME=/usr/java/latest/jre' Environment=CATALINA_PID=/opt/_Tomcat/application2/temp/tomcat.pid Environment=CATALINA_HOME=/opt/_Tomcat/application2 Environment=CATALINA_BASE=/opt/_Tomcat/application2 Environment='CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC' Environment='JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom' ExecStart=/opt/_Tomcat/application2/bin/startup.sh ExecStop=/bin/kill -15 $MAINPID User=tomcat Group=tomcat UMask=0007 RestartSec=10 Restart=always [Install] WantedBy=multi-user.target

Укажем systemd, чтобы он прочитал новые юниты:


$ systemctl daemon-reload

Запускаем, проверяем, ставим в автозапуск:


# для Application1 $ sudo systemctl enable tomcat-application1.service $ sudo systemctl start tomcat-application1.service $ sudo systemctl status tomcat-application1.service # для Application2 $ sudo systemctl enable tomcat-application2.service $ sudo systemctl start tomcat-application2.service $ sudo systemctl status tomcat-application2.service

Если запуск Tomcat-ов прошёл успешно, можно разворачивать приложение.
При необходимости передавать некоторые параметры в приложение необходимо их прописывать в файл: <TMC>/conf/catalina.properties в форме:


параметр=значение

б) Настройка интерфейса управления

Для предоставления доступа к консоли управления приложениями "Manager App" (для управления приложениями, в том числе и деплоя) надо описать доступ в файлах контекста обоих приложений <TMC>/webapps/manager/META-INF/context.xml таким образом:


# "по умолчанию" разрешено только локально allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" /> # вариант "разрешить всем" allow="^.*$" /> # разрешить только локальные подключения и из сетей # 192.168.0.0/16, 10.0.0.0/8, 172.0.0.0/8 и запретить для адреса 172.21.3.5 allow="127\.0\.0\.\d+|10\.255\.253\.\d+|192\.168\.d+\.\d+|10\.d+\.d+\.\d+|172\.\d+\.\d+\.\d+" deny="172\.21\.3\.5" />

Аналогичным образом настраивается доступ к "Host Manager" и другим (если они нужны).
После изменения - перезапускаем Tomcat-ы.


# для Application1 $ sudo systemctl restart tomcat-application1.service # для Application2 $ sudo systemctl restart tomcat-application2.service

Открытие доступа к порту:
а) на межсетевом экране firewalld:


# открываем доступ к контейнерам и интерфейсу управления для указанной сети # добавляем требуемые порты 8080 и 8081 $ firewall-cmd --permanent --new-service=tomcat-http $ firewall-cmd --permanent --service=tomcat-http --add-port=8080/tcp $ firewall-cmd --permanent --service=tomcat-http --add-port=8081/tcp $ firewall-cmd --permanent --add-service=tomcat-http $ firewall-cmd --reload ### Далее - примеры (!) для настройки более "тонкой" настройки доступа: $ firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.1.0/24" service name="http" accept' # открываем полный доступ с сервера мониторинга Zabbix $ firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.19.34/32" accept'

б) в SELinux:
Проверить, что SELinux активен:


$ sestatus

Если в ответе на эту команду в строке "SELinux status:" будет enabled - проверяем порты:


# Посмотреть, открыты ли порты наших серверов Tomcat $ semanage port -l | grep -E "8080|8081" # если какого либо из требуемых портов нет - добавить в этот список (на примере 8081) $ semanage port -a -t http_port_t -p tcp 8081

При случае, когда утилита semanage не установлена на сервере - установим её (и повторим затем предыдущие команды):


$ yum install policycoreutils-python

в) Дополнительные действия

Если на целевом сервере используется только одна установка JDK, то можно указать переменные JAVA_HOME, JRE_HOME, PATH глобально. Например, для OpenJDK:


# создаём файл в каталоге профилей cat > /etc/profile.d/java.sh <<EOF [ -n "${BASH_VERSION}${KSH_VERSION}${ZSH_VERSION}" ] || return 0 JAVA_HOME=/usr/lib/jvm/java JRE_HOME=/usr/lib/jvm/jre PATH=${PATH}:/usr/lib/jvm/java/bin:/usr/lib/jvm/jre/bin EOF # делаем его исполняемым chmod +x /etc/profile.d/java.sh

Параметры применятся при перезагрузке.