We have openldap using the bdb has its database.For some reason the bdb had crashed complaining permission issue.
May 13 16:04:40 ccc slapd[30372]: conn=12430 fd=10 ACCEPT from IP=xxx.yyy.zzz.aaa:33905 (IP=0.0.0.0:389)
May 13 16:04:40 ccc slapd[30372]: conn=12430 op=0 BIND dn="cn=Directory Manager,o=none.com" method=128
May 13 16:04:40 ccc slapd[30372]: conn=12430 op=0 BIND dn="cn=Directory Manager,o=none.com" mech=SIMPLE ssf=0
May 13 16:04:40 ccc slapd[30372]: conn=12430 op=0 RESULT tag=97 err=0 text=
May 13 16:04:40 ccc slapd[30372]: conn=12430 op=1 MOD dn="uid=sysadmin,o=none.com"
May 13 16:04:40 ccc slapd[30372]: conn=12430 op=1 MOD noner=lastlogints lastaccessts authcookie
May 13 16:04:40 ccc slapd[30372]: bdb(o=none.com): /var/lib/ldap/log.0000000002: log file open failed: Permission denied
May 13 16:04:40 ccc slapd[30372]: bdb(o=none.com): PANIC: Permission denied
May 13 16:04:40 ccc slapd[30372]: bdb(o=none.com): DB_ENV->log_put: 2: DB_RUNRECOVERY: Fatal error, run database recovery
May 13 16:04:40 ccc slapd[30372]: bdb(o=none.com): /var/lib/ldap/log.0000000002: log file open failed: Permission denied
The log.000000000 gets rotated based on the size (10MB).The new logfile(log.0000000002) was rotated at on Apr 30th and I believe the permission was set as root:root instead of ldap:ldap(Note: the ldap being run as user ldap).The reason why didnât crash till yesterday was, only search queries were run against the ldap/bdb (The ldap search test for testing ldap keep alive).Yesterday a modify query was run from IP xxx.yyy.zzz.aaa and I guess bdb complained of permission problem and panicked
May 13 16:04:40 ccc slapd[30372]: conn=12430 fd=10 ACCEPT from IP=xxx.yyy.zzz.aaa:33905 (IP=0.0.0.0:389)
May 13 16:04:40 ccc slapd[30372]: conn=12430 op=0 BIND dn="cn=Directory Manager,o=none.com" method=128
May 13 16:04:40 ccc slapd[30372]: conn=12430 op=0 BIND dn="cn=Directory Manager,o=none.com" mech=SIMPLE ssf=0
May 13 16:04:40 ccc slapd[30372]: conn=12430 op=0 RESULT tag=97 err=0 text=
May 13 16:04:40 ccc slapd[30372]: conn=12430 op=1 MOD dn="uid=sysadmin,o=none.com"
[root@ccc ldap]# ls -l /var/lib/ldap
total 13236
-rw------- 1 ldap ldap 106496 Mar 24 19:30 cn.bdb
-rw------- 1 ldap ldap 16384 Mar 20 11:50 __db.001
-rw------- 1 ldap ldap 278528 Mar 20 11:50 __db.002
-rw------- 1 ldap ldap 98304 Mar 20 11:50 __db.003
-rw------- 1 ldap ldap 450560 Mar 20 11:50 __db.004
-rw------- 1 ldap ldap 16384 Mar 20 11:50 __db.005
-rw------- 1 ldap ldap 45056 Mar 24 19:30 dn2id.bdb
-rw------- 1 ldap ldap 278528 Apr 2 13:40 id2entry.bdb
-rw------- 1 ldap ldap 10485710 Apr 30 14:40 log.0000000001
-rw------- 1 root root 1827874 May 13 16:00 log.0000000002
-rw------- 1 ldap ldap 8192 Mar 20 11:50 mail.bdb
-rw------- 1 ldap ldap 16384 Mar 24 19:30 objectClass.bdb
-rw-r--r-- 1 ldap ldap 0 Apr 2 13:31 openldap-master-replog
-rw-r--r-- 1 ldap ldap 0 Apr 2 13:31 openldap-master-replog.lock
-rw------- 1 ldap ldap 8192 Mar 20 11:50 ou.bdb
drwxr-xr-x 2 root root 4096 Mar 21 16:33 replica
-rw------- 1 ldap ldap 49152 Mar 20 11:50 sn.bdb
-rw------- 1 ldap ldap 8192 Mar 20 12:00 uid.bdb
The ldap is being run as user ldap
[root@ccc ~]# ps -ef | grep ldap
root 8983 6956 0 15:40 pts/0 00:00:00 grep ldap
ldap 31694 1 0 Mar20 ? 00:01:57 /usr/sbin/slapd -u ldap -h ldap:///
[root@ccc ~]# grep ldap /etc/passwd
ldap:x:55:55:LDAP User:/var/lib/ldap:/bin/false
Why should a modify cause a panic and not a search?Why did the rotated log had root as owner instead of ldap?Is there a fix for this issue?
Cheers CG
Govind c writes:
The log.000000000 gets rotated based on the size (10MB).
_Rotated_? With logrotate or something like a syslog file? If so you sabotaged your database. This is a database log file to be used for recovery, you should not rotate it. You can delete it when db_archive says so, see the Berkeley DB doc. Or you can set it up to be auto- deleted when it is no longer needed, if you do not need to support catastrophic recovery.
The new logfile(log.0000000002) was rotated at on Apr 30th and I believe the permission was set as root:root instead of ldap:ldap(Note: the ldap being run as user ldap).
That'd explain permission denied all right.
On Tuesday 03 June 2008 18:06:46 Govind c wrote:
We have openldap
What version ?
using the bdb has its database.For some reason the bdb had crashed complaining permission issue.
[...]
May 13 16:04:40 ccc slapd[30372]: conn=12430 op=1 MOD noner=lastlogints lastaccessts authcookie
May 13 16:04:40 ccc slapd[30372]: bdb(o=none.com): /var/lib/ldap/log.0000000002: log file open failed: Permission denied
May 13 16:04:40 ccc slapd[30372]: bdb(o=none.com): PANIC: Permission denied
May 13 16:04:40 ccc slapd[30372]: bdb(o=none.com): DB_ENV->log_put: 2: DB_RUNRECOVERY: Fatal error, run database recovery
May 13 16:04:40 ccc slapd[30372]: bdb(o=none.com): /var/lib/ldap/log.0000000002: log file open failed: Permission denied
[...]
-rw------- 1 ldap ldap 10485710 Apr 30 14:40 log.0000000001
-rw------- 1 root root 1827874 May 13 16:00 log.0000000002
-rw------- 1 ldap ldap 8192 Mar 20 11:50 mail.bdb
[...]
The ldap is being run as user ldap
Why should a modify cause a panic and not a search?
Transactions usually only occur when an entry is changed (added, deleted, modified).
Why did the rotated log had root as owner instead of ldap?
Since slapd is not running as root, it is impossible that slapd created the transaction log.
Is there a fix for this issue?
I think in some versions of OpenLDAP (2.1 to 2.2?) slapcat could incorrectly incur a transaction. So, if slapcat was run as root on 13 May at 16:00, that would be the cause. The fix would be to either upgrade, or to run your slapcat as the ldap user.
If slapcat wasn't run on 13 May at 16:00, some other administration (slapadd?) was run as root, and the permissions were not corrected before slapd was started.
Regards, Buchan
openldap-technical@openldap.org
-
Buchan Milne -
Govind c -
Hallvard B Furuseth