6.3 Performing a Dry Run before Upgrading eDirectory

ndsupg can be used to perform a dry run before upgrading the packages. This utility alone can be used against a copied database on all the supported platforms. The advantage is that eDirectory services will still be available when the dry run is being performed.

Here, the -d option can be used where the upgrade utility itself takes a copy of the DIB and performs the upgrade on the copy. ds.nlm should be unloaded while copying the database to ensure the integrity of the database. Upgrade will require twice the size of the database since a copy needs to be taken.

6.3.1 Common Problems Encountered during the Upgrade Process

The following FAQ section discusses the common problems faced while upgrading from the previous versions of eDirectory to eDirectory 8.8.

Question: I am upgrading from eDirectory 8.7.x to eDirectory 8.8. The upgrade process failed with an error. My eDirectory 8.7.x server no longer comes up.

Answer: While upgrading from 8.7.x to eDirectory 8.8, the database goes through a two phase upgrade. In the first phase, a key pair is created for encrypted attributes support which was introduced in eDirectory 8.8. In the second phase, DIB upgrade happens for reference changes. Incase the second phase fails after the first phase, the existing binaries (eDirectory 8.7.x) will not be able to open the database as database is already upgraded to 8.8 level and the database version is changed to reflect that. We recommend taking a backup of the database before proceeding with upgrading to eDirectory 8.8. Please refer to Section 8.2, Migrating to eDirectory 8.8 SP8 Without Upgrading the Operating System for further details.

Question: The upgrade process seems to be taking a lot of time.

Answer: The upgrade scans the entire database and checks for reference attributes on all the objects. This process might take a while depending on the number of the objects in the database. It may take hours for a database with 5 million objects with reference attributes on all the objects.

Question: The upgrade process seems to be taking a lot of space in the storage.

Answer: Since the entire reference upgrade has to be done in a single transaction and transaction rollback is required in case the upgrade fails, FLAIM keeps the changed blocks in its nds.db file. As a result of this, you might observe the nds.db growing during the upgrade process. This is quite normal. The file might spill over to nds.00v, nds.002, etc. The upgrade process will require as much as 100% of existing disk space depending on the number of objects to be upgraded. For e.g, a DIB size of 15Gig might require another 15Gig free space, if all objects in the DIB has reference attributes.

Question: The eDirectory database upgrade proceeds even if I provide a wrong password and admin user.

Answer: eDirectory package upgrade and database upgrade happens based on your file system rights. The eDirectory administrator password will not be used for this. It has a side effect that the login might fail once the upgrade begins. The next attempt to use the ndsconfig upgrade command will always go through.

Question: I provided a wrong password for administrator. My upgrade failed, and I started the upgrade again with the correct password. The upgrade is again taking long time (as long as 1 hour for a 5 million objects with reference attributes on all) to bring up the initial display.

Answer: eDirectory maintains the reference attributes in a separate container in the database. The delay in the initial display is due to the time it takes FLAIM to delete the database container that holds the “Reference” attribute records.