Stam_emg30 окт в 13:47

Старый софт на свежем Linux: свой GCC, свой OpenSSL и честный RPATH

Сложный

17 мин

6.9K

Linux * DevOps * Python * Компиляторы * PHP *

Кейс

Комментарии 13

jorlyf 30 окт в 14:19

Вы пробовали использовать Nix для получения нужной версии GCC/python? По идее, можно просто зафиксировать коммит репозитория пакетов на то время, когда нужная версия была актуальной, и Nix сам скачает или соберет готовую среду.

И перенос с Debian на Astra Linux прошел бы без изменений.

Возможно, я что-то не учитываю, но хотел поделиться идеей.

Stam_emg 30 окт в 14:41

Спасибо, хорошая идея, Nix действительно решает похожую задачу.

Но с Nix я пока плотно не работал, но… вижу несколько нюансов.

1. Зафиксированный коммит nixpkgs замораживает и зависимости. Если взять nixpkgs того времени, когда Python 3.7 был актуален, вместе с ним приедет OpenSSL, zlib и всё остальное тех же лет со всеми уязвимостями, найденными с тех пор. Это ровно та проблема, с которой я начинал статью про замороженные официальные образы. Чтобы её решить, придётся переопределять OpenSSL через overlay и собирать из исходников. То есть делать то же самое, что у меня, только на языке Nix. Тут Nix ничем не хуже, но и магии нет.

2. Перенос «без изменений» — потому что closure тащит с собой всё, включая свою glibc. Технически это плюс. Но от Astra тогда остаётся только ядро:

системные библиотеки и сертифицированный OpenSSL не используются вообще. У меня в эксперименте рантайм работал поверх системной glibc Astra, и именно поэтому всплыли реальные отличия дистрибутива. Одно из них оказалось скрытой ошибкой, которая на Debian пока просто не проявилась.

3. Эксплуатация. У меня эти образы — база для пачки дочерних образов на обычном Debian, и команде проще читать Dockerfile, чем Nix-выражения. Для Astra в защищённом режиме /nix/store с неподписанными бинарниками — такая же, если не бОльшая, проблема, чем мои бинарники.

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

Если у вас есть опыт держать на Nix длинный хвост EOL-версий с патчами безопасности, было бы интересно почитать. Спасибо еще раз!

MrBotikkk 30 окт в 14:43

У меня есть собственные неофициальные Docker-образы Astra Linux 1.7 и 1.8.

Есть официальные в открытом доступе. Просто никто не читает документы. "Образы доступны для скачивания по ссылке в разделе astra."

Есть специальный проект https://hub.docker.com/r/debian/eol debian/eol:bullseye debian/eol:buster debian/eol:stretch и возможно debian/eol:jessie будут запускаться на современных ядрах. Python 3.7 и ниже не проблема.

Stam_emg 30 окт в 14:59

Спасибо за ссылки , учту.

Про Astra.

Свои образы я делал давно, когда официальных в открытом доступе ещё не было, во всяком случае для меня. С тех пор просто поддерживаю их в том же виде, что и остальные свои образы. Сам я не пользователь Astra, и кому нужна именно официальная, тот, конечно, возьмёт официальную. Этой мысли посвящен абзац.

Про debian/eol.

Я им пользовался в своих образах, пока на нём не начали копиться CVE. Статья как раз о том, почему я от этого ушёл: debian/eol — это тот же старый зоопарк, только аккуратно упакованный. Старый OpenSSL, старая glibc, обновлений безопасности больше нет. А совсем старые релизы вроде squeeze и wheezy (6 и 7) на свежих ядрах без эмуляции vsyscall не заводятся, о чём я тоже упоминал в начале статьи.

MrBotikkk 30 окт в 15:53

Запускал на Debian 13 docker.io/debian/eol:lenny

