Смена Syntax для аттрибута

[мережевий хробачок™]

Привет.

У нас есть два LDAP сервера: наш, локальный - на OpenLDAP, и IBM Directory Server for IBM i (LDAP) - у заказчика.

Между ними есть различия в описании аттрибута uniqueMember.

Локальный OpenLDAP:



LDAP заказчика:



В файле схемы /etc/openldap/schema/core.schema аттрибут uniqueMember описан как:

Код: [Выделить]

attributetype ( 2.5.4.50 NAME 'uniqueMember'
        DESC 'RFC2256: unique member of a group'
        EQUALITY uniqueMemberMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
Где 1.3.6.1.4.1.1466.115.121.1.34 - и есть искомый 1.3.6.1.4.1.1466.115.121.1.34 - Name and Optional UID syntax, тогда как нам нужен 1.3.6.1.4.1.1466.115.121.1.12 - Distinguished Name syntax.

Собственно - вопрос. Как его можно изменить?

Нагуглить получилось вот это>>>, где говорится, что:

> One cannot change the syntax definition of an attribute in the schema when that attribute is already populated with data. The data need to be unloaded/backed up (e.g , in an LDIF file perhaps) first. The schema changes can be done after that. The data then can be reloaded with the new syntax

Т.е. - просто изменить OID в файле схемы - нельзя, т.к. это затронет (поломает?) уже имещиеся данные (что, в принципе, логично).

Так ли это? Так как на нашем LDAP-сервере уже достаточно много баз, и лишнего геморроя не хочется...

Спасибо за подсказки.

[egor]

Здравствуйте, Арсений! Как всегда, в первую очередь нужно решить вопрос не как что-то сделать, а зачем, а точнее с какой целью это сделать. Если сравнить описания синтаксисов DN и Name and Optional UID в RFC 4517, то очевидно, что оба синтаксиса подразумевают совпадение с distinguishedName, только в последнем добавляется НЕОБЯЗАТЕЛЬНЫЙ идентификатор на случай, если уникальные имена записей совпадут. Не могу представить, когда в нормальном каталоге такой случай может настать =) . Так что если Ваша задача что-то отработать у себя, а затем залить в чужой каталог, то не вижу смысла что-то предпринимать: Вы же будете хранить в этом атрибуте DN записей и никаких противоречий в данных не наступит. Если у Вас какая-то специфичная задача, то напишите подробнее, попробуем разобраться.

Кстати, в OpenLDAP, как обычно, следуют стандартам, и uniqueMember у них определен строго по RFC 4519. В IBM, видимо, решили "сэкономить" и не вводить синтаксис, вероятность совпадения с которым стремится к нулю.

Егор.

[мережевий хробачок™]

Егор, спасибо за ответ.

Касаемо "зачем" - я понятия не имею :-)

Знаю только, что приложение, которое разрабывается нами, не будет корректно работать из-за этих самых разных OID.
Потому - разработчики попросили заменить на локальном LDAP-е конфигурацию.

[Narcom]

День добрый всем.
Всё прозаично как обычно. Дело в том что проверка по стандарту не дает создать пустую группу. Тоесть группу с пустым аттрибутом uniqueMember.
А сервера IBM дают это сделать, уж незнаю по умолчанию они так настроены или по "злому" умыслу.
Соостетственно код не может работать одинаково на тестовой среде и на релизной.
Что бы уменьшить количество багов и оценить узкие места мы подгоняем тестовый сервер под релизный.

[мережевий хробачок™]

Что ещё интересно, заметил - что distinguishedName вообще закомментирован в /etc/openldap/schema/core.schema, хотя ссылки к нему, как родительскому, есть в описании многих атрибутов:

Код: [Выделить]

attributetype ( 2.5.4.31 NAME 'member'
        DESC 'RFC2256: member of a group'
        SUP distinguishedName )

Код: [Выделить]

# system schema
#attributetype ( 2.5.4.49 NAME 'distinguishedName'
#       EQUALITY distinguishedNameMatch
#       SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

[egor]

Здравствуйте!

Всё прозаично как обычно. Дело в том что проверка по стандарту не дает создать пустую группу. Тоесть группу с пустым аттрибутом uniqueMember.
А сервера IBM дают это сделать, уж незнаю по умолчанию они так настроены или по "злому" умыслу.
Соостетственно код не может работать одинаково на тестовой среде и на релизной.
Что бы уменьшить количество багов и оценить узкие места мы подгоняем тестовый сервер под релизный.

Вам тогда стоит смотреть не в сторону изменения синтаксиса, а в сторону изменения объектного класса groupOfUniqueNames -- перевести атрибут uniqueName из разряда MUST в разряд MAY. При настройках через slapd.conf, думаю, достаточно просто поменять core.schema и перезапустить slapd. Не стоит это делать на боевом сервере -- для любых экспериментов лучше иметь виртуалку, либо, на худой конец, запускать экспериментальный каталог на другом порту того же сервера.

Что ещё интересно, заметил - что distinguishedName вообще закомментирован в /etc/openldap/schema/core.schema, хотя ссылки к нему, как родительскому, есть в описании многих атрибутов:
attributetype ( 2.5.4.31 NAME 'member'
        DESC 'RFC2256: member of a group'
        SUP distinguishedName )

При описании синтаксисов речь идёт не о типах атрибутов, а о правилах составления значений атрибутов.  В Вашем же примере  SUP distinguishedName означает, что тип атрибута member является потомком от типа атрибута  distinguishedName, а сам  distinguishedName, вероятно, прошит в самом коде slapd как требуемый для cn=config конфигурации.

Егор

[мережевий хробачок™]

Здравствуйте!
в сторону изменения объектного класса groupOfUniqueNames -- перевести атрибут uniqueName из разряда MUST в разряд MAY. При настройках через slapd.conf, думаю, достаточно просто поменять core.schema и перезапустить slapd.
Егор

Не совсем понял, при чём в данном случае groupOfUniqueNames (ведь uniqueMember от неё не зависит?) - но ОК.

Есть у нас такой:

Код: [Выделить]

objectclass ( 2.5.6.17 NAME 'groupOfUniqueNames'
        DESC 'RFC2256: a group of unique names (DN and Unique Identifier)'
        SUP top STRUCTURAL
        MUST ( uniqueMember $ cn )
        MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
Помню, что изначально делал на slapd.conf, потом перенёс в cn=config. Если не ошибаюсь - при "перезде" на cn=config - файлы схем конвертируются в отдельные ldif-ы.

Т.е. - в данном нашем случае, это:

Код: [Выделить]

# cat /etc/openldap/slapd.d/cn=config/cn=schema/cn={1}core.ldif | grep -A3 groupOfUniqueNames
olcObjectClasses: {15}( 2.5.6.17 NAME 'groupOfUniqueNames' DESC 'RFC2256: a gr
 oup of unique names (DN and Unique Identifier)' SUP top STRUCTURAL MUST ( uni
 queMember $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ descript
 ion ) )
Идея проста - забекапить базы, забекапить ldif, отредактировать, перезапустить, проверить.

[egor]

Здравствуйте!

Не совсем понял, при чём в данном случае groupOfUniqueNames (ведь uniqueMember от неё не зависит?) - но ОК.

Дело в том, что обязательность появления атрибута в записи (в данном случае атрибута членства в групповой записи) зависит не от синтаксиса типа атрибута, а от определения того объектного класса, на котором строится запись. Именно поэтому нужно изменить определение объектного класса groupOfUniqueNames чтобы атрибут uniqueMember стал необязательным.

Идея проста - забекапить базы, забекапить ldif, отредактировать, перезапустить, проверить.

Попробовали?

Егор

[мережевий хробачок™]

Попробовали?

Егор

Ещё нет. Вчера только насетапить новый сервер успел и базу перенести.
Сделал пока на slpad.conf (дело было к вечеру - хотедось побыстрее :-) ), перенесу на OLC, и буду пробовать.

Насколько успел вчера нагуглить - напрямую ldif (в данном случае это /etc/openldap/slapd.d/cn=config/cn=schema/cn={1}core.ldif ) править не надо, надо через ldapmodify. Т.е. - запилить новый ldif  с измененными данными, и его "скормить" через ldapmodify -f. Верно?

UPD только что протестили на slapd.conf. Изменил:

Код: [Выделить]

objectclass ( 2.5.6.17 NAME 'groupOfUniqueNames'
        DESC 'RFC2256: a group of unique names (DN and Unique Identifier)'
        SUP top STRUCTURAL
        MUST ( uniqueMember $ cn )
        MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
на:

Код: [Выделить]

objectclass ( 2.5.6.17 NAME 'groupOfUniqueNames'
        DESC 'RFC2256: a group of unique names (DN and Unique Identifier)'
        SUP top STRUCTURAL
        MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description $ uniqueMember $ cn ) )
в /etc/openldap/schema/core.schema.

Вроде полёт нормальный, помогло. Осталось поправить на OLC-конфиге.

[egor]

Здравствуйте, Арсений!

Я бы оставил хотя бы cn в MUST -- класс-то структурный.

Егор

[мережевий хробачок™]

Здравствуйте, Арсений!

Я бы оставил хотя бы cn в MUST -- класс-то структурный.

Егор

Да, хороший поинт, спасибо :-)

В целом - сделал по подсказке отсюда.

Всё заработало под OLC:

Код: [Выделить]

# cat /etc/openldap/slapd.d/cn=config/cn=schema/cn={1}core.ldif | grep -A3 groupOfUniqueNames
olcObjectClasses: {15}( 2.5.6.17 NAME 'groupOfUniqueNames' DESC 'RFC2256: a gr
 oup of unique names (DN and Unique Identifier)' SUP top STRUCTURAL MUST ( cn
 ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description $ uniqueMem
 ber ) )
Разработчик подтвердил, создание групп работает.

Не понимаю одного - раз меняется ldif-файл схемы, какая разница - пилить через создание отдельного ldif и потом ldapmodify (а именно так рекомендуется во всех нагугленных примерах), или напрямую отредактировать файл /etc/openldap/slapd.d/cn=config/cn=schema/cn={1}core.ldif?

Не так давно менял пароль cn=root,cn=config прямо в файле /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif - всё работает.

Anyway - Егор, спасибо.

[egor]

Не понимаю одного - раз меняется ldif-файл схемы, какая разница - пилить через создание отдельного ldif и потом ldapmodify (а именно так рекомендуется во всех нагугленных примерах), или напрямую отредактировать файл /etc/openldap/slapd.d/cn=config/cn=schema/cn={1}core.ldif?

Разницы 3:
1. ldapmodify можно использовать удалённо или когда нет прямого доступа к файловой системе.
2. ldapmodify защищает "от дурака": выдаёт ошибку при неправильной модификации и изменение не проходит.
3. Перед правкой файлов нужно отключать slapd, а при ldapmodify всё online.

Егор

[мережевий хробачок™]

Разницы 3:
1. ldapmodify можно использовать удалённо или когда нет прямого доступа к файловой системе.
2. ldapmodify защищает "от дурака": выдаёт ошибку при неправильной модификации и изменение не проходит.
3. Перед правкой файлов нужно отключать slapd, а при ldapmodify всё online.

Егор

Ещё раз спасибо :-)