Bug 21207

Summary: ошибка репликации syncrepl
Product: Branch 4.0 Reporter: Timur Batyrshin <erthad>
Component: openldap-serversAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED WONTFIX QA Contact: Q.A. 4.0 <qa-4.0>
Severity: normal    
Priority: P3 CC: barabashka, dlebkov, ldv
Version: 4.0   
Hardware: all   
OS: Linux   
Attachments:
Description Flags
конфиг провайдера
none
конфиг консьюмера
none
LDIF первоначальной базы
none
лог падения
none
лог успешного добавления none

Description Timur Batyrshin 2009-08-24 17:50:53 MSD 
Если при репликации типа 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
Comment 1 Timur Batyrshin 2009-08-24 17:51:30 MSD 
Created attachment 3777 [details]
конфиг провайдера
Comment 2 Timur Batyrshin 2009-08-24 17:52:09 MSD 
Created attachment 3778 [details]
конфиг консьюмера
Comment 3 Timur Batyrshin 2009-08-24 17:52:52 MSD 
Created attachment 3779 [details]
LDIF первоначальной базы
Comment 4 barabashka 2009-08-24 18:02:22 MSD 
sizelimit и timelimit может стоит попробовать выставить и проверить еще раз в unlimitied? Поиск по данному типу ошибок приводит чаще всего к
Replicas running syncrepl as non-rootdn need unrestricted size/time
Comment 5 Timur Batyrshin 2009-08-24 18:27:24 MSD 
sizelimit стоял -1, строка timelimit отсутствовала, выставил тоже -1 -- ситуация не поменялась.
Но не похоже, что они должны какую-то роль играть, т.к. если убрать access restriction для консьюмера, все начинает работать нормально, а если выставить -- начинаются снова.
Comment 6 Timur Batyrshin 2009-08-24 18:27:56 MSD 
Один раз все-таки удалось его уронить простым 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
----------

Повторно воспроизвести не удалось.
Логи падения и успешного добавления сейчас приаттачу. Напоминаю, что логи провайдера, т.к. падает именно он. В логах консьюмера при таких операциях тишина.
Comment 7 Timur Batyrshin 2009-08-24 18:28:29 MSD 
Created attachment 3780 [details]
лог падения
Comment 8 Timur Batyrshin 2009-08-24 18:29:11 MSD 
Created attachment 3781 [details]
лог успешного добавления
Comment 9 Dmitry V. Levin 2009-09-18 14:33:20 MSD 
openldap-servers is no longer part of repository, please check its successor openldap2.4-servers.
Comment 10 Timur Batyrshin 2009-09-21 10:27:10 MSD 
Тогда перевешиваю на 4.0
Comment 11 Michael Shigorin 2014-11-05 20:17:10 MSK 
В 4.0/branch исправления не будут вноситься уже технически (заглушена очередь на сборку), поэтому прошу ошибки, актуальные для sisyphus/p7/t7, перевесить на текущие ветки или сизиф.