Использование DDNS и LDAP совместно с ROSA Directory Server

Преамбула

Не секрет, что многие пользователи и технические специалисты, интересующиеся ОС Linux, неоднократно высказывали своё недовольство тем, что любая информация о технических разработках «Лаборатории РОСА» больше смахивает на маркетинговый пресс-релиз, чем на техническую информацию как таковую. К тому же, большинство людей просто не в курсе, чем мы вообще занимаемся помимо создания дистрибутива, медиапроигрывателя и сборочной системы ABF. В связи с этим группа коллег, включая вашего покорного слугу, решили это положение исправить и постараться по возможности регулярно выкладывать информацию о том, что происходит на техническом поприще внутри компании, заодно рассказать о наработках, сделанных в рамках создания того или иного программного обеспечения.

Я попробую начать с одной из достаточно интересных вещей, которая была сделана при создании ROSA Directory Server, а также о технических моментах, связанных с его созданием. Итак, поехали!

Для чего требуется?

Наверное, любой достаточно серьёзный системный администратор сталкивался с тем, что управление DNS в более-менее разветвлённой инфраструктуре требует наличия инструментов для управления всем этим хозяйством.

Даже в самом простейшем виде у нас возникает три задачи:

• где хранить и поддерживать в актуальном виде информацию?
• как обновлять?
• как обеспечить отказоустойчивость сервиса?

В реальности, конечно, этих вопросов намного больше.

Для решения этой проблемы была создана реализация динамического DNS с возможностью прозрачного хранения информации о зонах на LDAP-сервере через специальную файловую систему, позволяющую читать информацию о записях DNS.

Решается таким образом несколько задач, начиная от единообразного способа хранения конфигураций, до минимизации человеческого фактора в процессе настройки и обновлений данных серверов DNS.

Как оно работает?

В обычной ситуации, для чтения записей из LDAP, когда bind использует специальный бэкэнд SDB LDAP, работает всё примерно следующим образом:

Как вы понимаете, каждый раз после проведения изменений, если следовать схеме выше, приходится производить массу рутинных действий: внести необходимые правки в конфигурационные файлы, проверить корректность внесённой информации, перезапустить сервер, чтобы он перечитал конфигурацию, проверить корректную работу вышепроизведённых изменений и только после этого заниматься другими задачами. Когда серверов немного и столь же немного хостов — ещё куда ни шло. Можно обойтись парочкой скриптов и как-то всю эту деятельность автоматизировать даже силами весьма посредственного администратора. А если это постоянно изменяющаяся структура достаточно большого предприятия?

Именно для таких случаев и было придумано данное решение. В случае использования связки DynamicDNS и сервера LDAP, работа, связанная с обновлением зон, существенно изменяется:

Как мы можем видеть на схеме выше, помимо сервера LDAP и bind в схеме появляется несколько промежуточных компонентов, наибольший интерес из которых вызывают два из них: специальная файловая система ldapbindfs и оверлей для LDAP под названием dnsmod, которые рассмотрим чуть подробнее.

Итак, dnsmod — это оверлей для LDAP, который позволяет обеспечить возможность редактирования данных DNS непосредственно в LDAP, используя специальный web-интерфейс либо внешнюю программу, в режиме динамического обновления зоны.

Основное назначение dnsmod - отслеживание операций изменения данных в дереве записей DNS. Например, проверяются операции добавления, изменения, удаления и изменения DN записи в LDAP.

Оверлей автоматически отключает обновление зон во время процедуры изменения данных в LDAP и заново его включает после завершения изменений.

Следует заметить, что при работе в динамическом режиме работы DNS сервера bind запрещается вручную редактировать файлы зон. Если возникла необходимость в ручной правке, то перед началом редактирования зоны необходимо отключить динамическое обновление зоны, перенести DNS-данные из файлов журналов в файл зоны и удалить файл журнала. После завершения редактирования нужно снова включить динамическое обновление зон.

Для управления некоторыми аспектами DDNS оверлей dnsmod использует команды

rndc freeze 

и

rndc thaw

, входящие в состав bind. В нашем случае, при выполнения команды rndc freeze, записи зоны переносятся из журнала обновления в LDAP, а файл журнала удаляется. Динамическое обновление зоны приостанавливается. Команда rndc thaw, применяемая к соответствующей зоне, позволяет named-серверу bind обновить свой кэш и возобновить динамическое обновление зоны. После чего оверлей указывает файловой системе ldapbindfs обновить кэш файла измененной зоны, перечитав данные зоны из LDAP. Все описанные действия в реальности убраны «под капот» ROSA Directory Server и администратор имеет дело только с веб-интерфейсом, через который и вносит необходимые настройки.

Но главный компонент всей этой конфигурации ldapbindfs — файловая система, работающая через FUSE и предназначенная для работы с файлами зоны DNS. Все операции с файлом зоны отображаются как операции чтения, записи, удаления и редактирования данных в LDAP. При открытии файла зоны его содержимое кэшируется с целью сохранения его целостности. При записи в файл, запись производится в кэш файла, а сохранение данных в LDAP производится при закрытии файла. На время редактирования данных файловая система ldapbindfs устанавливает блокировку оверлея dnsmod в дереве записей DNS с целью поддержания целостности данных и предотвращения зацикливания.

При динамическом обновлении данные DNS сначала попадают в специальный журнал, а сам bind при этом настраивается на хранение журналов обновлений зон (файлы с расширением .jnl) отдельно от самих файлов зон. Данные DNS из журнала переносятся в файл зоны с определённой задержкой, либо по команде от rndc или при перезагрузке самого сервера.

В результате применения подобной схемы, bind читает и записывает данные зон, которые выглядят для него как обычные текстовые конфигурационные файлы. При этом эти конфигурационные файлы генерируются ldapbindfs на основе данных, хранящихся в LDAP.

Внимательный читатель заметит, что самое интересное в этой реализации то, что bind даже не подозревает о том, что его данные хранятся в LDAP. Он по-прежнему работает с собственными файлами конфигурации, что позволяет избавиться от какой-либо модификации самого bind и сильно облегчить дальнейшую поддержку такого рода решений.

Авторы: Буданов Евгений, Кабанова Елена