Bug 9895

Summary: add useradd and groupadd macros
Product: Sisyphus Reporter: Sergey Vlasov <vsu>
Component: rpm-buildAssignee: placeholder <placeholder>
Status: ASSIGNED --- QA Contact: qa-sisyphus
Severity: enhancement    
Priority: P2 CC: arseny, erthad, force, glebfm, imz, inger, lav, ldv, mike, php-coder, placeholder, vt, vvk
Version: unstableKeywords: sisyphus-core-1.0
Hardware: all   
OS: Linux   
Attachments:
Description Flags
Макросы из rpm-build-macros-1.315-1 (PLD) none

Description Sergey Vlasov 2006-08-19 18:15:55 MSD
В настоящее время все пакеты, где в скриптах создаются пользователи или группы,
содержат в 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.
Comment 1 Dmitry V. Levin 2006-08-22 01:55:16 MSD
С одной стороны, useradd/userdel должны сами запускать nscd -i.
С другой стороны, у groupadd/useradd есть куча опций.
Непонятно, как в результате должны выглядеть макросы.
Comment 2 Sergey Vlasov 2006-08-28 12:33:24 MSD
Действительно, nscd запускать не нужно - в shadow обнаружился код для очистки
кеша nscd.

Однако остались и другие проблемы - например, сейчас при обновлении пакета dbus
на экран лезет:

useradd: user messagebus exists

В большинстве пакетов вызывается "useradd ... >/dev/null 2>&1 ||:", однако в
dbus перенаправление в /dev/null отсутствует.  Впрочем, подобное скрытие ошибок
тоже выглядит некрасиво - в PLD в макросах сначала проверяется существование
пользователя, и useradd вызывается только в том случае, если пользователь не
обнаружен.
Comment 3 Sergey Vlasov 2006-08-28 12:37:43 MSD
Created attachment 1609 [details]
Макросы из rpm-build-macros-1.315-1 (PLD)

Вот так сделано в PLD (там требуют задавать uid/gid принудительно).
Comment 4 Dmitry V. Levin 2006-08-30 21:05:45 MSD
Требовать всегда указывать uid для нас нереально.
Впрочем, перенаправлять stderr от useradd в /dev/null тоже не очень хорошо:
если что-то сломается, мы об этом не узнаем.

Лучше, если макрос будет просто вызывать wrapper, который сделает всё как надо:
проверит, существует ли нужный user с нужными параметрами и при необходимости
вызовет useradd или usermod (по аналогии с /usr/sbin/post_service).

Проблема в том, что при использовании макроса этот wrapper должен автоматически
попадать в зависимости пакета, скрипт которого использует этот макрос.  Чтобы
такое происходило, нужно доработать rpm-build.
Comment 5 Sergey Vlasov 2006-08-30 22:02:44 MSD
(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.

Хотя разговоры об автоматическом поиске зависимостей для установочных скриптов
были уже очень давно...
Comment 6 Dmitry V. Levin 2006-08-30 22:07:57 MSD
Вообще говоря, "PreReq: shadow-utils" может быть недостаточно при обновлении
пакетов.

Автоматический поиск зависимостей для установочных скриптов реализован в том
бранче rpm, который ведёт jbj, в принципе можно портировать.
Но здесь нужно немного другое: если поместить wrapper в один пакет с useradd
(что логично), то оптимизатор зависимостей оставит лишь имя пакета.  Однако
одного имени пакета может быть недостаточно при обновлении пакетов.
Comment 7 Michael Shigorin 2007-01-24 17:49:55 MSK
(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"?
Comment 9 Michael Shigorin 2007-09-26 10:34:25 MSD
(In reply to comment #4)
> Требовать всегда указывать uid для нас нереально.
Подумалось: можно задавать, но если уже такой существует -- создавать с
произвольным.

Это не сломает наследственные системы (на них уже бардак), но позволит
синхронизировать uid/gid псевдопользователей (и данных) на новых

Крайне полезно в т.ч. с контейнерами.

PreReq: список соответствия (наверное, в setup, но не в самих /etc/passwd и
/etc/group во избежание лишних даже псевдопользователей/групп -- или сами по
себе они не страшны?).
Comment 10 Dmitry V. Levin 2008-11-28 00:12:53 MSK
(In reply to comment #4)
> Требовать всегда указывать uid для нас нереально.
> Впрочем, перенаправлять stderr от useradd в /dev/null тоже не очень хорошо:
> если что-то сломается, мы об этом не узнаем.
> 
> Лучше, если макрос будет просто вызывать wrapper, который сделает всё как надо:
> проверит, существует ли нужный user с нужными параметрами и при необходимости
> вызовет useradd или usermod (по аналогии с /usr/sbin/post_service).
> 
> Проблема в том, что при использовании макроса этот wrapper должен
> автоматически
> попадать в зависимости пакета, скрипт которого использует этот макрос. 
> Чтобы
> такое происходило, нужно доработать rpm-build.

Поскольку rpm-build уже доработан, осталось придумать подходящие имена макросов, а также имя нового пакета, в который предстоит поместить врапперы.
Comment 11 Michael Shigorin 2008-11-28 01:21:31 MSK
%user_add?
Comment 12 Vitaly Lipatov 2008-11-28 22:53:53 MSK
(In reply to comment #11)
> %user_add?
> 
С аргументацией, в виде примера так же названных у нас макросов.
В PLD например useradd/userremove
Comment 13 Michael Shigorin 2008-11-29 14:10:39 MSK
А, точно -- у них такое уже было.  Ну или так :)
Comment 14 Vitaly Lipatov 2017-11-27 23:30:27 MSK
В 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.
У меня вопрос осложняется тем, что мы хотелось бы видеть подобное решение и в других дистрибутивах, т.е. возможность переноса решения туда.

Но может быть мы начнём с описания, как должны называться макросы, и какие могут быть параметры, основываясь на том, что применяется в пакетах?
Comment 15 Vitaly Lipatov 2024-03-03 21:48:48 MSK
Предлагаю рассмотреть закрытие задачи в связи с наличием systemd-sysusers, который после установки пакета обработает новые файлы из /lib/sysusers.d/ и создаст необходимых пользователей и группы.