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

Я тут, раз уж у меня большой парк личного железа в личном ДЦ, запилил новый flavor stal/#ix - server. Включение его выглядит вот так - https://github.com/pg83/ix/blob/main/pkgs/set/system/0/server/ix.sh

А используется вот так - https://github.com/pg83/ix/blob/main/pkgs/set/system/0/unwrap/ix.sh#L6

По сути, немного другой набор софта, собранного с чуть другими флагами. Реально, зачем на сервере нужен console greeter, и зачем на сервере нужен iwd? Вряд ли кто-то в своем уме будет гонять серверные нагрузки через wifi.

Так же там отключены демоны звука, seatd, и так далее.

Чуть более интересна вот эта вот строчка - https://github.com/pg83/ix/blob/main/pkgs/set/system/0/unwrap/ix.sh#L7

Тут написано, что у меня на серверах полностью отсутствуют (штатные) privilege escalation механизмы.

Я несколько раз писал, что у меня нет #suid бинарей вообще, и что для повышения привилегий у меня используется кастомно перепиленный ssh daemon, с авторизацией по ключам. То есть, повысить привилегии может тот, у кого есть правильный ключ, а не пароль от рута. (https://t.iss.one/itpgchannel/1544 #suid)

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

Зачем? А не знаю, зачем.

За все время эксплуатации своей #lab мне ни разу не пришлось им воспользоваться. В целом, пакетная система работает очень хорошо, и мне ни разу не пришлось заниматься recovery. А если бы было надо - то у меня временно на vt 1 каждого сервера запущена рутовая консолька, физически доступная только в моем ДЦ.

Поэтому ответ - "а почему бы и нет, попробуем пожить так".

Будни #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 на оверлейные, немного страшновато.

Кстати, таки перевесил.

Теперь dropbear у меня слушает только на оверлейных адресах, но я, на всякий случай, поднял ssh3 на все остальное.

Почему так?

Потому что, как вы знаете, я не верю, что на C можно написать софт без проездов, но верю, что на Go - можно.

Поэтому dropbear висит на адресах, активность на которых может быть только от доверенных источников, как-то так.

#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

Продолжение 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 скрипты нам не нужны!