The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Интерактивная система просмотра системных руководств (man-ов)

 ТемаНаборКатегория 
 
 [Cписок руководств | Печать]

slapd-sock (5)
  • >> slapd-sock (5) ( Русские man: Форматы файлов )
  •  

    НАЗВАНИЕ

    slapd-sock - механизм манипуляции данными и наложение для slapd сокет  

    ОБЗОР

    /usr/local/etc/openldap/slapd.conf  

    ОПИСАНИЕ

    Механизм манипуляции данными для slapd(8) сокет использует внешнюю программу для обработки запросов, по аналогии с slapd-shell(5). Однако в данном случае внешняя программа ожидает соединения на сокете домена UNIX. Это дает возможность иметь пул процессов, которые сохраняются от запроса к запросу, что позволяет осуществлять многопоточность и обеспечивать более высокий уровень эффективности. Внешняя программа должна быть запущена отдельно, slapd(8) не заботится об её запуске.

    Этот модуль также может использоваться как наложение поверх некоторой другой базы данных. Использование в качестве наложения позволяет инициировать внешние действия в ответ на операции с основной базой данных.  

    КОНФИГУРАЦИЯ

    Приведённые ниже директивы slapd.conf применяются к базам данных механизма манипуляции данными SOCK. То есть, они должны следовать за строкой "database sock" и находиться до последующих строк "backend" или "database". Другие относящиеся к базам данных директивы описаны в man-странице slapd.conf(5).

    Для использования этого модуля в качестве наложения, данные директивы должны следовать за строкой "overlay sock" в существующем определении базы данных.

    extensions [ binddn | peername | ssf | connid ]*
    Включает отправку дополнительных мета-атрибутов с каждым запросом.
    binddn: <DN, от имени которого выполнено подсоединение>
    peername: IP=<адрес>:<порт>
    ssf: <значение SSF>
    connid: <идентификатор соединения>
    
    socketpath <путь_к_сокету>
    Задаёт путь к сокету домена Unix, в который будут отправляться команды и из которого будут приниматься ответы.

    При использовании в качестве наложения определены следующие дополнительные директивы:

    sockops [ bind | unbind | search | compare | modify | modrdn | add | delete ]*
    Определяет, какие типы запросов отправлять во внешнюю программу.
    По умолчанию список пуст (никаких запросов не отправляется).
    sockresps [ result | search ]*
    Определяет, какие типы ответов отправлять во внешнюю программу. В варианте "result" отправляются только результаты операций. В варианте "search" отправляются все записи, которые вернула база данных в ответ на запрос search. По умолчанию список пуст (никаких ответов не отправляется).

     

    ПРОТОКОЛ

    Протокол, по существу, тот же, что и у механизма slapd-shell(5), с добавлением новой строки, свидетельствующей о завершении параметров команды. Могут быть отправлены следующие команды:
    ADD
    msgid: <идентификатор сообщения>
    <повторение { "suffix:" <DN суффикса базы данных> }>
    <запись в формате LDIF>
    <пустая строка>
    

    BIND
    msgid: <идентификатор сообщения>
    <повторение { "suffix:" <DN суффикса базы данных> }>
    dn: <DN>
    method: <номер метода>
    credlen: <длина <учётных данных>>
    cred: <учётные данные>
    <пустая строка>
    

    COMPARE
    msgid: <идентификатор сообщения>
    <повторение { "suffix:" <DN суффикса базы данных> }>
    dn: <DN>
    <атрибут>: <значение>
    <пустая строка>
    

    DELETE
    msgid: <идентификатор сообщения>
    <повторение { "suffix:" <DN суффикса базы данных> }>
    dn: <DN>
    <пустая строка>
    

    MODIFY
    msgid: <идентификатор сообщения>
    <повторение { "suffix:" <DN суффикса базы данных> }>
    dn: <DN>
    <повторение {
        <"add"/"delete"/"replace">: <атрибут>
        <повторение { <атрибут>: <значение> }>
        -
    }>
    <пустая строка>
    

    MODRDN
    msgid: <идентификатор сообщения>
    <повторение { "suffix:" <DN суффикса базы данных> }>
    dn: <DN>
    newrdn: <новое RDN>
    deleteoldrdn: <0 или 1>
    <если указана новая вышестоящая запись: "newSuperior: <DN>">
    <пустая строка>
    

    SEARCH
    msgid: <идентификатор сообщения>
    <повторение { "suffix:" <DN суффикса базы данных> }>
    base: <базовое DN>
    scope: <0-2, смотрите ldap.h>
    deref: <0-3, смотрите ldap.h>
    sizelimit: <ограничение по размеру>
    timelimit: <ограничение по времени>
    filter: <фильтр>
    attrsonly: <0 или 1>
    attrs: <"all" или разделённый пробелами список атрибутов>
    <пустая строка>
    

    UNBIND
    msgid: <идентификатор сообщения>
    <повторение { "suffix:" <DN суффикса базы данных> }>
    <пустая строка>
    

    Все эти команды, - за исключением unbind, - должны выдавать:

    RESULT
    code: <целое число>
    matched: <совпавшее DN>
    info: <текст>
    
    (обязательна только строка RESULT), и затем закрыть сокет. В ответе команды search перед строкой RESULT должны следовать записи в формате LDIF, за каждой из которых добавляется пустая строка. Строки, начинающиеся с `#' или `DEBUG:' игнорируются.

    При использовании в качестве наложения внешняя программа должна вернуть ответ CONTINUE, если обработка запроса должна продолжиться нормальным способом; либо вернуть обычный ответ RESULT, если внешняя программа хочет обойти обработку результатов механизмом манипуляции данных той базы данных, к которой применяется наложение.

    Если наложение настроено на отправку ответных сообщений во внешнюю программу, такие сообщения будут представлены как расширенное сообщение RESULT или сообщение ENTRY, определённые ниже. Сообщение RESULT аналогично приведённому ранее, но включает также поле msgid и любые сконфигурированные расширения (смотрите директиву extensions):

    RESULT
    msgid: <идентификатор сообщения>
    code: <целое число>
    matched: <совпавшее DN>
    info: <текст>
    <пустая строка>
    

    Как правило, для сопоставления сообщения результата с запросом требуется как поле msgid, так и поле connid. Сообщение ENTRY имеет форму:

    ENTRY
    msgid: <идентификатор сообщения>
    <запись в формате LDIF>
    <пустая строка>
    

     

    КОНТРОЛЬ ДОСТУПА

    Механизм манипуляции данными sock не соблюдает все семантики ACL, описанные в man-странице slapd.access(5). В общем случае, доступ к объектам проверяется с использованием фиктивного объекта, который содержит только DN, поэтому правила доступа, основанные на анализе содержимого объекта, не выполняются. В частности:

    Для операции add не требуется иметь доступ write (=w) к псевдо-атрибуту children родительской записи.

    Для операции bind требуется доступ auth (=x) к псевдо-атрибуту entry той записи, идентификационная сущность которой оценивается; доступ auth (=x) к удостоверяющим данным не проверяется, а делегируется программе, обрабатывающей запросы.

    Для операции compare требуется доступ compare (=c) к псевдо-атрибуту entry того объекта, в котором находится значение, подвергающееся сравнению; доступ compare (=c) к атрибуту, значение которого подвергается сравнению, не проверяется.

    Для операции delete не требуется иметь доступ write (=w) к псевдо-атрибуту children родительской записи.

    Для операции modify требуется доступ write (=w) к псевдо-атрибуту entry; доступ write (=w) к конкретным атрибутам, которые подвергаются модификации, не проверяется.

    Для операции modrdn не требуется иметь доступ write (=w) к псевдо-атрибутам children как текущей, так и новой родительской записи, если они различны; доступ write (=w) к отличительным значениям атрибутов именования не проверяется.

    Для операции search не требуется иметь доступ search (=s) к псевдо-атрибуту entry базовой записи поиска; доступ search (=s) к атрибутам и значениям, используемым в поисковых фильтрах, не проверяется.

     

    ПРИМЕР

    Пример скрипта находится в директории slapd/back-sock/ дерева исходных кодов OpenLDAP.  

    ФАЙЛЫ

    /usr/local/etc/openldap/slapd.conf
    конфигурационный файл slapd по умолчанию.
     

    СМОТРИТЕ ТАКЖЕ

    slapd.conf(5), slapd-config(5), slapd(8).  

    АВТОР

    Brian Candler, с улучшениями от Howard Chu


     

    Index

    НАЗВАНИЕ
    ОБЗОР
    ОПИСАНИЕ
    КОНФИГУРАЦИЯ
    ПРОТОКОЛ
    КОНТРОЛЬ ДОСТУПА
    ПРИМЕР
    ФАЙЛЫ
    СМОТРИТЕ ТАКЖЕ
    АВТОР


    Поиск по тексту MAN-ов: 




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру