Artifactory 7.77 introduces the next generation permission model and your existing permissions are migrated.
The new model is fully backward compatible with the legacy permissions model.
You might encounter the following known issues during migration.
Cannot Modify Permission
Migration locks the old tables so that no new data is inserted into them.
If an old node tries to perform a change to the old permissions table (via UI/API) during migration, the following error occurs: will get the following error: JFrog migration is running in the background, cannot modify permissions, please wait for the migration to finish
Solution
Wait until migration for all nodes is complete.
The error will not be thrown after the migration is complete.
Long Migration Time for Large Customers
A large customer is a customer that has more than 100K permissions.
Migration might take a few minutes for large customers. During migration the JFrog Access service will not communicate with the other internal JFrog services.
Currently, all internal JFrog services are waiting for 5 minutes for JFrog Access to start. In case JFrog Access service does not respond during this time, they shutdown.
Solution
Configure the services to wait for 10 minutes to allow JFrog Access service the time it needs to migrate.
If you are a large customer and not yet started the migration, set the following values in system.yaml.
shared:
security:
bootstrapKeysReadTimeoutSecs: 600
frontend:
startup:
ping:
retries: 600
accessClient:
join:
retries: 600
observability:
accessClient:
joinTimeoutMins: 10
pingTimeoutMins: 10
metadata:
accessClient:
joinTimeout: 10m
jfconnect:
accessClient:
joinTimeoutMins: 10
pingTimeoutMins: 10
event:
accessClient:
joinTimeout: 10m
pingTimeout: 10mIf you are a large customer and your migration failed since it took a long time, wait until the migration is complete and restart the entire system.
Migration Lock Database Tables Failure
For the migration to work properly, and to avoid data loss, the first step is locking the legacy permissions tables.
The lock is done by creating a trigger that throws an error when a customer tries to manipulate the old permissions tables.
Creating these triggers requires the database user to have special grants. For example, in MySQL/MariaDB, the user has to have SUPER user grants.
If the user doesn't have the proper permissions to create these triggers, the migration will fail.
The migration name is: V7_82_0_1__PermissionsV2DataMigration
Solution
Remove the failing migration from the database with the following command.
DELETE from access_schema_version where version='7.82.0.1'
This allows the migration to run again on the next restart.
Warning
Do not restart at this point!
Choose one of the following solutions.
Elevate the DB user permissions so it can create TRIGGERs.
If you’re using MySQL or MariaDB, set the flag,
SET GLOBAL log_bin_trust_function_creators = 1;, which allows the creation of TRIGGERs and FUNCTIONs.You can remove the flag after the migration is complete.
Starting Artifactory 7.77.5, you can manually review and apply the TRIGGERs to your database and skip their automatic creation during the migration.
To skip the triggers creation, set either one of the following properties.
Java System Property:
jf.access.skip_pv2_legacy_tables_lock=trueEnvironment Variable:
JF_ACCESS_SKIP_PV2_LEGACY_TABLES_LOCK=true
Warning
Do not restart the migration and skip the TRIGGERs creation before manually setting the TRIGGERs!
It can cause a data loss of permissions in the system (if you add/remove/edit permissions while some nodes in your JPD were not upgraded, you will lose these changes).
You are ready to run the migration again.
Upgrade your nodes to the new version, the migration will succeed.
Issue ID | Description | Fix Version | Additional Information |
|---|---|---|---|
INST-7510 | As a result of changing the Nginx Internal Ports to 8080/8443, the value of | 7.77.6 | This issue impacts only Helm Installations with |