Bug 15268

Пакет 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)