Журнал Витуса

До выхода ubuntu 24.04 еще два дня, а у нас уже есть первый сервер с этой ОС. Потому что ставить interim release mantic minotaur на сервер как-то некошерно. А поставить туда debian не получается, так как архитектура riscv64 пока отсутствует даже в testing - есть только в sid-е. И у альта - только в Sisyphus. Поэтому зоопарк разрастается по следующему принципу - x86_64 и aarch64 - debian, e2k - alt, riscv - ubuntu. Хотя целевая ОС там конечно alt. Но это еще пока мы портируем наш софт, глядишь у альта в 11 платформе уже эта арихтектура будет.

Вот как можно так настроить веб-сервер, чтобы пакетный менеджер оттуда rpm-ки скачивал с ошибками, а wget и браузер - нормально?

Оказывается, можно. Если отдавать статический файл с диска с Transfer-Encoding: chunked. Как будто это не статический файл, выложенный три месяца назад (и ему надо отдавать Last-Modified, Content-Length, и ETag, а желательно еще и предлагать Accept-Ranges) а динамичски генерируемая страница. (отдельная песня что там еще заглоовка Content-Type не было. Тот кто начинал заниматься веб-программированием в эпоху CGI и конкурирующих семи русских кодировок при виде http-respоnse в которой отсутствует нафиг заголовок Content-Type (даже если там по смыслу application/octet-stream), но зато присуствует Content- Disposition: attachment впадает в ступор.

Авторам apt-rpm тоже не пришло в голову потестировать свое поделие на совместимость с Transfer-Encoding: chunked. А у них собственная гордость, своя библиотека для работы с http которая говорят на целых несколько процентов быстрее curl (это когда это скорость скачивания по http лимитировала клиентская библиотека а не канал где-то посредине?)

А у меня первая мысль когда приходит баг репорт, что-де пакеты скачиваются с не теми контрольными суммами? Что сервер кто-то ломанул и в rpm-ки трояна завернул. И только после того как я сравнил sha256 суммы этих rpm-ок с архивом стало понятно что дело в админах сервера. Нет, современное поколение сисадминов выросшее в эпоху динамически генерируемых страниц - это что-то.

Кстати, почему-то дебиановский apt, yum и dnf скушали chunked и не подавились. Возможно потому что последние два - на питоне написаны и используют его стандартные библиотеки для скачивания файлов.

Решил прикрутить ко всем своим lxc-контейнерам (а их у меня на моей рабочей машине 30 штук) bind-mounted /home.
Для этой цели пришлось, естественно, синхронизироват uid-ы пользователей между всеми контейнерами.
И тут вдруг внезапно altlinux-ы 7 и 8 перестали меня пускать. shell request failed говорят. А внутри в логи пишут "altlinux-7 sshd[2758]: error: do_exec_pty: fork: Resource temporarily unavailable"
Почему-то вот ресурса числа процессов на юзера, которого им вполне хватало, хватать перестало. То ли там ошибка в cgroups и они считают процессы на хосте и других контейнерах, то ли не знаю что.
Вылечилось увеличением лимитов на nproc в /etc/security/limits.d/50-defaults.conf раза в четыре.

Да, это напоминает "почему мой эмулятор 8-битной игровой коноли для 16-битной DOS звпущенный в 32-битной виртуальной машине с Windows работающей на 64-битом хосте не издает звуков?"

Но иногда приходится.

Потому что есть логин на машинку с относительно древним RHEL (7.5) и на ней хочется собирать пакеты для кучи разных дистрибутивов. Потому что у этой машинке архитектура ppc64le. Такую за копейки на aliexpress не купишь.
(впрочем, arm64 который покупается за копейки на aliexpress, для сборки пакетов тоже пригоден не слишком. Хотя надо попробовать укупить там что-то побыстрее RaspBerry PI 3B)

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

К сожалению, вот просто так взять и поставить хэшер на RHEL - мероприятие, не слишком простое и очевидное.

А вот schroot есть в EPEL.

Как оказалось, делать это следует следующим способом

1. Качаем образ минимальной системы требуемой архитектуры с альта.
   
2. Распаковываем ее в /srv/chroot/altlinux9
   
3. Пишем близкий к тривиальному конфиг schroot в /etc/schroot/chroot.d
   

   [altlinux9]
   descriotion=AltLinux 9 with hasher
   type=directory
   directory=/srv/chroot/altlinux9
   users=vitus
   

   
   
   
4. Копируем в chroot /etc/sudoers
   
5. Заходим в chroot рутом (sudo schroot -c altlinux8)
   и делаем apt-get install sudo, потому что в минимальной системе sudo нет
   
6. Далее, из под рута же выполняем инструкцию
   
7. Выходим из chroot и копируем из chroot-а /etc/passwd, /etc/group и /etc/shadow в хост-систему
   (потому что schroot их копирует из хост-системы при каждом входе. Это можно отключить но не нужно. так как простейший chroot свойства юзера, включая членство в группе наследует из хост-системы.)
   
8. Выходим из хост-системы и заходим обратно, после чего заходим в chroot уже юзером и выполняем ту часть инструкции, которая из-под юзера.
   

Ура, можно пересобирать пакеты.