Будни #bootstrap, #gold

Проснулся сегодня с мыслью, что именно сегодня, хоть тушкой, хоть чучелом, хоть вызовом https://play.rust-lang.org/?version=stable&mode=debug&edition=2021 по http, но я затащу Rust в #ix.

Потому что ну сколько можно? И потому что мне нужно было обрести уверенность, что выбранный мной способ #bootstrap, рано или поздно, но приведет к работающему результату.

В #stal/ix теперь есть #rust!

Пока не #bootstrap, пока просто сборка с оффсайта, творчески перепаханная, чтобы уметь работать в full static environment:

* https://github.com/pg83/ix/blob/main/pkgs/bld/musl/ix.sh - сборка shared musl, с динамическим загрузчиком. Особое внимание стоит обратить на мою великолепную реализацию динамических исключений (libgcc_s.so.1) - https://github.com/pg83/ix/blob/main/pkgs/bld/musl/ix.sh#L22-L69

* С помощью patchelf перепахиваем скачанный дистрибутив, чтобы он использовал мой ld.so - https://github.com/pg83/ix/blob/main/pkgs/bld/rust/linux/unwrap/ix.sh#L20-L23

* Цимес, мякотка, соль всего процесса - https://github.com/pg83/ix/blob/main/pkgs/die/rust/cargo.sh#L30-L65 - хрень, которую я подсовываю в rustc в качестве С/С++ компилятора (и линкера). Она решает творческую задачу по редактированию строки вызова компилятора так, чтобы, когда надо, это была динлинковка с моим musl (для последующей загрузки получившейся .so компилятором rustc), а, когда надо, статлинковка финального артефакта.

Заняло это всего час времени.

Нет, реально, все оказалось проще, чем я изначально предполагал, оно просто взяло, и заработало.

Это не финальный результат, но:

* Уже можно использовать какие-то полезные программы на rust, хотя они еще не bootstrapped.

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

Продолжаем развенчивать мифы про 3D ускорение терминала. #terminal

Раз уж я заполучил #rust (https://t.iss.one/itpgchannel/1605), то теперь у меня есть работающий #alacritty!

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

#alacritty:

real  0m1.039s
user  0m0.000s
sys  0m0.396s

#foot:

real  0m0.597s
user  0m0.000s
sys  0m0.362s

Что это значит?

Это значит, что, несмотря на свою похвальбу, alacritty не является самым быстрым терминалом, и что 3D ускорение в терминале - совершенно необязательно для комфортной работы.

Ссылки:
https://t.iss.one/itpgchannel/133
https://t.iss.one/itpgchannel/119
https://t.iss.one/itpgchannel/39

UPD: в коментах меня попросили побенчмаркать не бинарный треш, а что-то другое.

Вот, вывод на экран 150 мегабайт текста:

alacritty:

real  0m2.920s
user  0m0.000s
sys  0m1.456s

foot:

real  0m2.059s
user  0m0.000s
sys  0m1.534s

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

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

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

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

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

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

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

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

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

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

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

V2:

У канала есть флудилка, там можно обсудить мои тексты, и просто пообщаться на разные темы - https://t.iss.one/it_pg_talks

О чем я тут пишу:

Мама, я мейнтейнер:

https://stal-ix.github.io/

- https://t.iss.one/itpgchannel/376
- https://t.iss.one/itpgchannel/377
- https://t.iss.one/itpgchannel/379
- https://t.iss.one/itpgchannel/467
- https://t.iss.one/itpgchannel/545
- https://t.iss.one/itpgchannel/572
- https://t.iss.one/itpgchannel/757
- https://t.iss.one/itpgchannel/824
- https://t.iss.one/itpgchannel/1261
- https://t.iss.one/itpgchannel/1608

Как настроить зеркало stal/IX:

- https://t.iss.one/itpgchannel/1371

#ix как пакетник для разработки:

- https://t.iss.one/itpgchannel/882
- https://t.iss.one/itpgchannel/898
- https://t.iss.one/itpgchannel/965
- https://t.iss.one/itpgchannel/1422

https://en.m.wikipedia.org/wiki/Bootstrappable_builds:

- https://t.iss.one/itpgchannel/20
- https://t.iss.one/itpgchannel/207
- https://t.iss.one/itpgchannel/221

Эстетика статической линковки:

- https://t.iss.one/itpgchannel/705
- https://t.iss.one/itpgchannel/709

Rant & wisdom:

- https://t.iss.one/itpgchannel/660
- https://t.iss.one/itpgchannel/710
- https://t.iss.one/itpgchannel/1572
- https://t.iss.one/itpgchannel/1279
- https://t.iss.one/itpgchannel/1639

