Re: Известные группы в /etc/group. Ищу официальное описание и полиси.
Eugene Berdnikov -> debian-russian@lists.debian.org @ Fri, 28 Sep 2012 11:19:24 +0400:
>> >> >> Ну, ты хотя бы эти три раскрой. Вот у тебя пакет, который
>> >> >> внутри кода использует имя группы, допустим, remote-dev. Начнем
>> >> >> с вопроса "как ты в postinst обнаруживаешь, что то же имя группы
>> >> >> с другими целями использует какой-то другой пакет?
>> >>
>> >> EB> Не в postinst, а в preinst -- по статус-коду от groupadd.
>> >>
>> >> ... который будет точно таким же, если это ты сам при прошлой установке
>> >> ее добавил.
>>
>> EB> Я немного знаю борновский шелл и потому умею комбинировать разные условия
>> EB> в предикаты. :-) В данном случае нужно скомбинировать статус от groupadd
>> EB> с параметром $1, в который dpkg передаёт "install", "upgrade", etc.
>>
>> Цикл установка-снос-установка эта система либо не переживает, либо
>> сносит группу при сносе. Подразумевая, что она ТОЧНО никому больше не
>> нужна, и юзеров в нее не добавляют (то есть информацию о членстве в
>> группе при сносе сохранять ТОЧНО не надо).
EB> Ну да, изначально к рассмотрению была предложена ситуация, когда пакет
EB> считает свою группу уникальной, тогда обнаружение группы с идентичным
EB> именем при установке означает конфликт. Самая верхняя твоя цитата:
EB> "то же имя группы с другими целями использует какой-то другой пакет".
Изначально - в смысле Олександром - как раз нет. Он как раз писал (в
том числе) о группах потенциально общего пользования. И в моей цитате
существенно "с другими целями". Если с теми же целями - то это как раз
нормально.
Впрочем, даже в случае уникальности, если в группу надо добавлять
реальных юзеров, то сносить ее при remove нельзя, можно только при
purge. А значит, цикл установка-снос-установка все равно приводит тебя
к false positive. Нет, опять же можно делать разделение "есть
заполненный конфиг - нет заполненного конфига" для различения ситуации
"был remove или не было", но тут ты немедленно станешь недружелюбным по
отношению к пресидам debconf. Это тоже можно учесть и обработать, но
сложность задачи и количество информации, которую нужно добыть и учесть,
растет на глазах.
Как раз в случае уникальности при грамотном выборе имени группы можно
рассчитывать на то, что наличие ее в системе НЕ является признаком
конфликта, а является вот ровно следом от прошлой установки, и надо
молча использовать готовое, а не подскакивать нервно.
>> При таком предположении
>> проще взять заведомо уникальное имя группы, сгенерированное путем
>> хэширования вывода /dev/random в момент сборки пакета, и не париться.
EB> Хэш плох тем, что имя группы будет длинным и/или лишённым
EB> смысловой нагрузки. При этом от софтины требуется возможность
EB> менять имя своей рабочей группы.
Осмысленный префикс и часть хэша. git вон сокращает в норме до первых 7
символов свой sha1, на практике хватает. (Он, правда, умеет работать и
с полным, и возможно, даже каждый раз проверяет на уникальность
сокращенный прежде чем выбрать ОДИН коммит - но на коллизию по полному
он уже явно не рассчитан. Но это детали, а на практике семи хватает.)
exim-d25caac вряд ли так уж сильно уступает в осмысленности Debian-exim
и всего на 1 символ длиннее, и при этом шансы нарваться на то, что
кто-то другой случайно получит со своего /dev/random такой же результат,
куда ближе к нулю, чем вероятность допустить ошибку в решении
вышеобсуждаемой задачи.
Reply to: