☰

openldap：日志级别“stats”下的日志文件非常大

tag-icon • tag-icon linux logging openldap
openldap：日志级别“stats”下的日志文件非常大

我有一台运行 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。

相关内容