У меня есть 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, работающего в фоновом режиме, когда какой-либо пользователь входит в систему.
В 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 результат: SEARCH RESULT tag=101 err=0 nentries=1 text. Также ожидается 0 результатов, имя пользователя или числовой uidNumber неизвестны, более одного результата будут интересны, учетные записи пользователей и числовое uidNumber должны быть уникальными и отличными для каждого уникального пользователя.
Вы можете настроить свои клиенты Linux для создания и поддержки кеша с результатами таких запросов в центральный каталог пользователей, что должно снизить нагрузку на ваш сервер LDAP, привести к меньшему количеству записей в журнале и улучшить работу клиентов.
Установите и включите nscd (демон кэширования службы имен) на клиентах. Настройка nscd обычно не требуется.