The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз LDAP-сервера ReOpenLDAP 1.2.0, opennews (??), 08-Сен-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


36. "Релиз LDAP-сервера ReOpenLDAP 1.2.0"  +1 +/
Сообщение от erthink (ok), 09-Сен-22, 09:12 
> Один вопрос - можно ли в принципе приспособить LDAP в качестве general-purpose
> базы данных?

Да..., но...

> Например, конторе на вход поступают данные в виде XMLек, там само собой
> вложенные и множественные тэги. Реализуемо ли как-то в рамках схемы (самописной
> конечно) LDAP повторить структуру XMLки особенно в части вложенности? У меня
> впечатление, что иерархия в таком виде в LDAP-модели данных невозможна? Может
> как-то objectclass'ами это нужно нагородить.

LDAP DIT - это расширенный key-value, где для ключей определена иерархия, а value состоит из набора обязательных и опциональны атрибутов.

> Или вот можно ли как-то на лету менять схему, как в SQL
> базах? Хотя бы дописав новую, расширяющую старую? Так же сложилось впечатление,
> что тут всё плохо.

Можно, но не всегда и не во всех LDAP-серверах, со всеми теми-же (часто неявными) проблемами что и в SQL.
В самом простом случае можно менять набор необязательных атрибутов.

Ответить | Правка | Наверх | Cообщить модератору

42. "Релиз LDAP-сервера ReOpenLDAP 1.2.0"  +/
Сообщение от mos87 (ok), 09-Сен-22, 09:36 
Спасибо за ответ.
> LDAP DIT - это расширенный key-value, где для ключей определена иерархия, а
> value состоит из набора обязательных и опциональны атрибутов.

да, но сформиулирую так - можно ли как-то сделать, чтобы KEY был лишь контейнером для других KEY?

со множественностью проблем нет это я понимаю (один ключ может повторяться сколько угодно, в соотв. со схемой конечно), а вот такая вроде бы нехитрая система с вложенностью - сколько ни гуглил такого не видел.

т.е. так например
cn=запись_номер_столько_то
|
--key (пусть будет передающая_организация)
| |
| -- тут key - value (к примеру номер или адрес там)
| |
| -- тут key - value (подразделение какое-нибудь)
| |
| -- тут key - value (номер лицензии скажем)
|
--key (работы выполненные в рамках передаваемой записи)
| |
| -- тут key - value (услуга)
| |
| -- тут key - value (выполнивший)
| | |
| | -- имя выполнившего - Иванов
| | |
| | -- должность - прораб
| -- тут key - value (номер договора какой-нибудь)

...

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

Может есть какие-то качественные ссылки, где люди описывают опыт не стандартной работы со схемами? Был бы благодарен.

Ответить | Правка | Наверх | Cообщить модератору

51. "Релиз LDAP-сервера ReOpenLDAP 1.2.0"  +3 +/
Сообщение от bOOster (ok), 09-Сен-22, 10:09 
Бери и создавай свою схему в разрезе всего что тут написал. основной затык у новичков вызывает создание индивидуальных OID. Где взять, как рассчитать. Ниче сложного нет.
1.3.6.1.4.1.4203.666.x.x.... - эта ветка считается экспериментальной/временной. Потом, если решение идет в массы - OID меняются уже на постоянные и уникальные.
Остальное все в доках. Мне как-то понадобилась централизованная авторизация/аутентификация для FreeSwitch IP PBX - пришлось сколхозить схему -
# Telephone Attributes
attributetype ( 1.3.6.1.4.1.4203.666.6273.2.1 NAME 'telephoneNumberAccessCode'
    DESC 'Access code for telephoneNumber services'
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.4203.666.6273.2.2 NAME 'faxDeliveryMailbox'
        EQUALITY caseIgnoreIA5Match
        SUBSTR caseIgnoreIA5SubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

attributetype ( 1.3.6.1.4.1.4203.666.6273.2.3 NAME 'voiceDeliveryMailbox'
    DESC 'Voice Mailbox'
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.4203.666.6273.2.4 NAME 'phoneGroupName'
    DESC 'Telephone Group Name'
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.4203.666.6273.2.5 NAME 'registrar'
        DESC 'The last serving registrar'
        EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

objectclass ( 1.3.6.1.4.1.4203.666.6273.2.100 NAME 'telephoneNumberAccount'
        DESC 'Telephone account'
        SUP top STRUCTURAL
        MUST ( telephoneNumber )
        MAY ( userPassword $ telephoneNumberAccessCode $ macAddress $ faxDeliveryMailbox $ registrar ) )

objectclass ( 1.3.6.1.4.1.4203.666.6273.2.101 NAME 'phoneGroup'
        DESC 'Telephone Group'
        SUP top STRUCTURAL
        MUST ( phoneGroupName )
        MAY ( telephoneNumber $ description ) )

# Autoprovision options
attributetype ( 1.3.6.1.4.1.4203.666.6273.4.1 NAME 'provisionDeviceName'
        DESC 'Autoprovision Device Name'
        EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.4203.666.6273.4.2 NAME 'provisionOptionName'
        DESC 'Autoprovision Option Name'
        EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.4203.666.6273.4.3 NAME 'provisionOptionValue'
        DESC 'Autoprovision Option Value'
        EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

objectclass ( 1.3.6.1.4.1.4203.666.6273.4.100 NAME 'autoprovisionRecord'
        DESC 'Autoprovision option record'
        STRUCTURAL
        MUST ( provisionDeviceName $ provisionOptionName )
        MAY ( provisionOptionValue ) )

# Autoprovision options end

В результате через OpenLDAP таскается все что для IP телефонии нужно, от аутентификации и авто-provisioning до автоматического роуминга телефонов - одна телефонная станция в одном офисе - сама знает на какой сервер в какой офис роутить звонок all over the world.

Ответить | Правка | Наверх | Cообщить модератору

74. "Релиз LDAP-сервера ReOpenLDAP 1.2.0"  +/
Сообщение от mos87 (ok), 09-Сен-22, 13:05 
спасибо, повтыкаю
Ответить | Правка | Наверх | Cообщить модератору

98. "Релиз LDAP-сервера ReOpenLDAP 1.2.0"  –1 +/
Сообщение от Ivan_83 (ok), 10-Сен-22, 02:01 
Античеловечный ASN.1.
Бинарные протоколы обречены иметь единичные реализации.
Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

100. "Релиз LDAP-сервера ReOpenLDAP 1.2.0"  +1 +/
Сообщение от aliechemail (?), 10-Сен-22, 02:59 
Только ldap об этом не знает. У него сильно больше одной реализации как серверов, так и клиентских частей есть.
Ответить | Правка | Наверх | Cообщить модератору

114. "Релиз LDAP-сервера ReOpenLDAP 1.2.0"  +/
Сообщение от bOOster (ok), 11-Сен-22, 10:08 
> Античеловечный ASN.1.
> Бинарные протоколы обречены иметь единичные реализации.

Для неосиляторов - любое решение "Нечеловечное".
А про единичные реализации - так ASN.1 пользуют X.500, LDAP, PKCS, SNMP, все телефонные 2G..5G, kerberos, и т.д. Еще десяток различных протоколов и решений.

Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

120. "Релиз LDAP-сервера ReOpenLDAP 1.2.0"  –1 +/
Сообщение от Ivan_83 (ok), 12-Сен-22, 00:50 
И всё это - какахи мамонта, которые неюзабельны.
SNMP хрень полная, где вечно надо бегать искать актуальные OID для каждой железки.
X.500 - мёртв просто.
PKCS - хреновина которая как то работает, её терпят потому что она обложена высокоуровнемыми АПИ.
kerberos - примерно в такой же Ж как и LDAP - полтора страдальца его юзают по своей воле.
Телефонный стёк - куча Г которая нынче используется как обычный WiFi основную часть времени.

Есть удачные решения, есть не удачные решения. ASN.1 относится к последним.
Есть IP, TCP, DNS, DHCP, RADIUS - они тоже бинарные но без избыточной сложности, и самое сложное что там нужно сделать это составить список опций коих не может быть больше 255 в принципе, у дхцп таких списков полтора.
У ASN.1 мало того что длина данных может идти после данных что делает написание безопасного парсера /валидатора затруднительным, так ещё рандомные OID с которыми непонятно что делать если ты их не ждал но встретил.
Даже XML более удачный формат получивший большее распространение.

Ответить | Правка | Наверх | Cообщить модератору

52. "Релиз LDAP-сервера ReOpenLDAP 1.2.0"  +1 +/
Сообщение от erthink (ok), 09-Сен-22, 10:14 
> Спасибо за ответ.
>> LDAP DIT - это расширенный key-value, где для ключей определена иерархия, а
>> value состоит из набора обязательных и опциональны атрибутов.
> да, но сформиулирую так - можно ли как-то сделать, чтобы KEY был
> лишь контейнером для других KEY?
> со множественностью проблем нет это я понимаю (один ключ может повторяться сколько
> угодно, в соотв. со схемой конечно), а вот такая вроде бы
> нехитрая система с вложенностью - сколько ни гуглил такого не видел.

Не уверен что могу понять что вы имели в виду, кроме как предположив что речь о составных ключах и/или индексах.

В LDAP это не обязательно, т.е. не требуется для соблюдения RFC (хотя их много и я точно не читал все). Соответственно, вы не можете рассчитывать на подобные возможности глядя на абстрактный LDAP-сервер.

С другой стороны, в (Re)OpenLDAP доступно определение составных индексов по атрибутам, в том числе с контролем уникальности. Плюс есть всяческие плагины/оверлеии типа MemberOf и виртуальных групп.

>[оверквотинг удален]
> | -- тут key - value (выполнивший)
> | | |
> | | -- имя выполнившего - Иванов
> | | |
> | | -- должность - прораб
> | -- тут key - value (номер договора какой-нибудь)
> ...
> Данные поступающие то вроде по большей части как раз иерархические, так что
> в качестве "фронта" вроде логично использовать не табличное хранилище. Но насколько
> тут приспособляем LDAP я пока не очень пойму...

И так тоже можно..., но насколько удобно решайте сами.
Также нужно не забывать, что LDAP не гарантирует ACID на уровне всего DIT, а только для отдельных элементов.


> Может есть какие-то качественные ссылки, где люди описывают опыт не стандартной работы
> со схемами? Был бы благодарен.

https://pro-ldap.ru/
Только смотреть/искать нужно не чей-то опыт, а вникать в возможности сервера, через примерны понимать как их настраивать, а затем (желательно) понимать как это работает внутри.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

73. "Релиз LDAP-сервера ReOpenLDAP 1.2.0"  +/
Сообщение от mos87 (ok), 09-Сен-22, 13:05 
> Не уверен что могу понять что вы имели в виду, кроме как
> предположив что речь о составных ключах и/или индексах.

Чтобы отражало такую нехитрую структуру (и подобные):

<?xml version="1.0" encoding="utf-8"?>
<LIST>
    <HEADER>
        <VERSION>3.2</VERSION>
        <DATE>2022-09-09</DATE>
        <FILENAME>incoming_example</FILENAME>
    </HEADER>
    <INVOICE>
        <ORG>123</ORG>
        <YEAR>2022</YEAR>
        <MONTH>9</MONTH>
    </INVOICE>
    <REC>
        <N_REC>1</N_REC>
        <THINGY>0</THINGY>
        <CLIENT>
            <ID_CLIENT>317</ID_CLIENT>
            <DOCNUM>2845738957349578</DOCNUM>
        </CLIENT>
        <EVENT>
            <IDEVENT>1</IDEVENT>
            <VARIOUS>1</VARIOUS>
            <TAGS>2</TAGS>
            <SERVICE>
                <IDSERV>1</IDSERV>
                <CODE>AAAAA</CODE>
                <SUB>
                    <SOME>1</SOME>
                    <TAGS>2</TAGS>
                </SUB>
            </SERVICE>
            <SERVICE>
                <IDSERV>2</IDSERV>
                <CODE>BBBBB</CODE>
                <SUB>
                    <SOME>1</SOME>
                    <TAGS>2</TAGS>
                </SUB>
            </SERVICE>
        </EVENT>
    </REC>
</LIST>

Само собой надо для разных данных придумать структуру DIT. Что dn'ом будет, и т.д. В системе много разных расшифровщиков типа "справочник" - вот они должны хорошо лечь на DIT (справочники же).

> Также нужно не забывать, что LDAP не гарантирует ACID на уровне всего
> DIT, а только для отдельных элементов.

Переживём.

> https://pro-ldap.ru/

Перевод зитракса? Ну дык я оригинал могу.
Он конечно обширный, но на данном этапе мене хотелось бы для себя уяснить, реализуемо ли в продакшне для насущных задач.. это другой коленкор. Чем просто поднять slapd.

> Только смотреть/искать нужно не чей-то опыт, а вникать в возможности сервера, через
> примерны понимать как их настраивать, а затем (желательно) понимать как это
> работает внутри.

Я как раз это понимаю. И даже не смотрю на криволапые гайды копирующие одно и то же друг у друга.
Я вообще поднимал OpenLDAP но не в продакшне, а в домашней сетке. Давно ещё. Завязывал для прикола разные сервисы на каталог - керберос с хранением его данных в дереве же, NFS4 с integrity и privacy, autofs, NIS-службы (аутентификация/авторизация с машин через sssd уже, хотя можно было и более традиционными клиентами логина), jabberd2 с расшаренным ростером (состоящих из семьи), и другое. По вот этой серии статей http://itdavid.blogspot.com/2012/05/howto-centos-6.html (сам удивился что нагуглил - было оч давно) - почему-то это оказалось очень толковым, в отличие от многих других.

Ответить | Правка | Наверх | Cообщить модератору

53. "Релиз LDAP-сервера ReOpenLDAP 1.2.0"  +1 +/
Сообщение от bOOster (ok), 09-Сен-22, 10:21 
а Key Value, индексация и все такое это уже относяться к реализации сервера - например OpenLDAP

olcDbIndex, dbIndex - там свой синтаксис описания например твое поле numLicence eq - система создаст индекс и значительно ускориться поиск numLicence - "строго идентичное совпадение".

Ну и т.п. - в доках реально все расжевано, только глотай

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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