❗️Хочу предупредить всех, кто администрирует почтовые сервера, где в составе есть imap сервер Dovecot. В версии 2.4 очень сильно поменялся формат конфигурационного файла. Я вообще первый раз сталкиваюсь с такими кардинальными изменениями от версии к версии. Там натурально всё ломается после обновления и правкой пары изменившихся параметров не отделаться. Поменялся и синтаксис, и логика оформления. Какие-то параметры, плагины вообще исчезли.
Я краем уха уже слышал о том, что там конфигурация изменилась, но не предполагал, что настолько. В Debian 13 в репозиториях уже живёт версия 2.4, поэтому если будете обновлять систему, непременно столкнётесь с этой проблемой. Я потому и стал этим заниматься, потому что всё равно придётся рано или поздно.
Новую конфигурацию в итоге создал, она уже работает, отлаживаю. Потратил почти день на это. Сейчас тружусь над обновлением своей статьи по установке и настройке почтового сервера. Очень много изменений. И очень объёмный материал. Пишу и думаю, а надо ли вообще это сейчас кому-нибудь? Кто-то будет почтовый сервер вручную собирать из компонентов?
А с другой стороны, если этого не делать, то как научиться и разобраться в этой теме? Почта как была актуальной, так и осталась по сей день. Откуда-то всё равно должны браться специалисты из этой сферы. А самый простой способ освоить продукт - собрать его самостоятельно из компонентов. RuPost, кстати, как раз таким самосбором и является на базе open source софта.
📌Полезные ссылки по теме:
⇨ https://doc.dovecot.org/main/installation/upgrade/2.3-to-2.4.html
⇨ https://monospace.games/posts/20250815-dovecot-24.html
⇨ https://willem.com/en/2025-06-04_breaking-changes/
ИИшки, кстати, по этой задаче не помогли. Пришлось самому разбираться и переводить конфигурацию со старой версии на новую. Получился наглядный пример, как они полностью пасуют перед задачей, которую ещё не спарсили в человеческих статьях, потому что их практически нет.
#mailserver
Я краем уха уже слышал о том, что там конфигурация изменилась, но не предполагал, что настолько. В Debian 13 в репозиториях уже живёт версия 2.4, поэтому если будете обновлять систему, непременно столкнётесь с этой проблемой. Я потому и стал этим заниматься, потому что всё равно придётся рано или поздно.
Новую конфигурацию в итоге создал, она уже работает, отлаживаю. Потратил почти день на это. Сейчас тружусь над обновлением своей статьи по установке и настройке почтового сервера. Очень много изменений. И очень объёмный материал. Пишу и думаю, а надо ли вообще это сейчас кому-нибудь? Кто-то будет почтовый сервер вручную собирать из компонентов?
А с другой стороны, если этого не делать, то как научиться и разобраться в этой теме? Почта как была актуальной, так и осталась по сей день. Откуда-то всё равно должны браться специалисты из этой сферы. А самый простой способ освоить продукт - собрать его самостоятельно из компонентов. RuPost, кстати, как раз таким самосбором и является на базе open source софта.
📌Полезные ссылки по теме:
⇨ https://doc.dovecot.org/main/installation/upgrade/2.3-to-2.4.html
⇨ https://monospace.games/posts/20250815-dovecot-24.html
⇨ https://willem.com/en/2025-06-04_breaking-changes/
ИИшки, кстати, по этой задаче не помогли. Пришлось самому разбираться и переводить конфигурацию со старой версии на новую. Получился наглядный пример, как они полностью пасуют перед задачей, которую ещё не спарсили в человеческих статьях, потому что их практически нет.
#mailserver
doc.dovecot.org
2.3 to 2.4 | Dovecot CE
Dovecot CE Documentation
340👍283👎2
Я наконец-то закончил обновление статьи про локальный почтовый сервер на базе Postfix и Dovecot:
⇨ Настройка Postfix + Dovecot + Postfixadmin + Roundcube + DKIM на Debian
Она актуальна на сегодняшний день на базе Debian 13 и стандартных пакетов в её репозитории. Хотя для примера я некоторые компоненты скачивал из их репозиториев и устанавливал вручную, так как со временем в Debian версии начинают отставать от актуальных.
Старую версию статьи под Debian 12 сохранил в виде статической страницы и упаковал в архив. Ссылка в начале новой статьи. Если кто-то по ней настраивал или что-то нужно будет подсмотреть, можете скачать. Я не стал плодить похожие статьи с разными версиями ПО, так как это неудобно, приводит к дублированию информации на сайте и путанице. Удобнее, когда есть одна актуальная статья, на которую можно ссылаться.
Уместил в одну статью практически невмещаемое. Очень большой материал получился, по которому можно с нуля практически без базовых знаний о предметной области, настроить и запустить в работу почтовый сервер. Материал подаётся этапами с объяснениями на каждом, чтобы было понятнее.
Можно было бы сразу итоговый вариант настроек дать и всё разом запустить, но это было бы не так понятно. В целом, подобный сервер можно запустить в пару кликов на базе какого-нибудь Mailcow, Mailu, или их аналогов. Почти все сборки бесплатных серверов (и не только бесплатных) сделаны на базе этих же компонентов. Но если вы собираетесь потом эксплуатировать и администрировать этот сервер, то без знания его устройства это будет сложно сделать.
Так что если хотите изучить эту тему, то рекомендую действовать похожим образом, описанным в статье. Несмотря на то, что почту и локальные серверы для неё хоронят уже столько лет, актуальности она не потеряла и повсеместно используется. А как показал недавний опрос, локальных установок значительно больше, чем использование облачных сервисов. А подобных сборок так вообще треть. И этому есть вполне логичные объяснения. Я на днях ещё подниму эту тему.
Всем спасибо, кто пролайкал и прокомментировал мою прошлую заметку по этой теме. Любому автору приятно осознавать, что то, что он делает, кому-то нужно. Поэтому лично я всегда лайкаю и комментирую то, что вижу у других авторов. У многих нет финансовой мотивации что-то делать, потому что их сфера либо не монетизируется, либо они не умеют это делать, а сами работают в других местах. Но при этом всё равно что-то пишут, снимают, делают для других.
Например, сайт для меня в финансовом плане сейчас пассив. Но я вижу, что его каждый день до сих пор читает огромное количество людей. Они находят его полезным, хотя многие материалы сильно устарели, содержат ошибки. По мере сил и времени, стараюсь что-то обновлять и актуализировать. Эту статью писал в выходные, на буднях просто нет на это времени.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#mailserver #postfix #dovecot #статья
⇨ Настройка Postfix + Dovecot + Postfixadmin + Roundcube + DKIM на Debian
Она актуальна на сегодняшний день на базе Debian 13 и стандартных пакетов в её репозитории. Хотя для примера я некоторые компоненты скачивал из их репозиториев и устанавливал вручную, так как со временем в Debian версии начинают отставать от актуальных.
Старую версию статьи под Debian 12 сохранил в виде статической страницы и упаковал в архив. Ссылка в начале новой статьи. Если кто-то по ней настраивал или что-то нужно будет подсмотреть, можете скачать. Я не стал плодить похожие статьи с разными версиями ПО, так как это неудобно, приводит к дублированию информации на сайте и путанице. Удобнее, когда есть одна актуальная статья, на которую можно ссылаться.
Уместил в одну статью практически невмещаемое. Очень большой материал получился, по которому можно с нуля практически без базовых знаний о предметной области, настроить и запустить в работу почтовый сервер. Материал подаётся этапами с объяснениями на каждом, чтобы было понятнее.
Можно было бы сразу итоговый вариант настроек дать и всё разом запустить, но это было бы не так понятно. В целом, подобный сервер можно запустить в пару кликов на базе какого-нибудь Mailcow, Mailu, или их аналогов. Почти все сборки бесплатных серверов (и не только бесплатных) сделаны на базе этих же компонентов. Но если вы собираетесь потом эксплуатировать и администрировать этот сервер, то без знания его устройства это будет сложно сделать.
Так что если хотите изучить эту тему, то рекомендую действовать похожим образом, описанным в статье. Несмотря на то, что почту и локальные серверы для неё хоронят уже столько лет, актуальности она не потеряла и повсеместно используется. А как показал недавний опрос, локальных установок значительно больше, чем использование облачных сервисов. А подобных сборок так вообще треть. И этому есть вполне логичные объяснения. Я на днях ещё подниму эту тему.
Всем спасибо, кто пролайкал и прокомментировал мою прошлую заметку по этой теме. Любому автору приятно осознавать, что то, что он делает, кому-то нужно. Поэтому лично я всегда лайкаю и комментирую то, что вижу у других авторов. У многих нет финансовой мотивации что-то делать, потому что их сфера либо не монетизируется, либо они не умеют это делать, а сами работают в других местах. Но при этом всё равно что-то пишут, снимают, делают для других.
Например, сайт для меня в финансовом плане сейчас пассив. Но я вижу, что его каждый день до сих пор читает огромное количество людей. Они находят его полезным, хотя многие материалы сильно устарели, содержат ошибки. По мере сил и времени, стараюсь что-то обновлять и актуализировать. Эту статью писал в выходные, на буднях просто нет на это времени.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#mailserver #postfix #dovecot #статья
Please open Telegram to view this post
VIEW IN TELEGRAM
110👍398👎2
Решил обновить весь цикл статей про почтовый сервер. Начал с самой актуальной - настройка Fail2Ban для защиты от перебора учёток и прочих паразитных соединений:
⇨ Защита почтового сервера Postfix + Dovecot с помощью Fail2Ban
Инструкция получилась универсальная, потому что и для Postfix, и для Dovecot пришлось писать свой шаблон под формат текущих логов свежих версий. Так что материал будет актуален для любого сервиса с текстовыми логами.
В очередной раз хотел сходить по лёгкому пути и попросил ИИ написать шаблоны. ChatGPT не справился совершенно. Мучал его минут 15, пока не понял, что это бесполезно и проще разобраться самому. Он постоянно обещал теперь точно рабочую версию, но всё мимо. PerplexityPro тоже не помогла.
Я пока спокоен за своё будущее трудоустройство. Современные ИИшки никаким интеллектом не обладают и даже имея документацию и похожие примеры не могут родить новое уникальное решение, которое ещё нигде не подсмотрели. У них хорошо получается с bash, думал и с другими вещами так же будет, но нет.
Fail2Ban очень старое, простое и эффективное средство. За столько лет у него не появилось аналогов, кроме CrowdSec, но он сильно навороченнее и движется в сторону масштабного сервиса, а не простой утилиты для одиночного сервера. При этом Fail2Ban, несмотря на свою простоту и топорный подход анализа логов, работает нормально и эффективно там, где нет больших нагрузок. Я его повсеместно использую.
Помню как-то даже шутку придумал:
Это придумано в контексте того, что сам я лично для SSH никогда не ставлю Fail2Ban. В этом просто нет большого смысла.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#fail2ban #mailserver #postfix #dovecot
⇨ Защита почтового сервера Postfix + Dovecot с помощью Fail2Ban
Инструкция получилась универсальная, потому что и для Postfix, и для Dovecot пришлось писать свой шаблон под формат текущих логов свежих версий. Так что материал будет актуален для любого сервиса с текстовыми логами.
В очередной раз хотел сходить по лёгкому пути и попросил ИИ написать шаблоны. ChatGPT не справился совершенно. Мучал его минут 15, пока не понял, что это бесполезно и проще разобраться самому. Он постоянно обещал теперь точно рабочую версию, но всё мимо. PerplexityPro тоже не помогла.
Я пока спокоен за своё будущее трудоустройство. Современные ИИшки никаким интеллектом не обладают и даже имея документацию и похожие примеры не могут родить новое уникальное решение, которое ещё нигде не подсмотрели. У них хорошо получается с bash, думал и с другими вещами так же будет, но нет.
Fail2Ban очень старое, простое и эффективное средство. За столько лет у него не появилось аналогов, кроме CrowdSec, но он сильно навороченнее и движется в сторону масштабного сервиса, а не простой утилиты для одиночного сервера. При этом Fail2Ban, несмотря на свою простоту и топорный подход анализа логов, работает нормально и эффективно там, где нет больших нагрузок. Я его повсеместно использую.
Помню как-то даже шутку придумал:
«Если я усну и проснусь через сто лет и меня спросят, что сейчас настраивают системные администраторы Linux, я отвечу: блокировку SSH с помощью Fail2Ban».
Это придумано в контексте того, что сам я лично для SSH никогда не ставлю Fail2Ban. В этом просто нет большого смысла.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#fail2ban #mailserver #postfix #dovecot
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍115👎4
Пока в голове свежа тема почтового сервера, плюс тут в комментариях было много обсуждений по этой теме, выскажу некоторые свои мысли по поводу покупки почты как сервиса.
С точки зрения системного администратора, особенно того, кто не знаком с почтовыми серверами или по какой-то причине не любит их, проще и удобнее купить услугу как сервис и снять с себя все вопросы, связанные с настройкой и эксплуатацией. В целом, мне тоже нравится такой подход 😁. Если что-то упало или не работает, как надо, ты не при чём. Это всё сервис глючит.
На поверхности лежат основные минусы этого подхода:
➖ Можно потерять доступ к услуге или почте в целом по различным причинам, как техническим, так и юридическим. Забыли проплатить, вас забанили по ошибке, сервис упал или повысил стоимость и т.д.
➖ Могут быть неочевидны вопросы бэкапа и централизованного управления большой инфраструктурой. Последнее, кстати, актуально. Мне как-то довелось управлять большим количеством ящиков в Google Workspace. Они тогда вроде G-Suite назывались. Не было, к примеру, простой возможности всем добавить какое-то правило сортировки почты. Надо было либо инструкцию пользователям писать, либо в каждый ящик заходить. И таких моментов там много было.
➖ Чаще всего нет инструментов для анализа каких-то непонятных ситуаций. Пользователь может намудрить с правилами и письмо куда-то пропадает. Он жалуется, что почта не ходит. Поди разберись, в чём причина. Либо просто письмо не приходит, или он его сразу удалил. Ты тут можешь только развести руками.
➖ Нет возможности сделать какие-то гибкие настройки. Например, кому-то запретить заходить в ящик не из офиса. Запретить отправку на конкретные домены или наоборот разрешить переписываться только с определёнными доменами. Сделать централизованное автоудаление писем с какой-то конкретной темой. Я за свою работу много разных примеров видел, когда от почты хотелось немного больше, чем просто переписка.
❗️Это всё технические моменты. Но есть не менее важные и некоторые другие. Я не раз слышал такое мнение от руководителей и обеспеченных людей. Они не хотят светить свою переписку как личную, так и всей компании, в публичном сервисе, где она наверняка в обязательном порядке анализируется ИИ и подшивается к чему-то.
В итоге условный Яндекс или Мейл знает про тебя всё - где живёшь, сколько налогов платишь, какие накопления и инвестиции есть, где какие счета открыты, какая недвижимость, куда летаешь отдыхать и т.д. И по компании то же самое - вся твоя деятельность как на ладони: контрагенты, цены, условия, сотрудники, используемые сервисы и подписки и т.д. И всё это в режиме реального времени. Для кого-то это может быть несущественно, а какой-то бизнес может и пострадать из-за этого и даже не узнать об этом. Мы можем только предполагать, куда дальше утекают эти данные.
Если раньше до массового внедрения ИИ ещё были какие-то сложности с анализом всего этого, то теперь уже точно нет. И вот тебе продают услуги, назначают тарифы по цене x2 от той, которая могла бы быть, если бы о тебе ничего не знали. А может какие-то современные рейдеры в законе приходят с предложением, от которого невозможно отказаться.
☝️Так что вопрос это не такой простой, как может показаться на первый взгляд. И лежит не только в технической плоскости. Активная деловая переписка содержит много различной информации, причём уже в готовом виде. Это не СУБД по модели SaaS, где ещё ковыряться в данных надо. Возможно не стоит её вот так опрометчиво отдавать кому-то. Запустил свой сервер где угодно, настроил Thunderbird пользователям в офисе. И твоя переписка теперь только у тебя. Не такая уж большая переплата за это.
Понятно, что это вопрос не к техническим специалистам, и не им решать, где и как будет жить почта. Я не увидел вообще обсуждений в подобном ключе, поэтому решил лишний раз напомнить, что есть и такие нюансы.
#mailserver
С точки зрения системного администратора, особенно того, кто не знаком с почтовыми серверами или по какой-то причине не любит их, проще и удобнее купить услугу как сервис и снять с себя все вопросы, связанные с настройкой и эксплуатацией. В целом, мне тоже нравится такой подход 😁. Если что-то упало или не работает, как надо, ты не при чём. Это всё сервис глючит.
На поверхности лежат основные минусы этого подхода:
❗️Это всё технические моменты. Но есть не менее важные и некоторые другие. Я не раз слышал такое мнение от руководителей и обеспеченных людей. Они не хотят светить свою переписку как личную, так и всей компании, в публичном сервисе, где она наверняка в обязательном порядке анализируется ИИ и подшивается к чему-то.
В итоге условный Яндекс или Мейл знает про тебя всё - где живёшь, сколько налогов платишь, какие накопления и инвестиции есть, где какие счета открыты, какая недвижимость, куда летаешь отдыхать и т.д. И по компании то же самое - вся твоя деятельность как на ладони: контрагенты, цены, условия, сотрудники, используемые сервисы и подписки и т.д. И всё это в режиме реального времени. Для кого-то это может быть несущественно, а какой-то бизнес может и пострадать из-за этого и даже не узнать об этом. Мы можем только предполагать, куда дальше утекают эти данные.
Если раньше до массового внедрения ИИ ещё были какие-то сложности с анализом всего этого, то теперь уже точно нет. И вот тебе продают услуги, назначают тарифы по цене x2 от той, которая могла бы быть, если бы о тебе ничего не знали. А может какие-то современные рейдеры в законе приходят с предложением, от которого невозможно отказаться.
☝️Так что вопрос это не такой простой, как может показаться на первый взгляд. И лежит не только в технической плоскости. Активная деловая переписка содержит много различной информации, причём уже в готовом виде. Это не СУБД по модели SaaS, где ещё ковыряться в данных надо. Возможно не стоит её вот так опрометчиво отдавать кому-то. Запустил свой сервер где угодно, настроил Thunderbird пользователям в офисе. И твоя переписка теперь только у тебя. Не такая уж большая переплата за это.
Понятно, что это вопрос не к техническим специалистам, и не им решать, где и как будет жить почта. Я не увидел вообще обсуждений в подобном ключе, поэтому решил лишний раз напомнить, что есть и такие нюансы.
#mailserver
Please open Telegram to view this post
VIEW IN TELEGRAM
11👍132👎2
Пока работает полностью настроенный сервер с тестовым почтовым сервером, решил обновить все статьи, связанные с ним. Не знаю, насколько хватит терпения и времени, так как статью писать помуторнее, чем просто заметку. Для заметки достаточно быстро настроить, сделать пару скринов и своими словами потом описать проделанное. А для статьи надо полностью всю последовательность описать и заскринить, чтобы можно было повторить.
В этот раз занялся мониторингом:
⇨ Мониторинг Postfix в Zabbix
У меня очень давно опубликована и периодически обновлялась статья на эту тему. Там я сам из костылей и велосипедов собирал свой шаблон для почтового сервера и подробно всё расписывал, почему, зачем и как.
Времени поддерживать свои шаблоны в актуальном состоянии у меня нет, так что решил перейти на что-то более стабильное в плане поддержки. Взял шаблон из репозитория Zabbix с community-templates:
⇨ Template App Postfix by Zabbix Agent
Там в принципе есть всё, что нужно. Все многочисленные шаблоны и статьи для мониторинга Postfix похожи, потому что основа для метрик там почтовая очередь и лог-файл со статистикой. И все этот лог-файл разбирают с помощью pflogsumm. Это древнючий скрипт на Perl. Но так как Postfix бдит за обратной совместимостью и практически не меняет формат лог файла в части доставки писем, скрипты даже 20-ти летней давности работают до сих пор.
Представленный шаблон относительно свежий. Писался для версии 6.4. Я его без проблем адаптировал по свой почтовый сервер, который недавно обновлял. По сути только пути к бинарникам и лог-файлам нужно было поправить.
Описанный мониторинг будет актуален для всех решений на базе Postfix, где используется лог файл /var/log/mail.log и стандартная очередь в /var/spool/postfix. Пути, если что, можно будет поправить.
Альтернативное решение - Prometheus exporter for Postfix. У Grafana есть готовый дашборд для этого экспортера. А при желании какие-то метрики из него, или даже все, можно завести в Zabbix через встроенную предобработку метрик Prometheus.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#zabbix #postfix #mailserver
В этот раз занялся мониторингом:
⇨ Мониторинг Postfix в Zabbix
У меня очень давно опубликована и периодически обновлялась статья на эту тему. Там я сам из костылей и велосипедов собирал свой шаблон для почтового сервера и подробно всё расписывал, почему, зачем и как.
Времени поддерживать свои шаблоны в актуальном состоянии у меня нет, так что решил перейти на что-то более стабильное в плане поддержки. Взял шаблон из репозитория Zabbix с community-templates:
⇨ Template App Postfix by Zabbix Agent
Там в принципе есть всё, что нужно. Все многочисленные шаблоны и статьи для мониторинга Postfix похожи, потому что основа для метрик там почтовая очередь и лог-файл со статистикой. И все этот лог-файл разбирают с помощью pflogsumm. Это древнючий скрипт на Perl. Но так как Postfix бдит за обратной совместимостью и практически не меняет формат лог файла в части доставки писем, скрипты даже 20-ти летней давности работают до сих пор.
Представленный шаблон относительно свежий. Писался для версии 6.4. Я его без проблем адаптировал по свой почтовый сервер, который недавно обновлял. По сути только пути к бинарникам и лог-файлам нужно было поправить.
Описанный мониторинг будет актуален для всех решений на базе Postfix, где используется лог файл /var/log/mail.log и стандартная очередь в /var/spool/postfix. Пути, если что, можно будет поправить.
Альтернативное решение - Prometheus exporter for Postfix. У Grafana есть готовый дашборд для этого экспортера. А при желании какие-то метрики из него, или даже все, можно завести в Zabbix через встроенную предобработку метрик Prometheus.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#zabbix #postfix #mailserver
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍79👎2
Решил по максимуму наполнить тему почтового сервера. На очереди сбор и обработка логов в ELK, но для этого надо сначала с этим стеком обновить статью.
А пока более простой материал на тему автоматической загрузки больших вложений в свой Nextcloud для отправки получателям не самого файла, а ссылки на него:
⇨ Автоматическая загрузка почтовых вложений в Nextcloud при отправке через RoundCube и Thunderbird
Подобная связка удобна для пользователя, так как всё автоматизировано. Он в клиенте прикрепляет файл, который автоматом улетает в Nextcloud, а в письмо вставляется ссылка для загрузки.
Отдельный вопрос стоит с аутентификацией в Nextcloud, если нет общей SSO для почты и остальных сервисов. Но даже если и нет, то можно один раз настроить пользователю доступ, чтобы он потом этим пользовался.
Про плагин к RoundCube у меня уже была ранее заметка, а про Thunderbird даже не упоминал. Настройки простые, если уже есть Nextcloud. Стоит ли его поднимать только для почты - не знаю. По месту надо решать, если в принципе потребность - регулярно обмениваться файлами.
У меня на одном из серверов есть ящики по 100-150 гигабайт. Хлопотно обслуживать такой почтовый архив. Было бы проще, если бы подобная функциональность была внедрена на этапе запуска сервера.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#mailserver #nextcloud
А пока более простой материал на тему автоматической загрузки больших вложений в свой Nextcloud для отправки получателям не самого файла, а ссылки на него:
⇨ Автоматическая загрузка почтовых вложений в Nextcloud при отправке через RoundCube и Thunderbird
Подобная связка удобна для пользователя, так как всё автоматизировано. Он в клиенте прикрепляет файл, который автоматом улетает в Nextcloud, а в письмо вставляется ссылка для загрузки.
Отдельный вопрос стоит с аутентификацией в Nextcloud, если нет общей SSO для почты и остальных сервисов. Но даже если и нет, то можно один раз настроить пользователю доступ, чтобы он потом этим пользовался.
Про плагин к RoundCube у меня уже была ранее заметка, а про Thunderbird даже не упоминал. Настройки простые, если уже есть Nextcloud. Стоит ли его поднимать только для почты - не знаю. По месту надо решать, если в принципе потребность - регулярно обмениваться файлами.
У меня на одном из серверов есть ящики по 100-150 гигабайт. Хлопотно обслуживать такой почтовый архив. Было бы проще, если бы подобная функциональность была внедрена на этапе запуска сервера.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#mailserver #nextcloud
Please open Telegram to view this post
VIEW IN TELEGRAM
👍66👎2
По какой-то причине практически отсутствует как класс программное обеспечение для архивирования почты и последующей работы с архивами. По крайней мере мне ничего такого на ум не приходит, кроме некоторых небольших проектов. Про один из них я недавно писал - Mail-Archiver.
Сегодня рассмотрю другое бесплатное ПО по этой же теме - Open Archiver. По сравнению с Mail-Archiver он выглядит более функциональным и технологичным. Внешне тоже больше понравился. Но сразу скажу, что проект не очень зрелый, появился недавно. Есть некоторые баги, скупая документация. Я немного повозился, прежде чем развернул его. Но в итоге всё получилось.
📌 Возможности и особенности Open Archiver:
▪️Сбор почты по IMAP, в том числе с Google Workspace и Microsoft 365, импорт из PST и Mbox файлов.
▪️Почта хранится в виде .eml файлов с зашифрованным содержимым.
▪️Для хранения может использоваться локальная директория или S3 хранилище.
▪️Развитый поиск по телу письма и вложениям, в том числе с распознаванием PDF, DOCX, XLSX, архивов и др., в том числе картинок. В бэкенде распознавания там Apache Tika, а поисковой движок Meilisearch. Сразу скажу, что поиск работает хорошо и быстро. По крайней мере на моих тестах.
▪️Проверка и сравнение хэшей писем и вложений на оригинальном сервере и архиве.
▪️RBAC модель доступа пользователей, то есть можно создавать роли с разными правами и назначать пользователям. Кто-то может только читать, кто-то и удалять, кто-то добавлять новые ящики и т.д. Можно глобально запретить любое удаление писем или ящиков из Open Archiver.
▪️Все действия с системой можно выполнять через API.
Я недавно раздумывал над задачей, как разгрузить хранилище большого почтового сервера, где куча ящиков уволенных людей. Всё это занимает много места, не особо надо, но удалить нельзя. Вдруг ещё понадобится. Причём это не домыслы. Иногда реально старая почта нужна. Как-то раз я помогал найти письма давно уволившегося сотрудника для заверения у нотариуса, так как начались судебные разбирательства по одному старому делу.
Весь этот объём постоянно тянется от основного хранилища по цепочке бэкапов и занимает место. У меня была идея сделать отдельный почтовый сервер для таких ящиков, переносить их туда и там с ними работать. Навскидку Open Archiver выглядит удобнее для этой задачи. Думаю, что буду пробовать его в этой роли.
Установить Open Archiver нетрудно, так как он упакован в Docker контейнеры, но есть нюансы, которые я не сразу узнал. Рассказываю, как быстро установить.
Клонируем репозиторий:
Правим переменные окружения:
В файле
Ключевыми являются параметры ORIGIN и ENCRYPTION_KEY. По умолчанию ORIGIN=$APP_URL, а надо явно прописать. Если не указать ENCRYPTION_KEY, то после установки не запустится начальная настройка, невозможно будет создать администратора. При этом по умолчанию ENCRYPTION_KEY не задан, просто пустое значение. Если не указать STORAGE_ENCRYPTION_KEY, то хранилище писем не будет шифроваться. По умолчанию ENABLE_DELETION=false. Невозможно будет удалить добавленные ящики. Я не сразу понял, почему они не удаляются, потом разобрался. JWT_SECRET и MEILI_MASTER_KEY можно оставить по умолчанию на тестовой установке. На работу они не влияют.
После того, как заполните .env, запускаем:
Я сначала в консольном режиме запускаю, чтобы смотреть логи. Некоторые проблемы увидел как раз по логу. Потом можно запустить в режиме службы.
В целом, у меня всё получилось. Добавил 3 ящика, один старый от mail ru. Всё заработало. Синхронизация работает значительно быстрее, чем в Mail-Archiver.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#mailserver #backup
Сегодня рассмотрю другое бесплатное ПО по этой же теме - Open Archiver. По сравнению с Mail-Archiver он выглядит более функциональным и технологичным. Внешне тоже больше понравился. Но сразу скажу, что проект не очень зрелый, появился недавно. Есть некоторые баги, скупая документация. Я немного повозился, прежде чем развернул его. Но в итоге всё получилось.
▪️Сбор почты по IMAP, в том числе с Google Workspace и Microsoft 365, импорт из PST и Mbox файлов.
▪️Почта хранится в виде .eml файлов с зашифрованным содержимым.
▪️Для хранения может использоваться локальная директория или S3 хранилище.
▪️Развитый поиск по телу письма и вложениям, в том числе с распознаванием PDF, DOCX, XLSX, архивов и др., в том числе картинок. В бэкенде распознавания там Apache Tika, а поисковой движок Meilisearch. Сразу скажу, что поиск работает хорошо и быстро. По крайней мере на моих тестах.
▪️Проверка и сравнение хэшей писем и вложений на оригинальном сервере и архиве.
▪️RBAC модель доступа пользователей, то есть можно создавать роли с разными правами и назначать пользователям. Кто-то может только читать, кто-то и удалять, кто-то добавлять новые ящики и т.д. Можно глобально запретить любое удаление писем или ящиков из Open Archiver.
▪️Все действия с системой можно выполнять через API.
Я недавно раздумывал над задачей, как разгрузить хранилище большого почтового сервера, где куча ящиков уволенных людей. Всё это занимает много места, не особо надо, но удалить нельзя. Вдруг ещё понадобится. Причём это не домыслы. Иногда реально старая почта нужна. Как-то раз я помогал найти письма давно уволившегося сотрудника для заверения у нотариуса, так как начались судебные разбирательства по одному старому делу.
Весь этот объём постоянно тянется от основного хранилища по цепочке бэкапов и занимает место. У меня была идея сделать отдельный почтовый сервер для таких ящиков, переносить их туда и там с ними работать. Навскидку Open Archiver выглядит удобнее для этой задачи. Думаю, что буду пробовать его в этой роли.
Установить Open Archiver нетрудно, так как он упакован в Docker контейнеры, но есть нюансы, которые я не сразу узнал. Рассказываю, как быстро установить.
Клонируем репозиторий:
# git clone https://github.com/LogicLabs-OU/OpenArchiver.git# cd OpenArchiverПравим переменные окружения:
# cp .env.example .envВ файле
.env нужно обязательно указать несколько параметров, для запуска на IP адресе, а не реальном домене:APP_URL=http://192.168.137.38:3000ORIGIN=http://192.168.137.38:3000ENCRYPTION_KEY=952e40feca16JWT_SECRET=9VRzbD56aYpFSTORAGE_ENCRYPTION_KEY=50348f31f0281MEILI_MASTER_KEY=abk3pAhzgk6NENABLE_DELETION=trueКлючевыми являются параметры ORIGIN и ENCRYPTION_KEY. По умолчанию ORIGIN=$APP_URL, а надо явно прописать. Если не указать ENCRYPTION_KEY, то после установки не запустится начальная настройка, невозможно будет создать администратора. При этом по умолчанию ENCRYPTION_KEY не задан, просто пустое значение. Если не указать STORAGE_ENCRYPTION_KEY, то хранилище писем не будет шифроваться. По умолчанию ENABLE_DELETION=false. Невозможно будет удалить добавленные ящики. Я не сразу понял, почему они не удаляются, потом разобрался. JWT_SECRET и MEILI_MASTER_KEY можно оставить по умолчанию на тестовой установке. На работу они не влияют.
После того, как заполните .env, запускаем:
# docker compose upЯ сначала в консольном режиме запускаю, чтобы смотреть логи. Некоторые проблемы увидел как раз по логу. Потом можно запустить в режиме службы.
В целом, у меня всё получилось. Добавил 3 ящика, один старый от mail ru. Всё заработало. Синхронизация работает значительно быстрее, чем в Mail-Archiver.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#mailserver #backup
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍113👎3
Написал очередную статью из цикла про настройку своего почтового сервера:
⇨ Roundcube Fetchmail plugin - сбор почты с других почтовых ящиков
Я в ней настраиваю плагин для веб клиента Roundcube, с помощью которого можно собирать в свой ящик почту с других внешних серверов. И настроить этот сбор может каждый пользователь самостоятельно в своём аккаунте. Работает всё это на базе известного и популярного решения Fetchmail.
В настоящий момент цикл моих статей про почтовый сервер выглядит следующим образом:
▪️Настройка сервера на базе ОС Debian
▪️Защита от перебора учётных данных с помощью Fail2Ban
▪️Мониторинг Postfix в Zabbix
▪️Автоматическая загрузка почтовых вложений в Nextcloud при отправке через RoundCube и Thunderbird
▪️Roundcube Fetchmail plugin - сбор почты с других почтовых ящиков
Это свежие статьи, обновлённые в течении последних двух месяцев. Есть более старый, но актуальный материал:
◽️Выбор сервера для отправки в зависимости от получателя
◽️Настройка маршрута отправки в зависимости от домена
◽️Ограничение на отправку писем в единицу времени
◽️Перенос почтового сервера
◽️Как изменить тему письма и адрес отправителя через Postfix
◽️Удаление из писем заголовков с локальными IP адресами
◽️Защита почтовых алиасов с множеством получателей от спама
◽️Очистка и обслуживание почтовой базы Postfix
❓Как думаете, какой ещё темы не хватает в контексте своего почтового сервера? По идее не хватает бэкапа, но я почтовую базу формата maildir бэкаплю обычным rsync, про который было много заметок и добавить нечего. Подумываю написать ещё про сбор и анализ логов. Больше ничего в голову не приходит. По идее, всё наиболее актуальное я описал.
Не хватает материала по аутентификации через LDAP, но лично я всегда для почтового сервера использую отдельную базу данных учётных записей. Почтовые сервера всегда открыты для всего интернета, клиенты настроены на различных устройствах пользователей. Учётные данные нередко утекают. Мне не нравится идея объединять их с другими сервисами. Конкретно для почты я считаю, лучше использовать отдельную базу данных с учётными записями, хотя это и не совсем удобно. Для больших масштабов, наверное, не подойдёт, но для малых и средних компаний вполне.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#mailserver #postfix #подборка
⇨ Roundcube Fetchmail plugin - сбор почты с других почтовых ящиков
Я в ней настраиваю плагин для веб клиента Roundcube, с помощью которого можно собирать в свой ящик почту с других внешних серверов. И настроить этот сбор может каждый пользователь самостоятельно в своём аккаунте. Работает всё это на базе известного и популярного решения Fetchmail.
В настоящий момент цикл моих статей про почтовый сервер выглядит следующим образом:
▪️Настройка сервера на базе ОС Debian
▪️Защита от перебора учётных данных с помощью Fail2Ban
▪️Мониторинг Postfix в Zabbix
▪️Автоматическая загрузка почтовых вложений в Nextcloud при отправке через RoundCube и Thunderbird
▪️Roundcube Fetchmail plugin - сбор почты с других почтовых ящиков
Это свежие статьи, обновлённые в течении последних двух месяцев. Есть более старый, но актуальный материал:
◽️Выбор сервера для отправки в зависимости от получателя
◽️Настройка маршрута отправки в зависимости от домена
◽️Ограничение на отправку писем в единицу времени
◽️Перенос почтового сервера
◽️Как изменить тему письма и адрес отправителя через Postfix
◽️Удаление из писем заголовков с локальными IP адресами
◽️Защита почтовых алиасов с множеством получателей от спама
◽️Очистка и обслуживание почтовой базы Postfix
❓Как думаете, какой ещё темы не хватает в контексте своего почтового сервера? По идее не хватает бэкапа, но я почтовую базу формата maildir бэкаплю обычным rsync, про который было много заметок и добавить нечего. Подумываю написать ещё про сбор и анализ логов. Больше ничего в голову не приходит. По идее, всё наиболее актуальное я описал.
Не хватает материала по аутентификации через LDAP, но лично я всегда для почтового сервера использую отдельную базу данных учётных записей. Почтовые сервера всегда открыты для всего интернета, клиенты настроены на различных устройствах пользователей. Учётные данные нередко утекают. Мне не нравится идея объединять их с другими сервисами. Конкретно для почты я считаю, лучше использовать отдельную базу данных с учётными записями, хотя это и не совсем удобно. Для больших масштабов, наверное, не подойдёт, но для малых и средних компаний вполне.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#mailserver #postfix #подборка
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍87👎2
В своих заметках и статьях про почтовый сервер я ни разу не касался темы резервного сервера, который в рамках возможностей DNS записей вида MX реализуется очень просто. Для каждого домена могут быть указаны несколько почтовых серверов, используя разные приоритеты. Например:
Нашёл случайный пример. Для домена прописаны 2 сервера с разными приоритетами: 20 и 30. У кого приоритет меньше - туда по умолчанию отправляется письмо. Если первый сервер из списка недоступен, письмо отправляется на следующий в списке приоритетов сервер.
На практике я не знаю, насколько активно сейчас это применяется. Я проверил с десяток популярных доменов и только у 1С нашёл 2 сервера. В основном у всех один, либо несколько но с одинаковыми приоритетами для распределения нагрузки. Думаю, я знаю, в чём причина.
Когда я только начинал настраивать почтовые сервера, делал резервные сервера и MX записи к ним. На практике это приводило к серьёзным заботам и хлопотам:
1️⃣ По хорошему, вам нужно синхронизировать информацию о ящиках и пользователям между двумя серверами. Можно этого не делать и собирать всю почту в один ящик-ловушку для всех писем домена, но потом придётся каким-то образом раскладывать её по пользователям.
2️⃣ В случае, если ваш основной сервер по каким-то причинам был недоступен и письма попали на резервный, вам придётся потом каким-то образом вернуть эти письма на основной в ящики пользователей. Решения для этого есть - тот же fetchmail. Он может на основании адреса получателя раскладывать письма по пользователям. Но всё это надо поддерживать в актуальном состоянии, следить, что нормально работает. На практике это не так то просто реализовать, если это не какое-то готовое решение.
3️⃣ На резервный MX сервер спамеры могут слать спам вопреки более высокому приоритету основного сервера. Это отдельные хлопоты по администрированию.
Надо ещё понимать особенность обмена письмами по SMTP. Стандартной настройкой почтовых серверов является многократные попытки доставить почту. Если у вас упал почтовый сервер, то отправитель, не доставив с первого раза письмо, будет пытаться доставить его ещё какое-то время. Причём существенное время, если администратор сервера отправителя для каких-то целей сильно не урезал время нахождения недоставленного письма в очереди. Обычно письма в очереди на отправку с периодическими попытками доставить находятся день-два, могут и больше.
При таких вводных получается, что даже если ваш почтовый сервер недоступен час-два, с большой долей вероятности вы не потеряете переписку. Все письма упадут в почтовые ящики пользователей, когда сервер вернётся в онлайн. И вам не придётся потом разбираться с синхронизацией почтовых ящиков между двумя серверами.
Собственно, я поэтому и перестал держать резервные сервера, когда один раз столкнулся с такой ситуацией. За пару часов на резервный сервер нападало писем, которые потом нужно было возвращать на основной. Вроде бы и хорошо, что ничего не потерял, но на деле я бы скорее всего и так ничего бы не потерял. Тем более если это рядовой сервер с перепиской пользователей. Обычно потеря письма некритична. Бывает, что письма не доходят. Если письмо не дошло до адресата из-за недоступности сервера, отправитель получит об этом уведомление.
Крупные же компании, где к почте предъявляются высокие требования по доступности, насколько я понимаю, предпочитают настраивать отказоустойчивые кластера основного сервера, а не выстраивать инфраструктуру с основным и резервными, так как это приводит к описанным выше хлопотам. Либо же это должно быть готовое программное обеспечение, которое автоматически реализует такую схему работы. Мне таковое неизвестно.
❗️Написанное выше исключительно моё мнение и опыт. Не претендую на правоту и истину. Если кто-то поделится своим опытом настройки основного и резервного MX серверов, с удовольствием прочитаю и приму к сведению.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#mailserver
# dig 1c.ru MX +short20 relay.1c.ru.30 mx1-ksmg.1c.ru.Нашёл случайный пример. Для домена прописаны 2 сервера с разными приоритетами: 20 и 30. У кого приоритет меньше - туда по умолчанию отправляется письмо. Если первый сервер из списка недоступен, письмо отправляется на следующий в списке приоритетов сервер.
На практике я не знаю, насколько активно сейчас это применяется. Я проверил с десяток популярных доменов и только у 1С нашёл 2 сервера. В основном у всех один, либо несколько но с одинаковыми приоритетами для распределения нагрузки. Думаю, я знаю, в чём причина.
Когда я только начинал настраивать почтовые сервера, делал резервные сервера и MX записи к ним. На практике это приводило к серьёзным заботам и хлопотам:
Надо ещё понимать особенность обмена письмами по SMTP. Стандартной настройкой почтовых серверов является многократные попытки доставить почту. Если у вас упал почтовый сервер, то отправитель, не доставив с первого раза письмо, будет пытаться доставить его ещё какое-то время. Причём существенное время, если администратор сервера отправителя для каких-то целей сильно не урезал время нахождения недоставленного письма в очереди. Обычно письма в очереди на отправку с периодическими попытками доставить находятся день-два, могут и больше.
При таких вводных получается, что даже если ваш почтовый сервер недоступен час-два, с большой долей вероятности вы не потеряете переписку. Все письма упадут в почтовые ящики пользователей, когда сервер вернётся в онлайн. И вам не придётся потом разбираться с синхронизацией почтовых ящиков между двумя серверами.
Собственно, я поэтому и перестал держать резервные сервера, когда один раз столкнулся с такой ситуацией. За пару часов на резервный сервер нападало писем, которые потом нужно было возвращать на основной. Вроде бы и хорошо, что ничего не потерял, но на деле я бы скорее всего и так ничего бы не потерял. Тем более если это рядовой сервер с перепиской пользователей. Обычно потеря письма некритична. Бывает, что письма не доходят. Если письмо не дошло до адресата из-за недоступности сервера, отправитель получит об этом уведомление.
Крупные же компании, где к почте предъявляются высокие требования по доступности, насколько я понимаю, предпочитают настраивать отказоустойчивые кластера основного сервера, а не выстраивать инфраструктуру с основным и резервными, так как это приводит к описанным выше хлопотам. Либо же это должно быть готовое программное обеспечение, которое автоматически реализует такую схему работы. Мне таковое неизвестно.
❗️Написанное выше исключительно моё мнение и опыт. Не претендую на правоту и истину. Если кто-то поделится своим опытом настройки основного и резервного MX серверов, с удовольствием прочитаю и приму к сведению.
———
ServerAdmin:
#mailserver
Please open Telegram to view this post
VIEW IN TELEGRAM
👍83👎1
Продолжу одновременно две темы, которые развиваю последнее время - почтовый сервер на базе Postfix и сбор логов в Loki. Покажу, как очень просто и быстро собирать логи Postfix в Loki с базовым анализом содержимого и простенькой визуализацией в дашборде.
Напомню, что у меня есть подробная статья про мониторинг Postfix с помощью Zabbix. Там в том числе выполняется и анализ логов, но локально, а в систему мониторинга уходит результат локальной обработки. Сами логи Postfix не хранятся.
Сегодня я рассмотрю другой вариант - непосредственно хранение логов на внешнем сервере Loki, который сам будет парсить данные и выполнять некоторую аналитику. Я выведу на дашборд метрики:
◽️Количество доставленных и отклонённых писем в виде соотношения и временной шкалы
◽️Статистика по доменам внешних получателей писем от нас
◽️Статистика по полученным письмам локальных доменов нашего сервера
◽️Статистика по отклонённым письмам в разрезе ошибок и доменов
Помимо этого Loki автоматически будет парсить поступающие логи, что позволит выполнять группировки по 24 распознанным полям: имя получателя, имя отправителя, домен отправителя, IP адрес, ID сообщения, статусы и т.д.
Данную заметку я пишу на примере реального почтового сервера, который я настроил по этой своей статье. Это важно, так как в разных версиях Postfix немного отличается формат логов. Я за основу взял готовый Dashboard из базы Grafana и подправил его под свою версию сервера и настроек Alloy, которые я возьму из этой заметки. А сам Loki установлен и настроен так же, как тут.
Первым делом устанавливаем Alloy на почтовый сервер с Postfix. Посмотреть установку можно в предыдущей заметке. Для сбора только почтовых логов достаточно такой конфигурации:
После этого логи сразу потекут в Loki. Их можно смотреть в разделе Drilldown ⇨ Logs. В качестве service_name в соответствии с настройками Ally будет указано имя сервера и приписка
Далее нам нужно импортировать дашборд. Я положил его в свой репозиторий grafana-loki, в раздел
Если у вас Loki и Postfix настроены по моим статьям и заметкам, на которые я дал ссылки, то всё должно получиться, потому что все настройки я взял с работающего сервера. Проверил в момент написания заметки. Как это всё выглядит, видно ниже на скриншотах.
Если что-то не работает на дашборде, значит либо лог немного отличается, там локальный парсер прямо в настройках виджетов, либо выборка по меткам не совпадает, если свои метки ставили. Всё это проверяется тут же, в дашборде, в настройках виджетов. Я так всё и правил в изначальном дашборде. У меня после импорта ничего не работало. Поправил и шаблоны парсинга, и метки под свои настройки, добавил ещё один виджет, разделив внешних и внутренних получателей. В итоге всё получилось.
Ниже публикую файлы, которые используются в заметке. Они же продублированы в репозитории.
Подобная настройка максимально простая и быстрая, настраивается буквально за 5 минут по готовым конфигам и шаблонам. Плюс, это всё в формате IaC.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#loki #logs #mailserver #postfix
Напомню, что у меня есть подробная статья про мониторинг Postfix с помощью Zabbix. Там в том числе выполняется и анализ логов, но локально, а в систему мониторинга уходит результат локальной обработки. Сами логи Postfix не хранятся.
Сегодня я рассмотрю другой вариант - непосредственно хранение логов на внешнем сервере Loki, который сам будет парсить данные и выполнять некоторую аналитику. Я выведу на дашборд метрики:
◽️Количество доставленных и отклонённых писем в виде соотношения и временной шкалы
◽️Статистика по доменам внешних получателей писем от нас
◽️Статистика по полученным письмам локальных доменов нашего сервера
◽️Статистика по отклонённым письмам в разрезе ошибок и доменов
Помимо этого Loki автоматически будет парсить поступающие логи, что позволит выполнять группировки по 24 распознанным полям: имя получателя, имя отправителя, домен отправителя, IP адрес, ID сообщения, статусы и т.д.
Данную заметку я пишу на примере реального почтового сервера, который я настроил по этой своей статье. Это важно, так как в разных версиях Postfix немного отличается формат логов. Я за основу взял готовый Dashboard из базы Grafana и подправил его под свою версию сервера и настроек Alloy, которые я возьму из этой заметки. А сам Loki установлен и настроен так же, как тут.
Первым делом устанавливаем Alloy на почтовый сервер с Postfix. Посмотреть установку можно в предыдущей заметке. Для сбора только почтовых логов достаточно такой конфигурации:
loki.write "default" {
endpoint {
url = "http://195.20.47.169:3100/loki/api/v1/push"
}
external_labels = {}
}
local.file_match "postfix" {
path_targets = [{
__address__ = "localhost",
__path__ = "/var/log/mail.log",
instance = constants.hostname,
job = string.format("%s-maillog", constants.hostname),
}]
}
loki.source.file "postfix" {
targets = local.file_match.postfix.targets
forward_to = [loki.write.default.receiver]
}После этого логи сразу потекут в Loki. Их можно смотреть в разделе Drilldown ⇨ Logs. В качестве service_name в соответствии с настройками Ally будет указано имя сервера и приписка
-maillog. В моём случай это будет mail.zeroxzed.ru-maillog. На картинках другое название, но это мне показалось более удачное.Далее нам нужно импортировать дашборд. Я положил его в свой репозиторий grafana-loki, в раздел
grafana/dashboards/, файл Postfix Delivery Status.json. Его нужно скачать и импортировать в Grafana. Во время импорта в качестве источника данных укажите свой Datasource с Loki. Если он не подцепится автоматически, то после импорта зайдите в настройки дашборда, раздел Variables, укажите его явно в переменной DS_LOKI.Если у вас Loki и Postfix настроены по моим статьям и заметкам, на которые я дал ссылки, то всё должно получиться, потому что все настройки я взял с работающего сервера. Проверил в момент написания заметки. Как это всё выглядит, видно ниже на скриншотах.
Если что-то не работает на дашборде, значит либо лог немного отличается, там локальный парсер прямо в настройках виджетов, либо выборка по меткам не совпадает, если свои метки ставили. Всё это проверяется тут же, в дашборде, в настройках виджетов. Я так всё и правил в изначальном дашборде. У меня после импорта ничего не работало. Поправил и шаблоны парсинга, и метки под свои настройки, добавил ещё один виджет, разделив внешних и внутренних получателей. В итоге всё получилось.
Ниже публикую файлы, которые используются в заметке. Они же продублированы в репозитории.
Подобная настройка максимально простая и быстрая, настраивается буквально за 5 минут по готовым конфигам и шаблонам. Плюс, это всё в формате IaC.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#loki #logs #mailserver #postfix
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍66👎1