Исчезают записи в LDAP.

а чем записи добавляете, милейший ? если через ldapadd то нужно попробовать поиграться с настройками самого ldap (bdb вместо ldbm или наоборот ...)

А какая собственно разнца через что добавлять? Все равно все сводится к командам LDAP протокола. Мне кажется дело в чем-то другом. Логи сервера смотрели? GQ вобще страшное глюкало. Если смотреть, то только через ldapsearch. Вобще странное дело. Я подобный переход сделал давно (на RedHat) и пока все ОК (тьфу тьфу). Если данные дошли до базы на диске, то куда им собственно деваться-то? Ошибка проявляется всегда или раз от раза? Место на диске? Нужны подробности короче.

Ошибка появляется от раза к разу, вот последний раз была вчера. Пропали двен последних учетных записи и 4 записи почтовых аккаунтов (они у меня раздельные) и 4 записи в адресной книге (все было добавлено в течение последней недели). После перезагрузки LDAP появились учетные записи, а вот мейлы так и не появились, пришлось их снова забивать.

Какое бы глюкало GQ не было бы, ведь и другие средства перестают видеть, qmail перестает принимать письма для юзеров, Samba тоже перестает их находить, так что дело то явно не в нем. К тому же GQ я использу. только для визуальной навигации по дереву, а создаю записи и модифицирую их как правило родными средствами smb-ldap-tools...

backend используется bdb, место на var около 3GB.

на счет логов, то какой посоветуете поставить уровень, чтобы отловить подобное? обращение то идет многно и просто просматривать полный лог замучаешься...

а как на счет inodes?????

Для начала, наверное нужно проверить состояние ОС. Возможно slapd плохо живется: состояние диска (свободные иноды, блоки, ...), загрузка сервера, состояние памяти, открытые сокеты, не мешает проверить системные логи за этот период. Для более подробного просмотра лога slapd уровень, насколько я помню, нужно понижать, поставьте например 256 - посмотрите. Вообще желательно видеть все принимаемые им LDAP команды, посмотрите команды свзанные с удаением, модификацией. Посмотрите error'ы, варнинги. Не советую ставить уровень лога -1 - производительность резко подсядет вплоть до того, что не сможете нормально работать. Далее, насчет backend. У меня стоит ldbm, насколько я понимаю это его родная база. Попробуйте перейти на нее. Может у него глюк с bdb ? Посмотрите параметры базы 'man 5 slapd.conf'. Например, у ldbm есть такие параметры как dbnosync, dbnolocking и тд, которые могут вызвать такую ситуацию - т.е. нарушение целостности если нет локировки или синхронизации. Посмотрте подобные опции для bdb.

Короче вырисовывается три зоны поиска: 1) Влияние ОС 2) Влияние каких-либо LDAP приложений, тогда в логах увидите команды удаления записей - закройте всем доступ на модификацию в ACL. 3) Некорректная настройка/поведение самого openldap. Посмотрите настройки базы, попробуйте перейти на ldbm, закройте всем доступ на модификацию в ACL

Для выявления точного времени сбоя можно периодически снимать ldif базы (например раз в 10 миннут) и сравнивать ее с целостной версией.

Можно списаться по email

мой адрес rikoil@newmail.ru

странная проблема и мыло.. ну хорошо: нет челоевка - нет и проблемы.