Changes

Jump to: navigation, search

NSS Shared DB

2,872 bytes added, 00:35, 26 January 2008
Database Upgrade
==== Database Upgrade ====
To understand the issues of migration NSS has traditionally performed automatic updates when moving to the Shareable Database version new database formats. If NSS cannot find a database that matches it's current database type, it looks for older versions of NSS from the traditional (legacy) it's database and automatically updates those versions, we group applications that use to the new database version of NSS into three 'modes' of operation, . In these cases database upgrade is automatic and into two types, of which there are five valid combinationsmandatory for all applications.
In the shared database design, upgrade is no longer mandatory. Applications may choose to remain using the old DBM database, update to using the new shared database from old DBM databases, or merge your old DBM database into a new location shared by multiple apps. There is still a desire for this update to be automatic, at least as far as the application user is concerned. The following design manages this update. To understand the issues of migration to the Shareable Database version of NSS from the traditional (legacy) versions, we group applications that use the new version of NSS into three 'modes' of operation, and into two types for a total of five valid combinations (Mode 1 B is not valid)..  Mode 1: Legacy applications which formerly used DBM databases, that and upgrade to the new version of NSS without making any changes to the applications' code, or applications that chose to continue to use the DBM database.
These applications will continue to use the legacy database support and the
old DBM database format. The applications cannot take advantage of new features
in the shared database. In this Mode, the nssdbm3 shared library must be
present. No update from legacy DBM to sharable is needed in this mode.
Application Changes: none.
Mode 2: Applications that use the new shareable database engine, but choose not to share copies of their cert and key stores. They wish , or applications which would prefer to keep merge databases as a separate copies of their databasesstep. They may or may not have existing legacy DBM databases from older versions of those applications. (Some servers might be like this.)Typically users of these applications are aware of the NSS databases and the locations of these databases.
These applications use the new shareable database engine. The first time the new application version runs, when NSS first creates the shareable databases, NSS will automatically detect instances of legacy old DBM databases and will upgrade those legacy databases to the new shareable ones without user interaction. This is similar the the traditional NSS database update found in previous versions of NSS.
Summary:
trust.
Mode 3: Applications that intend to share their keys and certs with other applications (the common case - browsers, mail clients, secure shells, vpns, etc.)and which the users typically have little or no awareness of what the NSS databases are and where they might be.
To achieve that sharing, these applications must share a single common set of databases. If older versions of these applications created legacy DBM databases, those legacy databases must be merged. To perform such a merge, NSS will need some extra support from the application, and possibly user intervention (in the form of password authentication) as well.
Summary:
Type B applications do no database upgrades, and do not need nssdbm3.
=====How Applications Use Upgrade=====
 
NOTE: While database Upgrade may involve a merge (mode 3), database upgrade is not merging. See the section on how to manage merging databases.
 
Mode 1 Applications can continue to call the traditional NSS_Initialize() function without changes. Mode 1 applications which need to guarantee that they open only old DBM databases should prepend the string "dbm:" to the directory path passed to NSS in the configdir parameter of NSS_Initialize().
 
Mode 2 Applications can also continue to call traditional NSS_Initialize() functions. The should, however, prepend the string "sql:" to the directory path passed to NSS in the configdir parameter. If the sql databases do not exist, NSS will automatically update any old DBM databases in the config directory to shared databases. Like the upgrade from cert7 to cert8, if the update does not work, the app will open and use the old DBM database. Upgrade will not happen if
1) NSS is opened readOnly.
2) NSS_Initialization fails.
3) The database is password protected and the user never logs into the token during the lifetime of the application.
 
Applications can avoid case 3 by forcing the user to authenticate to softoken using PK11_Authenticate().
 
Mode 3 Applications are the most complicated. NSS provides some services to help applications get through and update and merge with the least interaction with the user of the application.
 
First, Mode three applications need to call NSS_InitWithMerge(). This call includes extra parameters needed by NSS to help automatically determine if an update/merge is necessary, and how to accomplish it.
=====Upgrade complications=====
439
edits

Navigation menu