Мы используем LDAP в качестве серверной базы данных пользователей для наших сайтов drupal (drupal читает из / и записывает в нее). LDAP работает нормально в течение нескольких недель, но по какой-то причине он просто перестал работать сегодня. Я смотрел системный журнал, используя следующую команду:
$ 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
Q1: Есть ли способ узнать больше о причинах fatal region error? (возможно, модуль ldap drupal выдает команды, которые не нравятся openldap).
Следуя совету из сообщения об ошибке, я запустил инструмент восстановления:
$ 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
В системном журнале я вижу следующее:
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
Я исправил это, изменив владельца с root на 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.
Q2: рекомендуется ли запускать db4.7_recover как openldap, чтобы избежать проблем с разрешениями в файлах журнала (например, выполните sudo -u openldap /usr/bin/db4.7_recover -v -h / var / lib / ldap)?
Q3: В качестве более общего вопроса: есть ли способ отслеживать, какой процесс последним изменил права доступа к файлу? (таким образом, если проблема не в запуске db4.7_recover как sudo я могу узнать, что это такое).
Q4: Есть ли у вас дополнительные советы по устранению неполадок этого типа LDAP?
Дополнительная информация:
-сервер = ubuntu 10.04
-openldap =https://help.ubuntu.com/community/OpenLDAPServer
На загруженных серверах я видел, как OpenLDAP имеет проблемы с дескрипторами файлов размером 1024 max по умолчанию. Увеличьте это ограничение в /etc/security/limits.conf для пользователя openldap и посмотрите, решит ли это проблему. Обычно, если это причина, slapd будет жаловаться на это в журналы.
При определенных обстоятельствах slapd также может со временем утечка памяти, и в результате OOM ядра Linux убьет его. Если это произошло, dmesg расскажет вам историю о том, как убийца не в памяти храбро убил slapd.
Q2: не имеет значения, если вы исправляете разрешения перед запуском slapd.
Q3: Подсистема аудита Linux может вам в этом помочь. Прочтите man auditd и auditctl; ответ на это выходит за рамки вашего первоначального Q :)
Q4: Увеличьте уровень лога slapd до максимума, читайте логи. Google.