Шпаргалка на тему создания LVM Raid. Создаём RAID1.

# apt install lvm2
# pvcreate /dev/sdb /dev/sdc
# vgcreate vgroup /dev/sdb /dev/sdc
# lvcreate --type raid1 -l 100%FREE -n lvraid1 vgroup

Проверяем:

# lvs -o+segtype

Создаём файловую систему и монтируем:

# mkfs.ext4 /dev/vgroup/lvraid1
# mkdir /mnt/lvraid1
# mount /dev/vgroup/lvraid1 /mnt/lvraid1

Смотрим, что в итоге получилось:

# lsblk

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

# cp -r /var/log/* /mnt/lvraid1/

Диск отключил. Проверяю данные, всё на месте. То есть LV работает как и прежде. Проверяю статус:

# lvs -a -o name,devices vgroup

Вижу, что одно устройство в статусе [unknown]. Добавляю в систему новый диск. Не тот же самый, что я отключил.

# lsblk

Вижу, что он подключился на /dev/sdd. Добавляю его в VG:

# pvcreate /dev/sdd
# vgextend vgroup /dev/sdd

Удаляем вывалившийся диск:

# vgreduce --removemissing vgroup --force

Проверяем:

# lvs -a -o name,devices vgroup

Устройства в статусе [unknown] больше нет. Добавляем в наш LV новый диск:

# lvconvert --repair vgroup/lvraid1
# lvconvert -m1 vgroup/lvraid1 /dev/sdd

На все вопросы отвечаем утвердительно. Смотрим результат и наблюдаем за синхронизацией:

# lvs -a -o name,devices vgroup
# lvs -o+segtype

Пошла синхронизация, данные все на месте. Замена прошла без остановки системы. Диски убирал и добавлял наживую. В целом, ничего сложного. Вполне понятный и логичный набор команд. Один раз проверил, записал и воспроизвёл в случае выхода из строя диска.

Из особенностей LVM Raid - LV можно конвертировать налету в разные уровни рейдов, добавлять к ним диски. Можно из raid1 сделать raid5, добавить туда диски. Не думаю, что на практике это будет оправданно. А вот превратить raid1 в raid10 видится полезным. Было 2 диска, добавил ещё 2 и получил raid10. Для этого надо добавить 2 диска в VG и сконвертировать LV. Прямой конвертации из raid1 в raid10 нет. Нужно сначала сконвертировать в raid5, добавить туда 2 диска, дождаться синхронизации и сконвертировать в raid10:

# pvcreate /dev/sdc /dev/sde
# vgextend vgroup /dev/sdc /dev/sde
# lvconvert --type raid5_n vgroup/lvraid1
# lvresize -l5118 vgroup/lvraid1 # размер зависит от размера LV
# lvconvert --stripes 1 vgroup/lvraid1
# lvconvert --stripes 2 vgroup/lvraid1
# lvconvert --type raid10 vgroup/lvraid1
# lvconvert --type raid10 vgroup/lvraid1

На выходе получил из RAID1 ⇨ RAID10 без остановки и потери данных. Я по всем этим командам получал подсказки в консоли. Там и по размеру подсказки были, и по тому, что финальная конвертация проходит в 2 этапа, и что сначала надо в raid5_n сконвертировать.

Если делать с нуля RAID10, то команда простая. Сначала добавляем 4 одинаковых диска в VG, потом создаём LV:

# lvcreate --type raid10 -l 100%FREE -n lvraid10 vgroup

А теперь ради чего всё это затевалось. LVM Raid умеет вести контроль целостности файлов на основе хэшей. Реализуется это на базе технологии DM Integrity. Включаем её во время создания LV:

# lvcreate --type raid1 --raidintegrity y -L 9G -n lvraid1 vgroup

Размер нужно будет вычислять опытным путём. Я сначала указал размер 100% и получил ошибку, что для моих 10G дисков нужно 150 MiB под метаданные. В итоге указал 9G.

Если в VG есть свободное место, то добавить raidintegrity можно к существующему тому:

# lvconvert --raidintegrity y vgroup/lvraid1

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

