[RTFACT-14231] Artifactory should NOT regenerate Access files and communication.key when failing to extract an existing bootstrap bundle Created: 11/May/17  Updated: 06/Dec/18  Resolved: 06/Dec/18

Status: Resolved
Project: Artifactory Binary Repository
Component/s: None
Affects Version/s: 5.2.1, 5.3.2
Fix Version/s: 5.7.0

Type: Bug Priority: Critical
Reporter: Uriah Levy Assignee: Unassigned
Resolution: Fixed Votes: 3
Labels: None

Issue Links:
is duplicated by RTFACT-14303 When the db.properties exists, a wron... Resolved
is duplicated by RTFACT-14302 Display verbose activities of the boo... Resolved


If one of the following conditions apply, Artifactory will ignore the bootstrap.bundle.tar.gz during startup:

1.$ARTIFACTORY_HOME/access OR $ARTIFACTORY_HOME/etc/security/access dirs exist at the time of the startup
2.The $ARTIFACTORY_HOME/etc/db.properties file exists at the time of the startup
3.The $ARTIFACTORY_HOME/etc/ha-node.properties file was missing during the first startup, which means Artifactory will not boot in HA mode, leading to it ignoring the bootstrap bundle.

This leads to an inconsistent state where Artifactory will generate the access dirs from scratch, creating the private key/fingerprint mismatch scenario.

This situation should not happen. If the bootstrap.bundle.tar.gz is placed in the $ARTIFACTORY_HOME/etc dir deliberately, it should not be considered legitimate to create new access dirs and communication.key which is mismatching the one in bootstrap bundle. It's better to fail startup with an informative error, so the Artifactory administator will be able to correct whatever caused the bootstrap bundle to be ignored.

Comment by Andrei Komarov [ 06/Dec/18 ]

Resolved as part of bootstrap bundle removal and HA build refactoring

Generated at Wed Aug 21 00:29:18 UTC 2019 using JIRA 7.6.3#76005-sha1:8a4e38d34af948780dbf52044e7aafb13a7cae58.