Description of problem: NSS now supports a superior database format based on sqlite3 databases. CS should start using this new format. NSS shared DB uses sqlite3 to store certs and keys rather than the old berkeley dbm. Sqlite has a vibrant upstream which is continuing to improve the database. The old berkeley DB is basically dead code. The developers moved on to sleepy cat long ago. The only bug fixing to that database format is what we have done. Besides a more vibrant upstream, sqlite3 also provides the ability for multiple processes to safely share a single database instance. It supports transactions, reducing the risk of database corruption (even when used by a single database user). You can also use sqlite3 commands to examine the raw database when debugging issues. The database is used just like the old DBM database. You can continue to open your own private databases, as well as allowing servers to share databases (so they could, for instance, use a single cert database to store all the keys and certs that may be shared by multiple servers). Even more useful for servers, however, is now you can make admin changes without rebooting. If you change the trust on a root cert, or you import a new cert and key, the server will be able to use that new cert and key, or will respond to the new trust attributes immediately without requiring a reboot.
Upstream ticket: https://fedorahosted.org/pki/ticket/167
edewata added the folloowing: The migration issue was fixed in the following changes: https://github.com/dogtagpki/pki/commit/dd8bdc6c9b6e4bd8966237a3606099e74b1a7d9b https://github.com/dogtagpki/pki/commit/d06bed84e50ac3acb578d4e0acc0a538e3826979 https://github.com/dogtagpki/pki/commit/e4384d2c5986b98d5c084e7b9d8f4fa93fddb432 https://github.com/dogtagpki/pki/commit/c02268cc025ebfb0860d5528e080e208e09b3cbb