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

Question 1

Как и предполагал @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который отключает ленивую привязку, затем start 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 slapdlibldap_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. Должны быть какие-то похожие или альтернативные решения, используемые дистрибутивами...

Answer