Enabling features

[girish]

https://git.cloudron.io/packages/keycloak-app/-/merge_requests/9

[andreasdueren]

My understand is, that this was added to the package but enabling it still won't work:

root@bdb4c70c-3a98-4263-b7b4-06816ea7d6c3:/app/code/bin# ./kc.sh build --features="passkeys"
WARNING: The following run time options were found, but will be ignored during build time: kc.cache, kc.db-url, kc.db-username, kc.db-password, kc.hostname, kc.hostname-strict, kc.http-enabled, kc.http-host, kc.http-port, kc.proxy-headers, kc.proxy-trusted-addresses

Updating the configuration and installing your custom providers, if any. Please wait.
2025-02-13 13:16:07,396 INFO  [org.key.com.Profile] (main) Preview features enabled: passkeys:v1
2025-02-13 13:16:08,305 INFO  [org.key.com.Profile] (main) Preview features enabled: passkeys:v1
2025-02-13 13:16:08,680 WARN  [io.qua.config] (build-21) Unrecognized configuration key "quarkus.smallrye-health.extensions.enabled" was provided; it will be ignored; verify that the dependency extension for this configuration is set or that you did not make a typo
2025-02-13 13:16:09,481 INFO  [io.qua.hib.orm.dep.HibernateOrmProcessor] (build-19) Persistence unit 'keycloak-default': Enforcing Quarkus defaults for dialect 'org.hibernate.dialect.H2Dialect' by automatically setting 'jakarta.persistence.database-product-version=2.3.230'.
2025-02-13 13:16:09,483 INFO  [io.qua.hib.orm.dep.HibernateOrmProcessor] (build-19) A legacy persistence.xml file is present in the classpath. This file will be used to configure JPA/Hibernate ORM persistence units, and any configuration of the Hibernate ORM extension will be ignored. To ignore persistence.xml files instead, set the configuration property 'quarkus.hibernate-orm.persistence-xml.ignore' to 'true'.
ERROR: Failed to run 'build' command.
ERROR: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
        [error]: Build step io.quarkus.deployment.pkg.steps.JarResultBuildStep#buildRunnerJar threw an exception: java.nio.file.ReadOnlyFileSystemException
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.checkWritable(ZipFileSystem.java:370)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.createDirectory(ZipFileSystem.java:708)
        at jdk.zipfs/jdk.nio.zipfs.ZipPath.createDirectory(ZipPath.java:742)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.createDirectory(ZipFileSystemProvider.java:186)
        at java.base/java.nio.file.Files.createDirectory(Files.java:700)
        at java.base/java.nio.file.Files.createAndCheckIsDirectory(Files.java:808)
        at java.base/java.nio.file.Files.createDirectories(Files.java:753)
        at io.quarkus.deployment.pkg.steps.JarResultBuildStep.buildThinJar(JarResultBuildStep.java:664)
        at io.quarkus.deployment.pkg.steps.JarResultBuildStep.buildRunnerJar(JarResultBuildStep.java:228)
        at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:733)
        at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:856)
        at io.quarkus.builder.BuildContext.run(BuildContext.java:256)
        at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
        at org.jboss.threads.EnhancedQueueExecutor$Task.doRunWith(EnhancedQueueExecutor.java:2516)
        at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2495)
        at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1521)
        at java.base/java.lang.Thread.run(Thread.java:1583)
        at org.jboss.threads.JBossThread.run(JBossThread.java:483)

