Если при репликации типа syncrepl консьюмер не может получить доступ ко всей реплицируемой базе на провайдере, после измнения данных на провайдере в недоступной для консьюмера части базы репликация полностью останавливается до перезапуска консьюмера. Для демонстрации этого, патчи на стандартные конфигурационные файлы и первоначальный LDIF с данными пойдут аттачами следом. В них подразумевается, что 10.9.9.1 -- провайдер, 10.9.9.2 -- консьюмер. После первоначальных загрузки данных и репликации их на консьюмер расскоментируем в конфиге slapd-hdb-db01.conf провайдера строки: #access to dn.subtree="ou=branch2,dc=example,dc=com" # by dn="uid=syncrepl,dc=example,dc=com" none # by * read Затем любым способом создаем на провайдере в ветке ou=branch2,dc=example,dc=com любой объект. После этого все объекты, создаваемые на провайдере в ветке ou=branch1,dc=example,dc=com , к которой у консьюмера есть полный доступ, реплицированы не будут до перезапуска консьюмера. Аналогичные действия в более сложной конфигурации (подчиненные базы данных, использование оверлея dynlist) приводили помимо этого и к падению провайдера, но воспроизвести это на установке с нуля пока не удалось. [root@box1 openldap]# rpm -q openldap-servers openldap-servers-2.3.43-alt2
Created attachment 3777 [details] конфиг провайдера
Created attachment 3778 [details] конфиг консьюмера
Created attachment 3779 [details] LDIF первоначальной базы
sizelimit и timelimit может стоит попробовать выставить и проверить еще раз в unlimitied? Поиск по данному типу ошибок приводит чаще всего к Replicas running syncrepl as non-rootdn need unrestricted size/time
sizelimit стоял -1, строка timelimit отсутствовала, выставил тоже -1 -- ситуация не поменялась. Но не похоже, что они должны какую-то роль играть, т.к. если убрать access restriction для консьюмера, все начинает работать нормально, а если выставить -- начинаются снова.
Один раз все-таки удалось его уронить простым LDIF-ом: ---------- dn: ou=ldif3,ou=branch2,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: ldif3 dn: ou=ldif4,ou=branch1,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: ldif4 ---------- Повторно воспроизвести не удалось. Логи падения и успешного добавления сейчас приаттачу. Напоминаю, что логи провайдера, т.к. падает именно он. В логах консьюмера при таких операциях тишина.
Created attachment 3780 [details] лог падения
Created attachment 3781 [details] лог успешного добавления
openldap-servers is no longer part of repository, please check its successor openldap2.4-servers.
Тогда перевешиваю на 4.0
В 4.0/branch исправления не будут вноситься уже технически (заглушена очередь на сборку), поэтому прошу ошибки, актуальные для sisyphus/p7/t7, перевесить на текущие ветки или сизиф.
