Истории про мою home #lab.

Заебался я на самом деле с этой загрузочной флешкой.

Много чего было, расскажу про две проблемы.

Первая - то, что root fs пытается настроиться до того, как проинициализирован usb controller.

Сука, это леденящий душу пиздец.

GRUB загружает ядро Linux, передает в загрузчик ядра partition uuid, а потом Linux не может найти этот partition uuid, потому что разделы на флешке еще не пронумерованы, потому что система их еще не нашла.

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

Дебажил это реально несколько часов.

Решение?

Слушайте, вот как бы эту проблему решил нормальный разраб? Я бы написал там какой-то retry, с exponential backoff, пытаясь примонтировать rootfs до того момента, когда инициализация драйверов не будет полностью завершена.

Конечно, это было бы слишком просто, и работало бы слишком хорошо, поэтому это явно не Linux-way.

Заботливые кернел-какеры предлагают вот такую опцию - https://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re58.html. Ну, типа, сделайте sleep 20, наверняка за это время все usb устройства будут найдены.

Леденящий душу пиздец. Программирование многопоточных программ на sleep, ага.

Истории про мою home #lab.

И вторая проблема - а как написать правильную конфигурацию GRUB, чтобы не надо было заморачиваться с probe всего и вся?

Флешка может использоваться на разном железе, и не всегда она будет hd0.

В итоге, решил я это так:

* На первой партиции, в которой лежит EFI, я кладу же и сам GRUB, с его конфигом, который устроен вот так:

https://github.com/pg83/lab/blob/master/lab/services/mk/boot.sh#L19-L28

set root=hd0,2
configfile /etc/grub.cfg
set root=hd1,2
configfile /etc/grub.cfg
set root=hd2,2
configfile /etc/grub.cfg
set root=hd3,2
configfile /etc/grub.cfg
set root=hd4,2
configfile /etc/grub.cfg

А дальше, на второй партиции лежит уже настоящий конфиг, который адресован относительно root:

https://gist.github.com/pg83/7941d82e39c6a019ce184e01572ed62d

GRUB тут себя ведет, как POSIX sh без set -e, то есть, просто пропускает все неуспешные команды, пока не сможет попасть в реально существующий конфиг.

Работает like a charm, загружается на любом моем конфиге.

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

Истории про home #lab.

Пока я переводил хосты на новую схему загрузки (с флешкой в качестве /dev/root), мне несколько раз пришлось пошатать #etcd.

Убрать с хоста, переналить хост, вернуть etcd с пустым начальным состоянием на хост, подождать, пока оно догонется с оставшихся реплик.

Два раза все прошло хорошо, на третий раз я осмелел, и решил устроить ученьки с disaster recovery.

Взял, и под живым инстансом etcd забил его базу из /dev/random, дождался, пока это все не дошло до кластера, ребутнул, переналил на новую схему, поднял пустой инстанс etcd.

В общем, провел пару часов за чтением документации, кластер оживил.

Но это было несколько сложнее, чем я ожидал.

Потому что кворум из двух машин перевел этот третий инстанс в состояние "never again", то есть, пометил его id как сломанный навсегда, и отказывался с ним иметь дело даже после переналивки.

Выяснилось, что надо вручную удалить из кластера этот id, и добавить новый инстанс с новым id.

Зачем так сложно, и зачем эта процедура отличается от предыдущей, не очень понятно.

Зато, КМК, теперь я получил некоторый опыт, и уверенность, что, в случае чего, данные в etcd я не проебу, и мне теперь не сташно класть туда какие-то master/original данные, а не только легко восстановимые копии.

Будни #bootstrap, #homelab, #lab короткая эволюция того, как я катаю код на свой флот.

