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

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

Как и предполагал @ 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", это статически строит 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.so~~LD_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?