Форум проекта Pro-LDAP.ru
Общие вопросы по LDAP => Схема данных, наборы Schema, объектные классы, атрибуты и другое => Тема начата: мережевий хробачок™ от 18 Август 2014, 16:12:17
-
Привет.
У нас есть два LDAP сервера: наш, локальный - на OpenLDAP, и IBM Directory Server for IBM i (LDAP) - у заказчика.
Между ними есть различия в описании аттрибута uniqueMember.
Локальный OpenLDAP:
(http://rtfm.co.ua/wp-content/uploads/ldap_local.JPG)
LDAP заказчика:
(http://rtfm.co.ua/wp-content/uploads/ldap_remote.JPG)
В файле схемы /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 (http://www.alvestrand.no/objectid/1.3.6.1.4.1.1466.115.121.1.34.html), тогда как нам нужен 1.3.6.1.4.1.1466.115.121.1.12 - Distinguished Name syntax (http://www.alvestrand.no/objectid/1.3.6.1.4.1.1466.115.121.1.12.html).
Собственно - вопрос. Как его можно изменить?
Нагуглить получилось вот это>>> (http://stackoverflow.com/questions/18356912/modify-attribute-type-definition-on-ldap-server), где говорится, что:
> 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-сервере уже достаточно много баз, и лишнего геморроя не хочется...
Спасибо за подсказки.
-
Здравствуйте, Арсений! Как всегда, в первую очередь нужно решить вопрос не как что-то сделать, а зачем, а точнее с какой целью это сделать. Если сравнить описания синтаксисов DN (http://tools.ietf.org/html/rfc4517#section-3.3.9) и Name and Optional UID (http://tools.ietf.org/html/rfc4517#section-3.3.21) в RFC 4517, то очевидно, что оба синтаксиса подразумевают совпадение с distinguishedName, только в последнем добавляется НЕОБЯЗАТЕЛЬНЫЙ идентификатор на случай, если уникальные имена записей совпадут. Не могу представить, когда в нормальном каталоге такой случай может настать =) . Так что если Ваша задача что-то отработать у себя, а затем залить в чужой каталог, то не вижу смысла что-то предпринимать: Вы же будете хранить в этом атрибуте DN записей и никаких противоречий в данных не наступит. Если у Вас какая-то специфичная задача, то напишите подробнее, попробуем разобраться.
Кстати, в OpenLDAP, как обычно, следуют стандартам, и uniqueMember (http://tools.ietf.org/html/rfc4519#section-2.40) у них определен строго по RFC 4519. В IBM, видимо, решили "сэкономить" и не вводить синтаксис, вероятность совпадения с которым стремится к нулю.
Егор.
-
Егор, спасибо за ответ.
Касаемо "зачем" - я понятия не имею :-)
Знаю только, что приложение, которое разрабывается нами, не будет корректно работать из-за этих самых разных OID.
Потому - разработчики попросили заменить на локальном LDAP-е конфигурацию.
-
День добрый всем.
Всё прозаично как обычно. Дело в том что проверка по стандарту не дает создать пустую группу. Тоесть группу с пустым аттрибутом 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 )
-
Здравствуйте!
Всё прозаично как обычно. Дело в том что проверка по стандарту не дает создать пустую группу. Тоесть группу с пустым аттрибутом uniqueMember.
А сервера IBM дают это сделать, уж незнаю по умолчанию они так настроены или по "злому" умыслу.
Соостетственно код не может работать одинаково на тестовой среде и на релизной.
Что бы уменьшить количество багов и оценить узкие места мы подгоняем тестовый сервер под релизный.
Вам тогда стоит смотреть не в сторону изменения синтаксиса, а в сторону изменения объектного класса groupOfUniqueNames (http://tools.ietf.org/html/rfc4519#section-3.6) -- перевести атрибут 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 (http://tools.ietf.org/html/rfc4519#section-3.6) -- перевести атрибут 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, отредактировать, перезапустить, проверить.
-
Здравствуйте!
Не совсем понял, при чём в данном случае groupOfUniqueNames (ведь uniqueMember от неё не зависит?) - но ОК.
Дело в том, что обязательность появления атрибута в записи (в данном случае атрибута членства в групповой записи) зависит не от синтаксиса типа атрибута, а от определения того объектного класса (http://pro-ldap.ru/tr/zytrax/ch3/index.html#objectclass-def), на котором строится запись. Именно поэтому нужно изменить определение объектного класса 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-конфиге.
-
Здравствуйте, Арсений!
Я бы оставил хотя бы cn в MUST -- класс-то структурный.
Егор
-
Здравствуйте, Арсений!
Я бы оставил хотя бы cn в MUST -- класс-то структурный.
Егор
Да, хороший поинт, спасибо :-)
В целом - сделал по подсказке отсюда (http://blog.peter-b.org/2011/08/21/modify-openldap-schema-in-2-4/).
Всё заработало под 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 - Егор, спасибо.
-
Не понимаю одного - раз меняется 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.
Егор
Ещё раз спасибо :-)