Удаление зоны через AXFR? В случае с репликацией базы удаление получается «из коробки», в случае с AXFR вам нужно будет городить агента или ещё какой-нибудь способ очистки слейвов. Нужно ли очищать? с одной стороны — нет, с другой стороны — должен быть порядок и если домен удален из клиентской панели, значит авторитетные серверы не должны больше отвечать на эти запросы.
В случае плейбуков мы, возможно, ожидаем разное поведение: это работает как отметка тегами сам факт выполнения роли, в то время как вам бы хотелось только выполнение конкретных тегов внутри роли. Верно?
Как отметка факта выполнения роли — работает уже давно, иначе бы у меня всё сразу поломалось :) в 2.0 тоже работает. Однако действительно есть неоднозначности и расхождения:
1.9.4: если у роли есть зависимости и они внутри не помечены тегом, то таски зависимостей не будут выполнены, только сама роль
2.0b2: если у роли есть зависимости и они внутри не помечены тегом, то зависимостей выполняются.
Что касается указания зависимостей в meta для выполнения конкретных тасков требуемых ролей: не работает ни в одной из версий.
Должен признать что раньше с тегами у нас не возникало никаких проблем, но, похоже, нужно копнуть эту тему поглубже и идти бодаться в issues :)
async относится к выполнению таска, т.е. запустили таск и пошли дальше, причём сделали это на всей группе хостов синхронно.
Стратегии определяют последовательность выполнения задач в плее. Ранее, на группе хостов задачи всегда выполнялись синхронно, хост управления дожидался когда каждая выполнится на всех узлах прежде чем приступить к следующей. Теперь можно не ждать выполнения этих же тасков на всей группе хостов. Другими словами, это контроль асинхронности выполнения тасков относительно хостов.
проверил в 2.0 — работает, как со --skip-tags=, так и просто c --tags=
Честно говоря, ранее проблем с этим не замечал. В какой версии проявлялась проблема?
К сожалению, сайт k-root'а в процессе реорганизации и статистика новых узлов недоступна. Приведу график DNS-запросов к серверу, который нам прислали в сентябре:
Данные с интерфейсов (зелёный — входящий):
Только нужно быть внимательным к порядку раскрытия переменных:
1. Сначала запускаются vars_plugins
2. На переменные из 1 накладываются переменные из inventory_dir/{group,host}_vars/
3. Сверху прилетают переменные из playbook_dir/{group,hosts}_vars
Поведение update или merge настраивается в ansible.cfg
Мы используем vars_plugins для разделения переменных пулов следующим образом:
— общие переменные для всех пулов лежат в /common_group_vars/ и читаются плагином
— переменные пулов лежат в /pools/<имя пула>/{group,host}_vars/ (инвенторий, соответственно в /pools/<имя пула>/hosts)
— глобальнные переменные, ссылающиеся на пулоспецифичные можно положить в /group_vars/
P.S. нужно быть осторожным с версией 1.9.x, оно пытается «раскрыть» при использовании lookup-плагина переменные, которые не используются не то что в текущем таске, но и вообще в плейбуке, поэтому если в переменных есть что-то что ссылается на ещё не созданное или просто ненужное именно сейчас, то можно получить остановку выполнения плейбука на ровном месте.
Использую seafile для синхронизаци данных между устройствами чуть более полугода (после того как ubuntu one прикрыли), каких-либо проблем и косяков не замечено + умеет версионирование.
hs01:~/temp/sources$ grep -nB2 PREFETCH_TTL_CALC ./unbound-1.4.22/util/data/msgreply.h
55-/** calculate the prefetch TTL as 90% of original. Calculation
56- * without numerical overflow (uin32_t) */
57:#define PREFETCH_TTL_CALC(ttl) ((ttl) - (ttl)/10)
Если верить ./unbound-1.4.22/daemon/worker.c и другим немаловажным *.c и *.h, то, вкрадце, работает это так:
RR.TTL — время жизни ресурсной записи (RR, Resource Record) в секундах, получаем от авторитетных серверов вместе с самой RR.
ttl — время «протухания» RR в кеше. Именно время, в unix timestamp. ttl = now() + RR.TTL
prefetch_ttl — время когда уже пора заново идти к авторитетным NS-серверам за правдой, но простой ttl ещё не протух. prefetch_ttl = now() + (RR.TTL — RR.TTL/10)
От клиента пришёл запрос конкретной RR:
если RR не было в кеше — отрезолвили (сходили к авторитетному серверу), посчитали для неё сразу prefetch_ttl и ttl, да положили в кеш.
если была в кеше, то (worker.c, строка 935) проверили не протух ли prefetch_ttl: не протух — просто ответили, а если да — отвечаем и обновляем кеш с обновлением prefetch_ttl и ttl (вот она нагрузка +10%).
Если запросов конкретной RR не приходило — она из кеша удаляется по наступлении ttl и всё хорошо, к авторитетным серверам не ходим, память/проц/трафик не жрём.
Совсем плохо будет если туннелировать трафик в днс пакетах через такой рекурсер.
Что же будет плохого? Для туннеля как раз генерируются уникальные имена с маленьким временем жизни (тыц). И эти имена совсем не популярны среди остальных пользователей рекурсора чтобы создавать дополнительную нагрузку.
Ни к чему. Он самостоятельно обновляет ресурсную запись если её запросят когда ttl почти «протух» и осталось меньше 10% от оригинального. Т.е. если эти домены спросят один раз — unbound отрезолвит их один раз.
Как отметка факта выполнения роли — работает уже давно, иначе бы у меня всё сразу поломалось :) в 2.0 тоже работает. Однако действительно есть неоднозначности и расхождения:
Что касается указания зависимостей в meta для выполнения конкретных тасков требуемых ролей: не работает ни в одной из версий.
Должен признать что раньше с тегами у нас не возникало никаких проблем, но, похоже, нужно копнуть эту тему поглубже и идти бодаться в issues :)
Приведите, пожалуйста, более полный пример и где возникает ошибка. Особенно интересует часть про «в зависимостях роли».
Стратегии определяют последовательность выполнения задач в плее. Ранее, на группе хостов задачи всегда выполнялись синхронно, хост управления дожидался когда каждая выполнится на всех узлах прежде чем приступить к следующей. Теперь можно не ждать выполнения этих же тасков на всей группе хостов. Другими словами, это контроль асинхронности выполнения тасков относительно хостов.
Т.к. стратегии реализованы в виде плагинов, то можно реализовать свою специфичную логику (два важных таска — синхронно, следующие — асинхронно). Более подробно реализацию можно посмотреть в коде: github.com/ansible/ansible/blob/devel/lib/ansible/plugins/strategy
Честно говоря, ранее проблем с этим не замечал. В какой версии проявлялась проблема?
Так что точно не закапают :D Будут дальше улучшать интеграцию с Fedora/RHEL-based утилитами.
В зависимости от IPv4/IPv6 ответ может различаться, добавляйте в параметры "-4"/"-6" для явного указания протокола
Альтернативно можно воспользоваться скриптом nmap (требуются права root'а):
ns1.ru-led.k.ripe.net — хостнейм узла в нашем ДЦ
Данные с интерфейсов (зелёный — входящий):
http://blog.powerdns.com/2015/06/23/what-is-a-powerdns-backend-and-how-do-i-make-it-send-an-nxdomain/
P.S. с помощью raw можно даже сетевыми железками подруливать.
github.com/ansible/ansible/tree/devel/lib/ansible/inventory/vars_plugins
github.com/ginsys/ansible-plugins/blob/devel/vars_plugins/group_vars_dirs.py (под старую версию ansible, но совместимо)
Только нужно быть внимательным к порядку раскрытия переменных:
1. Сначала запускаются vars_plugins
2. На переменные из 1 накладываются переменные из inventory_dir/{group,host}_vars/
3. Сверху прилетают переменные из playbook_dir/{group,hosts}_vars
Поведение update или merge настраивается в ansible.cfg
Мы используем vars_plugins для разделения переменных пулов следующим образом:
— общие переменные для всех пулов лежат в /common_group_vars/ и читаются плагином
— переменные пулов лежат в /pools/<имя пула>/{group,host}_vars/ (инвенторий, соответственно в /pools/<имя пула>/hosts)
— глобальнные переменные, ссылающиеся на пулоспецифичные можно положить в /group_vars/
P.S. нужно быть осторожным с версией 1.9.x, оно пытается «раскрыть» при использовании lookup-плагина переменные, которые не используются не то что в текущем таске, но и вообще в плейбуке, поэтому если в переменных есть что-то что ссылается на ещё не созданное или просто ненужное именно сейчас, то можно получить остановку выполнения плейбука на ровном месте.
Работает только в указанных версиях??
Заодно выяснил что у моего домашнего провайдера в качестве рекурсоров стоят bind'ы 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 и 9.9.5 :)
Если верить ./unbound-1.4.22/daemon/worker.c и другим немаловажным *.c и *.h, то, вкрадце, работает это так:
От клиента пришёл запрос конкретной RR:
Если запросов конкретной RR не приходило — она из кеша удаляется по наступлении ttl и всё хорошо, к авторитетным серверам не ходим, память/проц/трафик не жрём.
Что же будет плохого? Для туннеля как раз генерируются уникальные имена с маленьким временем жизни (тыц). И эти имена совсем не популярны среди остальных пользователей рекурсора чтобы создавать дополнительную нагрузку.
авторитативныхавторитетных
раз, два, три
По содержанию — полностью согласен :)