Jean-Baptiste Onofré's Blog

Karaf leverages Pax Logging for the logging layer. Pax Logging provides an abstraction service for most popular logging frameworks, like SLF4J, Log4j, commons-logging, etc.

Karaf provides a default logging configuration in etc/org.ops4j.pax.logging.cfg file.

By default, all INFO log messages (rootLogger) are send into a file appender (in data/log/karaf.log). The file appender “maintains” one file of 1MB, and store up to 10 backup files.

Adding a new appender configuration, example with Syslog appender

We can add new appender configuration in the Karaf logging module.

For instance, we can add a syslog appender in etc/org.ops4j.pax.logging.cfg:


log4j.rootLogger = INFO, out, syslog, osgi:*
...
# Syslog appender
log4j.appender.syslog=org.apache.log4j.net.SyslogAppender
log4j.appender.syslog.layout=org.apache.log4j.PatternLayout
log4j.appender.syslog.layout.ConversionPattern=[%p] %c:%L - %m%n
log4j.appender.syslog.syslogHost=localhost
log4J.appender.syslog.facility=KARAF
log4j.appender.syslog.facilityPrinting=false
...


We create the syslog appender configuration, and we use this appender for the rootLogger.

Pax Logging provides all default Log4j appenders.

Creating a custom appender

It’s also possible to create your own appender.

For instance, you want to create MyJDBCAppender, extending the standard Log4J JDBCAppender. MyJDBCAppender has a better management of the quote in the SQL query for a DB2 backend for instance:


package org.apache.karaf.blog.logging.appender;

}


We put the MyJDBCAppender java file in a src/main/java/org/apache/karaf/blog/logging folder.

We package this appender as an OSGi bundle. This bundle is a fragment to the Pax Logging service bundle:


<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

</project>


We can use our appender in etc/org.ops4j.pax.logging.cfg file, for instance:


