Re: Синхронизация main-backup mail servers

2007-09-24 Пенетрантность Andrey Melnikoff
Tim Tereschenko <[EMAIL PROTECTED]> wrote:
> On Wed, 5 Sep 2007 14:50:19 +0400
> "Artem Chuprina" <[EMAIL PROTECTED]> wrote:

> AC> > > Да, и называются "база юзеров в LDAP/*SQL"
> AC> >
> AC> > Ну, прям уж сразу в LDAP/SQL...  В BerkeleyDB, (AKA исходник в
> AC> > текстовом файле), что есть у любого почтовика, при небольшом
> AC> > количестве юзеров гораздо удобнее.
> AC> 
> AC> Вернее, даже так: это почти единственный способ.  Ибо бэкапный MX не
> AC> должен пользоваться той же базой пользователей, что и основной.  Ибо
> AC> если понадобился бэкапный MX, то скорее всего, основная база
> AC> недоступна.

> В теории более-менее ясно. В какую сторону смотреть? На какую связку? 
> Рекомендации, описания?
Exim со smarthost и включенным require verify=recipient. без файликов и
прочих sql/ldap. Но если первичный сервер упал - оно тоже почту принимать не
будет.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Синхронизация main-backup mail servers

2007-09-07 Пенетрантность Alexey Lobanov
Тут по ходу дела вспомнилось грязное, но быстрое полу-решение.

Верификация получателя, reject_unverified_recipient в Постфиксе. В
других MTA не помню.

Результаты верификации (и положительные, и отрицательные) Postfix
кэширует, создавая тем самым некий волатильный аналог локальной базы
правильных получателей. Время кэширования управляется.

А для задачи "прикрыть иксчейндж снаружи нормальным MTA" это работает
почти совсем хорошо, поскольку набранная "автоматическая" база
правильных получателей быстро оказывается полной.

А.Л.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Синхронизация main-backup mail servers

2007-09-05 Пенетрантность Artem Chuprina
> >> Да, и называются "база юзеров в LDAP/*SQL"
>
> > Ну, прям уж сразу в LDAP/SQL...  В BerkeleyDB, (AKA исходник в
> > текстовом файле), что есть у любого почтовика, при небольшом
> > количестве юзеров гораздо удобнее.
>
> Однако на практике в эту же базу должны смотреть не только MXы, но и ещё
> кое-кто. Как минимум всегда смотрит система хранения - IMAP или
> файловая.

... вот только эти системы на бэкапном MX, вообще говоря, не имеют
отношения к оным на основном.  Никто туда не ходит по IMAP и уж тем
более - по файловой системе.  Ну, кроме админов.  Ибо о существовании
его знают только DNS да админы.

Если же речь идет о резервировании внутреннего почтового сервера, то
это не бэкапный MX, это реплика сервера.  Это совсем другая задача...

> Как максимум - биллинг в коммерческой системе и стайка
> прикладных сервисов в корпоративной.

Вот уж чего на бэкапном MX нету, так это биллинга.  Биллинг - он на
основной площадке, рядом со входом юзеров.  Прикладные сервисы там
быть могут, но мне как-то не попадалось.  Они обычно тоже на основной
площадке...


Re: Синхронизация main-backup mail servers

2007-09-05 Пенетрантность Artem Chuprina
> AC> Посему, если уж бэкапный MX используется, то у него должна быть своя
> AC> база со всей необходимой информацией.  Синхронизируемая с основной, но
> AC> не являющаяся ею.
>
> Реплика?

Реплика.  Я, правда, обхожусь.  Но  у меня на бэкапном MX логика
хитрее, чем на основном, там репликой можно пользоваться, но нельзя
отделаться.


Re: Синхронизация main-backup mail servers

2007-09-05 Пенетрантность Alexey Lobanov
Hi all.

05.09.2007 14:48, Artem Chuprina пишет:

>> Да, и называются "база юзеров в LDAP/*SQL"

> Ну, прям уж сразу в LDAP/SQL...  В BerkeleyDB, (AKA исходник в
> текстовом файле), что есть у любого почтовика, при небольшом
> количестве юзеров гораздо удобнее.

Однако на практике в эту же базу должны смотреть не только MXы, но и ещё
кое-кто. Как минимум всегда смотрит система хранения - IMAP или
файловая. Как максимум - биллинг в коммерческой системе и стайка
прикладных сервисов в корпоративной.

Соответственно, зацепить всю эту херню за одну базу со стандартным
сетевым интерфейсом (LDAP или *SQL) может быть существенно эффективнее
по перспективам дальнейшей эксплуатации. А не генерировать отдельные
файлики для каждого демона.

А для надёжности есть LDAP/SQL репликация и даже heartbeat.

А.Л.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Синхронизация main-backup mail servers

2007-09-05 Пенетрантность Tim Tereschenko
On Wed, 5 Sep 2007 17:09:27 +0400
"Artem Chuprina" <[EMAIL PROTECTED]> wrote:

AC> Посему, если уж бэкапный MX используется, то у него должна быть своя
AC> база со всей необходимой информацией.  Синхронизируемая с основной, но
AC> не являющаяся ею.

