При переходе с Debian Jessie (openldap 2.4.40) на Debian Buster (openldap 2.4.47) я наткнулся на несколько проблем, но последний из них просто сбивает с толку.
Первая проблема: ldapsearch не возвращает все атрибуты по умолчанию - вы должны указать их явно:
ldapsearch -Y EXTERNAL -H ldapi:/// -b "ou=contacts,<BASE>" -LLL -o ldif-wrap=no "*" \
givenName sn cn mail telephoneNumber mail mobile facsimileTelephoneNumber dn sn title \
o l postalAddress postalCode pager homePhone homePostalAddress jpegPhoto labeledURI \
description manager businessCategory physicalDeliveryOfficeName objectClass uid \
> 2020-07-15-contacts.ldif
Вторая проблема: похоже, что openldap base64 кодирует значения, содержащие специальные символы, поэтому обнаружено немного Perl-foo для автоматического декодирования этих значений. После этого двойные двоеточия «::» необходимо было заменить одинарными двоеточиями «:», поскольку значение больше не кодировалось.
Третья и еще не решенная проблема заключается в том, что сгенерированный LDIF содержит атрибуты givenName и sn для всех записей в LDIF, но эти атрибуты отсутствуют в новом каталоге openldap после ldapadd:
ldapadd -c -Y EXTERNAL -H ldapi:/// -f 2020-07-15-contacts.ldif
Журналы slapd для каждой записи в адресной книге показывают:
conn=32243 op=14144 ADD dn="<DN>"
conn=32243 op=14144 RESULT tag=105 err=0 text=
(все остальные атрибуты импортированы правильно)
Приношу свои извинения - проблема была связана не с экспортом / импортом содержимого ldap, а с выполненной впоследствии ldapsearch (): все содержимое было правильно импортировано, но списки управления доступом были испорчены, и обычным пользователям не был предоставлен доступ к данным Name и sn атрибуты (не знаю, почему это произошло - еще одна вещь, которую нужно добавить в список «TODO LATER»).
Этот вопрос может быть актуален для других - если вы выполняете резервное копирование данных ldap, убедитесь, что вы делаете резервную копию все содержание ...