Ты просыпаешься на пыльном чердаке.
Снаружи буря грохочет по старой черепице.
Во рту пересохло. Ноги болят.
Ты прикован наручниками к трубе, и твоя рука обожжена.
Перед тобой стоит женщина. Тесак в ее руке блестит в тусклом свете.
"Что, - спрашивает она, - ты готов сделать, чтобы сбежать?"

Неплохое начало для триллера? Так начинается текстовая обучающая игра по regex выражениям SLASH\ESCAPE. В данном случае нетрудно догадаться об ответе: "Всё, что угодно." В формате regex это будет .*

"Всё, что угодно? - говорит она, - сурово."

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

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

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

Ваша рука выскользнула из наручника.

Вы можете двигаться ВПРАВО или ВЛЕВО - в RegEx вы можете просто написать слово, которое хотите сопоставить, так что пишите свой выбор.

Ну и так далее. К каждому заданию есть подсказка, которая объясняет правильный ответ и рассказывает, где это может пригодиться.

Сделано прикольно и атмосферно. Не видел и не слышал раньше про эту игру. Увидел случайно в другой похожей игре: lost-at-sql. Там тоже свой необычный сюжет. Вы капитан подводной лодки SS.QL, у которой какие-то проблемы. Вам надо их решать посредством SQL запросов к базе данных аппарата. Сделано забавно, но про SQL и так последнее время было много заметок, поэтому не стал акцентировать внимание именно на ней. С regex игра больше понравилась.

🎮 ⇨ SLASH\ESCAPE
📱⇨ Lost at SQL

#regex #обучение #игра

Когда собирал заметку про различные варианты рисования схем, в том числе на основе текстового описания, наткнулся на интересный и полезный проект kroki.io. Не стал его там упоминать, чтобы в одну кучу всё не сваливать. Решил написать отдельно.

Это open source проект, который есть в редакции self-managed, то есть можно развернуть у себя. Он объединяет в себе все доступные библиотеки open source движков для рисования графиков из текстового описания. На сайте есть форма, где можно выбрать из выпадающего списка желаемый движок диаграмм, посмотреть пример текстового описания и тут же графическое отображение.

Если вы подбираете себе подобный инструмент для рисования схем, то можете очень быстро выбрать и попробовать то, что вам понравится больше всего. Кто-то прям неслабо заморочился и объединил в одном месте 27 доступных движков, в том числе Mermaid, GraphViz, Excalidraw и другие.

Я, кстати, именно тут впервые увидел, что Excalidraw, оказывается, тоже может рисовать схемы на основе текстового описания. Изначально думал, что это только графический редактор. Язык у него не сказать, что простой. Немного посмотрел представленные примеры. Стало понятно, почему Mermaid такой популярный. С ним реально проще работать, чем с другими. Синтаксис наиболее простой и интуитивный.

На сайте kroki.io есть небольшая шпаргалка в виде pdf с картинками, где представлены различные форматы визуализаций и движки, с помощью которых они нарисованы. Можно быстро прикинуть, что вам больше всего подойдёт. Примеры:

◽️Схема сети - NwDiag
◽️Детали сетевого пакета - PacketDiag
◽️Схемы стоек - RackDiag
◽️Диаграммы из блоков - BlockDiag, Ditaa
◽️Столбчатая диаграмма - Vega-lite
и т.д.

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

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

#схемы

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