Bug 9895 - add useradd and groupadd macros
: add useradd and groupadd macros
Status: ASSIGNED
: Sisyphus
(All bugs in Sisyphus/rpm-build)
: unstable
: all Linux
: P2 enhancement
Assigned To:
:
:
: sisyphus-core-1.0
:
:
  Show dependency tree
 
Reported: 2006-08-19 18:15 by
Modified: 2017-11-27 23:30 (History)


Attachments
Макросы из rpm-build-macros-1.315-1 (PLD) (2.06 KB, text/plain)
2006-08-28 12:37, Sergey Vlasov
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


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

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

useradd: user messagebus exists

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

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

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

Проблема в том, что при использовании макроса этот wrapper должен автоматически
попадать в зависимости пакета, скрипт которого использует этот макрос.  Чтобы
такое происходило, нужно доработать rpm-build.
------- Comment #5 From 2006-08-30 22:02:44 -------
(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 From 2006-08-30 22:07:57 -------
Вообще говоря, "PreReq: shadow-utils" может быть недостаточно при обновлении
пакетов.

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

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

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

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

Но может быть мы начнём с описания, как должны называться макросы, и какие
могут быть параметры, основываясь на том, что применяется в пакетах?