On 7/22/14, 9:03 PM, Olivier Mehani wrote:
I ended up having to create a 5.4 VM (I stuck with the same amd64 arch
as my actual server, and have not investigated or tested under what
constraints this might work across architectures) to load the ldapd(8)
database files, use third party LDAP tools to create a text dump in
LDIF format, and then load the LDIF into an empty database of 5.5
ldapd(8).
I'm currently trying to cobble together a binary importer which reads
5.4 dbs, and writes them as 5.5 dbs. It's a bit ugly, based on
frankensteined code from ldapd and ldapctl. I haven't found a straight
way to write back into a file, so I'm trying go down the compacting way,
which appears to be rewriting an entirely new database.
Hopefully, it should work in the end.
I thought about the VM/dump option, but all I could find was for slapd
(using slapcat). Could you give more details on the tools you use?
Someone else asked about this off the list. After setting up the VM
and copying /etc/ldapd.conf, /etc/ldap/*.schema, and /var/db/ldap/*.db
into it, I started up ldapd(8) and connected to it with ldapvi(1) from
ports. I wrote out the contents of that buffer to a separate file, and
that was my not-exactly-LDIF text backup.
To add those entries to the 5.5 server, I replaced the numeric
identifier ldapvi(1) uses for existing entries with the special key
'add' like so:
0 dc=example,dc=net
objectClass: dcObject
objectClass: organization
objectClass: top
dc: example
o: example.net
description: Account and Group LDAP Identity Database
was changed to
add dc=example,dc=net
objectClass: dcObject
objectClass: organization
objectClass: top
dc: example
o: example.net
description: Account and Group LDAP Identity Database
I had to use ldapadd(1) from the openldap-client package to populate
the root object before ldapvi(1) would work, however. I think I also
had to add the structure of the LDAP tree first, and do a second round
of edits to populate leaf nodes.
It looks like particularly the btree_stat and btree_meta structs used
in the ldapd(8) btree implementation are the culprits, as it looks like
they are the only time_t bits actually stored on disk. Since it
appears my problems are now solved, I'm mostly sending this message as
a heads up in case there is anyone still getting ready to upgrade to
5.5 that uses ldapd(8).
I think only the btree_meta is relevant, as I don't see the btree_stat
being written on disk.
Maybe, I didn't dig too deep into it once I solved my problems.
--
Matthew Weigel
hacker
unique & idempot . ent
