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’更冗长的东西,这在我的情况下是否有意义？
解决方法
这些对于具有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.
