Проблемы с бэкэндом 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!?

Источник

2 ответа

Решение

Как и предполагалось @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 msgstr "это статически встраивает бэкэнд LDAP в slapd, он не создает динамически загружаемый 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?

Источник
Другие вопросы по тегам