OpenLDAP

随便记一笔，备忘。

形如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

dn: mail=foo@somedomain.org,ou=somedomain.org,ou=org,ou=MailAccounts,dc=somehost
mail: foo@somedomain.org
accountstatus: alias
sn: Foo
cn: Foo account at somedomain.org
objectClass: postfixAlias
objectClass: person
maildrop: delphij@delphij.net
maildrop: someone@example.org
maildrop: someoneelse@example.edu
maildrop: anotherperson@somewhere.com

这样一个项目，希望把后三项删掉。

之前用的邮件系统是基于 postfix、Cyrus IMAPd、amavisd-new等软件在2006年搭建的，跑了5年多，作为不折腾会死星人，对这套系统一直有相当多的不满意，举例来说：

📜 历史文件已不具备现实意义

OpenLDAP 现已转为使用 lmdb。

今天帮陈总研究一个奇怪的问题的时候误操作导致机器停止ssh响应，遂请机房重启。由于机房做的是power cycle，导致部分数据丢失。先前在配置OpenLDAP时，忘记在其中配置checkpoint，另外也没有对这台机器的LDAP进行备份，因此只好尝试从现有的数据库中恢复。冗余不做，日子甭过；备份不做，十恶不赦！

记录一下修复过程。

第一件事是把出问题的数据库做一份备份：rsync -av /var/db/openldap-data/ /var/db/openldap-data.old/

接着尝试slapcat。出现下面的错误：

1
2
3
4
5
6

bdb(dc=********.com): file id2entry.bdb has LSN 1/1476384, past end of log at 1/374639
bdb(dc=********.com): Commonly caused by moving a database from one database environment
bdb(dc=********.com): to another without clearing the database LSNs, or by removing all of
bdb(dc=********.com): the log files from a database environment
bdb(dc=********.com): /var/db/openldap-data/id2entry.bdb: unexpected file type or format
bdb_db_open: database "dc=********.com": db_open(/var/db/openldap-data/id2entry.bdb) failed: Invalid argument (22).

尝试使用BerkeleyDB的修复工具修复：

1
2
3
4
5

# db_recover-4.6 -vvf
Finding last valid log LSN: file: 1 offset 374639
recovery 0% completeRecovery starting from [1][374527]
recovery 67% completeRecovery complete at Tue Jul 13 16:41:59 2010
Maximum transaction ID 800000c0 Recovery checkpoint [1][374639]

slapcat发现问题依旧。搜索Google发现答案基本上都是从备份中恢复，看了一下Oracle的网站，关于这类问题也没有很好的办法。尝试将bdb文件dump出来再load回去：

1
2
3
4
5

db_recover-4.6 -vvf
db_dump-4.6 id2entry.bdb > /tmp/id2entry.dump
rm id2entry.bdb
db_load-4.6 id2entry.bdb < ~/id2entry.dump
db_recover-4.6 -vvf

再次slapcat，发现对另一文件报错，用类似的方法修补之后，slapcat成功。

将slapcat的输出导出到一个文件中： slapcat > /tmp/my.ldif

然后，删除OpenLDAP数据目录：rm /var/db/openldap-data/_* /var/db/openldap-data/[a-z]*

最后，重新使用导出的ldif文件恢复：slapadd -l /tmp/my.ldif。

至此，恢复完成。

trac确实是个好东西。为了方便（主要是为了少维护一个daemon考虑），我采用的方式是cgi方式(除此之外还有两种常见的用法，一种是使用trac自己的daemon，另一种是通过FastCGI)。

总算做完了OpenLDAP 2.4的port，就等kris同学一声令下了。这个版本的OpenLDAP有一些非常搞笑的能力，比如SQL Backend，等等。

I have submitted another patch for python-ldap. This time it’s error path.

之前曾经误认为 Python中存在内存泄漏，不过最终证明还是C程序的问题。Py-LDAP2这个模块在某些情况下，会泄漏一个空的List，具体泄漏代码如下：

retval = Py_BuildValue("(OOiO)", result_str, pmsg, res_msgid, pyctrls ? pyctrls : PyList_New(0));

当pyctrls == NULL时，Py_BuildValue()会为PyList_New(0)生成的那个对象再增加一个引用，这样会导致泄漏。这一问题会发生于调用result()而all=0的情形。

I used to think that ldap_unbind() is the opposite of ldap_bind(), however I was wrong. Pierangelo Masarati (ando at openldap) pointed out that it was actually opposite of ldap_init(). So, do NOT expect init() -> bind() -> search() -> unbind() -> bind() would success, it’s simply wrong thing. You do not need to unbind() before you do another bind().

Just make a note.

今天给某个维护OpenLDAP相关port的老大提了几个patch，等他消息了。

另外就是Python自己也会有泄漏，而且居然是gc部分自己出了许多tuple，这年头：（

今天发现了OpenLDAP client库的一个内存泄漏(每次连接会漏掉大约80字节)，并提交了ITS patch(4441)，不过我觉得这里面上锁上的还是有点问题的，至少逻辑不是很清楚。