linux – openldap:日志级别的巨大日志文件’stats’

前端之家收集整理的这篇文章主要介绍了linux – openldap:日志级别的巨大日志文件’stats’前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有一个运行openldap的 linux服务器用于用户管理.日志级别设置为“stats”,我认为这是某个地方的“推荐”日志级别.现在的问题是日志文件正在快速增长,大量的条目由少数KDE 4客户端的查询生成:每秒,创建以下表单的dozends条目
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确实是默认的日志级别,如 manual中所述.

这些对于具有LDAP后端的Linux系统来说似乎是完全有效的查询.

过滤器:“(&(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未知,超过1个结果将是有趣的,用户帐户和数字uidNumber应该是唯一的并且对于每个唯一用户是不同的.

您可以将Linux客户端配置为创建和维护缓存,并将此类查询的结果发送到中央用户目录,这样可以减少LDAP服务器的负载,减少日志条目,并使客户端也能更好地运行.

在客户端上安装并启用nscd(名称服务缓存守护程序).通常不需要调整nscd.

原文链接:https://www.f2er.com/linux/398844.html

猜你在找的Linux相关文章