Привязать получить статус передачи зоны после выполнения rndc reload
У меня есть сценарий, который выполняет rndc reload <имя_зоны> в <имя_просмотра> на вторичных (подчиненных) серверах в зонах, которые были изменены. Эта команда возвращает успех, если перезагрузка успешно поставлена в очередь.
Я хотел знать, есть ли способ получить статус фактического переноса зоны без просмотра самих журналов. Я хочу иметь возможность автоматически обрабатывать случай, когда перезагрузка привязки не удалась из-за самой ошибки. В настоящее время мне нужно проанализировать журналы, чтобы получить статус передачи зоны после выполнения rndc reload .
Может кто-нибудь помочь мне выяснить, как я могу получить статус передачи зоны после выполнения rndc reload <имя_зоны> , что лучше, чем анализ самих журналов.
ПРИМЕЧАНИЕ [для большей ясности] : Я знаю, что notify может использоваться ведущим устройством для передачи ведомому устройству об изменении. Мой вопрос заключается в том, чтобы узнать, есть ли способ получить уведомление , когда передача зоны, инициированная ведомым устройством, не удалась по какой-либо причине, без анализа журналов.
Например, может быть, после уведомления ведомого, главный сервер умер по какой-то причине. В этом случае, когда ведомое устройство инициирует передачу зоны, оно не сможет получить запись SOA от ведущего устройства. Я хочу получать уведомления о подобных ошибках, которые могут произойти во время передачи зоны, без фактического анализа журналов.
Сообщите мне, если потребуется дополнительная информация.
Файл журнала (ошибок) - единственное место, где Bind будет регистрировать такие ошибки, поэтому, если вы не хотите анализировать файлы журнала на предмет конкретных ошибок (хотя вы можете использовать что-то вроде Splunk для автоматизации такого разбора и генерации соответствующих предупреждений) вам нужно кое-что еще.
С точки зрения мониторинга, я думаю, что ваша сосредоточенность на получении уведомлений об ошибках во время передачи зон немного упускает суть. На самом деле, не столько ошибки имеют значение, сколько то, что они указывают на сокращение, отказ или ошибочное обслуживание. Вместо этого сосредоточьтесь на обслуживании.
Правильно настроенное решение для мониторинга обнаружит такое изменение состояния службы и предупредит вас. Тогда ваш инженер / оператор может легко найти в файле журнала соответствующую причину сокращения / отказа услуги ...
В сценарии главный-подчиненный ваш мониторинг должен гарантировать, что:
- все подчиненные и главное имя- серверы отвечают и возвращают данные зоны
- все подчиненные устройства возвращают данные, которые согласуются с данными главного устройства
. Хорошей записью DNS для мониторинга зоны будет запись SOA, поскольку это то, что каждый сервер имен всегда должен иметь возможность возврат для каждой зоны.
Во-вторых, серийный номер в записи SOA должен сообщить вам, синхронизируется ли ведомое устройство с ведущим. Если есть разница в серийных номерах, которая может быть вызвана тем, что ведомое устройство пропустило сообщение NOTIFY, но если эта разница присутствует дольше, чем интервал обновления SOA, возникает более серьезная проблема.
Создайте сценарий slave.sh с помощью:
#!/bin/sh
ns1="yourfirstdnsserver"
ns2="yourslavednsserver"
serial='grep SOA |cut -d " " -f7'
domain=$1
rndc reload $domain
a=`host -t SOA $domain $ns1 |grep SOA |cut -d " " -f7`
b=`host -t SOA $domain $ns2 |grep SOA |cut -d " " -f7`
if [ $a = $b ];
then echo "$domain : synchro ok";
else "$domain : Error";
fi;
Просто используйте ./ slave.sh yourdomain.com .
Наслаждайтесь!
a=`host -t SOA yourdomain.com yourns1.com |grep SOA |cut -d " " -f7` && b=`host -t SOA yourdomain.com yourns2.com |grep SOA |cut -d " " -f7` && if [ $a = $b ]; then echo "synchro ok"; else "Error"; fi;