ldap + samba + replication

вот еще забыл:
samba-server везде настроен как:
domain logons = yes
domain master = yes
preferred master = auto
local master = yes
domain logons = yes

Поиск чего делает Samba? :)

Отключите вообще все slave ldap сервера - samba работает?

Опишите схему наконец, лето еще - телепаты в отпуске

С LDAP slave'а снять репликацию? )))) это сильно.

zgen привет.
Как то около года назад мы с тобой на эту тему говорили, я спрашивал о лучшей схеме реализации единой базе пользователей. В итоге договорились, что лучше в удаленных офисах поставить свой ldap-slave-server + samba PDC с одним одинаковым именем и sid-ом, направить ее на свой slave-ldap-server этого офиса, а между ldap-серверами уже сделать репликацию.
В итоге все это я и сделал, но вот только столкнулся с тормозами в самбе, если она на ldap-slave-server направлена.
Основные конфиги самбы выше, поэтому не буду их дублировать.
Тормоза проявляются в разных вещах, допустим авторизация при включении компа медленно проходит. Если допустим запустить pdbedit -L -v, то пользователи также медленно вываливаются, при этом послушав ldap-мастер видно, что в это время идет обращение к нему :((.

При отключеном ldap-slave, самбу просто не запустить - ругается на подключение к ldap.

Отключение репликации на slave-ldap - имел в виду убирание сторк:
updatedn "uid=replicator,dc=ldap,dc=mycompany,dc=ru"
updateref ldap://mycompany.ru:389,
- этого достаточно, что бы ldap удаленного офиса перестал передавать модифицирующие данные главному. После этого samba начинает летать.

Тут, вчера нашел одну, пока непонятную вещь:
конфиг ldap.conf изначально выглядел:
base dc=ldap, dc=mycompany, dc=ru
URI ldap://192.168.1.1 #(ldap-master)

переделал на:
base dc=ldap, dc=mycompany, dc=ru
SIZELIMIT 12
TIMELIMIT 15
все рестартанул - все зашевелилось, вернул все в зад - так же все стало летать.....

Значит так, тормоза со slave/master сервером могут быть:

1) Из-за неправильно настроенных индексов на ldap
2) Постоянной попытке ЗАПИСИ в ldap.
3) Из-за неправильной конфигурации nss_ldap.

С первым - почитаете доку. Со вторым:

дайте конфиг master ldap и slave ldap без пароля manager и адресов сервера. Включите логи samba уровня 2 и посмотрите, что же она делает в момент тормозов. ;)

Самба обращается к мастеру только если ей надо записать, пишет она только по следующим событиям:

1) Смена пароля пользователя
2) Смена пароля аккаунта машины.

И то и другое делается крайне редко, и поэтому samba на практически любом линке абсолютно работоспособна (поверьте, у меня большой опыт :))

>при этом послушав ldap-мастер видно, что в это время идет обращение к >нему

Это наводит меня на мысль, что вы таки натупили при настройке nss_ldap. Конфиги покажите.

>конфиг ldap.conf изначально выглядел:

В ldap.conf не должно быть указано master сервера (зачем)? в нем вообще не нужно URI указывать.

1) - доку по индексам гляну.
2) конфиги такие:
###################### /etc/nsswitch.conf
passwd: compat ldap
group: compat ldap
shadow: compat ldap

hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis

###########################slapd.conf
allow bind_v2

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema

include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/squid.schema
include /etc/ldap/schema/mail.schema
include /etc/ldap/schema/samba.schema

schemacheck off
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd.args

loglevel 0
backend bdb
checkpoint 512 30
database bdb
suffix "dc=ldap,dc=mycompany,dc=ru"
rootdn "cn=Administrator,dc=ldap,dc=mycompany,dc=ru"
rootpw {MD5}xxxxxxxxxxxxxxxxxxxx
directory "/var/lib/ldap"
index objectClass,uid eq
index squidStatus,squidUserPassword eq
lastmod on

#replogfile /var/lib/ldap/replog

updatedn "uid=replicator,dc=ldap,dc=mycompany,dc=ru"
updateref ldap://192.168.1.1:389

modulepath /usr/lib/ldapaccess to attrs=userPassword
by dn="cn=Administrator,dc=ldap,dc=mycompany,dc=ru" write
by dn="uid=ntadmin,ou=Users,dc=ldap,dc=mycompany,dc=ru" write
by dn="uid=replicator,dc=ldap,dc=mycompany,dc=ru" write
by dn="uid=mailManager,ou=Users,dc=ldap,dc=mycompany,dc=ru"read
by anonymous auth
by self write
by * none

access to dn.base="" by * read
access to *
by dn="cn=Administrator,dc=ldap,dc=mycompany,dc=ru" write
by dn="uid=ntadmin,ou=Users,dc=ldap,dc=mycompany,dc=ru" write
by dn="uid=replicator,dc=ldap,dc=mycompant,dc=ru" write
by dn="uid=mailManager,ou=Users,dc=ldap,dc=mycompany,dc=ru"read
by * read
moduleload back_bdb

Конфиг мастера почти такой же за исключение след-их строк:

# Indexing options for database #1
index objectClass eq
index cn pres,sub,eq
index sn pres,sub,eq
index uid pres,sub,eq
index displayName pres,sub,eq
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index default sub

replogfile /var/lib/ldap/replog