(продолжаю https://t.iss.one/itpgchannel/1730)

Собственно, с помощью этой херОборы я вполне успешно собрал darwin patch.

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

Настойчивый читатель спросит, а нафига все это нужно, если результат уже был получен?

* Это интересно!

* Мне всегда казалось, что миру не хватает "FreeBSD с content addressable package manager", если вы понимаете, о чем я (#ix). Вот, теперь я могу поэкспериментировать и в эту сторону тоже.

И, с учетом того, что я уже не влез в размер одного поста в телеге, продолжение цикла историй о трех херОборах - в следующих сериях!

В фоне продолжаю заниматься своей home #lab.

Там уже 3 ноды, автоматическая наливка с 0, нормальная сеть между всеми узлами (2.5gb), IaC для выкладки (конечно же, на основе #ix), сервисы сами рассказывают про себя через mdns, и вообще, красота.

Коллеги, а порекомендуйте нормальную очередь задач для распределенного кластера?

Я это вижу примерно так - etcd + какая-то встраиваемая библиотека, которая реализует скучные вещи, типа очередей поверх etcd, какой-нить простой work stealing алгоритм шедулинга, эфемерные ноды для каждого хоста, разгребающего очередь, для того, чтобы задачи с упавших нод прозрачно возвращались в общую очередь, и прочий crud.

Вот, например, как https://github.com/lytics/metafora, только живое, и чтобы звезд побольше?

Будни #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 каждого сервера запущена рутовая консолька, физически доступная только в моем ДЦ.

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

Я как-то косвенно упомянул #heirloom https://heirloom.sourceforge.net/ , это аналог coreutils/busybox, но только родом из традиционных UNIX, типа Sun, Caldera.

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

Ну, типа, configure скрипты gnu grep/awk/diff/patch/sed/etc требуют уже работающих awk/grep/sed/diff/etc.

Раньше, когда я только начинал пилить #ix, я использовал heirloom как "начало начал" - имея только libc, нужно получить хоть какие-то unix тулзы, чтобы дальше собирать что-то еще.

Вот у меня был самый отвратительный shell script ever - https://github.com/pg83/mix/blob/main/pkgs/bld/boot/2/heirloom/darwin/ix.sh#L70-L95

Тут literally описан порядок сборки всяких mkdir/cp/rm, чтобы дальше можно было собрать что-то еще, из поставки heirloom.

Я постепенно заменял этот скрипт на:

* sbase - для базовых утилит, из проекта suckless - https://core.suckless.org/sbase/ (там есть слабенький grep, и sed, который падает в корку)

* minised - https://github.com/bostikforever/minised

* bmake - https://www.crufty.net/help/sjg/bmake.html - реализация make, которую можно собрать через cc *.c https://t.iss.one/itpgchannel/82

* и, вот, появилась новая реализация awk, для проекта https://github.com/landley/toybox (https://t.iss.one/itpgchannel/145), которая зависит только от C - https://github.com/raygard/wak

Я, конечно, добавил ее в процесс бутстрапа, и отправил этот гадкий скрипт на заслуженный отдых, потому что heirloom больше не участвует в моей процедуре bootstrap!

Будни #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

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

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

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

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

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

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

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

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

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

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

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

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

Будни #bootstrap, stal/#ix

А у меня случилось 10к коммитов в репу со stal/ix, https://github.com/pg83/ix/commit/34311a72ea4c5a62edb6a40ad21a1d72f80cdb7a!

(и это без учета того, как проект жил в моем хомяке, а потом под брендом #mix)

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

https://discourse.nixos.org/t/nix-team-member-suggests-removing-flakes-data-suggest-it-isnt-a-good-idea-please-remove-the-experimental-flag-instead/54959

Как известно, nix един в трех Ф:

* Фурри
* Фембои
* Флейки (flakes)

Вот, третий столп у них хотят выбить из под ног.

Зачем?

Я понятия не имею, давно запутался в их Санта-Барбаре, и перестал следить.

Вот, кстати, мой вариант dev env:

pg# ix run \
    bin/bash/5 \
    bin/coreutils \
    bld/compiler \
    -- bash
pg# llvm-nm --version
llvm-nm, compatible with GNU nm
LLVM (https://llvm.org/):
  LLVM version 19.1.2
  Optimized build.
pg#
exit
pg# llvm-nm --version
bash: llvm-nm: command not found
pg#

Можно обернуть в какой-нить run.sh, можно даже сделать команду ix env, но зачем, непонятно, потому что и так хорошо.

Фиксацию зависимостей я заменяю на предложение брать #ix из определенного коммита, или делать overlay.

Зачем уметь фиксировать версии всех зависимостей, с одной стороны, понятно, а с другой, много понятных проблем:

* Помимо фиксации версий, все равно, надо привязываться к конкретной версии nixpkgs, иначе под вами могут просто убрать пакет (переименовать).

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

Поэтому lock файл я пока делать не хочу.

Никогда #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

Такие дела.

https://github.com/pg83/ix/commit/f3a90fb63d77c00d1c65b60d817bc214413f689a

У нас в проекте случился первый серьезный (большой, сложный, трудозатратный) вклад в развитие непосредственно пакетника #IX, от наших пользователей!

https://github.com/pg83/ix/pull/24

https://github.com/stal-ix/stal-ix.github.io/blob/main/ASAN.md

Что?! Да!!

Никто не умеет, а мы теперь умеем:

* сборка с address sanitizer, с musl (а не с glibc)

* с musl, да не просто так, а со статически слинкованным!

Это, реально, очень круто, в мире так никто не умеет!

Я, если честно, просто в восторге.

КДПВ: https://gist.github.com/pg83/82b4d3c75016086a0412920181333bfa

И второе событие за день - в проекте появился второй человек с правом записи в 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

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

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

"В пакетных менеджерах GNU Guix, Nix и Lix выявлены уязвимиости (Nix, Guix, Lix), позволяющие выполнить код с правами пользователей, под которыми запускаются сборочные задания (например, nixbld* в Nix/Lix), что может использоваться для записи своих данных в сборочное окружение и внесения изменений в сборочный процесс. Проблемы присутствуют в фоновых процессах guix-daemon и nix-daemon, применяемых для организации доступа непривилегированных пользователей к сборочным операциям"

Я, когда дизайнил это место в #IX (https://t.iss.one/itpgchannel/179, тогда это еще называлось #mix, до ребрендинга, #security), смотрел на то, как это сделано в nix и guix. Мне это место с демоном показалось довольно тонким, и я решил, что имеющейся у меня изоляции не хватит на то, чтобы гарантировать безопасность.

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

Фактически, любой вызов ix build у меня содержит вызов su -s /bin/sh ix -- executor ..., для непосредственного применения построенного графа к системе (в других терминах, конечно, потому что у меня нет классических способов поменять пользователя, #suid).

Натурально, можешь стать пользователем ix - можешь менять систему.

Поэтому такой проблемы у меня нет, и быть не может.

Будни #bootstrap, #ix

pg:home# ./ix build bin/b64 --target=freebsd-x86_64
...
pg:home# readelf -a .../bin/base64 | grep OS/ABI
  OS/ABI: UNIX - FreeBSD

https://github.com/graphitemaster/detour

Ого, кто-то сумел это соорудить:

At its core, Detour is a minimal bootstrap layer that gives your application access to the system dynamic linker ld-linux.so without requiring libc at all. It allows:

* Dynamically loading libraries without linking libc
* Capturing libdl functionality (e.g., dlopen, dlsym) inside a fully static executable
* Mixing different libcs in one process
* Creating freestanding, zero-libc ELF executables

TL;DR - статический stub, который умеет загружать в адресное пространство процесса системный динамический загрузчик, и, с его помощью, загружать системные .so.

Сделано весьма изящно:

It works like this:

* We provide a tiny stub ELF executable that is dynamically linked against the system dynamic linker.
* Your actual program (which Detour bootstraps) loads this stub ELF using a minimal ELF loader.
* Detour reads the stub executable's PT_INTERP segment and loads the specified dynamic linker, just like the kernel would.
* Before jumping into the dynamic linker, Detour calls setjmp to capture its current state.
* It then jumps into the dynamic linker, forwarding the stub ELF and original arguments as if it were the kernel.
* The dynamic linker maps in and initializes the stub ELF, then calls its main function. That main receives a string argument containing a function pointer encoded as a hex string. It decodes the address, casts it to a function pointer, and calls it.
* This function captures symbols like dlopen, dlsym, dlclose, dlerror, and then calls longjmp to return to the original application.
* Now, back at your main program's entry point, you have full access to the dynamic linker without ever linking against libc.

It is a trampoline: a short, carefully orchestrated detour through the dynamic linker, giving you just enough of its guts to carry on without ever depending on it directly

Прямо мое уважение.

UPD: зачем это?

* Например, я могу сделать статический бинарь, который загрузит системную mesa, вместо того, чтобы вкомпилять драйвер в себя. Это не нужно в stalix, но для "#IX as a package manager" может быть очень полезно.

* Можно получить бинарь, который работает в ЛЮБОМ Linux, не только в том, где он скомпилен, при этом, он будет использовать системные .so, неважно, musl это, или glibc.