9895 2006-08-19 18:15:54 +0400 add useradd and groupadd macros 2025-02-01 03:25:09 +0300 1 1 4 Development Sisyphus rpm-build unstable all Linux ASSIGNED https://bugzilla.altlinux.org/show_bug.cgi?id=52893 sisyphus-core-1.0 P2 enhancement --- 1 vsu placeholder arseny erthad force glebfm imz inger lav ldv mike php-coder placeholder vt vvk qa-sisyphus oldest_to_newest 39661 0 vsu 2006-08-19 18:15:55 +0400 В настоящее время все пакеты, где в скриптах создаются пользователи или группы, содержат в 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. 39709 1 ldv 2006-08-22 01:55:16 +0400 С одной стороны, useradd/userdel должны сами запускать nscd -i. С другой стороны, у groupadd/useradd есть куча опций. Непонятно, как в результате должны выглядеть макросы. 39809 2 vsu 2006-08-28 12:33:24 +0400 Действительно, nscd запускать не нужно - в shadow обнаружился код для очистки кеша nscd. Однако остались и другие проблемы - например, сейчас при обновлении пакета dbus на экран лезет: useradd: user messagebus exists В большинстве пакетов вызывается "useradd ... >/dev/null 2>&1 ||:", однако в dbus перенаправление в /dev/null отсутствует. Впрочем, подобное скрытие ошибок тоже выглядит некрасиво - в PLD в макросах сначала проверяется существование пользователя, и useradd вызывается только в том случае, если пользователь не обнаружен. 39812 3 1609 vsu 2006-08-28 12:37:43 +0400 Created attachment 1609 Макросы из rpm-build-macros-1.315-1 (PLD) Вот так сделано в PLD (там требуют задавать uid/gid принудительно). 39896 4 ldv 2006-08-30 21:05:45 +0400 Требовать всегда указывать uid для нас нереально. Впрочем, перенаправлять stderr от useradd в /dev/null тоже не очень хорошо: если что-то сломается, мы об этом не узнаем. Лучше, если макрос будет просто вызывать wrapper, который сделает всё как надо: проверит, существует ли нужный user с нужными параметрами и при необходимости вызовет useradd или usermod (по аналогии с /usr/sbin/post_service). Проблема в том, что при использовании макроса этот wrapper должен автоматически попадать в зависимости пакета, скрипт которого использует этот макрос. Чтобы такое происходило, нужно доработать rpm-build. 39900 5 vsu 2006-08-30 22:02:44 +0400 (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. Хотя разговоры об автоматическом поиске зависимостей для установочных скриптов были уже очень давно... 39902 6 ldv 2006-08-30 22:07:57 +0400 Вообще говоря, "PreReq: shadow-utils" может быть недостаточно при обновлении пакетов. Автоматический поиск зависимостей для установочных скриптов реализован в том бранче rpm, который ведёт jbj, в принципе можно портировать. Но здесь нужно немного другое: если поместить wrapper в один пакет с useradd (что логично), то оптимизатор зависимостей оставит лишь имя пакета. Однако одного имени пакета может быть недостаточно при обновлении пакетов. 44747 7 mike 2007-01-24 17:49:55 +0300 (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"? 44748 8 mike 2007-01-24 18:17:43 +0300 BTW: http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2005-February/015314.html 55858 9 mike 2007-09-26 10:34:25 +0400 (In reply to comment #4) > Требовать всегда указывать uid для нас нереально. Подумалось: можно задавать, но если уже такой существует -- создавать с произвольным. Это не сломает наследственные системы (на них уже бардак), но позволит синхронизировать uid/gid псевдопользователей (и данных) на новых Крайне полезно в т.ч. с контейнерами. PreReq: список соответствия (наверное, в setup, но не в самих /etc/passwd и /etc/group во избежание лишних даже псевдопользователей/групп -- или сами по себе они не страшны?). 81854 10 ldv 2008-11-28 00:12:53 +0300 (In reply to comment #4) > Требовать всегда указывать uid для нас нереально. > Впрочем, перенаправлять stderr от useradd в /dev/null тоже не очень хорошо: > если что-то сломается, мы об этом не узнаем. > > Лучше, если макрос будет просто вызывать wrapper, который сделает всё как надо: > проверит, существует ли нужный user с нужными параметрами и при необходимости > вызовет useradd или usermod (по аналогии с /usr/sbin/post_service). > > Проблема в том, что при использовании макроса этот wrapper должен > автоматически > попадать в зависимости пакета, скрипт которого использует этот макрос. > Чтобы > такое происходило, нужно доработать rpm-build. Поскольку rpm-build уже доработан, осталось придумать подходящие имена макросов, а также имя нового пакета, в который предстоит поместить врапперы. 81856 11 mike 2008-11-28 01:21:31 +0300 %user_add? 81903 12 lav 2008-11-28 22:53:53 +0300 (In reply to comment #11) > %user_add? > С аргументацией, в виде примера так же названных у нас макросов. В PLD например useradd/userremove 81915 13 mike 2008-11-29 14:10:39 +0300 А, точно -- у них такое уже было. Ну или так :) 167511 14 lav 2017-11-27 23:30:27 +0300 В 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. У меня вопрос осложняется тем, что мы хотелось бы видеть подобное решение и в других дистрибутивах, т.е. возможность переноса решения туда. Но может быть мы начнём с описания, как должны называться макросы, и какие могут быть параметры, основываясь на том, что применяется в пакетах? 242501 15 lav 2024-03-03 21:48:48 +0300 Предлагаю рассмотреть закрытие задачи в связи с наличием systemd-sysusers, который после установки пакета обработает новые файлы из /lib/sysusers.d/ и создаст необходимых пользователей и группы. 1609 2006-08-28 12:37:43 +0400 2006-08-28 12:37:43 +0400 Макросы из rpm-build-macros-1.315-1 (PLD) pld-user-group-macros text/plain 2113 vsu IyB1c2VyYWRkL2dyb3VwYWRkIG1hY3JvcyB3cml0dGVuIGJ5IGdsZW5AcGxkLWxpbnV4Lm9yZy4K IyBBbGwgcmlnaHRzIHJlc2VydmVkLiBQZXJtaXNzaW9uIHRvIGNvcHkgaXMgaGVyZWJ5IGdyYW50 ZWQuLiB5YWRhLCB5YWRhLCB5YWRhCiMKIyBVc2FnZToKIyAgICV1c2VyYWRkIFstUCBwYWNrYWdl XSBbLXUgdWlkXSBbLWQgaG9tZV9kaXJdIFstcyBzaGVsbF0gWy1jIGNvbW1lbnRdCiMgICBbLWcg aW5pdGlhbF9ncm91cF0gWy1HIGdyb3VwWywuLi5dXSBsb2dpbgojCiMgIC11IHVpZC4gUkVRVUlS RUQKIyAgLWcgZ2lkL2dyb3VwLiBSRVFVSVJFRAojICAtcyBkZWZhdWx0cyB0byAvYmluL2ZhbHNl CiMgIC1kIGRlZmF1bHRzIHRvIC91c3Ivc2hhcmUvZW1wdHkKIyAgLWMgTm8gZGVmYXVsdAojICAt ciBpcyBhY2NlcHRlZCBidXQgaWdub3JlZCAoaXQncyBhbHdheXMgc2V0KQojICAtayBza2VsZXRv biBkaXIuIGRlZmF1bHRzIHRvIC91c3Ivc2hhcmUvZW1wdHkKIyBycG0gc3BlY2lmaWMgZmxhZ3MK IyAgLVAgcGFja2FnZSBuYW1lLiBkZWZhdWx0cyB0byAle25hbWV9CiMKJXVzZXJhZGQoYzpkOmU6 ZjpnOkc6TW1rOm9wOnM6dTpyUDopIFwKJXshLXU6JXtlcnJvcjp1c2VyYWRkOiBSZXF1aXJlZCBh cmd1bWVudCAtdSBtaXNzaW5nfX0gXAoleyEtZzole2Vycm9yOnVzZXJhZGQ6IFJlcXVpcmVkIGFy Z3VtZW50IC1nIG1pc3Npbmd9fSBcCiV7IT8xOiV7ZXJyb3I6dXNlcmFkZDogUmVxdWlyZWQgcGFy YW1ldGVyIGxvZ2luIG1pc3Npbmd9fSBcCmlmIFsgLW4gImAvYmluL2lkIC11ICV7ZXhwYW5kOiV7 JXsjfX19IDI+L2Rldi9udWxsYCIgXTsgdGhlbiBcCglpZiBbICJgL2Jpbi9pZCAtdSAle2V4cGFu ZDoleyV7I319fWAiICE9ICIley11Kn0iIF07IHRoZW4gXAoJCWVjaG8gIkVycm9yOiB1c2VyICV7 ZXhwYW5kOiV7JXsjfX19IGRvZXNuJ3QgaGF2ZSB1aWQ9JXstdSp9LiBDb3JyZWN0IHRoaXMgYmVm b3JlIGluc3RhbGxpbmcgJXstUCp9JXshPy1QOiV7bmFtZX19LiIgMT4mMiBcCgkJZXhpdCAxIFwK CWZpIFwKZWxzZSBcCgllY2hvICJBZGRpbmcgdXNlciAle2V4cGFuZDoleyV7I319fSBVSUQ9JXst dSp9LiIgXAoJL3Vzci9zYmluL3VzZXJhZGQgXFxcCgkJJXstbTotbSAtayAley1rKn0leyEtazov dXNyL3NoYXJlL2VtcHR5fX0gXFxcCgkJLXUgJXstdSp9IFxcXAoJCS1yIFxcXAoJCS1kICV7LWQq fSV7IS1kOi91c3Ivc2hhcmUvZW1wdHl9IFxcXAoJCS1zICV7LXMqfSV7IS1zOi9iaW4vZmFsc2V9 IFxcXAoJCSV7LWM6LWMgIiUoc2V0IC0tICV7LWMqfSAleyp9OyBlY2hvICQxKSJ9XFxcCgkJLWcg JXstZyp9IFxcXAoJCSV7LU19IFxcXAoJCSV7LUc6LUcgJXstRyp9fSBcXFwKCQkle2V4cGFuZDol eyV7I319fSAxPiYyIHx8IGV4aXQgJD8gXAoJWyAhIC14IC91c3Ivc2Jpbi9uc2NkIF0gfHwgL3Vz ci9zYmluL25zY2QgLWkgcGFzc3dkIFwKZmk7CgojIFVzYWdlOgojICAgJWdyb3VwYWRkIFstUCBw YWNrYWdlXSBbLWcgZ2lkXSBncm91cAojCiMgLWcgZ2lkLiBSRVFVSVJFRAojCiMgU2FtcGxlOgoj ICAgJWdyb3VwYWRkIC1QICV7bmFtZX0tYmFzZSAtZyAle2dpZH0gJXtuYW1lfQoKJWdyb3VwYWRk KGc6UDpyZm8pCVwKJXshLWc6JXtlcnJvcjpncm91cGFkZDogUmVxdWlyZWQgYXJndW1lbnQgLWcg bWlzc2luZ319IFwKJXshPzE6JXtlcnJvcjpncm91cGFkZDogUmVxdWlyZWQgcGFyYW1ldGVyIGdy b3VwIG1pc3Npbmd9fSBcCmlmIFsgLW4gImAvdXNyL2Jpbi9nZXRnaWQgJXsxfWAiIF07IHRoZW4g XAoJaWYgWyAiYC91c3IvYmluL2dldGdpZCAlezF9YCIgIT0gIiV7LWcqfSIgXTsgdGhlbiBcCgkJ ZWNobyAiRXJyb3I6IGdyb3VwICV7MX0gZG9lc24ndCBoYXZlIGdpZD0ley1nKn0uIENvcnJlY3Qg dGhpcyBiZWZvcmUgaW5zdGFsbGluZyAley1QKn0leyE/LVA6JXtuYW1lfX0uIiAxPiYyIFwKCQll eGl0IDEgXAoJZmkgXAplbHNlIFwKCWVjaG8gIkFkZGluZyBncm91cCAlezF9IEdJRD0ley1nKn0u IiBcCgkvdXNyL3NiaW4vZ3JvdXBhZGQgLWcgJXstZyp9IC1yICV7MX0gMT4mMiB8fCBleGl0ICQ/ IFwKCVsgISAteCAvdXNyL3NiaW4vbnNjZCBdIHx8IC91c3Ivc2Jpbi9uc2NkIC1pIGdyb3VwIFwK Zmk7Cg==