[
https://issues.apache.org/jira/browse/KNOX-2990?focusedWorklogId=902972&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-902972
]
ASF GitHub Bot logged work on KNOX-2990:
----------------------------------------
Author: ASF GitHub Bot
Created on: 01/Feb/24 08:04
Start Date: 01/Feb/24 08:04
Worklog Time Spent: 10m
Work Description: smolnar82 commented on code in PR #826:
URL: https://github.com/apache/knox/pull/826#discussion_r1473959716
##########
gateway-server/src/main/java/org/apache/knox/gateway/services/token/impl/JDBCTokenStateService.java:
##########
@@ -65,12 +76,33 @@ public void init(GatewayConfig config, Map<String, String>
options) throws Servi
} catch (Exception e) {
throw new ServiceLifecycleException("Error while initiating
JDBCTokenStateService: " + e, e);
}
+
+ this.skipTokenMigration = config.skipTokenMigration();
+ this.archiveMigratedTokens = config.archiveMigratedTokens();
+ this.migrateExpiredTokens = config.migrateExpiredTokens();
+ this.verboseTokenMigration =
config.printVerboseTokenMigrationMessages();
+ this.tokenMigrationProgressCount =
config.getTokenMigrationProgressCount();
} finally {
initLock.unlock();
}
}
}
+ @Override
+ public void start() throws ServiceLifecycleException {
+ super.start();
+ if (skipTokenMigration) {
+ log.skipTokenMigration();
+ } else {
+ final TokenMigrationTool tokenMigrationTool = new
TokenMigrationTool(aliasService, this, null);
Review Comment:
Yes, that was the final agreement with @lmccay on the
[[DISCUSS]](https://lists.apache.org/thread/fs9nkl6l45o330ttvgvqxj3jnxt63bcs)
thread about this change:
```
- the migration tool will be run automatically when the Knox Gateway starts,
and it will run on the main thread (i.e. not in the background).
- there will be a config to control this step: in case of an error/bug, this
automated migration could be turned off
```
In the 2.1.0 release, we will add proper documentation on best practices
about this change: the recommended way of upgrading to that version is to run
the new KnoxCLI code before the upgraded Knox Gateway starts. If admins do
that, this implicit step will finish in a matter of (milli)seconds during Knox
Gateway startup. However, if they failed to do that before, we agreed that it's
better to have tokens auto-migrated than leave them in the dark and guess why
token authentication isn't working. I believe the detailed entries in
`gateway.log` (see above in the description) make it crystal clear why the KG
startup takes such time for the first time.
Issue Time Tracking
-------------------
Worklog Id: (was: 902972)
Time Spent: 2.5h (was: 2h 20m)
> TokenStateService implementation cleanup
> ----------------------------------------
>
> Key: KNOX-2990
> URL: https://issues.apache.org/jira/browse/KNOX-2990
> Project: Apache Knox
> Issue Type: Task
> Components: Server
> Affects Versions: 2.0.0, 1.6.0, 1.6.1
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Critical
> Fix For: 2.1.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This issue is driven by a [DISCUSS] thread initiated on Knox's DEV mailing
> list [here|https://lists.apache.org/thread/fs9nkl6l45o330ttvgvqxj3jnxt63bcs].
> As a result of that discussion, the following needs to be implemented:
> * deprecate the following TSS implementations:
> ** AliasBasedTokenStateService
> ** ZookeeperTokenStateService
> ** JournalBasedTokenStateService
> * document the deprecation of these TSS implementations in v2.1.0 and
> highlight that they will be removed in the upcoming release (v2.2.0?).
> * implement a DerbyDB storage that will store tokens in
> {{$DATA_DIR/security/tokens}} (encrypted or not, it'll be decided later)
> * make sure appropriate file permissions are set on that folder
> * have the {{homepage}} topology configured with JDBC TSS pointing to this
> DerbyDB storage
> * implement a new KnoxCLI command that migrates existing tokens from
> credential stores to the DerbyDB storage
> * automate this new KnoxCLI command in a way such that it runs when Knox
> Gateway is started, token management is enabled, and DerbyDB storage is
> configured
> * ensure that the previous automated step can be controlled (E.g. in case of
> unforeseen errors it can be turned off)
> * document possible data replication scenarios when, in the case of HA
> deployments, existing tokens from one Knox node should be made available in
> other Knox node(s) and there is no other centralized RDBMS in use
> (PostgreSQL, MySQL for instance)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
