Ознакомьтесь с нашей политикой обработки персональных данных
14:09 

Как научиться работать с LDAP?

Ответом на это, разумеется, может быть только RTFM.
А именно, лучшей книгой в онлайн на эту тему, бесспорно, является опубликованный на сайте zytrax.com хрестоматийный учебник "LDAP for Rocket Scientists". Несерьёзное название книги полностью соответствует стилю изложения: лёгкому, слегка ироничному и максимально доходчивому. Собственно. авторы просто не хотели называть её "LDAP для Чайников" - это было бы похоже на моветон, да и сразу понижало бы в глазах потенциального читателя важность и полезность данной работы.
Читать учебник от корки до корки особого смысла, на мой взгляд, не имеет: он содержит множество примеров и различной практически полезной информации, так что "если срочно" (а оно почти всегда так и бывает), ищите в нём ответы на свои конкретно поставленные вопросы, да обрящете. Во всяком случае, зачастую это куда полезнее чтения сильно фрагментированного, непоследовательного, находящегося в перманентном состоянии дописывания руководстве OpenLDAP Administration Guide, и это даже при том, что после "LDAP for Rocket Scientists" именно документация проекта OpenLDAP является, на мой взгляд, наиболее толковой.
P.S. Я очень признателен Zytrax'у за выложенные на их сайте книги, и не только по LDAP, но и по DNS-серверу ISC BIND, например. Зитракс - это вообще отличный пример того как коммерческий проект может без каких-то значительных вложений сделать полезное и нужное дело для всех.

URL
Комментарии
2010-08-20 в 17:08 

vimax: да, я тоже читаю этот затрах :). Но изеначально поднять лдап на сервере мне помогла только Ваша статейка тут.. всё по порядку изложено! спасибо

URL
2010-08-21 в 03:45 

На Зитраксе старый подход изложен, там, конечно, всё несколько размазано и slapd.conf-ориентировано :)
P.S. Кстати, сейчас вникаю в QNX с азов буквально, но думаю, что первым софтом, установленным там, будет OpenLDAP и BASH :) Как только что-нить получится, отпишусь. Тема QNX+LDAP явно ещё нераскрыта...

URL
2010-08-21 в 03:48 

Кстати, а почему затрах? Вообще действительно Zytrax с точки зрения классического инглиша произносится как Зитракс или как Зайтракс?.. Вот ё-моё, придётся старые учебники инглиша доставать с антресолей

URL
2010-08-26 в 10:24 

Конечно же зитракс, ну просто название шибко говорящее само за себя :))) Литература там хорошая. Знаете, у нас большая организация. Филиалы разбросаны по всему миру. Ужасно не нравится, что все страны (а то и фидиалы в городах) придумывают для себя собственные базы данных, для хранения информации. Как такового скелета для базы нет, поэтому хочу попробовать LDAP.
Информация однозначно должна быть связана между странами, поэтому решил делать одну базу для всех. Частота обновления полей в базе не критиична..
Вы мне можете что-нибудь посоветовать?

URL
2010-08-26 в 10:31 

vimax: забыл сказать. Сейчас у нас из общих распределенных ресурсов есть только почтарь от Билли (Exchange Server) с его адресной книгой. И еще есть система Lotus Notes. Один программист за бугром в своё время начинал что-то писать на лотусе.. вроде что-то вышло нормально.. по сей день работает у всех.. но это капля в море, по сравнению с тем, что нужно сделать.

p.s. недавное поработал немного с модулем php-ldap. Получилось. Теперь мое желание работать через веб непреодолимо )))

URL
2010-08-30 в 08:45 

