В postgresql8.3-server%prein не создаётся (при необходимости) пользователь и группа postgres и из-за этого установка проходит со сбоями и в дальнейшем система не работает. Приходится вручную создавать пользователя и группу и назначать соответствующие права на каталоги, либо переустанавливать пакет после создания пользователя.
Пакет postgresql8.3-server требует по зависимостям postgresql-common, который в секции %pre как раз и создает как пользователя, так и группу postgres. Проверено на свежесгенерированной VE, баг не воспроизводится, пользователь и группа успешно создаются. В принципе, можно функциональность продублировать, но я не уверен, что это стоит делать.
Проблема в том, что Вы пытаетесь создать группу с предопределённым номером 46 и если он занят, то создание группы обламывается, а с ним и создание пользователя. Что у меня и произошло. Насколько необходимо создавать группу и пользователя именно с номером 46? Может лучше пусть система выбирает?
Наверное я не очень точно сказал - на чистую. Имелось в виду - на систему, на которой не было пользователя postgres. А так там много чего установлено.
(In reply to comment #2) > Проблема в том, что Вы пытаетесь создать группу с предопределённым номером 46 и > если он занят, то создание группы обламывается, а с ним и создание пользователя. Есть такое дело, но таки не в этом пакете, а в postgresql-common, который пока что не мой, а mithraen@ :) Думаю, багу стоит перевесить на postgresql-common, что и делаю.
2mithraen: а фиксированное выставление UID/GID 46 при создании пользователя postgres было по какой-то важной причине выставлено?
Так делать не надо. Если хочется фиксированный uid/gid, то нужно оформить FR на пакет setup, чтобы оно было сразу искаропки.
Такс... как убить сразу двух зайцев? В смысле попытаться все-таки создавать с фиксированым номером, но если он занят -- с любым другим?
Ну видимо нечто вроде getent group 46 || /usr/sbin/groupadd -r -f %pg_group >/dev/null 2>&1 ||: getent passwd 46 || /usr/sbin/useradd -g %pg_group -c 'pgsql' \ -d %pg_home -s /dev/null -r %pg_user >/dev/null 2>&1 ||:
Может всё же кто-нибудь знающий объяснит мне,зачем нужно неприменно регистрировать группу и пользователя под id 46, если и без этого можно обойтись?
(In reply to comment #9) > Может всё же кто-нибудь знающий объяснит мне,зачем нужно неприменно > регистрировать группу и пользователя под id 46, если и без этого можно обойтись? А уж если учесть, что на сегодня в пакете setup группа и пользователь postgres присутствуют в файле /etc/passwd именно под UID/GID 46, то по новой можно добавлять и без жесткой привязки. Если же кто-то вручную вынес системного пользователя - значит у него были на то причины. В общем, до появления внятного полиси на эту тему я бы предложил убрать в postgresql-common явное задание UID и GID.
Хм, я бы предложил как раз оставить. Аргументация -- сервис под этим псевдопользователем работает с данными и если есть возможность сохранить совместимость численных uid/gid между инсталяциями -- это надо сделать. Мишка, я как-то об это конкретные шишки набил, натягивая бэкап поверх новенького VE template. Хорошо, что сам заметил дивные права в результате. Если кто-то вынес системного пользователя -- он ССЗБ и пусть продолжает кувыркаться как хочет.
Тогда надо вообще убрать команду создания пользователя и группы, зачем, если они и так есть? Вместо этого поставить проверку наличия нужного пользователя и группы и злобно ругаться при их отсутствии, отказываясь от всяких гарантий (будет хотя бы понятно что ты ССЗБ).
Потому что в системе, которая растёт от древнего setup, может не быть этих пользователей-групп (они отдыхают в /etc/{passwd,shadow}.rpmnew в таком разе). Серёж, я по этим граблям походил уже достаточно, чтобы сказать именно то, что сказал: делать -- надо, если есть зарегистрированные в setup uid/gid -- пользоваться следует именно ими. См. тж. драфт/обсуждение здесь: http://freesource.info/wiki/AltLinux/Policy/UidGid
(In reply to comment #11) > Мишка, я как-то об это конкретные шишки набил, натягивая бэкап поверх новенького > VE template. Хорошо, что сам заметил дивные права в результате. Миш, хитровымученных вариантов может быть много. В данном случае проблема усугубляется еще и несовместимостью данных между разными версиями PostgreSQL. Миграция данных между _разными_ системами - это вобще отдельная тема, которую лучше отдельно обсуждать. > Если кто-то вынес системного пользователя -- он ССЗБ и пусть продолжает > кувыркаться как хочет. Ну, резервное копирование с привязкой к UID/GID и без переноса данных о пользователях/группах - это тоже повод для самостоятельного кувыркания :) JIMHO, будет вполне достаточно такого варианта: 1. В дефолтном /etc/passwd есть пользователь с фиксированными UID/GID (уже). 2. При установке пакета производится попытка создать пользователя, но уже без привязки к UID/GID (нужно убрать привязку). Кроме того, это надо решать в рамках полиси для всех пакетов, создающих псевдопользователей. А иначе мы просто видоизменим бардак, а не решим проблему.
(In reply to comment #14) > JIMHO, будет вполне достаточно такого варианта: > 1. В дефолтном /etc/passwd есть пользователь с фиксированными UID/GID (уже). 2a. При установке пакета производится попытка создать пользователя с ними же > 2. При установке пакета производится попытка создать пользователя, но уже без > привязки к UID/GID (нужно убрать привязку). > Кроме того, это надо решать в рамках полиси для всех пакетов, создающих > псевдопользователей. А иначе мы просто видоизменим бардак, а не решим проблему. Так вот в полиси я всерьёз собираюсь стоять на том, что uid/gid для псевдо, имеющих данные, _надо_ фиксировать и пытаться создавать именно одинаковые. С фолбэком на какие попало (не взрываться же).
Так сейчас что делать будем?
(In reply to comment #16) > Так сейчас что делать будем? Предлагаю: создать_группу_и_пользователя_с_46 || создать_каких_выйдет
(In reply to comment #17) > > Так сейчас что делать будем? > Предлагаю: создать_группу_и_пользователя_с_46 || создать_каких_выйдет Вполне нормальное решение, пока с полиси не определились.
Шлите патчи :)
postgresql-common-1.0-alt6 -> sisyphus: * Sat Oct 31 2009 Denis Smirnov <mithraen@altlinux> 1.0-alt6 - fix user/group creation (ALT#15268)
