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

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

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

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

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

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

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

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

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

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

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

Будни #bootstrap

Я настолько задолбался, что сел, и запилил свой велосипед.

Его формат - максимально простой.

Это пожатый \n-delimited json, примерно такого содержания:

{"type": "file", "data": base64(data), \
 "path": "a/b/c.x", "flags": ["exe"]}
{"type": "dir", "path", "x/y/z"}
{"type": "symln", "path": "a", "to": "c/d"}

Да, да, это текстовый формат (не так, как в дурацком nar, а действительно текстовый):

* не нужно велосипедить парсер

* для отладки (поиска отличий) достаточно diff

* парсеры и сериализаторы json настолько быстрые (https://github.com/simdjson/simdjson), что даже оставляют за собой всякие бинарные форматы, типа protobuf. Ну потому что json мы перекладываем чаще всего, вот он и соптимизирован в хламину

* после сжатия каким-нить нормальным компрессором (я взял zstd -10), вы не увидите разницу между моим форматом, и специализированным бинарным, потому что все ключи часто повторяются, и займут примерно 0 байт, ну а то, что compress(base64(data)) ~~ compress(data) - факт довольно очевидный.

https://github.com/pg83/ix/blob/main/pkgs/bld/pzd/scripts/ser.py - вот, например, компрессор
https://github.com/pg83/ix/blob/main/pkgs/bld/pzd/scripts/des.py - а вот декомпрессор

Да, на python, потому что на golang заняло бы в 2 раза больше строк, а работало бы так же, потому что json в python соптимизирован в хлам, но требовало бы бутстрепа golang, а python у меня есть всегда.

Вот эти вот несчастные 50 строк кода:

* работают на полтора десятичных порядка быстрее, чем мой предыдущий вариант на shell, который на каждый файл зовет chown/chmod (чтобы привести все к одному набору флагов). Нет нужды оптимизировать, потому что стало о-малое от времени на download всего этого дела.

* решили вообще ВСЕ накопившиеся у меня проблемы с этим форматом

Надо было сразу не бояться велосипедить, и сделать все по уму!

Назвал я его, конечно, .pzd, от Packed ZstD

Вышли coreutils 9.5 https://www.opennet.ru/opennews/art.shtml?num=60872

Все бы хорошо, но:

"Сокращено время запуска утилиты sort за счёт прекращения динамического связывания с библиотекой libcrypto в ситуациях, когда не указана опция -R"

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

Поэтому мы не будем линковаться с ним в процессе сборки, но обязательно позовем в runtime, со всеми вытекающими (код будет работать по разному у тех, кто поставил себе openssl, а кто - нет)

Я как-то косвенно упомянул #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://xn--r1a.website/itpgchannel/82

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

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

После этого вашего #xz_gate какие-то хаотические движения во всем open source:

Кто-то обсуждает отказ от xz.

Кто-то пилит способ воспроизвести все окружение, нужное для того, чтобы запустить эту дырень - https://github.com/amlweems/xzbot, прямо https://anekdotov.net/anekdot/all/bspkstvskrnnvsh.htm

кто-то предлагает пострипать лишние зависимости у systemd - https://www.opennet.ru/opennews/art.shtml?num=60912 Наверное, люди уже написали весь важный код, и надо писать не очень важный.

Кто-то пишет большие заметки, пытаясь срубить хайпа на великих (Кен Томпсон с его trusting trust) - https://joeyh.name/blog/entry/reflections_on_distrusting_xz/

Кто-то вендорит xz (https://github.com/Genivia/ugrep):

Making all in lzma/C
  CC       libviiz_a-viizip.o
  CC       libviiz_a-7zAlloc.o
  CC       libviiz_a-7zArcIn.o
  CC       libviiz_a-7zBuf.o
  CC       libviiz_a-7zBuf2.o
  CC       libviiz_a-7zCrcOpt.o
  CC       libviiz_a-7zDec.o
  CC       libviiz_a-7zCrc.o
  CC       libviiz_a-7zFile.o
  CC       libviiz_a-7zStream.o
  CC       libviiz_a-Bcj2.o
  CC       libviiz_a-Bra86.o
  CC       libviiz_a-Bra.o
  CC       libviiz_a-BraIA64.o
  CC       libviiz_a-CpuArch.o
  CC       libviiz_a-Delta.o
  CC       libviiz_a-Lzma2Dec.o
  CC       libviiz_a-LzmaDec.o
  CC       libviiz_a-Ppmd7.o
  CC       libviiz_a-Ppmd7Dec.o

Я вот дернул кофе, и написал этот обзор.

Продолжение темы #jpeg_xl (а я эту новость вижу именно в таком контексте)

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

Гугл выкатили библиотеку, которая может пожать в обычный jpeg так, что качество будет сравнимо с Jpeg XL.

Это, конечно, неожиданный поворот во всей этой истории, дааа.

https://discourse.llvm.org/t/rfc-improve-binary-security/78121

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

Пользуясь случаем, хочу сделать рекламу нашему (корпоративному) toolchain registry - https://github.com/yandex/toolchain-registry/releases/tag/clang16-v3

Там лежат тулчейны, которые:

* воспроизводимо собираются

* мы их используем для сборки наших open source проектов (да и внутри тоже)

Хозяйке на заметку.

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

Вопрос на засыпку - как ведет stdin/stdout в вашей программе grep (просто для примера, можете взять awk, или sed), с точки зрения буферизации?

Далее ответ на этот вопрос. Вернее, не ответ per se, а набор фактов, которые помогут вам на него ответить:

* Стандарт C, и стандарт POSIX оставляют это unspecified. Ну, то есть, in the wild, вы можете встретить любое поведение.

* glibc соблюдает старую юниксовую традицию - если stdout соединен с tty (ну, считайте, программа запущена в interactive shell), то stdout будет line buffered (то есть, как только в буфер пришел \n, его содержимое сбрасывается в файловый дескриптор). Если не соединен, то stdout buffered, а stderr всегда unbuffered (и это правильно, потому что вы хотите видеть последнее сообщение, которое написала программа перед тем, как умереть по SEGFAULT).

* musl - вроде, тоже, но я не смог там быстро найти проверку, которая бы включала line buffered явно.

* дело усложняется тем, что произвольная программа может положиться на поведение этих потоков по умолчанию, а может как позвать setvbuf(чтобы поменять дефолт), так и звать fflush() в нужных местах. При этом, программа может настаивать на повторении вот этой вот традиции UNIX, то есть, для libc, которая не поддерживает такое соглашение, звать fflush() самостоятельно, или не звать, если считает, что libc устроена согласно разумению этой программы.

* все это усугубляется configure скриптами, которые могут неправильно понять default для нижележащей libc.

Короче, вы поняли - in the wild можно встретить почти любую комбинацию этих поведений, и заранее понять это довольно сложно.

Почему я про это решил рассказать?

Очевидно, потому что столкнулся со странным поведением одного скрипта, который по разному себя вел в процессе отладки, и во время работы в production.

Потратил на #debug пару часов, в результате заменил вызов на gnugrep --line-buffered, чтобы уж точно не зависеть от того, какая программа стоит на хосте, и какие в ней дефолты.

Мораль? Да нет ее, как обычно.

Не на правах рекламы.

Я, где-то с 2021 года, использовал ноуты от Xiaomi:

https://xn--r1a.website/itpgchannel/111
https://xn--r1a.website/itpgchannel/428

Первый ноут был прекрасен, второй - просто неплох (потому что его явно не тестировали с Linux, там были проблемы с ACPI, с питанием, и он почти не держал батарею).

Короче, вот мой новый ноут - https://www.ozon.ru/product/lenovo-xiaoxin-pro-14-2024-32-gb-1-tb-amd-r7-8845h-tonkie-i-legkie-bloknoty-besplatnyy-podarok-1452961844/

Основные отличия от предыдущего моего Xiaomi:

* 90hz -> 120hz. Это прямо хорошо заметно, и очень приятно.

* экран чуть ярче, для OLED это важно, потому что OLED экраны не очень яркие сами по себе.

* 16gb -> 32gb mem. В целом, приятно, хотя мне хватало и 16 почти всегда.

* 512gb -> 1Tb HD. Тоже, приятно, но я не помню, чтобы хоть раз упирался в 500 гиг.

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

* Держит батарею, нет проблем с ACPI (уходит в сон и возвращается без проблем)

* Чуть толще.

* Во всем остальном они прямо близнецы - братья (AMD ryzen, AMD встройка, OLED экран, металлический корпус, клавиатура "как у Мак")

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

Цена 50к (я брал за 70, но вот нашел объявление за 50 - https://www.ozon.ru/product/lenovo-xiaoxin-pro-14-2024-32-gb-1-tb-amd-r7-8845h-tonkie-i-legkie-bloknoty-besplatnyy-podarok-1517165298/). Мне кажется, это какой-то демпинг от Ozon, потому что на Ali ноут стоит 100к.

50к, конечно, звучит немного как чудо.

Будни #bootstrap

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

Вот, на этот раз отличился проект x265, перевыложил файл https://bitbucket.org/multicoreware/x265_git/downloads/x265_3.6.tar.gz

Зачем?

На этот раз я совершенно точно знаю, зачем.

Коллега, который готовыл релиз, объебался, и вместо структуры директорий:

src/a
src/b/d
src/e

сделал

a
b/d
e

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

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

Никогда, никогда не перевыкладывайте новые данные под старым именем.

Как было нужно?

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

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

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

Релиз dropbear.

Из интересного для меня - "Добавлена возможность пробрасывать UNIX-сокеты через туннель, созданный на базе Dropbear SSH"

Одна из вещей, которая не работала в моей модели безопасности (эскалация в root через условный sshd) - это fuse. Потому что он запускает suid helper, и ожидает от него получить файловый дескриптор от fuse, который можно получить только от root.

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

Сейчас можно попробовать вернуться к этой задаче.

#bcachefs

#Kent выложил код, который умеет читать поврежденные им ранее файловые системы - https://www.opennet.ru/opennews/art.shtml?num=60946

"New repair/construction code is in the final stages, should be ready in
about a week. Anyone that lost btree interior nodes (or a variety of
other damage) as a result of the splitbrain bug will be able to repair
then"

Знаете, вот, на самом деле, когда разработчик FS начинает употреблять что-то типа "split brain bug", то я, например, очень радуюсь, и говорю, что, вот, кто-то, наконец-то, понял, как правильно пилить файловую систему.

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

До этого, КМК, FS писали в парадигме того, что нижележещие устройства или надежны, или мы перемонтируем всю FS в read only, если "снизу" вернули ошибку.

https://lore.kernel.org/lkml/20240405102754.435410987@infradead.org/

Я просто оставлю это здесь:

"... Critically cfs-cgroup throttling is not tested, and cgroups are only tested in so far that a systemd infected machine now boots (took a bit) ..."

#vendor

https://github.com/desktop-app/cmake_helpers/commit/5a19eddd4554486547d6d5dac3002a93bc105867

Тем временем, коллеги откатили scudo, и вернули jemalloc.

Верю, что пройдет еще пара итераций, и там таки окажется #tcmalloc, хехе.

Как я это заметил? Ну, у меня сломалась "кузькина мать", когда не смогла развендорить scudo в новой версии телеги.

UPD: у меня github показывает розовых поней, наверное, это как-то связано

Будни #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 класса - сервиса, и производящая функция всего кластера, которая полностью описывает его структуру, имея на вход низкоуровневое описание кластера (сети, диски, и так далее).

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

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

What a day to be alive, python jit уже на полпути к релизу: https://www.opennet.ru/opennews/art.shtml?num=60966