Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Юрий

Страницы: [1]
1
Здравствуйте. Спасибо Егору и Леониду за оперативные ответы.

Цитировать
У Вас, по всей видимости, используется база BDB
Вы совершенно правы: olcDatabase={1}bdb

По всей видимости придется обновить OpenLDAP и поменять бэкенд хранения данных на mdb.

Цитировать
Если Вы делаете резервные копии каталога или используете репликацию, то хранить их необязательно.

Делаю снимки cn=config и каталога посредством slapcat каждый день + репликация на другой сервер + полные дампы сервера (ось крутится на VMware ESXi)

В моем случае (пока не поменяю бэкенд) можно добавить в файл /var/lib/ldap/DB_CONFIG строку set_flags DB_LOG_AUTOREMOVE чтоб логи транзакций удалялись автоматически? Или лучше не трогать? Как выяснилось снимки базы посредством slapcat за один год занимают в два раза больше места чем эти логи транзакций за все время работы сервера)

Еще раз спасибо. Как дойдут руки к миграции и возникнут вопросы на которые не смогу найти ответ буду просить помощи.

2
В далёком 2014 году был поднят Ubuntu Server 12.04 + openldap-2.4.28 для организации единой базы пользователей организации, все делалось как временное решение, так как на тот момент руководство трубило что вот-вот внедрим Active Directory и все пользователи переедут туда. Но как говорится "нет ничего более постоянного, чем временное". Спасибо ресурсу pro-ldap.ru за огромное количество материала, которое было использовано при внедрении каталога пользователей. Но дело в том что настраивалось все на скорую руку без углубления в тонкости оптимизации, производительности, безопасности... Каталог используется только для авторизации пользователей на ресурсах сети (Zimbra, Kanboard, Openfire и еще нескольких собственных БД).
Структура каталога следующая:
корень
|\ ou=Group
      |\ cn=mail
      |\ cn=kanboard
       \ cn=jabber
\ ou=Users
      |\ uid=user1
      |\ uid=user2
       \ ...
+ наложение MemberOf (именно по вхождению пользователя в группу разграничивается доступ к ресурсам).
+ наложение Syncprov (для синхронизации с резервным каталогом)

Не хочется заново глубоко вникать в это "временное решение", но вылезло несколько вопросов которые не дают спокойно спать:

1. В каталоге для хранения локальной базы записей LDAP обнаружил файлы вида log.0000000001, log.0000000002...log.0000000176 на сегодня. К выяснилось это логи транзакций, которые позволяют восстановить базу в случае сбоя на диске или аварийного отключения питания. Но их размер меня уже пугает. Как правильно поступить чтобы уменьшить их размер или избавиться от них без последствий?

2. Всего на сервере 2 Гб ОЗУ, после перезапуска службы OpenLDAP на сервере занято около 200 Мб памяти, а у процесса openldap 5 дочерних процессов. За несколько месяцев количество процессов openldap вырастает в десятки раз и они съедают всю оперативную память. Подскажите как диагностировать причину такого поведения и как с этим бороться?

Страницы: [1]