[RTFACT-16046] Fix numerous issues with the Access admin creds not persisted, and adminToken disappearing in certain cases Created: 06/Mar/18 Updated: 09/May/18 Resolved: 09/May/18
|Project:||Artifactory Binary Repository|
|Reporter:||Uriah Levy||Assignee:||Uriah Levy|
|Sprint:||Leap 29, Leap 30, Leap 31|
This deals with multiple issues:
1. On an HA upgrade scenario from < 5.6.0 to 5.7.0+, the master key converter starts running and re-encrypts all the encrypted configs in the configs table etc. At the same time, while Access is starting in the background, it creates a bootstrap.creds file so that Artifactory could bootstrap the access client creds at some point during the init phase. The problem is that if the master.key converter re-inserts the access.creds row to the db with a timestamp that is more recent than the last modified date of the bootstrap.creds file, for example due to time zone differences between the DB and Artifactory, it will result in the creds file being overwritten by the old one from the DB regardless to the bootstrap process taking place. This leads to the secondaries not being able to start because they will see the outdated access creds when they start up, failing with the following error:
2. The adminToken field may disappear when the system mistakenly deduces the artifactory service_id has changed.
After an upgrade scenario from a version < 5.6 to a version above 5.6, if for some reason the secondary node starts up before the primary node, it will wait up to 90 seconds for the primary node to convert/create the new access client admin credentials. If the wait time elapses and the primary has not inserted the new creds to the DB, the secondary node will throw an exception and the startup will fail with the following message:
|Comment by Uriah Levy [ 11/Mar/18 ]|
Upgrade path confirmed as affected is 5.5.1 -> 5.8.3. It's possible that other upgrade paths are not affected.