Для каждого диска в составе LV с DM Integrity создаётся отдельный LV rimage для хранения метаданных. В нём можно посмотреть статистику по ошибкам:

# lvs -o+integritymismatches vgroup/lvraid1_rimage_0_imeta

Колонка IntegMismatches. Все события по DM Integrity будут в системном логе /var/log/syslog.

Всё, что я показал, подробно описано в руководстве по LVM от Red Hat.

#lvm #raid

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

Для этого взял виртуалку с Debian 12 и установил систему с ручным разбитием диска. Создал ровно один раздел /dev/sda1, на нём создал VG - vgroup и один LV - root на весь доступный объём. Больше не делал ничего. Раздел /boot не выносил отдельно. Всё только в корне. Grub уже давно умеет грузиться с LVM разделов.

Установил систему. Добавил туда ещё один диск /dev/sdb. Скопировал на него разметку с sda и добавил его в VG:

# sfdisk -d /dev/sda | sfdisk /dev/sdb
# pvcreate /dev/sdb1
# vgextend vgroup /dev/sdb1

Пробую сконвертировать корневой раздел в RAID1:

# lvconvert --type raid1 -m 1 vgroup/root

Получаю ошибку:

Insufficient free space: 1 extents needed, but only 0 available

Суть её в том, что при создании любого RAID необходимо создать отдельный малюсенький LV на 4 MiB для хранения метаданных массива. А я полностью весь VG во время установки отдал на LV root. Чтобы избежать этой ошибки, оставляйте во время установки немного места на VG.

Решить эту проблему не трудно. LV можно уменьшить вместе с ФС, если это ext4:

# lvreduce -l -1 --resizefs /dev/vgroup/root

Команда сработает, только если раздел размонтирован. А у меня это корень системы, так что получил ошибку. Решение простое. Загрузился с SystemRescueCD и выполнил её там. Откусил кусочек от LV, теперь конвертирую в RAID1:

# lvconvert --type raid1 -m 1 vgroup/root

Всё проходит без ошибок. Загружаю систему, проверяю массив:

# lvs -o+segtype
# lvs -a -o name,devices vgroup

Всё в порядке, оба диска на месте. Ставлю загрузчик на второй диск sdb:

# dpkg-reconfigure grub-pc

Теперь вынимаю первый диск sda, на который изначально ставилась система и перезагружаю её. Grub запускается со второго диска, а дальше вываливаюсь в initramfs. Система не грузится, пишет, что не видит диск /dev/mapper/vgroup-root. В консоли initramfs ввожу команду на активацию всех lvm томов:

# vgchange -ay

Находит VG vgroup, но ругается, что там нет sda. Логично, диск этот отключен. После этого выхожу из initramfs:

# exit

Так как LVM раздел активирован, грузится система со второго диска. То есть в целом всё в порядке. Система жива, загружается. Надо только разобраться с тем, чтобы initramfs автоматически активировал неактивный VG с raid1.

Как оказалось, проблема эта нередкая. Нашёл решение в интернете. Создаём файл /etc/initramfs-tools/scripts/local-top/forcelvm следующего содержания:

#!/bin/sh

PREREQ=""
prereqs()
  {
    echo "$PREREQ"
  }
case $1 in
  prereqs)
  prereqs
  exit 0
   ;;
  esac
. /scripts/functions
lvm vgchange -ay

Пересобираем initramfs:

# chmod +x /etc/initramfs-tools/scripts/local-top/forcelvm
# update-initramfs -u -k all

Перезагружаемся. Теперь загрузка работает нормально. Что с одним, что с двумя дисками.

Заменяем выключенный диск новым. Смотрим, какие диски есть в системе:

# lsblk

У меня с данными диск стал sda, новый sdb. Копирую на него разметку, добавляю в VG и LV с raid1:

# sfdisk -d /dev/sda | sfdisk /dev/sdb
# pvcreate /dev/sdb1
# vgextend vgroup /dev/sdb1
# vgreduce --removemissing vgroup --force
# lvconvert --repair vgroup/root
# lvconvert -m1 vgroup/root /dev/sdb1

Ставим загрузчик на новый диск:

