[ новости /+++ | форум | теги | ]

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

Ключевые слова: dns, sync, domain, bind, freebsd,  (найти похожие документы)

From: Alex Samorukov <samm@os2.kiev.ua.>
Date: Mon, 6 Mar 2008 14:31:37 +0000 (UTC)
Subject: Автоматическая синхронизация файлов конфигурации master и slave DNS серверов

Зачем это нужно?

Для одного из проектов мне потребовалось обеспечить автоматическое
распространение DNS зон, прописанных на master dns, slave серверам. Так
как зон ожидалось не больше 100-200 мне хотелось сделать максимально
простую, но в тоже время безопасную схему синхронизации серверов, без
использования LDAP или SQL в качестве backend. В итоге я решил задачу
используя shell скрипты, которыми решил поделиться с общественностью.
Всё нижеописанное работает на OS FreeBSD но должно без проблем работать
и в любой другой UNIX OS c BIND в роли DNS. 


Как это работает

Все master зоны на primary dns лежат в отдельной директории
(/etc/namedb/master-auto) и названы в формате <domain>.db.

Например example.com.db, kernel.org.db и т.п. Это важный момент, так как
на этом основан алгоритм получения списка доменов (это проще и удобнее
чем читать named.conf). Используя протокол SSH клиенты (secondary
сервера) запрашивают у primary сервера список доменов и, в случае
различий с локальным списком, обновляют конфигурацию. Клиентов может
быть сколько угодно, обновление происходит по cron, например, раз в 10
минут. Для безопасного транспорта содержимого  зон используется TSIG
протокол. 


Конфигурация сервера

Как я уже писал выше, primary сервер должен по протоколу SSH отдавать
список обслуживаемых доменов. Для этого я завёл пользователя dnssync.
Shell данного пользователя будет специально созданный для данной цели sh
скрипт.

        # pw user add dnssync -s /home/dnssync/domainlist.sh


Пароль пользователю не нужен, так как для подключения будет
использоваться SSH ключ.

Теперь создадим сам скрипт:

        mkdir /home/dnssync; chmod 700 /home/dnssync; 


vi /home/dnssync/domainlist.sh

          #!/bin/sh
          
          export COLUMNS=1
          # directory with <zone>.db files
          cd /etc/namedb/master-auto
          echo "DOMAINLIST_START"
          /bin/ls *.db|/usr/bin/sed 's/\.db//'
          echo "DOMAINLIST_END"


Корректируем права доступа:

        chmod +x /home/dnssync/domainlist.sh


Как видно из текста скрипта, всё что он делает - это получает список
файлов в директории, убирает суффикс .db и добавляет к выводу
DOMAINLIST_START перед листингом и DOMAINLIST_END в конце вывода. Для
проверки запустите /home/dnssync/domainlist.sh - должно быть что-то
вроде 

          DOMAINLIST_START
          example.com
          kernel.org
          DOMAINLIST_END


Конфигурация клиента

Теперь перейдём к настройке secondary DNS. Для начала нам потребуется
настроить авторизацию по ключу для подключения к главному серверу. Если
ключ ещё не создан, запустим ssh-keygen, указав пустой passphrase. Нам
потребуется скопировать публичный ключ (по умолчанию
/root/.ssh/id_rsa.pub в FreeBSD) в список авторизованных ключей на
главном сервере (в файл  /home/dnssync/.ssh/authorized_keys). В этом же
файле можно задать IP адрес владельца ключа для большей безопасности.
Чтобы убедиться, что всё работает, на клиенте введём команду ssh
dnssync@<master_ip>, например # 'ssh dnssync@1.2.3.4 sync'. Последний
аргумент требуется, чтобы сервер не показывал motd и прочие радости. В
случае правильной настройки должен быть выведен список доменов, без
запроса пароля. 

Теперь установим клиентский скрипт, который отвечает за изменение
конфигурации BIND и его перезапуск:

        mkdir /root/bin


vi /root/bin/dnssync.sh

          #!/bin/sh
  
          MASTERHOST="1.2.3.4"
          MASTERUSER="dnssync"
          DNSTMPDIR="/root/tmp"
  
          # fetching domain list from the master
          /usr/bin/ssh -o BatchMode=yes ${MASTERUSER}@${MASTERHOST} fetch > ${DNSTMPDIR}/domains.tmp </dev/null
          if [ "$?" -ne "0" ]; then
            echo "Error while transferring"
            exit 1
          fi
  
          # simple check of the received file
          if [ -z `grep DOMAINLIST_START ${DNSTMPDIR}/domains.tmp` -o -z `grep DOMAINLIST_END ${DNSTMPDIR}/domains.tmp` ]; then
            echo "Invalid data received"
            exit 1;
          fi
  
          # check if the files are equal
          if [ -f ${DNSTMPDIR}/domains -a -z "`/usr/bin/cmp ${DNSTMPDIR}/domains.tmp ${DNSTMPDIR}/domains 2>/dev/null`" ]; then
             # files are equal, do nothing
             exit 0;
          fi
  
          # copy temporary file to the primary
          /bin/cp  ${DNSTMPDIR}/domains.tmp  ${DNSTMPDIR}/domains
  
          # creating output file for the dns
          /usr/bin/grep -v DOMAINLIST_ ${DNSTMPDIR}/domains \
                  | sed 's/\(.*\)/zone "\1" in  { type slave; file "slave\/\1.db"; masters {'${MASTERHOST}';}; };/' \
                  > /etc/namedb/slave.conf
  
          /etc/rc.d/named restart >/dev/null


Корректируем права доступа:

        chmod 700 /root/bin/dnssync.sh


Этот скрипт при запуске подключается к master серверу, скачивает список
доменов (проверяя его корректность), сравнивает с имеющимся файлов и в
случае изменений создаёт /etc/namedb/slave.conf, содержащий список slave
зон после чего перезапускает BIND. Запустите скрипт, в случае если всё
работает правильно вы должны получить файл /etc/namedb/slave.conf
содержащий конфигурацию slave зон. Чтобы named читал этот файл добавим
строчку 'include "slave.conf";' в файл /etc/named.conf и перезапустим
named. В случае отсутствия ошибок в директории /etc/namedb/slave
появятся файлы зон.  Для автоматической работы скрипт dnssync.sh
добавляем в crontab пользователя root с требуемой вам периодичностью. 

Для вторичных серверов поступаете аналогично. 


TSIG - безопасная передача зон

Для увеличение безопасности работы я рекомендую использовать механизм
TSIG. Достаточно подробное описание настройки можно прочитать в статье
"Защита сервера DNS", так
что я не вижу смысла дублировать это в своей заметке.

Заключение

Описанная схема прекрасно подходит для сравнительно небольших
конфигураций. К её плюсам можно отнести простоту реализации (только
shell), высокую безопасность и лёгкую переносимость. Недостатки - каждый
раз передаётся полный список зон, в случае обновления требуется
перезапуск named. В масштабах большого регистратора рекомендую подумать
о более эффективных методах репликации, но для большинства других задач
эти недостатки совершенно не существенны. Как всегда - буду рад
замечаниям и советам.

Alex Samorukov, samm@os2.kiev.ua

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