Да, vimax, знакомая ситуация...
Сам по себе распределённый каталог сделать несложно, лучше через механизм прокси (где-то я уже писал об этом в начале блога), а не рефералами. По сути всё упирается, как обычно в случае с LDAP, - в клиентское ПО. Сможет ли тот же Exchange использовать что-либо, кроме AD? Насколько специфичны атрибуты, которые хочет увидеть Lotus Notes в каталоге, где взять этот кусок схемы, чтобы его прикрутить к OpenLDAP (OpenDS, ApacheDS или чему угодно ещё).
Интеграция на мой взгляд не может быть односторонней - вроде как сделали глобальное хранилище общей для всех приложений информации, а потом сказали приложениям его использовать (такое бывает только в идеальном мире), интеграция всё-таки должна предусматривать ревизию софта на предмет целесообразности его использования (а то часто бывает так, что сложные и дорогие программные комплексы используют как микроскоп для забивания гвоздей) и трудности/возможности его замены в случае, если оно ну никак не хочет куда бы то ни было интегрирооваться.
Кстати, а у вас сервер Lotus Domino есть сейчас? Notes - это, если я не ошибаюсь, просто клиентская часть этого сервера. А у сервера есть собственный встроенный LDAP-каталог...

URL
2010-09-05 в 20:10 

vimax: Сервер Domino есть. Он стоит в Женеве и его пользуют все клиенты тоже толи через прокси толи через рефералы.. Наш лотус конектится к московскому домино серверу. У нас сейчас в этом лотусе хранятся все наши клиенты и еще какая-то информация. Юзеры берут оттуда UID клиента, создают там UID заказа и вообщем все на этом. Бухгалтера туда ещё какую-то инфу по заказу скидывают. Короче, этот лотус нужен чтобы хозяин видел "всё". Для него это может и нормально, но для работников это ужасно.Они ведут свои "расширенные" базы и должны их как-то состыковывать с основной.. везде свои выдуманные базы..у кого на листочках, у кого в экселевских файлах, у когол просто в голове :).
Теперь по поводу интеграции. Она и не нужна. Хочу сделать всё с нуля для России... потом может быть и дальше уйдёт. А с выгрузкой некоторых данных в лотус что-нибудь придумаю :). Сейчас используется Лотус версии ещё со времен динозавров. Он старинный и глючный. Обновление на всю организацию стоит баснословных денег. Обновлять не будут. У нас антивирусов нормальных нет даже.. Макафи юзают все офисы. Макафи тоже стариннный.. пропускает 50% заразы.
Я вообще программист. Работать с LDAP из своих приложений научусь (если не решу вообще всё в вебе сделать).
Ну так вот, хочу сделать базу с нуля. Где будут хранится: свой классификатор заказчиков, улиц, заказов, инвентаризация всякая... ну и собственно всякие данные, касаемые нашей деятельности...всё-всё.всё.
Можно кое-что взять из стандартных схем, но однозначно там нет специфичных для нашей деятельности полей(узлов..или как там их :) ).
Я думаю никакие сторонние программные средства не будут использоваться с этой базой (разве что может быть когда нибудь я захочу переместить туда аутентификацию для почты, домена). Поэтому наверное придётся делать свою схему.

Как Вы считаете, в правильном направлении я мыслю?

p.s. Снача была идея сделать реляционным базы во всех филиалах и реплицировать их.

URL
2010-09-08 в 17:17 

Здесь главный вопрос: какую структуру имеет база данных. Если она имеет чётко выраженную иерархическую структуру, такую, что хоть файловую систему из этих данных строй, то LDAP - лучший выбор. Если она не совсем иерархическамя, но с помощью виртуальных групп и алиасов можно как-то всё собрать в иерархию и при этом всё оправдывается распределённостью базы, то в общем тоже LDAP. Для любой модели со сложными взаимосвязями и произвольными запросами (общего случая сетевой) LDAP не годится.
Кстати, LDAP может быть костяком всей структуры, но содержать внешние ссылки на базы данных. То есть каталог можно представить как скелет и неврную систему, на который подвешиваются "мышцы" -реляционные СУБД. Конечно, при этом нужен "головной мозг" - то есть софт, умеющий ходить по ссылкам из каталога в базы данных и приводить всю эту структуру в "движение".

URL
2010-09-14 в 18:24 

vimax: хочу спроектировать базу таким образом, чтобы она получилась иерархическая. Сотрудникам, данным лабораторий, данным бухгалтеров и т.п. хочу присвоить уникальные идентификаторы. Таким образом я обеспечу ссылочную целостность.
А описание объекта будет обеспечиваться за счёт членства его в той или иной группе. Очень нравиться идея с Member и MemberOf.
Например
ou=People
uid=123123
cn=Ivanov Ivan
MemberOf= ou=Filials,ou=Samara
MemberOf= ou=Operators
MemberOf= ou=WorkPlaces,ou=Самарский завод 1
....

Каждая из этих групп, естествеено, имеет этот uid в узле "Member".
Таким образом обеспечиться быстрый и "легкий" для базы и клиентского ПО доступ ко всем данным.
Мне кажется тут и схем стандартных особо использовать и не нужно. самому сделать какую-нибудь простенькую. Может я что-то не понимаю. Я только учу LDAP.

Это будет глобальная база предприятия. А локальные "особенные" данные можно прикрутить в реляционной базе и реплицировать как-то.

p.s. А для чего при создании схемы нужно регистрировать и получать уникальный номер параметров на каком-то сайте...? это чтобы другие люди могли пользоваться этой схемой что ли?

URL
2010-09-15 в 03:57 

С учётом того, что memberOf заполняется OpenLDAP автоматически, членством в группах и правда очень удобно становится управлять полностью, поддерживаю ваше начинание :)
Схему регистрировать не нужно, так же как, откровенно говоря, в 99 случаях из 100 её не следует и создавать. Создание новой схемы сразу же уводит вас из области строгих стандартов в область велосипедостроения, а последняя уже ближе к тому бардаку, который вечно царит в SQL. Вам нужно сначала узнать, какие подходящие классы объектов и атрибуты уже существуют и только в крайнем случае .создавать свои. И конечно иногда лучше использовать уже зарегистрированный тип атрибута/класс объекта с неидеально подходящим именем, но нужным синтаксисом, нежели придумывать схему.
Ну а с практической точки зрения - могу привести пример своего бывшего начальника, который накатал собственную схему под совершенно типовую задачу и даже не проверил, используются его OID'ы в какой-либо из распространённых схем или нет. Оказалось, что используются... Конечно, это нестрашно, просто противоречит самой концепции каталогов.

URL
2010-09-18 в 00:40 

vimax: Проверьте меня пожалуйста, правильно ли я мыслю:

Корень первого дерева - это список уникальных идентификаторов людей.
класс "groupOfUniqueNames" для этого подойдет?

*** objectclass ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL
*** MUST ( uniqueMember $ cn )
*** MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )

Получиться что-то вроде

cn=People (это и будет DN?)
description="Здесь находятся все сотрудники предприятия"
uniqueMember=123
uniqueMember=456
uniqueMember=789
...

или же нужно использовать какой-то другой класс? например "uidObject"

*** # From RFC2377
*** objectclass ( 1.3.6.1.1.3.1 NAME 'uidObject'
*** DESC 'RFC2377: uid object'
*** SUP top AUXILIARY MUST uid )

или надо использовать несколько классов?..вроде uidObject + Person + organizationalUnit и тогда картина будет такой:

ou=People (классы uidObject + organizationalUnit)
description="Здесь находятся все сотрудники предприятия"
uid=123
uid=456
uid=789

ou=People,uid=123 (классы uidObject + Person)
cn=Иван
sn=Иванов


Теперь если я создам другую группу и добавлю туда членов из группы ou=People:

ou=Laboratory1 (классы organizationalUnit + groupOfNames)
description="Лаборатория первая"
member=ou=People,uid=123
member=ou=People,uid=456

то у меня к записяи в ou=People автоматом добавится MemberOf?:

ou=People,uid=123
MemberOf=ou=Laboratory1

ou=People,uid=456
MemberOf=ou=Laboratory1

URL
2010-09-18 в 04:02 

Вот в первую очередь рекомендую почитать: diary.ru/~ldap/p75630304.htm
Сегодня я дополнил этот пост полезными ссылками

URL
   

LDAP - заметки на полях

главная