Назад | Перейти на главную страницу

Проблемы с запуском Openldap после обновления

Я пытаюсь синхронизировать подчиненный и главный сервер ldap. Главный сервер использует openldap 2.3.43-12, а подчиненный сервер использует openldap 2.4.23. Я скопировал файлы в / var / lib / ldap, запустил сервер и получил эту ошибку:

Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb(dc=mydomaine,dc=fr): Program version 4.7 doesn't match environment version 4.4
Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb_db_open: database "dc=mydomaine,dc=fr" cannot be opened, err -30971. Restore from backup!
Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb(dc=mydomaine,dc=fr): txn_checkpoint interface requires an environment configured for the transaction subsystem
Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb_db_close: database "dc=mydomaine,dc=fr": txn_checkpoint failed: Invalid argument (22).
Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: backend_startup_one (type=bdb, suffix="dc=mydomaine,dc=fr"): bi_db_open failed! (-30971)
Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb_db_close: database "dc=mydomaine,dc=fr": alock_close failed

Я использовал db_upgrade команда для обновления файлов базы данных на новом подчиненном сервере, но я все равно получаю ту же ошибку при запуске slapd.

Главный сервер - это Centos 5.5 32bit и openldap 2.3.43-12. Подчиненный сервер - Centos 6.3 64 bit и openldap 2.4.23. Все было установлено с использованием yum.

Каков правильный метод синхронизации файлов базы данных с главного сервера ldap и подчиненного сервера, когда подчиненный сервер более новый, чем главный?

Я последовал предложению 84104, но получаю сообщение об ошибке на ведомом устройстве.

конфигурация syncrepl

syncrepl  rid=003
        provider=ldaps://ldap0.lan.myserver.net:636
        bindmethod=simple
        binddn="cn=syncuser,dc=mydomaine,dc=fr"
        scope=sub
        attrs="*"
        credentials=some_password
        searchbase="dc=mydomaine,dc=fr"
        logbase="cn=accesslog"
        logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
        schemachecking=on
        type=refreshAndPersist
        retry="60 +"
        syncdata=accesslog

Эта конфигурация syncrepl отлично работает на других подчиненных серверах.

Вот ошибка на рабе:

Oct 23 18:28:30 xe-ldap-slave1 slapd[1415]: slap_client_connect: URI=ldaps://ldap0.lan.myserver.com:636 DN="cn=syncuser,dc=mydomaine,dc=fr" ldap_sasl_bind_s failed (-1)
Oct 23 18:28:30 xe-ldap-slave1 slapd[1415]: do_syncrepl: rid=003 rc -1 retrying

Вот ошибка мастера:

Oct 23 18:29:30 ldap0 slapd[15265]: conn=201 fd=35 ACCEPT from IP=192.168.150.100:47690 (IP=0.0.0.0:636) 
Oct 23 18:29:30 ldap0 slapd[15265]: conn=201 fd=35 closed (TLS negotiation failure)

Я могу выполнить поиск ldap на главном сервере, если пользователь настроен на синхронизацию с новым подчиненным сервером.

ldapsearch -LLL -x -H ldaps://192.168.150.99:636 -x -W -b dc=mydomaine,dc=fr-D"cn=syncuser,dc=mydomaine,dc=fr"

Репликация LDAP под syncrepl довольно прочный. Серверы не обязательно должны быть одной версии, им просто нужно понимать друг друга. (Для правильного мультимастера требуется версия 2.4.X, но, насколько я могу судить, вы спрашиваете не об этом.)

"The consumer replica can be constructed from a consumer-side or a provider-side backup at any synchronization status." Наиболее примечательно в этом случае то, что syncrepl может создать правильную реплику на сервере, на котором никогда ранее синхронизировались любым способом.

Что делать с:

  1. остановить реплики slapd
  2. удалить содержимое /var/lib/ldap (Кроме DB_CONFIG)
  3. убедитесь, что ваш syncrepl или olcsyncrepl директива верна
  4. запустить реплики slapd
  5. подождите, пока реплика синхронизируется

Примечание. Использование определенных оверлеев (например, memberof) приведет к потере (переопределению) operational attributes creatorsName и createTimestamp на реплике, а в остальном все будет так же.

IMHO вы должны запустить одну и ту же версию на мастере и на подчиненных устройствах.

Если вы действительно этого хотите, перенесите данные в формате LDIF: slapcat и slapadd можно использовать для дампа и восстановления базы данных. Это автономные утилиты, поэтому перед использованием остановите серверы ldap.

РЕДАКТИРОВАТЬ: насколько я помню, репликация хрупкая, я не говорю, что использование той же версии обязательно, просто рекомендуется.

db_upgrade напрямую изменяет файлы, созданные ранее slapd. Может случиться так, что конечный результат будет в порядке.