-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Перенос мыла между хостингами.
- Автор темы craz
- Дата начала
Во первых, пока твои DNS-сы обновятся на кешах тех же ripn'овских, неговоря уже о локальных того же mail'а почта будет ходить на разные хосты. Есть два выхода из этой ситуации.
Первый, и самый простой. Тупо создать заранее на новом серваке все ящики, протестить все через подмену хостов в host файле винды, сменить ns-сы (поменять записи DNS'са), и ждать (до суток) нормализации работы почты, остаточную почту забрать через POP3 со старого сервака по IP старого сервера.
Вариант второй, наиболее геморный. Применять в случае, если есть почта других юзеров (что бы не делать эти самые процедуры на всех клиентских машинах):
- Подготовка.
а) За сутки до фактического переноса настраиваешь работоспособность всей почтовой системы на новом сервере, с учетом логинов и паролей учетных записей.
б) После успешного тестирования учетных записей делаешь следующее - на старом сервере в управлении DNS добавляешь запись:
new.mail.domian.com. IN A новый.ip.сервера (точка в конце домена обязательна)
old.mail.domian.com. IN A старый.ip.сервера (точка в конце домена обязательна)
добавляешь запись вида
domian.com. IN MX 10 new.mail.domain.com. (точка в конце домена обязательна)
domian.com. IN MX 20 old.mail.domain.com. (точка в конце домена обязательна)
Остальные MX записи удаляешь.
(т.е., тебе необходимо в качестве Max Prioritet MX server указать новый почтовый сервер, в качестве второго - старый).
Ожидаешь около суток до полного сброса кешей всех NS серверов и соответственно начала правильной работы резервной схемы.
После этого почтовик сам разберется куда что слать, в качестве основного сервера будет взят новый.
Перенос.
Переносишь доменную зону на новый сервер, записи A и MX касающиеся почты сохраняешь т.е.:
domian.com. IN MX 10 new.mail.domain.com. (точка в конце домена обязательна)
domian.com. IN MX 20 old.mail.domain.com. (точка в конце домена обязательна)
Домены new.mail.domain.com. и old.mail.domain.com. должны быть проделегированы с теме же IP как и на старом домене.
Осатальные записи домена делаешь по новому.
Далее Переносишь сайты и др. на новый сервак.
После успешного переноса и проверки меняешь NS записи домена
Ждешь когда обновится полностью кеши доменов (до 1 суток) и вуаля, работа системы стабилизируется.
удаляешь со старых NS-сов хостера домен полностью (SOA запись) дабы небыло проблем асинхронизации DNS в дальнейшем.
Гарантия 100% - ни одно письмо не потеряется.
При тестах активно юзать линуксовую утилиту dig (есть в комплекте к BIND под винду), проверить релей на новом сервере, спамсистему на предмет кривой настройки и ложного срабатывания.
-~{}~ 07.11.10 02:13:
ДА, забыл сказать, после успешно переноса, через двое трое суток удалить запись domian.com. IN MX 20 old.mail.domain.com. на новом сервере.
Первый, и самый простой. Тупо создать заранее на новом серваке все ящики, протестить все через подмену хостов в host файле винды, сменить ns-сы (поменять записи DNS'са), и ждать (до суток) нормализации работы почты, остаточную почту забрать через POP3 со старого сервака по IP старого сервера.
Вариант второй, наиболее геморный. Применять в случае, если есть почта других юзеров (что бы не делать эти самые процедуры на всех клиентских машинах):
- Подготовка.
а) За сутки до фактического переноса настраиваешь работоспособность всей почтовой системы на новом сервере, с учетом логинов и паролей учетных записей.
б) После успешного тестирования учетных записей делаешь следующее - на старом сервере в управлении DNS добавляешь запись:
new.mail.domian.com. IN A новый.ip.сервера (точка в конце домена обязательна)
old.mail.domian.com. IN A старый.ip.сервера (точка в конце домена обязательна)
добавляешь запись вида
domian.com. IN MX 10 new.mail.domain.com. (точка в конце домена обязательна)
domian.com. IN MX 20 old.mail.domain.com. (точка в конце домена обязательна)
Остальные MX записи удаляешь.
(т.е., тебе необходимо в качестве Max Prioritet MX server указать новый почтовый сервер, в качестве второго - старый).
Ожидаешь около суток до полного сброса кешей всех NS серверов и соответственно начала правильной работы резервной схемы.
После этого почтовик сам разберется куда что слать, в качестве основного сервера будет взят новый.
Перенос.
Переносишь доменную зону на новый сервер, записи A и MX касающиеся почты сохраняешь т.е.:
domian.com. IN MX 10 new.mail.domain.com. (точка в конце домена обязательна)
domian.com. IN MX 20 old.mail.domain.com. (точка в конце домена обязательна)
Домены new.mail.domain.com. и old.mail.domain.com. должны быть проделегированы с теме же IP как и на старом домене.
Осатальные записи домена делаешь по новому.
Далее Переносишь сайты и др. на новый сервак.
После успешного переноса и проверки меняешь NS записи домена
Ждешь когда обновится полностью кеши доменов (до 1 суток) и вуаля, работа системы стабилизируется.
удаляешь со старых NS-сов хостера домен полностью (SOA запись) дабы небыло проблем асинхронизации DNS в дальнейшем.
Гарантия 100% - ни одно письмо не потеряется.
При тестах активно юзать линуксовую утилиту dig (есть в комплекте к BIND под винду), проверить релей на новом сервере, спамсистему на предмет кривой настройки и ложного срабатывания.
-~{}~ 07.11.10 02:13:
ДА, забыл сказать, после успешно переноса, через двое трое суток удалить запись domian.com. IN MX 20 old.mail.domain.com. на новом сервере.
craz
Нестандартное звание
СУПЕРБЛ!!! ВЕРИ СЭНКС!!!
а) За сутки до фактического переноса настраиваешь работоспособность всей почтовой системы на новом сервере, с учетом логинов и паролей учетных записей.
Вот это только конкретно не понятно... Это вручную делать?
P.s. А вообще я твердо уверен нефик почту держать на домене, такой гемор, что писец...
почему это доходит только когда 1) не продлили домен 2) почтовый сервак хостинга отмер 3) многое что еще может случиться...
Тем кто это когда либо прочитает увидит Офигенскую инструкцию от Активист и поймет что он этим заниматься не хочет, до того как выберет работу с почтой на своем домене Я ВАМ ЧЕСТНО ГОВОРЮ
создайте блин почту [email protected] и никогда не имейте гемороя!
а) За сутки до фактического переноса настраиваешь работоспособность всей почтовой системы на новом сервере, с учетом логинов и паролей учетных записей.
Вот это только конкретно не понятно... Это вручную делать?
P.s. А вообще я твердо уверен нефик почту держать на домене, такой гемор, что писец...
почему это доходит только когда 1) не продлили домен 2) почтовый сервак хостинга отмер 3) многое что еще может случиться...
Тем кто это когда либо прочитает увидит Офигенскую инструкцию от Активист и поймет что он этим заниматься не хочет, до того как выберет работу с почтой на своем домене Я ВАМ ЧЕСТНО ГОВОРЮ
создайте блин почту [email protected] и никогда не имейте гемороя!
Добавлю следующее.
> Гарантия 100% - ни одно письмо не потеряется.
1. 100% гарантия на этапе подготовки, почему 100%.
Самая первая реакция будет на твоей старой почтовой системе, ибо обновятся локальные DNS, кеши будут сброшены моментально. С этого момента транспорт на сервере почты будет отключен (Local Develery Mail Box Transport), старый сервер будет аккумулировать почту и станет транизитным.
2. 100% гарантия на этапе переноса. Поскольку после суток резервная схема будет работать полностью и корректно и независимо от того, какой с какого NS сервера запрошена информация по MX.
3. 100% гарантия в течении 7 суток от начала подготовки. Поскольку транзитный сервер является резеврным и в случае ошибок доставки на первичный MX сервер, вся почта на MX 20 будет лежать как минимум 7 дней до восстановления Primary MX, это гарантирует целостность почты при неверно настроенной почтовой системе на новом сервере. Важно - главное не отдавать код 500 с нового сервере (user not found н-р), проблемы 4xx (tempory local problem) не вызывают difered (4xx коды обычно связаны с проблемными конфигами, правами и т.п.), т.е., не возможность принять в spool или проблемы транспорта.
Обрати внимание, что с "момента подготовки" основным сервером будет выступать новый сервер, соответственно на старом сервере почты уже не будет, все она будет на новом (максимум, на старом почта будет в spool'e, но в локальные mbox доставляться не будет), заберется она с нового сервера после переноса (смены NS'ов и сброса кешей), т.е., на новом сервере спокойно будет все лежать, дожидаясь своего часа, отсюда возможен эффект, при котором - почты как бы нет, но в действительности она будет на новом сервере, поэтому, в течении 2-х суток сами пользователи могут испытывать дисконфорт.
Все это лучше, чем просто переброс почты, поскольку здесь гарантия 100%.
Надеюсь понятно изложил.
-~{}~ 07.11.10 03:05:
craz
> Вот это только конкретно не понятно...
> Это вручную делать?
То что я опишу ниже, будет касаться только нового сервера.
Да перед тестом, домен должен быть на новом сервере проделигирован по новому (как я писал выше).
Тестирование входящей почты по SMTP. Берешь телнет и шлешь на на свои (те которые создал) почтовые ящики письма (комманда RCPT TO), типа того. Результатом толжен быть код 2xx
Проверка исх. почты - это проще пареной репы - в настройках the bat (или чего-нибудь подобного) указываешь SMTP сервер - IP нового сервера, через него шлешь пару писем локальным юзерам, и на внешний релай - на mail.ru (в случае если ушло на внешнию почту и на локальные ящики, то все ок).
Проверяешь POP3 - меняешь в клиенте почтовом хост POP 3 сервера и ты должен получить локальные письма, отправленные через telnet.
> вообще я твердо уверен нефик почту держать на домене,
> такой гемор, что писец...
С опытом приходит, главное делать резервные схемы, хоть с офисным 1-мегабитным каналом, главное что бы были.
-~{}~ 07.11.10 03:27:
Да, учетки переносить вручную (логины, пароли).
Как вытащить пароли учетных записей. Если есть такая возможность в панели управления, то через нее, если нет, то посмотри в бейкапах, если паролей там нет и у тебя их нет, то проси адинов хостинга их тебе дать.
Имея права рута есть вариант что они могут быть в файлах
/etc/exim4/passwd
/etc/postfix/passwd
(или аналогичные)
Если там фряха - и sendmail, то скорее всего используется Sasl2 для хранения паролей, это геморой еще тот, вытягивал оттуда пароли пользователей, чесно слово ... ... , писать пришлось башовые скрипты для дергания паролей. (Тоже переносил 160 доменов на новый сервак года три назад). ISPManager хоть и имел возможность переноса бзеров с их паролями, но все было настолько криво, а по факту не работало.
> Гарантия 100% - ни одно письмо не потеряется.
1. 100% гарантия на этапе подготовки, почему 100%.
Самая первая реакция будет на твоей старой почтовой системе, ибо обновятся локальные DNS, кеши будут сброшены моментально. С этого момента транспорт на сервере почты будет отключен (Local Develery Mail Box Transport), старый сервер будет аккумулировать почту и станет транизитным.
2. 100% гарантия на этапе переноса. Поскольку после суток резервная схема будет работать полностью и корректно и независимо от того, какой с какого NS сервера запрошена информация по MX.
3. 100% гарантия в течении 7 суток от начала подготовки. Поскольку транзитный сервер является резеврным и в случае ошибок доставки на первичный MX сервер, вся почта на MX 20 будет лежать как минимум 7 дней до восстановления Primary MX, это гарантирует целостность почты при неверно настроенной почтовой системе на новом сервере. Важно - главное не отдавать код 500 с нового сервере (user not found н-р), проблемы 4xx (tempory local problem) не вызывают difered (4xx коды обычно связаны с проблемными конфигами, правами и т.п.), т.е., не возможность принять в spool или проблемы транспорта.
Обрати внимание, что с "момента подготовки" основным сервером будет выступать новый сервер, соответственно на старом сервере почты уже не будет, все она будет на новом (максимум, на старом почта будет в spool'e, но в локальные mbox доставляться не будет), заберется она с нового сервера после переноса (смены NS'ов и сброса кешей), т.е., на новом сервере спокойно будет все лежать, дожидаясь своего часа, отсюда возможен эффект, при котором - почты как бы нет, но в действительности она будет на новом сервере, поэтому, в течении 2-х суток сами пользователи могут испытывать дисконфорт.
Все это лучше, чем просто переброс почты, поскольку здесь гарантия 100%.
Надеюсь понятно изложил.
-~{}~ 07.11.10 03:05:
craz
> Вот это только конкретно не понятно...
> Это вручную делать?
То что я опишу ниже, будет касаться только нового сервера.
Да перед тестом, домен должен быть на новом сервере проделигирован по новому (как я писал выше).
Тестирование входящей почты по SMTP. Берешь телнет и шлешь на на свои (те которые создал) почтовые ящики письма (комманда RCPT TO), типа того. Результатом толжен быть код 2xx
Код:
login as: root
[email][email protected][/email]ce's password:
Access denied
[email][email protected][/email]ce's password:
Access denied
[email][email protected][/email]ce's password:
Linux serv002 2.6.26-2-686 #1 SMP Thu Sep 16 19:35:51 UTC 2010 i686
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Nov 6 10:03:57 2010 from 192.168.0.1
serv002:~# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 local.office ESMTP Postfix (Debian/GNU)
EHLO tester
250-local.office
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: [email][email protected][/email]
250 2.1.0 Ok
RCT TP // тут я ошибся , не обращать внимание.
502 5.5.2 Error: command not recognized
RCPT TO: root@localhost
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Hello word!
.
250 2.0.0 Ok: queued as E9D56262A2
QUIT
221 2.0.0 Bye
Connection closed by foreign host.
serv002:~#Проверка исх. почты - это проще пареной репы - в настройках the bat (или чего-нибудь подобного) указываешь SMTP сервер - IP нового сервера, через него шлешь пару писем локальным юзерам, и на внешний релай - на mail.ru (в случае если ушло на внешнию почту и на локальные ящики, то все ок).
Проверяешь POP3 - меняешь в клиенте почтовом хост POP 3 сервера и ты должен получить локальные письма, отправленные через telnet.
> вообще я твердо уверен нефик почту держать на домене,
> такой гемор, что писец...
С опытом приходит, главное делать резервные схемы, хоть с офисным 1-мегабитным каналом, главное что бы были.
-~{}~ 07.11.10 03:27:
Да, учетки переносить вручную (логины, пароли).
Как вытащить пароли учетных записей. Если есть такая возможность в панели управления, то через нее, если нет, то посмотри в бейкапах, если паролей там нет и у тебя их нет, то проси адинов хостинга их тебе дать.
Имея права рута есть вариант что они могут быть в файлах
/etc/exim4/passwd
/etc/postfix/passwd
(или аналогичные)
Если там фряха - и sendmail, то скорее всего используется Sasl2 для хранения паролей, это геморой еще тот, вытягивал оттуда пароли пользователей, чесно слово ... ... , писать пришлось башовые скрипты для дергания паролей. (Тоже переносил 160 доменов на новый сервак года три назад). ISPManager хоть и имел возможность переноса бзеров с их паролями, но все было настолько криво, а по факту не работало.
craz
Нестандартное звание
прояснилась одна деталь на хостинге старом есть такие записи
domain.ru. 3600 IN MX 10 sbs.domain.ru.
sbs.domain.ru. 3600 IN A ххх.ххх.ххх.ххх
Где ххх.ххх.ххх.ххх - статический IP-адрес нашего собственного сервака(вон в серверной жужжит).
Мои предположения верны
если регистратор=хостинг(то есть одно и тоже лицо), и от регистратора как такового я отказываться не буду, то есть домены так и будут там лежать, то в таком случае мне вообще не надо ниче трогать так ведь?)
domain.ru. 3600 IN MX 10 sbs.domain.ru.
sbs.domain.ru. 3600 IN A ххх.ххх.ххх.ххх
Где ххх.ххх.ххх.ххх - статический IP-адрес нашего собственного сервака(вон в серверной жужжит).
Мои предположения верны
если регистратор=хостинг(то есть одно и тоже лицо), и от регистратора как такового я отказываться не буду, то есть домены так и будут там лежать, то в таком случае мне вообще не надо ниче трогать так ведь?)
craz
Нестандартное звание
Че не так блин? Я пытаюсь разобраться, вопросы тупые потому что не сталкивался, сталкивался бы не спрашивал - логично?
Да одна, да я же написал
У админа узнал, что да локально. Домены от регистратора не переношу, почту получается же тоже переносить не надо, она на локальном компе.
Мне кажется или не надо на новом серваке ничего писать?
craz
Нестандартное звание
Ну факт, что получает, я просто не могу так, хренакс сделать, а потом говорить "вон админ он за это деньги получает почему не следил? От меня отстаньте идите лесом."
Активист - спасибо огромное за помощь, очень счастлив, что не пришлось воспользоваться вашей инструкцией) Но все равно ваша помощь была не оценима(а если бы пришлось следовать ваше й инструкции то в стократ неоценимее)
Активист - спасибо огромное за помощь, очень счастлив, что не пришлось воспользоваться вашей инструкцией) Но все равно ваша помощь была не оценима(а если бы пришлось следовать ваше й инструкции то в стократ неоценимее)
Есть намного более простой способ, если ящиков немного:
1) Зарегаться в google apps
2) Настроить MX по их инструкции для подтверждения акка
3) Временно вернуть обратно как было, зарегать всех юзеров, настроить pop3 fetch в gmail-ах, подождать пока все стянется
4) Поставить уже навсегда гугловые MX-ы и забыть про весь этот онанизм с exim-ами и postfix-ами.
1) Зарегаться в google apps
2) Настроить MX по их инструкции для подтверждения акка
3) Временно вернуть обратно как было, зарегать всех юзеров, настроить pop3 fetch в gmail-ах, подождать пока все стянется
4) Поставить уже навсегда гугловые MX-ы и забыть про весь этот онанизм с exim-ами и postfix-ами.
Есть еще проще - Яндекс. Почта для домена:
1) Делегировать домен на днс-ы Яндекса.
2) Все работает.
1000 ящиков, алсо, лучше чем 50 ящиков.
с точки зрения безопасности паранойи Большой Брат читает всю твою почту до получения на сервер 
в этой стране опасность конфискации сервера товарисчами с автоматами несколько выше опасности заинтересовать ЦРУ или админов gmail-а своим бизнесом
а с gmail ее можно читать удобно из любого места в мире по ssl-каналу и забыть про спам
в этой стране опасность конфискации сервера товарисчами с автоматами несколько выше опасности заинтересовать ЦРУ или админов gmail-а своим бизнесом
а с gmail ее можно читать удобно из любого места в мире по ssl-каналу и забыть про спам