В настоящее время все пакеты, где в скриптах создаются пользователи или группы, содержат в spec-файлах явные вызовы useradd/groupadd, что чревато типовыми ошибками (например, пропуском ||: - хотя нужно ли это сейчас?). Кроме того, при использовании nscd недостаточно выполнить только useradd или groupadd - в PLD после этих команд используются конструкции вида: [ ! -x /usr/sbin/nscd ] || /usr/sbin/nscd -i passwd [ ! -x /usr/sbin/nscd ] || /usr/sbin/nscd -i group Размножение таких команд по всем пакетам никуда не годится - пора делать макросы для useradd и groupadd.
С одной стороны, useradd/userdel должны сами запускать nscd -i. С другой стороны, у groupadd/useradd есть куча опций. Непонятно, как в результате должны выглядеть макросы.
Действительно, nscd запускать не нужно - в shadow обнаружился код для очистки кеша nscd. Однако остались и другие проблемы - например, сейчас при обновлении пакета dbus на экран лезет: useradd: user messagebus exists В большинстве пакетов вызывается "useradd ... >/dev/null 2>&1 ||:", однако в dbus перенаправление в /dev/null отсутствует. Впрочем, подобное скрытие ошибок тоже выглядит некрасиво - в PLD в макросах сначала проверяется существование пользователя, и useradd вызывается только в том случае, если пользователь не обнаружен.
Created attachment 1609 [details] Макросы из rpm-build-macros-1.315-1 (PLD) Вот так сделано в PLD (там требуют задавать uid/gid принудительно).
Требовать всегда указывать uid для нас нереально. Впрочем, перенаправлять stderr от useradd в /dev/null тоже не очень хорошо: если что-то сломается, мы об этом не узнаем. Лучше, если макрос будет просто вызывать wrapper, который сделает всё как надо: проверит, существует ли нужный user с нужными параметрами и при необходимости вызовет useradd или usermod (по аналогии с /usr/sbin/post_service). Проблема в том, что при использовании макроса этот wrapper должен автоматически попадать в зависимости пакета, скрипт которого использует этот макрос. Чтобы такое происходило, нужно доработать rpm-build.
(In reply to comment #4) > Требовать всегда указывать uid для нас нереально. Это я и не требую - макросы от PLD приведены только в качестве примера передачи опций и некоторых проверок. > Впрочем, перенаправлять stderr от useradd в /dev/null тоже не очень хорошо: > если что-то сломается, мы об этом не узнаем. Именно расплодившиеся "&>/dev/null" мне и не нравятся. Да и "||:" тоже. > Лучше, если макрос будет просто вызывать wrapper, который сделает всё как надо: > проверит, существует ли нужный user с нужными параметрами и при необходимости > вызовет useradd или usermod (по аналогии с /usr/sbin/post_service). Согласен - не стоит тащить эту логику непосредственно в макрос. > Проблема в том, что при использовании макроса этот wrapper должен автоматически > попадать в зависимости пакета, скрипт которого использует этот макрос. Чтобы > такое происходило, нужно доработать rpm-build. На самом деле в таких пакетах уже сейчас есть PreReq: shadow-utils (по крайней мере, должно быть) - если положить wrapper туда же, пока можно обойтись и без доработок rpm-build. Хотя разговоры об автоматическом поиске зависимостей для установочных скриптов были уже очень давно...
Вообще говоря, "PreReq: shadow-utils" может быть недостаточно при обновлении пакетов. Автоматический поиск зависимостей для установочных скриптов реализован в том бранче rpm, который ведёт jbj, в принципе можно портировать. Но здесь нужно немного другое: если поместить wrapper в один пакет с useradd (что логично), то оптимизатор зависимостей оставит лишь имя пакета. Однако одного имени пакета может быть недостаточно при обновлении пакетов.
(In reply to comment #4) > Требовать всегда указывать uid для нас нереально. Почему? Пока такой реестр (необязательно поддерживаемый в setup) кажется наиболее логичным для упорядочивания новых установок с потенциально различным порядком установки пакетов, данные и конфигурация с правами псевдопользователей и псевдогрупп из которых могут при этом мигрировать. Какие проблемы, кроме обеспечения usermod (или скорее подсказки локальному администратору о требуемых действиях) для "наследственных" uid/gid, я не заметил? (кстати, энфорсить это можно именно с переездом на использование макросов -- если где-то чревато, пусть майнтейнер облизывается, подготавливая переезд) PS: багу нагуглил, рассматривая http://cvs.pld-linux.org/cgi-bin/cvsweb/SPECS/boa.spec?rev=1.87: Revision 1.87 2006/09/08 18:03:40 glen - rel 3 (rebuild with fixed %useradd/%groupadd macros) PPS: было бы очень здорово иметь эти макросы и такую договоренность для ALM3.1 -- хотя бы для того, чтобы за время его жизни у новоприбывших и нас, грешных, был лишний стимул начать исправлять положение. #9199 "blocker"?
BTW: http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2005-February/015314.html
(In reply to comment #4) > Требовать всегда указывать uid для нас нереально. Подумалось: можно задавать, но если уже такой существует -- создавать с произвольным. Это не сломает наследственные системы (на них уже бардак), но позволит синхронизировать uid/gid псевдопользователей (и данных) на новых Крайне полезно в т.ч. с контейнерами. PreReq: список соответствия (наверное, в setup, но не в самих /etc/passwd и /etc/group во избежание лишних даже псевдопользователей/групп -- или сами по себе они не страшны?).
(In reply to comment #4) > Требовать всегда указывать uid для нас нереально. > Впрочем, перенаправлять stderr от useradd в /dev/null тоже не очень хорошо: > если что-то сломается, мы об этом не узнаем. > > Лучше, если макрос будет просто вызывать wrapper, который сделает всё как надо: > проверит, существует ли нужный user с нужными параметрами и при необходимости > вызовет useradd или usermod (по аналогии с /usr/sbin/post_service). > > Проблема в том, что при использовании макроса этот wrapper должен > автоматически > попадать в зависимости пакета, скрипт которого использует этот макрос. > Чтобы > такое происходило, нужно доработать rpm-build. Поскольку rpm-build уже доработан, осталось придумать подходящие имена макросов, а также имя нового пакета, в который предстоит поместить врапперы.
%user_add?
(In reply to comment #11) > %user_add? > С аргументацией, в виде примера так же названных у нас макросов. В PLD например useradd/userremove
А, точно -- у них такое уже было. Ну или так :)
В Fedora я видел вызов getent для проверки наличия пользователя/группы. Ещё пытался сделать нечто такое # useradd USER options %useradd() \ args="%{*}"; \ set $args ''; \ user="$1" ; \ shift ; \ getent passwd "$user" >/dev/null || /usr/sbin/useradd -r "$@" "$user" \ %nil но у меня не заработало: useradd: неверный ключ — «g» ошибка: Неизвестный параметр ? в useradd() предупреждение: Macro %* not found В /usr/lib/rpm/macros.d/tcl я подсмотрел %tea_makeindex(vdlf:L:C:) \ %{-v:_verbose="-verbose"} \ %{-d:_direct="-direct"} \ %{-l:_lazy="-lazy"} \ Получается, мы можем сделать нормальный макрос, который выполнит все необходимые действия, и будет принимать некоторые оговорённые параметры. (В ответ на комментарий №4) > Лучше, если макрос будет просто вызывать wrapper, который сделает всё как надо: > проверит, существует ли нужный user с нужными параметрами и при необходимости > вызовет useradd или usermod (по аналогии с /usr/sbin/post_service). Я вот тоже думаю о враппере, много логики в макросах как-то сложно и некрасиво. Но всё же макрос не надо ставить в систему. > Проблема в том, что при использовании макроса этот wrapper должен автоматически > попадать в зависимости пакета, скрипт которого использует этот макрос. Чтобы > такое происходило, нужно доработать rpm-build. У меня вопрос осложняется тем, что мы хотелось бы видеть подобное решение и в других дистрибутивах, т.е. возможность переноса решения туда. Но может быть мы начнём с описания, как должны называться макросы, и какие могут быть параметры, основываясь на том, что применяется в пакетах?
Предлагаю рассмотреть закрытие задачи в связи с наличием systemd-sysusers, который после установки пакета обработает новые файлы из /lib/sysusers.d/ и создаст необходимых пользователей и группы.
