LDAP因不明原因死亡

我们使用LDAP作为我们drupal站点的后端用户数据库（drupal从/读取并写入）。 LDAP已经运行好几个星期，但由于某些原因，它只是今天停止运行。 我正在使用以下命令查看syslog：

$ grep -i "error\|panic\|unable\|warning\|fatal\|issue" /var/log/syslog | grep slapd 

出现的第一个错误是这些错误：

 Sep 20 09:59:38 server slapd[18158]: bdb(dc=example,dc=org): PANIC: fatal region error detected; run recovery Sep 20 09:59:38 server slapd[18158]: conn=1010 op=7 RESULT tag=107 err=80 text=internal error 

问题1：有什么方法可以find更多fatal region error ？ （也许drupal的ldap模块正在发布openldap不喜欢的命令）。

根据错误消息的build议，我运行了恢复工具：

• openldap：如何实现密码策略？
• 带有ldapmodify＆.ldif文件的LDAP ACL仅允许用户访问
• 在200台计算机上实现域login
• 数据库恢复后的LDAP：“不可接受的日志文件”
• LDAP：错误代码49 – 将jira连接到Mac OS X Lion Server LDAP时无效的证书

 $ sudo /etc/init.d/slapd stop $ sudo /usr/bin/db4.7_recover -v -h /var/lib/ldap/ Finding last valid log LSN: file: 3916 offset 298418 Recovery starting from [3916][298273] Recovery complete at Tue Sep 20 12:17:42 2011 Maximum transaction ID 80000017 Recovery checkpoint [3916][298418] $ sudo /etc/init.d/slapd start 

我在syslog中看到的是这样的：

 Sep 20 12:17:47 server slapd[10286]: @(#) $OpenLDAP: slapd 2.4.21 (Jun 2 2011 19:36:19) $#012#011buildd@allspice:/build/buildd/openldap-2.4.21/debian/build/servers/slapd47 Sep 20 12:17:47 server slapd[10286]: PROXIED attributeDescription "DC" inserted. Sep 20 12:17:48 server slapd[10287]: bdb(dc=example,dc=org): /var/lib/ldap/log.0000003916: log file unreadable: Permission denied <----- HERE Sep 20 12:17:48 server slapd[10287]: bdb(dc=example,dc=org): PANIC: Permission denied Sep 20 12:17:48 server slapd[10287]: bdb(dc=example,dc=org): Invalid log file: log.0000003916: DB_RUNRECOVERY: Fatal error, run database recovery Sep 20 12:17:48 server slapd[10287]: bdb(dc=example,dc=org): PANIC: DB_RUNRECOVERY: Fatal error, run database recovery 

发生的情况是，其中一个日志文件不能被slapd读取，因为所有者已经从openldap更改为root并且权限被设置为600：

 /var/lib/ldap/log.0000003916: log file unreadable: Permission denied $ sudo ls -lh /var/lib/ldap/ -rw------- 1 openldap openldap 10M 2011-09-09 11:09 log.0000003914 -rw------- 1 openldap openldap 10M 2011-09-20 09:54 log.0000003915 -rw------- 1 root root 10M 2011-09-20 12:10 log.0000003916 <----- HERE -rwxr-xr-x 1 openldap openldap 20M 2011-09-20 12:51 mail.bdb -rwxr-xr-x 1 openldap openldap 1.7M 2011-09-20 12:51 objectClass.bdb -rwxr-xr-x 1 openldap openldap 12M 2011-09-20 12:51 sn.bdb -rwxr-xr-x 1 openldap openldap 1.4M 2011-09-20 12:51 uid.bdb 

我通过将所有者从根目录更改为openldap来解决此问题：

 $ sudo chown openldap:openldap /var/lib/ldap/log.0000003916 

然后slapd正常启动：

 Sep 20 13:01:40 evergreen slapd[18901]: @(#) $OpenLDAP: slapd 2.4.21 (Jun 2 2011 19:36:19) $#012#011buildd@allspice:/build/buildd/openldap-2.4.21/debian/build/servers/slapd Sep 20 13:01:40 evergreen slapd[18901]: PROXIED attributeDescription "DC" inserted. Sep 20 13:01:41 evergreen slapd[18902]: slapd starting 

在运行db4.7_recover之前，我没有检查该日志文件的权限，所以我不知道将所有者设置为root。

问题2：build议运行db4.7_recover作为openldap，以避免日志文件的许可问题（例如：sudo -u openldap /usr/bin/db4.7_recover -v -h / var / lib / ldap）？

问题3：作为一个更通用的问题：有没有一种方法来监视哪个进程上次更改文件的权限？ （这样，如果问题不是与运行db4.7_recover作为sudo我可以找出它是什么）。

问题4：您是否有更多的build议来解决这类LDAP问题？

附加信息：
服务器= Ubuntu的10.04
-openldap = https://help.ubuntu.com/community/OpenLDAPServer