|
|
ru.unix- RU.UNIX ---------------------------------------------------------------------- From : Constantin Stefanov 2:5020/400 25 Feb 2004 16:29:52 To : Victor Sudakov Subject : Re: openldap, TheBat, русский язык -------------------------------------------------------------------------------- Victor Sudakov wrote: >>>>>Такой еще вопрос - в какой objectclass лучше всего поместить записи >>>>>типа "Приёмная", "Диспетчер" и т.п.? IMHO логично было бы в >>>>>organizationalUnit или organizationalRole соответственно, но в этих >>>>>классах нет атрибута mail, а стандартные схемы корёжить не хочется. >>>> >>>>А ты не путаешь objectlclass и attributetype? >>> >>>Я не знаю, что такое attributetype. Может, и путаю. >> >>attributetype - это те самые dn, telephoneNumber и т.д. А objectclass - >>говорит, какие у записи должны быть атрибуты, а какие могут быть. > > Значит, не путаю. Мне нужно, чтобы у объекта "Приёмная" могли > одновременно быть атрибуты ou, telephoneNumber и mail. Hасколько я понял, > ни в одном из готовых классов (которые идут в > /usr/local/etc/openldap/schema), такое сочетание не предусмотрено. > >>Тебе Александр Лунев написал пару вариантов, могу с ним только >>согласиться. Я бы лично сделал доп. objectclass, у которого только один >>атрибут - mail, и дописывал бы его к нужным записям. А что касаемо > > Видишь ли, в openldap 1.x было довольно легко создавать собственные > схемы, а в 2.x я пока не разобрался, как это делается. В частности, > непонятно откуда брать OID-ы для своих схем. В 1.x можно было в конце > концов вообще поставить "schemacheck off" и писать в entries что в > голову взбредёт. > > Вот ты бы "сделал доп. objectclass" - а OID откуда бы взял? Тут два пути. Посложнее - как написано в доке к openldap - получить себе ветку OID. Попроще - взять приватную (1.1, если мне не изменяет память, в доке опять же написано), и делать там что хошь, только не рапространять эти схемы. >>канона - ты ж не хочешь от схемы реляционной БД каноничности (в том >>смысле, что здесь). Я лично думаю, что лучше сделать, чтоб работало и >>было логично, чем втискивать свои реалии в придуманные другими схемы. >>Иногда они подходят - хорошо, иногда - нет, тогда делаешь свою и не >>напрягаешься. > > Можно еще вопрос? От 1.x осталась адресная книга с записями вида > > dn: cn=Ivanov I.I., o=COMPANY, c=RU > objectclass: user > sn: Ivanov I.I. > cn: Ivanov I.I. > o: COMPANY > c: RU > mail: ivanov@COMPANY.RU > > Как бы её на время миграции запихать в 2.x ? Проблема в том, что я > опять-таки не нашёл классов, в которых было бы разрешено > вышеперечисленное описание атрибутов, в частности "c". Hу как я понял, класс user самодельный, так что тебе, в общем, ничего не мешает состряпать аналогичный класс, в котором все эти attributetype будут MUST или MAY - по ситуации. Что касаемо атрибута 'c', то он есть в классе country. Вообще, рекомендую для всех своих атрибутов пройтись grep'ом по файлам со стнадратными схемами - разберешься, что где есть стандартно, может, и поймешь, как это лучше сделать (или ты уже это сделал? - тогда не совсем ясно, откуда вопрос с 'c'). А вот попутно у меня возник вопрос - а ты уверен, что тебе в этом объекте действительно нужны атрибуты 'c' и 'o'? Просто я себе с трудом прдесталяю сущность из реального мира, которая обладает атрибутами имени, имени компании и имени страны одновременно ('c' и 'o' - это же укороченные алиасы). может, стоит подумать, а все ли атрибуты тебе нужны? Особенно, если они одинаковые у всех объектов. Впрочем, это зависит от конкретной ситауции. -- Константин Стефанов --- ifmail v.2.15dev5.3 * Origin: Demos online service (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.unix/6577e0520aef.html, оценка из 5, голосов 10
|