ERROR: Build failure: Build failed due to errors
        [error]: Build step io.quarkus.deployment.pkg.steps.JarResultBuildStep#buildRunnerJar threw an exception: java.nio.file.ReadOnlyFileSystemException
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.checkWritable(ZipFileSystem.java:370)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.createDirectory(ZipFileSystem.java:708)
        at jdk.zipfs/jdk.nio.zipfs.ZipPath.createDirectory(ZipPath.java:742)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.createDirectory(ZipFileSystemProvider.java:186)
        at java.base/java.nio.file.Files.createDirectory(Files.java:700)
        at java.base/java.nio.file.Files.createAndCheckIsDirectory(Files.java:808)
        at java.base/java.nio.file.Files.createDirectories(Files.java:753)
        at io.quarkus.deployment.pkg.steps.JarResultBuildStep.buildThinJar(JarResultBuildStep.java:664)
        at io.quarkus.deployment.pkg.steps.JarResultBuildStep.buildRunnerJar(JarResultBuildStep.java:228)
        at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:733)
        at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:856)
        at io.quarkus.builder.BuildContext.run(BuildContext.java:256)
        at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
        at org.jboss.threads.EnhancedQueueExecutor$Task.doRunWith(EnhancedQueueExecutor.java:2516)
        at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2495)
        at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1521)
        at java.base/java.lang.Thread.run(Thread.java:1583)
        at org.jboss.threads.JBossThread.run(JBossThread.java:483)

For more details run the same command passing the '--verbose' option. Also you can use '--help' to see the details about the usage of the particular command.

[girish]

@andreasdueren the package builds the final jar with the features enabled, why does one have to build it again?

[andreasdueren]

@girish I thought that was necessary because it didn't seem like the feature was installed on my instance. I'll investigate...

[msbt]

Quick update on this: A customer of mine refined the package and supplied the code to dynamically enable/disable features and also rebuild the executable on restart. Corresponding MR is here.

Until now custom providers were not usable because adding them required a rebuild of the app (which wasn't working due to readonly fs), with this patch this should work.

cc @girish @nebulon

[girish]

@msbt thanks, will take a look!

[msbt]

@girish a quick test would be setting --metrics-enabled=false to true, you'll see a message that the server is listening on another port

[girish]

@msbt mm, so while that MR works, it goes against our philosophy of code being readonly at runtime. Wondering if there are any strong reasons to do this. After all, we can just enable the necessary features in the package. Things like --db etc should not be changed by users (the manifest addons are static)

[msbt]

@girish the problem is that if you add a new provider, the executable needs a rebuild, else it won't recognize it (as far as I understand it)

[msbt]

@girish https://www.keycloak.org/server/configuration-provider#_installing_and_uninstalling_a_provider

[girish]

@msbt ah ok, this is for providers and not this features thing. So, in your case, there is a custom provider jar file and we have to rebuild keycloak with that?

[girish]

mm, I see. Even setting some provider configuration requires a rebuild.. crazy

[gpichler]

Yes it's mainly about providers. Changing features is an additional option. I do not think it would be wise to include all possible providers and features upstream whenever a user requests them.

[shrey]

@girish is there any workaround/solution planned for this (capability to add/modify features)?

Example, i'm trying to add SMS Auth and Webhook Events capabilities, by first adding the .jar files to the providers folder > add/edit the corresponding conf/env variables in keycloak.conf > trigger the build operation. But it simply restarts the container, while removing all of my changes to the .conf file.

[gpichler]

@shrey You could try my patch in the MR https://git.cloudron.io/packages/keycloak-app/-/merge_requests/12 :
Add the .jar in the providers/, add additional commandline flags in env.sh and then simply restart the container.

[girish]

@gpichler @shrey we will try to get the MR merged soonish . Just have to double check if there is any other workaround we can use because we really dislike code being writable!

[gpichler]

@girish Out of curiosity: What is your rational for not liking code being writable? Is it a security consideration?

[nebulon]

Security is one but equally important is it for updating apps. If code files are changed we can't test and validate updates and each update will overwrite any local changes anyways.

[gpichler]

I see. In the case of this MR, the executable (the .jar file) is rebuilt on every app startup. Thus, this would not be overwritten by an update. The relevant commandline parameters are persistent in env.sh when updating.

I think there are two failure modes after an update: 1) obsolete commandline parameters in env.sh or 2) .jar files in providers/, which were compatible with the previous version but incompatible with the new version. If you want to allow users to select custom features and install custom providers. I think both these options are essentially unavoidable.

Let me know if there is something I can improve. I am looking forward to getting this merged.

[girish]

@gpichler @msbt I have merged it now and published it