Мне тут попался на глаза один любопытный проект - wstunnel. Самому особо не нужен, но друг интересовался 😁. Он любой трафик упаковывает в websocket. Сейчас много таких упаковывателей появилось, как в websocket, в dns запросы, так и другие протоколы, например, icmp.

Этот упаковыватель отличает простота использования. Я лично проверил, работает хорошо. Состоит из одного бинарника, который достаточно скачать и запустить. Поддерживаются системы - Linux, macOS, Android. Windows нет, но если в винде запустить в WSL, то в основной системе нормально работает. Можно без проблем поднять SOCKS5 для основного браузера.

Покажу на примере, как это работает. Допустим, нам надо на работе скачать дистрибутив Veeam Agent for Microsoft Windows FREE или Elasticsearch. Компании заблокировали возможность загрузки из РФ. А на файрволе закрыты все порты, кроме 443, и изменить это вы не можете. Арендуем любую VPS, откуда будет доступ в США. Скачиваем на неё бинарник и распаковываем:

# wget https://github.com/erebe/wstunnel/releases/download/v10.5.5/wstunnel_10.5.5_linux_amd64.tar.gz
# tar xzvf wstunnel_10.5.5_linux_amd64.tar.gz

Даём права на запуск и запускаем в режиме сервера:

# ./wstunnel server wss://[::]:443

На своей машине скачиваем то же самое и запускаем в режиме клиента:

# ./wstunnel client -L socks5://127.0.0.1:8090 --connection-min-idle 5 wss://vps_ip:443

У вас на машине запустился SOCKS5 прокси по адресу 127.0.0.1:8090. Теперь эти параметры можно использовать в браузере в настройках прокси. Отдельно порекомендую вот это расширение для браузеров - ZeroOmega. Я постоянно пользуюсь, хорошо работает, задачи решает. Можно быстро переключать прокси на конкретных сайтах, либо настроить постоянные списки.

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

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

Очередная подборка статей авторов, которые согласились в ней участвовать. Кто не понимает, о чём идёт речь, может прочитать прошлые публикации по этой теме (раз, два).

⇨ Удобная Docker лаборатория с блэкджеком и Web GUI
Очень подробная статья с настройкой лаборатории на базе Docker, Komodo - оркестратор для него, Nginx Proxy Manager - веб интерфейс управления веб сервером, Technitium - DNS сервер для всей лаборатории.

⇨ Установка Taiga в Docker
Установка сервера для управления проектами Taiga.io - функциональный open source проект для работы по методологии Agile. Я делал про него заметку.

⇨ Duplicati - резервное копирование с шифрованием для домашнего сервера
Обзор популярной программы для бэкапов. Я делал про неё заметку У программы простой и приятный веб интерфейс, поддержка дедупликации и инкрементных бэкапов. Ставится локально на сервер и с него же управляется. То есть это не централизованная система.

⇨ Zerobyte - автоматизация резервного копирования для self-hosted инфраструктуры
Ещё один инструмент для бэкапов, но уже централизованный. В основе у него Restic. Я его недавно тестировал и писал заметку. Интересное решение, рекомендую попробовать.

⇨ Zabbix. Оповещения в MAX.
Скрипт и подробная инструкция по использованию для отправки уведомлений из Zabbix в MAX.

⇨ Как настроить оповещения Zabbix в MAX
Ещё одна реализация уведомлений из Zabbix в MAX через Webhook, без внешнего скрипта.

⇨ Первое знакомство с n8n
Обзор популярной платформы для автоматизации n8n - визуальный конструктор для выстраивания рабочих процессов. Автор показал установку и создание простого workflow с отправкой уведомления в Telegram.

⇨ Как восстановить данные из резервной копии Veeam Agent
Подробная инструкция по восстановлению бэкапа, созданного через Veeam Agent. Там на самом деле не всё так просто и очевидно, как может показаться на первый взгляд. Я недавно сталкивался с проблемами. Надо обязательно тестировать восстановление заранее, чтобы знать, как действовать.

⇨ Настраиваем OpenConnect middle server для доступа к закрытому контуру
Подробная статья по настройке OpenConnect сервера в качестве промежуточного сервера, который принимает подключения от клиентов, а потом сам подключается к другому серверу и прокидывает туда соединение пользователя. Интересная тема в том числе в контексте современных блокировок.

⇨ Pangolin — самый простой (но не дешевый) способ открыть доступ к homelab
Обзор сервиса Pangolin для публикации веб сервисов из закрытой сети в интернет. Необычная реализация на базе Traefik + свой сервис IAM + Wireguard. Я писал по нему подробную заметку.

⇨ PowerShell для начинающих администраторов: команды, справка и примеры
Базовая информация по работе в Powershell.

