Форум проекта Pro-LDAP.ru
Общие вопросы по LDAP => Общий раздел => Тема начата: Юрий от 12 Сентябрь 2017, 14:42:45
-
В далёком 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. Сделайте дам базы посредством slapcat
2. Установите OpenLDAP 2.4.45 или ReOpenLDAP 1.1.6 в новую локацию.
3. Переключитесь с бэекнда хранения bdb/hdb на mdb.
4. Восстановите базу посредством slatadd.
5. Проверьте что все работает и после удалите старое.
2.4.28 - это кошмарно старая версия, её нельзя использовать.
bdb/hdb - это старые бекенды хранения на морально устаревшей Berkeley DB, причем с использование старой версии.
-
Здравствуйте, Юрий!
1. В каталоге для хранения локальной базы записей LDAP обнаружил файлы вида log.0000000001, log.0000000002...log.0000000176 на сегодня. К выяснилось это логи транзакций, которые позволяют восстановить базу в случае сбоя на диске или аварийного отключения питания. Но их размер меня уже пугает. Как правильно поступить чтобы уменьшить их размер или избавиться от них без последствий?
У Вас, по всей видимости, используется база BDB, и это логи её транзакций. Если Вы делаете резервные копии каталога или используете репликацию, то хранить их необязательно. Обслуживаются они командой db_archive (https://docs.oracle.com/cd/E17275_01/html/api_reference/C/db_archive.html), на форуме это уже как-то обсуждалось (https://pro-ldap.ru/forum/index.php?topic=64.0).
Чтобы решить эту проблему радикально, лучше перейти на LMDB (back_mdb (https://pro-ldap.ru/tr/man/slapd-mdb.5.html)), эта БД вполне стабильна.
2. Всего на сервере 2 Гб ОЗУ, после перезапуска службы OpenLDAP на сервере занято около 200 Мб памяти, а у процесса openldap 5 дочерних процессов. За несколько месяцев количество процессов openldap вырастает в десятки раз и они съедают всю оперативную память. Подскажите как диагностировать причину такого поведения и как с этим бороться?
С разрастанием количества процессов slapd не сталкивался, даже на старых версиях openldap. Более того, у меня всегда запускается и работает 1 процесс slapd. Может у вас какие-то специфические настройки?
Из общих рекомендаций могу посоветовать перейти на более свежую версию openldap, с 2011 они пофиксили очень много багов, особенно в области репликации.
Егор
PS: Пока писал ответ, Вам уже ответил Леонид =) . В принципе, наши мнения совпали.
-
Здравствуйте. Спасибо Егору и Леониду за оперативные ответы.
У Вас, по всей видимости, используется база BDB
Вы совершенно правы: olcDatabase={1}bdb
По всей видимости придется обновить OpenLDAP и поменять бэкенд хранения данных на mdb.
Если Вы делаете резервные копии каталога или используете репликацию, то хранить их необязательно.
Делаю снимки cn=config и каталога посредством slapcat каждый день + репликация на другой сервер + полные дампы сервера (ось крутится на VMware ESXi)
В моем случае (пока не поменяю бэкенд) можно добавить в файл /var/lib/ldap/DB_CONFIG строку set_flags DB_LOG_AUTOREMOVE чтоб логи транзакций удалялись автоматически? Или лучше не трогать? Как выяснилось снимки базы посредством slapcat за один год занимают в два раза больше места чем эти логи транзакций за все время работы сервера)
Еще раз спасибо. Как дойдут руки к миграции и возникнут вопросы на которые не смогу найти ответ буду просить помощи.
-
Здравствуйте!
В моем случае (пока не поменяю бэкенд) можно добавить в файл /var/lib/ldap/DB_CONFIG строку set_flags DB_LOG_AUTOREMOVE чтоб логи транзакций удалялись автоматически? Или лучше не трогать?
Я так никогда не делал, а сейчас уже попробовать не на чем. Попробуйте сами -- в конце концов, у Вас такое резервирование, что вряд ли что-то потеряется.
Как выяснилось снимки базы посредством slapcat за один год занимают в два раза больше места чем эти логи транзакций за все время работы сервера)
Хранить так много дампов ни к чему, как мне кажется. Неужели может возникнуть необходимость восстановить удалённую год назад учётку =) ? Нужно определить баланс между риском потери данных и расходом ресурсов файловой системы. Обычно проблемы с удалённой учёткой обнаруживаются в первые несколько дней, так что дампы годовой давности -- это перебор. К тому же, дампы slapcat хорошо сжимаются архиваторами типа bzip2 и им подобными.
Дампы cn=config имеет смысл делать только после того, как внесено и протестировано очередное изменение, данные там без вмешательства администратора не меняются сами по себе =) .
Егор