sr.ht, кстати, починили.

А я, кстати, хочу сказать, что, благодаря нашим анонимным благожелателям, пользователи #stal/ix этого даже не заметили, благодаря нашей мощной системе зеркал, которых ажно уже 9 штук!

https://t.iss.one/itpgchannel/1371
https://github.com/pg83/ix/blob/main/pkgs/die/scripts/mirrors.txt

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

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

https://t.iss.one/itpgchannel/1342
https://t.iss.one/itpgchannel/1300
https://t.iss.one/itpgchannel/1085

Немного довольно очевидных мудростей от PG.

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

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

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

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

Хороший пример - https://t.iss.one/itpgchannel/1605

Или утащу случай с работы.

Как-то мне нужно было сделать upver версии gdb для нашей инфраструктуры. gdb не обновлялся много лет, и вообще говоря, было неочевидно, что можно вот так взять новый бинарник с новой мажорной версией, и он возьмет, и заведется.

Поэтому, прежде чем бросаться и строить постоянное сооружение, я пошел и построил херобору - взял новую сборку из какой-то убунты. Эта сборка, конечно, не очень работала в нашей инфре, поэтому я положил рядом с бинарником какие-то недостающие .so со своей рабочей тачки, переписал динамический загрузчик в исполняемом файле, потому что glibc тоже пришлось положить рядом, положил рядом какие-то данные из ncurses, написал враппер, который бы выставил все пути для поиска локальной копии библиотек, упаковал всю эту херобору в tgz, и отправил в условный "testing" (на самом деле, "варить плашку", но это мало кому чего-то скажет).

Благодаря этой хероборе я сумел прикинуть масштаб проблем, и понял, что, в принципе, это подъемная задача, и начал ее "отливать в граните".

(работала ли эта херобора в нашем настоящем проде, история стыдливо умалчивает)

А я, тем временем, занялся автоматизацией своей home #lab.

Моя home lab - это 3 сервера, в которых примерно 200 ядер, + 3 - 4 небольших нод, которые сделаны из всякого хлама, скопившегося за несколько лет.

Понятно дело, что все это и так крутится под #stal/ix, но, до сего момента, все это выглядело так - я руками ставил OS на машину, а дальше заходил на нее через ssh, и руками вводил какие-то команды, которые что-то делали с этой машиной.

Конечно, можно было бы взять что-то готовое, но:

* нужно есть свою собачью еду.

* https://en.wikipedia.org/wiki/Content-addressable_storage - очень хорошая основа для всякого там IaC, и мне хочется сделать еще один подход к этому снаряду.

Если совсем коротко:

* Ручная наливка хоста заканчивается тем, что мы удаляем set/stalix из system #realm, и ставим туда почти то же самое, но с автоапдейтом.

* Автоапдейт занимается тем, что "приводит систему к состоянию", которое указано в каком-то заранее определенном репозитории.

Состояние - это набор пакетов, заданное состояние - это набор пакетов, который описан в какой-то конкретной версии репозитория.

https://github.com/pg83/lab - вот код, который полностью описывает состояние моей home lab.

Он состоит:

* Fork stal/IX, который я периодически сливаю с upstream.

* Одна точка входа, тот самый пакет, который содержит ссылку на auto updater, и на пакеты, которые должны стоять в системе - https://github.com/pg83/lab/tree/master/pkgs/lab https://github.com/pg83/lab/blob/master/pkgs/lab/ix.sh#L7

Я его устанавливаю на каждый хост, он ставит:

* сам auto updater. https://github.com/pg83/lab/blob/master/pkgs/lab/services/autoupdate/scripts/ix.sh - простой скрипт, который в цикле забирает новое состояние с github, и приводит систему в соответствие этому состоянию.

* пакеты, которые должны быть на каждом хосте

* и диспетчер, который ведет на список пакетов, уникальный для хоста - https://github.com/pg83/lab/blob/master/pkgs/lab/ix.sh#L6

Вот, например, список пакетов для "host1" - https://github.com/pg83/lab/blob/master/pkgs/lab/hosts/host1/ix.sh. Видно, что он крутит мой ci, и какую-то ерунду, про которую расскажу в другой раз.

Так, я на вас вывалил некоторый "framework", в рамках которого потом буду рассказывать про свой home lab.

Про пользу #etcd в home #lab.

В качестве роутера я использую коробочку от Xiaomi.

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

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

Но у этой коробочки есть один небольшой недостаток - она конфигурируется из web gui, и настроек там очень мало.