🔥Fwknop - современный port knocking для Linux
Современная реализация похожего на port knocking подхода для открытия доступа на файрволе. Ни разу раньше не слышал про него. Надо будет попробовать. Там в основе отправка одного пакета с зашифрованным содержимым, а не обычный стук разными размерами пакетов по портам или отправка icmp запросов.

Хотите присоединиться к этой подборке? Пишите мне в личные сообщения.

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#статьи

При переходе на Linux с Freebsd, я почти сразу пересел на Centos, где по умолчанию была файловая система XFS. Я особо не заморачивался, и везде использовал её. Каких-то нюансов или проблем у меня с ней не было. По мере того, как стал потихоньку использовать другие ОC, в частности Ubuntu и Debian, где по умолчанию используется EXT4, стал появляться вопрос, а какую файловую систему использовать? Можно выбрать и ту, и другую.

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

Я уже поднимал когда-то давно эту тему на канале и было много отзывов по этим ФС. Решил для себя и вас актуализировать этот вопрос, прочитав обсуждения на эту тему, некоторые статьи и поспрашивав ИИ. Вот что в итоге вынес для себя.

📌 На основе комментариев в канале и нескольких обсуждений на Reddit:

◽️XFS архитектурно более сложная система, восстановить с неё данные, если что-то пойдёт не так, намного сложнее, чем с EXT4.
◽️Аварийные выключения с гораздо большей вероятностью приведут к сбоям XFS. На эту тему прям много отзывов.
◽️XFS не получится уменьшить в размере, в отличие от EXT4.
◽️В EXT4 количество доступных inodes задаётся в момент создания, либо используется значение по умолчанию, и их вполне реально все исчерпать. Я лично с этим сталкивался. В XFS такой проблемы нет, они выделяются динамически.
◽️Из-за активного развития XFS, в разных системах могут быть разные версии ФС, так что не получится примонтировать том из одной системы в другую, где отличаются версии ФС в ядре. Это в основном актуально при подключении томов из новых версий в старые. Например, том из Centos 7 можно примонтировать в Centos 9, а наоборот - нет. Даже из Centos 9 в 8-ю версию не примонтировать.

С точки зрения пользовательского опыта, EXT4 проще, универсальнее, надёжнее.

📌 Теперь набор архитектурных отличий:

◽️У XFS есть так называемые Allocation Groups (AG) - независимые группы, на которые разбита файловая система. Каждая AG работает как отдельная мини файловая система. Благодаря этому XFS более эффективно работает с параллельной нагрузкой по чтению-записи по сравнению с EXT4. Это их основное архитектурное отличие. Важно понимать, что разница эта будет заметна только при больших нагрузках на больших же хранилищах.
◽️В XFS есть поддержка Reflink - позволяет нескольким файлам использовать одни и те же блоки данных, что экономит место на диске. Она основана на механизме копирования при записи (Copy-on-Write, CoW).

И ещё важный нюанс. В 2020 году вышла известная статья со сравнением производительности XFS и EXT4 в контексте использования под MySQL сервер. С учётом изменений в MySQL того времени и тестам, автор сделал однозначный вывод, что с XFS работа значительно быстрее, так что он рекомендовал использовать именно её. С тех пор было много обновлений, в том числе и EXT4 и такой разницы в производительности больше нет. Так что та рекомендация потеряла актуальность. Если верить современным тестам, то разница между этими файловыми системами в смешанной нагрузке стала минимальна.

❓ Какой я в итоге для себя сделал вывод?

- Для смешанной нагрузки в различных VPS использовать EXT4 и не забивать себе голову.

- XFS рассматривать только в больших хранилищах, собранных в RAID, например под видеонаблюдение, образы VM или бэкапы. Последнее наиболее актуально. Например, Veeam поддерживает технологию reflink, что существенно экономит место и увеличивает производительность хранилища с бэкапами. У меня есть одна такая большая хранилка с Veeam и там, к сожалению, EXT4. Надо было раньше эту заметку писать. Так что имейте это в виду. Я на тот момент не стал заморачиваться и сделал всё по умолчанию. И теперь Synthetic Full длится часами, а мог бы за минуты выполняться.

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#fileserver

Когда разбирался с файловыми системами, увидел возможность EXT4, про которую раньше не знал. Можно сделать дамп метаданных файловой системы, без непосредственно самих данных. То есть вы получаете список всех файлов с размером, правами и прочими атрибутами. Этот дамп можно примонтировать, как обычный диск, и посмотреть структуру. Всё будет выглядеть, как обычная файловая система, только самих данных не будет.

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

# e2image -rf /dev/sda1 fs_raw.img
# mkdir -p /mnt/fs_metadata
# mount -t ext4 -o ro,noload fs_raw.img /mnt/fs_metadata

