Lnav представляет собой расширенный просмотрщик файлов журналов (log) для терминала Linux. Открывает архивные логи, отображает содержимое в режиме реального времени, возможно открыть сразу несколько логов и увидеть их наложение на одном экране.
Введение
В работе постоянно требуется просматривать логи для выявления ошибок и оптимальной настройки как системы так и разных служб. На практике я перепробовал разные утилиты, но данная программа подходит идеально для разных случаев. Устанавливается просто и не требует никаких дополнительных настроек.
Основные преимущества утилиты:
Устанавливается просто и не требует настроек,
Показывает содержание в режиме реального времени,
Позволяет открывать архивные файлы,
Производит подсветку синтаксиса,
Можно открывать несколько логов одновременно.
Установка Lnav
Утилита присутствует во всех популярных операционных системах Linux.
Более подробно о программе и работе с ней можно посмотреть на официальном сайте Lnav.
Установка из репозитория:
= Семейство Debian =
apt install lnav
= Семейство RedHat =
dnf install lnav
Работа с Lnav
В сети существует Документация по Lnav на русском языке в котором все хорошо рассказано.
Lnav понимает наиболее популярные форматов логов, таких как access логи веб сервера, syslog, dpkg, strace и другие. Программа автоматически подсвечивает, позволяет быстро делать какие-то выборки. Например, посмотреть все ошибки в нужном логе, показать по ним статистику, вывести информацию по какой-то службе и т.д. и т. п.
В Lnav есть возможность открыть сразу несколько логов и увидеть их наложение на одном экране. Это удобно, когда надо что-то расследовать.
Открываем сразу два лога такой командой:
# В случае если находимся в нужной папке
/var/www/sevo44.ru/log # lnav sevo44.ru-access.log sevo44.ru-error.log
# С указанием полного пути
lnav /var/www/sevo44.ru/log/sevo44.ru-access.log /var/www/sevo44.ru/log/sevo44.ru-error.log
Утилита выстроит строки обоих логов в порядке времени событий.
Заключение
Конечно для более профессионального подхода в изучении логов лучше использовать такое решение как Elastic Stack, но пока его нет или не подключили новый ресурс использование утилиты Lnav лучшее решение.
Кроме того не надо путать мониторинг логов и мониторинг параметров системы это совсем разные вещи. Например я лично для мониторинга разных параметров системы активно и давно использую систему Zabbix.
Рано или поздно всегда приходиться делать изменение размера диска или раздела Linux. Варианты как это сделать существуют разные и все зависит от конкретного случая. Постарался найти вариант который подходит для разных случаев.
Введение
Рано или поздно всем необходимо произвести изменение размера диска, раздела, или вообще перестроить разбивку диска по новому.
Вариантов как это сделать множество, но мне кажется я нашел идеальный и 100% рабочий вариант.
Основной принцип состоит из следующих моментов:
Подключаем дополнительный диск;
Загружаем систему с Live-образа;
Переносим информацию на дополнительный диск;
Создаем, изменяем разделы на требуемом диске;
Возвращаем данные в случае форматирования;
Обновляем загрузчик системы и вносим правки в файл системы отвечающий за подключение разделов диска в систему.
Это очень грубая общая схема не отражающая всех нюансов, но дающая понять суть процесса.
В моем случае необходимо было поменять размер диска с преобразованием системы XFS в EXT4 на виртуальной машине работающей в Proxmox.
Меня лично необходимость уменьшить раздел возникла по причине того что в системе Proxmox появился диск SSD, но вот перенести туда нужную машину я не мог по причине большого размера диска а не реально используемого пространства.
Подготовка
Обязательно перед выполнением работ сделайте резервные копии виртуальных машин или как минимум данных с них!
Все действия необходимо выполнять только на отключенных разделах.
Забегая вперед скажу, что для уменьшения размера диска мы будем использовать возможности типа файлов raw и для этого в системе Proxmox диски должны находится в файловом варианте.
В моем случае делались изменения размеров на корневом разделе а значит необходимо запустить систему с Live-образа. Для этих целей у меня сделана собственная сборка дистрибутива Calculate Linux где установлены все необходимые мне утилиты. Можно использовать любой удобный вам Live-образ системы Linux.
Перед началом работ выполните команду которая покажет все реально смонтированные диски в работающей системе:
Сохраните эти данные, так как в последствии нам с ними будет проще работать.
Загружаем систему используя Live-образ.
Работать в консоли самого Proxmox не удобно, так как нет возможности копировать команды. Запускаю ssh сервер командой:
/etc/init.d/sshd start
Подключаюсь по ssh используя данные авторизации live-образа.
Все подготовительные действия сделаны и переходим к непосредственной работе с разделами диска.
В примере имеется ввиду что раздел /boot выведен на отдельный раздел и мы его не трогаем. Всегда при создании выношу раздел boot на отдельный раздел и не раз эта схема упрощала мне жизнь при работе или проблемах с диском.
Изменение размера диска без форматирования
В случае простого изменения размеров у разделов все просто.
К сожалению раздел XFS уменьшить нельзя а увеличить можно.
Запускаем программу Gparted и выполняем необходимые действия с имеющимися разделами. Уменьшаем, перераспределяем или отключаем какой то раздел и переносим в корень. Например, в моем случае раздел /var/sevo44 находился на отдельном разделе а мне захотелось перенести его в корневой раздел.
Самое главное это перед тем как удалять раздел и переносить его в общий не забудьте сохранить данные с него.
Если выполнялись действия только по изменению размера имеющихся разделов делать больше ничего не надо. После перезагрузки система успешно запустится с новым размером разделов.
Изменение размера диска с форматированием
В моем случае файловая система была XFS и для уменьшения этого раздела мне необходимо было его переформатировать.
Определяем имеющиеся диски в системе выполнив команду:
fdisk -l
= часть вывода команды с пояснениями =
Диск /dev/sda: 100 GiB, 107374182400 байт, 209715200 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт
Тип метки диска: dos
Идентификатор диска: 0x85300bf3
Устр-во Загрузочный начало Конец Секторы Размер Идентификатор Тип
/dev/sda1 * 2048 2099199 2097152 1G 83 Linux/dev/sda2 2099200 23070719 20971520 10G 83 Linux/dev/sda3 23070720 209715199 186644480 89G 83 Linux
Диск /dev/sdb: 32 GiB, 34359738368 байт, 67108864 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт
Из вывода видно что sda рабочий диск а sdb подключенный.
Создаем раздел из всего диска sdb и форматируем его в ext4:
cfdisk -z /dev/sdb
mkfs.ext4 /dev/sdb1
Создаем две папки куда будем монтировать диски:
mkdir /mnt/sda && mkdir /mnt/sdb
Монтируем раздел sdb1 в необходимую папку:
mount /dev/sdb1 /mnt/sdb
C диском sda немного посложнее. В нашем случае разделы были подключены следующим образом:
df -h
= часть вывода с работающей системы =
/dev/sda2 10G 6,9G 3,2G 69% /
/dev/sda3 89G 11G 79G 12% /var/sevo44
/dev/sda1 976M 179M 731M 20% /boot
Раздел sda1 надо оставить как есть а вот sda3 убрать переместив все данные в корневой раздел sda2.
Монтируем вначале главный раздел а затем вложенный:
mount /dev/sda2 /mnt/sda
mount /dev/sda3 /mnt/sda/var/sevo44
Переносим теперь все данные с папки /mnt/sda в папку /mnt/sdb
Переносить необходимо в консольном файловом менеджере Midnight Commander (mc), так как она при переносе сохранит все права на файлы и перенесёт все один в один.
Есть и другие способы переноса в консоли, но вариант с Midnight Commander проще и наглядней.
После переноса проверяем правильность и только после этого отключаем разделы диска sda строго в таком порядке:
umount /mnt/sda/var/sevo44
umount /mnt/sda
Запускаем программу Gparted с Live-образа и делаем с разделами что нам необходимо. В моем случае получилось следующее:
Удалил раздел sda3 а раздел sda2 увеличил и отформатировали в формат ext4. Уменьшили диск больше чем на 50 Гиб.
Можно высчитывать и обрезать раздел ровно для последующего уменьшения, но мне проще потом его расширить подключившись с Live-образа.
Монтируем sda2 в папку /mnt/sda и копируем обратно в программе mc все данные с папки /mnt/sdb в /mnt/sda:
mount /dev/sda2 /mnt/sda
После копирования и проверки отключаем sdb1:
umount /mnt/sdb
Теперь нам необходимо отредактировать файл /etc/fstab который отвечает за монтирование разделов.
Определим какие uuid у разделов диска sda (при форматирование раздела uuid меняется на новый):
После перезагрузки системы CentOS 8 вы увидите такое сообщение:
Система говорит что она не видит корневой диск с таким uuid.
В случае если вы делали изменения раздела /boot вы увидите другую ошибку и способ устранения этой ошибки выходит за рамки данной статьи.
Решается эта проблема в два шага:
Загрузится указав правильный uuid;
В загрузившейся системе обновить Grub2.
Запускаем систему и как только увидите варианты загрузки нажимайте клавишу е:
В результате вы увидите место где необходимо сменить информацию:
Меняем на наш новый uuid 611171b8-5da5-460c-a6da-7bf8d42f2128 и нажимаем сочетание клавиш Ctrl и X.
Система загрузится, но значения загрузчика не поменяются. Выполним команду которая обновит grub2 в системе CentOS 8:
grub2-mkconfig -o /boot/grub2/grub.cfg
= вывод команды =
Generating grub configuration file ...
Found CentOS Linux 8 (Core) on /dev/sdb1
done
Все успешно обновилось, но я не отключил дополнительный диск и он добавился в меню загрузчика. На работу системы это никак не повлияет, но лучше не забывать отключать дополнительный диск после того как он больше не нужен.
Диск мы уменьшили и добились работоспособности системы теперь осталось выполнить последнее действие по уменьшению файла raw.
Преобразование раздела утилитой fstransform
Существует более простой способ, но как он работает на практике точно сказать не могу. Для меня описанный вариант выше более надежен, так как я не завишу от правильности действий этой утилиты.
Утилита называется fstransform и способна она преобразовывать в разные форматы.
Для преобразования корневого раздела необходимо загрузится с Live-образа установить утилиту и преобразовать нужный раздел.
Для Live-образа системы Debian (консольный вариант) нам вначале необходимо получить права root:
sudo su
Обновить список пакетов и установить:
apt update
apt install fstransform
Определить нужный раздел для преобразования командой # fdisk -l и запустить необходимую команду:
fstransform /dev/sda2 ext4
Раздел преобразуется с изменением uuid и дальше необходимо выполнить действия аналогично описанным выше.
Возможно если у вас виртуальная машина работает на LVM существует способ более простой и не надо переносить образ в файловый вариант, но мне не захотелось выполнять более сложные действия с системой LVM.
Воспользуемся командой которая может произвести изменение диска обрезав образ диска raw с конца на нужный размер.
В нашем случае номер виртуальной машины был 112 и нам необходимо уменьшить образ на 50 G:
qemu-img resize /var/lib/vz/images/112/vm-112-disk-0.raw -50G
= вывод команды =
WARNING: Image format was not specified for '/var/lib/vz/images/112/vm-112-disk-0.raw' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
qemu-img: warning: Shrinking an image will delete all data beyond the shrunken image's end. Before performing such an operation, make sure there is no important data there.
qemu-img: warning: Using the --shrink option will suppress this message. Note that future versions of qemu-img may refuse to shrink images without this option.
Image resized.
Как видим образ успешно изменён.
Осталось загрузится c Live-образа и в программе Gparted задействовать все свободное место от диска.
В системе Proxmox после изменения размера диска в разделе вы увидите уже новые параметры а вот в свойствах машины будет стоять старое значение. Возможно необходимо выполнить какое то действие, но в моем случае я переношу диск на раздел LVM и после этого везде будет показываться правильное значение.
Вывод
Как видно из статьи нюансы и главное внимательность при работе с разделами главный залог успеха. В любом случае всегда необходимо делать резервную копию выполняя изменение размера диска.
При создании новой системы всегда в голове возникает мысль как лучше разбить и какое использовать место, но попасть в нужные параметры удаётся не всегда. Зная как производить изменение разделов можно больше не ломать голову а делать все стандартным проверенным способом и в случае необходимости все исправить.
Установим коробочную версию Битрикс24 на операционную система CentOS 7 используя скрипт от разработчика. Выполним все первоначальные настройки которые дадут возможность произвести полноценное тестирование продукта. CRM система удобна и весьма популярна среди бизнеса.
Введение
В этой статье вы узнаете как установить коробочную версию Битрикс24 на систему CentOS 7. Варианты установки могут быть разные, но мне больше нравится именно такой способ о котором и поведаю.
Устанавливать будем тестовую версию на 30 дней и в последствии приобретём лицензию.
Мы увидим приветствие, в котором говорится, что на все вопросы по умолчанию будет ответ «Да» (Yes) и при необходимости ответить «Нет» нужно ввести n.
====================================================================
Bitrix Environment for Linux installation script.
Yes will be assumed as a default answer.
Enter 'n' or 'no' for a 'No'. Anything else will be considered a 'Yes'.
This script MUST be run as root, or it will fail.
====================================================================
Если на сервере работает SELinux, первый вопрос — согласны ли мы его отключить. Отвечаем утвердительно, нажав Enter:
You have to disable SElinux before installing Bitrix Environment.
Do you want to disable SELinux?(Y|n)
Скрипт вернет ответ, что SELinux выключен и потребует перезагрузки сервера:
SELinux status changed to disabled in the config file /etc/selinux/config.
SELinux status changed to disabled in the config file /etc/sysconfig/selinux.
Please reboot the system! (cmd: reboot)
В нашем случае мы уже отключили SELinux ранее и мы просто не увидим это сообщение. Если мы не отключали его рание надо перезагрузить сервер и запустить скрипт снова.
В конце установки при успешной установке увидем следующее:
Bitrix Environment bitrix-env has been installed successfully.
Посмотреть пароль от базы данных можно выполнив команду:
cat /root/.my.cnf
= необходимая часть информации в коде =
...
password='dfgj8856jdfbjf8'
...
Веб-окружение установлено.
Смотрим что сделал скрипт
В выводе конечно многое показывало, но проверим что произошло по факту.
Скрипт удалит FirewallD и настроил iptables.
Посмотрим какие правила iptables можно выполнив необходимую команду:
iptables -L -v -n
= вывод команды =
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 state NEW
7792 468K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW
240K 271M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
1 48 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
17887 1891K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
3 180 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
39660 6312K REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 213K packets, 170M bytes)
pkts bytes target prot opt in out source destination
Параметры настройки находятся в файле /etc/sysconfig/iptables.
Были установлены основные пакеты для работы веб сервера:
PHP7.2 из репозитория Remi’s PHP 7.2 RPM repository for Enterprise Linux 7;
Nginx 1.16.1;
Apache 2.4.6.
MySQL 5.7.28-31.
Основные настройки находятся в следующих местах:
Файлы лежат по пути /home/bitrix/www/;
Настройки Nginx находятся по пути /etc/nginx/bx;
Настройки Apache находятся по пути /etc/httpd/bx.
Понятно почему так всё было сделано и свои мнения по этому поводу я оставлю за рамками этой статьи.
Установка Битрикс24
Если ресурс работает напрямую без использования проксирования переходите к следующему разделу статьи.
Работа сайта через Nginx proxy
По умолчанию считается что сервер имеет свой белый IP и это понятно. Часто коробочную версию Битрикс24 устанавливают в своей локальной сети где имеется один белый ip на котором работают разные ресурсы по протоколам http или https.
Для решения задачи размещения на одном IP адресе разных ресурсов работающих по протоколу http(s) давно и успешно используется Nginx работающий в режиме прокси сервера.
На практике удобно настроить на Nginx получение сертификатов SSL и дальше проксировать сигнал до нужного сервера по протоколу http.
crm.sevo44.ru — под домен где будет работать Битрикс24;
http://192.168.0.44:80 — адрес на котором будет установлен Битрикс24;
client_max_body_size 10m — параметр который позволит передавать на ресурс файлы больше 10 Мбайт.
Использование Nginx прокси надо учитывать при дальнейшей настройке ресурса, так как внутренняя диагностика системы будет показывать выводы исходя из того что ресурс работает напрямую не используя маршрутизацию.
Установка Битрикс24
Открываем браузер и переходим по ссылке http://IP-адрес сервера.
Увидим окно приветствия и на каждом этапе вносим всю необходимую информацию.
Процедура не сложная и описывать её не вижу смысла. Гораздо интересней дальнейшая настройка без которой не возможно начать полноценное тестирование работы ресурса.
Настройка после установки
После установки произведем проверки которые покажут нам все проблемы из за которых работа ресурса просто не возможна на начальном этапе.
Тестирование конфигурации
Первое что надо сделать это произвести «Тестирование конфигурации». Находится это по пути: Панель управления (меню пользователя) -> Настройки (слева внизу) -> Инструменты -> Проверка системы -> Тестирование конфигурации.
В нашем случае было несколько ошибок и не одном из них покажу общий принцип решения проблемы.
Рассмотрим на ошибке не позволяющей загрузки файла больше 4 Мб:
Справа у каждого параметра есть кружок с восклицательным знаком и нажав на него откроется окно:
Из описания вроде всё понятно что делать и где смотреть, но везде вы увидите что параметр стоит верный:
В начале статьи я говорил что ресурс работает через Nginx прокси и именно параметр в настройке client_max_body_size 10m; позволит нам не увидеть данную ошибку.
В случае успеха вы должны увидеть:
Были еще незначительные ошибки которые с легкостью удалось поправить используя подсказки. Ниже расмотрим ошибку связаную с работой почты так как она одна из самый главных и имеет разный подход к решению.
Настройка работы почты
Настройка почты сильно меня не удивила, но заставила немного повозиться. Ровно одни сутки (1С) 🙂
Вот что будет показывать в выводе при тестировании конфигурации:
Оказывается разработчики придумали свой механизм который необходимо изучить. На просторах интернета есть много информации что при хорошей нагрузке этот механизм плохо работает, хотя это может быть связано с тем что никто не хочет досконально изучать и тратить кучу времени на его настройку.
Для себя я решил так, если разработчики не стали использовать стандартный FirewallD который идет по умолчанию в CentOS 7 (не думаю что отказ от использования был реально необходим с технической точки зрения) а стали использовать iptable, то и я могу с легкостью отказатся от их механизма отправки почты и настроить надежный и стабильный Postfix.
На сайте поддержи Битрикс24 есть статьи пользователей о том как это настраивается, но они либо устарели либо успускают очень важные настройки без который у вас ничего не будет работать.
Мой пример рабочий на все 100% и успешно работает на нескольких серверах.
Если Postfix не установлен то производим установку выполнив команду:
yum install postfix
Запускаем и добавляем в автозагрузку командами:
systemctl start postfix
systemctl enable postfix
Чтобы отправлять письма с консоли необходимо установить пакет mailx:
yum install mailx
После этого можно отправлять с консоли сервера сообщения на свою почту:
uname -a | mail -s "info server" info@sevo44.ru
Если сообщения получаем на почту значит все работает и двигаемся дальше.
Для начала надо в настройках /etc/php.d/bitrixenv.ini поменять значение:
vim /etc/php.d/bitrixenv.ini
= вывод команды с информацией для правки =
-- мы увидим --
sendmail_path = msmtp -t -i
-- меняем на --
sendmail_path = /usr/sbin/sendmail -i -t
Теперь открываем любой лид и производим отправку сообщения. Ошибки мы не увидим, так смотреть надо на сервере выполнив команду которая покажет последнюю информацию о работе почты:
tail -n 10 /var/log/maillog
В выводе отправляемого письма вы увидите:
said: 550 5.7.1 Email rejected per DMARC policy for mail.ru
В данном случае письма сразу попадают в спам.
Теперь настроим отправку почты через сторонний SMTP сервер.
Настроить через mail.ru не выйдет, так как будет ругаться что поле from не совпадает.
(host smtp.mail.ru[94.100.180.160] said: 550 Message was not accepted – it contains invalid headers. More specially, ‘From:’ header must match user you are sending mail from.
Будем настраивать используя Yandex, так как при тестовых оправках с почтового ящика mail, yandex.ru и gmail письма письма благополучно уходят и проходят успешную проверку у получателя.
Настройка через SMTP Yandex
В примере будет использована почта noreply@sevo44.ru которая обслуживается Yandex.
Переименуем базовый конфиг Postfix. После этого, создадим рабочий и добавим необходимые настройки:
mv /etc/postfix/main.cf /etc/postfix/main.cf_orig
vim /etc/postfix/main.cf
= необходимый код =
# DEFAULT CONFIG
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
mail_owner = postfix
# Имя сервера, которое выводит команда hostname
myhostname = vds-micro2.sevo44.ru
# По логике нужно оставлять только домен, но в данном случае лучше оставить полное имя сервера, чтобы в поле отправитель
# фигурировало полное имя сервера, так удобнее разбирать служебные сообщения
mydomain = vds-micro2.sevo44.ru
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain, localhost
inet_interfaces = localhost
inet_protocols = all
unknown_local_recipient_reject_code = 550
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
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/samples
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
# SMTP YANDEX CONFIG
relayhost = smtp.yandex.ru:587
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
# База параметров авторизации с SMPT
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
# Беза подмены имени почтового ящика
smtp_generic_maps = hash:/etc/postfix/generic
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = may
Создаем файл с информацией об имени пользователя и пароле для авторизации на сервере SMTP:
vim /etc/postfix/sasl_passwd
= необходимый код =
smtp.yandex.ru:587 noreply@sevo44.ru:PASSWORD
Создаем db файл:
postmap /etc/postfix/sasl_passwd
Переименуем дефолтную базу подмены имени почтового ящика. После этого, создадим рабочий и добавим необходимые настройки:
mv /etc/postfix/generic /etc/postfix/generic_orig
vim /etc/postfix/generic
= необходимый код =
bitrix@bitrix24.localdomain noreply@sevo44.ru
root@bitrix24.localdomain noreply@sevo44.ru
Выделенные параметры смотрим исходя из вывода команды: tail -n 10 /var/log/maillog в которой вы увидите информацию об отправлениях.
Создаем db файл:
postmap /etc/postfix/generic
При получении ошибки при проверке: «warning: SASL authentication failure: No worthy mechs found»
Необходимо установить ещё несколько пакетов для работы SASL.
В заключение, осталось добавить к стандартному алиасу для root в /etc/aliases, внешний адрес, куда будет дублироваться почта, адресованная root. Для этого редактируем указанный файл, изменяя последнюю строку:
vim /etc/aliases
= необходимо привести к виду =
# Person who should get root's mail
root: root,info@sevo44.ru
Обновляем базу сертификатов:
newaliases
Создание пула серверов
При подключении к консоли сервера вы увидете сообщение:
Нам предложено создать пул серверов, но делать мы это пока не будем так как это отдельная тема которой я посвящу отдельную статью.
Вводим 0 нажимаем Ентер и продолжаем работать дальше с имеющейся системой.
Вывод
В целом система мне понравилась. Радует наличие огромного количества проверок. Единственное что настоятельно рекомендую перед любыми действиями делать резервную копию, ну и конечно должны автоматически создаваться резервные копии за период который максимально позволяет размер дискового массива сервера резервных копий.
Расскажу про установку системы GLPI на операционную систему CentOS. Удобней системы для ведения ИТ-инфраструктуры я не встречал. Кроме ведения заявок можно контролировать рабочие станции, вести справочную документацию и много чего ещё делать.
Введение
Практически сразу начав заниматься обслуживанием компьютерной техники я столкнулся с необходимостью вести учет всех поступивших заявок по обслуживанию в удобном виде.
Основные причины по которым я пришел к выводу что такая система необходима следующие:
Удобное ведение поступивших заявок — заявки поступившие в систему не забываются и не надо вести дополнительных блокнотов;
Хронология каждой заявки — в процессе решения собирается вся необходимая информация в одном месте;
История заявок — в случае проблем с заказчиком всегда можно посмотреть все события по заявке и освежить в памяти события которые со временем забываются.
Требования к системе предъявлялись следующие:
Свободная система работающая на свободных операционных системах;
Система должна активно развиваться и иметь возможность простого обновления;
Система должна работать на популярном языке программирования;
Возможность удобной подачи заявки и последующего ведения;
Ведение в одной системе разных организаций;
Гибкое администрирование уровня доступа пользователей;
Создание базы знаний для пользователей;
Использование доменных пользователей;
Личный планировщик заданий.
Перепробовал большое количество разных систем, но остановился на GLPI, так как эта система максимально удовлетворяет всем моим требованиям и позиционирует себя как свободный менеджер ИТ-инфраструктуры.
Основное что меня порадовало в системе GLPI это:
Систему GLPI можно установить на простой хостинг как обычный сайт так как он написан на PHP (при условии что можно сделать некоторые специфические настройки);
Настроек очень много и это позволяет реализовать практические любые пожелания;
Простота и продуманность обновления;
Информативность по выполняемым действиям очень радует, так как можно посмотреть подробную историю как действий пользователей так и автоматических заданий;
Расширение возможностей с помощью большого количества дополнений;
Почти во всех настройках есть история изменений где можно посмотреть кто и что делал;
Делать резервные копии базы данных перед серьезными настройками в системе GLPI.
Если сравнить по функционалу и подходу разработчиков, то система похожа на популярную систему мониторинга Zabbix.
Еще один из главных аргументов которые меня склонили к окончательному выбору системы это то что в разработке принимает активное участие Remi Collet и ведет поддержку GLPI в своем репозитории.
В статье вы узнаете полную версию установки на операционную систему CentOS c нуля.
Добавляем пользователя nginx в группу support.sevo44.ru:
usermod -aG support.sevo44.ru nginx
Открываем конфигурационный файл ssh находящийся по пути /etc/ssh/sshd_config. Комментируем один параметр и добавим необходимый код:
vim /etc/ssh/sshd_config
= необходимые изменения и добавления =
# Закоментируем параметр
#Subsystem sftp /usr/lib64/misc/sftp-server
# Для работы sftp
Subsystem sftp internal-sftp
# Для support.sevo44.ru
Match User support.sevo44.ru
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no
ForceCommand internal-sftp
ChrootDirectory /var/www/support.sevo44.ru
# /support.sevo44.ru
Перезапускаем службу sshd:
systemctl restart sshd
Назначаем владельцем содержимого сайта пользователя которого мы создали выше:
С репозитория Remi можно установить GLPI, но настроен он будет для работы с Apache.
Установим Php версии 7.2 со всеми необходимыми пакетами. Возможно их больше чем необходимо, но именно они устанавливаются если устанавливать используя репозиторий Remi:
Внесем необходимые изменения в файл настроек php.ini:
vim /etc/php.ini
= необходимые изменения =
# Запрет на исполнение произвольного кода на сервере с правами php процесса при загрузке файла.
cgi.fix_pathinfo=0
# Необходимая временная зона
date.timezone = "Europe/Moscow"
Запускаем php-fpm и добавляем в автозагрузку:
systemctl enable --now php-fpm
Запускать php-fpm будем через unix сокет. Для этого переименуем конфиг /etc/php-fpm.d/www.conf, создадим новый и приводим к следующему виду:
Создадим отдельный пул для php-fpm, который будет обслуживать сайт support.sevo44.ru на котором и будет работать GLPI. Удобно когда для каждого сайта используется независимый пул в котором можно выставить необходимые значения.
Переходим в нужную папку, копируем существующий конфигурационный файл и делаем необходимые изменения:
vim /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
module_hotfixes=true
Устанавливаем:
dnf install nginx
Добавляем в автозагрузку и запускаем:
systemctl enable --now nginx
Проверяем работу:
curl http://localhost
= вывод команды =
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
Для удобства всегда правлю файл сайта по умолчанию для понимания к какому серверу подключился:
vim /usr/share/nginx/html/index.html
= необходимый код =
<!DOCTYPE html>
<html>
<head>
<title>Welcome!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working.</p>
<p><em>lemp.sevo44.loc</em></p>
</body>
</html>
Переименуем главный конфигурационный файл Nginx и создадим новый с нужными параметрами:
mv /etc/nginx/nginx.conf /etc/nginx/nginx.conf_orig
vim /etc/nginx/nginx.conf
= необходимый код c пояснениями=
# Пользователь и группа, от имени которых будет запущен процесс
user nginx nginx;
# Число воркеров в новых версиях рекомендовано устанавливать параметр auto
worker_processes auto;
# Уровни лога debug, info, notice, warn, error, crit, alert или emerg
# перечислены в порядке возрастания важности. При установке определённого уровня
# в лог попадают все сообщения указанного уровня и уровней большей важности.
# Например, при стандартном уровне error в лог попадают сообщения уровней error, crit, alert и emerg.
# Если параметр не задан, используется error.
error_log /var/log/nginx/error.log warn;
# Файл в котором будет храниться идентификатор основного процесса
pid /var/run/nginx.pid;
events {
# Максимальное количество соединений одного воркера
worker_connections 1024;
# Метод выбора соединений (для FreeBSD будет kqueue)
use epoll;
# Принимать максимально возможное количество соединений
multi_accept on;
}
http {
# Отключить вывод версии nginx в ответе
server_tokens off;
# Указываем файл с mime-типами и указываем тип данных по-умолчанию
include /etc/nginx/mime.types;
default_type application/octet-stream;
# Формат для лога доступа и путь к файлу
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
# Метод отправки данных sendfile эффективнее чем read+write
sendfile on;
# Ограничивает объём данных, который может передан за один вызов sendfile().
# Нужно для исключения ситуации когда одно соединение может целиком захватить воркер
sendfile_max_chunk 128k;
# Отправлять заголовки и начало файла в одном пакете
tcp_nopush on;
tcp_nodelay on;
# Параметр задаёт таймаут, в течение которого keep-alive соединение с клиентом не будет закрыто со стороны сервера
keepalive_timeout 65;
# Сбрасывать соединение если клиент перестал читать ответ
reset_timedout_connection on;
# Разрывать соединение по истечению таймаута при получении заголовка и тела запроса
client_header_timeout 3;
client_body_timeout 5;
# Разрывать соединение, если клиент не отвечает в течение 3 секунд
send_timeout 3;
# Задание буфера для заголовка и тела запроса
client_header_buffer_size 2k;
client_body_buffer_size 256k;
# Ограничение на размер тела запроса
client_max_body_size 12m;
# Подключение дополнительных конфигов
include /etc/nginx/conf.d/*.conf;
}
Проверяем правильность настроек Nginx:
nginx -t
= вывод команды =
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Всё хорошо. Выполняем обновление правил без перезагрузки Nginx:
nginx -s reload
Конфигурационный файл Nginx для GLPI
Создаем фал Nginx для работы GLPI:
vim /etc/nginx/conf.d/support.sevo44.ru.conf
= необходимый код =
### support.sevo44.ru
server {
listen 80;
server_name support.sevo44.ru www.support.sevo44.ru;
root /var/www/support.sevo44.ru/www/;
index index.php index.html index.htm;
access_log /var/www/support.sevo44.ru/log/support.sevo44.ru-access.log;
error_log /var/www/support.sevo44.ru/log/support.sevo44.ru-error.log;
# Для записи в log реальных ip при использовании прокси nginx
set_real_ip_from 10.10.0.1;
real_ip_header X-Real-IP;
# Без него не грузит файлы больше 1 метра
client_max_body_size 10m;
keepalive_timeout 60;
add_header Strict-Transport-Security 'max-age=604800';
location / {
try_files $uri $uri/ =404;
autoindex on;
}
location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff)$ {
access_log off;
expires max;
}
location /api {
rewrite ^/api/(.*)$ /apirest.php/$1 last;
}
location ~ \.php$ {
try_files $uri = 404;
fastcgi_index index.php;
fastcgi_pass unix:/run/php-fpm/support.sevo44.ru.sock;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SERVER_NAME $host;
fastcgi_param HTTPS on;
fastcgi_intercept_errors on;
fastcgi_ignore_client_abort off;
fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_param PHP_VALUE "
memory_limit = 64M
file_uploads = on
max_execution_time = 600
session.auto_start = off
session.use_trans_sid = 0
";
}
location = /favicon.ico {
log_not_found off;
access_log off;
}
location = /robots.txt {
#allow all;
deny all;
log_not_found off;
access_log off;
}
location ~ /\.ht {
deny all;
}
}
В моем варианте сигнал проксируется с помощью Nginx прокси. Сертификат получаем на проксирующем сервере.
nginx -t
= вывод команды =
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
nginx -s reload
Добавим необходимый репозиторий создав файл с кодом:
vim /etc/yum.repos.d/mariadb.repo
= необходимый код =
# MariaDB 10.4 CentOS repository list - created 2019-10-24 18:16 UTC
# http://downloads.mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.4/centos8-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
Сам процесс установки и начальной настройке прост и понятен. Все дальнейшие «сюрпризы» и нюансы будут при настройке системы для работы.
Система настолько гибкая что порой начинаешь путаться во всех её возможных схемах работы.
Главное делайте бэкап базы данных средствами самой GLPI и тогда сможете сэкономить много своего времени.
Установка GLPI
Разработчики для безопасности рекомендуют вынести некоторые папки за рамки веб сервера для безопасности и об это рассказано тут.
В данном примере я не выношу папки за пределы веб сервера, хотя на практике это использую. Лишняя безопасность еще никому не вредила.
Запускаем установку введя в браузере адрес сайта.
Выбираем язык:
Соглашаемся с лицензией:
Выбираем вариант установить:
Смотрим результат проверок:
На предупреждение не обращаем внимания так как мы не вынесли некоторые папки за пределы веб сервера по рекомендации разработчиков.
Вводим данные от базы данных:
Выбираем созданную ранее базу данных:
Проверка подключения к базе данных прошла успешно:
Соглашаемся с отправкой статистики использования если уважаем свободное программное обеспечение:
Если посмотрите по ссылке какие данные отправятся то увидите что ничего секретного там нет.
Продолжаем и при желании открываем страницу на которой сказано как можно помочь материально проекту:
В результате увидим сообщение об удачной установке и список всех пользователей по умолчанию с паролями:
Вот таким видом нас встретит страница авторизации GLPI:
Вот так выглядит главная страница при авторизации GLPI:
По рекомендации удаляем указанный файл и меняем пароль у пользователя glpi. У остальных пользователей или меняем пароль или просто отключаем их.
Настройка CRON для GLPI
Добавление в cron правильной команды один из главных моментов в GLPI, так как он будет обрабатывать все автоматические задачи.
Добавим файл с необходимым кодом:
vim /etc/cron.d/glpi
= необходимый код =
# GLPI core
# Run cron to execute task even when no user connected
*/5 * * * * root /usr/bin/php /var/www/support.sevo44.ru/www/front/cron.php
Где указаны следующие параметры:
*/5 * * * * — задание выполняется каждые 5 минут;
support.sevo44.ru — пользователь которому принадлежит файл;
/usr/bin/php — с помощью чего обрабатывать файл;
/var/www/support.sevo44.ru/www/front/cron.php — путь до необходимого файла.
После добавления обязательно нужно проверить как он выполняется. Посмотрим логи cron:
cat /var/log/cron
= часть вывода кода =
Nov 10 21:57:01 support.sevo44.loc CROND[527]: (root) CMD (/usr/bin/php /var/www/support.sevo44.ru/www/front/cron.php)
Nov 10 21:58:01 support.sevo44.loc CROND[540]: (root) CMD (/usr/bin/php /var/www/support.sevo44.ru/www/front/cron.php)
Nov 10 21:59:01 support.sevo44.loc CROND[556]: (root) CMD (/usr/bin/php /var/www/support.sevo44.ru/www/front/cron.php)
Из вывода видно что задачи успешно выполняются каждую минуту.
Ротация логов
В системе GLPI присутствует свой хороший механизм логирования, но держать логи на уровне сайта не помешает.
Настроим сразу ротацию логов что бы при необходимости было удобно их просматривать.
Создадим необходимый файл:
vim /etc/logrotate.d/sites
= необходимый код =
/var/www/support.sevo44.ru/log/*.log
{
daily
missingok
rotate 52compress
delaycompress
notifempty
create 644 nginx adm
sharedscripts
postrotate
if [ -f /var/run/nginx.pid ]; then
kill -USR1 `cat /var/run/nginx.pid`
fi
endscript
}
Согласно кода ротация будет проводится раз в день, и хранить архивы будет 52 дня. Файлы будут сжиматься и иметь права 644.
Backup сайта GLPI
После настройки настоятельно рекомендую настроить резервное копирование файлов и базы данных. Посмотреть о том как я произвожу резервное копирование в подобных случаях можно из статьи Backup надежный и безопасный.
Изменения в файлах GLPI
Обычно я сторонник не вносить изменения в файлы разработчика, но в данном случае мне они кажутся разумными и снимают ненужные вопросы от пользователей системы.
Произведем изменении графики:
pics/favicon.ico — иконка сайта;
pics/fd_logo.png — логотип справа после авторизации;
pics/login_logo_glpi.png — логотип при авторизации.
Берем оригинальные файлы и не меняя разрешения делаем новые картинки. Для создания иконки сайта существуют куча онлайн сайтов и Вы можете воспользоваться ими.
Изменим заголовок сайта до авторизации:
index.php
=== примерно 76 строка ===
echo '<head><title>'.__('CЭВО:Техподдержка - Аутентификация').'</title>'."\n";
Убираем внизу сообщений информацию Automatically generated by GLPI:
inc/notificationtemplate.class.php
=== По поиску в 2 местах меняем ===
Automatically generated by GLPI ---> Сгенерировано автоматически
Обновление GLPI
Механизм обновления разработчиками продуман и хорошо документируется. При правильном подходе проблем с обновлением не возникнет. Например, мне без проблем удается обновлять уже в течении трех лет.
Перед обновление обязательно посмотрите какие у Вас установлены плагины и проверьте будут ли они работать в новой версии. В случае если плагина для новой версии еще нет Вам необходимо отказаться от его использования или повременить с обновлением GLPI.
Перед обновление обязательно делайте резервную копию файлов и базы данных.
Перед началом обновления всегда ставлю пароль на открытие сайта средствами Nginx. Это позволит вам избежать случая когда пользователь который хочет зайти на портал увидит там страницу с обновлением и начнет выполнять действия за вас 🙂
О том как сделать доступ к сайту по паролю средствами Nginx Вы можете посмотреть тут.
Посмотреть какая последняя версия и сохранить себе путь можно на странице Downloads сайта разработчика.
Переходим в корневую папку, скачиваем туда новую версию и распаковываем:
cd /var/www/support.sevo44.ru
wget https://github.com/glpi-project/glpi/releases/download/9.5.3/glpi-9.5.3.tgz
tar zxvf glpi-9.5.3.tgz
В результате у вас появиться папка glpi.
В папке www удаляем всё кроме нескольких папок:
files — все файлы что загружали;
plugins — все плагины;
config — настройки db.
Теперь всё что есть в папке glpi переносим в папку www. Например, я для подобных целей использую MC.
После того как всё перенесено необходимо выставить правильного пользователя и правильные права на файлы с папками:
Переходим на сайт и видим информацию об обновлении.
В данном обновление необходимо настроить работу с временными зонами и в документации про это сказано.
Инициализируем данные часовых поясов из часовых поясов нашей системы:
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -p -u root mysql
Enter password: пароль пользователя root mariadb
Дадим необходимые права на чтение:
mysql -u root -p
Enter password: пароль пользователя root mariadb
GRANT SELECT (`Name`) ON `mysql`.`time_zone_name` TO 'support.sevo44.ru'@'%';
Query OK, 0 rows affected (0.082 sec)
FLUSH PRIVILEGES;
\q
Перезапустим сервис баз данных:
systemctl restart mariadb
Больше ошибок нет и переходим к обновлению базы данных.
Нажимаем кнопку «Обновление» и получим примерно такую картину:
Мы видим что обновление произошло с 9.4.4 до 9.5.3 и указало какие действия необходимо сделать.
В данном случае нам сказано что необходимо выполнить консольную команду которая преобразует в базе данных все необходимые поля относящиеся к временным зонам.
Произведем необходимые действия:
cd /var/www/support.sevo44.ru/www/bin
php console glpi:migration:timestamps
=== вывод команды ===
Found 185 table(s) requiring migration.
Do you want to continue ? [Yes/no]y
185/185 [============================] 100%
Migration done.
Возможно после обновления расширений необходимо будет повторить действие которое описано выше.
В заключении, необходимо обновить плагины, если это необходимо, и зайти на страницу с автоматическими заданиями. Возможно какие то задания будут в зависшем состоянии и их необходимо перезапустить на странице настроек конкретного задания.
Не забываем произвести изменения в файлах GLPI если это делалось ранее.
Заключение
Надеюсь статья оказалась понятной и информативной. Рассмотрены все основные моменты по установке, начальной настойке и последующего обновления системы GLPI. В следующей статье я обязательно поделюсь нюансами с которыми столкнулся при настройке системы. Некоторые моменты не логичны возможно по причине не правильного перевода, но в целом система очень удобна в работе.
Версии PHP от Remi являются самыми популярными и стабильными при использовании на Web серверах. Расскажу основные моменты работы с репозиторием. Рассмотрим как сменить версию PHP. Один из самых популярных репозиториев для CentOS.
Введение
Есть замечательный человек Remi Collet, который создал репозиторий пользующийся огромной популярностью у пользователей операционной системы CentOS. Познакомится с новостями репозитория можно на блоге Remi Collet.
В статье будет рассказано про использование репозитория на системах CentOS 7 и 8.
Les RPM de Remi repository поддерживает последние версии MySQL и PHP (бэкпорты федоровских rpm). Пакеты этого репозитория необходимо использовать с осторожностью, так как они заменяют базовые пакеты.
В другой статье вы можете узнать как использовать репозиторий WebtaticEL для CentOS 7. В нем так же используются последние версии PHP, но к сожалению там нет многих удобств которые есть у Remi. Например, используя репозиторий Remi можно всегда иметь последнюю версию phpMyAdmin.
Предварительная подготовка
Перед началом использования репозитория Remi необходимо подключить репозиторий Epel созданный группой специалистов операционной системы Fedora. Пакеты из Epel репозитория никогда не конфликтуют и не переустанавливают базовые пакеты RHEL.
Установка Epel в CetnOS 7 производится командой:
yum install epel-release
Установка Epel в CetnOS 8 производится командой:
dnf install epel-release
Подключение репозитория от Remi
для CentOS 7
Для установки репозитория Remi в CentOS 7 достаточно выполнить команду:
Посмотреть активные репозитории можно следующей командой:
yum repolist
= вывод части команды =
Загружены модули: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.corbina.net
* epel: mirror.logol.ru
* extras: mirror.reconn.ru
* remi-safe: mirror.reconn.ru
* updates: mirror.corbina.net
remi-safe Safe Remi's RPM repository for Enterprise Linux 7 - x86_64 3 144
По умолчанию установлен репозиторий remi-safe который имеет только дополнительные пакеты для базового хранилища и коллекций программного обеспечения. Например, при попытке установить phpMyAdmin будет установлена старая версии. Для установки последних версий надо активировать репозиторий remi.
Посмотрим репозитории что у нас есть в системе выполнив команду:
GLPI — это программный инструмент ITSM, который помогает вам легко планировать и управлять изменениями в ИТ структуре предприятия, эффективно решать возникающие проблемы используя систему заявок, так же позволяет вам получить контроль над ИТ-бюджетом и расходами вашей компании. В будущем я расскажу как работать с этим замечательным проектом. Кроме того, то что Remi Collet поддерживает репозиторий меня очень радует.
Перед работой с репозиториями Remi необходимо установите пакет yum-utils, что бы не получать ошибку «bash: yum-config-manager: command not found». Установим yum-utils выполнив необходимую команду:
yum install yum-utils
Сейчас у нас активирован remi-safe. Для активации remi надо вначале отключить remi-safe а потом активировать remi выполнив команды:
Перед тем как определится какую версию PHP использовать я всегда смотрю на сайте Supported Versions PHP.
В списке имеющихся репозиториев нет версии php5.6, так как он входит в состав remi.repo. Для установки достаточно в команде указать remi-php56.
для CentOS 8
В 8 версии CentOS используется версия php 7.2 которая уже может удовлетворять требования множества новых сайтов, но если вам нужны версии новее подключайте Remi.
Посмотрим список всех доступных вариантов установки php:
dnf module list php
= вывод команды =
Последняя проверка окончания срока действия метаданных: 1:41:10 назад, Пн 28 окт 2019 08:05:09.
CentOS-8 - AppStream
Name Stream Profiles Summary
php 7.2 [d] common [d], devel, minimal PHP scripting language
Remi's Modular repository for Enterprise Linux 8 - x86_64
Name Stream Profiles Summary
php remi-7.2 common [d], devel, minimal PHP scripting language
php remi-7.3 common [d], devel, minimal PHP scripting language
php remi-7.4 common [d], devel, minimal PHP scripting language
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled
Из вывода выше видно что по умолчанию стоит базовая версия CentOS 7.2 и имена она будет установлена.
Установка версии PHP от Remi
для CentOS 7
Активируем репу remi-php72, для этого выполняем команду:
# yum-config-manager --enable remi-php72
Устанавливаем php7.2 выполнив команду:
yum install php72
Лучше указывать php72 и тогда пакеты будут установлены только из репозитория remi. Например, я всегда внимательно смотрю какая версия php будет установлена в списке устанавливаемых пакетов.
Установим php-fpm и наиболее популярные модули, которые могут пригодится в процессе эксплуатации веб сервера.
Последняя проверка окончания срока действия метаданных: 1:53:36 назад, Пн 28 окт 2019 08:05:09.
Зависимости разрешены.
====================================================================================================
Пакет Архитектура Версия Репозиторий Размер
====================================================================================================
Enabling module streams:
httpd 2.4
php remi-7.2
Результат транзакции
====================================================================================================
Продолжить? [д/Н]: д
Выполнено!
Switching module streams does not alter installed packages (see 'module enable' in dnf(8) for details)
Убедимся что версия выбрана правильно:
dnf module list php
= вывод команды =
Последняя проверка окончания срока действия метаданных: 1:55:03 назад, Пн 28 окт 2019 08:05:09.
CentOS-8 - AppStream
Name Stream Profiles Summary
php 7.2 [d] common [d], devel, minimal PHP scripting language
Remi's Modular repository for Enterprise Linux 8 - x86_64
Name Stream Profiles Summary
php remi-7.2 [e] common [d], devel, minimal PHP scripting language
php remi-7.3 common [d], devel, minimal PHP scripting language
php remi-7.4 common [d], devel, minimal PHP scripting language
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled
Всё правильно.
Установим php remi-7.2 и все популярные модули следующей командой:
Внесем необходимые изменения в файл настроек php.ini:
vim /etc/php.ini
= необходимые изменения =
# Запрет на исполнение произвольного кода на сервере с правами php процесса при загрузке файла.
cgi.fix_pathinfo=0
# Необходимая временная зона
date.timezone = "Europe/Moscow"
Настройка Php-fpm для Nginx
Для того чтобы связать nginx и php будем использовать мост php-fpm. Основной файл настройки находится по пути /etc/php-fpm.conf и там должен быть параметр include=/etc/php-fpm.d/*.conf говорящий о том где лежат настройки пулов.
Запускаем php-fpm и добавляем в автозагрузку:
systemctl start php-fpm
systemctl enable php-fpm
=== Для CentOS 8 можно выполнить одну команду ===
systemctl enable --now php-fpm
Проверяем, запустился ли он.
systemctl status php-fpm
= вывод команды =
● php-fpm.service - The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2019-10-28 10:09:25 MSK; 1min 1s ago
Main PID: 463 (php-fpm)
Status: "Processes active: 0, idle: 5, Requests: 0, slow: 0, Traffic: 0req/sec"
Tasks: 6 (limit: 11524)
Memory: 25.7M
CGroup: /system.slice/php-fpm.service
├─463 php-fpm: master process (/etc/php-fpm.conf)
├─464 php-fpm: pool www
├─465 php-fpm: pool www
├─466 php-fpm: pool www
├─467 php-fpm: pool www
└─468 php-fpm: pool www
окт 28 10:09:24 wp-lxc_pro-php7_sevo44_loc systemd[1]: Starting The PHP FastCGI Process Manager...
окт 28 10:09:25 wp-lxc_pro-php7_sevo44_loc systemd[1]: Started The PHP FastCGI Process Manager.
Все в порядке, сервис работает и находится в автозагрузке.
Использовать порт или сокет решать вам, но говорят что сокет использовать лучше. Запустим php-fpm через unix сокет. Для этого переименуем конфиг /etc/php-fpm.d/www.conf, создадим новый и приводим к следующему виду:
Вы можете для каждого сайта созать свой пул и указать там все необходимые параметры. Например, для каждого сайта я создаю свой пул для гибкости настройки и благодаря этому я настраиваю корректный доступ к файлам по sftp.
В настройках nginx для сайта необходимо указать требуемый пул. Например, прописать код fastcgi_pass unix:/run/php-fpm/www.sock; в секции location ~ \.php$
Обновление версий PHP от Remi
Схема обновления универсальна и подойдет как для всех версий CentOS. В примере ниже расмотрен вариант обновления для версии 7.
Обновление состоит из нескольких действий:
Остановка php-fpm,
Вывод и удаление всех имеющихся пакетов php,
Удаление старого и активирование нового репозитория требуемой версии php,
Установка новой версии,
Проверка настрое из старой версии,
Запуск php-fpm и проверка сервиса.
Выполним обновление PHP до версии 7.3 в системе CentOS 7.
Обязательно смотрим версию и репозиторий откуда будут ставится пакеты.
Осталось проверить файлы что выдала команда при удалении старой версии php:
предупреждение: /etc/php-fpm.d/www.conf сохранен как /etc/php-fpm.d/www.conf.rpmsave
предупреждение: /etc/php.ini сохранен как /etc/php.ini.rpmsave
В заключение, запустим сервис php-fpm и проверим статус:
systemctl start php-fpm
systemctl status php-fpm
● php-fpm.service - The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled; vendor preset: disabled)
Active: active (running) since Ср 2019-03-13 21:16:12 MSK; 7s ago
Main PID: 1392 (php-fpm)
Status: "Ready to handle connections"
CGroup: /lxc/php7-lxc/system.slice/php-fpm.service
├─1392 php-fpm: master process (/etc/php-fpm.conf)
├─1393 php-fpm: pool www
├─1394 php-fpm: pool www
├─1395 php-fpm: pool www
├─1396 php-fpm: pool www
└─1397 php-fpm: pool www
мар 13 21:16:11 php7-lxc-lemp.sevo44.loc systemd[1]: Starting The PHP FastCGI Process Manager...
мар 13 21:16:12 php7-lxc-lemp.sevo44.loc systemd[1]: Started The PHP FastCGI Process Manager.
Из вывода видно что сервис не стартует при загрузке. Добавим сервис в автозагрузку выполнив команду:
systemctl enable php-fpm
Вывод
В статье рассказано про основные моменты работы с репозиторием Remi Collet. Репозиторий активно обновляется и мой выбор остановился на использовании именно его при работе с PHP.
Backup или резервное копирование данных самое важное и необходимое действие. Только постоянное регулярное сохранение резервной копии в надежном месте и их постоянная проверка и мониторинг даст полную гарантию защиты данных от потери.
Введение
Правильное создание и безопасное хранение бэкапов задача важная и необходимая. Можно относится халатно, но тогда в случае проблем можете обнаружить что резервных копий нет или они просто испорчены.
Из статьи вы узнаете как я подхожу к этому вопросу и защищаю бэкапы всех своих ресурсов надежно и безопасно.
В примере будет рассмотрен вариант для резервного копирования файлов и базы данных сайта, но можно этот подход использовать и для других задач.
Можно использовать для резервных копий разные программные комплексы или пользоваться средствами которые предоставляют хостинги, но для этого необходимо их изучать или производить финансовые затраты.
Основа безопасности бэкапов
Правильность и безопасность бэкапов включает в себя несколько простых правил:
Хранение бэкапов за продолжительный период времени. Вариантов почему лучше хранить бэкапы долго множество. Например, удалили какой то материал, но решили восстановить спустя некоторое время или необходимо найти ошибку когда появилась проблема которую обнаружили не сразу.
Забирать бэкапы сторонним сервером. В идеале лучше использовать под резервные копии специальный сервер использующийся только для бэкапов. В случае если копии бэкапов отправляются с самого сервера где делаются бэкапы это опасно, так как в случае взлома или вируса вы можете потерять все копии.
Мониторинг как создание бэкапа так и аналитика его размеров. Как бы вы не пытались отслеживать периодически сами как делаются бэкапы по закону подлости, когда они потребуются, обнаружите что они или не делаются или испорчены.
Ниже я по порядку опишу все свои действия которые использую на практике. Будут использованы стандартные программы используемые во всех версиях Linux.
Создание бэкапов на сервере
Самое надежное это когда производится создание резервных копии на самом сервере, так как это гарантирует что вы не получите проблем возникших с удаленным подключением к сторонним ресурсам. Например, при использовании бэкапа на Yndex Disk у меня периодически были ошибки при создании бэкапа.
Структура папок для бэкапов
Создавать папки можно где угодно. Например, мне больше нравится создавать их в корне папку backup и держать там всё что связанно с резервными копиями.
Создадим необходимые папки куда будем класть бэкапы
/backup — папка где будет находиться всё что связано с резервными копиями;
/backup/bin — папка где будут находиться скрипты запускаемые по расписанию;
/backup/sevo44.ru/day — папка где будут лежать ежедневные бэкапы;
/backup/sevo44.ru/month — папка где будут лежать ежемесячные бэкапы;
/backup/sevo44.ru/source — папка в которой я храню копии которые были начальными. Например, в случае когда ресурс переносится с другого сервера или возвращается в жизнь после продолжительного перерыва в работе.
Backup и его периодичность
Всегда сложно выбрать какой необходим период хранения и интервал резервного копирования. Для меня удобней организовать резервное копирование по следующей схеме:
Дневные копии — хранить 30 дней,
Месячные копии — хранить год.
Подход к резервированию сугубо личное дело и зависит от множества факторов. Главное чтобы эти копии всегда были доступны, исправны и удовлетворяли вашим требованиям.
Создание скриптов для бэкапов
Создадим два скрипта для ежедневного и ежемесячного бэкапа.
Создадим скрипт который будем ежедневно запускать по расписанию:
vim /backup/bin/day-backup-sevo44.ru.sh
= необходимый код =
#!/bin/sh
# Текущая дата в формате 2015-09-29_04-10
date_time=`date +"%Y-%m-%d_%H-%M"`
# Папка для бэкапа
inf_dir='/var/www/sevo44.ru/www'
# Куда размещаем backup
bk_dir='/backup/sevo44.ru/day'
# Название архива с файлами
name_www='www-sevo44.ru'
# Название архива с базой
name_sql='sgl-sevo44.ru'
# Пользователь базы данных
user='sevo44-ru'
# Пароль пользователя базы данных
password='пароль'
# Имя базы данных для бэкапа
bd_name='sevo44-ru'
# Команды для выполнения
# В случае необходимости хранить только последний бэкап
# очищаем папку удаляя только файлы в папке
rm -f $bk_dir/*
# Создание файла с датой для мониторинга в zabbix
echo `date +"%Y-%m-%d_%H-%M"` > $bk_dir/timestamp
# Создание архива папки с файлами
/bin/tar -czvf $bk_dir/$name_www-$date_time.tar.gz $inf_dir
# Создание архива базы данных
/usr/bin/mysqldump --opt -v --databases $bd_name -u$user -p$password | /bin/gzip -c > $bk_dir/$name_sql-$date_time.sql.gz
# Удаляем архивы старше 5-ти дней
#/usr/bin/find $bk_dir -type f -mtime +5 -exec rm {} \;
Для ежемесячных бэкапов создадим такой скрипт:
vim /backup/bin/month-backup-sevo44.ru.sh
= необходимый код =
#!/bin/sh
# Текущая дата в формате 2015-09-29_04-10
date_time=`date +"%Y-%m-%d_%H-%M"`
# Папка для бэкапа
inf_dir='/var/www/sevo44.ru/www'
# Куда размещаем backup
bk_dir='/backup/sevo44.ru/month'
# Название архива с файлами
name_www='www-sevo44.ru'
# Название архива с базой
name_sql='sgl-sevo44.ru'
# Пользователь базы данных
user='sevo44-ru'
# Пароль пользователя базы данных
password='пароль'
# Имя базы данных для бэкапа
bd_name='sevo44-ru'
# Команды для выполнения
# В случае необходимости хранить только последний бэкап
# очищаем папку удаляя только файлы в папке
rm -f $bk_dir/*
# Создание файла с датой для мониторинга в zabbix
echo `date +"%Y-%m-%d_%H-%M"` > $bk_dir/timestamp
# Создание архива папки с файлами
/bin/tar -czvf $bk_dir/$name_www-$date_time.tar.gz $inf_dir
# Создание архива базы данных
/usr/bin/mysqldump --opt -v --databases $bd_name -u$user -p$password | /bin/gzip -c > $bk_dir/$name_sql-$date_time.sql.gz
# Удаляем архивы старше одного года
#/usr/bin/find $bk_dir -type f -mtime +365 -exec rm {} \;
Первая и последняя команда в обоих скриптах взаимоисключающие. При варианте когда мало места и есть возможность хранить только один бэкап первая команда должна выполняться а последняя нет. В случае достаточного места под бэкапы первую команду не выполняем а в последней выставляем количество дней за которые хранятся бэкапы.
После создания скриптов сделаем их исполнительными выполнив необходимую команду:
chmod +x -R /backup/bin
Ошибка при выполнении mysqldump
Иногда вы можете увидеть ошибку при резервном копировании базы данных такого вида:
mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces
Ошибка говорит о том что данный пользователь не может получить доступ к созданию резервных копий у всех таблиц базы.
Исправить такое можно добавив к од следующий параметр:
Суть этой команды заключается в том что на момент бэкапа база остановится. Такой вариант меня не устраивает и мы дадим правильные права для пользователя базы данных (предварительно подключившись к базе данных):
= для случая когда доступ нужен снаружи =
GRANT ALL PRIVILEGES ON *.* TO 'пользователь бд'@'%';
= для случая когда доступ только с localhost =
GRANT ALL PRIVILEGES ON *.* TO 'пользователь бд'@'127.0.0.1';
= сохраним изменения =
FLUSH PRIVILEGES;
Добавление заданий в cron
Время в которое необходимо выполнять выбирайте на свое усмотрение. В большинстве случаев лучше использовать ночное время так как в это время сервера загружены минимально и можно использовать их ресурсы для выполнения своих внутренних задач.
Обязательно учитывайте время когда делается первый бэкап, так как дальнейшие копии сделанных бэкапов надо делать позже по времени для правильного мониторинга.
В случае если создается резервная копия для разных ресурсов выставляйте время с учетом времини которое необходимо для создания бэкапа.
Открываем необходимый файл и добавляем нужный код:
vim /etc/crontab
= необходимый код =
### Backup
# sevo44.ru
# ежедневно
20 1 * * * root /backup/bin/day-backup-sevo44.ru.sh >/dev/null 2>&1
# ежемесячно 1-го числа
25 1 1 * * root /backup/bin/month-backup-sevo44.ru.sh >/dev/null 2>&1
Согласно команде каждый день в 1:20 бедет выполнятся скрипт для создания ежедневного бэкапа и ежемесячно первого числа в 1:25 будет создаваться ежемесячная резервная копия.
Проверка создания бэкапов
Убедится что все работает правильно можно только запустив скрипт у посмотреть результат его работы.
Мне больше нравится брать код непосредственно из файла crontab, так как это последнее место которое выявит ошибки связаные с правильностью написания пути к скрипту.
=== Выводим на укран всё что есть заданиях ===
cat /etc/crontab
= часть вывода =
20 1 * * * root /backup/bin/day-backup-sevo44.ru.sh >/dev/null 2>&1
=== Копируем выделеный код и выполняем в консоли ===
/backup/bin/day-backup-sevo44.ru.sh
= часть вывода =
...
/var/www/sevo44.ru/www/modules/mod_syndicate/tmpl/
/var/www/sevo44.ru/www/modules/mod_syndicate/tmpl/default.php
/var/www/sevo44.ru/www/modules/mod_syndicate/mod_syndicate.xml
/var/www/sevo44.ru/www/modules/mod_syndicate/helper.php
/var/www/sevo44.ru/www/LICENSE.txt
-- Connecting to localhost...
-- Retrieving table structure for table oxsht_assets...
-- Sending SELECT query...
-- Retrieving rows...
...
-- Disconnecting from localhost...
Посмотреть результат работы cron можно заглянув в файл:
Для безопасности можно создать пользователя на ресурсе откуда забираете данные и ограничить его только в папке откуда забираем резервные копии.
Создание скрипта для выполнения rsync
Создадим необходимый скрипт:
vim /backup/bin/rsync-lemp.sevo44.ru.sh
= необходимый код =
#!/bin/bash
# Записываем информацию в лог о начале
#echo "`date +"%Y-%m-%d_%H-%M-%S"` Start rsync lemp.sevo44.ru" >> /var/log/rsync-lemp.sevo44.ru.log
# Копирование бэкапов с lemp.sevo44.ru
/usr/bin/rsync -avzhe "ssh -p 25555" root@192.168.0.33:/backup/ /backup/lemp.sevo44.ru
# Зеркало бэкапов с lemp.sevo44.ru
#/usr/bin/rsync --delete -avzhe "ssh -p 25555" root@192.168.0.33:/backup/ /backup/lemp.sevo44.ru
# Записываем информацию в лог о конце
#echo "`date +"%Y-%m-%d_%H-%M-%S"` End rsync lemp.sevo44.ru" >> /var/log/rsync-lemp.sevo44.loc.log
# Удаляем архивы старше 15-ти дней если не использовать параметр --delete
#
/usr/bin/find /backup/lemp.sevo44.ru/sevo44.ru/day -type f -mtime +15 -exec rm {} \;
Скрипт задокументирован и выберите параметры исходя из ваших требований.
Расшифрую параметры указанные в коде:
a — режиме архива;
v — увеличение детализации;
z — сжатие данных файла во время передачи;
h — вывод чисел в удобочитаемом формате;
e — используем ssh подключение.
После создания скриптов сделаем их исполнительными выполнив необходимую команду:
chmod +x -R /backup/bin
Добавление задания в cron
Обязательно учитывайте время когда делается первый бэкап, так как дальнейшие копии сделанных бэкапов надо делать позже по времени для избегания путаницы и правильного мониторинга.
В случае если создается резервная копия для разных ресурсов выставляйте время с учетом времени которое необходимо для создания бэкапа.
Открываем необходимый файл и добавляем нужный код:
Согласно команде каждый день в 6:30 будет выполнятся скрипт который будет забирать резервные копии согласно вашим пожеланиям.
Дальнейшие проверки аналогичны действиям указанным в разделе выше.
В случае вывода ошибки при выполнении скрипта:
Unexpected remote arg: root@192.168.0.33:/backup/
rsync error: syntax or usage error (code 1) at main.c(1343) [sender=3.1.2]
Смотрите правильность указания всех путей, параметров. Для вывода справки выполните в консоли команду rsync —help .
Использование Yndex.Disk для backups
При регистрации домена мне нравится переводить его управление на Yandex. Для бэкапов создаю отдельный почтовый ящик на домене и туда копирую бэкапы сайта. Удобно передавать заказчику управление доменом и резервные копии в одном месте.
Yandex.Disk дает возможность подключится с помощью WebDav. Необходимо добавить пакет davfs2 для работы по WebDav.
К сожалению на данный момент невозможно передавать данные большого размера по WebDav на Yandex.
Вы можете установить на систему консольный клиент от Yandex и проводить резервное копирование с помощью его.
Более подробно с описанием сервиса Yandex Disk вы можете ознакомиться перейдя в раздел техподдержки Яндекса.
Установка Davfs2
Рассмотрим настройку на примере системы CentOS 7.
Подключим репозиторий Еpel:
yum -y install epel-release
Установим пакет davfs2:
yum -y install davfs2
Настройка WebDav для Yandex.Disk
Создадим папку куда будем монтировать:
mkdir /backup/mnt/ydisk-sevo44.ru-backups
Чтобы не путаться в конце я указываю логин почты на котором находиться диск.
Смонтируем Yandex.Disk в необходимую папку:
mount -t davfs https://webdav.yandex.ru /backup/mnt/ydisk-sevo44.ru-backups/
= вывод команды с необходимыми данными =
Please enter the username to authenticate with server
https://webdav.yandex.ru or hit enter for none.
Username: вводим логин
Please enter the password to authenticate user zeroxzed@yandex.ru with server
https://webdav.yandex.ru or hit enter for none.
Password: вводим пароль
/sbin/mount.davfs: Warning: can't write entry into mtab, but will mount the file system anyway
Диск смонтировался в указанную папку.
Отмантировать диск можно командой:
umount /backup/mnt/ydisk-sevo44.ru-backups/
Введение вручную данных при монтировании не всегда удобно и для удобства мы автоматизируем этот процесс.
Отредактируем файл /etc/davfs2/secrets, добавив в конец строку с данными для авторизации:
vim /etc/davfs2/secrets
= необходимые данные для добавления =
# путь монитрования - почтовый ящик - пароль
/backup/mnt/ydisk-sevo44.ru-backups/ backups@sevo44.ru password
Так мы можем задать любое количество строчек с необходимыми ресурсами Yandex.Disk.
В случае если вы хотите чтобы диск монтировался при перезагрузке системы то в etc/fstab необходимо добавить строчку:
mcedit /etc/fstab
= необходимые данные для добавления =
https://webdav.yandex.ru /backup/mnt/ydisk-sevo44.ru-backups davfs rw,user,_netdev 0 0
# обязательно переход на новую строку
Теперь при перезагрузке сервера диск автоматически монтируется.
Не советую использовать монитрование через fstab, так как в случае обрыва связи копии не будут копироваться.
Можно конечно настроить механизм который будет окнтролировать это подключение и поднимать его в случае обрыва, но мне это кажется ненужным усложнением.
Создание скрипта для работы с Yandex.Disk
Создалим скрипт для выполнения копирования резервных копий на Yandex.Disk:
vim /backup/bin/ydisk-sevo44.ru-backups.sh
= необходимые данные =
#!/bin/sh
# Монтируем Yandex.Disk
mount -t davfs https://webdav.yandex.ru /backup/mnt/ydisk-sevo44.ru-backups/
# Создание зеркала ежедневных архивов
rsync -avzh --delete /backup/sevo44.ru/day /backup/mnt/ydisk-sevo44.ru-backups/
# Копирование резервных копий
#rsync -avzh /backup/sevo44.ru/day /backup/mnt/ydisk-sevo44.ru-backups/
# Удаляем копии старше 10 дней при использовани копирования
#/usr/bin/find $bk_dir -type f -mtime +30 -exec rm {} \;
# Отмонтирует Yandex.Disk
umount /backup/mnt/ydisk-sevo44.ru-backups/
# Очищения кэш davfs2
find /var/cache/davfs2/ -mindepth 1 -a -print0 | xargs -n 100 -0 rm -rf
Скрипт выполнит следующие действия:
Смонтирует удаленный Yandex.Disk;
Сделает зеркало с папки /backup/sevo44.ru/day;
Отмонтирует Yandex.Disk;
Очистит кэш создаваемый при работе davfs2.
Очищать кэш созданный при работе davfs2 надо обязательно иначе место на диске быстро закончиться.
После создания скриптов дадим необходимые права для всех файлов в папке backup:
chmod +x -R /backup/bin
Добавление задания в cron
Откроем для редактирования /etc/crontab файл откуда выполнятся задания:
vim /etc/crontab
= необходимые данные для добавления =
# sevo44.ru backup to Ydisk.Disk
# Каждый день в 6:30 запускается ежедневный backup
30 6 * * * root /root/backup/sevo44.ru/day.sh >/dev/null 2>&1
Перезагрузим cron в системе CentOS 7 для применения изминений:
systemctl restart crond
Проверки осуществляем по аналогии с предыдущими главами.
Заключение
Постарался описать максимально понятно все варианты которые я использую при создании резервных копий данных сайтов. В случае если вы найдете ошибки или знаете как можно улучшить данные примеры пожалуйста напишите в комментариях к статье.
Рассмотрим установку системы CentOS 8 и последующую настройку исходя из практики использования этой операционной системы. Данная система для меня является основной для использования на серверах. Стабильность работы гарантированна. Поддержка до 2029 года.
Введение
В данной статье собраны все основные моменты базовой настройки сервера CentOS 8 которые использую на практике.
Установка CentOS 8
Создания USB носителя для установки
Существует множество программ для записи iso образа на устройство. Например, у меня два варианта для создания носителя для установки:
Rufus — использую эту программа для создание загрузочных USB-дисков в системе Windows;
ROSA ImageWriter — использую эту программу для любой системы Linux.
Варианты установки
Рассмотрим два самых популярных варианта установки СentOS 8.
Образы iso CentOS 8
Образы можно скачать c зеркала Yandex по ссылке Download CentOS. Существует два варианта:
CentOS-8-x86_64-1905-dvd1.iso — полный образ 7G;
CentOS-8-x86_64-1905-boot.iso — загрузочный образ 550M.
Какой вариант использовать решать вам. Например, мне нравится устанавливать загрузочный образ и дальше настраивать руками, так и опыт приходит и понимаешь как что работает.
Больше нет минимального образа, но радует что есть загрузочный при установке с которого надо только руками внести требуемый репозиторий и выбрать нужные параметры установки.
Указывать надо путь к той папке, где лежит каталог repodata. Например, mirror.yandex.ru/centos/8/BaseOS/x86_64/os/.
В выборе программ выбираем базовое окружение «Минимальная установка» а в дополнительных параметрах «Гостевые агенты» и «Стандарт».
Шаблоны
Шаблоны используются как правило для установки на VDS и предоставляются компаниями предоставляющие такие услуги. Удобно, но тем не менее я пару раз попадал в дурацкие ситуации.
Вот моменты почему я советую использовать установку на VDS систем с iso образа:
Разбивка диска порой не учитывает конфигурацию тарифа или требований вашей системы — например, на одном хостинге при 2 G оперативной памяти был создал SWAP раздел в 512 М в результате пришлось переустанавливать систему дабы не терять место на и так небольшом диске;
Локализация как правило Английская — мне приятней работать на своем родном языке хотя и на английском если надо всё настрою;
Присутствие в шаблоне каких-то изменений отличающихся от стандартных минимальных параметров установки — порой не понимаешь откуда взялись какие то настройки которых раньше не видел. Кроме того, можно потратить кучу времени не понимая почему не работает то что всегда работало как часы. В итоге выясняется что в шаблоне установки нет пакета который всегда ставился в стандартном минимальном образе.
Все компании предоставляющие услуги VDS могут предоставить возможность установки системы с ISO образа системы. При установке надо правильно указать сетевые параметры исходя из предоставленных сетевых параметров настроек выбранного тарифа!
Разбивка диска для установки
Вариантов разбивки диска для CentOS 8 может быть множество исходя из пожеланий и предпочтений. Например, мне нравиться придерживаться таких параметров:
Размер диска под систему Linux 50 G — этого мне хватает с запасом;
Создаю раздел boot размером 1 G — так я гарантирую что при заполнении диска система загрузится однозначно;
Создаю SWAP — согласно требованиям системы.
Можно выносить логи и кэш в отдельные разделы, но это лишняя трата времени. Лучше всегда выполнять мониторинг размера диска и в случае проблем оперативно принять необходимые меры. Прежде всего, так и головная боль пропадает о том какой размер указывать разделам ( вариант с перераспределением очень сюрпризная тема) и больше времени потратится на правильную настройку сервера.
SWAP
Тема организации SWAP на сервере очень важная и поэтому я описал все основные моменты использования в статье SWAP для Linux
Настройка CentOS 8
Пакетный менеджер DNF
Используется новый менеджер пакетов который поддерживает модульный формат пакетов.
По прежнему можно вносить команды yum вместо dnf и всё будет работать. Для yum сделан алиас для запуска dnf.
Для вывода всей информации о том какие команды можно использовать достаточно внести в консоли команду dnf и увидеть полный список возможностей.
dnf
= вывод части команды =
usage: dnf [options] COMMAND
Список основных команд:
alias List or create command aliases
autoremove удалить все ненужные пакеты, первоначально установленные по зависимостям
check поиск проблем в packagedb
check-update проверить доступные обновления для пакетов
clean удалить кэшированные данные
deplist Показывать список зависимостей пакета и какие пакеты их предоставляют
distro-sync обновить установленные пакеты до последних имеющихся версий
downgrade Откат к предыдущей версии пакета
group показать или использовать информацию о группах
help отобразить подсказку по использованию
history отобразить (или использовать) историю транзакций
info отобразить информацию о пакете или группе пакетов
install установка пакета(ов) в систему
list вывести список пакетов или групп пакетов
makecache создание кэша метаданных
mark отметить или снять отметку пользовательской установки с установленных пакетов.
module Взаимодействие с репозиторием Modules.
provides найти пакет по заданному значению
reinstall переустановка пакета
remove удалить пакет или пакеты из системы
repolist отобразить настроенные репозитории ПО
repoquery поиск пакетов по ключевому слову
repository-packages выполнить команды над всеми пакетами заданного репозитория
search поиск информации о пакете по заданной строке
shell запустить интерактивную оболочку DNF
swap запустить интерактивный вариант dnf для удаления и установки одной спецификации
updateinfo показать рекомендации к пакетам
upgrade обновить пакет или пакеты в системе
upgrade-minimal обновление, но только «новейших» пакетов, которые исправляют проблему в вашей системе
Информация об установленной системе
Узнать какая система установлена на сервере можно следующей командой:
uname -a
= вывод команды =
Linux localhost.localdomain 4.18.0-80.11.2.el8_0.x86_64 #1 SMP Tue Sep 24 11:32:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Этой информации достаточно для понимания с какой системой предстоит работать.
Отключение SELinux
Отключаем SELinux. Его использование и настройка в системе CentOS отдельный разговор.
vi /etc/sysconfig/selinux
= меняем значение =
SELINUX=disabled
Перезагрузим для применения изменений. После перезагрузки проверяем статус:
sestatus
= вывод команды =
SELinux status: disabled
Надо иметь четкое понимание что SELinux система требующая хорошего понимания в том как она работает и как настраивать. Надо или отключить сразу или потратить время на изучение как она работает.
Добавление репозиториев
Для инсталляции различного софта необходимо подключить репозитории в CentOS 8. Со временем пришло понимание того что относится к добавляемым репозиториям надо очень внимательно, чтобы в последствии не возникало проблем при обслуживании.
Всегда подключаю самый популярный репозиторий Epel (Extra Packages for Enterprise Linux). Epel хранилище пакетов, созданное группой специалистов операционной системы Fedora. Пакеты из Epel репозитория никогда не конфликтуют и не переустанавливают базовые пакеты RHEL.
dnf -y install epel-release
Старюсь подключать репозитории которые поддерживают сами разработчики программ. Например, такие как Nginx, Zabbix, MariaDB.
Обновление CentOS 8
Обновление системы очень важный момент и следует относится к нему очень внимательно. Всегда проще найти проблему когда проходит немного обновлений.
Прежде всего, всегда перед обновлениями делайте резервные копии!
Перед выполнением настройки лучше выполнить полное обновление системы:
dnf update
Автоматическое обновление системы
Для безопасности сервера его необходимо своевременно обновлять. Вариантов обновления CentOS 8 несколько и это тема отдельного длинного разговора.
Например, получать сообщения на почту об появившихся обновлениях и уже на основании этого принимать решение о необходимости обновления — для меня лучший вариант.
При моих пожеланиях мне подойдёт утилита dnf-automatic. Ставится она из базового репозитория командой:
dnf install dnf-automatic
Управлением запуском по расписанию занимается systemd со своим встроенным планировщиком. Посмотреть таймеры автоматического запуска можно командой:
systemctl list-timers *dnf-*
= вывод команды =
NEXT LEFT LAST PASSED UNIT ACTIVATES
Thu 2019-10-24 14:36:56 MSK 5min left n/a n/a dnf-makecache.timer dnf-makecache.service
Посмотрим настройки этого таймера выполнив команду:
cat /etc/systemd/system/multi-user.target.wants/dnf-makecache.timer
= вывод команды =
[Unit]
Description=dnf makecache --timer
ConditionKernelCommandLine=!rd.live.image
# See comment in dnf-makecache.service
ConditionPathExists=!/run/ostree-booted
Wants=network-online.target
[Timer]
OnBootSec=10min
OnUnitInactiveSec=1h
Unit=dnf-makecache.service
[Install]
WantedBy=multi-user.target
Если заданий нет, то можно добавить таймер выполнив команду:
systemctl enable --now dnf-automatic.timer
Настройка этого таймера будет по пути — /etc/systemd/system/multi-user.target.wants/dnf-automatic.timer.
Настройка системы автоматического обновления находится по пути /etc/dnf/automatic.conf. По-умолчанию он только скачивает обновления, и отправляет сообщение на почту root.
Самый важный параметр это update_type — которой будет говорить системе какие выполнять обновления. Доступно несколько вариантов:
default — полное обновление;
security — только обновление безопасности.
Мой вариант настройки выглядит следующим образом:
vim /etc/dnf/automatic.conf
= часть вывода с пояснениями
[commands]
# What kind of upgrade to perform:
# default = all available upgrades
# security = only the security upgrades
upgrade_type = security
random_sleep = 0
# To just receive updates use dnf-automatic-notifyonly.timer
# Whether updates should be downloaded when they are available, by
# dnf-automatic.timer. notifyonly.timer, download.timer and
# install.timer override this setting.
download_updates = yes
# Whether updates should be applied when they are available, by
# dnf-automatic.timer. notifyonly.timer, download.timer and
# install.timer override this setting.
apply_updates = no
Согласно этих параметров будут скачаны все обновления безопасности и будет отправлено сообщение пользователю root.
В настройках можно настроить отправку почты на другой почтовый ящик, но мне больше нравится вариант когда все сообщения пользователя root пересылаются на мой почтовый ящик.
Популярные и полезные утилиты
Установим в начале основные популярные утилиты которые обычно требуются в работе.
net-tools bind-utils — сетевые утилиты после установки которых будут работать команды # ifconfig и # nslookup,
htop atop — два интересных диспетчера задач,
iftop — показывает в режиме реального времени загрузку сетевого интерфейса,
lsof — вывода информации о том, какие файлы используются теми или иными процессами,
wget — неинтерактивная консольная программа для загрузки файлов по сети,
bzip2 — утилита командной строки с открытым исходным кодом для сжатия данных,
traceroute — утилита предназначенная для определения маршрутов следования данных в сетях TCP/IP,
gdisk — умеет работать с GPT-дисками разработано по подобию fdisk,
yum-utils — — это набор утилит для управления репозиторием, установки и отладки пакетов, поиска пакетов и много другого.
Отправка почты с авторизацией на другом SMTP сервере
Настраиваем на базе Postfix.
Проверка статуса:
systemctl status postfix
Если Postfix не установлен то производим установку выполнив команду:
dnf install postfix
Запускаем и добавляем в автозагрузку командами:
systemctl start postfix
systemctl enable postfix
Чтобы отправлять письма с консоли необходимо установить пакет mailx:
dnf install mailx
После этого можно отправлять с консоли сервера сообщения на свою почту:
uname -a | mail -s "info server" info@sevo44.ru
В результате на почту придёт сообщение:
Мы не уверены в подлинности отправителя этого письма. Возможно, данные были подменены.
Отправитель: vds-micro2.sevo44.ru
Подпись: Нет
Шифрование: Нет
Из за выше сказанного сообщение может попасть в спам, либо вообще не будет принято сервером получателя, потому что на сервере нет корректных настроек для отправки почты. Чтобы почта корректно отправлялась, надо воспользоваться внешним почтовым сервером.
Например, мне удобно в данном случае везде использовать почту noreply@sevo44.ru которая обслуживается Yandex.
Переименуем дефолтный конфигурационный файл Postfix. После этого, создадим рабочий и добавим необходимые настройки:
mv /etc/postfix/main.cf /etc/postfix/main.cf_orig
vim /etc/postfix/main.cf
= необходимый код =
# DEFAULT CONFIG
compatibility_level = 2
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
mail_owner = postfix
# Имя сервера, которое выводит команда hostname
myhostname = vds-micro2.sevo44.ru
# По логике нужно оставлять только домен, но в данном случае лучше оставить полное имя сервера, чтобы в поле отправитель
# фигурировало полное имя сервера, так удобнее разбирать служебные сообщения
mydomain = vds-micro2.sevo44.ru
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain, localhost
inet_interfaces = localhost
inet_protocols = all
unknown_local_recipient_reject_code = 550
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
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/samples
readme_directory = /usr/share/doc/postfix/README_FILES
smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
smtpd_tls_security_level = may
smtp_tls_CApath = /etc/pki/tls/certs
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
meta_directory = /etc/postfix
shlib_directory = /usr/lib64/postfix
# SMTP YANDEX CONFIG
relayhost = smtp.yandex.ru:587
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
# База параметров авторизации с SMPT
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
# Беза подмены имени почтового ящика
smtp_generic_maps = hash:/etc/postfix/generic
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = may
Создаем файл с информацией об имени пользователя и пароле для авторизации на сервере SMTP:
vim /etc/postfix/sasl_passwd
= необходимый код =
smtp.yandex.ru:587 noreply@sevo44.ru:PASSWORD
Создаем db файл:
postmap /etc/postfix/sasl_passwd
Для того чтобы почта уходила надо чтобы адрес отправителя а адрес авторизации на сервер smtp совпадал!
В случае если у нас имеется сайт отправляющий почту средствами PHP можно настроить корректную отправку почты. Например, добавим параметр для сайта crystalium44.ru.
Переименуем дефолтную базу подмены имени почтового ящика. После этого, создадим рабочий и добавим необходимые настройки:
mv /etc/postfix/generic /etc/postfix/generic_orig
vim /etc/postfix/generic
= необходимый код =
root@vds-micro2.sevo44.ru noreply@sevo44.ru
crystalium44.ru@php7-lxc-vds-micro2.sevo44.ru noreply@sevo44.ru
Создаем db файл:
postmap /etc/postfix/generic
При получении ошибки «warning: SASL authentication failure: No worthy mechs found» Необходимо установить еще несколько пакетов для работы SASL!
Отправитель письма подтверждён и проверен Спамообороной Яндекса.
Отправитель: sevo44.ru
Подпись: sevo44.ru
Шифрование: Да
Так выглядит письмо отправленное с сайта crystalium44.ru c помощью PHP:
Как видим теперь всё работает как надо!
В случае ошибок проверяем почтовый лог выполнив команду:
tail -n 10 /var/log/maillog
В заключение, осталось добавить к стандартному алиасу для root в /etc/aliases, внешний адрес, куда будет дублироваться почта, адресованная root. Для этого редактируем указанный файл, изменяя последнюю строку:
vim /etc/aliases
= необходимо привести к виду =
# Person who should get root's mail
root: root,info@sevo44.ru
Обновляем базу сертификатов:
newaliases
Настройка времени
Определим текущее время на сервере:
date
= вывод команды =
Ср ноя 14 12:17:34 CET 2018
Как видим временная зона не настроена.
Выполним необходимую настройку временной зоны Europe — Moscow:
= Сделать резервную копию текущей timezone =
mv /etc/localtime /etc/localtime.bak
= В папке /usr/share/zoneinfo/ ищем что надо и делаем ссылку =
ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime
В итоге получим:
date
= вывод команды =
Сб окт 13 02:59:46 MSK 2018
Можно использовать одну команду зная точно что эта временная зона присутствует в настройках:
timedatectl set-timezone Europe/Moscow
Синхронизация времени
В CentOS 8 по-умолчанию используется утилита для синхронизации времени chrony. Если у вас её нет, то устанавливайте:
dnf install chrony
Запускаем chrony и добавляем в автозагрузку:
systemctl start chronyd
systemctl enable chronyd
Проверяем правильность работы:
systemctl status chronyd
= вывод команды =
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since Ср 2018-10-03 21:55:18 MSK; 27min ago
Docs: man:chronyd(8)
man:chrony.conf(5)
Main PID: 631 (chronyd)
CGroup: /system.slice/chronyd.service
└─631 /usr/sbin/chronyd
окт 03 21:55:17 lemp.sevo44.loc systemd[1]: Starting NTP client/server...
окт 03 21:55:17 lemp.sevo44.loc chronyd[631]: chronyd version 3.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SECHASH +SIGND +ASYNCDNS +IPV6 +DEBUG)
окт 03 21:55:17 lemp.sevo44.loc chronyd[631]: Frequency 1.141 +/- 1.440 ppm read from /var/lib/chrony/drift
окт 03 21:55:18 lemp.sevo44.loc systemd[1]: Started NTP client/server.
окт 03 21:55:35 lemp.sevo44.loc chronyd[631]: Selected source 89.109.251.23
окт 03 21:55:35 lemp.sevo44.loc chronyd[631]: System clock wrong by 1.035954 seconds, adjustment started
окт 03 21:55:36 lemp.sevo44.loc chronyd[631]: System clock was stepped by 1.035954 seconds
Сетевые параметры
При установке CentOS 8 уделяю особое внимание настройки сетевых параметров. Кроме того, на странице настройки сетевых параметров указывается название хоста.
Всегда отключаю ipv6 так как в большинстве случаев он не используется а вот проблемы при работе с системой может создать.
Для управления сетевыми настройками в CentOS 8 после установки можно воспользоваться графической утилитой nmtui:
nmtui
= вывод команды =
-bash: nmtui: команда не найдена
= команда установки необходимого пакета для работы nmtui =
yum install NetworkManager-tui
В CentOS 8, сеть управляется только через Network Manager. Сетевые настройки лучше выполнять с помощью утилиты nmtui.
Руками вся настройка сводится к редактированию файлов в паке /etc/sysconfig/network-scripts/. Для определения интерфейсов необходимо предварительно выполнить команду ip addr которая покажет название всех имеющихся интерфейсов.
Например, мой файл настройки сетевого интерфейса ens18:
Для применения изменений необходимо перезагрузить Network Manager выполнив команду:
= или командой =
systemctl restart NetworkManager
= предварительно поняв название необходимого сервиса =
systemctl list-units | grep -i network
Смена пароля root
Смена пароля производится командой:
passwd
= вывод команды =
Изменяется пароль пользователя root.
Новый пароль :
Повторите ввод нового пароля :
passwd: все данные аутентификации успешно обновлены.
Брандмауэр FirewallD
По умолчанию в системе CentOS 8 используется брандмауэр FirewallD.
Ниже я выполню необходимые действия не описывая всё подробно.
Вывод информации об активных зонах:
firewall-cmd --get-active-zones
= вывод команды =
public
interfaces: ens18
Выведем информацию о конкретной зоне:
firewall-cmd --list-all --zone=public
= вывод команды =
public (active)
target: default
icmp-block-inversion: no
interfaces: ens18
sources:
services: cockpit ssh dhcpv6-client
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
Для безопасности порт ssh лучше поменять на нестандартный.
Добавим разрешение подключаться по этому порту:
firewall-cmd --permanent --zone=public --add-port=25555/tcp
= вывод команды =
success
Кроме того, сразу удалим ненужный сервис:
firewall-cmd --permanent --zone=public --remove-service=dhcpv6-client
= вывод команды =
success
Применим изменения и посмотрим результат сделанных действий:
firewall-cmd --reload
= вывод команды =
success
firewall-cmd --list-all --zone=public
= вывод команды =
public (active)
target: default
icmp-block-inversion: no
interfaces: ens18
sources:
services: cockpit ssh
ports: 25555/tcp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
Только после настройки ssh для работы по новому порту удаляйте сервис ssh из FirewallD! Иначе в случае ошибки настройки можете потерять доступ к серверу.
Смена порта SSH
Укажем порт в настройках ssh открыв конфигурационный файл командой:
vi /etc/ssh/sshd_config
= необходимые изменения =
Раскоментируем строку Port 22 и заменим на наш 25555
Перезапускаем сервис ssh командой:
systemctl restart sshd
Проверяем какой порт слушает sshd (для работы нужен установленный пакет net-tools):
Подключение производится с указанием необходимого порта командой:
ssh -p 25555 root@193.124.180.195
Авторизация SSH по ключу
Вводить каждый раз пароль не удобно да и не помешает добавить безопасности.
После настройки можно отключить в параметрах ssh авторизацию по паролю, но иногда подключение по паролю просто необходимо. Обычно я создаю 16 злачный пароль и меняю его если давал временный доступ специалистам любого уровня и моего доверия. Безопасность лишней не бывает!
Установим самый популярный файловых менеджеров с текстовым интерфейсом командой:
dnf -y install mc
Включаем подсветку синтаксиса всех файлов, которые не обозначены явно в файле /usr/share/mc/syntax/Syntax. Этот универсальный синтаксис подходит для конфигурационных файлов, с которыми чаще всего приходится работать на сервере. Именно этот шаблон будет применяться к .conf и .cf файлам, так как к ним явно не привязано никакого синтаксиса. Перезаписываем файл unknown.syntax:
cp /usr/share/mc/syntax/sh.syntax /usr/share/mc/syntax/unknown.syntax
= вывод команды =
cp: переписать «/usr/share/mc/syntax/unknown.syntax»? y
В случае отказа от использования встроенного редактора MC необходимо в настройках «Настройки — Конфигурация» снять галки у параметров «Встроенный редактор» и «Встроенный просмотр»
Установка редактора Vim
По умолчанию в системе работает редактор vim и это вполне оправдано.
Обоснование использования редактора VIM и как с ним работать можно в статье Vim текстовый редактор
В случае отсутствия редактора его можно установить без вопросов командой:
dnf -y install vim
Отображение приглашения в консоли bash
При появлении большого количества серверов на обслуживании я сразу столкнулся с плохой информативностью о том с каким я сервером работаю.
Стандартный вариант отображения приветствия после установки CentOS 8:
[root@vds-micro ~]#
В представленном виде при работе одновременно с разными серверами я путался и порой выполнял команды не там где надо. Изменение цвета приглашения, вывода полного имени машины и пути где мы находимся позволило мне избежать таких ошибок.
Выведем имеющиеся параметры:
echo $PS1
= вывод команды =
[\u@\h \W]\$
Изменим для текущей сессии:
export PS1='\[\033[01;31m\]\u@\H\[\033[01;34m\] \w \$\[\033[00m\] '
= в результате =
root@vds-micro.sevo44.ru ~ #
Для постоянного применения настроек необходимо в папке пользователя в файл .bashrc добавить необходимый код:
vim .bashrc
= необходимые дополнения =
# Приветствие bash
PS1='\[\033[01;31m\]\u@\H\[\033[01;34m\] \w \$\[\033[00m\] '
Для применения подобных настроек для всех пользователей с обычными правами сделаем приглашение зеленым. Добавим необходимые параметры в имеющийся файл или создадим новый и добавим туда необходимые параметры:
vim /etc/profile.d/bash_completion.sh
= необходимое дополнение =
# Вид bash
PS1='\[\033[01;32m\]\u@\H\[\033[01;34m\] \w \$\[\033[00m\] '
В итоге я получил следующее:
root@vds-micro.sevo44.ru/etc # = права root
root@vds-micro.sevo44.ru/etc # = простой пользователь
Список последних выполненных команд хранится в домашней директории пользователя в файле .bash_history (в начале точка). Его можно открыть любым редактором и посмотреть.
По умолчанию вывод команды history в консоли нам покажет:
history
= вывод команды =
1 yum update
2 reboot
3 htop
4 df -h
Как видим вывод не информативный. Кроме того, покажет только последние 1000 команд.
Быстро найти конкретную команду, можно с помощью фильтрации только нужных строк, например вот так:
history | grep yum
Изменим эту ситуацию добавив в файл .bashrc находящийся в папке пользователя необходимые параметры:
Можно применить эту настройку для всех пользователей указав параметр в файле /etc/profile.d/bash_completion.sh.
В таком варианте получаем гораздо большую информативность.
Установка Tmux
Установим пожалуй один из самых необходимых и удобных программ для удаленной работы с сервером. Tmux терминальный оконный менеджер при использовании дает возможность при обрыве связи с сервером по ssh не терять информацию о выполняемых действиях.
Cockpit: Веб-интерфейс управления сервером CentOS 8
Возможность видеть наглядно все основные параметры системы и иметь возможность ими управлять пожалуй самая приятна новость которая меня порадовала в выпуске CentOS 8.
При авторизации по ssh вы увидите следующее сообщение:
Activate the web console with: systemctl enable --now cockpit.socket
Достаточно выполнить команду в консоли systemctl enable —now cockpit.socket и при следующей авторизации вы увидите следующее сообщение:
Web console: https://localhost:9090/ or https://192.168.0.252:9090/
Порт 9090 должен быть открыт. Работающий по умолчанию сервис cockpit в FirewallD открывает этот порт.
При вводе в браузере https://192.168.0.252:9090 увидите приглашение ввести данные авторизации.
После входа вы увидите главную страницу с выводом графиков нагрузки основных параметров сервера.
Далеко не все конечно можно видеть и настраивать в этой панели но определенное удобство есть явно. Пользоваться панелью просто, понятно и не вызывает никаких сюрпризов, так что описывать по большому счету нечего. Попробуйте и вы сами всё поймете.
Единственное что я делаю это то что не держу её включенной. Убираю из автозагрузки в самой панели управления или командой:
systemctl disable cockpit.socket
В случае необходимости мне не сложно включить при необходимости и отключить после использования следующими командами:
В результате я получил статью в которой свёл в одно место все основные моменты которые я на практике использую при базовой настройке сервера CentOS 8. Возможно что-то сказано с ошибками или можно улучшить. Комментируйте и советуйте я всегда рад обратной связи с пользователями систем Linux.
ZFS мониторинг файловой системы с помощью системы Zabbix. Контроль состояния происходит с учетом значения DEGRADED появляющегося в выводе статуса ZFS при ошибках с дисками. Своевременно полученная информация может избавить от серьезных проблем.
Введение
Не представляю как можно спокойно жить системному администратору без тотального контроля файловых систем. Например, для меня чем больше механизмов меня оповестят о проблемах дисков тем лучше. К сожалению жесткий диск может выйти из строя в любой момент и это не зависит от того дорогой он или дешевый.
В этой статье вы узнаете как с помощью системы Zabbix можно держать под контролем все имеющие диски в файловой системе ZFS.
Схема действий для мониторинга параметра будет следующей:
Создаем скрипт bach который будет записывать нужное значение в текстовый файл;
Добавляем в cron задание которое будет с нужной нам периодичностью записывать показания в текстовый файл;
Добавляем необходимые параметры в агент Zabbix и проверяем правильность работы;
На сервере Zabbix для нужного узла добавляем все необходимые данные для контроля над параметром и настраиваем оповещение в случае плохих параметров.
Действия на Zabbix агенте
Команда для вывода нужных параметров ZFS
Выведем состояние zfs:
zpool status
= вывод команды =
pool: rpool
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-ST3120811AS_5PT00YS1-part3 ONLINE 0 0 0
ata-ST3120811AS_5PT00DRP-part3 ONLINE 0 0 0
errors: No known data errors
Из вывода видно что имеются 2 диска сделанные в зеркале.
ZFS мониторинг будет основываться на появлении сообщения DEGRADED. Выполним команду которая проверит наличие этого сообщение:
/sbin/zpool status | grep DEGRADED | wc -l
= вывод команды =
0
При отсутствии значения DEGRADED выводится сообщение 0. При наличии значения выведется число соответствующее количеству встречающихся значений.
Отключим диск и подождав немного запросим статус ZFS:
zpool status
= вывод команды =
pool: rpool
state: DEGRADED
status: One or more devices has been removed by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
scan: none requested
config:
NAME STATE READ WRITE CKSUM
rpool DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
ata-ST3120811AS_5PT00YS1-part3 REMOVED 0 0 0
ata-ST3120811AS_5PT00DRP-part3 ONLINE 0 0 0
errors: No known data errors
Видим что у одного из дисков появилось значение REMOVED и параметр DEGRADED встречается 3 раза.
Проверим правильность выполняемой команды:
/sbin/zpool status | grep DEGRADED | wc -l
= вывод команды =
3
Всё правильно.
Создадим папку и в ней скрипт bash который будем запускать в cron для записи значения в текстовый файл.
mkdir /etc/zabbix/scripts
vim /etc/zabbix/scripts/zfs_degraded-bin.sh
= необходимый код =
#!/bin/bash
/sbin/zpool status | grep DEGRADED | wc -l > /etc/zabbix/scripts/zfs_degraded.txt
Сделаем скрипт исполнительным:
chmod +x /etc/zabbix/scripts/zfs_degraded-bin.sh
Произведем проверки. Запустим скрит, проверим создание текстового файла и информацию в нём. Выполнив по очереди 3 команды:
sh /etc/zabbix/scripts/zfs_degraded-bin.sh
= вывод пустой =
ls /etc/zabbix/scripts
= вывод команды =
zfs_degraded-bin.sh zfs_degraded.txt
cat /etc/zabbix/scripts/zfs_degraded.txt
= вывод команды =
3
Все работает как надо. Добавим задание в крон:
vim /etc/crontab
= необходимый код =
*/3 * * * * root /etc/zabbix/scripts/zfs_degraded-bin.sh >/dev/null 2>&1
Каждые 3 минуты в текстом фале будет обновляться информация.
Добавление параметров для Zabbix агента
Для того чтобы Zabbix агент мог работать с нашими параметрами необходимо добавить в файл настройки необходимый параметр.
vim /etc/zabbix/zabbix_agentd.conf
= необходимый параметр =
UnsafeUserParameters=1
После необходимого параметра добавляем нужный код. В моем случае получился следующий код:
Открываем необходимый узел и перейдя в «Элементы данных» добавляем новый нажав «Создать элемент данных«.
Необходимо заполнить следующие поля:
Имя — pve-1 degraded zfs;
Ключ — pve-1.zfs;
Тип информации — Числовой (целое положительное);
Интервал обновления — 5m;
Период хранения истории — 1w;
Группы элементов данных — Filesystem.
Добаление тригера
Открываем необходимый узел и перейдя в «Триггеры» добавляем новый нажав «Создать триггер«.
Необходимо заполнить следующие поля:
Имя триггера — pve-1 degraded zfs;
Выражение — {pve-1:pve-1.zfs.last()}>0.
Ждем немного времени и проверяем срабатывание триггера. В случае успешного срабатывания выключаем систему, подключаем диск назад и запускаем систему.
Cброс счетчиков ошибок ZFS
После того как мы подключили в диск в выводе статуса ZFS будет информация об ошибках. Например, в нашем случае мы знаем чем вызваны эти ошибки и разбираться в их причине не требуется.
Сбросить все ошибки в пуле мы можем следующей командой:
zpool clear rpool
Заключение
Возможно есть и другие варианты и подходы для мониторинга файловой системы ZFS и если вы знаете о них поделитесь информацией в комментариях.
Обслуживание компьютеров, ремонт, лечение вирусов, модернизация. Системы на ОС Linux. Создание и продвижение Интернет проектов. Бесплатные консультации. Офисные АТС. Видеонаблюдение.