1.1, Salvator (?), 18:56, 06/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– имхо, статья о том, как не надо делать. для таких целей есть директива masters в named.conf     2.20, Samm (??), 23:19, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– Если вы расскажете как поставленную задачу решить средствами бинд - я удалю эту статью и попрошу извинения у читателей. Но что-то мне подсказывает, что дальше заголовка вас читать не научили.   1.2, aZ (?), 19:17, 06/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Велосипед. Зачем придумано master и slave в намеде - автору явно не известно.     2.27, Samm (??), 23:32, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >Велосипед. Зачем придумано master и slave в намеде - автору явно не >известно. Жду решения задачи описанной в статье встроенными средствами.   1.3, Deepwalker (??), 19:19, 06/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Автор, объясните пожалуста смысл действий. А то народ в недоумении, может я чего не допонял/не знаю? : (     2.41, Samm (??), 00:54, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– >Автор, объясните пожалуста смысл действий. А то народ в недоумении, может я >чего не допонял/не знаю? : ( Смысл действий ясно описан в статье - автоматическое создание и удаление зон на слейвах, в зависимости от конфигурации мастера.   1.4, Аноним (4), 19:22, 06/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– спасибо, но я буду пользоваться встроенными в бинд средствами синхронизации :))     2.6, brandy (?), 19:44, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >спасибо, но я буду пользоваться встроенными в бинд средствами синхронизации :)) +1 :) Автор, отсыпь :)     3.21, Samm (??), 23:23, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– Да не вопрос, обращайся. Только до этого опиши, как решить задачу распространения вновь созданных или удалённых зон встроенными средствами. Отсыплю стакан.     4.31, brandy (?), 23:36, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– Дико извиняюсь, таки недосмотрел и не до конца внимательно прочитал, а так, бегло, между строк... Идея отличная. Попроси лучше вебмастеров/админов сайта переименовать статью :)     5.40, Samm (??), 00:52, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– Не страшно, да и с названием я и в самом деле накосячил. Заявку на изменение названия сразу отправил, надеюсь завтра поправят. Просто не понимаю, зачем писать комментарии к тексту не прочитав его.   1.5, Аноним (-), 19:35, 06/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– более того, встроенные средства красиво оформляют файлы зон =)     2.23, Samm (??), 23:26, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >более того, встроенные средства красиво оформляют файлы зон =) И распространяют вновь созданные? Почитайте статью. Название и в самом деле неудачно,   1.7, shad (??), 20:32, 06/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– С ума сойти... ну понятно когда такое проделывают с djb dns, но с named, имхо - извращение...   1.9, uldus (ok), 21:33, 06/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– А слабо комментаторам прочитать статью ? Речь про то как _автоматически_ синхронизировать зоны на слейв, без ручной правки конфигов слейва, просто добавил домен на мастере, он сам заведется на слейве. У меня например это делается формированием конфига слейфа на стороне мастера и последующим его копированием.     2.13, Anonymous (?), 21:45, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– Но это должно делаться только один раз при создании зоны     3.15, Аноним (4), 22:16, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– А если слейвов >> 1? А если это должно происходить автоматически? Например, на мастере вписывают зоны из веб-панели. Ну и? Дальше что?     4.18, Anonymous (?), 23:08, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >А если слейвов >> 1? А если это должно происходить автоматически? Например, на мастере вписывают зоны из веб-панели. Ну и? Дальше что? Не досмотрел... статью правильно надо было назвать: Автоматическое создание slave зон DNS. И то в скрипте высмотрел, что не перестартовывается DNS если нет обновление. А по тексту это не совсем так. Каждый раз скрипты читать...     5.26, Samm (??), 23:30, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >>А если слейвов >> 1? А если это должно происходить автоматически? Например, на мастере вписывают зоны из веб-панели. Ну и? Дальше что? > >Не досмотрел... >статью правильно надо было назвать: Автоматическое создание slave зон DNS. >И то в скрипте высмотрел, что не перестартовывается DNS если нет обновление. >А по тексту это не совсем так. Каждый раз скрипты читать... > Название было выбрано неудачно, согласен. Хотя в тексте ясно написано о чём идёт речь.   4.38, Samm (??), 00:02, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– >А если слейвов >> 1? А если это должно происходить автоматически? Например, на мастере вписывают зоны из веб-панели. Ну и? Дальше что? Кстати, именно так и происходит. Зоны создаёт менеджер - реселлер из веб морды. Географически разнесённых слейвов больше одного. И вообще есть мысль в целях безопасности настоящий мастер сделать скрытым, чтобы с него только слейвы и кормились.   3.16, uldus (ok), 22:29, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >Но это должно делаться только один раз при создании зоны Посмотрите вы скрипт в статье в конце концов, там вся его работа сводится к автоматическому формированию slave.conf, передается через ssh каждый раз только список доменов.     4.28, Samm (??), 23:33, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >>Но это должно делаться только один раз при создании зоны > >Посмотрите вы скрипт в статье в конце концов, там вся его работа >сводится к автоматическому формированию slave.conf, передается через ssh каждый раз только >список доменов. Большое спасибо что прочитали статью, ваш IQ явно много выше большинства пишущих тут :)   3.25, Samm (??), 23:29, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >Но это должно делаться только один раз при создании зоны Почитайте статью. Зон - порядка сотни, и правит их менеджер через веб морду. Задача решалась для небольшого хостинг-провайдера.   2.24, Samm (??), 23:27, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >А слабо комментаторам прочитать статью ? Речь про то как _автоматически_ синхронизировать >зоны на слейв, без ручной правки конфигов слейва, просто добавил домен >на мастере, он сам заведется на слейве. У меня например это >делается формированием конфига слейфа на стороне мастера и последующим его копированием. > Большое спасибо что смогли прочитать дальше заголовка (в отличии от большинства муд.. комментаторов).   1.10, ture (?), 21:40, 06/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Может книжку в начале почитал бы? А то читать тошно...     2.17, uldus (ok), 22:32, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >Может книжку в начале почитал бы? А то читать тошно... Книжку по магии ? У вас конфигурационный файл slave сервера волшебным образом создается ? Чтобы средствами DNS перетащить зоны, нужно вначале эти зоны в конфиге обозначить связав их с мастером.   2.35, Samm (??), 23:40, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >Может книжку в начале почитал бы? А то читать тошно... Тошно - не читайте. А теперь скажи мне, мой слаткий, в какой книжке это описано?   1.12, alfss (?), 21:44, 06/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– pDNS     2.39, Samm (??), 00:46, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– Да, это 1 из вариантов, я его рассматривал, но всё же решил остановиться на бинд, ввиду его лучшей изученности :)     1.14, Аноним (4), 22:15, 06/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Почти все, кто сверху - идиоты. Речь идет о синхронизации зон и их содержания, а не только содержания. Некоторое время назад мне тоже пришлось решать такую задачку.     2.19, Anonymous (?), 23:12, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >Почти все, кто сверху - идиоты. Речь идет о синхронизации зон и >их содержания, а не только содержания. Некоторое время назад мне тоже >пришлось решать такую задачку. Встречают по одежке... Это я к чему - название статьи правильно надо писать!     3.30, Samm (??), 23:34, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >>Почти все, кто сверху - идиоты. Речь идет о синхронизации зон и >>их содержания, а не только содержания. Некоторое время назад мне тоже >>пришлось решать такую задачку. > >Встречают по одежке... >Это я к чему - название статьи правильно надо писать! Да, это была моя ошибка. Но писать комментарии к статье НЕ ЧИТАВ ЕЁ - это идиотизм. Клинический.   1.29, Onan (?), 23:34, 06/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Афтар, что мешало передать файл конфига по ftp? К чему такие сложности?     2.32, brandy (?), 23:38, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– Не автор не все же как Ранович отвечу вопросом на вопрос - а если слейв в десяти-двадцати транзитных общедоступных для других сеток от мастера и никто никому не мешает мирроринг на порту свитча включить и сниффить? И просниффить аккаунт для фтп?   2.33, Samm (??), 23:39, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >Афтар, что мешало передать файл конфига по ftp? К чему такие сложности? > 1) ftp не безопасен. 2) Передать файл откуда? На мастере - совсем другая конфигурация. 3) Где вы увидели сложности? Задача решена исключительно средствами ОС. С фтп решение бы заняло не меньше времени и скрипт всё равно бы пришлось писать.     3.72, Lazy (?), 11:20, 15/03/2008 [^] [^^] [^^^] [ответить]   +/– А rsync не лучше заюзать? Я понимаю, это конечно выходит за рамки средств ОС. но тем не менее.   2.34, Pilat (?), 23:40, 06/03/2008 [^] [^^] [^^^] [ответить]   +/– >Афтар, что мешало передать файл конфига по ftp? К чему такие сложности? > Наверно, отличный от нуля IQ автора статьи помешал. Вам, наверно, не помешает.   1.37, Samm (??), 23:42, 06/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Читаем новость: Alex Samorukov подготовил статью с рассказом как обеспечить автоматическую синхронизацию конфигурации первичного и вторичных DNS серверов. Что неясно, мои милые лемминги?     2.43, Skif (ok), 02:00, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– >Читаем новость: > >Alex Samorukov подготовил статью с рассказом как обеспечить автоматическую синхронизацию конфигурации первичного >и вторичных DNS серверов. > >Что неясно, мои милые лемминги? Саш, плюнь и не заводись. Здесь многие сначала поливают, потом думают. Столкнутся с похожей проблемой - прибегут и будут читать. И еще спасибо скажут. А до тех пор: "а на.. оно надо? А зачем велосипед?". Многие просто не сталкивались с чем-то серьезнее одного роута в компании и все. :) Решение не безгрешное, но имеет право быть.   1.42, daiver (??), 01:53, 07/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Samm, идея отличная и реализация тоже. Спасибо.   1.44, alex (??), 08:34, 07/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Статья понравилась. Спасибо. "Теоретикам", написавшим максимум "hello, word" в своей жизни нужно научиться уважать людей, которые умеют генерить идеи и воплощать их в жизнь...   1.45, ig0r (??), 08:43, 07/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Скрипт стоит подправить, чтобы срабатывало не по крону, а скажем вызывалось скриптом на мастере, после правки конфига, этот скрипт также могбы рестартовать named на мастере. В итоге, слейв синхронизируеться сразу, и нету ненужных синхронизаций в период когда конфиги не правились.     2.50, Samm (??), 09:38, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– >Скрипт стоит подправить, чтобы срабатывало не по крону, а скажем вызывалось скриптом >на мастере, после правки конфига, этот скрипт также могбы рестартовать named >на мастере. В итоге, слейв синхронизируеться сразу, и нету ненужных синхронизаций >в период когда конфиги не правились. В этом есть и плюсы и минусы. Ну плюс очевиден - нет лишних обращений к мастеру. Минус тоже - во первых у всех клиентов должен быть для этого заведён ssh account, во вторых - если кто-то временно не доступен (как я уже говорил, сервера разнесены) то синхронизация не произойдёт (и мы должны это учитывать в скрипте). Я решил пойти по варианту большей надёжности, тем более что трафик, по сегодняшним меркам, оно создаёт крошечный.     3.57, ig0r (??), 10:35, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– во первых не совсем понял о чём Вы говорите "у всех клиентов должен быть для этого заведён ssh account" ну на случай если кто-то временно не доступен (у меня тоже сервера разнесены ;) ), то можно раз в сутки действительно делать по крону (и не обязательно со слейва) но основной плюс от продложеной мной схемы не отсутствие лишних запросов, а мгновенная синхронизация.     4.63, Samm (??), 18:46, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– Это не сложно добавить, просто для моей задачи время синхронизации до 10 минут было совершенно допустимым. Кроме того, я бы не хотел чтобы на каждый чих рестартавали слейвы, лучше уж пусть какой-то лаг будет. Но, повторюсь, это - индивидуально.   1.47, pablo (ok), 09:28, 07/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– "Если ключ ещё  создан" Видимо пропущена "не". Alex, а по -HUP named не перечитывает конфиг?     2.49, Samm (??), 09:35, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– Судя по документации Certain UNIX signals cause the name server to take specific actions, as described in the following table. These signals can be sent using the kill command. SIGHUP Causes the server to read named.conf and reload the database. перечитывает. На практике у меня пару раз он "волшебным образом" исчезал из списка процессов и, исключительно для надёжности, я вписал рестарт. Можете заменить если это критично.   2.52, Samm (??), 09:51, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– >"Если ключ ещё  создан" >Видимо пропущена "не". > >Alex, а по -HUP named не перечитывает конфиг? Да, и спасибо за "ключ ещё не создан" - действительно опечатка, послал запрос на исправление.   1.48, dRiZd (?), 09:32, 07/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Сам в 96-ом году так-же парился, выкрутился подобным способом. Я думаю, для тех людей у кого голова дана не "для того, чтобы шляпу носить" - данная статья будет хорошим подспорьем.   1.53, Аноним (4), 09:53, 07/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– пипец, кто писал выше в начале клинические дибилы, прочитав заголовок я почемуто СРАЗУ понял о чем статья. по теме: 1) статья вери гут 2) вопрос к знатокам - а как быть если доменов планируется 5 000 - 10 000, юзать как бэкенд лдап или мускуль ? однакож читал что с производительностью проблемы в таком случае.... ваши мнения ?     2.55, Samm (??), 10:12, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– >пипец, кто писал выше в начале клинические дибилы, прочитав заголовок я почемуто >СРАЗУ понял о чем статья. >по теме: >1) статья вери гут >2) вопрос к знатокам - а как быть если доменов планируется 5 >000 - 10 000, юзать как бэкенд лдап или мускуль ? > >однакож читал что с производительностью проблемы в таком случае.... >ваши мнения ? Ну я бы решал задачу так: 1) Перевёл бы мастер и слейвы на SQL драйвер конфигурации, например - отсюда (MySQL) http://mysql-bind.sourceforge.net/ . 2) Настроил бы репликацию MASTER->SLAVES в mysql, кстати, при этом можно без проблем включить SSL шифрование и ограничение IP (средствами MySQL). Это бы обеспечило автоматический и надёжный механизм распространения конфигов и баз. Желательно также сделать мониторинг баз данных на слейвах, чтобы не пропустить момент рассинхронизации. 3) Я не думаю, что на современном железе у вас возникнут проблемы с производительностью, если вы конечно не собираетесь строить root сервер ;-) Обычно dns жрёт достаточно небольшое количество ресурсов. В крайнем случае - можно поставить обычный named в роли кеширующего. Ну и в MYSQL5 покрутить (query cache и т.п.).     3.56, Аноним (4), 10:15, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– Спасибо за отзыв пайду читать gt оверквотинг удален ... большой текст свёрнут, показать   1.54, vl (??), 09:53, 07/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Спасибо за статью. Начал читать то же сразу не догнал, зачем так делать. Потом понял в чем смысл. Мне кажется название статьи лучше поменять на что нибудь такое: автоматическая синхронизация списка доменных зон ... И в пункте "Зачем это нужно?" акцент на это сделать.   1.58, Egenius (??), 11:16, 07/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Спасибо за статью ! Давно хотел найти нечто подобное. У меня только один вопрос. А почему нельзя читать зоны из named.conf ? При этом выборку делать по типу зоны и брать записи только с типом master. У меня, например сервер, являющийся мастером для одних доменов, в то же время является слэйвом для некоторых других. И мне трудно заставить, например Plesk, разделять мастер и слэйв зоны по разным директориям и писать файлы зон с окончанием ".db" Можно ли как то сделать выборку мастер зон из named.conf для передачи их Вашему скрипту ? Спасибо !     2.62, Samm (??), 18:37, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– >Спасибо за статью ! Пожалуйста ) >Давно хотел найти нечто подобное. >У меня только один вопрос. >А почему нельзя читать зоны из named.conf ? Можно, конечно, просто это услоэнит задачу. >При этом выборку делать по типу зоны и брать записи только с >типом master. >У меня, например сервер, являющийся мастером для одних доменов, в то же >время является слэйвом для некоторых других. В данном примере случай частной задачи, не более. >И мне трудно заставить, например Plesk, разделять мастер и слэйв зоны по >разным директориям и писать файлы зон с окончанием ".db" >Можно ли как то сделать выборку мастер зон из named.conf для передачи >их Вашему скрипту ? >Спасибо ! Можно, конечно. С плеском я бы поступил иначе - весь конфиг он хранит в mysql, так что просто на сервере сделайте скрипт из mysql + sed :)     3.68, Egenius (??), 16:40, 08/03/2008 [^] [^^] [^^^] [ответить]   +/– > С плеском я бы поступил иначе - весь конфиг он хранит в mysql, так что просто на сервере сделайте скрипт из mysql + sed :) Спасибо за совет. И как я раньше не догнал ?))   1.59, Аноним (4), 14:34, 07/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Статья - ради статьи :( Теперь предлагается сделать форки этой статьи о пересылке и разборе файла named.conf по почте (и разбирать procmail), по ftp, по http, по ....... Тут можно список продлить. А потом добавить весь перечень статейсписок с использованием AWK, perl etc....     2.60, Samm (??), 17:17, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– >Статья - ради статьи :( >Теперь предлагается сделать форки этой статьи о пересылке и разборе файла named.conf >по почте (и разбирать procmail), по ftp, по http, по ....... > >Тут можно список продлить. >А потом добавить весь перечень статейсписок с использованием AWK, perl etc.... Я надеюсь, что кому-та эта статья здорово сократит время для реализации данной задачи.   1.61, Lin (??), 17:27, 07/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Спасибо за статью Сейчас пользую самописный скрипт scp/ssh для синхронизации 3-х серверов, но у меня его нужно запускать ручками На неделе буду внедрять!   1.64, Аноним (64), 22:04, 07/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Начало статьи однозначно говорит о том, что автор собирается синхронизировать именно файлы зон. Отсюда и весь сыр, бор. Вот пример: "Для одного из проектов мне потребовалось обеспечить автоматическое распространение DNS зон, прописанных на master dns, slave серверам." Любой прочитавший это сразу задастся вопросом: А на кой сие? Сам BIND это умеет и даже очень хорошо умеет. Даже смена названия статьи не сдерживает негатива от прочтения. Так же не освещена тема когда зона с основного сайта удаляется. На резервном сервер ведь мусор остается. Как его стирать прикажите? Могу дать идею. Надо пройтись AWK-ом по файлу named.conf и все файлы, которые там не указаны удалить из соответствующего каталога. Вот тогда будет действительно хорошее и полезное решение.     2.65, aZ (?), 23:17, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– Согласен. А автора статьи за обзывания забанить. :D     3.67, Samm (??), 23:34, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– >Согласен. > >А автора статьи за обзывания забанить. :D Да ради бога! Пожалуйтесь редактору.   2.66, Samm (??), 23:33, 07/03/2008 [^] [^^] [^^^] [ответить]   +/– >Начало статьи однозначно говорит о том, что автор собирается синхронизировать именно файлы >зон. >Отсюда и весь сыр, бор. > >Вот пример: >"Для одного из проектов мне потребовалось обеспечить автоматическое >распространение DNS зон, прописанных на master dns, slave серверам." > >Любой прочитавший это сразу задастся вопросом: А на кой сие? Сам BIND >это умеет и даже очень хорошо умеет. Да? умеет распространять зоны мастера, не прописанные на слейвах? А в ISC про это знают? > >Так же не освещена тема когда зона с основного сайта удаляется. На >резервном сервер ведь мусор остается. Ну остаётся и ладно, меня не напрягает наличие мусора в дире слейв. Если вас напрягает - 2 строчке в скрипте-апдейтере, diff + awk + xargs и всё. В любом случае они НИ НА ЧТО не влияют.     3.69, mega (??), 17:38, 08/03/2008 [^] [^^] [^^^] [ответить]   +/– в PowerDNS задача отлично решается встроенными средствами. И испортировать зоны из бинда тоже можно. Имхо нет смысла изобретать велосипед.   3.73, Andrey Y. Ostanovsky (?), 22:57, 14/05/2008 [^] [^^] [^^^] [ответить]   +/– > Да? умеет распространять зоны мастера, не прописанные на слейвах? А в ISC про это знают? Умеет, знают.:) Ловите нотификации - они присылаются на слэйвы независимо от того - прописано там что-то у них в конфигах, или нет: 14-May-2008 18:06:20.053 notify: info: zone sxxxxxxxxxxxx/IN/regular: sending notifies (serial 20080426)     4.75, Samm (??), 14:19, 13/06/2008 [^] [^^] [^^^] [ответить]   +/– >> Да? умеет распространять зоны мастера, не прописанные на слейвах? А в ISC про это знают? > >Умеет, знают.:) Ловите нотификации - они присылаются на слэйвы независимо от того >- прописано там что-то у них в конфигах, или нет: >14-May-2008 18:06:20.053 notify: info: zone sxxxxxxxxxxxx/IN/regular: sending notifies (serial 20080426) С точки зрения security крайне стрёмное решение )   1.70, tsv4g (ok), 01:50, 09/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Alex, мне кажется у тебя в статье закрался один косяк "по процедуре" вот в этой строке /bin/ls *.db|/usr/bin/sed 's/\.db//' будут неправильно обрабатываться домены типа domain.dbxxxxx.com  и т.д. т.е. содержащие .db внутри имени домена решается банально: /bin/ls *.db|/usr/bin/sed 's/\.db$//' но лучше в статье написать правильно - некоторые могут наступить на эти грабли, огорчатся потом ... Про статью вообще - задачка довольно специфическая, но решение адекватное - дёшево и сердито.   1.71, Anonymous (?), 15:52, 13/03/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Интересное решение, простое и надежное. Репликация базы имеет свои риски и тонкости, например упасть может MySQL, база попортиться может, да и вообще любое лишнее звено снижает надежность. А то можно дойти до того, что давайте все конфиги в базе хранить, а /etc удалим за ненадобностью :) Можно предложить улучшение: файлы копировать через rsync. Он по ssh работает, передает только диффы и сжимает данные. Трафик будет виден только под микроскопом.   1.74, VB (?), 03:23, 22/05/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– У нас была аналогичная проблема на MS DNS серверах (тоже хостинг-провайдер где клиенты добавляют домены через веб интерфейс). Нашли готовый софт: http://tools.tripletee.com/3tdns/   1.76, Sergej Kandyla (?), 23:33, 15/10/2008 [ответить] [﹢﹢﹢] [ · · · ]   +/– Hi! идея отличная. Сам писал подобное (с учетом специфики своей задачи) на основе shell+rsync(via ssh). я удивляюсь всяким "комИнтОтАрам" которые банально не одупляют суть вопроса, лишь бы что-то ляпнуть....в духе "аФтор не курил ман бинда" Спасибо!     2.77, zerg23k (??), 15:07, 16/01/2009 [^] [^^] [^^^] [ответить]   +/– Автору спасибо за идею и статью, я тоже боролся с подобной проблемой чуть меньше месяца назад. Читал про многие DNS демоны, но задача стояла (работа с кириллическими доменами), а на данный момент с ними работает только ibind. Поэтому проблемма синхронизации зон - была решена подобным способом с передачей через rsync. Спасибо автору..   игнорирование участников | лог модерирования

Партнёры:

Хостинг: