Господа, ищу общее решение для "безотказного" почтового сервера (принципиальное).Есть 2 канала в Интернет, две различных белые подсети от двух провайдеров.
Внутри сети почтовый сервер за NAT, с именем mail.domain.tld и серым адресом.
Есть 2 МХ записи типа (в общем виде, естественно)
domain.tld 5 IP1 (provider1) mail.domain.tld
domain.tld 10 IP2 (provider2) mail1.domain.tld
и, естественно, соответствующие прямые A и реверсные ДНС записи у провайдеров.Шлюз автоматически переходит с основного провайдера на резервного при падении основного и при восстановлении связи возвращается на основной. Возможно, появится и третий провайдер с третьим адресом. AS в ближайшие годы не будет.
При переходе между провайдерами я вынужден переписывать hostname почтового сервера с mail на mail1, дабы HELO/EHLO проходило корректно. В перспективе (включение TLS) придется еще и менять сертификаты.
Может быть, кто-нибудь подскажет более элегантную схему организации безотказного почтовика? Буду благодарен за любую идею.
> Господа, ищу общее решение для "безотказного" почтового сервера (принципиальное).
> Есть 2 канала в Интернет, две различных белые подсети от двух провайдеров.вот тут поползли тараканы ... начали про сервер и резко перешли к каналам - причем тут сервер спрашивается?
>[оверквотинг удален]
> mail.domain.tld
> domain.tld 10 IP2 (provider2) mail1.domain.tld
> и, естественно, соответствующие прямые A и реверсные ДНС записи у провайдеров.
> Шлюз автоматически переходит с основного провайдера на резервного при падении основного
> и при восстановлении связи возвращается на основной. Возможно, появится и третий
> провайдер с третьим адресом. AS в ближайшие годы не будет.
> При переходе между провайдерами я вынужден переписывать hostname почтового сервера с mail
> на mail1, дабы HELO/EHLO проходило корректно. В перспективе (включение TLS) придется
> еще и менять сертификаты.
> Может быть, кто-нибудь подскажет более элегантную схему организации безотказного почтовика?еще раз спрошу причем тут вообще _безотказность_ _почтовика_?
> Буду благодарен за любую идею.идЭя:
1) прописать одинаковые реверсы на оба паблика - mail.domain.tld
2) прямую зону держать у себя, сделать низкий TTL в двух вариантах
3) мониторить падение канала и автоматом подставлять нужную зону в ДНС сервер
> идЭя:
> 1) прописать одинаковые реверсы на оба паблика - mail.domain.tldДавольно часто принимающая сторона хочет чтобы обратный резолв соответствовал прямому, иначе - до свидания.
>> Господа, ищу общее решение для "безотказного" почтового сервера (принципиальное).
>> Есть 2 канала в Интернет, две различных белые подсети от двух провайдеров.
> вот тут поползли тараканы ... начали про сервер и резко перешли кБезотказный сервер при том, что 250-300 клиентов внутренней сети могут и отправлять, и получать почту при падении основного интернет канала без необходимости переходить на другой (внутренний же) почтовый сервер.
> еще раз спрошу причем тут вообще _безотказность_ _почтовика_?
Еще раз отвечу - если у Вас линуксовый почтовик падает хоть раз в год - значит, это кривые руки (кривое железо, поставленное этими руками). Мое понимание безотказности я изложил чуть выше - который работает без AS на 2-3 внешних адресах с малым (менее 3 минут) простоем на приеме/отправке внешней почты при переключении каналов.
>> Буду благодарен за любую идею.
> идЭя:
> 1) прописать одинаковые реверсы на оба паблика - mail.domain.tldРеверсы возможно, а в прямой зоне ДНС что - два одинаковых имени с разными адресами? Или расщепленный ДНС? Чего-то либо я, либо Вы не понимаете...
> 2) прямую зону держать у себя, сделать низкий TTL в двух вариантахКеширование ДНС у тех, кто почту мне снаружи отсылает, тоже отключить?
> 3) мониторить падение канала и автоматом подставлять нужную зону в ДНС серверВремя распространения информации снаружи (обновления кешей чужих ДНС серверов), как считаете, сколько продлится? Канал-то и так мониторится...
>>> Господа, ищу общее решение для "безотказного" почтового сервера (принципиальное).
>>> Есть 2 канала в Интернет, две различных белые подсети от двух провайдеров.
>> вот тут поползли тараканы ... начали про сервер и резко перешли к
> Безотказный сервер при том, что 250-300 клиентов внутренней сети могут и отправлять,
> и получать почту при падении основного интернет канала без необходимости переходить
> на другой (внутренний же) почтовый сервер.При таком маштабе LAN заведите себе два сервера - благо несколько MX записей предусмотрено ... а дальше настраивайте меж ними пересылку как вам угодно.
>> еще раз спрошу причем тут вообще _безотказность_ _почтовика_?
> Еще раз отвечу - если у Вас линуксовый почтовик падает хоть раз
> в год - значит, это кривые руки (кривое железо, поставленное этими
> руками). Мое понимание безотказности я изложил чуть выше - который работает
> без AS на 2-3 внешних адресах с малым (менее 3 минут)
> простоем на приеме/отправке внешней почты при переключении каналов.еще ращ сервер есть сервер, когда вы об этом говорите (говорите что он почтовый) подразумевается устойчивость СЕРВИСА, а не органиция канала типа мультихоум. Мух от котлет отделяйте.
>>> Буду благодарен за любую идею.
>> идЭя:
>> 1) прописать одинаковые реверсы на оба паблика - mail.domain.tld
> Реверсы возможно, а в прямой зоне ДНС что - два одинаковых имени
> с разными адресами? Или расщепленный ДНС? Чего-то либо я, либо Вы
> не понимаете...вот я про пряму зону как раз и пишу, да никто не чЕтает ))
обнаружил что канал упал - выставил нужную прямую зону, поднялся основной - вернул предыдущую.>> 2) прямую зону держать у себя, сделать низкий TTL в двух вариантах
> Кеширование ДНС у тех, кто почту мне снаружи отсылает, тоже отключить?строку до конца до читать попробуйте. (про ТТЛ)
>> 3) мониторить падение канала и автоматом подставлять нужную зону в ДНС сервер
> Время распространения информации снаружи (обновления кешей чужих ДНС серверов), как считаете,
> сколько продлится? Канал-то и так мониторится...см №2
> При таком маштабе LAN заведите себе два сервера - благо несколько MX
> записей предусмотрено ... а дальше настраивайте меж ними пересылку как вам
> угодно.И много Вы видели виндовых клиентов, которые не хотели бы чихать на TTL DNS-записи?
Половина клиентов сидит через IMAP. Даже если я TTL на внутреннем DNS 5 секунд поставлю, до перезагрузки клиентского компа или исправления ошибок сетевого соединения ничего не проиизойдет у них, увы. Это ж не циска...
Хотя Виндовый ДНС я никогда не ставил - может, его TTL они понимают. Но не поставлю.
> еще ращ сервер есть сервер, когда вы об этом говорите (говорите что
> он почтовый) подразумевается устойчивость СЕРВИСА, а не органиция канала типа мультихоум.
> Мух от котлет отделяйте.Хорошо, слова "Почтовый сервис" Вас устроят? К устойчивости почтового сервера на Linux у не нищих людей с прямыми руками претензий нет. Время простоя сервиса я определяю как время простоя процессов MTA+MDA (малозначимое у меня) плюс время переключения между внешними каналами провайдеров при падении основного канала (не более 1 минуты).
ПОЛЬЗОВАТЕЛИ же почему-то считают, что время простоя - это время от момента начала падения/временного сбоя основного провайдера до момента, когда письмо из Германии, Италии, с Тайваня, из Турции, из Новосибирска или Иркутска, в этот или следующий момент отправленное, до них дойдет.При чем здесь мультихоум? Я же не о способе его организации вопросы задаю, он уже создан и работает, претензий к нему нет. Я лишь для понимания структуры сети, в которой мой почтовый сервис работает, это написал. И все, кроме Вас, похоже, это поняли...
>[оверквотинг удален]
>> Реверсы возможно, а в прямой зоне ДНС что - два одинаковых имени
>> с разными адресами? Или расщепленный ДНС? Чего-то либо я, либо Вы
>> не понимаете...
> вот я про пряму зону как раз и пишу, да никто не
> чЕтает ))
> обнаружил что канал упал - выставил нужную прямую зону, поднялся основной -
> вернул предыдущую.
>>> 2) прямую зону держать у себя, сделать низкий TTL в двух вариантах
>> Кеширование ДНС у тех, кто почту мне снаружи отсылает, тоже отключить?
> строку до конца до читать попробуйте. (про ТТЛ)Да у ряда идиотов из Италии по неделе проходит до того, как они изменение записей на ns3.nic.ru c TTL 3600 секунд у себя увидят. КАК это у них получается - я до сих пор понять не могу, но факт есть факт... И это корень зоны ru. Подумать страшно, сколько времени они прочухивать изменения в глубине зоны ru будут... Да и турки в этом плане хороши изрядно.
Плюс изменение файла зоны 4 часа на nic.ru занимает. А держать DNS у себя - я не в провайдере работаю с собственной AS, а на производственной фирме, и приоритеты несколько другие, и доступность моего ДНС пониже будет.Поэтому смена DNS записей, увольте, не пойдет. Записи должны быть УЖЕ распространены и закешированы всеми адиетами мира...
подымите запасной мх на сторонней площадку, например у провайдера.
> подымите запасной мх на сторонней площадку, например у провайдера.Поднять не проблема. Как мне внутренних клиентов, в том числе IMAP, переводить с одного сервера на другой при отказе канала, если учесть, что у них на клиентах Винда и маршруты закешированы?
Понятно, что я мог бы и 2 почтовых сервера внутри локалки поднять, с нужными именами, и каждому дать по внешнему адресу от разных провайдеров, но вот переключение 250-300 клиентов с почтовика на почтовик...
>[оверквотинг удален]
> domain.tld 10 IP2 (provider2) mail1.domain.tld
> и, естественно, соответствующие прямые A и реверсные ДНС записи у провайдеров.
> Шлюз автоматически переходит с основного провайдера на резервного при падении основного
> и при восстановлении связи возвращается на основной. Возможно, появится и третий
> провайдер с третьим адресом. AS в ближайшие годы не будет.
> При переходе между провайдерами я вынужден переписывать hostname почтового сервера с mail
> на mail1, дабы HELO/EHLO проходило корректно. В перспективе (включение TLS) придется
> еще и менять сертификаты.
> Может быть, кто-нибудь подскажет более элегантную схему организации безотказного почтовика?
> Буду благодарен за любую идею.Exim можно настроить так что бы он менял сам свое helo в зависимости от интерфейса с которого он производит подключение. Думаю можно что-то придумать и с tls.
С утра больше никаких идей не приходит в голову.
>>[оверквотинг удален]
> Exim можно настроить так что бы он менял сам свое helo в
> зависимости от интерфейса с которого он производит подключение. Думаю можно что-то
> придумать и с tls.
> С утра больше никаких идей не приходит в голову.Ну я на postfix-е через postconf -e myhostname = mail|mail1.domain.tld это делаю при переходе между каналами. Но вопрос не просто в том, как это сделать, а в том, как это сделать более ЭЛЕГАНТНО...
Собственно, я создал эту тему, потому что казалось, что я зашорился на своем решении и более простого/элегантного/разумного решения не вижу.
>[оверквотинг удален]
> domain.tld 10 IP2 (provider2) mail1.domain.tld
> и, естественно, соответствующие прямые A и реверсные ДНС записи у провайдеров.
> Шлюз автоматически переходит с основного провайдера на резервного при падении основного
> и при восстановлении связи возвращается на основной. Возможно, появится и третий
> провайдер с третьим адресом. AS в ближайшие годы не будет.
> При переходе между провайдерами я вынужден переписывать hostname почтового сервера с mail
> на mail1, дабы HELO/EHLO проходило корректно. В перспективе (включение TLS) придется
> еще и менять сертификаты.
> Может быть, кто-нибудь подскажет более элегантную схему организации безотказного почтовика?
> Буду благодарен за любую идею.Как я понял, вам нужна схема, при которой не нужно менять настройки МТА при смене канала. Элегантно - это, таки, AS :)
В порядке филосовских размышлений:
Вы можете настроить ваш MTA таким образом, чтобы он слал почту с разных source_IP, выбирая их, например, случайным образом, которые на шлюзе будут натиться в соответствующие IP-адреса выданные провайдерами. При этом конфигурация МТА будет статичной, но нужно будет как-то сообщать MTA что какой-то из каналов лёг и не нужно использовать соответствующий source_IP для отправки.
>>[оверквотинг удален]
> Как я понял, вам нужна схема, при которой не нужно менять настройки
> МТА при смене канала. Элегантно - это, таки, AS :)Вы абсолютно правы. Esse homo!
> В порядке филосовских размышлений:
> Вы можете настроить ваш MTA таким образом, чтобы он слал почту с
> разных source_IP, выбирая их, например, случайным образом, которые на шлюзе будут
> натиться в соответствующие IP-адреса выданные провайдерами. При этом конфигурация МТА
> будет статичной, но нужно будет как-то сообщать MTA что какой-то из
> каналов лёг и не нужно использовать соответствующий source_IP для отправки.К сожалению, проблема не внутри, а снаружи локальной сети. MTA и так уже имеет информацию о текущем внешнем роутинге (файлик на FTP в локалке содержит эту информацию и обновляется роутером при смене маршрута).
Но необходимости переписывать HELO/EHLO в соответствии с (новым)именем хоста почтовика (имена ведь разные по разным внешним адресам/маршрутам) это не отменяет. Возможно, я не вполне понял, что имеется в виду под статичной конфигурацией MTA. Попытаться сделать HELO/EHLO динамически (скриптом)?Весьма похоже, что без AS и динамической маршрутизации ничего не выйдет.
>[оверквотинг удален]
>> натиться в соответствующие IP-адреса выданные провайдерами. При этом конфигурация МТА
>> будет статичной, но нужно будет как-то сообщать MTA что какой-то из
>> каналов лёг и не нужно использовать соответствующий source_IP для отправки.
> К сожалению, проблема не внутри, а снаружи локальной сети. MTA и так
> уже имеет информацию о текущем внешнем роутинге (файлик на FTP в
> локалке содержит эту информацию и обновляется роутером при смене маршрута).
> Но необходимости переписывать HELO/EHLO в соответствии с (новым)именем хоста почтовика
> (имена ведь разные по разным внешним адресам/маршрутам) это не отменяет. Возможно,
> я не вполне понял, что имеется в виду под статичной конфигурацией
> MTA. Попытаться сделать HELO/EHLO динамически (скриптом)?Возможно я не вполне корректно применил слово "статичный". Конечно, так как в вашей схеме при смене маршрута меняется IP-адрес с которого почта уходит во внешний мир, то полностью исключть обмен информацией между роутером и МТА невозможно. Однако можно свести к минимуму число меняющихся параметров МТА при смене маршрута, вплоть до изменения одного флага в SQL-табличке. Слегка погуглив я обнаружил, что в postfix пожно сделать то о чём я писал в своих "философских" рассуждениях:
master.cf
Create different Interfaces. One for each domain:
rotate1 unix - - n - - smtp
-o syslog_name=postfix-rotate1
-o smtp_helo_name=domainone.com.br
-o smtp_bind_address=173.111.111.1rotate2 unix - - n - - smtp
-o syslog_name=postfix-rotate2
-o smtp_helo_name=domaintwo.com.br
-o smtp_bind_address=173.111.111.2main.cf
Disable all other transport maps, i.e.: # transport_maps = xxxxx
Enable dependent transport map (require postfix 2.7.x or later)
sender_dependent_default_transport_maps = mysql:/etc/postfix/config/transport_random_dependent.cf
transport_random_dependent.cf
Example:
user = postfix
password = mypassword
dbname = postfixdb
hosts = localhost
query = SELECT transport FROM transport_random WHERE domain = '%d' AND status='1' ORDER BY RAND() LIMIT 1Table transport_random
Column "transport" = rotate1, rotate2, rotate3, rotate4 (etc)
Column "domain" = sender domains (replaced by %d)
Column "status" = boolean (0 or 1) if is enabled the transport.The instruction "RAND() LIMIT 1" is necessary only if you want to use random transports for the same domain.
In example, you want to send from mydomain.com from 3 different IPs.
Then, you create 3 transports (rotate1, rotate2 and rotate3) with 3 different IPs, then set at mysql lines:
transport = rotate1 | domain = mydomain.com
transport = rotate2 | domain = mydomain.com
transport = rotate3 | domain = mydomain.comThen, when postfix will randomize three different transports (rotate one to three) to send this emails.
Моя мысль была следующей: МТА для отправки почты всегда использует все имеющиеся каналы, перебирая их случайным образом. В таком случае нет вопроса о переключении канала (смене настроек МТА) - есть вопрос использовать или не использовать данный канал. Если какой-то из каналов лёг, роутер должен сообщить МТА об этом, чтобы тот перестал его использовать. Так вот, если мой английский меня не подводит, кусок конфига приведённый выше как раз и намекает на возможность реализации данной схемы работы. Чтобы исключить транспорт (канал) из списка используемых нужно просто полю status в таблице transport_random присвоить значение 0. В идеале роутер по ssh с авторизацией по ключам заходит на хост с СУБД, которую использует МТА и дёргает SQL-скрипт. Достаточно элегантно? Понятно, что с AS не сравнится, но при данной структуре сети выглядит весьма не плохо :)
Всё выше сказанное - на правах "философских рассуждений" так как эксперементального стенда нет. Просто задача интересная. :)
>[оверквотинг удален]
> МТА об этом, чтобы тот перестал его использовать. Так вот, если
> мой английский меня не подводит, кусок конфига приведённый выше как раз
> и намекает на возможность реализации данной схемы работы. Чтобы исключить транспорт
> (канал) из списка используемых нужно просто полю status в таблице transport_random
> присвоить значение 0. В идеале роутер по ssh с авторизацией по
> ключам заходит на хост с СУБД, которую использует МТА и дёргает
> SQL-скрипт. Достаточно элегантно? Понятно, что с AS не сравнится, но при
> данной структуре сети выглядит весьма не плохо :)
> Всё выше сказанное - на правах "философских рассуждений" так как эксперементального стенда
> нет. Просто задача интересная. :)Спасибо! Весьма элегантный вариант. Вот как всегда - смотришь в main.cf, а про master.cf забываешь... И оказываешься в плену собственной (узкой) специализации.
В моем случае есть ряд усложняющих деталей - alias_maps в LDAP, связка dbmail+mysql в качестве POP3/IMAP сервера/хранилища почты и т.п. То есть на transport_maps возлагается некая смысловая нагрузка. Но это уже проблемы технические, а не принципиальные.
В ближайшие дни попробую на резервном сервере, и если все пойдет - отпишусь и и далее буду использовать в продакшене. Реально заманчивый вариант, еще раз спасибо.
P.S.Еще вероятно попробую выбрать изменяемый default transport вида
* transport:rotate1|rotate2
в таблице transport_maps=hash:/etc/postfix/transport
c изменениями в master.cf из Вашего примера выше. Это бы должно и на более старых версиях postfix работать.
> В ближайшие дни попробую на резервном сервере, и если все пойдет -
> отпишусь и и далее буду использовать в продакшене.Даже если не пойдёт - всё равно отпишитесь почему не пошло.
> Даже если не пойдёт - всё равно отпишитесь почему не пошло.Обязательно, тема-то достаточно веселая, и, думаю, актуальная. Еще раз спасибо за идею.
>> Даже если не пойдёт - всё равно отпишитесь почему не пошло.
> Обязательно, тема-то достаточно веселая, и, думаю, актуальная. Еще раз спасибо за идею.Удалось попробовать данную схему? Каковы результаты?
> При переходе между провайдерами я вынужден переписывать hostname почтового сервера с mail
> на mail1, дабы HELO/EHLO проходило корректно. В перспективе (включение TLS) придется
> еще и менять сертификаты.AFAIK, HELO и реверс могут не совпадать, и это корректно. Ткните, если не прав, желательно с примерами.
Сертификат, AFAIK, опять же не обязан совпадать с CN сертификата, но тут я могу и ошибаться.
>> При переходе между провайдерами я вынужден переписывать hostname почтового сервера с mail
>> на mail1, дабы HELO/EHLO проходило корректно. В перспективе (включение TLS) придется
>> еще и менять сертификаты.
> AFAIK, HELO и реверс могут не совпадать, и это корректно. Ткните, если
> не прав, желательно с примерами.Если на почтовом сервере получателя стоит strict RFC822 check (postfix), то результат реверсного ДНС запроса должен соответствовать имени в HELO/EHLO сервера-отправителя письма. Этим может пренебречь администратор при настройке, но может и нет. Получается самое худшее - до кого-то не доходит, причем внезапно... Или некоторое время все нормально, а потом бамс - и почта старому клиенту не идет - а там админа сменили...
> Сертификат, AFAIK, опять же не обязан совпадать с CN сертификата, но тут
> я могу и ошибаться.Тут я тоже точно не знаю - с TLS не работал пока. Но в принципе сертификат должен включать имя хоста для MX.
> Если на почтовом сервере получателя стоит strict RFC822 check (postfix), то результат
> реверсного ДНС запроса должен соответствовать имени в HELO/EHLO сервера-отправителя
>письма.
> Этим может пренебречь администратор при настройке, но может и нет.Что-то вы фантазируете. Приведите пожалуйста опцию postfix, которая включает такое поведение? Я пока в документации такого не нашел.
Равно как и RFC822 ничего подобного не описывает.
>> Если на почтовом сервере получателя стоит strict RFC822 check (postfix), то результат
>> реверсного ДНС запроса должен соответствовать имени в HELO/EHLO сервера-отправителя
>>письма.
>> Этим может пренебречь администратор при настройке, но может и нет.
> Что-то вы фантазируете. Приведите пожалуйста опцию postfix, которая включает такое поведение?
> Я пока в документации такого не нашел.
> Равно как и RFC822 ничего подобного не описывает.Sorry, strict_rfc821_envelopes = yes
ОписАлся. Помню, что параметр похожий есть. Вечно путаю RFC820/821/822 - cтарость не радость...
> Еще раз отвечу - если у Вас линуксовый почтовик падает хоть раз в год - значит, это кривые руки (кривое железо, поставленное этими руками).та вы шо, а у вас никогда ничего не ломается? Или вы работаете в параллельной вселенной или что то не договариваете. 100% аптайма это фантастика сыночек :D
> AFAIK, HELO и реверс могут не совпадать, и это корректно.
и не должны, но при использовании reject_unknown_client_hostname будут реджекты
>> Еще раз отвечу - если у Вас линуксовый почтовик падает хоть раз в год - значит, это кривые руки (кривое железо, поставленное этими руками).
> та вы шо, а у вас никогда ничего не ломается? Или вы
> работаете в параллельной вселенной или что то не договариваете. 100% аптайма
> это фантастика сыночек :DПопробуйте как-нибудь наняться на работу, где за 1 час простоя главных сервисов (в том числе и почты) по Вашей вине Ваша зарплата уменьшится на 800 зеленых - будете сильно удивлены результатом.
Ломается, конечно, вот в этом году райд на 12 ТБ вскипятили из-за аварии кондиционера - три диска сдохли в райде 6 при норме 2, но восстановили со свежего бекапа, и ничего.
Никто не говорит про 100% аптайма, есть 5-10 дней в году, когда встает производство и можно производить апдейт. Но в остальные дни 24 часа в сутки - это святое.
Почтовик, кстати, на обычной рабочей станции вот уже 5 лет работает исправно, при примерно 170 ГБ почты сейчас.
Тестировать железо надо перед сдачей в эксплуатацию, и ОС/приложения корректно настраивать, а не рассказывать владельцам, что все горит и дохнет. Ну либо руки на рельсе прямить.>> AFAIK, HELO и реверс могут не совпадать, и это корректно.
> и не должны, но при использовании reject_unknown_client_hostname будут реджекты
> Попробуйте как-нибудь наняться на работу, где за 1 час простоя главных сервисов
> (в том числе и почты) по Вашей вине Ваша /зарплата/ оплата за ближайший месяц >уменьшится на 800 зеленых - будете сильно удивлены результатом.
> Попробуйте как-нибудь наняться на работу, где за 1 час простоя главных сервисов
> (в том числе и почты) по Вашей вине Ваша зарплата уменьшится
> на 800 зеленых - будете сильно удивлены результатом.
> Никто не говорит про 100% аптайма, есть 5-10 дней в году, когда
> встает производство и можно производить апдейт. Но в остальные дни 24
> часа в сутки - это святое.за 5 дней в году меня бы уже давно уволили ;)
> Ломается, конечно, вот в этом году райд на 12 ТБ вскипятили из-за
> аварии кондиционера - три диска сдохли в райде 6 при норме
> 2, но восстановили со свежего бекапа, и ничего.а вот за такой бок надо было бы штраф впаять, что рабочая температура не отслеживается. У меня за такими вещами следит nagios и в случае чего приходит sms.
> Почтовик, кстати, на обычной рабочей станции вот уже 5 лет работает исправно,
> при примерно 170 ГБ почты сейчас. Тестировать железо надо перед сдачей в эксплуатацию, > и ОС/приложения корректно настраивать, а не рассказывать владельцам, что все горит и дохнет.ну смешно же читать. Сегодня память полностью рабочая, а через час сгорит. Тоже касается и всех других компонентов - hdd, video, cpu, etc ... О каком таком тестировании/настройке вы говорите? Может я чего то не знаю или пропустил?
> за 5 дней в году меня бы уже давно уволили ;)Опять передержки. Можно обновлять софт и т.д. в дни простоя, которых 5-10 в год (год на год не приходится). Компания торгово-производственная, а не провайдер.
> а вот за такой бок надо было бы штраф впаять, что рабочая
> температура не отслеживается. У меня за такими вещами следит nagios и
> в случае чего приходит sms.Блиин, вот круто! Предупреждение у Вас само останавливает сервер? Или кондиционер в чужой серверной ремонтирует и включает? Или Вас телепортирует на 120 км до места происшествия, попутно дезавуируя охрану здания в выходной? Бога ради, не пересказывайте общие места. Zabbix у меня, но результат не сильно отличается...
>> Почтовик, кстати, на обычной рабочей станции вот уже 5 лет работает исправно,
>> при примерно 170 ГБ почты сейчас. Тестировать железо надо перед сдачей в эксплуатацию, > и ОС/приложения корректно настраивать, а не рассказывать владельцам, что все горит и дохнет.
> ну смешно же читать. Сегодня память полностью рабочая, а через час сгорит.
> Тоже касается и всех других компонентов - hdd, video, cpu, etc
> ... О каком таком тестировании/настройке вы говорите? Может я чего то
> не знаю или пропустил?Смейтесь, смейтесь...
Диски в райдах меняются превентивно, через 2-3 года эксплуатации, не дожидаясь выхода по смарту, и закупаются партиями по 10 при потребности 8. Райд 6, никаких 10/50/60. Остальное просто до одурения. Берется системный блок, разгоняется до максимума по частоте (процессор и память), ставится в тумбочку (термошкаф самодельный, не в серверной), грузится на 2 суток. Если все в порядке (нет ни одного сбоя) - возвращаются стандартные частоты и отдается в продакшен. Для особо важных случаев - делается 20-30 внезапных отключений питания под нагрузкой. Естественно, это для наколенных "серверов". Нормальное серверное железо этого не требует. Там методики другие.
> Опять передержки. Можно обновлять софт и т.д. в дни простоя, которых 5-10
> в год (год на год не приходится). Компания торгово-производственная, а не
> провайдер.ну тут вам виднее, у нас простой 15-30 минут это уже абзац полный (не провайдер)
> Блиин, вот круто! Предупреждение у Вас само останавливает сервер? Или кондиционер в
> чужой серверной ремонтирует и включает? Или Вас телепортирует на 120 км
> до места происшествия, попутно дезавуируя охрану здания в выходной? Бога ради,
> не пересказывайте общие места. Zabbix у меня, но результат не сильно
> отличается...это дает мне возможность зайти удаленно и остановить сервер, не доводя его до развала рейда, сжигание матери и т.п. ;) Или у вас простой 10-16 часов, пока будет восстанавливаться рейд на 10-15 Тб, считается нормальным?
> Диски в райдах меняются превентивно, через 2-3 года эксплуатации, не дожидаясь выхода
> по смарту, и закупаются партиями по 10 при потребности 8.и зря, имхо. Сколько раз видел, что винт с 10k часов намного надежнее абсолютно нового, которые часто сыпятся в первые 2-3 месяца работы. И никакие тесты тут не помогут.
> Райд 6, никаких 10/50/60.
а что 6ка это панацея? Я видел как и 3-4 диска в полке одновременно вылетали.
> Остальное просто до одурения. Берется системный блок, разгоняется
> до максимума по частоте (процессор и память), ставится в тумбочку (термошкаф
> самодельный, не в серверной), грузится на 2 суток. Если все в
> порядке (нет ни одного сбоя) - возвращаются стандартные частоты и отдается
> в продакшен. Для особо важных случаев - делается 20-30 внезапных отключений
> питания под нагрузкой. Естественно, это для наколенных "серверов". Нормальное серверное
> железо этого не требует. Там методики другие.мдаа, ну что тут скажешь :)
> это дает мне возможность зайти удаленно и остановить сервер, не доводя его
> до развала рейда, сжигание матери и т.п. ;) Или у вас
> простой 10-16 часов, пока будет восстанавливаться рейд на 10-15 Тб, считается
> нормальным?И как быстро остановить получается? При серверной 8м2 с тепловыделением 5-6 кВт и отказе кондиционера температура взлетает до ташкента за 15-20 минут максимум. И не факт, что канальное оборудование от провайдера не упадет раньше серверов. А проснуться от SMS в 3 часа утра быстрее, чем за 20 минут у меня, как правило, не выходит - старость не радость.
Но райд резервированный по-любому, там файлопомойка, резервный по данным от него отстает на 15-30 минут, только сам помедленнее несколько. Вот если оба в двух разных серверных улетят - тогда точно беда.>> Диски в райдах меняются превентивно, через 2-3 года эксплуатации, не дожидаясь выхода
>> по смарту, и закупаются партиями по 10 при потребности 8.
> и зря, имхо. Сколько раз видел, что винт с 10k часов намного
> надежнее абсолютно нового, которые часто сыпятся в первые 2-3 месяца работы.
> И никакие тесты тут не помогут.А что за винты такие? Неперегретые и сыплются в первые 2-3 месяца? И было менее месяца тестирования вне серверной до продакшена? За последних 5 лет я таких точно не встречал, хотя при тестировании кое-что и падало. Хотя Сигейтами SAS/SATA не пользуюсь, WD SATA, Hitachi SAS, IBM SCSI - может, в этом дело? Или Вы 15К оборотов используете? Они, в отличие от 10К, за час перегрева максимум дохнут, а 10К сутки стоят в серверных корпусах...
>> Райд 6, никаких 10/50/60.
> а что 6ка это панацея? Я видел как и 3-4 диска в
> полке одновременно вылетали.Без перегрева? Не, пока бог миловал...
Ну насчет 60 райда я загнул, однозначно. Но 10 и 5 давно не держу. 50, наверное, тоже имеет право на жизнь, но лично я ставить его у себя не буду. Просто полок больше 16 винтов у меня нет пока, да и в них обычно 8+8 райды раздельные использую.
Хотя знакомец мой пользует исключительно 5 райды по 3+1spare диска, но у него больше 150 точек и время прибытия техподдержки 20-24 часа...
Но вообще от вылета 3-4 дисков из 8 по определению спасти нечего не может, кроме везения и drbd, etc...
>> Остальное просто до одурения. Берется системный блок, разгоняется
>> до максимума по частоте (процессор и память), ставится в тумбочку (термошкаф
>> самодельный, не в серверной), грузится на 2 суток. Если все в
>> порядке (нет ни одного сбоя) - возвращаются стандартные частоты и отдается
>> в продакшен. Для особо важных случаев - делается 20-30 внезапных отключений
>> питания под нагрузкой. Естественно, это для наколенных "серверов". Нормальное серверное
>> железо этого не требует. Там методики другие.
> мдаа, ну что тут скажешь :)
> И как быстро остановить получается? При серверной 8м2 с тепловыделением 5-6 кВт
> и отказе кондиционера температура взлетает до ташкента за 15-20 минут максимум.
> И не факт, что канальное оборудование от провайдера не упадет раньше
> серверов. А проснуться от SMS в 3 часа утра быстрее, чем
> за 20 минут у меня, как правило, не выходит - старость
> не радость.
> Но райд резервированный по-любому, там файлопомойка, резервный по данным от него отстает
> на 15-30 минут, только сам помедленнее несколько. Вот если оба в
> двух разных серверных улетят - тогда точно беда.у меня было всего один раз, серверная 2x3м полный пипец без кондера там наступает за час. Вырубание 5ти из 6ти серверов, оставил только роутер, очень даже помогло ;)
> А что за винты такие? Неперегретые и сыплются в первые 2-3 месяца?
> И было менее месяца тестирования вне серверной до продакшена? За последних
> 5 лет я таких точно не встречал, хотя при тестировании кое-что
> и падало. Хотя Сигейтами SAS/SATA не пользуюсь, WD SATA, Hitachi SAS,
> IBM SCSI - может, в этом дело? Или Вы 15К оборотов
> используете? Они, в отличие от 10К, за час перегрева максимум дохнут,
> а 10К сутки стоят в серверных корпусах...да разные - SAS/SATA, 10/15K, Seagate/Hitachi/WD. Нет прямой корреляции, по крайней мере я ее не нашел
> Без перегрева? Не, пока бог миловал...
> Ну насчет 60 райда я загнул, однозначно. Но 10 и 5 давно
> не держу. 50, наверное, тоже имеет право на жизнь, но лично
> я ставить его у себя не буду. Просто полок больше 16
> винтов у меня нет пока, да и в них обычно 8+8
> райды раздельные использую.
> Хотя знакомец мой пользует исключительно 5 райды по 3+1spare диска, но у
> него больше 150 точек и время прибытия техподдержки 20-24 часа...
> Но вообще от вылета 3-4 дисков из 8 по определению спасти нечего
> не может, кроме везения и drbd, etc...без конечно, полка стояла в серверной, там 10-15 градусов, 10 или 16 sas винтов, уже не припомню. Наши все админы в шоке тогда были, что сразу 4 винта умерло. Пришлось доставать из бекапов
P.S.
это все демагогия. А по сабжу, postfix к сожалению плохо умеет дружить с такими моментами, как замена helo в зависимости от интерфейса и т.п. Например, он не умеет менять приветствие, которое smtp helo geeting. Я бы посмотрел в сторону exim, там все намного проще в этом плане.
> мдаа, ну что тут скажешь :)просто перестань кормить тролля!
>> AFAIK, HELO и реверс могут не совпадать, и это корректно.
> и не должны, но при использовании reject_unknown_client_hostname будут реджектыС каких это пор reject_unknown_client_hostname что-то делает с HELO ?
>>> AFAIK, HELO и реверс могут не совпадать, и это корректно.
>> и не должны, но при использовании reject_unknown_client_hostname будут реджекты
> С каких это пор reject_unknown_client_hostname что-то делает с HELO ?В smtpd_helo_restrictions можно применять ограничения для smtpd_client_restrictions
http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions
И медленно проматываем до фразы:
Other restrictions that are valid in this context:
Generic restrictions that can be used in any SMTP command context, described under smtpd_client_restrictions.
>>>> AFAIK, HELO и реверс могут не совпадать, и это корректно.
>>> и не должны, но при использовании reject_unknown_client_hostname будут реджекты
>> С каких это пор reject_unknown_client_hostname что-то делает с HELO ?
> В smtpd_helo_restrictions можно применять ограничения для smtpd_client_restrictions
> http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions
> И медленно проматываем до фразы:
> Other restrictions that are valid in this context:
> Generic restrictions that can be used in any SMTP command context, described
> under smtpd_client_restrictions.Ну валидно их использовать в этой фазе проверок (контексте), ну и что?
Рестрикшены от этого "точку приложения усилий" не меняют.
Если вы пропишете reject_unknown_client_hostname в smtpd_helo_restrictions, то оно как проверяло client_hostname, так его (а не HELO) и будет проверять.Вы же в smtpd_helo_restrictions используете
check_helo_access
check_helo_mx_access
check_helo_ns_access
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_rhsbl_helo
reject_unknown_helo_hostnameа не
check_client_access
check_client_mx_access
check_client_ns_access
reject_rhsbl_client
reject_unknown_client_hostnameкоторые по-вашему в smtpd_helo_restrictions берут, и HELO проверяют.
Прошу отдельно отметить reject_unknown_helo_hostname.
Промотаю документацию чуть вверх и сцитирую, специально для читающих по-диагонали:reject_unknown_helo_hostname (with Postfix < 2.3: reject_unknown_hostname)
Reject the request when the HELO or EHLO hostname has no DNS A or MX record.
The unknown_hostname_reject_code parameter specifies the numerical response code for rejected requests (default: 450).
The unknown_helo_hostname_tempfail_action parameter specifies the action after a temporary DNS error (default: defer_if_permit).Нет ни одного слова про то, что оно обязано совпадать с client hostname, реверсом, и т п.
>[оверквотинг удален]
> reject_non_fqdn_helo_hostname
> reject_rhsbl_helo
> reject_unknown_helo_hostname
> а не
> check_client_access
> check_client_mx_access
> check_client_ns_access
> reject_rhsbl_client
> reject_unknown_client_hostname
> которые по-вашему в smtpd_helo_restrictions берут, и HELO проверяют.Здесь вы, безусловно, правы. Я был невнимателен и поторопился с ответом.
>[оверквотинг удален]
> Промотаю документацию чуть вверх и сцитирую, специально для читающих по-диагонали:
> reject_unknown_helo_hostname (with Postfix < 2.3: reject_unknown_hostname)
> Reject the request when the HELO or EHLO hostname has no DNS
> A or MX record.
> The unknown_hostname_reject_code parameter specifies the numerical response code for
> rejected requests (default: 450).
> The unknown_helo_hostname_tempfail_action parameter specifies the action after a temporary
> DNS error (default: defer_if_permit).
> Нет ни одного слова про то, что оно обязано совпадать с client
> hostname, реверсом, и т п.rfc2821 вообще запрещает блокировать из-за подобных причин:
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only.
>[оверквотинг удален]
> Промотаю документацию чуть вверх и сцитирую, специально для читающих по-диагонали:
> reject_unknown_helo_hostname (with Postfix < 2.3: reject_unknown_hostname)
> Reject the request when the HELO or EHLO hostname has no DNS
> A or MX record.
> The unknown_hostname_reject_code parameter specifies the numerical response code for
> rejected requests (default: 450).
> The unknown_helo_hostname_tempfail_action parameter specifies the action after a temporary
> DNS error (default: defer_if_permit).
> Нет ни одного слова про то, что оно обязано совпадать с client
> hostname, реверсом, и т п.Однако, ошибки доставки вида
server refused to talk to me: 550 Reverse DNS lookup failed for host ip.ad.dre.ss (port 25)
если HELO/EHLO не совпадает с reverse DNS query, к сожалению, реальность.В то же время RFC1123 гласит:
5.2.5 HELO Command: RFC-821 Section 3.5The sender-SMTP MUST ensure that the <domain> parameter in a
HELO command is a valid principal host domain name for the
client host. As a result, the receiver-SMTP will not have to
perform MX resolution on this name in order to validate the
HELO parameter.The HELO receiver MAY verify that the HELO parameter really
Internet Engineering Task Force [Page 50]
RFC1123 MAIL -- SMTP & RFC-822 October 1989
corresponds to the IP address of the sender. However, the
receiver MUST NOT refuse to accept a message, even if the
sender's HELO command fails verification.DISCUSSION:
Verifying the HELO parameter requires a domain name lookup
and may therefore take considerable time. An alternative
tool for tracking bogus mail sources is suggested below
(see "DATA Command").Note also that the HELO argument is still required to have
valid <domain> syntax, since it will appear in a Received:
line; otherwise, a 501 error is to be sent.Судя по всему, многие MTA (исходно или после дополнительной настройки) не вполне соответствуют RFC1123, отвечая 550 в случае, если HELO parameter really !NOT! corresponds to the IP address of the sender.
С другой стороны, основание для проверки только "valid <domain> syntax" сейчас немного смешно - необходимость делать ресурсоемкий (некешируемый по определению!) реверсный ДНС запрос на каждое входящее соединение для серверов с пиком в 10-100 соединений в секунду при канале 100 МБ/с некритично, IMHO. Эпоха модемов, к счастью, позади...
Резюмируем:
Сервер отправителя ОБЯЗАН в HELO/EHLO писать корректное имя хоста.
Сервер-получатель обязан принимать письмо, если в HELO/EHLO любое имя хоста-отправителя.Практика показывает - многие администраторы почтовых серверов выдают таким нарушителям код 550 при несоответствии. Ну или 450, в частности, через check_client_access в postfix (см. greylist).
Я бы 2 инстанса постфикса для исходящей почты. Каждый со своим именем, адресом. В конфиге у каждого прописываем relayhost, smtp_fallback_relay.
> Я бы 2 инстанса постфикса для исходящей почты. Каждый со своим именем,
> адресом. В конфиге у каждого прописываем relayhost, smtp_fallback_relay.Только для исходящей почты? Клиенты должны использовать какой именно smtp сервер или как его выбирать?
domain.tld MX 5 mail.domain.tldmail.tld A IP1
mail.tld A IP2IP1.in-addr.arpa PTR mail.domain.tld
IP2.in-addr.arpa PTR mail.domain.tlddomain.tld TXT v=spf1 mx ip4:IP1 ip4:IP2 -all"
точнее
domain.tld MX 5 mail.domain.tldmail.domain.tld A IP1
mail.domain.tld A IP2IP1.in-addr.arpa PTR mail.domain.tld
IP2.in-addr.arpa PTR mail.domain.tlddomain.tld TXT "v=spf1 mx ip4:IP1 ip4:IP2 -all"
> точнее
> domain.tld MX 5 mail.domain.tld
> mail.domain.tld A IP1
> mail.domain.tld A IP2
> IP1.in-addr.arpa PTR mail.domain.tld
> IP2.in-addr.arpa PTR mail.domain.tld
> domain.tld TXT "v=spf1 mx ip4:IP1 ip4:IP2 -all"То есть расщепленный DNS - одно входящее письмо на IP1, другое на IP2?
Вообще-то черевато (потерей) отсрочкой доставки половины входящих писем при отказе одного провайдера, нет?
Ответ маршрутизатора однозначно с того интерфейса, с которого пришло.
Идея неплоха, в принципе... Но не вполне соответствует (неявному, согласен) пожеланию: пока работает основной канал - весь трафик через него.
> То есть расщепленный DNS - одно входящее письмо на IP1, другое на
> IP2?зависит от алгоритма выбора ИП на отправляющем сервере
> Вообще-то черевато (потерей) отсрочкой доставки половины входящих писем при отказе одного
> провайдера, нет?очень странная теория. если нет ответа от принимающего сервера, то отправляющий сервер должен пробовать следующий ИП или МХ. Потреь писем точно не будет.
> Ответ маршрутизатора однозначно с того интерфейса, с которого пришло.
по иначе и быть не может
> Идея неплоха, в принципе... Но не вполне соответствует (неявному, согласен) пожеланию:
> пока работает основной канал - весь трафик через него.возвращаемся к старой теме
domain.tld MX 5 mail.domain.tld
domain.tld MX 10 mail2.domain.tldmail.domain.tld A IP1
mail2.domain.tld A IP2МХ-записи влияют на входящую почту
при исходящей ваш сервер бедет всегда представляться как mail.domain.tld, реврес зона подтвердит соответствие ИП и имени. SPF окончательно развеет сомнения. Так что HELO не надо будет переделывать.
>> То есть расщепленный DNS - одно входящее письмо на IP1, другое на
>> IP2?
> зависит от алгоритма выбора ИП на отправляющем сервереДа, если его (или его провайдера) ДНС закеширует один из адресов, то по нему только и будет обращаться до момента отключения канала (недоступности адреса). Недоступность адреса не влияет на ответ DNS сервера, зона которого на ns3.nic.ru, а не в моей локальной сети.
>> Вообще-то черевато (потерей) отсрочкой доставки половины входящих писем при отказе одного
>> провайдера, нет?
> очень странная теория. если нет ответа от принимающего сервера, то отправляющий сервер
> должен пробовать следующий ИП или МХ. Потреь писем точно не будет.Ну этто под вопросом. Должен выбирать МХ хост с бОльшим числом приоритета, вообще-то. Если 2 разные МХ записи с двумя разными именами и разными приоритетами - однозначно выбор другого имени. Если имя одно и приоритет тоже один - не знаю, что будет. Боюсь, что и Вы не знаете.
А скорее всего, сделает паузу по умолчанию в 1 час и снова попробует тот же (закешированный) адрес. И так несколько раз с разными интервалами до истечения 5 суток (поведение постфикс по умолчанию).>> Ответ маршрутизатора однозначно с того интерфейса, с которого пришло.
> по иначе и быть не может
>> Идея неплоха, в принципе... Но не вполне соответствует (неявному, согласен) пожеланию:
>> пока работает основной канал - весь трафик через него.
> возвращаемся к старой теме
> domain.tld MX 5 mail.domain.tld
> domain.tld MX 10 mail2.domain.tld
> mail.domain.tld A IP1
> mail2.domain.tld A IP2
> МХ-записи влияют на входящую почтуЭэээ... Не помню точно, при получении входящего письма HELO проверяется или нет? Уточню, сервер должен быть mail2.domain.tld после перехода на резервный канал, а он себе говорит: HELO mail.domain.tld. Посмотрю к понедельнику этот момент.
> при исходящей ваш сервер бедет всегда представляться как mail.domain.tld, реврес зона подтвердит
> соответствие ИП и имени. SPF окончательно развеет сомнения. Так что HELO
> не надо будет переделывать.Вот это однозначно так. Если обе реверсные записи говорят, что и IP1, и IP2 имеют имя mail.domain.tld, то переписывать HELO не надо, т.к. ничего, кроме реверсных ДНС запросов, при этом не происходит.
В последнем варианте, когда реверсные зоны не вполне соответствуют прямым, вроде бы все должно быть корректно, если только внешний почтовик-отправитель не проверяет HELO получателя. Несколько необычно, но может сработать, несмотря на частичное нарушение RFC820/822.
По моему, Вам достаточно применить view:http://www.zytrax.com/books/dns/ch6/index.html#stealth
примерно такую проблему я недавно разрешал у себя:
А можно считать отказоустойчивой схему:domain.tld -> IP_0 -> вирт. машина в облачном хостинге типа selectel или linode. Функция: роутер.
На этой машине iptables перенаправляет запросы на 25, 110, 995 и другие порты, в зависимости от того, какой из ваших серверов online или других факторов.
Т.е. это не почтовик, а роутер. А почтовиков два, на линии провайдера1 первый, второй - на втором провайдере, или как вы желаете.
Соотв., все клиенты (ваши внутренние получатели, внешние отправители) изначально попадают на IP_0, а потом просто разруливаются. Вам удобно (вам - управлять куда идет почта, внешним клиентам никогда не меняется адрес вашего почтовика).
Из минусов - трафик через selectel или linode (в данном примере) идет. Если IP_0 недоступен, все ждут...
Но ведь можно один на linode, другой - на selectel, а роутить на один из ваших "внутренних" серверов. Тогда еще надежнее будет!
Или есть серьезные минусы у данной конструкции?
> Или есть серьезные минусы у данной конструкции?Есть. Минус в том что она ... не нужна.
Читай про веса MX records. Это два.
А потом до тебя дойдёт что проблема не в входящих ... и это раз. :)
>> Или есть серьезные минусы у данной конструкции?
> Есть. Минус в том что она ... не нужна.
> Читай про веса MX records. Это два.
> А потом до тебя дойдёт что проблема не в входящих ... и
> это раз. :)Я, может, не так выразил суть проблемы. Отказоустойчивость - это не только когда входящая почта не потеряется. Это решается, в самом деле, весом mx и почтовиками у разных провов, например. Отказоустойчивость - это, для меня, когда если в вашей серверной выбило питание, ваш сервер для клиентов продолжает отзываться на том же имени domain.tld. Когда для сервере входящей почты внутренних клиентов не надо вбивать в почтовые программы IMAP backup.domain.tld. Я вот о чем... Типа, как диск в рейде - сбойный, а всем незаметно.