Sbinmerge: различия между версиями
(→Sbinmerge: Улучшить формулировку текущего статуса и добавить добрый совет мейнтейнерам) |
м (→Глоссарий: "тто есть") |
||
Строка 8: | Строка 8: | ||
== Глоссарий == | == Глоссарий == | ||
Известно, что файловые объекты в системе сложены в иерархию каталогов. О FHS-подобной иерархии файловых объектов, в которой пути {{path|/usr/sbin}} и {{path|/usr/bin}} взаимозаменяемы ( | Известно, что файловые объекты в системе сложены в иерархию каталогов. О FHS-подобной иерархии файловых объектов, в которой пути {{path|/usr/sbin}} и {{path|/usr/bin}} взаимозаменяемы (т. е., фактически, {{path|/usr/sbin}} является ссылкой на {{path|/usr/bin}}), говорят, что она обладает '''{{term|merged-sbin}}'''-свойством; в проекте systemd это также называют '''{{term|merged-bin}}'''. | ||
Иерархия, не отвечающая этому правилу, называется '''{{term|unmerged-sbin}}'''; в проекте systemd это называют '''{{term|unmerged-bin}}'''. | Иерархия, не отвечающая этому правилу, называется '''{{term|unmerged-sbin}}'''; в проекте systemd это называют '''{{term|unmerged-bin}}'''. | ||
Версия от 14:51, 29 мая 2025
Sbinmerge
Пока не планируется в Sisyphus, но при подготовке пакетов лучше не усугублять несовместимость с merged-sbin.
Рекомендуем, собирая пакеты и устанавливая исполняшки под PATH, не класть неидентичные файлы по путям /usr/bin/$X и /usr/sbin/$X для любого $X. Если вы по одному из этих путей помещаете один свой файл, а в другом пакете по другому из этих путей' лежит другой чужой файл, эти пакеты должны явно конфликтовать. Проще всего использовать только /usr/bin, он же %_bindir.
Глоссарий
Известно, что файловые объекты в системе сложены в иерархию каталогов. О FHS-подобной иерархии файловых объектов, в которой пути /usr/sbin и /usr/bin взаимозаменяемы (т. е., фактически, /usr/sbin является ссылкой на /usr/bin), говорят, что она обладает merged-sbin-свойством; в проекте systemd это также называют merged-bin. Иерархия, не отвечающая этому правилу, называется unmerged-sbin; в проекте systemd это называют unmerged-bin.
Введение
Исторически[1] в UNIX System V, а позже и в мейнстримных линукс-дистрибутивах разделяли каталоги /bin и /sbin. Истинная причина различать эти два каталога утеряна.
У этих каталогов есть аналоги под /usr, для них справедливы всё те же рассуждения.
С течением времени этому расхождению стали придумывать разные обоснования.
- Под /sbin можно помещать критические статически скомпонованные бинарники вроде /sbin/mount и /sbin/mkfs, которые продолжат работать, если в системе сломаны или отсутствуют разделяемые библиотеки.
- Под /sbin можно помещать исполнимые файлы, предназначенные для запуска только администратором, и указывать /sbin в PATH только аккаунтам root (с uid 0).
Аргумент про статически скомпонованные бинарники не соответствует как практике ALT, так и других GNU/Linux: для этого, например, потребуется убрать из каталога /sbin динамические бинарники и выкинуть его из PATH. Для восстановления системы лучше организовать где-то рядом компактный раздел восстановления, с утончёнными бинарниками, возможно, статическими, ... Для порождения сборочных чрутов hasher применяет статически собранные find и cpio, но кладёт их так, чтобы они не могли попасться в PATH при типичном использовании системы.
Аргумент о инструментах администрирования смотрится интереснее, но провести границу между бесполезными для не-администраторов программами и остальными невозможно, и программы начинают попадать в один из каталогов случайно. Те категории пользователей, что привыкли дополнять PATH какими-то сторонними каталогами с исполняшками из сторонних источников, и вовсе могут получить нежелательные эффекты, добавив или убрав себе /sbin: либо запустится неправильная программа из /usr/sbin, перекрывающая правильную, либо выскочит ошибка "программа не найдена". Часто это заканчивается тем, что пользователи просто добавляют в PATH оба каталога, и разделение фактически не работает.
Более того, и сами инструменты администрирования меняются (ручное управление => ansible, salt, "GitOps", ...)
- Команда ip — не только инструмент настройки сетевого стека, но и инструмент диагностики (непривилегированной).
- Команды e2image, mksquashfs и подобные — это инструменты работы в том числе с образами ФС, нередко для дальнейшего применения на других машинах с более крутым уровнем привилегий, чем у пользователя на машине, где образ создаётся.
- Команды reboot, poweroff, halt при соотв. модели безопасности доступны и непривилегированному пользователю, если у него есть физ. доступ к кнопке "reset" (например, это рабочая станция или персоналка).
И так далее...
Чем сохранять бесцельно дублирующие друг друга два каталога для бинарников из PATH для одних и тех же файлов, лучше оставить один из них, /bin, а другой устранить.
Rationale
- Один каталог проще двух. Его легче снапшотить, по нему легче гонять find, ...
- Сборочным скриптам и прочим интеграционным программным компонентам не нужно будет перебирать каталоги, в которых находится искомая программа. (Возможно, самый частый случай такого перебора — execvp(3))
- Какой-нибудь толстый и важный апстрим (systemd) может прекратить поддержку unmerged-bin, и патчсет для сохранения корректной поддержки может оказаться слишком большим, создавая чрезмерную нагрузку на мейнтейнера.
Proposed changes
- Необходимо выявить все скрытые конфликты пакетов между собой и исправить их (метабаг), а также не допускать новых далее. Лучше всего было бы проверять на сборочнице при коммите задания, что таких конфликтов не возникает.
- Необходимо выявить и исправить пакеты, не устанавливаемые на merged-sbin систему из-за внутрипакетных конфликтов. Известно несколько классов таких пакетов:
- Пакеты, имеющие в /usr/bin и /usr/sbin разные исполняемые файлы (пакет passwd). В таких ситуациях следует перенести исполняемые файлы из /usr/sbin и /usr/bin в другое место, заменив их скриптом запуска, запускающий тот или иной бинарный файл в зависимости от того, кто его запускает (пользователь или root).
- Пакеты, использующие consolehelper. Их необходимо переводить на использование polkit (уже сделано). Если пакет не может быть переведён на polkit (beesu такой случай), то нужно перенести исполняемый файл из /usr/sbin в /usr/libexec и поправить путь в console.apps до программы.
- Пакеты, имеющие разные одноимённые симлинки в /usr/bin и /usr/sbin. Таким пакетом является sendmail-common mailq (/usr/bin/mailq -> ../sbin/sendmail; /usr/sbin/mailq -> sendmail); newaliases (/usr/bin/newaliases -> ../sbin/sendmail; /usr/sbin/newaliases -> sendmail). Сам /usr/sbin/sendmail в postfix, sendmail-submit, ssmtp.
- Пакеты, имеющие симлинки в /usr/sbin на /usr/bin и наоборот. При установке таких пакетов на уже смерженные системы может произойти непоправимое: установится симлинк, а не исполняемый файл. Поэтому симлинки должны быть заменены на хардлинки. Это может быть сделано автоматически. Примерный список таких пакетов:
alterator: alterator-cmdline alternatives: alternatives-update bonnie++: bonnie++ net-tools: arp ifconfig route iproute2: ip lnstat nstat rtmon ss tc fbset: fbset modeline2fb psmisc: fuser (/usr/bin/fuser -> ../../sbin/fuser) iftop: iftop systemd: systemctl lshw-gui: lshw-gui lsof: lsof (/usr/bin/lsof -> ../sbin/lsof) makemap: makemap squashfs-tools: mksquashfs udev: udevadm usbip: usbip
Incompatibilities
TODO: Проверить систему alternatives, что она работает правильно в merged-sbin окружении.
User-visible impact
Исчезнет ситуация, где программа на самом деле находится в /bin, но её вызывают по полному пути в /sbin (или наоборот) и получают ошибку "файл не найден".