[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

Status: Resolved
Project: Artifactory Binary Repository
Component/s: Access Client
Affects Version/s: None
Fix Version/s: 6.0.0

Type: Bug Priority: High
Reporter: Uriah Levy Assignee: Uriah Levy
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by RTFACT-16045 Access won't swap old admin creds wit... Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
RTFACT-16045 Access won't swap old admin creds wit... Sub-task Resolved Uriah Levy  
Assigned QA: Liza Dashevski (Inactive)
Sprint: Leap 29, Leap 30, Leap 31

 Description   

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:

 Failed to generate service admin token using bootstrap credentials. 

2. The adminToken field may disappear when the system mistakenly deduces the artifactory service_id has changed.

New behaviour:

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:

Timed out waiting on Access admin credentials to exist. Access cannot start on a secondary node without the new client admin credentials. Starting the primary node first, and restarting this node should allow this node to start up successfully. 


 Comments   
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.

Generated at Sun Oct 20 12:19:28 UTC 2019 using JIRA 7.6.16#76018-sha1:9ed376192612a49536ac834c64177a0fed6290f5.