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.
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. 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). 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). Something probably deserves to be in update55.html as well, but I don't have a repeatable, documented procedure for what I did. -- Matthew Weigel hacker unique & idempot . ent
