форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Ldap replica и syncrepl"

Сообщение от ZM_Michael (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 (ok) on 22-Ноя-05, 09:39
	Спасибо :) буду щас еще раз читать то-то я думаю что очень странные логи ...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

	6. "Ldap replica и syncrepl"
	Сообщение от ZM_Michael (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 (ok) on 24-Ноя-05, 14:37
	John, спасибо вам ограмное за помощь :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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