Перестали доставляться сообщения об итогах работы системных служб. В 12-ой консоли вижу следующее: Oct 7 09:31:05 Iron_Felix postfix/pickup[5908]: 1FFC692472: uid=0 from=<root> Oct 7 09:31:05 Iron_Felix postfix/cleanup[8163]: 1FFC692472: message-id=<20091007053105.1FFC692472@Iron_Felix.localdomain> Oct 7 09:31:07 Iron_Felix postfix/qmgr[5909]: 1FFC692472: from=<root@Iron_Felix.localdomain>, size=969, nrcpt=1 (queue active) Oct 7 09:31:08 Iron_Felix postfix/local[8170]: 1FFC692472: to=<mutabor@Iron_Felix.localdomain>, orig_to=<root>, relay=local, delay=5.1, delays=3.6/0.48/0/1, dsn=5.2.0, status=bounced (can't create user output file. Command output: procmail: Couldn't create "/var/spool/mail/mutabor" ) Oct 7 09:31:08 Iron_Felix postfix/cleanup[8163]: 81E7D92473: message-id=<20091007053108.81E7D92473@Iron_Felix.localdomain> Oct 7 09:31:08 Iron_Felix postfix/qmgr[5909]: 81E7D92473: from=<>, size=2924, nrcpt=1 (queue active) Oct 7 09:31:08 Iron_Felix postfix/bounce[8173]: 1FFC692472: sender non-delivery notification: 81E7D92473 Oct 7 09:31:08 Iron_Felix postfix/qmgr[5909]: 1FFC692472: removed Oct 7 09:31:08 Iron_Felix postfix/local[8170]: 81E7D92473: to=<mutabor@Iron_Felix.localdomain>, orig_to=<root@Iron_Felix.localdomain>, relay=local, delay=0.46, delays=0.06/0/0/0.4, dsn=5.2.0, status=bounced (can't create user output file. Command output: procmail: Couldn't create "/var/spool/mail/mutabor" ) Oct 7 09:31:08 Iron_Felix postfix/qmgr[5909]: 81E7D92473: removed [mutabor@Iron_Felix tmp]$ ls -l /var/spool | grep mail drwxrws--t 2 root mail 4096 Фев 25 2009 mail Т.е. с правами на каталог вроде всё в порядке. Наблюдается после перехода на p5 с 4.1
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.