Мой макетник (#ix) позволяет описать любую статическую комбинацию пакетов, с произвольными флагами для их настройки.

В принципе, этого достаточно, чтобы удобно описать конфигурацию одной машины. Собственно, так у меня и был описан мета-пакет, который и был установлен в мой #realm - https://github.com/pg83/ix/blob/main/pkgs/set/pg/ix.sh

В принципе, этого точно так же достаточно, чтобы описать конфигурацию небольшого кластера - вот, например, у меня по папочке с такими наборами на каждый хост - https://github.com/pg83/lab/tree/master/lab/hosts

Но это, конечно, неудобно.

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

https://github.com/pg83/lab/blob/master/lab/common/ix.sh#L23-L27

Вот, если наш текущий хост входит в определенную группу хостов, на нем поднимаем набор сервисов с определенными настройками.

Дальше - больше.

Дальше мы не хотим иметь этот json статическим, а хотим его генерировать на python. Вот, пример того, как такой json с описанием кластера может генерироваться на python:

https://github.com/pg83/lab/blob/5f6ebd3c236ba42793cfbf0a5ecbb148688dfda7/lab/ix.sh

А дальше Остапа понесло, он не смог остановиться, и применил свой любимый прием - eval(pickle.loads(base64.b64decode('...'))) (я сейчас явно слышу гомерический смех пяти человек). А, конкретно, давайте опишем состояние сервисов python объектами, сериазизуем их состояние, и будем использовать как описание кластера:

https://github.com/pg83/lab/blob/master/lab/cg.py#L9-L39

2 класса - сервиса, и производящая функция всего кластера, которая полностью описывает его структуру, имея на вход низкоуровневое описание кластера (сети, диски, и так далее).

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

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

#lab #homelab

https://github.com/francoismichel/ssh3 - прикольная штука, типа, "а давайте запилим ssh поверх стандартных web технологий", типа x509 сертификатов, http/3, quic, и так далее.

На Go, что приятно. В то, что openssh/dropbear написаны "аккуратно", я не верю, потому что на С нельзя писать сложные системы без проездов по памяти.

С точки зрения клиента оно пока довольно harsh, поэтому запилил несколько разных там улучшений:

https://github.com/francoismichel/ssh3/pull/139/files

Посмотрим, что скажут мейнтейнеры.

(особую гордость у меня вызывает способ, которым я зачинил то, что после добавления хоста в known_hosts клиента нужно было перезапустить - https://github.com/francoismichel/ssh3/pull/139/files#diff-8939e1ce1317af19fdceab3a5d7aabbac4949389802b082e926ed37b442fb4f7R203)

Продолжаю рубрику #делай_без_изъебов, #нормально_делай_нормально_будет.

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

Буду иногда писать про такой софт, по мере того, как он мне встречается.

https://github.com/slackhq/nebula

Очень приятная overlay network. Нужно это (мне) для того, чтобы с ноутбука ходить в свою home #lab откуда угодно. Ну и чтобы это было удобно, поэтому модель "bastion" мне не очень.

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

Узел определяется сертификатом, который ты подписываешь из CA, которое есть только на твоей машинке. В подписанные данные ты пишешь IP, сеть, и группы, к которым принадлежит этот хост.

Все максимально просто и понятно, в отличие от того же tailscale, при чтении документации на который хочется спрость "а нахуя вы тут нахуевертили столько???"

У меня nebula сейчас работает на всех хостах #homelab, но я пока не перевесил ssh daemon с настоящих IP на оверлейные, немного страшновато.

#lab #homelab

Я тут выбираю себе стор, для того, чтобы хранить всякого рода промежуточные артефакты своего кода и своих сервисов.

В целом, я посмотрел на свои задачки:

* обслуживать торренты прямо из сети, с кешом блоков в каком-нибуть распределенном хранилище

* кеш артефактов для #IX (кеш исходников, бинарные пакеты)

* распределенный стор для запускалки произвольных задач (к которым относится и CI для IX)

, и, мне кажется, что наиболее мне бы подошел локальный S3.

А дальше у меня вопрос:

* https://github.com/minio/minio

* https://github.com/seaweedfs/seaweedfs

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

Смотрел и код обоих поделий, и читал диздоки, читал, как развертывать. seeweed мне показался несколько более half baked, какие-то не очень связанные слои, и странные админские скрипты для управления этим барахлом, minio кажется более цельным решением.

Есть у кого опыт эксплуатации этих хреновин? Запилите прохладных!

Бесплатный сеанс психоанализа от дядюшки PG.

#homelab #lab, да и вообще любой pet project, типа моего #stal/ix, приятен тем, что можно сколько угодно времени тратить на всякую хуйню (по существу), но которая тебя лично напрягает.

Вот, например, меня очень сильно напрягало, что многие демоны принудительно и неотключаемо пишут .pid файл в свой cwd.

Это, наверное, было полезно, когда везде был sys-v init, но сейчас, в эпоху современных супервизоров, типа runit/openrc/etc, это все кажется довольно избыточным, и некрасивым.

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

У меня осталось буквально пара демонов, из которых они не выпиливались никак, кроме как правкой исходников, а этого я хотел избежать, поэтому я запилил регулярный скрипт, который просто стирает все .pid файлы из /var/run скопом - https://github.com/pg83/ix/blob/main/pkgs/bin/sched/stale/pids/pids.sh.

Так же у меня есть джоба, которая чистит ненужные хомяки, останки сервисов, и так далее - https://github.com/pg83/ix/blob/main/pkgs/bin/sched/stale/homes/homes.sh (кстати, хозяйке на заметку - comm, не знал о такой полезной разновидности diff)

При этом, я совершенно отчетливо понимаю, что, если бы я поставил себе (или кому-то еще) задачу в стиле "удалить все pid файлы за нашими демонами в проде" на своей day job (с тикетом в ST, а как же), то был бы послан далеко и надолго.

Поэтому, конечно, pet project - очень хороший способ "канализировать" такие свои странные желания, всем рекомендую.

Будни #bootstrap, #homelab, #lab

В итоге, я решил запилить и minio, и seaweed.

Начал я с minio, и, на днях, таки дополил свою инсталляцию до рабочего состояния, и положил в нее первую пару сотню гигабайт данных.

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

Напомню:

* в ДЦ у меня 3 настоящих бу-шных сервера, примерно одинаковой мощности.

* в каждом по 4 - 8 салазок для hdd/sdd того или иного фактора

* в каждом 4 гигабитных аплинка. В одном есть аплинк на 10 гигабит, но пока оставим это за скобками.

Мне хотелось построить такую конфигурацию, чтобы она уперлась в сеть.

С учетом того, что кластер я набивал hdd, а не ssd, и скорость одного hdd это и есть примерно гигабит, если нет рандомных скачков по диску, то логичной мне показалась схема, когда 1 hdd привязан к одному eth аплинку. Делать же bond интерфейсов мне не захотелось, так как это работало бы не очень предсказуемо по перфу.

Ну, то есть, я захотел на 3 хостах выделить по 3 hdd (всего 9), к каждому hdd был бы привязан 1 инстанс minio, который висел бы на своем eth{1..3} интерфейсе. eth0 я оставил для управления и прочего интерактивного трафика.

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

Самое близкое к тому, что мне было нужно - это конфигурация "3 стойки, в каждой по 3 хоста, в каждом по 1 диску". То есть, я отобразил host -> rack, и пару (host, eth) -> host, hdd -> hdd.

Если подумать, то это прямо то, что мне надо, потому что совпадает с моими failure domain, вот оно как.

К сожалению, без пердолинга патчинга minio тут не обошлось, так как он детектил, что я запускал несколько инстансов на одном хосте, способом, про который он ничего не знал, и отказывался работать.

Пришлось ему запилить режим "я мамой клянусь оно будет работать" https://github.com/pg83/lab/blob/master/bin/minio/patched/ix.sh, после чего все завелось.

Впереди учения по отключению "стоек" и отдельных "нод"!

#homelab #lab

Мне снова понадобилось навертеть дырок в своем NAT.

Схема, как в цитируемом посте, не очень масштабируется, поэтому у меня оставалось 3 выхода:

* попробовать настраивать роутер черз upnp. Настроить получилось, но, как выяснилось, upnp в моем роутере сломан напрочь, потому что просверленные дырки почему-то не открылись файерволом.

* запилить уже свой Linux router. Как и тогда, связываться с этим мне очень не хотелось, и не хочется.

* настроить проброс портов на роутере через его "API". API в кавычках, потому что это не API в классическом смысле, а просто последовательность вызовов HTML ручек web gui, с выковыриванием нужных данных из HTML регулярками.

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

Вот мой скрипт, если вдруг кому-то нужно - https://github.com/pg83/lab/blob/master/bin/xiaomi/api/xapi.py

#lab #home_lab

https://t.iss.one/itpgchannel/1827
https://t.iss.one/itpgchannel/1887

(по ссылкам - определение того, что я называю своими "датацентрами")

Тополиный пух, жара, и вот это вот все.

Первый датацентр приходится отключать, так как не выдерживает кондиционирование. Дело дошло ажно до того, что слетел контроллер SATA (правда, после охлаждения и парочки ребутов снова поднялся).

С другой стороны, два других датацентра справляются с CI на ура, minio/etcd, вроде, тоже работают, но уже без запаса.

Принудительные учения, ага.

#lab #home_lab #РКН

Провайдер начал резать wireguard, пришлось что-то изобретать.

Завернуть wireguard во что-то типа shadowsocks под Mac у меня ничего не вышло, и, кажется, я такой не один.

Так как я очень ленивая жопа, то проблему хождения в web я решил максимально эффективно:

ssh -D 10000 -N -i my.pem user@ip

Дальше прописал в firefox получившуюся socks5 proxy, и все заработало. Надеюсь, ssh пустят под нож последним, ладно, предпоследним, перед https.

В firefox, потому что вот так удобно, когда есть два браузера - медленный, но с vpn, и быстрый, но без.

Результат, в целом, удовлетворительный - https://www.speedtest.net/result/16813703179

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

#lab #home_lab #РКН

Каждую идею интересно довести до какого-то предела.

https://www.speedtest.net/result/16820727597

Вот, например, мой текущий setup - 3 ssh socks5 соединения на 2 vps в разных странах (6 линков всего), поверх #haproxy с round robin линков между соединениями.

(это не финальное состояние, дальше будет больше)

#lab #home_lab

В итоге, самым простым и дешевым оказался способ из https://habr.com/ru/articles/509666/ (спасибо моим радиослушателям за ссылку!).

Ну тупо потому, что такой девайс у меня уже был, и он взял, и заработал, без танцев с бубном:

CntR  390
Tamb  17.4125
CntR  390
Tamb  17.4125
CntR  390
Tamb  17.4125

Лежал, валялся без дела (думаю, из этих цифр понятно, почему), а тут пригодился.

#lab #home_lab

TIL что на серверном оборудовании надо совмещать фазу и ноль руками, то есть, правильно ориентировать вилку относительно розетки. Ну, по крайней мере, на некотором.

Сука, перевтыкал сервера из одного источника питания в другой, и меня шандарахнуло током с корпуса!

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

Как говорится, век живи - век учись.

Я вот как-то писал про свою личную OPS практику - периодический #reboot программ в проде (https://t.iss.one/itpgchannel/370)

Вот, хороший текст, подтверждающий эффективность такого подхода:

https://pushtoprod.substack.com/p/netflix-terrifying-concurrency-bug

"We created a rule in our central monitoring and alerting system to randomly kill a few instances every 15 minutes. Every killed instance would be replaced with a healthy, fresh one"

И я, кстати, совершенно не кривил душой, говоря про это.

Вот, например, я периодически рестартую свои #haproxy и ssh туннели для обхода блокировок (https://t.iss.one/itpgchannel/2262) в своей #lab #home_lab - https://github.com/pg83/lab/blob/master/lab/cg.py#L455-L457

#lab #home_lab

Теперь 3 vps, мир не без добрых людей.

Внезапно обнаружил, что 1 из vps помер месяц назад, из-за неуплаты, но весь комплекс продолжил работать, как танк.

Избыточность - хорошо!

Продолжение https://t.iss.one/itpgchannel/2199

#lab #homelab

Лаба замечательно перезимовала зиму, перезимовала в ящике, который на фото слева.

Да, просто сложил ее в ящик штабелем, и отрегулировал положение крышки ящика.

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

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

Пришла весна, достал лабу из сундука, и установил в стойку, надеюсь, уже надолго.

Будни #bootstrap

Случилось страшное, два одинаковых питона, собранных на двух разных хостах моей #homelab #lab:

lab1 # python3
Python 3.12.7 (main, Jun  9 2025, 09:12:41) [Clang 20.1.5 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import uuid
>>> ^D

lab2 # python3
Python 3.12.7 (main, Jun 10 2025, 11:25:34) [Clang 20.1.5 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import uuid
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ModuleNotFoundError: No module named 'uuid'
>>>

Я, конечно, предположил где такое может происходить (python frozen.py во втором случае не сумел понять, что используется модуль uuid, и не добавил его в заморозку), но выглядит максимально всрато.

Такие configure скрипты нам не нужны!