Does anyone have an idea on how I can do this (what the top comments suggests): Keycloak logging to logstash
But for the newest keycloak version 17+ which uses Quarkus instead of Wildfly?
Edit 1:
After I have successfully added logstash feature to my keycloak+quarkus build, and logging-gelf shows under installed features
I can still not see logs on kibana, as if the logs are not being sent but the feature is installed.
Am I correct in thinking that this configuration is a correct "replacement" for the the Wildfly cli from the link:
quarkus.log.handler.gelf.enabled=true
quarkus.log.handler.gelf.json=true
quarkus.log.handler.gelf.json.key-overrides={timestamp="#timestamp"}
quarkus.log.handler.gelf.json.exception-output-type=formatted
quarkus.log.handler.gelf.json.additional-field."appname".value=${env.LOGSTASH_APPNAME:myApplicationName}
quarkus.log.handler.gelf.json.additional-field."#version".value=1
quarkus.log.handler.gelf.host=tcp:${env.LOGSTASH_DESTINATION:someDefaultDestination}
quarkus.log.handler.gelf.port=${env.LOGSTASH_PORT:5044}
#Default vale is tcp
#quarkus.log.handler.gelf.protocol=tcp
quarkus.log.handler.gelf.block-on-reconnect=true
quarkus.log.handler.gelf.async=true
#Default value is ALL
#quarkus.log.handler.gelf.level=ALL
quarkus.log.handler.gelf.async.queue-length=${env-LOGSTASH_QUEUE:1000}
#Default value is block
#quarkus.log.handler.gelf.async.overflow=block
Or is there some configurations that I just have "made up"?
First of all: at the moment keycloak has no native support for gelf/logstash directly. That said, it is possible to do for sure using the quarkus logging gelf extension. In order for this to work, it is a bit complicated, but in general You have to:
download the jars for the quarkiverse-logging-gelf - both, the "deployment" and the runtime jar, for the quarkus version your keycloak version uses (2.7.0? Not sure, iirc I updated to 2.7.5 in 17.0.1). Also you need to download the transient dependency of this quarkus extension, namely the logstash-gelf jar in the right version. Put these jars inside the "providers" directory of your kc.
create a quarkus.properties file in the conf directory and add your desired configuration. There is a centralized log management guide on the quarkus homepage.
run a "build"
start Keycloak. Your log should now show
[io.quarkus] (main) Installed features: [..., logging-gelf, ...]
And it should work to get your logs out the way you want it.
These steps are also described with examples e.g. here.
Note: I am in the Keycloak team. There is no out of the box support right now directly, bc. we are thinking about leveraging quarkus' extension approach better (so you do not have to download the jars and transient dependencies manually), but I guess for this specific case we will do something the future :)
edit: open pr for support using keycloak config: -> https://github.com/keycloak/keycloak/pull/12843
edit 2: pr merged, firstclass support should be available from the next major version (19 i guess)
Related
I've followed the doc here : https://logging.apache.org/log4j/2.x/manual/migration.html
Also looked at https://logging.apache.org/log4j/2.x/manual/configuration.html#Properties
My existing log4j.properties only uses DailyRollingFileAppender, ConsoleAppender, both of which are under the 'Supported Components', so I shouldn't be forced to convert my log4j.properties file into log4j2.properties format. I'm not accessing methods and classes internal to the Log4j 1.x implementation, as suggested by the document.
For using the bridge, I previously was using both log4j1.compatibility and log4j.configuration, but the document suggests using 'any one' (tried using just one, doesn't work)
I can build my application successfully, however, my application no longer logs anything. What am I missing?
You may want to consider reload4j as a drop-in replacement for log4j 1.x. Initiated by Ceki Gülcü, the original author of Apache log4j 1.x, the reload4j project is a fork of Apache log4j version 1.2.17 with the goal of fixing pressing security issues.
The reload4j project offers a clear and easy migration path for the users who have an urgent need to fix vulnerabilities in log4j 1.2.17.
You don't need to update your properties file.
You can add a log4j2.component.properties file on the class path (in my case, in the same directory as my log4j.properties file) to set the log4j1.compatibility property, like this:
log4j1.compatibility=true
In our case, it only required setting the compatibility property and then it automatically picked up the log4j.properties file that was available on the class path.
Figured it out.
The answer lied in the Automatic Configuration section
I moved to Bolt 4 (from Bolt 3.7) and would like to implement front-end user to give them access to private contents of the website. Previously, I used the extension BoltAuth/Auth, which worked like a charm.
Now in Bolt 4, there is no easy way like in Bolt 3.x to install an extension from the back-end page. I found out I could use composer to do so, but I run in the following problem:
> composer require "boltauth/auth:3.0.1"
[InvalidArgumentException]
Could not find a matching version of package boltauth/auth. Check the package
spelling, your version constraint and that the package is available in a stability
which matches your minimum-stability (stable).
Either I do something wrong, or the extension is not compatible with Bolt 4.1.
Could someone tell me if there is a way to make this extension work? Or alternatives for front-end user management?
EDIT: I'm now using the bolt/users extension as it can be used to add a ROLE_MEMBERS and let users login for the frontend.
Yes, unfortunately the architecture for plugins (mainly driven by the move from Silex to Symfony) changed completely between 3.x and 4.x and it's not really feasible to release new 4.x compatible versions.
So for now there won't likely be updates to BoltAuth. It may be worth joining the Slack community and seeing if any other developers are working on 4.x compatible solutions to the client login scenarios.
We have spark configuration that uses spark.jars.ivySettings to customize jars resolution.
Spark jobs run in environment without internet access, so we want to skip maven central calls and use our repositories.
In spark 2.2.1 everything was working fine, but when we upgraded to 2.3, repositories specified in ivy settings are ignored. As the result our jobs are failing due to missing dependencies.
Specifying our repos with new spark.jars.repositories makes it visible for spark, but does not change an order (so it will always first check maven central, which we cannot allow).
Is this some bug introduced in new version? Or I'm doing something wrong here?
Ok, I found where is the problem. So apparently the way of acquiring spark.jars.ivySettings has changed in 2.3. Now system properties are used for that:
sys.props.get("spark.jars.ivySettings")
This change is not followed by documentation update, and for me it seems like a bug.
I am trying to use Primefaces 5.3 with a maven build on Bluemix, using the redmond theme from the 1.0.8 primefaces extensions. However, it seems I have run into a dependency issue.
1) When I leave out the all-themes artifact from the org.primefaces.extensions group, I get an exception that the themes.css could not be found.
2) When I edit in the all-themes artifact and stay with the maven repository only, I get a dependency error, as there seems to be a dependency to an artifact that is only on primefaces.org but not on maven.org, namely at least the afterdark pom.xml seems to refer to primefaces.org
3) When I edit in the primefaces.org repository, I get a build error on Bluemix, because Bluemix does not seem to trust the SSL certificate from primefaces.org:
[ERROR] ...Could not transfer artifact org.primefaces.themes:afterdark:pom:1.0.8 from/to prime-repo (https://repository.primefaces.org/): com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
[ERROR] java.security.cert.CertPathValidatorException: The certificate issued by CN=DST Root CA X3, O=Digital Signature Trust Co. is not trusted; internal cause is:
[ERROR] java.security.cert.CertPathValidatorException: Certificate chaining error
This happens with both http or https used as repository address, so probably the afterdark pom includes the https address anyway....
So maven.org is pointing to some untrusted repository for a dependency, and Bluemix does not accept it.
So what should be the fix (and no, don't suggest not using primefaces):
- Is this fixed with any newer version of primefaces? Not sure if I will be able to spend the effort for the upgrade though
- can this be fixed in the 1.x versions of primefaces extensions?
- I guess I won't be able to change Bluemix to accept the certificate...
- is there a way to only use the redmond theme as dependency and not all-themes?
Is there anything I am missing?
Note that locally there is no problem, as maven seems to happily download code from untrusted sources.
It looks like the certificate is not available in the jvm trust store and you will need to add it to resolve the problem.
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.