![openldap:日志级别“stats”下的日志文件非常大](https://linux22.com/image/702789/openldap%EF%BC%9A%E6%97%A5%E5%BF%97%E7%BA%A7%E5%88%AB%E2%80%9Cstats%E2%80%9D%E4%B8%8B%E7%9A%84%E6%97%A5%E5%BF%97%E6%96%87%E4%BB%B6%E9%9D%9E%E5%B8%B8%E5%A4%A7.png)
我有一台运行 openldap 的 Linux 服务器用于用户管理。日志级别设置为“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 组件。
- 这是正常现象吗?还是客户疯了?猜猜这些查询来自哪里?
- 如果这是正常的,我就不能使用“统计”级别。有没有比日志级别“无”更详细的内容,对我的情况有意义?
答案1
确实是loglevel=stats
默认日志级别,如中所述手动的。
对于具有 LDAP 后端的 Linux 系统来说,这些查询似乎是完全有效的。
过滤器:"(&(objectClass=posixAccount)(uid=####))"
查找具有特定登录名的帐户。当用户尝试登录时,我希望您的 PAM 堆栈能够进行此类查询。
过滤器:(&(objectClass=posixAccount)(uidNumber=####))
查找与数字 uidNumber 相关的信息。当您的系统需要将系统使用的数字 UID 号转换为更人性化的登录名时,例如ls -l
执行 a 时,我会期待此类查询。
请求以下帐户属性: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 未知,超过 1 个结果会很有趣,用户帐户和数字 uidNumber 应该是唯一的,并且对于每个唯一用户都是不同的。
您可以配置您的 Linux 客户端来创建并维护一个缓存,其中包含对中央用户目录的此类查询的结果,这应该会减少您的 LDAP 服务器上的负载,减少日志条目,并使客户端的性能更好。
在客户端上安装并启用nscd
(名称服务缓存守护进程)。通常不需要调整 nscd。