LDIF export/import问题请教

001CEO

正在将已经运行几年的OPENLDAP 2.0.27升级到2.3.32，升级过程中遇到一些问题向大家请教。

LDAP的结构如附图所示，其中每个RCCD是一个用户的记录，系统中有几万个用户。现在使用LDAP BROWSER 2.8.1从OPENLDAP 2.0.27中将数据EXPORT到LDIF中，然后再IMPORT到新版本的2.3.32中。
按图示的LDAP结构，在EXPORT产生的LDIF中应该是先有

dn: RCCD=AAA3140003t,dc=mountaincable,dc=net

然后才能有

dn:  ou=mail,RCCD=AAA3140003t,dc=mountaincable,dc=net
dn:  ou=ftp,RCCD=AAA3140003t,dc=mountaincable,dc=net

接下来才是
dn:  uid=pmartin,ou=mail,RCCD=AAA3140003t,dc=mountaincable,dc=net
dn:  uid=pmartin,ou=ftp,RCCD=AAA3140003t,dc=mountaincable,dc=net

这样在IMPORT的时候才能按正确的顺序建立LDAP的ENTRY。然而现在却出问题了，在EXPORT产生的LDIF文件中，有少部分RCCD记录的数据不是按上面说的顺序排列，而是
dn: RCCD=AAA3140003t,dc=mountaincable,dc=net

出现在最后，这样在IMPORT的时候，对于

dn:  ou=mail,RCCD=AAA3140003t,dc=mountaincable,dc=net
dn:  ou=ftp,RCCD=AAA3140003t,dc=mountaincable,dc=net

因为dn: RCCD=AAA3140003t,dc=mountaincable,dc=net还没有建立，所以建立ou=mail和ou=ftp出错，错误代码err=32(记得应该是 no such objects吧?）

请问出现这样的问题可能的原因是什么？LDAP BROWSER的BUG？问题是在几万个用户的数据输出到LDIF时，只有少数几十个用户的数据出现这样的问题，其他绝大多数都正常。除了用手工或者程序修改EXPORT产生的错误LDIF文件的DN排列顺序外，还有什么办法产生正确顺序的LDIF文件？

谢谢。

[ 本帖最后由 001CEO 于 2007-4-13 23:56 编辑 ]

neophiliac

Did you try to use slapcat to dump your data from ldap server? Maybe it caused by the interoperability between LDAP BROWSER 2.8.1 and OPENLDAP 2.0.27.

001CEO

用LDAP BROWSER就只有少数记录的顺序错误，属性内容没发现有错误的，用slapcat的结果，数据顺序完全乱套了，而且还有一些属性的值也是错误的，而且在slapcat产生的LDIF文件中出现以下内容

creatorsName: cn=Manager,dc=mountaincable,dc=net
createTimestamp: 20021202143249Z
modifiersName: cn=Manager,dc=mountaincable,dc=net
modifyTimestamp: 20021202143249Z

这些内容是在某个用户的RCCD记录之下，这在LDAP BROWSER产生的LDIF文件中是没有的。
dn: ou=mail, RCCD=AAA3149135m, dc=mountaincable, dc=net
objectClass: top
objectClass: organizationalUnit
ou: mail
creatorsName: cn=Manager,dc=mountaincable,dc=net
createTimestamp: 20021202143249Z
modifiersName: cn=Manager,dc=mountaincable,dc=net
modifyTimestamp: 20021202143249Z

neophiliac

原帖由 001CEO 于 2007-4-16 23:50 发表
creatorsName: cn=Manager,dc=mountaincable,dc=net
createTimestamp: 20021202143249Z
modifiersName: cn=Manager,dc=mountaincable,dc=net
modifyTimestamp: 20021202143249Z

This formate is absolutely right. ldapsearch is not to design for backup data, and one of the immediate reasons is the ldif file which is generated by ldapsearch command is loss of integrity. Some of the internal attribute value could not be dumped into the ldif file.
You can just use slapadd to recover ldif file output by slapcat regardless what the entries' sequence is.

001CEO

上面显示的是slapcat产生的，不是ldapsearch产生的。如果直接把这样顺序有错误的LDIF文件导入到新的LDAP中，有错误的那些记录将不会被导入，我已经试验过了  ：（

原帖由 neophiliac 于 2007-4-17 09:13 发表

This formate is absolutely right. ldapsearch is not to design for backup data, and one of the immediate reasons is the ldif file which is generated by ldapsearch command is loss of integrity. Som ...