(openwrt? нет, не хочу, когда руки до этого дойдут, запилю свой роутер, на #stal/ix)

В общем, в форме, которая настраивает port forwarding, можно установить только один адрес на входящий порт.

А я, знаете ли, решил, что в моем home lab будет сколько возможно мало точек отказа.

Поэтому, когда я решил наконец-то настроить edge proxy, который бы занимался тем, что делал ретраи, разбрасывал запросы по бекендам, и делал dispatch по vhost, я приуныл.

Потому что если взгромоздить этот прокси на 1 тачку, то это +1 точка отказа, а если хочется взгромоздить на несколько, то смотри выше пункт про то, что в формочке можно указать только 1 адрес для одного внешнего порта.

У меня в голове закрутились слова IPVS, keepalived, и я, признаться, приуныл еще больше!

Вот, придумал решение, которое мне кажется не очень всратым, решает мою проблему, и не содержит слов ipvs, keepalived, и прочих ноковых приблуд.

У меня на трех хостах крутится скрипт, который в цикле пытается, под etcd lock, запустить прокси. Везунчик, который получил блокировку, вешает на eth0 какой-то заранее известный IP адрес, и запускает на нем proxy. А все остальные, если блокировку взять не удалось, у себя этот IP адрес убирают, чтобы он всегда был только на одном интерфейсе.

В роутере прописываю этот самый IP адрес.

Если хост умирает, то кто-то другой получает блокировку, и цикл повторяется.

Ну, то есть, получился такой автоматический failover, без IP балансировки нагрузки.

У этого решения есть понятные проблемы - что произойдет, если master умер "странно", Ну, вот, блокировку в etcd проебал, а IP адрес с интерфейса снять не получается? Не знаю, расцениваю вероятность этого, как довольно низкую.

Захотел добавить в свой home #lab инсталляцию minio.

Ну потому что у меня сейчас зеркало #stal/ix копируется на 3 хоста rsync-ом, для надежности, но, кажется, надо попробовать что-нибудь более индустриальное, с кворумом.

Так что я:

* Выяснил, что конфигурация < 3 хостов, < 3 дисков, меня не устаривает. 3x3 - самое то, с точки зрения выпадения хоста/диска.

* Выяснил, что до требуемого числа дисков мне не хватает "чуть-чуть", но придется разобрать зеркала, и прочие массивы.

* Решил, что а нафиг мне выделенные диски под систему, и решил, что нужно, в срочном порядке, опробовать новую (для меня) схему установки stalix. Я давно хотел попробовать схему "налить универсальную флешку", которую, если вставить в правильный usb порт какого-то хоста, то она дальше все сделает сама - получит нужную конфигурацию, in place переконфигурируется под нужную роль, и продолжит работать. Да, да, система - на внешней флешке, воткнутой в usb port. Наверное, дико, но, с точки зрения введения нового хоста в строй для меня это явная экономия усилий, ну и место не пропадает почем зря.

* Пока учился устанавливать EFI + GRUB на флешку, пару раз убил загрузчик своего ноутбука.

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

* И вот, я здесь, продолжаю информировать почтеннейших слушателей о своих "приключениях"!

https://www.opennet.ru/opennews/art.shtml?num=60880
https://www.opennet.ru/opennews/art.shtml?num=60877

#xz_gate

Прекрасная детективная история про то, как несколько (или один) очень мотивированных людей встроили эксплоит в кодовую базу xz.

Не менее прекрасно и то, как эксплоит был найден:

https://mastodon.social/@AndresFreundTec/112180406142695845

"I was doing some micro-benchmarking at the time, needed to quiesce the system to reduce noise. Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc. Profiled sshd, showing lots of cpu time in liblzma, with perf unable to attribute it to a symbol. Got suspicious. Recalled that I had seen an odd valgrind complaint in automated testing of postgres, a few weeks earlier, after package updates.

Really required a lot of coincidences"

А что же #stal/ix?

А stal/ix эксплоиту не подвержен, по двум причинам:

* IFUNC не работает со статической линковкой. Это ограничение не принципиально, можно и завести, но всем лень.

* Более интересная причина - потому что я проактивно борюсь с такого рода возможностью, когда сумасшедший мейнтейнер может учудить, и не беру tgz, сваренные человеком, а беру tgz, сваренные системой контроля версий (прямые ссылки на архивы бранчей и коммитов) - https://t.iss.one/itpgchannel/93.

UPD: https://github.com/tukaani-project/xz - репу закрыли :(

Будни #bootstrap

Продолжаю тему bump alloc, https://github.com/pg83/ix/blob/main/pkgs/lib/bumpalloc/alloc.c

Забавно, но в моей кодовой базе (уникальный код, который я пишу для #stal/ix), использование этого bump alloc только растет:

* Про много мелких программ заранее известно, сколько они съедят памяти.

* Я ненавижу С, потому что без RAII/GC программировать невозможно (с этим согласны даже разработчики одной из самых больших кодовых баз на C - Linux Kernel (если вы не согласны, то что такое RCU, как не форма примитивного GC?)). Но вот если не освобождать за собой память, то программирование программ на C - это почти как программирование программ на Go. Важно, что именно программ, потому что вся обработка ошибок сводится к panic()

* В целом, если мне надо запилить что-то low level, то я либо пишу это на таком вот диалекте C (без free, и с минимальной обработкой ошибок, без return err), либо не пишу вовсе.

Вот, запилил очередную мелкую программулю, вместо которой у меня был скрипт на posix shell - https://github.com/pg83/ix/blob/main/pkgs/bin/cg/unwrap/main.c

Она занимается тем, что запускает другую программу в cgroup, а потом, после ее выхода, прибивает всю cgroup, чтобы не оставалось ошметков в виде stale процессов.

Красота-то какая, лепота!

10 килобайт на диске, ни одной аллокации, если запустить strace, то можно про каждый syscsall сказать, что он делает, и зачем, и почему без него не обойтись.

Как в старые добрые времена DOS, и дискеток на 1.44 мегабайт.

Бесплатный сеанс психоанализа от дядюшки 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 - очень хороший способ "канализировать" такие свои странные желания, всем рекомендую.

Нам тут пишут, что systemd собрали с musl.

https://www.opennet.ru/opennews/art.shtml?num=61818

Неожиданно, что эта новость привлекла какое-то внимание, потому что systemd с musl собирали уже несколько раз, и, например, даже я это как-то сделал, в рамках #stal/ix. Ничего особо сложного в этом не было.

Я сделал даже больше, я его собрал в статически слинкованном виде!

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

Ну и, в целом, мне бы хотелось, чтобы в мире Linux было какое-то разнообразие, и тот же Alpine на systemd не заглядывался, потому что так оно здоровЕе.

Будни #bootstrap

В очередной раз переделал цепочку bootstrap.

Раньше, на самых ранних стадиях, у меня был сумасшедший скрипт, которые пытался найти подходящий компилятор и shell, а дальше все работало с этими компилятором и shell.

Маленькая проблема заключалась в том, что происходило это в runtime, и команда не зависела от окружения. То есть, могло что-то сломаться, человек менял компилятор или shell, и дальше все ломалось, потому что компилятор и shell были уже закешированы.

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

Финальный аккорд выглядит как-то так - https://github.com/pg83/ix/blob/main/pkgs/bld/boot/0/ind/ix.sh

На самом деле, изменений по всей пакетной базе было сделано очень много, но показывать их особого смысла нет.

Главное - цепочка стала гораздо более робастной, и устойчивой к изменениям окружения, которые могут случаться у пользователей, во время установки #stal/ix

https://www.opennet.ru/opennews/art.shtml?num=62321

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код в загружаемое ядро Linux"

#stal/ix, конечно, это не подвержен, потому что:

"Указанный обработчик вносит изменения в загруженные в память функции ядра (отключает проверку модулей по цифровой подписи), а также изменяет строку запуска процесса инициализации с "/init" на "LD_PRELOAD=/opt/injector.so /init)".

Библиотека injector.so перехватывает некоторые операции SELinux и функцию init_module, которая затем используется для загрузки модуля ядра /opt/dropper.ko. ..."

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

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

Будни #bootstrap, #rant

Обновлял rqbit.

Это который упаковывает кучу js кода себе в бинарь, и вызывает для этого npm - https://t.iss.one/itpgchannel/2410

Обновление упало с ошибкой - https://gist.github.com/pg83/cd1ec54f5a4fd4f2e5cfc4b82e063c12

TL;DR - при обновлении приехал новый https://vite.dev/, который притащил за собой новый https://github.com/rollup/rollup (не спрашивайте, это говно бандлит JS код в 1 файл), который переписали на "мамой-клянусь memory safe" языке (https://github.com/rollup/rollup/tree/master/rust), а чтобы не портить пользователям малину, положили в пакет предкомпилированные даже не бинари, а .so для nodejs.

Вона там их сколько, даже для loongson есть:

https://github.com/rollup/rollup/blob/master/package.json#L19-L37

(для #stal/ix нет, ага)

Да, да, никогда такого не было, и вот, опять, зумеры подложили очередную вирусню в репу очередной supply chain attack:

#blob

https://t.iss.one/itpgchannel/1281
https://t.iss.one/itpgchannel/1301
https://t.iss.one/itpgchannel/2264
https://t.iss.one/itpgchannel/2084
https://t.iss.one/itpgchannel/1789
https://t.iss.one/itpgchannel/535

Что я сделал?

Даунгрейднул все эти зависимости, и все заработало:

https://github.com/pg83/ix/blob/main/pkgs/bin/rqbit/ix.sh#L22-L23

Что я буду делать, когда оно перестанет так собираться?

Стану проституткой!

Не знаю, изучу JS, наушники с котоушками у меня уже есть https://t.iss.one/itpgchannel/2444.

Будни #bootstrap

В саппортный чат #stal/ix (не ищите, там нет ничего интересного) пришел интересный коллега, и рассказал, что он случайно пришел к такому же дизайну пакетного менеджера, и OS на его основе:

https://ccx.te2000.cz/stagit/pthbs/file/README.html (диздок 1-в-1 как у IX)

Понятное дело, что тут очень много схожего с прародителями, типа Nix/Guix, но вот есть важная деталь, которая обеспечивает новизну этого дизайна:

"Jinja-based templating system for generating package definitions for pthbs"

https://ccx.te2000.cz/stagit/mrrl/file/templates/pkg/bison.html - вот, например, его пакет с bison.

Много общего с тем, как устроено у меня.

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

https://www.opennet.ru/opennews/art.shtml?num=63182

"Подход к обработке ошибок в Nimony претерпел значительные изменения. Автор Nim выражает неудовлетворённость традиционными механизмами исключений и их эмуляцией через алгебраические типы данных (sum types). Вместо этого предлагается концепция интеграции состояния ошибки непосредственно в сам объект данных. В качестве примеров приводятся: представление ошибки в потоках ввода-вывода через специальное состояние, использование NaN для чисел с плавающей запятой, или low(int) для невалидных целочисленных значений. В случаях, когда объект не может инкапсулировать состояние ошибки, предлагается использовать потоко-локальную (thread-local) переменную для сигнализации"

Эх, забавный был язык, я даже хотел написать на нем пару программок для #stal/IX, но его автор, очевидным образом, сошел с ума - говорит, в каждом типе данных должен быть особый sentinel.

Это уже не говоря про то, что он хочет уметь расширять синтаксис загружаемыми #plugins!

Никогда #stal/#IX не был так свеж!

https://www.warandpeace.ru/ru/news/view/197544/

"На разработку "Золотого купола" планируется направить 25 миллиардов долларов в следующем бюджете США, а общие затраты могут превысить 500 миллиардов долларов в течение 20 лет, отмечает CNN. В числе главных претендентов на реализацию проекта — компании SpaceX, Palantir и Anduril"

Anduril - компания, которая стоит за #nixgate (https://t.iss.one/itpgchannel/1882), поэтому, если вы контрибутите в #nix, то вы контрибутите в проклятых американских военных, которые будут сбивать православные русские ракетки!

Поэтому не надо контрибутить в nix, а надо контрибутить в #stal/#ix, проекту нужны ваши руки!

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

https://github.com/pkgforge

Вот есть такой проект.

Суть его в том, чтобы распространять готовые, статически слинкованные, бинари, чтобы они портабельно работали на всех Linux.

https://pkgs.pkgforge.dev/ - поиск по готовым бинарям
https://github.com/pkgforge/soarpkgs - вот тут, кажется, у них рецепты "как натырить побольше готовых бинарей с релизных страниц на gihub".
вот тут они развлекаются с appimage - https://github.com/pkgforge/pkgcache
https://github.com/pkgforge/soar - пакетник на "almost memory safe", ага.

В общем, они решили взять #stal/#IX как источник для таких бинарей, запилили #rootfs для докера, в котором лежит образ stal/ix, и через него можно собрать произвольный мой артефакт - https://github.com/pkgforge-community/stalix-pkger

Такие дела.

Будни #bootstrap #rootfs

https://huggingface.co/datasets/stal-ix/rootfs/tree/main

Под давлением общественности, начал готовить регулярные снепшоты rootfs для #stal/ix - можно скачать, войти в них, с помощью вашей любимой контейнерной изоляции (minijail/bwrap/pivit_root/chroot (только не забудьте про сеть, маунты /dev, /proc, /sys)), и можно попробовать позапускать команды из настоящего, живого, #stal/ix.

Тут вот один наш коллега показал, как у него хостилось зеркало #stal/ix, я аж смахнул слезу умиления, увидев знакомый логотип.

И второе событие за день - в проекте появился второй человек с правом записи в master:

https://github.com/stal-ix/stalix/people

Пока не в сам пакетник, а во вспомогательный репозиторий:

https://github.com/stal-ix/stalix

Натурально, пришел человек с улицы, и сказал, что хочет делать регулярные релизы #rootfs для #stal/ix, их можно использовать:

* Для ускорения процедуры установки.

* Для сборки произвольного статически слинкованного пакета из состава #IX.

Ебался с этим два месяца, и таки запилил!

Планов у него, мягко говоря, много:

https://github.com/stal-ix/stalix/issues/3

Такой сегодня день.