Reset Search
 

 

Article

10843 - Upgrade of Services Director VA from 2.1 - 2.2 to 2.3R1 or later degrade service & erase instance passwords

« Go Back

Information

 
Last Modified Date12/8/2017 8:00 AM
Synopsis
This article describes an issue where upgrading Service Director from 2.1 - 2.2 to 2.3R1 and later when using an external database may cause erase instance passwords and degrade service.
Problem or Goal
After upgrade, the Services Director service will be reported in the Services Director GUI as being degraded (amber warning triangle in the header bar). Any attempt to restart the service will produce the following message:
[mgmtd.INFO]: Services Director is not running due to unavailability of master 
password. Please ensure that the correct master password has been entered
Cause
For the affected releases, part of the upgrade process concerned with upgrading master passwords runs during a period where the Services Director has no network connectivity, and so performs the upgrade on the internal Services Director database (which will be empty for customers using an external database). Once network connectivity is restored and the Services Director service attempts to start, it detects that the database migration has not been applied and reapplies it, but without using a master password. This results in a) erasure of instance admin and service account passwords, and b) a failure to start the Services Director service.
Solution
When upgrading a Services Director VA configured to use an external database to a release supporting password encryption (2.3r1 onwards) from an earlier release, password encryption migration is applied incorrectly and results in loss of passwords for registered instances.
  • If the upgrade has not been attempted yet, then follow scenario 1.
  • If the upgrade has been attempted, and there is a record of the passwords, then follow scenario 2, otherwise follow scenario 3.

Scenario 1: Switch to use of Services Director internal database

NB. This approach must be used BEFORE upgrading.

For users who are willing to transfer the content of the external database to the Services Director's internal database before upgrading and use Services Director's inbuilt HA feature and disaster recovery feature after upgrading, use the following method.
  • Capture a mysqldump of the remote database, and append a Services Director version signature to the dumped file.
    • Example (for version 2.1.r1):
mysqldump -u root -p my_password my_dbname && echo "-- SSC Version:2.1.0-r1") > workaround.sql
  • Note: The string being echoed depends on the version of Services Director you are running:
    • For version 2.2: "-- SSC Version:2.2.0-mainline"
    • For version 2.2r1: "-- SSC Version:2.2.0-r1-mainline"
    • For version 2.2r2: "-- SSC Version:2.2.0-r2"
  • Run the CLI command on your Services Director to use local database:
ssc database use-local
  • Import the database dump from step 1 to Services Directors internal database. Example:
ssc database local db-file import scp://myusername:mypassword@myhost.example.com/root/workaround.sql
  • Once this is done, the usual upgrade commands ("image fetch <http://path/file.img>", "image upgrade image.img", "reload") may be used to perform the upgrade.

Scenario 2: Affected customers with recorded passwords for registered instances

Customers affected by this problem who have upgraded without switching to using the internal database but have a record of their instance passwords should follow this procedure. The passwords may be found in any existing database backup (including in any previous sysdumps that included the database).
  • Following the upgrade, use the CLI command:
ssc settings master-password reset password <something> force true

to give the SD a valid master password. This will allow the Services Director services to be restarted and to access the database, re-enabling FLA licensing.
  • Re-enter the admin password for each vTM
  • Relicense each vTM instance (using the FLA Licenses > Relicense button)

Scenario 3: Affected customers without recorded passwords for registered instances

Customers affected by this problem who have upgraded without applying the recommended workaround and have no record of their instance passwords should follow this procedure:
  • Following the upgrade, use the CLI command:
ssc settings master-password reset password <something> force true

to give the SD a valid master password. This will allow the Services Director services to be restarted and to access the database, re-enabling FLA licensing.
Related Links
Attachment 1 
Created ByVenkataKondaReddy Palem

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255