Bug 21894

procmail не является привилегированной программой.
Файл /var/spool/mail/mutabor должен был быть создан заранее, например, при создании аккаунта с помощью useradd.

1) Какие должны быть владелец и права у /var/spool/mail/mutabor?
2) Проблема возникла при переходе либо с Сизифа выпуска начала июня 2005 года на 4.1, либо с 4.1 на p5 (точнее сказать не могу, т.к. 4.1 стоял очень короткое время как промежуточный этап перехода). Стало быть, новая формулировка проблемы такова: необходимо при обновлении пакета procmail необходимо проверять наличие файлов в /var/spool/mail для всех зарегистрированных пользователей и создавать эти файлы в случае их отсутствия.

(In reply to comment #2)
> 1) Какие должны быть владелец и права у /var/spool/mail/mutabor?

Это зависит от прав на каталог /var/spool/mail, мо умолчанию
%attr(0660,mutabor,root)

> 2) Проблема возникла при переходе либо с Сизифа выпуска начала июня 2005 года
> на 4.1, либо с 4.1 на p5 (точнее сказать не могу, т.к. 4.1 стоял очень короткое
> время как промежуточный этап перехода).

Скорее при переходе на postfix-2.2.5-alt2 (почти 4 года назад).

> Стало быть, новая формулировка проблемы
> такова: необходимо при обновлении пакета procmail необходимо проверять наличие
> файлов в /var/spool/mail для всех зарегистрированных пользователей и создавать
> эти файлы в случае их отсутствия.

Почему вы считаете, что для всех зарегистрированных пользователей следует создавать mailbox'ы?
И при чём тут обновление пакета procmail?

Альтернативно, можете выключить mailbox_unpriv_delivery на время переезда.

> > 1) Какие должны быть владелец и права у /var/spool/mail/mutabor?
> 
> Это зависит от прав на каталог /var/spool/mail, мо умолчанию
> %attr(0660,mutabor,root)

Спасибо, локально помогло.

> 
> > 2) Проблема возникла при переходе либо с Сизифа выпуска начала июня 2005 года
> > на 4.1, либо с 4.1 на p5 (точнее сказать не могу, т.к. 4.1 стоял очень короткое
> > время как промежуточный этап перехода).
> 
> Скорее при переходе на postfix-2.2.5-alt2 (почти 4 года назад).

Возможно. Я совсем недавно обновился почти одномоментно (с задержкой около суток) с Сизифа'05 на 4.1 и сразу же на p5.

> 
> > Стало быть, новая формулировка проблемы
> > такова: необходимо при обновлении пакета procmail необходимо проверять наличие
> > файлов в /var/spool/mail для всех зарегистрированных пользователей и создавать
> > эти файлы в случае их отсутствия.
> 
> Почему вы считаете, что для всех зарегистрированных пользователей следует
> создавать mailbox'ы?
> И при чём тут обновление пакета procmail?

Возможно, не procmail, а shadow-utils, куда входит useradd. Новый useradd создаёт у вновь регистрируемого пользователя /var/spool/mail/$NAME. Но если система достаточно старая, то у пользователей, зарегистрированных до того, как useradd научился это делать, файлы в /var/spool/mail отсутствуют. Как следствие -- возможна описанная ошибка. Кто должен этим заниматься -- useradd или procmail, который эти файлы использует -- решать вам, т.к. оба пакета ваши. Как альтернативный вариант -- запретить обновлять систему, отключить функцию dist-upgrade у apt-get и объявить единственно правильным способом обновления системы переустановку новой взамен старой.

Да нет же.  Просто такой подарочный набор граблей стоит описать здесь:
http://www.altlinux.org/Changes/Master24

См. тж.
http://lists.altlinux.org/pipermail/sisyphus/2001-August/221275.html
http://lists.altlinux.org/pipermail/sisyphus/2001-September/221531.html

(В ответ на комментарий №6)
> Да нет же.  Просто такой подарочный набор граблей стоит описать здесь:
> http://www.altlinux.org/Changes/Master24
> 

Т.е. ты считаешь, что фирменные грабли в подарочной упаковке с ленточкой "с любовью от ALT Linux" ошибкой не являются -- Даже если достоверно известна причина их возникновения и способы решения проблемы? Если так, то я скоро действительно повешу на apt просьбу убрать команду "dist-upgrade", после чего, естественно, начну смотреть в сторону дистрибутива с более ответственным отношением к поддержке. А заодно устрою в рассылках разъяснительную кампанию, чтобы пользователи знали, на что они идут, если выберут ALT Linux.

> См. тж.
> http://lists.altlinux.org/pipermail/sisyphus/2001-August/221275.html
> http://lists.altlinux.org/pipermail/sisyphus/2001-September/221531.html

Блондинка виков не читает. Ей объяснили, как пользоваться программой synaptic, а рутовый пароль у неё написан на днище мышки :) А искать в архивах рассылки -- проще убиться веником.