# dpkg-reconfigure grub-pc

Следим за синхронизацией:

# watch lvs -a

Когда закончится, перезагружаем систему и убеждаемся, что всё работает.

Получилась готовая инструкция по установке системы на LVM Raid1 и по замене вышедшего из строя диска. В целом, всё примерно то же самое, что и в mdadm со своими нюансами. При случае попробую на каком-нибудь железном сервере вместо mdadm - LVM. На вид выглядит удобнее и функциональнее.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#lvm #raid

В недавнем цикле статей по LVM в комментариях всплывали вопросы так называемого Bit Rot или битового гниения. Это когда на носитель записан бит 1 или 0, а со временем по разным причинам он поменял своё значение. В конечном счёте эти изменения ведут к тому, что нужный файл хоть и нормально прочитается, но окажется "битым". Причём подвержены этим ошибкам все типы устройств хранения - от лент и CD до современных SSD. Я проверял свои старые записанные CD диски. Многие из них хоть и прочитались, но часть данных была безвозвратно утеряна или повреждена.

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

Проще всего следить за целостностью файлов с помощью подсчёта контрольных сумм по тем или иным алгоритмам (CRC, MD5, SHA1 и т.д.) Есть много бесплатного софта, который автоматически может это выполнять и сравнивать по расписанию. В Linux такой софт обычно используется для контроля за системными файлами, чтобы определять несанкционированное изменение. Пример - Afick, Tripwire. Если у вас лежат файлы, с ними никто не работает, но изменилась контрольная сумма, значит возникли проблемы. Необходимо то же самое проверить на другом хранилище этих же файлов и если там контрольная сумма не менялась, значит тот файл оригинальный и стоит его восстановить из этой копии.

Некоторые файловые системы выполняют такие проверки в автоматическом режиме. Это заложено в их архитектуру. Пример - ZFS, Btrfs, ReiserFS, Ceph. Все эти файловые системы могут не только контролировать изменения, но и выполнять автоматическое восстановление повреждённых файлов, если хранилища на их основе собраны с избыточностью данных. То есть каждый файл хранится как минимум в двух или более копиях, для каждой из которых посчитана и сохранена контрольная сумма.

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

Есть и другой механизм защиты файлов в Linux на основе контроля целостности - DM-integrity. С его помощью можно блочное устройство превратить в устройство с контролем целостности. А дальше с ним можно работать как с обычным диском - создавать разделы, тома Mdadm или Lvm. В случае нарушения целостности файла такое устройство будет возвращать Input/output error. Mdadm или LVM будут пытаться автоматически восстановить файл из копии, если хранилище обладает избыточностью данных, то есть собран рейд соответствующего уровня.

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

☝️ Самая надёжная защита от Bit Rot - множественные копии. И тут очень важно соблюдать один принцип. Делать копию надо не от копии, а от оригинала данных. У вас есть исходное хранилище с данными, где они регулярно меняются. С него вы снимаете первый бэкап. Второй бэкап для другого хранилища надо снимать не с первого бэкапа, а тоже с исходного сервера. Иначе вы на все зависимые сервера принесёте битые файлы с первого бэкапа.

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

#backup

Давно не занимался настройкой времени на серверах. Сейчас в Debian по умолчанию запущена служба systemd-timesyncd. Там либо стандартные дебиановские сервера указаны, типа 0.debian.pool.ntp.org, либо из шаблона хостера какие-то его или другие публичные сервера. Обычно всё это сразу работает и трогать не обязательно. Я даже подзабыл и названия служб, и расположение конфигураций.

А тут один внешний сервер стал в мониторинге мигать проблемами с синхронизацией. Просмотрел логи, увидел ошибку:

systemd-timesyncd[308]: Timed out waiting for reply from 195.90.182.235:123 (0.debian.pool.ntp.org)

Почему-то иногда подвисают соединения и синхронизация не происходит. Решил для начала просто поменять набор серверов. Конфигурация timesyncd хранится в файле /etc/systemd/timesyncd.conf. Но трогать его не рекомендуется, а как это обычно бывает с systemd, создать отдельный каталог с корректирующей конфигурацией:

