Кроме статических списков и групп, OpenLDAP также может работать и с динамическими. Их поддержка реализована с помощью стандартного наложения dynlist
.
Суть записей динамических списков и групп заключается в том, что часть их содержимого (атрибутов и их значений) не хранится в каталоге постоянно (статично), а формируется лишь в тот момент, когда такая запись возвращается пользователю в ответ на его поисковый запрос. Динамическое содержимое таких записей строится на основании текущего состояния каталога на момент запроса записи пользователем, то есть если пользователь дважды запросил одну и ту же динамическую запись, а между этими запросами в каталог были внесены изменения, то динамическое содержимое запрашиваемой записи может оказаться различным.
Само динамическое содержимое записи строится на основании дополнительного поискового запроса в тот же самый каталог. Те атрибуты и их значения, которые будут получены в результате этого дополнительного запроса, будут подставлены в запись динамической группы или списка перед выдачей её пользователю (составят её динамическое содержимое).
Параметры такого дополнительного поискового запроса задаются в виде LDAP URI в одном из атрибутов записи динамической группы. Формат LDAP URI определён в RFC 4516, и тому, кто немного разбирается в параметрах поисковых запросов LDAP, составить такой URI не составит труда. Чтобы не быть голословными, мы разберём компоненты LDAP URI в одном из последующих примеров.
Наложение dynlist
— штатное наложение OpenLDAP с хорошо отлаженным функционалом и довольно богатыми возможностями настройки. Оно позволяет учесть практически все возможные нюансы построения динамического содержимого, включая переопределение типов атрибутов и возможности обхода ограничений доступа к каталогу. Но при всём этом, у получающихся в результате работы наложения динамических групп есть один существенный недостаток, как всегда, являющийся обратной стороной их достоинств: динамическое содержимое не рассматривается при оценке поисковых фильтров. Попросту говоря, критерии первоначального поискового запроса оцениваются ещё до того, как записи каталога наполняются динамическим содержимым. Поэтому, если кто-то пытается отобрать только динамические группы, содержащие определённые члены, то ничего не выйдет: на момент оценки фильтров никаких членов в этих группах попросту нет.
Как ни крути, именно возможность фильтрации записей при поиске делает LDAP таким привлекательным для системных администраторов. И в поставке OpenLDAP есть неофициальное наложение autogroup
, позволяющее схожим по настройкам с dynlist
образом автоматически поддерживать членство записей каталога в группах. Функционал наложения autogroup
напоминает функционал другого наложения — memberof, только наоборот: в записи групп вносятся изменения, если претерпели определённые изменения записи-члены этих групп. То есть, если у записи-члена был убран признак принадлежности к определённой группе, то атрибут его членства будет удалён из этой группы. Если же запись в каталоге приобрела признак членства в какой-то группе, то в запись-группу будет добавлен соответствующий атрибут членства. При этом получающиеся группы уже нельзя назвать динамическими: их атрибуты членства статически находятся в каталоге, только ведутся автоматическим образом. Поэтому частенько среди администраторов такие группы называют "автогруппами" (в конце концов, это следует из названия самого наложения).
Поскольку на момент выполнения первоначального поиска в автогруппах статически прописаны атрибуты членства в них, то можно полноценно использовать фильтрацию по значениям этих атрибутов, что существенно для настройки многих работающих с каталогом приложений.
С точки зрения способа настройки, функционал наложения autogroup
похож на dynlist
(хотя, конечно, не столь богат, всё-таки наложение неофициальное). Поэтому мы сочли возможным рассмотреть динамические группы (и списки) и автогруппы в одном разделе.
Прежде чем рассматривать конкретные примеры настройки, сравним возможности наложений dynlist
и autogroup
, чтобы можно было сделать обоснованный выбор, какое из них использовать для решения той или иной задачи при работе с каталогом.
Функционал | dynlist | autogroup |
---|---|---|
Природа атрибутов членства в группе (атрибутов-пунктов списка) | Динамические | Статические, ведутся автоматически |
Возможность применения поисковых фильтров для отбора записей на основе значений атрибутов членства (атрибутов-пунктов) | Нет | Да |
Поддержка записей-групп | Да | Да |
Поддержка записей-списков | Да | Нет |
Возможность переопределения исходного типа атрибута при построении списка | Да | Нет |
Возможность переопределения авторизационной сущности при выполнении дополнительного поискового запроса | Да | Нет |
Возможность наложения дополнительных ограничений на отбор записей-кандидатов в члены группы (пункты списка) | Да | Нет |
Встроенный функционал поддержания признака обратного членства в группе в записях-членах | Нет | Да |
Следует отметить ещё одну небольшую тонкость, связанную с динамической и статической природой атрибутов, поддерживаемых с помощью этих наложений. При использовании наложения dynlist
дополнительная нагрузка на каталог создаётся при выполнении поисковых запросов (в виде вторичных поисковых запросов и обработки их результатов для каждой обслуживаемой записи с динамическим содержимым). Во время модификации записей каталога никакой дополнительной обработки не происходит. При использовании наложения autogroup
ситуация обратная: поисковые запросы обрабатываются стандартным способом, а вся дополнительная нагрузка (вторичные поисковые запросы и, при необходимости, модификация записей-групп) происходит именно во время модификации потенциальных записей-членов групп в каталоге. И в том и в другом случае дополнительная нагрузка не будет слишком ощутимой, если, конечно, в каталоге не поддерживаются тысячи динамических или автогрупп.
Во многих примерах настройки динамических групп, в том числе и в официальной man-странице наложения dynlist, для построения динамических записей используется объектный класс groupOfURLs
, в один из атрибутов которого, — memberURL
, — помещается LDAP URI для описания параметров вторичного поиска потенциальных записей-членов группы (списка). Определения этого объектного класса и типа атрибута входят в набор схемы данных dyngroup, включённого в стандартную поставку OpenLDAP. Хотя использование этого объектного класса и типа атрибута является общепринятой практикой, для работы рассматриваемых наложений они не требуются, поскольку, как мы покажем на примерах, динамические группы и списки можно строить и с другими классами и атрибутами. Так что вопрос подключения или неподключения набора схемы данных dyngroup
оставляется на выбор администратора каталога.
Единственный случай, когда подключение этого набора схемы необходимо — настройка наложения dynlist
с переопределением авторизационной сущности при выполнении вторичного поискового запроса. Наложение ищет в записи динамической группы конкретный атрибут dgIdentity
, который, вместе с содержащим его вспомогательным объектным классом dgIdentityAux
, входит в тот же набор схемы данных dyngroup
.
Поскольку вариантов настройки обоих наложений довольно много, рассмотреть их в рамках одного обзора не получится. Поэтому мы решили разобрать работу наложений на примерах. Сначала мы разберём "стандартные" варианты настройки наложений dynlist и autogroup для построения каталогов с динамическим содержимым, а затем — несколько нетривиальных конфигураций, в которых динамические объекты строятся на основе статических групп каталога.