Здравствуйте!
поднимаю вторичный сервер 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?!
>Главный:
>replica host=ldap2.****.ru:389>Вторичный:
>syncrepl rid=123>в базе SLURP (replog)
>и производится попытка синхронизации, в логи пишется вот что:syncrepl, указанный на вторичном сервере и SLURP(replog) это разные, независимые технологии репликации. Вы уж опередеоитесь, какую из них использовать для данных двух серверов. Читайте guide еще раз. Есть FAQ на www.openldap.org
Спасибо :) буду щас еще раз читать
то-то я думаю что очень странные логи ...
Прочел, но меня это не вдохновило....
вот отрывок:
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 ...
Вы по прежнему смешиваете разные механизмы репликации: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.
Спасибо большое за информацию - у меня не хватало этих индексов ...
Настроил щас на использование SLURP
Попробую переделать на SyncRepl, но если не получится думаю оставить так ...
Slurp оказывается не совсем заработал - ругается на то что не может обновить запись entryCSN - user modification not allowedOpenLDAP 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.*, а если собрать вручную, то в последствии будут проблемы с обновлением...
Пососветуйте что-либо ПЛИИИЗ, уже неделю он мне не дает покоя....
Прочтите книгу O'Reilly по LDAP - очень даже ничего:
http://files.nixp.ru/books/net_security/O%27Reilly%...и вообще на этом сайте много доки. Список:
http://files.nixp.ru/books/documentationcd_vol1.txt
John, спасибо вам ограмное за помощь :)