# mkdir /etc/systemd/timesyncd.conf.d
# touch /etc/systemd/timesyncd.conf.d/timesyncd.conf

И уже в него добавляем свои параметры. В данном случае я добавил несколько основных и один резервный сервер:

NTP=0.ru.pool.ntp.org 1.ru.pool.ntp.org 2.ru.pool.ntp.org 3.ru.pool.ntp.org
FallbackNTP=ntp0.vniiftri.ru

Перечитываем конфигурацию служб и перезапускаем timesyncd:

# systemd daemon-reload
# systemctl restart systemd-timesyncd

Проверяем общие настройки времени:

# timedatectl

И конкретно статус синхронизации:

# timedatectl timesync-status
    Server: 51.250.35.68 (0.ru.pool.ntp.org)
................................

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

Посмотреть логи службы можно так:

# journalctl -u systemd-timesyncd

☝️ Дам одну подсказу, если у вас вообще не синхронизируется время, нет соединения с внешними серверами. Такие соединения очень часто блокируют сами провайдеры, предоставляя свои внутренние сервера времени. Это делают специально, потому что протокол NTP, как и DNS очень часто используют для усиления DDOS атак. Так что если у вас не синхронизируется время на сервере с внешними источниками, задайте сразу вопрос провайдеру. Сэкономите кучу времени.

Это ограничение можно обойти различными способами. Например, использовать htpdate (apt install htpdate), которая берёт точное время по протоколу HTTP.

Замена серверов мне, кстати, в итоге не помогла. Всё равно часть запросов подвисают с ошибкой Timed out waiting for reply. Случается это без какой-то системы, но время в итоге всё равно синхронизируется. Не знаю точно, с чем связано. Думаю, что это особенность пула pool.ntp.org. Надо использовать какие-то конкретные адреса.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#systemd

Давно думал, что надо бы переходить на какие-то отечественные публичные серверы NTP и DNS. Идёт размежевание с западными странами и только вопрос времени, когда занавес окончательно опустится. Решение, судя по всему, уже принято и сейчас шаг за шагом прорабатывают технические моменты.

Я обычно для NTP использую сервера из pool.ntp.org, а для DNS - сервера Яндекса - 77.88.8.1 и 77.88.8.8. Откровенно говоря, я компанию Яндекс недолюбливаю по многим причинам. Сейчас не хочется это обсуждать, но по возможности стараюсь не использовать их сервисы, если есть альтернативы не хуже.

Вчера в комментариях один подписчик подсказал, что в крупных отечественных организациях идёт рекомендация на использование публичных сервисов от известной компании MSK-IX. Это компания - крупнейшая в стране точка обмена трафиком со своими дата-центрами и каналами связи. Думаю, это разумно и обоснованно. Вот их NTP сервер:

ntp.msk-ix.ru

MSK-IX NTP server относится к высшему уровню точности (Stratum One Time Servers) в иерархической системе часовых уровней. В качестве эталонного сигнала времени используется сигнал глобальных спутниковых систем навигации ГЛОНАСС.

MSK-IX NTP Server реализован в виде группировки серверов, размещенных в Москве, Санкт-Петербурге, Екатеринбурге и Новосибирске. Применение сетевой технологии anycast обеспечивает высокую надежность и быстрый отклик системы на всей территории страны.

Я бы к нему в список добавил ещё один от ВНИИФТРИ:

ntp1.vniiftri.ru

Вот список DNS серверов:

dns.msk-ix.ru 62.76.76.62
dns2.msk-ix.ru 62.76.62.76

Реплики сервера установлены в Москве и Санкт-Петербурге. Благодаря использованию технологий IP-anycast и кэширования пользовательских запросов, DNS-запросы пользователей направляются к ближайшей реплике по кратчайшему сетевому маршруту и обрабатываются с максимальной скоростью. Кроме того, применение технологии IP-anycast обеспечивает резервирование службы, повышает устойчивость к сетевым атакам и локальным авариям в сети Интернет.

Я себе сохранил эти сервера и теперь буду в настраиваемых системах использовать их.

#dns #ntp

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

Потом всё это поехало в виртуальные машины, а они, соответственно, в облака. Со временем с виртуальными рабочими местами как-то подуспокоились. Все, кто хотел, попробовали или внедрили VDI. Уже не вижу, чтобы эту технологию как-то активно продвигали. В основном все работают за своими компьютерами и ноутбуками, но уже в веб приложениях. Хотя на днях ходил в Сбербанк. Там оператор меня полностью обслужил, используя только планшет. Обратил внимание, что экран монитора у него был выключен. Либо уснул, либо он компьютер не включает за ненадобностью.

И вот теперь технологический виток сделал круг и облачные технологии обратно переезжают на сервера в виде Azure Local. То есть это тот же облачный Azure, который можно развернуть у себя локально. Судя по всему рост облачных сервисов прекратился и Microsoft начали наполнять рынок опять локальными решениями, чтобы занять его.

Вот сама статья в Forbes:

⇨ Azure Local Brings The Power Of Cloud To On-Premises And Edge

Там одна вода. Судя по всему, это реклама.

Интересно, Azure Local можно будет запустить в виртуальных машинах на Azure или AWS? И будет ли аналог от AWS и GCP?

#разное

Существует очень простой способ объединить несколько различных дисков в единый логический раздел. Речь идёт именно о логическом объединении. То есть у вас могут быть два абсолютно любых хранилища, смонтированных в разные разделы. Например, /mnt/sda и /mnt/sdb. Вы можете объединить их в единый диск в новой точке монтирования /mnt/sdab. Объём двух разделов суммируется в новой точке монтирования. При этом файлы будут писаться в зависимости от настроек в оба исходных диска, а /mnt/sdab просто будет единое место, к которому можно обращаться для работы с файлами.

Сразу поясню, где это может пригодиться.

🔹Видеосервер с записями камер. Можно объединить разнородные хранилища в единую точку монтирования и указать её в настройках видеосервера.

🔹У меня не раз бывали ситуации, когда мне нужно было объединить в единый раздел несколько raid1 или raid10. Для этого я их объединял с помощью LVM. Бывает так, что у вас есть сервер с 4-мя дисками, но при этом они одинаковые парами, например 2 по 2TB и 2 по 3TB. Вы делаете 2 зеркала mdadm, а потом поверх него пускаете LVM. Получаете 5TB в одном разделе. В некоторых случаях удобнее и безопаснее обойтись без LVM, а сделать логическое объединение.

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

🔹Сервер для бэкапов, где допустимо логическое объединение дисков. А для бэкапов это часто допустимо.

Работает всё это на базе mergerfs. Покажу сразу на практике. Допустим, у нас есть 2 диска sda и sdb по 20G. Создаём на них по одному разделу и монтируем в систему:

# cfdisk /dev/sda
# cfdisk /dev/sdb
# lsblk
# mkfs.ext4 /dev/sda1
# mkfs.ext4 /dev/sdb1
# mkdir /mnt/sda
# mkdir /mnt/sdb
# mount /dev/sda1 /mnt/sda
# mount /dev/sdb1 /mnt/sdb
# df -h
/dev/sda1    20G  24K  19G  1% /mnt/sda1
/dev/sdb1    20G  24K  19G  1% /mnt/sdb1

Создали, примонтировали, убедились, что всё работает. Устанавливаем mergerfs и создаём общий диск:

# apt install mergerfs
# mkdir /mnt/sdbc
# mergerfs -o defaults,allow_other,category.create=mfs,moveonenospc=true,minfreespace=1G /mnt/sda1:/mnt/sdb1 /mnt/sdab
# df -h | grep sdab
a1:b1      40G  48K  38G  1% /mnt/sdab

Я добавил к параметрам по умолчанию следующие:
◽️allow_other - позволяет пользователям видеть файловую систему, иначе увидит только root.
◽️category.create=mfs - политика распределения файлов по дискам в зависимости от наличия там свободного места, где больше места, туда пишем.
◽️moveonenospc=true - при сбое записи если, к примеру, на устройстве не осталось места или превышена квота, файл будет записан в другое место.
◽️minfreespace=1G - если на устройстве меньше 1G места, туда больше не пишем.

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

