Проблемы с бэкэндом LDAP в OpenLDAP

Доброе утро;

После работы по настройке прокси-сервера LDAP для репликации данных LDAP я получаю следующее сообщение:

52a0b5ca send_ldap_result: conn = -1 op = 0 p = 3

52a0b5ca send_ldap_result: err = 32 matched = "" text = ""

52a0b5ca ==> ldap_back_add ("dc = basecorp, dc = net")

52a0b5ca => ldap_back_getconn: conn 0x7f40ea0 извлечено refcnt = 1.

/ usr / libexec / slapd: ошибка поиска символа: /usr/libexec/openldap/back_ldap-2.4.so.2: неопределенный символ: ldap_add_ext

Это происходит с OpenLDAP 2.4.37 как на хосте Solaris 10 x86, так и на хосте RedHat 5.5. Оба установлены из источников, включая последний дистрибутив BDB. sourceserver - это машина, с которой я хочу получать данные и синхронизировать их с destserver (см. конфиги ниже).

Итак, единственное, что объединяет две машины, на которых я пытался запустить прокси, - это я (тьфу!). Проблема в том, что я настроил прокси в обратном направлении? Возможно, мне не разрешено добавлять запись в бэкэнд LDAP? Надеюсь, один из вас сможет проверить мои конфиги ниже и ответить на мой вопрос, а также многие другие там.

Мой slapd.conf для прокси:

database ldap
hidden on
suffix "dc=basecorp,dc=net"
rootdn "cn=Manager"
uri    ldaps://destserver01.dest.net:636

lastmod on


acl-bind  bindmethod=simple
          binddn="cn=Manager"
          credentials=mypassword

syncrepl  rid=500
          provider=ldaps://sourceserver01.dest.net:636
          binddn="cn=Manager"
          bindmethod=simple
          credentials=mypassword
          searchbase="dc=basecorp,dc=net"
          filter="(objectClass=*)"
          scope=sub
          schemachecking=on
          type=refreshAndPersist
          retry="5 5 300 5"

overlay   syncprov

Наконец, позвольте мне бросать грязь в воду:

Я использовал нм:

[root@buildtest01 ~]# nm  /usr/libexec/openldap/back_ldap-2.4.so.2 | grep ldap_add
                 U ldap_add_ext

И вот мой пропавший символ. Wth !?

Как и предполагалось @ c4f4t0r, у вас (пока) нет проблем с конфигурацией - у вас проблемы со сборкой .

TL; DR: не используйте динамические бэкэнды, они в основном не работают, если вы не возитесь с процессом сборки. Пропустите к обновлению ниже для ужасных деталей ...

Вероятно, у вас есть старые или не-OpenLDAP библиотеки LDAP в системных расположениях по умолчанию. Я не верю, что configureсценарий достаточно умен, чтобы проверить это условие или что процесс сборки достаточно устойчив, чтобы справиться с ним. Например, если старый файл libldap.soнаходится в системной библиотеке, он будет использоваться вместо правильного и только что установленного libldap.soво время выполнения. Бег lddпротив back_ldap-2.4.soдолжен показать это.

Вы можете исправить это (без перестройки), добавив соответствующий каталог в переменную среды, LD_LIBRARY_PATHчтобы сначала искать каталог с новейшими библиотеками OpenLDAP (убедитесь, что exportпеременная).

Или это исправить (предпочтительно) во время сборки, запустив configureс LDFLAGSпеременным окружением , установленный с RPATHкоторой будет жестко закодировать библиотеку пути поиска в бинарные файлы вы строите.

Вы не указали свои configureпараметры, путь установки и т. Д. Я использовал варианты этого в прошлом:

export LDFLAGS="-L/usr/local/ssl/lib -Wl,-rpath,/usr/local/ssl/lib"

в случае, когда я хочу использовать несистемный OpenSSL, то же самое относится и к несистемной версии BerkeleyDB. В Solaris вам может понадобиться использовать «-R» вместо «-rpath» (если вы используете gccкомпоновщик Sun, а не компоновщик GNU):

export LDFLAGS="-L/usr/local/ssl/lib -R/usr/local/ssl/lib"