log4j.rootLogger = INFO, out, myappender, osgi:*
...
log4j.appender.myappender=org.apache.karaf.blog.logging.appender.MyJDBCAppender
log4j.appender.myappender.url=jdbc:db2:....
log4j.appender.myappender.driver=com.ibm.db2.jcc.DB2Driver
log4j.appender.myappender.user=username
log4j.appender.myappender.password=password
log4j.appender.myappender.sql=insert into logs values({{sql_apos}%x{sql_apos}, {sql_apos}%d{sql_apos}, {sql_apos}%C{sql_apos}, {sql_apos}%p{sql_apos}, {sql_apos}%m{sql_apos})
log4j.appender.myappender.layout=org.apache.log4j.PatternLayout


In order to be loading very early in the Karaf bootstrap, our appender bundle should be present in the system folder and defined in etc/startup.properties.

The system folder has a “Maven repo like” structure. So you have to copy with:


system/groupId/artifactId/version/artifactId-version.jar


In our example, it means:


mkdir -p $KARAF_HOME/system/org/apache/karaf/blog/logging/appender
cp target/org.apache.karaf.blog.logging.appender.jdbc-1.0-SNAPSHOT.jar $KARAF_HOME/system/org/apache/karaf/blog/logging/appender/org.apache.karaf.blog.logging.appender.jdbc/1.0-SNAPSHOT/org.apache.karaf.blog.logging.appender.jdbc-1.0-SNAPSHOT.jar


and in etc/startup.properties, we define the appender bundle just after the pax-logging-service bundle:


...
org/ops4j/pax/logging/pax-logging-api/1.6.9/pax-logging-api-1.6.9.jar=8
org/ops4j/pax/logging/pax-logging-service/1.6.9/pax-logging-service-1.6.9.jar=8
org/apache/karaf/blog/logging/appender/org.apache.karaf.blog.logging.appender.jdbc/1.0-SNAPSHOT/org.apache.karaf.blog.logging.appender.jdbc-1.0-SNAPSHOT.jar=8
...


You can now start Karaf, it will use our new custom appender.

I received many times messages from users asking how we can “trust” HTTP clients in Karaf.

The purpose is to exchange certificates and allow only “trusted” clients to use the Karaf HTTP service.

Enable HTTP client auth

First of all, we have to enable the HTTP client auth support in Karaf.

When you install the HTTP feature, Karaf leverages Pax-Web to provide HTTP OSGi service:


karaf@root> features:install http


Now, we have to add a custom etc/org.ops4j.pax.web.cfg file:


org.osgi.service.http.port=8181

org.osgi.service.http.port.secure=8443
org.osgi.service.http.secure.enabled=true
org.ops4j.pax.web.ssl.keystore=./etc/keystores/keystore.jks
org.ops4j.pax.web.ssl.password=password
org.ops4j.pax.web.ssl.keypassword=password
#org.ops4j.pax.web.ssl.clientauthwanted=false
org.ops4j.pax.web.ssl.clientauthneeded=true


NB: clientauthwanted and clientauthneeded properties are valid for Karaf 2.2.x which use Pax Web 1.0.x.

Thanks to the clientauthneeded property, we “force” the client to be trusted.

Create the trusted client certificate

We are going to use keytool (provided with the JDK) to manipulate the keys and certificates.

The first step is to create two key pairs:

• one for the server side (use for SSL)
• one as a example of client side (use for “trust”, should be performed for each client, on the client side)


mkdir -p etc/keystores
cd etc/keystores
keytool -genkey -keyalg RSA -validity 365 -alias serverkey -keypass password -storepass password -keystore keystore.jks
keytool -genkey -keyalg RSA -validity 365 -alias clientkey -keypass password -storepass password -keystore client.jks


NB: these key are self-signed. In a production system, you should use a Certificate Authority (CA).

Now, we can export the client certificate to be imported in the server keystore:


keytool -export -rfc -keystore clientKeystore.jks -storepass password -alias clientkey -file client.cer
keytool -import -trustcacerts -keystore keystore.jdk -storepass password -alias clientkey -file client.cer


We can now check that the client certificate is trusted in our keystore:


keytool -list -v -keystore keystore.jks
...
Alias name: clientkey
Creation date: Dec 12, 2012
Entry type: trustedCertEntry
...


and we can now remove the client.cer certificate.

Start Karaf and test with WebConsole

Now we can start Karaf:


bin/karaf


and install the WebConsole feature:


karaf@root> features:install webconsole


If we try to access to the WebConsole (using a simple browser) using https://localhost:8443/system/console, we have:


An error occurred during a connection to localhost:8443.

(Error code: ssl_error_bad_cert_alert)


which is normal as the browser doesn’t have any trusted certificate.

Now, we can add the client certificate in the browser.

Firefox supports the import of PKCS12 keystore. So, we are going to “transform” the JKS keystore into a PKCS12 keystore:


keytool -importkeystore -srckeystore clientKeystore.jks -srcstoretype JKS -destkeystore client.pfx -deststoretype PKCS12
Enter destination keystore password:
Re-enter new password:
Enter source keystore password:
Entry for alias clientkey successfully imported.
Import command completed: 1 entries successfully imported, 0 entries failed or cancelled


Now, we can import the client certificate in Firefox. To do so, open the Preferences window (in Edit menu), and click on the Advanced tab.
You can go in Encryption tab and click on “View Certificates” button.

In “Your Certificates” tab, you can click on the Import button and choose the client.pfx keystore file.

If you try to access to https://localhost:8443/system/console again, you will have access as a trusted client and use it.

Conclusion

It’s the same with any kind of HTTP client that try to use the HTTPs layer of Karaf.

Now, we can disable the HTTP support in Karaf (to force the usage of HTTPs), and we can allow only “trusted” clients to use the HTTPs layer of Karaf.

It’s a simple mechanism if you want to limit access to HTTP resources only for trusted clients.