ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | add useradd and groupadd macros | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Sergey Vlasov <vsu> | ||||
| Component: | rpm-build | Assignee: | 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: | unstable | Keywords: | sisyphus-core-1.0 | ||||
| Hardware: | all | ||||||
| OS: | Linux | ||||||
| Attachments: |
|
||||||
|
Description
Sergey Vlasov
2006-08-19 18:15:55 MSD
С одной стороны, 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"? (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/ и создаст необходимых пользователей и группы. |