replica host=192.168.2.1:389
suffix="ou=spb,ou=Users,dc=ldap,dc=mycompany,dc=ru"
suffix="ou=spb,ou=Hosts,dc=ldap,dc=mycompany,dc=ru"
binddn="uid=replicator,dc=ldap,dc=mycompany,dc=ru"
bindmethod=simple credentials=xxxxxxxxxxxxxxxxxxxxxxx
Ну вот наверное и все по slapd.base

Остался ldap.conf где возможно и есть про проблемы.
на slave он имеет вид
base dc=ldap, dc=mycompany, dc=ru
URI ldap://192.168.1.1 # (master)
Почему у меня в slave прописан URI ldap://192.168.1.1 # (master) - это потому, что когда я репликацию тестил, без его указания репликация была только из мастера на slave, но при ее прописани все пошло и с slave на мастер.
Тут еще что я опытным путем обнаружила - у брав как раз эту строку, и добавив
SIZELIMIT 12
TIMELIMIT 15
и рестартануть сервисы, то pdbedit -L -v начинает летать, вернув конфиг в начальное положение, все как же продолжает летать, обращение идет к локальному лдапу, репликация slave-master и обратно проходит. Не проверил правда как будет себя ведет репликация когда я конфиг изменяю временно, но сегодня или завтра постараюсь проверить.

slave не должен отсылать изменений master'у. slave находится в RO режиме для всех, кроме uid=replicator иначе у вас будет рассинхронизация базы.

Все клиенты (Samba) делают свои изменения на master, на slave'е они появляются после репликации.

Так и происходит - данные slave передает мастеру, а мастер потом передает репликацией на slave, я это сразу проверил когда тестил. Была только одна сложность, как раз в конфиге ldap.conf, с указанием slave сервера в нем нельзя было сделать изменения через slave, только если делать изменения на мастере можно бало их через репликацию получить в slave, а сам славе почему-то их не передавал мастеру, поэтому я в ldap.conf на slave и поставил указание на master - это помогло, репликация пошла двусторонняя, т.е. slave все мастеру, а мастер уже всем. На этом я и успокоился.
Сейчас я нашел выход, приходится после настройки нового slave запускать его как локального на минутку, проверять, что все летает (ну еще с конфигами ldap.conf понипулировать), перевести уже в slave, ldap.conf на место вернуть ну и после этого все прекрасно и реплицируется во все стороны и скорости нормальные.
Кстати про настройки ldap.conf я как-то ничего не нашел на официальном сайте :((

Кто и зачем у вас делает изменения на SLAVE? "почему-то не передавал" - он НЕ ДОЛЖЕН ПЕРЕДАВАТЬ. НИКОГДА.

Не нашли про настройки ldap.conf потому, что со SLAVE на MASTER никто никогда изменений не шлет!

Я может не точно выразился - я имел не изменения на slave которые же отдаются мастеру, этого конечно не происходит, а имел в виду то, что slave, если делать попытку изменения на нем, благодаря записе

updatedn "uid=replicator,dc=ldap,dc=mycompany,dc=ru"
updateref ldap://192.168.1.1:389

все запросы передают master-у, в котором делаются изменения, которые уже и репликацируются на все описанные slave сервера.

>запросы передают master-у
из ваших сообщений я понял, что запросы на чтение тоже обслуживает master, а этого быть не должно.

нет конечно - только изменение данных.

>Если допустим запустить pdbedit -L -v, то пользователи также медленно вываливаются, при этом послушав ldap-мастер видно, что в это время идет обращение к нему :((.

А это кто написал? :)

так собственно в этом и состоял вопрос.
Почему сразу так происходит? В результате я доделываю, что все начинает летать за счет того, что лезет в локальную уже базу, но сразу, в первый раз запуска и без всем описанных выше манипуляций не хочет :((

Разговор слепого с глухим, я вам выше написал в чем может быть проблема.

Что именно вы "доделываете"?

Ну давайте еще раз попробую:
1) стоит только что отставленный сервер, пока с пустой базой и настройкой slapd по умолчанию. Следующие действия:
1) переделали slapd.conf - дописали права доступа и режим сервера (сделали slave), переделали ldap.conf (добавили base и URI с указанием на мастер), скопировали базу с мастера, проиндексировали, запустили slapd.
запустили pdbedit -L -v. Результат - медленная работа этой утилиты. Запустили getent passwd. Результат - быстрая работа этой утилиты.
Вывод - как-то samba непонятно себя видет.

Дальнейшие действия:
1) делаем из slave master-а;
2) из ldap.conf убираем вообще строку с URI, оставляем только base и добавляем, строки;
SIZELIMIT 12
TIMELIMIT 15
3) перезапускаем slapd;
4) проверяем pdbedit -L -v - летает (перевели же в режим мастера);
5) Возвращаем режим из переведенного только что мастера обратно в slave;
6) Возвращаем обратно URU (указывает на master);
7) Перезапускам slapd;
8) Запускаем pdbedit -L -v - ЛЕТАЕТ!! И репликация работает (если пытаться изменить данные на slave или мастере (с мастера на прямую в базу пишет, со slave - передает все запросы на изменение на msater, мастер меняет и реплицирует на slave):)).

2) из ldap.conf убираем вообще строку с URI
6) Возвращаем обратно URU (указывает на master);
ЗАЧЕМ?? для репликации URI в ldap.conf НЕ НУЖЕН. Тем более, если он указывает на MASTER.

Репликация работает БЕЗ URI MASTER в ldap.conf SLAVE. Более того, SLAVE ВООБЩЕ НИКОГДА НА MASTER данных не передает. Только принимает. Что делать со строчкой "ref бла-бла-бла", которую SLAVE отдает всем, кто хочет в него записать должен знать клиент.

Все. Точка.