В вашем случае вам, вероятно, просто нужно установить rpath ( -Wl,-rpathили -R), а не -L(хотя я рекомендую использовать оба варианта для случаев OpenSSL и BerkeleyDB).

Обновление Вы строите с:

/configure --prefix=/usr --sysconfdir=/etc --enable-slapd --enable-crypt \
    --enable-modules --enable-bdb=mod --enable-hdb=mod --enable-ldap=yes \
    --enable-perl=mod --enable-overlays=mod --with-tls --with-gnu-ld

Примечание « --enable-ldap=yes», это статически встраивает бэкэнд LDAPslapd , не создает динамически загружаемый back_ldap.so(то есть --enable-ldap=mod). Одна из возможностей заключается в том, что у вас есть заблуждение, back_ldap.so которое вы пытаетесь загрузить на свой сервер, и ненужное moduleload back_ldap. Однако slapdвы не сможете загружать динамический модуль, когда существует статический модуль с тем же именем, поэтому ваш slapdдвоичный файл выглядит не так, как вы описали.

Запустите slapd -VVVдля подтверждения статических бэкэндов.

Предполагая, что back_ldapон статичен, вы должны быть в состоянии обойти эту проблему и удалить все заблуждения moduleloadи устаревшие .soдля хорошей меры.

У меня есть сильное подозрение, что здесь есть некоторые проблемы с libtool, зависимостью или компоновщиком. Я могу воспроизвести это с динамическим back_ldap. ldap_add_extэто действительно неразрешенный символ, который не обязательно является проблемой (из-за явного dlopen()для модулей), но этот символ не экспортируется slapd. Он будет экспортироваться libldap.so, но это не зависимость , back_ldap.soа больше ничего не вызывает , libldapчтобы быть загружен. (Это также означает, что совет, который я дал выше, не решит проблему, поскольку она не так проста, как проблема с путями в библиотеке.)

То, что происходит (то есть ошибка, которую вы видите), заключается в том, что символ ldap_add_extне разрешается до тех пор, пока он не потребуется («ленивая» привязка). Когда вы пытаетесь добавить объект LDAP, это, конечно, требуется. Тогда колеса отрываются. (Если вы чувствуете побуждение, вы можете прервать его во время запуска, экспортировав, LD_BIND_NOW=1что отключает отложенное связывание, а затем запускается slapd, хотя шансы - другой символ, отключают его.)

Прямо сейчас самый простой вариант - работать со статическим back_ldap( --enable-ldap=yesи, возможно, make clean && make depend && make installбыть уверенным, что slapdон правильно построен). Менее простой вариант заключается в том, чтобы обойти проблему зависимости и скрестить пальцы в надежде, что у нее нет каких-то странных побочных эффектов.LD_PRELOAD=/usr/lib/libldap.soLD_PRELOAD=/usr/lib/libldap_r.so

Хорошо, это древнее электронное письмо покрывает проблему: http://www.openldap.org/lists/openldap-software/200211/msg00469.html по умолчанию slapdсвязан со статическим libldap_r.a, это ограничивает символы, которые будут доступны тем, кто известен в время ссылки . Поскольку динамические модули загружаются во время выполнения с dlopen()компоновщиком, они не видят свои требования (символы / библиотеки).

Можно разумно заключить, что динамическое построение (некоторых) бэкэндов в течение некоторого времени было в значительной степени нарушено.

Так что, либо не используйте динамические бэкэнды (рекомендуется), либо поменяйте сборку (не рекомендуется) чем-то вроде:

make depend && make
rm servers/slapd/slapd
LTSTATIC="" make -e     # alternative to editing the Makefile
make install

Это связано slapdс тем, что libldap_r.soвы только что создали, вместо того .a, чтобы, так что все символы могут быть загружены при необходимости (это также slapdуменьшает размер диска примерно на 15%). Я не запускал работающий сервер LDAP с этим, YMMV. Должны быть некоторые подобные или альтернативные решения, используемые дистрибутивами ...

Это не проблема конфигурации, ошибка ясна, говорит вам, что openldap ищет функцию в библиотеке /usr/libexec/openldap/back_ldap-2.4.so.2, которой там нет.

На redhat 5, почему вы не используете стандартный ldap в формате rpm?