# dd if=/dev/zero of=/mnt/sdab/tempfile1 bs=1M count=1000
# dd if=/dev/zero of=/mnt/sdab/tempfile2 bs=1M count=1000
# ls /mnt/sdab
tempfile1 tempfile2
# ls /mnt/sda1
tempfile2
# ls /mnt/sdb1
tempfile1

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

Общее хранилище можно подключать через fstab или systemd-mount. Примеры есть в репозитории.

Полезный прикладной софт. Работает просто, решает конкретную задачу.

⇨ 🌐 Исходники

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#fileserver

Заметил на днях, что давно мне обновления в Windows 11 не прилетали. Зашёл в раздел обновлений, выполнил проверку. Ничего нового нет. Обратил внимание - висит предупреждение, что моя версия системы больше не поддерживается. Удивился. Винда лицензионная, никаких твиков, остановок служб не делал. Даже Defender в этой системе не отключал.

Версия системы - 22H2. Оказывается, у неё кончилась поддержка в октябре. Я особо не слежу за всеми этими движухами и с обновлениями не тороплюсь. Мне от системы надо, чтобы она просто работала. И желательно не беспокоила различными изменениями. Привык, что в рамках одной версии все сервис паки и обновления прилетают автоматически, когда приходит время. А тут почему-то этого не случилось, и я оказался с неподдерживаемой версией.

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

Я сразу выбрал, как мне показалось, самый простой и надёжный вариант. Скачал Windows11InstallationAssistant.exe с сайта Microsoft и запустил. Какое-то время он качал файлы, а потом начал очень длительное обновление. Заставил меня понервничать. В какой-то момент обновление минут 30 висело на стадии 31% и не двигалось. Я уже прикидывал, как буду восстанавливать систему. Предварительно, само собой, сделал полный бэкап с помощью Veeam Agent for Windows. Я им постоянно пользуюсь, он бесплатный.

В итоге всё обошлось. Примерно за пару часов с момента запуска ассистента система полностью обновилась. И сразу начала отчёты в центр слать. Без перерыва шуршат два процесса:

- Windows Hello Security Process
- Служба индексации

Индексация через несколько часов прекратилась, а вот первая до сих пор грузит процессор и вынуждает гудеть вентиляторы ноута. Предстоит разбирательство с этой новой проблемой. Как говорится: "Не было печали, апдейтов накачали". Вот только не качать их варианта не было.

#windows

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

Пишем в отдельные файлы ошибку 404 и все коды 5XX. Добавляем в секцию http:

map $status $to404log {
404 1;
default 0;
}                
map $status $to5XXlog {
~^[5]  1;
default 0;
}

И потом в тот виртуальный хост, для которого это настаиваем:

access_log /var/log/nginx/404.log combined if=$to404log;
access_log /var/log/nginx/5XX.log combined if=$to5XXlog;

Теперь все запросы со статусом 404 будут писаться в лог 404.log, а все 500-е ошибки в лог 5XX.log. При этом в общий лог они тоже будут попадать.

Работает модуль map очень просто. В данном случае мы используем встроенную переменную $status, в которой хранится код ответа на запрос. Если код будет 404, то мы назначаем созданной нами переменной $to404log значение 1. А затем в виртуальном сервере указываем через if, что если значение 1, то пишем запрос в лог. А для 500-х ошибок используем регулярное выражение, которое будет включать их все.

По аналогии можно сделать блокировку определённых user-agent. Как раз для них я очень давно использую готовую конструкцию и баню наиболее известных ботов:

map $http_user_agent $block_useragent {
default 0;
~*semrushbot 1;
~*ahrefs 1;
~*rss2tg 1;
~*seznambot 1;
~*AspiegelBot 1;
~*BLEXBot 1;
~*MASHIAH 1;
  }

Добавляю в виртуальный хост:

if ($block_useragent) {
return 403;
}

Думаю, принцип понятен. По аналогии можно блокировать разные типы запросов через переменную $request_method, какие-то урлы для каких-то user agent. Модуль geoip тоже удобно через map использовать с помощью переменной $geoip_country_code, и т.д.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#nginx

