Sbinmerge: различия между версиями

Материал из ALT Linux Wiki
(→‎Sbinmerge: Улучшить формулировку текущего статуса и добавить добрый совет мейнтейнерам)
м (→‎Глоссарий: "тто есть")
Строка 8: Строка 8:


== Глоссарий ==
== Глоссарий ==
Известно, что файловые объекты в системе сложены в иерархию каталогов. О FHS-подобной иерархии файловых объектов, в которой пути {{path|/usr/sbin}} и {{path|/usr/bin}} взаимозаменяемы (тт. е., фактически, {{path|/usr/sbin}} является ссылкой на {{path|/usr/bin}}), говорят, что она обладает '''{{term|merged-sbin}}'''-свойством; в проекте systemd это также называют '''{{term|merged-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 (или наоборот) и получают ошибку "файл не найден".

Appendix