Динамические объекты имеют ограниченное время существования, определяемое временем жизни (TTL), которое можно перезапустить посредством специальной операции-расширения refresh. Эта операция позволяет задать так называемый клиентский период подновления (Client Refresh Period, CRP), то есть промежуток времени, через который требуется выполнять подновления во избежание устаревания динамического объекта. Время устаревания вычисляется путём прибавления запрашиваемого TTL к текущему времени. Когда время жизни динамических объектов заканчивается и очередного подновления не происходит, они автоматически удаляются. Не гарантируется, что удаление будет выполняться немедленно, поэтому клиенты не должны на это рассчитывать.
У динамических объектов могут быть подчиненные объекты, при условии, что они также являются динамическими объектами. В RFC 2589 не определяется поведение динамической службы каталогов при устаревании динамического объекта, у которого есть подчинённые (динамические) объекты. В этой реализации время жизни динамического объекта, у которого есть подчинённые объекты, пролонгируется до тех пор, пока не закончится время жизни всех его подчинённых динамических объектов.
В базе данных должно быть настроено rootdn, в противном случае наложение dds не сможет удалять объекты, у которых превышено время жизни. Наложение dds может использоваться с любым механизмом манипуляции данными, реализующим операции add, modify, search и delete. Поскольку при использовании этого наложения могут происходить многочисленные внутренние поиски записей, а также добавления и удаления объектов, лучше всего применять его вместе с механизмами, имеющими достаточно хорошую производительность при выполнении операций записи.
Специфичные для наложения dds директивы конфигурации должны иметь префикс dds-, во избежание потенциальных конфликтов с директивами базы данных, к которой применяется это наложение, или с другими наложениями, применяемыми к той же базе данных.
В RFC 2589 рекомендуется не давать доступ на подновление динамических объектов анонимным клиентам. Это можно реализовать путём надлежащей настройки контроля доступа для получения желаемого эффекта.
Пример: разрешить выполнение подновлений только аутентифицированным клиентам
access to attrs=entryTtl
by users manage
by * read
access to attrs=entryTtl
by dnattr=creatorsName manage
by * read
Пример: подразумевая, что participant является валидным атрибутом, имеющим в качестве значений DN, разрешим пользователям начинать собрание и присоединяться к нему; разрешим выполнять операцию подновления только участникам собрания; разрешим удалять объект собрания только его создателю
access to dn.base="cn=Meetings"
attrs=children
by users write
access to dn.onelevel="cn=Meetings"
attrs=entry
by dnattr=creatorsName write
by * read
access to dn.onelevel="cn=Meetings"
attrs=participant
by dnattr=creatorsName write
by users selfwrite
by * read
access to dn.onelevel="cn=Meetings"
attrs=entryTtl
by dnattr=participant manage
by * read
При репликации таких объектов требуется явно исключать объектный класс dynamicObject и атрибут entryTtl. В данной реализации RFC 2589 представлен новый операционный атрибут entryExpireTimestamp, в котором содержится отметка времени устаревания. Он также должен быть исключён из репликации.
Быстрое и грубое решение - задать schemacheck=off в конфигурации syncrepl и, опционально, исключить эти операционные атрибуты из репликации с помощью настройки
syncrepl ...
exattrs=entryTtl,entryExpireTimestamp
В любом случае, чтобы потребитель репликации знал об операционном атрибуте entryExpireTimestamp, наложение должно быть либо статически встроено в slapd, либо загружено во время исполнения; однако, оно не должно быть сконфигурировано в базе данных потребителя репликации. В настоящий момент нет возможности удалить из записи объектный класс dynamicObject; это можно рассматривать как дополнительный функционал, поскольку этот класс позволяет увидеть динамические свойства объекта.
|
Закладки на сайте Проследить за страницей |
Created 1996-2025 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |