![网络启动之前出现 LDAP 错误](https://linux22.com/image/1050473/%E7%BD%91%E7%BB%9C%E5%90%AF%E5%8A%A8%E4%B9%8B%E5%89%8D%E5%87%BA%E7%8E%B0%20LDAP%20%E9%94%99%E8%AF%AF.png)
我在启动过程中收到以下类型的错误:
May 11 12:19:25 vagrant-ubuntu-vivid-64 sh[482]: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server
May 11 12:19:25 vagrant-ubuntu-vivid-64 sh[482]: nss_ldap: failed to bind to LDAP server ldap://ldap: Can't contact LDAP server
May 11 12:19:25 vagrant-ubuntu-vivid-64 sh[482]: nss_ldap: reconnecting to LDAP server...
May 11 12:19:25 vagrant-ubuntu-vivid-64 sh[482]: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server
May 11 12:19:25 vagrant-ubuntu-vivid-64 sh[482]: nss_ldap: failed to bind to LDAP server ldap://ldap: Can't contact LDAP server
May 11 12:19:25 vagrant-ubuntu-vivid-64 sh[482]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
这发生在网络启动之前,此时 ldap 服务器显然无法访问。一旦网络启动,ldap 身份验证就可以正常工作。
重点是,启动过程不需要从 ldap 服务器检索任何用户或组。
/etc/nsswitch.conf配置如下:
passwd: files ldap
group: files ldap
shadow: files ldap
hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
请注意,相同的设置不会导致 Ubuntu 14.10 出现任何错误。
我如何找出尝试连接 ldap 的对象及其原因?
更新
journalctl -o verbose _PID=482
返回
_UID=0
_GID=0
_SYSTEMD_SLICE=system.slice
PRIORITY=3
_CAP_EFFECTIVE=3fffffffff
_EXE=/bin/dash
_SYSTEMD_CGROUP=/system.slice/networking.service
_SYSTEMD_UNIT=networking.service
_TRANSPORT=syslog
SYSLOG_IDENTIFIER=sh
SYSLOG_FACILITY=10
MESSAGE=nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server
_PID=484
_COMM=resolvconf
_CMDLINE=/bin/sh /sbin/resolvconf -a lo.inet
_SOURCE_REALTIME_TIMESTAMP=1431438028207234
我仍然不明白发生了什么。networking.service 单元似乎实际上不包含任何内容,所以我不知道它与 resolvconf 有何关系。我也不明白为什么 resolvconf 使用 ldap 地址。
答案1
我如何找出尝试连接 ldap 的对象及其原因?你查看日志,发现它显示:
12:19:25 vagrant-ubuntu-vivid-64 sh[482]: nss_ldap:重新连接到 LDAP 服务器...您认为:
“啊哈!进程 ID 482。”然后你跑
journalctl-o详细_PID=482并且可能
journalctl-o详细SYSLOG_PID = 482并进一步查看日志,以准确了解“sh”是什么程序、它传递了什么命令行以及哪个用户正在运行它。