The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Ldap replica и syncrepl"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [ Отслеживать ]

"Ldap replica и syncrepl"  
Сообщение от ZM_Michael email(ok) on 22-Ноя-05, 08:36 
Здравствуйте!
поднимаю вторичный сервер LDAP с такими вот настройками:

Главный:
replica host=ldap2.****.ru:389
    binddn="cn=replica,ou=DSA,dc=****,dc=ru"
    bindmethod=simple
    credentials=replicaldap

Вторичный:
syncrepl rid=123
    provider=ldap://ldap.****.ru:389
    type=refreshOnly
    interval=00:00:01:00
    searchbase="dc=****,dc=ru"
    filter="(objectClass=inetOrgPerson)"
    scope=sub
    attrs="cn,sn,telephoneNumber,userPassword,sambaSID,dn,sambaGroupType,memberUid,objectClass,uid,givenName,roomNumber,homePhone,mail,gecos,cn,entryCSN,modifiersName,modifyTimestamp"
    schemachecking=on
    updatedn="cn=replica,ou=DSA,dc=****,dc=ru"
    bindmethod=simple
    binddn="cn=replica,ou=DSA,dc=****,dc=ru"
    credentials=replicaldap

Ни SSL ни SASL не использую, после изменения в главной, появляются изменения в базе SLURP (replog)
и производится попытка синхронизации, в логи пишется вот что:
slapd[20408]: conn=0 op=3 MOD dn="uid=michael,ou=Users,dc=****,dc=ru"
slapd[20408]: conn=0 op=3 MOD attr=objectClass uid sn givenName roomNumber telephoneNumber homePhone mail gecos cn entryCSN modifiersName modifyTimestamp
slapd[20408]: conn=0 op=3 RESULT tag=103 err=53 text=shadow context; no update referral

никто случайно не сталкивался с этим вопросом? что значит это text=shadow context?!

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Ldap replica и syncrepl"  
Сообщение от John (??) on 22-Ноя-05, 09:30 
>Главный:
>replica host=ldap2.****.ru:389

>Вторичный:
>syncrepl rid=123

>в базе SLURP (replog)
>и производится попытка синхронизации, в логи пишется вот что:

syncrepl, указанный на вторичном сервере и SLURP(replog) это разные, независимые технологии репликации. Вы уж опередеоитесь, какую из них использовать для данных двух серверов. Читайте guide еще раз. Есть FAQ на www.openldap.org

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Ldap replica и syncrepl"  
Сообщение от ZM_Michael email(ok) on 22-Ноя-05, 09:39 
Спасибо :) буду щас еще раз читать
то-то я думаю что очень странные логи ...


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Ldap replica и syncrepl"  
Сообщение от ZM_Michael email(ok) on 22-Ноя-05, 12:22 
Прочел, но меня это не вдохновило....
вот отрывок:
When creating a provider database from the LDIF file using slapadd (8), contextCSN and the syncProviderSubentry entry must be created. slapadd -p -w will create a new contextCSN from the entryCSNs of the added entries. It is also possible to create the syncProviderSubentry with an appropriate contextCSN value by directly including it in the ldif file. slapadd -p will preserve the provider's contextCSN or will change it to the consumer's contextCSN if it is to promote a replica to the provider's content. The syncProviderSubentry can be included in the ldif output when slapcat (8) is given the -m flag; the syncConsumerSubentry can be retrieved by the -k flag of slapcat (8).

The session log is configured by

        sessionlog <sid> <limit>

А куда это прописывать?
у меня в базе сейча нет полей типа  contextCSN...
вообще может кто сталкивался с тем что надо сделать с установленным и рабочим сервером, чтобы с ним происходило взаимодействие через syncrepl..

сейчас у меня в логах главного пишется следующее:
slapd[32705]: conn=37 fd=10 ACCEPT from IP=192.168.147.3:54790 (IP=0.0.0.0:389)
slapd[32712]: conn=37 op=0 BIND dn="cn=replica,ou=DSA,dc=****,dc=ru" method=128
slapd[32712]: conn=37 op=0 BIND dn="cn=replica,ou=DSA,dc=****,dc=ru" mech=SIMPLE ssf=0
slapd[32712]: conn=37 op=0 RESULT tag=97 err=0 text=
slapd[32711]: conn=37 op=1 SRCH base="ou=users,dc=****,dc=ru" scope=2 deref=0 filter="(objectClass=*)"
slapd[32711]: conn=37 op=1 SRCH attr=* objectClass structuralObjectClass entryCSN
slapd[32732]: conn=37 op=2 UNBIND
slapd[32732]: conn=37 fd=10 closed

при такой настройке второстепенного сервера
syncrepl rid=123
    provider=ldap://ldap.****.ru:389
    type=refreshOnly
    interval=00:00:01:00
    searchbase="ou=Users,dc=****,dc=ru"
    filter="(objectClass=*)"
    scope=sub
    attrs="*"
    schemachecking=off
    updatedn="cn=root2,dc=****,dc=ru"
    bindmethod=simple
    binddn="cn=replica,ou=DSA,dc=****,dc=ru"
    credentials=replicaldap
Очень смущает последняя строка UNBIND ...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Ldap replica и syncrepl"  
Сообщение от John (??) on 22-Ноя-05, 13:23 
Вы по прежнему смешиваете разные механизмы репликации:

sessionlog <sid> <limit> это репликация посредством SLURPD
syncrepl - это репликация посредством syncrepl

Это совершенно разные и независимые механизмы.

При репликации посредством SLURPD все обновления на slave осуществляются демоном SLURPD работающем на master. Соответственно должны быть настроены права на slave на внесение таких обновлений.

При репликации посредством syncrepl на master ведутся (обязательно) дополнительные индексы для репликации
index entryCSN,entryUUID    eq

#и указывается загрузка соответствующего оверлея для openldap 2.3.X
#но это зависит от того, как собран openldap
overlay syncprov
syncprov-checkpoint     100 10
syncprov-sessionlog     100

при этом сами поля entryCSN,entryUUID в базе данных создаются когда происходит первая репликация. Это служебные поля slapd и явно их создавать не нужно.

А уже на slave настраивается репликация посредством
syncrepl rid=...
....

При этой схеме изменения "забирает" сам slave и на master должны быть даны права на получение этой информации (чтение, поиск - подробней в guide)

Вообще, тенденция такова, что в будущих версиях openldap будет использоваться только syncrepl.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Ldap replica и syncrepl"  
Сообщение от ZM_Michael email(ok) on 22-Ноя-05, 14:17 
Спасибо большое за информацию - у меня не хватало этих индексов ...
Настроил щас на использование SLURP
Попробую переделать на SyncRepl, но если не получится думаю оставить так ...
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Ldap replica и syncrepl"  
Сообщение от ZM_Michael email(ok) on 23-Ноя-05, 19:08 
Slurp оказывается не совсем заработал - ругается на то что не может обновить запись entryCSN - user modification not allowed

OpenLDAP 2.2.28
настраиваю syncrepl - не работает
сервер:
index           objectClass,uidNumber,gidNumber,entryCSN,entryUUID   eq
клиент:
syncrepl rid=1
    provider=ldap://ldap.****.ru:389
    type=refreshAndPersist
    interval=00:10:00:00
    retry="60 10 300 +"
    searchbase="dc=****,dc=ru"
    filter="(objectClass=*)"
    scope=sub
    attrs="cn,sn,ou"
    schemachecking=off
    updatedn="cn=replica,ou=DSA,dc=****,dc=ru"
    bindmethod=simple
    binddn="cn=replica,ou=DSA,dc=****,dc=ru"
    credentials=replicaldaprootpasswd
пользователь replica прописан во всех acl с провами записи на вторичном и провами чтения на первичном сервере.

после старта в лог идет вот что (на шлавном сервере):
(loglevel 256)
slapd[11259]: conn=0 fd=10 ACCEPT from IP=192.168.147.3:39846 (IP=0.0.0.0:389)
slapd[11681]: conn=0 op=0 BIND dn="cn=replica,ou=DSA,dc=****,dc=ru" method=128
slapd[11681]: conn=0 op=0 BIND dn="cn=replica,ou=DSA,dc=****,dc=ru" mech=SIMPLE ssf=0
slapd[11681]: conn=0 op=0 RESULT tag=97 err=0 text=
slapd[11681]: conn=0 op=1 SRCH base="dc=****,dc=ru" scope=2 deref=0 filter="(objectClass=*)"
slapd[11681]: conn=0 op=1 SRCH attr=cn sn ou objectClass structuralObjectClass entryCSN
slapd[11259]: connection_input: conn=0 deferring operation: awaiting write

попытка:
slapd[11681]: conn=5 op=0 BIND dn="cn=replica,ou=DSA,dc=****,dc=ru" method=128
new-pdc slapd[11681]: conn=5 op=0 BIND dn="cn=replica,ou=DSA,dc=****,dc=ru" mech=SIMPLE ssf=0
new-pdc slapd[11681]: conn=5 op=0 RESULT tag=97 err=0 text=
new-pdc slapd[11682]: conn=5 op=1 SRCH base="dc=****,dc=ru" scope=2 deref=0 filter="(objectClass=*)"
new-pdc slapd[11682]: conn=5 op=1 SRCH attr=cn sn ou objectClass structuralObjectClass entryCSN
new-pdc slapd[11681]: conn=5 op=2 UNBIND

Пробовал запускать поиск вручную - выдается вся инфа...
смущает что нет ошибки, но нет и SEARCH RESULT, хотя на ведомом сервере вообще нет ничего в логах на 256 loglevel.. на других уровнях проскакивало упоминание об отсутствии пользователя "cn=syncrepl1,..." - создал его, но ничего не изменилось...
Если изменить на главном что-либо, то на вторично никаких изменений нет ...

Подскажите как отследить где ошибка.
Может кто поделистся конфигом настроенной системы...
Какие права должны быть у пользователя replica? он должен быть рутом на slave ?

Каким должен быть параметр rid - и что это вообще за идентификатор...
К сожалению в Gentoo портах нет еще версии 2.3.*, а если собрать вручную, то в последствии будут проблемы с обновлением...
Пососветуйте что-либо ПЛИИИЗ, уже неделю он мне не дает покоя....

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Ldap replica и syncrepl"  
Сообщение от John (??) on 24-Ноя-05, 09:51 
Прочтите книгу O'Reilly по LDAP - очень даже ничего:
http://files.nixp.ru/books/net_security/O%27Reilly%...

и вообще на этом сайте много доки. Список:
http://files.nixp.ru/books/documentationcd_vol1.txt

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Ldap replica и syncrepl"  
Сообщение от ZM_Michael email(ok) on 24-Ноя-05, 14:37 
John, спасибо вам ограмное за помощь :)


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру