Использование DDNS и LDAP совместно с ROSA Directory Server — различия между версиями
Juliette (обсуждение | вклад) м (→Для чего требуется?) |
Juliette (обсуждение | вклад) м (→Как оно работает?) |
||
| Строка 20: | Строка 20: | ||
В обычной ситуации, для чтения записей из LDAP, когда bind использует специальный бэкэнд SDB LDAP, работает всё примерно следующим образом: | В обычной ситуации, для чтения записей из LDAP, когда bind использует специальный бэкэнд SDB LDAP, работает всё примерно следующим образом: | ||
| + | [[File:DDNS0.png|center]] | ||
| + | |||
Как вы понимаете, каждый раз после проведения изменений, если следовать схеме выше, приходится производить массу рутинных действий: внести необходимые правки в конфигурационные файлы, проверить корректность внесённой информации, перезапустить сервер, чтобы он перечитал конфигурацию, проверить корректную работу вышепроизведённых изменений и только после этого заниматься другими задачами. Когда серверов немного и столь же немного хостов — ещё куда ни шло. Можно обойтись парочкой скриптов и как-то всю эту деятельность автоматизировать даже силами весьма посредственного администратора. А если это постоянно изменяющаяся структура достаточно большого предприятия? | Как вы понимаете, каждый раз после проведения изменений, если следовать схеме выше, приходится производить массу рутинных действий: внести необходимые правки в конфигурационные файлы, проверить корректность внесённой информации, перезапустить сервер, чтобы он перечитал конфигурацию, проверить корректную работу вышепроизведённых изменений и только после этого заниматься другими задачами. Когда серверов немного и столь же немного хостов — ещё куда ни шло. Можно обойтись парочкой скриптов и как-то всю эту деятельность автоматизировать даже силами весьма посредственного администратора. А если это постоянно изменяющаяся структура достаточно большого предприятия? | ||
| + | |||
Именно для таких случаев и было придумано данное решение. | Именно для таких случаев и было придумано данное решение. | ||
В случае использования связки DynamicDNS и сервера LDAP, работа, связанная с обновлением зон, существенно изменяется: | В случае использования связки DynamicDNS и сервера LDAP, работа, связанная с обновлением зон, существенно изменяется: | ||
| − | + | [[File:DDNS1.png|center]] | |
Как мы можем видеть на схеме выше, помимо сервера LDAP и bind в схеме появляется несколько промежуточных компонентов, наибольший интерес из которых вызывают два из них: специальная файловая система ldapbindfs и оверлей для LDAP под названием dnsmod, которые рассмотрим чуть подробнее. | Как мы можем видеть на схеме выше, помимо сервера LDAP и bind в схеме появляется несколько промежуточных компонентов, наибольший интерес из которых вызывают два из них: специальная файловая система ldapbindfs и оверлей для LDAP под названием dnsmod, которые рассмотрим чуть подробнее. | ||
| − | Итак, dnsmod — это оверлей для LDAP, который позволяет обеспечить возможность редактирования данных DNS непосредственно в LDAP, используя специальный web-интерфейс либо внешнюю программу, в режиме динамического обновления зоны. | + | |
| + | Итак, '''dnsmod''' — это оверлей для LDAP, который позволяет обеспечить возможность редактирования данных DNS непосредственно в LDAP, используя специальный web-интерфейс либо внешнюю программу, в режиме динамического обновления зоны. | ||
| + | |||
Основное назначение dnsmod - отслеживание операций изменения данных в дереве записей DNS. Например, проверяются операции добавления, изменения, удаления и изменения DN записи в LDAP. | Основное назначение dnsmod - отслеживание операций изменения данных в дереве записей DNS. Например, проверяются операции добавления, изменения, удаления и изменения DN записи в LDAP. | ||
| + | |||
Оверлей автоматически отключает обновление зон во время процедуры изменения данных в LDAP и заново его включает после завершения изменений. | Оверлей автоматически отключает обновление зон во время процедуры изменения данных в LDAP и заново его включает после завершения изменений. | ||
| + | |||
Следует заметить, что при работе в динамическом режиме работы DNS сервера bind запрещается вручную редактировать файлы зон. Если возникла необходимость в ручной правке, то перед началом редактирования зоны необходимо отключить динамическое обновление зоны, перенести DNS-данные из файлов журналов в файл зоны и удалить файл журнала. После завершения редактирования нужно снова включить динамическое обновление зон. | Следует заметить, что при работе в динамическом режиме работы 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 с целью поддержания целостности данных и предотвращения зацикливания. | + | Для управления некоторыми аспектами DDNS оверлей dnsmod использует команды |
| − | При динамическом обновлении данные DNS сначала попадают в специальный журнал, а сам bind при этом настраивается на хранение журналов обновлений зон (файлы с расширением .jnl) отдельно от самих файлов зон. Данные DNS из журнала переносятся в файл зоны с определённой задержкой, либо по команде от rndc или при перезагрузке самого сервера. | + | 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 читает и записывает данные зон, которые выглядят для него как обычные текстовые конфигурационные файлы. При этом эти конфигурационные файлы генерируются ldapbindfs на основе данных, хранящихся в LDAP. | ||
| + | |||
Внимательный читатель заметит, что самое интересное в этой реализации то, что bind даже не подозревает о том, что его данные хранятся в LDAP. Он по-прежнему работает с собственными файлами конфигурации, что позволяет избавиться от какой-либо модификации самого bind и сильно облегчить дальнейшую поддержку такого рода решений. | Внимательный читатель заметит, что самое интересное в этой реализации то, что bind даже не подозревает о том, что его данные хранятся в LDAP. Он по-прежнему работает с собственными файлами конфигурации, что позволяет избавиться от какой-либо модификации самого bind и сильно облегчить дальнейшую поддержку такого рода решений. | ||
| − | Авторы: | + | |
| − | Буданов Евгений | + | '''Авторы:''' |
| − | Кабанова Елена | + | ''Буданов Евгений, Кабанова Елена'' |
[[Категория:"Точка РОСЫ"]] | [[Категория:"Точка РОСЫ"]] | ||
Текущая версия на 19:40, 28 сентября 2012
Преамбула
Не секрет, что многие пользователи и технические специалисты, интересующиеся ОС 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 и сильно облегчить дальнейшую поддержку такого рода решений.
Авторы: Буданов Евгений, Кабанова Елена
