Всем привет. Есть одна проблемка. Случайно обнаружил, что queue ID в PostFix может быть одинаковым даже за одни сутки. В sendmail такого не наблюдал. Соответственно очень и очень сложно сделать привязку from-to. Т.к. единственное, что может быть у сообщения одно и тоже по всему пути его следования, при обратотке, это queue ID, а он оказывается может быть один и тот же за сутки. Да, в логах есть фраза, что с таким-то номером id удален, но стает вопрос - как тогда собрать воедино куски обработки (т.е. from -> to) когда сообщение принято сегодня, а отправлено завтра или позже? Копаться в исходниках postfix'а и тем более писать патчи не дело. Может где-то в конфигах можно поставить определенное значение по времени в течение которого ID не может быть одинаковым. Пример лога: May 14 00:03:33 gro postfix/smtpd[68733]: 785654833B: client=localhost[127.0.0.1] ^^^^^^^^^^ Вот этот номер может за одни сутки быть два раза, пока я такое находил за неделю раза 3-4 и с разницей в 8-10 часов. И у меня нет уверенности, что он не поменяется только один раз. Во всяком случае в доке нет четкого описания этого маразма. Можно конечно отслеживать еще и дату, но это как-то круто уж будет. Опять же, плюс/пинус пару минут. Проше по чайнику наколупать авторам postfix'а, что мол "шо ж вы делаете?" :) Так написать парсер для сборки логов (без погрешностей в особо крупнух размерах на большем трафике) не представляется возможным - будут погрешности и может даже большие. Может я лабуду написал и это все уже народ обходил, тогда расскажите как? --- With best regards, Alexander Fedorko =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Fri, May 14, 2004 at 16:06:59, alx wrote about "[uanog] queue ID в PostFix":
Случайно обнаружил, что queue ID в PostFix может быть одинаковым даже за одни сутки. Он генерируется случайным образом. В sendmail такого не наблюдал.
До 8.10 было сплошь и рядом. В 8.10 переделали на уникальные (с повтором за 60 лет;))
Да, в логах есть фраза, что с таким-то номером id удален, Уже есть? Мне приходилось патчить, чтобы это писалось.
но стает вопрос - как тогда собрать воедино куски обработки (т.е. from -> to) когда сообщение принято сегодня, а отправлено завтра или позже? Копаться в исходниках postfix'а и тем более писать патчи не дело. Может где-то в конфигах можно поставить определенное значение по времени в течение которого ID не может быть одинаковым. Сомневаюсь. Попробуй переделать генерацию случайным образом на использование timestamp+pid+seq.
-netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, 14 May 2004, Valentin Nechayev wrote:
Случайно обнаружил, что queue ID в PostFix может быть одинаковым даже за одни сутки. Он генерируется случайным образом.
Я бы так сказал, что хреновый у них генератор случайных номеров.
Да, в логах есть фраза, что с таким-то номером id удален, Уже есть? Мне приходилось патчить, чтобы это писалось.
Да. Уже есть в каком-то snap'е 2.0.18 было уже.
но стает вопрос - как тогда собрать воедино куски обработки (т.е. from -> to) когда сообщение принято сегодня, а отправлено завтра или позже? Копаться в исходниках postfix'а и тем более писать патчи не дело. Может где-то в конфигах можно поставить определенное значение по времени в течение которого ID не может быть одинаковым. Сомневаюсь. Попробуй переделать генерацию случайным образом на использование timestamp+pid+seq.
Этого-то я и боялся, что вердикт будет подобный, что только патчить и все. Не понимаю, что сложного, написать такое изначально им было? :( Просто из-за этого написать более-менее нормальный парсер не возможно. Двух проходность не канает (сперва from собрать, а потом to), т.к. queue ID может быть одинаковый. Сделать все в ожном проходе тоже сложно ,т.к. сообщения в логе идут не по порядку. Это было бы пол беды, если бы при передаче от своих процессов на (например) тот же amavis postfix меняет номер. Спасибо, что он хоть пишет на какой он поменял. Но и вот эта смена очень часто бывает раскидана по логу в разных местах. Т.е. очень насто сперва и дет конекшен и генерация номера от amavis'а, а потом только где-то ниже встречается надпись, что оказывается это был номер с которым amavis должен был вернуть проверенное сообщение.В общем обработка крайне затруднена. Погрешности неизбежать :( --- With best regards, Alexander Fedorko =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, May 14, 2004 at 04:50:54PM +0300, Alexander Fedorko wrote:
вопрос - как тогда собрать воедино куски обработки (т.е. from -> to) когда сообщение принято сегодня, а отправлено завтра или позже? Копаться в исходниках postfix'а и тем более писать патчи не дело. Может где-то в конфигах можно поставить определенное значение по времени в течение которого ID не может быть одинаковым. Сомневаюсь. Попробуй переделать генерацию случайным образом на использование timestamp+pid+seq.
Этого-то я и боялся, что вердикт будет подобный, что только патчить и все.
Не бойся, это не единственный выход. Есть еще другое решение.... (пауза)... - выкинуть. :)
Не понимаю, что сложного, написать такое изначально им было? :(
Просто из-за этого написать более-менее нормальный парсер не возможно. Двух проходность не канает (сперва from собрать, а потом to), т.к. queue ID может быть одинаковый. Сделать все в ожном проходе тоже сложно ,т.к. сообщения в логе идут не по порядку. Это было бы пол беды, если бы при передаче от своих процессов на (например) тот же amavis postfix меняет номер. Спасибо, что он хоть пишет на какой он поменял. Но и вот эта смена очень часто бывает раскидана по логу в разных местах. Т.е. очень насто сперва и дет конекшен и генерация номера от amavis'а, а потом только где-то ниже встречается надпись, что оказывается это был номер с которым amavis должен был вернуть проверенное сообщение.В общем обработка крайне затруднена. Погрешности неизбежать :(
=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Fri, May 14, 2004 at 18:01:40, victor wrote about "[uanog] Re: queue ID в PostFix":
Этого-то я и боялся, что вердикт будет подобный, что только патчить и все.
Не бойся, это не единственный выход. Есть еще другое решение.... (пауза)... - выкинуть.
:)
Угу, вместе с email.
Не понимаю, что сложного, написать такое изначально им было? :( Задача не ставилась, наверно.
Просто из-за этого написать более-менее нормальный парсер не возможно. Двух проходность не канает (сперва from собрать, а потом to), т.к. queue ID может быть одинаковый. Сделать все в ожном проходе тоже сложно ,т.к. сообщения в логе идут не по порядку. Это было бы пол беды, если бы при передаче от своих процессов на (например) тот же amavis postfix меняет номер. Спасибо, что он хоть пишет на какой он поменял. Но и вот эта смена очень часто бывает раскидана по логу в разных местах. Т.е. очень насто сперва и дет конекшен и генерация номера от amavis'а, а потом только где-то ниже встречается надпись, что оказывается это был номер с которым amavis должен был вернуть проверенное сообщение.В общем обработка крайне затруднена. Погрешности неизбежать :(
Так никто толком задачу записи логов не решает, так, чтобы не требовались дикие ухищрения. sendmail - клонирования, DSN'ы. qmail - надо связывать по номеру доставки. Exim - qid генерируется только по приходу тела, а все что было до того - ненумеровано. postfix просто поддерживает дурную традицию... -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi Valentin,
Просто из-за этого написать более-менее нормальный парсер не возможно. Двух проходность не канает (сперва from собрать, а потом to), т.к. queue ID может быть одинаковый. Сделать все в ожном проходе тоже сложно, т.к. сообщения в логе идут не по порядку. Это было бы пол беды, если бы при передаче от своих процессов на (например) тот же amavis postfix меняет номер. Спасибо, что он хоть пишет на какой он поменял. Но и вот эта смена очень часто бывает раскидана по логу в разных местах. Т.е. очень насто сперва и дет конекшен и генерация номера от amavis'а, а потом только где-то ниже встречается надпись, что оказывается это был номер с которым amavis должен был вернуть проверенное сообщение.В общем обработка крайне затруднена. Погрешности неизбежать :(
Так никто толком задачу записи логов не решает, так, чтобы не требовались дикие ухищрения. sendmail - клонирования, DSN'ы. qmail - надо связывать по номеру доставки. Exim - qid генерируется только по приходу тела, а все что было до того - ненумеровано. postfix просто поддерживает дурную традицию...
Netch, а разве это задача записи логов? По-моему логи нужны для отладки. А для статистики, например, никто не мешает пользоваться другими средствами и реализовывать их отдельно. По логам статистику обычно считать получается... к счастью... но по-моему они все же не для того. -- Michael Скорей скажите -- где тут модератор?.. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Fri, May 14, 2004 at 17:31:23, mp wrote about "[uanog] Re: queue ID в PostFix":
Так никто толком задачу записи логов не решает, так, чтобы не требовались дикие ухищрения. sendmail - клонирования, DSN'ы. qmail - надо связывать по номеру доставки. Exim - qid генерируется только по приходу тела, а все что было до того - ненумеровано. postfix просто поддерживает дурную традицию... Netch, а разве это задача записи логов? По-моему логи нужны для отладки.
Для диагностики в первую очередь. Для отладки во вторую.
А для статистики, например, никто не мешает пользоваться другими средствами и реализовывать их отдельно.
Откуда взялось рассмотрение для статистики?
По логам статистику обычно считать получается... к счастью... но по-моему они все же не для того. Вероятно. Хотя хорошие логи годятся и для статистики.
-netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi Valentin,
Для диагностики в первую очередь. Для отладки во вторую.
А для статистики, например, никто не мешает пользоваться другими средствами и реализовывать их отдельно.
Откуда взялось рассмотрение для статистики?
Ну а для чего? Если для регистрации - тоже вполне можно решать отдельно, и тогда для разработчика будет очевидной необходимость уникальности каких-нть идентификаторов.
По логам статистику обычно считать получается... к счастью... но по-моему они все же не для того. Вероятно. Хотя хорошие логи годятся и для статистики.
Годятся. Но мне не нравится... :-\ -- Michael Призывы жить без дураков многие считают геноцидом. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, May 14, 2004 at 06:24:07PM +0300, Valentin Nechayev wrote:
Fri, May 14, 2004 at 18:01:40, victor wrote about "[uanog] Re: queue ID в PostFix":
Этого-то я и боялся, что вердикт будет подобный, что только патчить и все.
Не бойся, это не единственный выход. Есть еще другое решение.... (пауза)... - выкинуть.
:)
Угу, вместе с email.
Нет, email оставить, postfix - выкинуть. Можно, конечно, и его оставить, но тогда - патчить. :))
Не понимаю, что сложного, написать такое изначально им было? :( Задача не ставилась, наверно.
Хммм...
Так никто толком задачу записи логов не решает, так, чтобы не требовались дикие ухищрения. sendmail - клонирования, DSN'ы. qmail - надо связывать по номеру доставки. Exim - qid генерируется только по приходу тела, а все что было до того - ненумеровано.
qid - это id объекта в почтовой очереди. Нет тела - нет и объекта. Что тебя смущает? =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Fri, May 14, 2004 at 19:01:09, victor wrote about "[uanog] Re: queue ID в PostFix":
Так никто толком задачу записи логов не решает, так, чтобы не требовались дикие ухищрения. sendmail - клонирования, DSN'ы. qmail - надо связывать по номеру доставки. Exim - qid генерируется только по приходу тела, а все что было до того - ненумеровано. qid - это id объекта в почтовой очереди. Нет тела - нет и объекта. Что тебя смущает?
То, что для "несуществующего" объекта есть существующий и уже наделавший последствий конверт (env-from, env-to...) -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, 14 May 2004, Michael Petuschak wrote:
Просто из-за этого написать более-менее нормальный парсер не возможно. Двух проходность не канает (сперва from собрать, а потом to), т.к. queue ID может быть одинаковый. Сделать все в ожном проходе тоже сложно, т.к. сообщения в логе идут не по порядку. Это было бы пол беды, если бы при передаче от своих процессов на (например) тот же amavis postfix меняет номер. Спасибо, что он хоть пишет на какой он поменял. Но и вот эта смена очень часто бывает раскидана по логу в разных местах. Т.е. очень насто сперва и дет конекшен и генерация номера от amavis'а, а потом только где-то ниже встречается надпись, что оказывается это был номер с которым amavis должен был вернуть проверенное сообщение.В общем обработка крайне затруднена. Погрешности неизбежать :(
Так никто толком задачу записи логов не решает, так, чтобы не требовались дикие ухищрения. sendmail - клонирования, DSN'ы. qmail - надо связывать по номеру доставки. Exim - qid генерируется только по приходу тела, а все что было до того - ненумеровано. postfix просто поддерживает дурную традицию...
Netch, а разве это задача записи логов? По-моему логи нужны для отладки.
Согласен, но тогда что нужно использовать для ведения статистики только основываясь на postfix'е? --- With best regards, Alexander Fedorko =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi Alexander,
Так никто толком задачу записи логов не решает, так, чтобы не требовались дикие ухищрения. sendmail - клонирования, DSN'ы. qmail - надо связывать по номеру доставки. Exim - qid генерируется только по приходу тела, а все что было до того - ненумеровано. postfix просто поддерживает дурную традицию...
Netch, а разве это задача записи логов? По-моему логи нужны для отладки.
Согласен, но тогда что нужно использовать для ведения статистики только основываясь на postfix'е?
Извиняюсь, что не в тему. Это я так. О связи логов со статистикой и том, что надоело ее grep'ом считать. Увы. Да, кстати, привязываются же к sendmail/postfix всевозможные внешние тулзы для разных действий над каждым письмом. Почему бы не сделать скриптик, к-рый бы на каждое письмо вызывался и ставил нужные галочки в какой-нть SQL..? (Или даже запускал бы rrdupdate для наглядного изображения... хотя все русурсы съест, пожалуй.) -- Michael В подвале гордо реял буревестник. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sat, 15 May 2004, Michael Petuschak wrote:
Так никто толком задачу записи логов не решает, так, чтобы не требовались дикие ухищрения. sendmail - клонирования, DSN'ы. qmail - надо связывать по номеру доставки. Exim - qid генерируется только по приходу тела, а все что было до того - ненумеровано. postfix просто поддерживает дурную традицию...
Netch, а разве это задача записи логов? По-моему логи нужны для отладки.
Согласен, но тогда что нужно использовать для ведения статистики только основываясь на postfix'е?
Извиняюсь, что не в тему. Это я так. О связи логов со статистикой и том, что надоело ее grep'ом считать. Увы.
Да, кстати, привязываются же к sendmail/postfix всевозможные внешние тулзы для разных действий над каждым письмом. Почему бы не сделать скриптик, к-рый бы на каждое письмо вызывался и ставил нужные галочки в какой-нть SQL..? (Или даже запускал бы rrdupdate для наглядного изображения... хотя все русурсы съест, пожалуй.)
Ну rrdupdate можно и раз в надцать минут запускать, я думаю. В вот скриптик это идея. Вопрос только в том как его в том же postfix вызвать. Хотя подумать надо будет.. завтра :) --- With best regards, Alexander Fedorko =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sun, May 16, 2004 at 07:20:37PM +0300, Alexander Fedorko wrote:
On Sat, 15 May 2004, Michael Petuschak wrote:
Да, кстати, привязываются же к sendmail/postfix всевозможные внешние тулзы для разных действий над каждым письмом. Почему бы не сделать скриптик, к-рый бы на каждое письмо вызывался и ставил нужные галочки в какой-нть SQL..? (Или даже запускал бы rrdupdate для наглядного изображения... хотя все русурсы съест, пожалуй.)
Ну rrdupdate можно и раз в надцать минут запускать, я думаю. В вот скриптик это идея. Вопрос только в том как его в том же postfix вызвать. Хотя подумать надо будет.. завтра :) Проще пареной репы - system() в куда-тебе-надо вставить... (smtpd - на приёме письма, smtp - на отправке). Для немирного применения такое есть...
-- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, May 14, 2004 at 07:06:42PM +0300, Valentin Nechayev wrote:
Fri, May 14, 2004 at 19:01:09, victor wrote about "[uanog] Re: queue ID в PostFix":
Так никто толком задачу записи логов не решает, так, чтобы не требовались дикие ухищрения. sendmail - клонирования, DSN'ы. qmail - надо связывать по номеру доставки. Exim - qid генерируется только по приходу тела, а все что было до того - ненумеровано. qid - это id объекта в почтовой очереди. Нет тела - нет и объекта. Что тебя смущает?
То, что для "несуществующего" объекта есть существующий и уже наделавший последствий конверт (env-from, env-to...)
Да, и последствиями этими может быть решение о непринятии собственно тела. Нет появившегося в очереди объекта - нет и субъекта идентификации. Какой смысл генерировать идентификатор для [env-from, env-to] ? Пытаюсь понять, почему ты видишь в этом недостаток, но пока что не понял... =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Thu, May 20, 2004 at 16:57:37, victor wrote about "[uanog] Re: queue ID в PostFix":
Так никто толком задачу записи логов не решает, так, чтобы не требовались дикие ухищрения. sendmail - клонирования, DSN'ы. qmail - надо связывать по номеру доставки. Exim - qid генерируется только по приходу тела, а все что было до того - ненумеровано. qid - это id объекта в почтовой очереди. Нет тела - нет и объекта. Что тебя смущает?
То, что для "несуществующего" объекта есть существующий и уже наделавший последствий конверт (env-from, env-to...)
Да, и последствиями этими может быть решение о непринятии собственно тела. Нет появившегося в очереди объекта - нет и субъекта идентификации. Какой смысл генерировать идентификатор для [env-from, env-to] ?
Чтобы когда xxx@yyy спросит "где письма для меня?" - было бы по каким словам грепать и не путаться в логах.
Пытаюсь понять, почему ты видишь в этом недостаток, но пока что не понял...
Представь себе задачу найти в логах, почему письмо не принято. -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (5)
-
Alexander Fedorko -
Michael Petuschak -
Paul Arakelyan -
Valentin Nechayev -
Victor Forsyuk