echo 'GRUB_CMDLINE_LINUX_DEFAULT="${GRUB_CMDLINE_LINUX_DEFAULT} vsyscall=emulate"' | sudo tee /etc/default/grub.d/99-vsyscall.cfg
sudo update-grub
-----
sudo rm /etc/default/grub.d/99-vsyscall.cfg
sudo update-grub

Stam_emg 30 окт в 16:52

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

в целом, данная ветка немного не про тематику статьи. складывается впечатление.

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

MrBotikkk 30 окт в 17:41

Не сочтите за “Грубое общение”, но конкретных решений в статье по vsyscall=emulate нет. Мной такой подход тестировался 3-4 г. назад

Dockerfile eol:lenny etch

FROM docker.io/debian/eol:lenny

ENV DEBIAN_FRONTEND=noninteractive
ENV TERM=xterm

RUN mkdir -p /etc/apt/sources.list.d \
    && printf '%s\n' \
       'deb [trusted=yes] http://archive.debian.org/debian etch main' \
       'deb [trusted=yes] http://archive.debian.org/debian-security etch/updates main' \
       > /etc/apt/sources.list.d/etch.list

RUN mkdir -p /etc/apt/preferences.d \
    && printf '%s\n' \
       'Package: *' \
       'Pin: release n=etch' \
       'Pin-Priority: 100' \
       > /etc/apt/preferences.d/etch

RUN mkdir -p /var/lib/apt/lists/partial \
    && apt-get update \
    && apt-get install -y --no-install-recommends nano file \
    && rm -rf /var/lib/apt/lists \
    && mkdir -p /var/lib/apt/lists/partial

CMD ["/bin/bash", "--noprofile", "--norc", "-i"]

Все эти версии Python уже не поддерживаются:

Python 3.9
https://peps.python.org/pep-0596/
Python 3.8
https://peps.python.org/pep-0569/
Python 3.7
https://peps.python.org/pep-0537/
Python 3.6
https://peps.python.org/pep-0494/
Python 2.7
https://www.python.org/doc/sunset-python-2/

Отлично собираются в podman/docker Arch Linux image c последними доступными патчами

Stam_emg 30 окт в 19:32

все подробно описано в первом абзаце.

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

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

MrBotikkk 30 окт в 15:12

Кто обнуляет карму? сегодня в 17:52 -1 Грубое общение. Где проявилось мое грубое общение?

SilverTrouse 30 окт в 19:52

У меня есть немного обратная проблема. Astra 1.7 к нему хочу собрать допустим современный vscodium - в итоге собираем по цепочке binutils ( так-как родной ld чуть багованный и не может собрать gcc 14-15-16). Собираем gcc собираем python собираем nodejs собираем llvm собираем rust. Только уже после билдим vscodium

Пребинари не подходят так как libc нужен более современный (1.7 - debian 10)

MrBotikkk 30 окт в 20:54

mkdir -p ~/.local/bin
cd ~/.local/bin
wget https://github.com/VSCodium/vscodium/releases/download/1.143.17232/VSCodium-1.143.17232-anylinux-x86_64.AppImage
chmod +x VSCodium-*.AppImage
ln -sf ~/.local/bin/VSCodium-1.143.17232-anylinux-x86_64.AppImage ~/.local/bin/codium
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc && source ~/.bashrc

или

cd /tmp
wget https://github.com/VSCodium/vscodium/releases/download/1.143.17232/VSCodium-1.143.17232-anylinux-x86_64.AppImage
chmod +x VSCodium-*.AppImage
sudo mv VSCodium-*.AppImage /usr/local/bin/codium

SilverTrouse 2 ноя в 11:36

appImage да, но интерснее натив

MrBotikkk 30 окт в 21:09

https://wiki.astralinux.ru/kb/sravnenie-sistem-upravleniya-paketami-snap-i-flatpak-238748637.html flatpak install flathub com.vscodium.codium

Зарегистрируйтесь на Хабре, чтобы оставить комментарий