В данном случае я сделал образ метаданных корневого раздела диска и примонтировал его в /mnt/fs_metadata.

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

Выглядит это примерно так:

# rsync -ani --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run --exclude=/tmp --exclude=/mnt / /mnt/fs_metadata/

В данном случае --exclude используются, потому что я сравниваю корень. Оставил их для примера, если нужно будет тоже сделать какие-то исключения. На выходе получите листинг изменённых файлов, где будет указан тип файла
f / d / l (файл / директория / симлинк) и чем различаются: s - размер, p - права, o - владелец и т.д. По этим меткам, соответственно, можно грепнуть и вывести только нужные различия.

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#linux

Предупреждение для тех, кто использует облачные хранилища файлов, как основные. Как я уже не раз говорил, у меня используется Яндекс.Диск, но исключительно, как резервное хранилище. Основное у меня дома на NAS. Оно копируется ещё в одно место локально, и в облако. Объём основной полезной информации в районе 1,5 ТБ и это ~175 тыс. файлов.

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

1️⃣ Взял чистую систему, установил туда клиент Яндекс.Диска и запустил синхронизацию, чтобы проверить, сколько времени займёт загрузка облачного архива. Канал в интернет - 100 мегабит, размер файлов в облаке - 1,1 ТБ. В идеальных условиях это должно качаться 25-30 часов. У меня в итоге ушла неделя. Большую часть времени клиент что-то обрабатывал и не занимал канал, и компьютер тоже особо не нагружал. Он не был узким местом. Если храните там какие-то важные бэкапы, которые нужно будет быстро забрать в случае аварии, имейте ввиду, что не факт, что получится это сделать.

2️⃣ Взял примерно полугодовалую локальную копию и сравнил MD5 хэши с тем, что скачалось из облака. Примерно у 500 файлов хэши не совпали, при полном совпадении всех остальных атрибутов. То есть без сверки хэшей разницу не заметить. Бегло проверил несколько из них. Это были фотки. На них наглядно видно повреждения. Проблемы были именно в облачных файлах. Где они побились - не понятно. Может во время хранения, может во время загрузки в облако или скачивания.

3️⃣ Примерно у 80% файлов были неверные даты создания. Сравнивал с основным хранилищем. Когда и почему они изменились - не знаю. Раньше никогда не обращал на это внимание. Размеры файлов одинаковые, а даты - разные. Это не сказать, что критично, но может создавать неудобства. И не понятно, как исправить, кроме как заливать туда заново все файлы с изменёнными датами.

4️⃣ Отдельно добавлю, о чём уже ранее писал. У меня был случай, когда часть файлов в Яндекс.Диске пропала. Заметил не сразу и только благодаря локальным копиям с большой глубиной хранения.

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

У меня Яндекс.Диск используется как для хранения бэкапов, так и для совместного хранилища для разных устройств, которые только частично синхронизируют информацию с ним. Но всегда есть отдельный компьютер или виртуалка, которая синхронизируют себе полную копию облачных данных, и с этой копии делается инкрементный бэкап с глубиной хранения 180 дней.

Все сравнения и синхронизации обычно делаю с помощью программы Goodsync.

#fileserver

Вчера на прогулке прослушал длиннющий вебинар на тему, которую я никак не мог пропустить. Она тут на канале обсуждалась раз 10 в разное время:

⇨ Zabbix vs Prometheus на практике

Особо чего-то полезного и интересного, чего бы не знал, я не услышал. Автор сразу признался, что с Zabbix не работает, знает его приблизительно по старой памяти, когда сталкивался с ним по работе много лет назад. Из-за этого был в некоторых местах необъективен и никто не поправил в чате.

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

Не то, чтобы я защищаю Zabbix. Он в этом не нуждается. Я и то, и другое активно использую и более-менее прилично знаю. Это инструменты под свои разные задачи. Я тут за объективность. Пишу заметку, чтобы акцентировать внимание на ключевом отличии с точки зрения автора вебинара между этими двумя системами. Никогда не смотрел на них под этим ключом.

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

В Prometheus принципиально другой подход - туда без всякой подготовки можно лить разные метрики. На сервере под каждую метрику не нужно создавать никаких сущностей. Хочешь 10 метрик отправляй, хочешь через минуту - 100. Серверу всё равно, он примет все без какой-либо донастройки. Это экономит время и организационно выглядит проще, что имеет решающее значение для динамических сред при выборе инструмента сбора метрик.

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

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

Второе заметное отличие с точки зрения практической работы с ним - Prometheus полностью совместим с подходом IaC, Zabbix - нет.

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#zabbix #prometheus