openldap: огромные файлы журнала на уровне журнала «статистика»
У меня есть Linux-сервер, на котором запущен openldap для администрирования пользователей. Уровень журнала установлен на 'stats', который я видел где-то "рекомендуемым" уровнем журнала. Теперь проблема в том, что файлы журналов быстро растут, причем большая часть записей создается запросами от нескольких клиентов KDE 4: в секунду, создаются десятки записей следующей формы
Apr 19 13:21:50 ###### slapd[1429]: conn=1001 op=26379 SRCH base="dc=###" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=####))"
Apr 19 13:21:50 ###### slapd[1429]: conn=1001 op=26379 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Apr 19 13:21:50 ###### slapd[1429]: conn=1001 op=26379 SEARCH RESULT tag=101 err=0 nentries=1 text=
Apr 19 13:21:50 ###### slapd[1429]: conn=1001 op=26380 SRCH base="dc=###" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uidNumber=####))"
Apr 19 13:21:50 ###### slapd[1429]: conn=1001 op=26380 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Apr 19 13:21:50 ###### slapd[1429]: conn=1001 op=26380 SEARCH RESULT tag=101 err=0 nentries=1 text=
Я не имею четкого представления, какой именно компонент клиентов создает этот поток запросов. Мое сильное предположение заключается в том, что он исходит от какого-то стандартного компонента KDE, работающего в фоновом режиме, когда какой-то пользователь входит в систему.
- Это нормальное поведение или клиенты сходят с ума? Угадайте, откуда берутся запросы?
- Если это нормально, я не могу использовать уровень «статистика». Есть ли что-то более подробное, чем уровень журнала «none», который имеет смысл в моей ситуации?
loglevel = stats действительно является уровнем журнала по умолчанию, как описано в руководство .
Эти запросы кажутся совершенно правильными для системы Linux, имеющей серверную часть LDAP.
Фильтр: "(& (objectClass = posixAccount) (uid = ####))" - это поиск учетной записи с определенным именем для входа. Я ожидал бы таких запросов от вашего стека PAM, когда пользователь пытается войти в систему.
Фильтр: (& (objectClass = posixAccount) (uidNumber = ####)) ищет информацию связанный с числовым uidNumber. Я ожидал бы таких запросов, когда вашей системе необходимо преобразовать числовые номера UID, используемые вашей системой, в более понятные для человека имена для входа, например, когда выполняется ls -l .
Запрашиваются следующие атрибуты учетной записи: attr = uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass , которые являются обычными атрибутами учетной записи POSIX для учетной записи пользователя.
Этот запрос LDAP выполнен успешно и, как и ожидалось, дает ровно 1 результат: Тег РЕЗУЛЬТАТА ПОИСКА = 101 ошибка = 0 записей = 1 текст . Также ожидается 0 результатов, имя пользователя или числовой uidNumber неизвестны, более одного результата будут интересны, учетные записи пользователей и числовое uidNumber должны быть уникальными и отличными для каждого уникального пользователя.
Вы можете настроить своих клиентов Linux. для создания и поддержки кеша с результатами таких запросов в центральный каталог пользователей, что должно снизить нагрузку на ваш сервер LDAP, привести к меньшему количеству записей в журнале и улучшить работу клиентов.
Установите и включите nscd (демон кэширования службы имен) на клиентах. Настройка nscd обычно не требуется.