Подписчик поделился полезным скриптом для аудита VPS серверов - VPS Security Audit Script. Я кстати, всегда с благодарностью отношусь ко всем рекомендациям. Всё читаю, смотрю, о чём-то пишу потом.

Возвращаясь к скрипту. Сначала прохладно отнёсся. Думаю, мало смысла на сервер нести какой-то посторонний софт. Но потом посмотрел исходники и поменял своё мнение. Там очень простой bash код, который легко читается. В скрипте никакой экзотики. Просто анализ типовых настроек с использованием стандартных утилит командной строки Linux.

📌 Скрипт проверяет:

▪️Настройки SSH: номер порта, аутентификацию по паролю и под root
▪️Статус Firewall
▪️Настройку автоматических установок обновлений безопасности
▪️Работу Fail2Ban или CrowdSec
▪️Количество неудачных попыток логина
▪️Количество доступных, но не установленных обновлений
▪️Количество работающих служб
▪️Количество открытых на внешнем интерфейсе портов
▪️Логирование команд через sudo
▪️Некоторые системные метрики: uptime, cpu, disk, memory
▪️Необходимость перезагрузки сервера после обновления ядра
▪️Наличие файлов с SUID (Set User ID) - флаг прав доступа, позволяющий запустить исполняемый файл с правами владельца.

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

# apt-get -s upgrade 2>/dev/null | grep -P '^\d+ upgraded' | cut -d" " -f1
49

Результат работы скрипта сохраняется в текстовый файл. Эти файлы можно хранить в системе для хранения логов, либо парсить и передавать данные в систему мониторинга. Например, можно добавить в Zabbix и сделать триггер на фразу FAIL в логе.

Скрипт интересный. Ничего особенного, но всё аккуратно собрано в одном месте. Можно его рассмотреть и взять себе что-то для встраивания в свой мониторинг или скрипты. Я сохранил.

⇨ 🌐 Исходники

Сам использую немного другую шутку, но решаю похожие задачи:

⇨ Мониторинг безопасности сервера с помощью Lynis и Zabbix

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#мониторинг #script

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

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

🔥Поднимаем сервер синхронизации файлов Syncthing в docker
Подробная статья по настройке популярного и функционального решения для синхронизации файлов между несколькими устройствами. Для Syncthing устанавливается веб интерфейс. Показаны примеры по настройке различных устройств на базе Linux, Windows, Android.

⇨ Собираем единую ленту новостей с сайтов и Telegram-каналов на своем сервере
Установка на своём сервере агрегатора Telegram-каналов RSSHub с представлением в виде RSS-лент с помощью Tiny Tiny RSS.
⇨ Готовим агрегатор новостей с автоматической публикацией в своем Telegram-канале
Продолжение предыдущей темы. Использование готовых ботов или запуск на своего на своём сервере для автоматической публикации постов в Telegram канале.

⇨ Planka - opensource альтернатива Trello
⇨ Affine - opensource альтернатива Notion и Miro
⇨ Plane - opensource альтернатива Jira
Обзорные статьи аналогов популярных систем управления проектами.

🔥Как мигрировать базу данных Zabbix с MySQL на PostgreSQL
Подробная инструкция по миграции с одной СУБД на другую.
⇨ Как перенести Zabbix на новый сервер
Перенос Zabbix Server на новый сервер без смены СУБД. База переносится дампом.
⇨ Как перенести Zabbix Proxy на новый сервер
Перенос Zabbix Proxy. Статью не совсем понял. Прокси не хранит долговременных данных, не понятно, зачем её переносить. Можно просто поднять новую прокси, перевести клиентов на неё, а старую потушить.
⇨ Как обновить Zabbix с версии 6.0 до 7.0
⇨ Как обновить Zabbix Proxy с версии 6.0 до 7.0
Инструкции по обновлению Zabbix Server и Proxy на базе официальной. Бэкапим, подключаем новый репозиторий, обновляем пакеты, проверяем.

⇨ bat, exa – подсветка синтаксиса стандартного вывода в терминале Linux (cat, less, tail и ls)
Обзор современных консольных утилит Linux, аналога более старых.