Реплика?

-- 
Tim Tereschenko


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Синхронизация main-backup mail servers

2007-09-05 Пенетрантность Artem Chuprina
> > > > Да, и называются "база юзеров в LDAP/*SQL"
> > >
> > > Ну, прям уж сразу в LDAP/SQL...  В BerkeleyDB, (AKA исходник в
> > > текстовом файле), что есть у любого почтовика, при небольшом
> > > количестве юзеров гораздо удобнее.
> >
> > Вернее, даже так: это почти единственный способ.  Ибо бэкапный MX не
> > должен пользоваться той же базой пользователей, что и основной.  Ибо
> > если понадобился бэкапный MX, то скорее всего, основная база
> > недоступна.
>
> нет (с).
> Проблемы с железом или фс, оверлоад, ребут основного сервера, падение
> канала -- что угодно.
> и да, база обязана быть общей чтоб избежать во-первых рейсов между
> "создали нового юзера" и "почта для нового юзера пришла на второй mx", а
> во-вторых чтоб спам на этапе смтп-сессии и грейлист на всех МХ
> проверялись по одной базе, иначе они теряют половину смысла.

Обычная проблема - падение канала.  Может быть, вместе с серверами
(электричество отключили), может быть по отдельности.  При этом либо
бэкапный MX недоступен, либо по причине падения канала не может
достучаться до базы.  В обоих случаях функциональность его равна нулю
(и это еще хорошо, если нулю, а не меньше - т.е. если он при
недоступности базы юзеров говорит 4xx, а не 5xx, как в случае, когда
база доступна, но юзер не найден), т.е. непонятно, зачем он вообще
нужен.

Прочие же дизастеры происходят много реже.  И уж во всяком случае не
чаще, чем те же дизастеры происходят с этой самой основной базой,
которая тоже не святым духом поддерживается, а на каком-то сервере
живет.

Посему, если уж бэкапный MX используется, то у него должна быть своя
база со всей необходимой информацией.  Синхронизируемая с основной, но
не являющаяся ею.


Re: Синхронизация main-backup mail servers

2007-09-05 Пенетрантность Artem Chuprina
> AC> > > Да, и называются "база юзеров в LDAP/*SQL"
> AC> >
> AC> > Ну, прям уж сразу в LDAP/SQL...  В BerkeleyDB, (AKA исходник в
> AC> > текстовом файле), что есть у любого почтовика, при небольшом
> AC> > количестве юзеров гораздо удобнее.
> AC>
> AC> Вернее, даже так: это почти единственный способ.  Ибо бэкапный MX не
> AC> должен пользоваться той же базой пользователей, что и основной.  Ибо
> AC> если понадобился бэкапный MX, то скорее всего, основная база
> AC> недоступна.
>
> В теории более-менее ясно. В какую сторону смотреть? На какую связку? 
> Рекомендации, описания?

Если вопрос ко мне, то я в такой ситуации пользуюсь штатными
средствами postfix.  Правда, в моей ситуации изменения в наборе
пользователей происходят настолько редко, что скрипта, заботящегося о
синхронизации, я себе не написал.


Re: Синхронизация main-backup mail servers

2007-09-05 Пенетрантность Tim Tereschenko
On Wed, 5 Sep 2007 14:50:19 +0400
"Artem Chuprina" <[EMAIL PROTECTED]> wrote:

AC> > > Да, и называются "база юзеров в LDAP/*SQL"
AC> >
AC> > Ну, прям уж сразу в LDAP/SQL...  В BerkeleyDB, (AKA исходник в
AC> > текстовом файле), что есть у любого почтовика, при небольшом
AC> > количестве юзеров гораздо удобнее.
AC> 
AC> Вернее, даже так: это почти единственный способ.  Ибо бэкапный MX не
AC> должен пользоваться той же базой пользователей, что и основной.  Ибо
AC> если понадобился бэкапный MX, то скорее всего, основная база
AC> недоступна.

В теории более-менее ясно. В какую сторону смотреть? На какую связку? 
Рекомендации, описания?
-- 
Tim Tereschenko


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Синхронизация main-backup mail servers

2007-09-05 Пенетрантность Artem Chuprina
> > Да, и называются "база юзеров в LDAP/*SQL"
>
> Ну, прям уж сразу в LDAP/SQL...  В BerkeleyDB, (AKA исходник в
> текстовом файле), что есть у любого почтовика, при небольшом
> количестве юзеров гораздо удобнее.

Вернее, даже так: это почти единственный способ.  Ибо бэкапный MX не
должен пользоваться той же базой пользователей, что и основной.  Ибо
если понадобился бэкапный MX, то скорее всего, основная база
недоступна.


Re: Синхронизация main-backup mail servers

2007-09-05 Пенетрантность Artem Chuprina
> Да, и называются "база юзеров в LDAP/*SQL"

Ну, прям уж сразу в LDAP/SQL...  В BerkeleyDB, (AKA исходник в
текстовом файле), что есть у любого почтовика, при небольшом
количестве юзеров гораздо удобнее.