On 2014-07-22, Matthew Weigel <uni...@idempot.net> wrote: > I finally upgraded my last machine - that runs ldapd(8) for user > logins, mail aliases, and a few other odds and ends - from 5.4 to 5.5.
Haha! I just did the same two days ago. > I'm left wondering if I'm the only one who actually uses the stock > ldapd(8), because it is not called out at all in upgrade55.html as > having problems with the Year 2038 fixes that went into 5.5. No, I'm here. > 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? > 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. -- Olivier Mehani <sht...@ssji.net> PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted.