⇨ Анализ дампов синих экранов Windows используя WinDBG
Создание и анализ дампов после BSOD с помощью WinDBG.

⇨ Как исправить пустую страницу после входа в ECP/OWA на сервере Exchange
Разбор ошибки, которая возникает при проблемах с настройкой TLS сертификатов.

🔥Тестовое задание. lamp + php 7 + php 8
⇨ Lemp + php 7 + php 8
Интересная заметка, как автор проходил собеседование с практическим заданием. В первом материале разбор тестового задания, а во втором оно же, только вместо Apache используется Nginx.

⇨ Замена системного диска в зеркале ZFS на Proxmox VE
Инструкция по замене диска в ZFS, на котором установлена система и загрузчик. Материал с последовательностью команд и результатом их работы.

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

⇨ Как решить проблему, когда Пуск не отвечает в Windows Server 2016
Какой-то странный баг с неработающим пуском на сервере. Сам не сталкивался с таким, хотя с этой версией периодически работаю.

Если кто-то хочет присоединиться к этой подборке, то пишите мне в личные сообщения. Пока список выглядит так:

▪️https://r4ven.me
▪️https://wiki-it.ru
▪️https://www.gurin.ru
▪️https://sysadminhub.ru
▪️https://devopslife.ru
▪️https://bite-byte.ru
▪️https://sysadminium.ru
▪️https://desoft.ru
▪️https://www.pc360.ru
▪️https://bafista.ru
▪️https://it-experience.ru
▪️https://blogadminday.ru
▪️https://marukhin.ru

#статьи

Тестировал вчера open source панель для управления сервером и установки на него софта - Cosmos. Сам автор позиционирует её как Secure and Easy Selfhosted Home Server. Панель и сама работает в Docker, и софт запускает тоже в контейнерах. Это уже не первая подобная панель на канале. Сразу скажу, что ничего особенного в ней не увидел. Она не лучше и не проще всех остальных похожих.

В целом, пользоваться можно. Даже русский язык есть, но переведено кривовато. Я переключился на английский. У всех подобных панелей на базе Docker есть один существенный минус. Они хоть и позиционируют себя как простые и быстрые в настройке, на деле это не так. Запуск приложений в Docker, особенно когда их много на одном сервере, требует от пользователя понимания, как всё это между собой связано и работает. Постоянно возникают небольшие нюансы в работе, которые не решить без этих знаний. А если вы знаете Docker, то и панель вам особо не нужна. Ставишь Portainer и запускаешь всё там.

Cosmos в целом неплоха в сравнении с остальными. Выделю несколько полезных особенностей:

▪️Интерфейс адаптивен, работает и на мобильных устройствах.
▪️Можно создавать пользователей веб панели. Бесплатная версия позволяет создать 5 штук.
▪️Панель нативно поддерживает работу MergerFS и SnapRAID.
▪️Из коробки HTTPS от Let's Encrypt.
▪️Поддержка OAuth 2.0 и OpenID, 2FA через Google аутентификатор или аналоги.
▪️Есть встроенные средства безопасности, на основании которых можно ограничивать доступ к публикуемым ресурсам. Можно ограничивать доступ на основе групп. Блокировать ботов, тех, кто превышает лимиты по запросам или трафику.

Запустить и посмотреть на Cosmos можно так:

# docker run -d --network host --privileged --name cosmos-server -h cosmos-server --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket -v /:/mnt/host -v /var/lib/cosmos:/config azukaar/cosmos-server:latest

Если настроено доменное имя, то можно сразу получить сертификат от Let's Encrypt, а все устанавливаемые службы будут запускаться на поддоменах. Если же сделать установку без HTTPS по IP адресу сервера, то сервисы будут подниматься на отдельных TCP портах. Я и так, и так попробовал.

Аналоги Cosmos:

◽️CasaOS
◽️Runtipi

Мне лично CasaOS больше всего понравилась. Она более целостно смотрится, магазин приложений больше, как и в целом сообщество. Но Cosmos более функциональна в базе.

⇨ 🌐 Сайт / Исходники / Demo

#docker #linux