Спустя семь лет после формирования версии 2.3.0 представлена новая ветка многоплатформенного IMAP-сервера Dovecot 2.4.0, поддерживающего протоколы POP3 и IMAP4rev1 с популярными расширениями, такими как SORT, THREAD, MULTIAPPEND, QUOTA, ACL, COMPRESS, NOTIFY, METADATA и IDLE, и механизмами аутентификации и шифрования (SASL, TLS, SCRAM, XOAUTH2). Dovecot сохраняет полную совместимость с классическими mbox и Maildir, применяя внешние индексы для повышения производительности. Для расширения функциональности могут использоваться плагины, через которые реализованы такие возможности, как квоты, ACL, Push-уведомления, полнотекстовый поиск и виртуальные почтовые ящики. Код проекта распространяется под лицензиями LGPL и MIT...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62611
> SASL-алгоритмов SCRAM-SHA-1 и SCRAM-SHA-256Ээээ я когда был студентом и писал свой почтовый сервер (2003-4 годы) уже тогда реализовал SCRAM-SHA-1.
и где Ваш почтовый сервер?
Сдан и, возможно, даже на "5".
проще говоря, никому не нужен
Я тогда писал под венду. Начинал ещё под 98 а заканчивал уже на ХР.
Он у меня был намного производительнее тогдашних серверов под венду которые были в обиходе у SOHO, но гуя фактически не было.В общем сервер пал жертвой козней МС, как на мой взгляд :)
И заодно как не совсем удачно спроектированный учебный проект :)У меня тогда были книжки от МС пресс про то как писать серверные приложения под венду.
Там было описание как типа правильно делать своё сервероное приложение на базе CopletionIO Port, там пул потоков.Только вот было две засады:
1. там был общий пул потоков, и это означало что события завершения чтения и записи на сокете могли обработать одновременно разные потоки и надо было как то синхронизировать доступ. Те оба могли получить сигнал что сокет закрыт и кто то из ниг мог грохнуть контекст первым а второй делал даблфри или юз афтер фри.
Этого книжка не освещала.2. Там был описан динамический пул потоков, те потоки могли и создаватся и завершатся по мере необходимости. С созданием проблем не было. А для завершения в книжке было написано что нужно самом реализовать функцию HasThreadIOPending() которая возвращала bool и значение зависело от того есть ли поставленные потоком задачи в порте завершения в/в. Потом что если есть то такие задачи были бы отменены и их надо было ставить по новой.
В общем такую функцию с юзерспейса было реализовать трудно, а в API её не было.
Но как потом я узнал через пару лет - МС эту функцию реализовала, просто никому об этом не сказало, как они делали ещё с некоторым функциями которые исследовали накапывали в ручную.В общем я считаю это было подставой со стороны МС чтобы пустить возможных конкурентов дорогой очень трудной.
Попутно могу ещё упомянуть что там были описаны всякие клёвые вещи типа счётчиков производительности и прочего WMI которыми типа и надо общатся с такими сервисами.
Вот только реализовать их достаточно сложно и вообще такое мало кто юзал в те годы, да и сейчас кажется всем этим пользуются только продукты МС.
В общем это был большой проект на котором я многому научился.
Если бы это было изначально под линукс может оно бы и жило где то сейчас в опенсорце.
А вендовые почтовые сервера кажется давно отмёрли, кроме эксчейнджа.
ТЛ;ДР. Никому не нужен.
Если бы отмёрли... Наши мышевозники всё ещё IceWarp долбят.
Ну да, я нашёл как его сдать в виде курсовой :)
Но честно говоря там можно было сдать и не свой почтовый сервер, препод бы всё равно ничего не заметил. )
Валяется где то в архиве на диске :)
А JMAP похоже так и не завезли?
А в каком почтовом клиенте для десктопа есть поддержка JMAP?
для начала, в каком провайдере...
fastmail
7 лет.Минимум
Он жыв? В смысле, внедряется где-нибудь?
Имхо, это один из самых популярных имап-серверов. Наряду с exim.
ты всё перепутал.разговор в этой ветке не про сабж как таковой, а про JMAP
а exim и вовсе не IMAP-сервер.
https://dovecot.org/mailman3/hyperkitty/list/dovecot@do.../ответ от разработчика 4 года назад. С тех пор ничего не изменилось, очевидно
Оно не взлетело. Бывает.
Короче полностью переписывать конфиги под новую версию.
Как он в сравнении с cyrus?
По сравнению с cyrus, subj не умел в дедупликацию рассылок, НЯП.
Зато есть масса плагинов на разные случаи и хорошее покрытие документацией (из-за чего "голубятня" — достаточно популярный выбор для почтового бэкэнда).
Бл#!
А какая-нибудь утилита для миграции или режим совместимости есть? Как-то переписывать все конфиги с нуля ручками неохота.В общем-то, хватило бы и сообщений в логах вида "Переменная X (строка 100500 конфига ABC) отныне не поддерживается, используйте переменную Y"
В наличии пачка серваков с довекотом. Да, дебиан, так что, возможно, там на новую версию переползут только когда я на пенсию уйду, а если раньше?
> а если раньше?а если раньше, то на пенсию придется еще подзаработать. Вот этими самыми ручками.
А то у безработных пенсия - так себе.
А в чем проблема это сделать постепенно?Напиши скрипт, используй в нем sed, прогони его на тестовом сервере. Если все ок, примени его на остальных серверах
> А в чем проблемаПроблема в том, что он в глаза не видел этих конфигов :)
Почти угадал :)))
Конфиги писал я, с нуля, осознанно, читая документацию и best practice к каждому параметру. Вот только было это лет несколько назад.Так что, да, можно считать, что я этих конфигов не видел, я тупо не помню - что там :)))
А, так как кроме почтовых серверов у меня ещё до хрена другой машинерии, то крайне не хотелось бы тратить своё время на актуализацию конфигов с учётом нового синтаксиса, названий параметров и прочая, и прочая...
> Конфиги писал я, с нуляВот писать то там нууууу совсем ничего не надо :), если только подкрутить некоторые параметры и дописать настройки подключения к базе.
>Напиши скрипт, используй в нем sedAnsible в помощь.
Аж чаем поперхнулся... не надо так.
> Как-то переписывать все конфиги с нуля ручками неохотаКакие-то локалхостные проблемы. В больших системах «ручками» конфиги не пишут, а для 3,5 локалхостов переписать не проблема.
И, конечно же, новые шаблоны конфигов возникнут по щелчку моих пальцев...Мдя, чего-то я забыл об этой возможности, погорячился, был не прав.
Джуну поручи, пусть внимательность тренирует.
Дружно ждем этих, как его... ебилдов, вот!
Есть вот такая страничкаhttps://doc.dovecot.org/main/installation/upgrade/2.3-to-2.4...
читать её прямо глаза вытекают. Похоже, автор интересно пошел: ему бы сделать ветку dovecot-24 в репах, и ставить 2.4 с нуля (или параллельно старому) если уж так хочется поломать конфиги (и из-за чего, чтобы переменные переименовать? сделали бы одновременную поддержку и старых, и новых, вроде это логически не проблема)!
Я тоже не понял это прикола так сильно покромсать формат конфигурации который 20 лет держался.
Полагаю, что 2.3 они еще какое-то время будут тащить по инерции, так что запас времени на переезд пока имеется
А есть хорошие книги по dovecot / postfix, где будут разжёвано и подробные схемы движения письма(в постфикс), и что за чем применяется. Единственную внятную схему работы что я видел - от iptables, а у того же постфикса - максимум схема с сервисами, но на такой схеме нет внутренней обработки, потому долго сидишь и ловишь в какой части письмо не пролазит, или наоборот, пролетает.
> А есть хорошие книгиА чем вам документация не угодила? все подробно расписано
> потому долго сидишь и ловишь в какой части письмо не пролазит, или наоборот, пролетает.
в логи смотрите, там показывает ошибки связанные со всеми процессами.
Тем, что она отвратительная.
ну-ну, в каком месте?
Во всех.Официальная документация postfix - это набор бессодержательных разрозненных, местами противоречивых, местами капитанских хаутушек, без общей системы, без логики изложения, без нормального индекса и без внятно сформулированных предположений о том, какая у неё целевая аудитория.
У меня есть даже замеры, идентичная по функционалу конфигурация достигается на postfix в 10 раз дольше, чем на opensmtpd. (20 дней против 2)
20 дней на настройку постфикс?! Может вам лучше профессию сменить?
Нет, я лучше сменю postfix на opensmtpd.
> Нет, я лучше сменю postfix на opensmtpd.А это не поможет. postfix не ахти какой сложный в настройке, если ты его не осилил то споткнешься на любой другой простой задаче отличной от next-next-finish
>> Нет, я лучше сменю postfix на opensmtpd.
> А это не поможет. postfix не ахти какой сложный в настройке, если
> ты его не осилил то споткнешься на любой другой простой задаче
> отличной от next-next-finishНу, я все же предполагаю, что речь шла не о настройке сферического postix на localhost'е - а по построению на его основе некоторого минимально нагруженного корпоративного mail gateway'а с антивирусом (clamav не предлагать!), антиспамом, аутентификацией, интеграцией с сервером каталогов и т.д. - да еще так, чтобы ту почту вот outlook.com с gmail.com по итогу кушал. Предполагаю, что по совокупности затрат (Нет, письмо "привет, мир!" прилетевшее админу на mailru'шный ящик - финальной точкой не является) если задача для тебя не конвейерная да есть внешний контроль качества выполнения\ограничения той же ИБ - оно как-то так и выйдет...
И каким образом ты из моих слов "локалхост" "приветмир" "майлру" и тем более "clamav" скомпелировал? Эльфийские фантазии?
Ну и да
> да есть внешний контроль качества выполнения\ограничения той же ИБТут уже смешно когда предлагается шило на мыло (opensmtpd) поменять.
Похоже, тебе действительно стоит поменять профессию.
> И каким образом ты из моих слов "локалхост" "приветмир" "майлру" и тем
> более "clamav" скомпелировал? Эльфийские фантазии?Вот из этой вот строчки:
"20 дней на настройку постфикс?! Может вам лучше профессию сменить?"
практически однозначно и вытекает, что с _реальными_ трудозатратами человек на уровне вот "локалхост", "приветмир", "мейлру" и знаком.
Ну или у нас миссандерстандинг и мы очень по разному определяем границы задачи - если так, то прошу пардону.
Про "андерстендинг" это ты верно подметил. У тебя он точно полный мисс. Ибо 20 дней настройки постфикс практически под любую задачу на которую он способен это за гранью понимания любого человека который настраивал почтовые системы, знает как это вообще работает и умеет читать документацию (желательно ДО, а не после).
Очередной диванный неосилятор.
> Про "андерстендинг" это ты верно подметил. У тебя он точно полный мисс.
> Ибо 20 дней настройки постфикс практически под любую задачу на которую
> он способен это за гранью понимания любого человека который настраивал почтовые
> системы, знает как это вообще работает и умеет читать документацию (желательно
> ДО, а не после).
> Очередной диванный неосилятор.Ну, если вы готовы выполнить указанные работы:
"Ну, я все же предполагаю, что речь шла не о настройке сферического postix на localhost'е - а по построению на его основе некоторого минимально нагруженного корпоративного mail gateway'а с антивирусом (clamav не предлагать!), антиспамом, аутентификацией, интеграцией с сервером каталогов и т.д. - да еще так, чтобы ту почту вот outlook.com с gmail.com по итогу кушал. Предполагаю, что по совокупности затрат (Нет, письмо "привет, мир!" прилетевшее админу на mailru'шный ящик - финальной точкой не является) если задача для тебя не конвейерная да есть внешний контроль качества выполнения\ограничения той же ИБ - оно как-то так и выйдет..."
на каком-нибудь заводике об 1000 хотя бы человеков сильно быстрее... то я предоложу, что на оном заводике вы и не были-то никогда и в реалиях(ТМ) аналогичные задачи не решали.
> Ну, если вы готовы выполнить указанные работы:И опять высасывание из сферического вакуума.
Мне то это зачем. Я с подобного рода задачами наигрался лет цать назад. Не интересно.
И да, наши админы сейчас оное крутят на "заводике" сильно больше 1000 человеков.
> то я предоложу
Ну понятно. Что и требовалось доказать. Диванный неосилятор.
>> Ну, если вы готовы выполнить указанные работы:
> И опять высасывание из сферического вакуума.
> Мне то это зачем. Я с подобного рода задачами наигрался лет цать
> назад. Не интересно.
> И да, наши админы сейчас оное крутят на "заводике" сильно больше 1000
> человеков.Ну вот с этого бы и начинали - "сам я не знал, но забыл, зато брат-жены-сестры-мужа в сторазбольше и вдваразабыстрее делает, фиглетут?!"
А в реальности - проект модернизации почтовой системы предприятия на коробочный exchange занял 9 месяцев, хотя казалось бы чего там - нехт-нехт-нехт проклацать? А вот гляди-ж ты.
>>> Ну, если вы готовы выполнить указанные работы:
>> И опять высасывание из сферического вакуума.
>> Мне то это зачем. Я с подобного рода задачами наигрался лет цать
>> назад. Не интересно.
>> И да, наши админы сейчас оное крутят на "заводике" сильно больше 1000
>> человеков.
> Ну вот с этого бы и начинали - "сам я не знал,
> но забыл, зато брат-жены-сестры-мужа в сторазбольше и вдваразабыстрее делает, фиглетут?!"С чего начинал? С того что ты опять высосал из... пусть будет пальца?
Нет, я вполне четко и ясно сказал что мне это НЕ интересно много лет уже как. У меня есть отлично оплачиваемая работа и личная жинь в отличии от.. а на понты вида "а вам слабо" я не ведусь с самого детства.
> А в реальности - проект модернизации почтовой системы предприятия на коробочный exchange
> занял 9 месяцев, хотя казалось бы чего там - нехт-нехт-нехт проклацать?
> А вот гляди-ж ты.О, внезапно тут оказался коробочный exchange... Это ПРОВАЛ дружОк. Ты так ловко (нет) условия задачи на ходу меняешь что аж загледенье.
Продолжай фантазировать. Ты меня улыбаешь.
Через пару десятков реплик ты дофантазируешься до реализации винды на кодовой базе постфикса. =)))
>[оверквотинг удален]
>>> И да, наши админы сейчас оное крутят на "заводике" сильно больше 1000
>>> человеков.
>> Ну вот с этого бы и начинали - "сам я не знал,
>> но забыл, зато брат-жены-сестры-мужа в сторазбольше и вдваразабыстрее делает, фиглетут?!"
> С чего начинал? С того что ты опять высосал из... пусть будет
> пальца?
> Нет, я вполне четко и ясно сказал что мне это НЕ интересно
> много лет уже как. У меня есть отлично оплачиваемая работа и
> личная жинь в отличии от.. а на понты вида "а вам
> слабо" я не ведусь с самого детства.Да все уже поняли, что вы больше по комментариям специалист, узбагойтесь - никто вас работать не заставляет.
>> А в реальности - проект модернизации почтовой системы предприятия на коробочный exchange
>> занял 9 месяцев, хотя казалось бы чего там - нехт-нехт-нехт проклацать?
>> А вот гляди-ж ты.
> О, внезапно тут оказался коробочный exchange... Это ПРОВАЛ дружОк. Ты так ловко
> (нет) условия задачи на ходу меняешь что аж загледенье.Ээээ... это не "изменение условий", это информация о том, сколько в реальной жизни занимает решение подобного рода функциональных задач для тех, кто в теме вот ну совсем не в зуб ногой и "дачотамдвадцатьднейделатьто?!".
>[оверквотинг удален]
>>> Ну вот с этого бы и начинали - "сам я не знал,
>>> но забыл, зато брат-жены-сестры-мужа в сторазбольше и вдваразабыстрее делает, фиглетут?!"
>> С чего начинал? С того что ты опять высосал из... пусть будет
>> пальца?
>> Нет, я вполне четко и ясно сказал что мне это НЕ интересно
>> много лет уже как. У меня есть отлично оплачиваемая работа и
>> личная жинь в отличии от.. а на понты вида "а вам
>> слабо" я не ведусь с самого детства.
> Да все уже поняли, что вы больше по комментариям специалист, узбагойтесь -
> никто вас работать не заставляет.Естественно не заставляет особенно ты, ибо фэйлиш буквально в каждом комментарии.
>>> А в реальности - проект модернизации почтовой системы предприятия на коробочный exchange
>>> занял 9 месяцев, хотя казалось бы чего там - нехт-нехт-нехт проклацать?
>>> А вот гляди-ж ты.
>> О, внезапно тут оказался коробочный exchange... Это ПРОВАЛ дружОк. Ты так ловко
>> (нет) условия задачи на ходу меняешь что аж загледенье.
> Ээээ... это не "изменение условий", это информация о том, сколько в реальной
> жизни занимает решение подобного рода функциональных задач для тех, кто в
> теме вот ну совсем не в зуб ногой и "дачотамдвадцатьднейделатьто?!".Нет мальчОнка, это изменение условий причем кардинальное.
И все это с учетом того, что ты _ВООБЩЕ_, никак, вот совсем не понимаешь что такое exchange но зачем-то вставил его в наш с тобой диалог про постфикс. А ещё ты путаешься в показаниях, сначала было цитирую "20 дней" и "минимально нагруженного корпоративного mail gateway'а " теперь "exchange" и "9 месяцев". Эпичненько.Примерно как в разговор про овальное приплести теплое. =)
> подобного рода функциональных задачПрямо таки взоржал. Ты даже отдаленно не понимаешь что в данном случае "подобного рода задача"
>[оверквотинг удален]
>>> (нет) условия задачи на ходу меняешь что аж загледенье.
>> Ээээ... это не "изменение условий", это информация о том, сколько в реальной
>> жизни занимает решение подобного рода функциональных задач для тех, кто в
>> теме вот ну совсем не в зуб ногой и "дачотамдвадцатьднейделатьто?!".
> Нет мальчОнка, это изменение условий причем кардинальное.
> И все это с учетом того, что ты _ВООБЩЕ_, никак, вот совсем
> не понимаешь что такое exchange но зачем-то вставил его в наш
> с тобой диалог про постфикс. А ещё ты путаешься в показаниях,
> сначала было цитирую "20 дней" и "минимально нагруженного корпоративного mail gateway'а
> " теперь "exchange" и "9 месяцев". Эпичненько.Ээээ... ну вот месяц из тех девяти как раз и заняла настройка postfix'ов со всеми приседушками перед тем exchange'ем - если хотите, можете справиться быстрее. Ах, да - лапки?
>[оверквотинг удален]
>>> теме вот ну совсем не в зуб ногой и "дачотамдвадцатьднейделатьто?!".
>> Нет мальчОнка, это изменение условий причем кардинальное.
>> И все это с учетом того, что ты _ВООБЩЕ_, никак, вот совсем
>> не понимаешь что такое exchange но зачем-то вставил его в наш
>> с тобой диалог про постфикс. А ещё ты путаешься в показаниях,
>> сначала было цитирую "20 дней" и "минимально нагруженного корпоративного mail gateway'а
>> " теперь "exchange" и "9 месяцев". Эпичненько.
> Ээээ... ну вот месяц из тех девяти как раз и заняла настройка
> postfix'ов со всеми приседушками перед тем exchange'ем - если хотите, можете
> справиться быстрее. Ах, да - лапки?Ага, уже "месяц"... 4й вариант твоей фантазии.
>если хотите, можете справиться быстрее.
Ок хочу. Час моего рабочего времени стоит ~4000 р. Поскольку это будет есессно во вне рабочее время вечером, то по тройной ставке. Понадобится где-то неделю если дополнительных "хотелок" и очередных "фантазий" всплывать не будет. Каждая новая фантазия по х5.
По 4-5 часов вечером, итого ~420 000 на руки. Предоплата 250 000 на карту сразу.А? чо? Ты столько в год не зарабатываешь? Не удивительно ибо "20 дней" и "9 месяцев".
И сколько коко было в стиле "Ах, да - лапки?" =)))
Вам, поди, ещё и на русском всё это надо?
Угадал?
Документация у постфикса одна из лучших. Если её не хватает, то тут только можно посоветовать читать букварь Эви Немет et al., релевантные RFC, и очень много думать над прочитанным. А для почты нанять кого-то с опытом и напроситься к нему в подмастерья.
Если брать документацию, как описание и возможные параметры - то да, очень хороша, как справочник, но и то, подробной картины не дающий. В пору исходники уже изучать чтоб понять где и какие моменты происходят, потому как настраивать правильно тот же алиас домена, а точнее его переписывание, на время переезда домена на другой(именно переписывать, чтоб пользователи временно могли получать и отправлять свои учётки старые, а ходило при этом всё с нового домена) - тот ещё геморрой, где не совсем понятно в какой части что применяется и как должно отработать. Примеры не до конца создают картину понимания что и зачем настраивается, и почему так, а не по другому. Для простых кейсов там действительно всё более чем хорошо описано и не создаётся проблем настроить.
Классика: The book of Postfix Ральфа Гильдебрандта. Есть на-русском. Но ей больше 20 лет уже.
zlib не выпилили: "zlib: Renamed to mail_compress plugin."
Не особо актуально уже. BTRFS рулит.
Для почтаря?!?!?! 8-о
BTRFS и так вовно, а для почтаря или DB-хи оно вовно абсолютное! АзЪ! :)
Не, ну на локалхосте жать базу почты в узерспейсе - да, производительненько.
Эээээ... так вы еще и не свои 2,5 письма на бырбырфысы держите?!
"У самурая нет цели, есть только путь ..."
Может он бакапы уже делает ?
> "У самурая нет цели, есть только путь ..."
> Может он бакапы уже делает ?И может даже не на соседний subvolume - но это не точно. И вообще, зачем их делать? Там жи этот, как его? RAID есть, и говорят, что уже работает (но это тоже не точно).
Не, ну свои-то ж - жалко будет.
А бэкап пусть юзеры делают, а то чо они?
В каких больших публичных деплоях используется сабж? Доводилось работать с несколькими крупными провайдерами из top 10 по количеству активных ящиков, везде самописанный софт на яве, крестах, ноджс, но Dovecot не встречал даже в самых недрах бэкэнда. Энтерпрайз плотно сидит на Exchange, Gmail для бизнеса и подобных продуктах. Сабж, похоже, подходит только для местечковых провайдеров и локалхостов.
Могу за местечкового провайдера сказать - действительно подходит :)
В этом сомнений нет. Интересно было бы почитать про деплои 10+миллионов активных пользователей. И не могу найти…
так все будет упираться в сторейдж, и довкот не для этого уровня, хотя через прокси (довкот-прокси) можно спроксировать на разные бекенды в зависимости от юзера и масштабировать его. С базой ток надо определиться на 10 лямов записей мускул еще может потянуть. 50-100К активных пользователей потянет без проблем. По лмтп подключаем к постфиксу и всё.
Зачем проксировать через сабж? Какую задачу это должно решить?
задачу 10 лямов пользователей со своей почтой как-то должны масштабироваться. Вы хоть представляете какой обьем хранилища необходимо? Эт вам не рамблер, который все письма в базу складывал :)
Я отлично представляю себе не только объёмы хранилищ, но и некоторые интимные подробности внутреннего устройства сетей этих самых хранилищ на примере Yahoo и Hotmail. Нет, это совсем не рамблер. Но ты так и не ответил зачем проксировать трафик через сабж. А не через TCP-прокси типа Envoy, как это делается в реальности.
> Но ты так и не ответил зачем проксироватьТвой тисипипрокси как будет проксировать пользователя vasya@domain.com на бекенд a.b.c.imap.domain.com? TCP у вас L7 протокол уже?
Вообще 10 миллионов можно спокойно пошардить, и базу пользователей тоже, без особых проблем. Но тут другой момент, на 10 миллионов классический файловый сторейдж с шардингом - это лютый геморрой в обслуживании, тут скорее надо делать на базе object storage (в коммерческом птицекоте есть S3-based), и дальше уже ноды просто спаунить от нагрузки классическими способами и вешать на балансер. Поэтому в теории можно и на птицекоте, но не на опенсорсном.
опенсорсный птицекот спокойно масштабируется, все зависит от размеров нод.
> спокойно масштабируетсяВ теории всё спокойно масштабируется. На практике же сабж для локалхостов и деплоев на 3,5 сервера.
> В теории всё спокойно масштабируется. На практике же сабж для локалхостов и деплоев на 3,5 сервера.Ну вот ваши эти 3,5 сервера достаточно для 10К, думаю и больше потянет, и не в теории, любой кто связывался с этим - подтвердит.
Подтверждаю. 3.5 сервера спокойно тянут 50к.
Да ни хрена он не масштабируется. Не, я могу OCFS'ов и на 10 миллионов нагородить - и даже отказоустойчивость будет. Но всё вот этот полуруками шардить и контролить кто где - это блин очень унылое извращение. С object storage можно хотя бы по размещению данных не париться. Но вот без дедупликации вложений будет очень накладно на эти 10 миллионов, когда спамер на них очередной zip в мегабайт разошлёт :)
> Да ни хрена он не масштабируется. Не, я могу OCFS'ов и на 10 миллионов нагородить - и даже отказоустойчивость будет.так это же не проблема довекота, это проблема масштабирования хранилища, а довкот только предоставляет средства проксирования протокола на разные бекенды, что необходимо при его масштабировании. Довкот масштабируем - да, потому-что у него из коробки есть средства проксирования. А вот средств хранения и управления масштабируемостью - нету. Есть только поддержка всяких лдапов, мускулов, обджект сторейдж (про) и т.д., но и задача по их масштабированию не задача довкота.
> С object storage можно хотя бы по размещению данных не париться.
Как это не парится? а кто будет заниматься его (object storage-а) масштабированием, когда можно тупо все данные распределить независимо по нодам на банальной локальной ФС. Но в таком случае надо еще задуматься о резервном хранилище. Ну свалился бекенд с данными у пользователя А, его быстро переводим в один клик на другой бекенд, он получает новый мейлбокс - да пустой, а потом из бекапа восстановить его содержимое. И проблема затронет только пользователя А (если бекенд выделен только для него). И система поиска по почте будет локальна, не надо потом городить систему поиска по всему обджект хранилищу, потому-что пользователю А нет необходимости искать по письмам пользователя Б - по определению.
> Но вот без дедупликации вложений будет очень накладно на эти 10 миллионов, когда спамер на них очередной zip в мегабайт разошлёт :)
это все не проблемы довкота :) давайте еще возложим на него проблемы резервного хранилища этих вложений и т.д.
пс: Вы предлагаете вот это решение
https://doc.dovecot.org/2.3/admin_manual/dovecot_cluster_arc.../
,а я предлагаю, что лучше сделать банальный
https://doc.dovecot.org/2.3/admin_manual/dovecot_proxy/
без всяких шаред стореджей (нфс, самба и т.д.), тупо распределить пользователей по независимым бекендам с хранением в локальной фс. И проблемы всяких айопсов будут локальны для пользователя, и тут можно играться, кому-то увеличить объем хранения, кого-то перекинуть с сата на ссд диск и т.д.
Нет больше нормальных средств проксирования в опенсорсной версии :)
И да, S3-based сторейджа в опенсорсной версии тоже нет.
По нодам на локальной ФС - это трындец по отказоустойчивости.
OCFS2 нормально справляется, не без нюансов, но.
Но вот всё это разгородить на 100500 нод и пошардить туда 10 лямов юзеров - я бы не взялся. Во всяком случае не в опенсорсном варианте точно.
> По нодам на локальной ФС - это трындец по отказоустойчивости.А если был бы S3, то мы бы об этом даже не думали бы, так что ли? И говоря об отказоустойчивости, тут все сводится к отказоустойчивости именно хранилища, свалилось хранилище - свалилось ВСЁ, и пофиг, что у вас автоскейлинг инстансов довкота и т.д. Вариант с локальными ФС - локализует "сваливание всего".
> OCFS2 нормально справляется, не без нюансов, но.
Свалится OCFS2 - свалится ВСЁ, не говорю про затраты на всякие SAN стореджи.
> Но вот всё это разгородить на 100500 нод и пошардить туда 10 лямов юзеров - я бы не взялся.
гугл ровно так и прошардил на недорогих мощностях.
> Во всяком случае не в опенсорсном варианте точно.
Потому-что надо дописывать логику управления всем этим распределением и механизмов фейловера. Да и миграция и апдейт упрощается в распределенной системе, чем в случае с шаред стореджем :)
>> OCFS2 нормально справляется, не без нюансов, но.
> Свалится OCFS2 - свалится ВСЁ, не говорю про затраты на всякие SAN стореджи.Почему всё? Всё тот же шардинг никто не отменял, просто появляется второй слой отказоустойчивости с возможностью нескольких нод на шард.
> гугл ровно так и прошардил на недорогих мощностях.
Гугл как раз таки "ровно так" и не шардит - они всё льют в огромный распределённый сторейдж.
> Почему всё?Потому-что она не обеспечивает отказоустойчивость, это просто кластерная ФС совместного (shared) доступа, а не кластерная распределенная ФС, такая как Lustre, HDFS, GFS (гугла) и т.д., в которых по определению заложены механизмы отказоустойчивости, такие как репликейшен факторы.
"""
https://www.oracle.com/us/technologies/linux/ocfs2-best-prac...It is important that all nodes that will access the file system have read and write access to the storage being used to store the file system. For SAN and iSCSI based storage access, multi-pathed disk volumes are highly recommended for redundancy. This will protect against the individual nodes losing access to the storage in the event of a path failure. Optimally this should be done on redundant switches in the event of a switch failure causing the path failure.
"""> Гугл как раз таки "ровно так" и не шардит - они всё льют в огромный распределённый сторейдж.
Тут надо понять, что мы шардим. В случае с довкотом - шардится пользователь. Пользователь А идет на бекенд А, пользователь Б идет на бекенд Б. Это есть банальное распределение пользователей (шардинг, независимое распределение (сегментирование)). И каждый бекенд хранит только данные своего пользователя, и в этой схеме нет необходимости в распределенном или совместном хранилище. А в случае гугла, у него уже есть распределенная система ХРАНЕНИЯ, как отдельный проект, где единицей шарда является блоки данных, а доступ - совместный (высокоуровневый - файловый или что у них там). И для проекта гмейла, не было необходимости придумывать механизм распределения пользователей и их писем (данных), ибо это связанные понятия в плане распределения, тут достаточно распределенной системы хранения, которая на момент зарождения гмейла уже была спроектирована, для задач поисковой системы.
Хосспаде. Замени в своей локальной схеме ext4 (или что там у тебя за) на ocfs2 и подумай :)
> Замени в своей локальной схеме ext4 (или что там у тебя за) на ocfs2 и подумай :)Да, надо подумать на какие бабки сначала купить SAN.
Фиксированный прокси - ну, можно, но это блин лютейший геморрой.
Ноду просто так не вывести. "Переводить в один клик" - можно только когда у тебя 1.5 бэкенда, на паре сотен уже задолбаешься. Опять же какую-то репликацию городить для активного бэкапа. Всё это можно, но всё это лютый костылинг, поэтому просто берут и пишут сами, POP3/IMAP/SMTP не настолько сложные протоколы.
> Фиксированный прокси - ну, можно, но это блин лютейший геморрой.Это норма для любой распределенной системы. Вот с чем я соглашусь, так с тем, что довкот НЕЛЬЗЯ считать распределенной системой по определению, но от этого довкот не перестал быть не масштабируемым. Вертикально, до некоторого предела, его можно масштабировать, а для горизонтального масштабирования у него есть средства проксирования, которые позволяют распределить пользователей по разным независимым бекендам (узлам), тем самым превращая всю систему (архитектуру) в распределенную, которая по определению является горизонтально масштабируемой.
https://ru.wikipedia.org/wiki/Масштабируемость
https://ru.wikipedia.org/wiki/Распределённая_система
> Опять же какую-то репликацию городить для активного бэкапа.
А разве в случае с OCFS2 или любой другой шаред ФС, в этом нет необходимости?
> Всё это можно, но всё это лютый костылинг, поэтому просто берут и пишут сами, POP3/IMAP/SMTP не настолько сложные протоколы.
Надо просто понимать масштабы и пределы масштабирования. Ваша архитектура на базе шаред ФС может 10М еще держать, но точно могу сказать - не сдержит 100М, потому-что в таких масштабах практика (ну и логика) показывает, что необходимо проектировать максимально распределенную архитектуру, и даже в таких случаях возникают вопросы связанные с data locality.
Вывод: никогда не будет готового решения, ибо все зависит от задач и масштабов, всегда лучше брать писать самим, но писать ли самим для конторы из 10К сотрудников? - НЕТ, если вам за это не готовы платить.
Окей. У меня _один_ пользователь с тысячей коннектов к ящику терабайтами писем в день. Давай, покажи мне горизонтальную масштабируемость своей схемы. Вот с универсальными нодами и объектным сторейджем - получится. Да, это вырожденный случай, но таковые тоже надо учитывать.
> Окей. У меня _один_ пользователь с тысячей коннектов к ящику терабайтами писем в день. Давай, покажи мне горизонтальную масштабируемость своей схемы.Тысяча коннектов - это уже сетевая масштабируемость, железный балансер (L4) проксирует на бекенды (инстансы довкота, который резолвит одного юзера). А для петабайтов писем одного пользователя необходима распределенная система хранения, которая будет иметь общую точку доступа, так как это кластер хранящий данные. Отсюда каждый бекенд будет иметь к нему доступ - общий доступ, но на каком уровне? - на уровне какого-то объекта или проще говоря - файла (API), но система хранения не является шаред как OCFS2, которая работает с блочным устройством. А раз нам необходима масштабируемая система хранения, то причем тут довкот вообще? Довкот - не система хранения, он не решает вопросы масштабирования и доступа к хранилищу. Но в моей описанной схеме довкот - масштабируется сам - горизонтально за счет проксирования, а его локальный сторедж масштабируется вертикально (засунуть терабайтник на один бекенд и выделить его пользователю, да хоть все 16 дисков, это все вертикальное масштабирование стореджа). Ваш вырожденный случай имеет место быть в случае с shared imap folder. А в этом случае все бекенды должны иметь к нему доступ, отсюда и необходимость общего доступа, в итоге плюс один уровень абстракции.
да, совсем забыл, как же без безопасТности, с ее точки зрения лучше распределить данные по независимым нодам, чем хранить централизованно в одном месте, куда каждый бекенд "имеет" доступ.
Вообще без разницы, все бэкенды в таком масштабе одинаковые. Ломанут один - ломанут все.
Можно пошардить, и таки шардят, но по-своему с учётом географии, юрисдикций и суточных циклов. Файловое хранение действительно не применяется, равно как и S3. И ноды не спавнятся сами по себе за пределами обычного круговорота поломок компонентов, всё максимально статично и декларативно.
На 10+ миллионов ни одного готового решения ты уже не найдёшь - только писать самому.
ты ценник у коммунигейта на 10к пользователей запроси, промолчу там про всякие лотусы и эксченджи.
Вот я и пытаюсь понять, как же так вышло, что опенсорсное решение есть, а всё равно пишут сами. И не надо про NIH рассказывать, ядро и весь обвес таки опенсорсные используются, да и в целом опесорсные решения в почёте, административно запрещено начинать новую разработку не оценив возможности имеющихся опенсорсных решений и сравнив объёмы работы по допиливанию vs. писать с нуля.
Не знаю, у меня последний внутренний IMAP ушёл в закат в 2018.
Сейчас жи даже Exchange свой держать не модно :( - всё в облако жи ...
А что значит "в облаке"? Там же тоже надо какое-то приложение для IMAP?
Кому надо-то? Аутлук с эксченджем работает не по IMAP, веб-клиент и подавно. А больше в бизнесе ничем и не пользуются особо. Ну какие-то маргинальные решения бывают, но на то они и маргинальные, чтобы погоды не делать.
> Аутлук с эксченджем работает не по IMAP, веб-клиент и подавноХотя привязываться к собственническому протоколу одного клиента не самое лучше решение, как потом этот аутлук на линукс ставить? Гм... ну допустим. Но ведь всё равно нужен же какой-то софт в облаках с поддержкой этого проприетарного протокола. И что там будет, опять проприетарщина?
Astra Linux (для вояк) проталкивает dovercot - как основной IMAP сервер.
Чёт с давкотом после копроративазиции всё плохо.- director: Feature has been removed
- fs-sis: Feature is now deprecated and has been made read-only
It will be removed in future release
- fts-lucene, fts-squat: These have been removed
- mail_compress: XZ and LZMA algorithm support has been removedПо ходу с 2.3 можно не уходить.
"а вот мы его поддерживать прекратим сразу после обнаружения remote root очередного!"
> "а вот мы его поддерживать прекратим сразу после обнаружения remote root очередного!"Самая шляпа с SiS и XZ, я тут понимаю, что у меня потребуется лишних 3-4 терабайта сторейджа, а он не дешёвый.
> лишних 3-4 терабайта сторейджа×100 нод хотя бы, да?
> а он не дешёвый
Ну не знаю, попробуйте деньги начать зарабатывать что ли…
Понимаешь в чём дело, почта у нас - это бесплатная дополнительная услуга. Поэтому есть моменты.
> бесплатная дополнительная услугаПонимаю, да. Ну повторюсь, чтобы такого не было надо на почте зарабатывать. Аналитика, защита от спама и фишинга, вот это всё.
Сбегут
Чтобы на почте зарабатывать - надо быть гуглом. Или мелкософтом.
Мелочёвка типа ну вы знаете рунет - не в счёт, готов даже предположить, что это тоже side service с отрицательной маржой.
А чего в новости умолчали, что проект написан на Си? Тут же растопереписывальшиков валом, вот был бы срач.
Репликацию выпилили, как и обещали.
Надеюсь кто-то форкнет 2.3