(In reply to comment #5)
> > > 1) Какие должны быть владелец и права у /var/spool/mail/mutabor?
> > 
> > Это зависит от прав на каталог /var/spool/mail, мо умолчанию
> > %attr(0660,mutabor,root)
> 
> Спасибо, локально помогло.
> 
> > 
> > > 2) Проблема возникла при переходе либо с Сизифа выпуска начала июня 2005 года
> > > на 4.1, либо с 4.1 на p5 (точнее сказать не могу, т.к. 4.1 стоял очень короткое
> > > время как промежуточный этап перехода).
> > 
> > Скорее при переходе на postfix-2.2.5-alt2 (почти 4 года назад).
> 
> Возможно. Я совсем недавно обновился почти одномоментно (с задержкой около
> суток) с Сизифа'05 на 4.1 и сразу же на p5.
> 
> > 
> > > Стало быть, новая формулировка проблемы
> > > такова: необходимо при обновлении пакета procmail необходимо проверять наличие
> > > файлов в /var/spool/mail для всех зарегистрированных пользователей и создавать
> > > эти файлы в случае их отсутствия.
> > 
> > Почему вы считаете, что для всех зарегистрированных пользователей следует
> > создавать mailbox'ы?
> > И при чём тут обновление пакета procmail?
> 
> Возможно, не procmail, а shadow-utils, куда входит useradd. Новый useradd
> создаёт у вновь регистрируемого пользователя /var/spool/mail/$NAME. Но если
> система достаточно старая, то у пользователей, зарегистрированных до того, как
> useradd научился это делать, файлы в /var/spool/mail отсутствуют. Как следствие
> -- возможна описанная ошибка. Кто должен этим заниматься -- useradd или
> procmail, который эти файлы использует -- решать вам, т.к. оба пакета ваши. Как
> альтернативный вариант -- запретить обновлять систему, отключить функцию
> dist-upgrade у apt-get и объявить единственно правильным способом обновления
> системы переустановку новой взамен старой.

FYI, useradd creates user mailboxes by default more than 8 years already.
If you decided to remove mailbox files, it's up to you, but please stop this nonsense.

(In reply to comment #7)
> > Да нет же.  Просто такой подарочный набор граблей стоит описать здесь:
> Т.е. ты считаешь, что фирменные грабли в подарочной упаковке с ленточкой "с
> любовью от ALT Linux" ошибкой не являются
Я считаю, что не всякая ошибка стоит исправления.  Угробливание непропорционального количества времени на исправление ошибки может также быть ошибкой, причём более трудноисправимой, если уж тебе хочется в этих терминах.

> Даже если достоверно известна причина их возникновения и способы решения
> проблемы?
Постой.  Известны способы решения проблемы _администратором_.  Теперь подумай над алгоритмом, а лучше сразу привесь его патчиком.

> Если так, то
Слушай, ну чушь-то пороть не надо.  Для всего скипнутого причины есть, но они (по крайней мере у меня) куда более веские.

> > http://lists.altlinux.org/pipermail/sisyphus/2001-August/221275.html
> > http://lists.altlinux.org/pipermail/sisyphus/2001-September/221531.html
> Блондинка виков не читает. Ей объяснили, как пользоваться программой synaptic
Ты на год посмотри :)  У блондинок веники (бишь винчестеры) столько не живут.

Ergo: если твой перфекционизм ещё круче Диминого -- вперёд на танки, кто ж мешает.  И да, походи по другим дистрибутивам и попробуй попрыгать через несколько лет.  А мы полюбуемся, что тогда запоёшь.

(In reply to comment #9)
> Ergo: если твой перфекционизм ещё круче Диминого -- вперёд на танки, кто ж
> мешает.  И да, походи по другим дистрибутивам и попробуй попрыгать через
> несколько лет.  А мы полюбуемся, что тогда запоёшь.

A clean update from an 8 years old installation is unattainable aim.  Good luck.

(В ответ на комментарий №8)

> 
> FYI, useradd creates user mailboxes by default more than 8 years already.

Через пару месяцев вернусь домой -- специально проверю, поставив с нуля 2.4. Как вариант -- там инсталятор использовал неправильный useradd.

> If you decided to remove mailbox files, it's up to you, but please stop this
> nonsense.

Т.е. это нормальное состояние, когда пользователя удалили, а его пожитки в виде /var/spool/mail/_username_ остались?

P.S. В следующий раз буду отвечать на латыни.

(В ответ на комментарий №9)

> > Т.е. ты считаешь, что фирменные грабли в подарочной упаковке с ленточкой "с
> > любовью от ALT Linux" ошибкой не являются
> Я считаю, что не всякая ошибка стоит исправления.  Угробливание
> непропорционального количества времени на исправление ошибки может также быть
> ошибкой, причём более трудноисправимой, если уж тебе хочется в этих терминах.

Какое к чёрту непропорциональное?! Для того, кто в теме, исправление данной ошибки отнимет не более 10 минут ИМХО.

> 
> > Даже если достоверно известна причина их возникновения и способы решения
> > проблемы?
> Постой.  Известны способы решения проблемы _администратором_.  Теперь подумай
> над алгоритмом, а лучше сразу привесь его патчиком.

Уже почти придумал. Единственное, что мне для этого надо -- узнать список зарегистрированных в системе реальных (не псевдо) пользователей.

(In reply to comment #11)
> Какое к чёрту непропорциональное?! Для того, кто в теме, исправление данной
> ошибки отнимет не более 10 минут ИМХО.

Automatic update scripts have no idea whether mailboxes have to be created or not.  I believe that only system administrator can fix this issue.

> Уже почти придумал. Единственное, что мне для этого надо -- узнать список
> зарегистрированных в системе реальных (не псевдо) пользователей.

$ getent passwd |awk -F: '{printf("%s\t%s\n",$7,$1)}' |sort -k1,1 |join -j1 -o1.2 - <(echo;cat /etc/shells |sort -u)

- this algorithm treats all users with valid shells as real users, and all the rest as pseudousers.