У меня есть сервер OpenLDAP OLC (2.4.23), к которому я пытаюсь просто добавить два атрибута к файлу наложения Syncprov, но встречаюсь с некоторой трудностью.
Вот содержание olcOverlay = {0} syncprov.ldif файл:
# кошка/etc/openldap/slapd.d/cn \= config/olcDatabase \= {1} bdb/olcOverlay \= {0} syncprov.ldif
dn: olcOverlay={0}syncprov
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 60
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 727d29d6-cc5c-1032-89d0-2fc7acd5ca31
creatorsName: cn=config
createTimestamp: 20131018161654Z
entryCSN: 20131018161654.036436Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20131018161654Z
И я пытаюсь применить этот LDIF:
# кошка SyncprovOverlayAdd2.ldif
dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config
changetype: modify
add: olcSpCheckpoint
olcSpCheckpoint: 100 30
-
add: olcSpSessionlog
olcSpSessionlog: 1000
Ошибка:
# "ldap://ldap01.lab.com" ldapadd-v-f SyncprovOverlayAdd2.ldif-D "cn=config"-H-W-x
ldap_initialize( ldap://ldap01.lab.com:389/??base )
Enter LDAP Password:
add olcSpCheckpoint:
100 30
add olcSpSessionlog:
1000
modifying entry "olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config"
ldap_modify: Inappropriate matching (18)
additional info: modify/add: olcSpCheckpoint: no equality matching rule
Я получаю ту же ошибку, если я вызываю ее с ldapmodify. Я использую несправедливость, добавляют/изменяют директивы или атрибуты?
Далее поиск и устранение неисправностей попыток:
Я пытался изменить LDIF без "добавления": директивы для сходства с:
dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config
changetype: add
olcSpCheckpoint: 100 30
olcSpSessionlog: 1000
Но когда я делаю это, я получаю другую ошибку:
add olcSpCheckpoint:
100 30
add olcSpSessionlog:
1000
adding new entry "olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config"
ldap_add: Object class violation (65)
additional info: no objectClass attribute
У меня вполне нет подвешивания этих OLC живые изменения и когда необходимо добавить/изменить/заменить, когда "тип изменения" должен быть установлен явно, когда необходимо указать objectClass при использовании ldapadd/ldapmodify для существующей записи и т.д.
Ссылка: Этот вопрос о ServerFault имел ответ, который предложил заменить, "добавляют" с "заменой" для этой ошибки, но это не работало на меня.
Чтобы исправить это, нужно было произойти две вещи. У меня уже была запись olcSpCheckpoint (но не запись olcSpSessionLog) в файле конфигурации наложения (olcOverlay = {0} syncprov.ldif), поэтому мне нужно было изменить мое "add:" на "replace:" для olcSpCheckpoint, например :
# cat SyncprovOverlayAdd2.ldif
dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config
changetype: modify
replace: olcSpCheckpoint
olcSpCheckpoint: 100 30
-
add: olcSpSessionlog
olcSpSessionlog: 1000
Таким образом, ссылка ServerFault, на которую я указал с пометкой «Ссылка:» в нижней части OP, действительно была правильной, но я не смог проверить ее сначала, так как проблема была в игре (и я все еще получал сообщения об ошибках после исправления LDIF).
Во-вторых, даже после того, как я исправил LDIF, я получал сообщения об ошибках, что он не мог изменить запись (к сожалению, я потерял точные сообщения, которые появлялись в терминале) при попытке применить LDIF с помощью ldapmodify, но у меня был роскошь клонирования виртуальной машины, на которой был мой сервер LDAP, чтобы я мог играть с ее копией вне производства. И когда я запустил ту же команду ldapmodify в клоне виртуальной машины, она успешно применила LDIF. Таким образом, мой единственный вывод заключался в том, что slapd по какой-то странной причине завис на рабочем сервере и его необходимо перезапустить. Я пытался избежать этого на моем производственном LDAP-сервере с единственной точкой отказа (который, кроме того, должен был быть полностью OLC, чтобы предотвратить такие вещи, как перезапуск slapd), но я укусил пулю и перезапустил slapd на сервере LDAP. и после этого мои изменения прошли без проблем.
Это http://www.openldap.org/its/index.cgi/?findid=8616 , который будет исправлен в выпуске OpenLDAP 2.4.47.