everflux

Drools (und JBoss Rules) funktioniert derzeit (Drools 5.2) nicht out-of-the-box mit Java 7 (OpenJDK bzw. Oracle Java 7). Der Grund ist, dass der von Drools verwendete Compiler lediglich Support bis Java 6 hat.

Eine einfache Loesung, die auch mit Java 7 funktioniert, ist die zu verwendende Java Version manuell zu konfigurieren, wenn man die KnowledgeBuilderFactory konfiguriert:

final Properties props = new Properties();
props.setProperty("drools.dialect.java.compiler.lnglevel", "1.6");
final KnowledgeBuilderConfiguration configuration = KnowledgeBuilderFactory.newKnowledgeBuilderConfiguration(props, getClass().getClassLoader());

Weitere Probleme mit Java 7 und JBoss Drools sind mir bisher nicht aufgefallen.

Änderungen an LaTeX Dokumenten lassen sich sehr komfortabel ansehen, wenn die Dokumente in einem Versionskontrollsystem wie Subversion verwaltet werden.

Subversion hat dazu das „diff“ Kommando, jedoch gibt dies lediglich Änderungen auf der Kommandozeile aus. Schöner wäre ja eine grafische Übersicht. Dazu kann man Subversion per „–diff-cmd“ auch ein Programm angeben, dass die Ausgabe aufbereiten bzw. anzeigen soll. Leider funktioniert das mit meinem lieblings-Diff-Viewer, „meld“ nicht wie erwartet.

Meld selber kann jedoch direkt aufgerufen werden und kuemmert sich dann darum, ein Diff zu erstellen und dies auch anzuzeigen. Dazu gibt man lediglich im Working-Directory

meld .

ein. Der Punkt ist wichtig, damit wird ab dem aktuellen Verzeichnis nach Änderungen gesucht. Nun sieht man die Dateien, die geändert sind, und kann diese in meld anklicken. Ubuntu und Debian User können meld bei Bedarf per sudo apt-get install meld installieren, sollte dies noch nicht geschehen sein.

Lange gesucht, doch gefunden:

ERROR: Aborted Maven execution for InterruptedIOException
java.net.SocketTimeoutException: Accept timed out


Jenkins (bzw. Hudson) bricht dann mit dieser Fehlermeldung den Build Prozess ab:

java.net.SocketTimeoutException: Accept timed out
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
	at java.net.ServerSocket.implAccept(ServerSocket.java:462)
	at java.net.ServerSocket.accept(ServerSocket.java:430)
	at hudson.maven.AbstractMavenProcessFactory$SocketHandler$AcceptorImpl.accept(AbstractMavenProcessFactory.java:167)
	at hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:221)
	at hudson.maven.ProcessCache.get(ProcessCache.java:231)
	at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:668)
	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:429)
	at hudson.model.Run.run(Run.java:1374)
	at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:467)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:145)
Finished: ABORTED

Beheben über advanced und dort in die MAVEN_OPTS hinzufügen:

-Djava.net.preferIPv4Stack=true

Anschließend sollte der Build wieder korrekt funktionieren. Alternativ kann man dies auch als globale Environment Variable setzen, das Problem wird mehrere Java Anwendungen betreffen und nicht nur den CI Server.

Nachdem ich (wie im vorherigen Artikel beschrieben) nun OpenJDK / Java 7 selber kompiliert habe, habe ich mich auf die Suche nach dem SSL Problem gemacht, dass ich mit Jameica/Hibiskus habe. (No offense, ich find es leichter OpenJDK zu übersetzen oder anzupassen als Jameica und Hibiskus zu bauen… praktischerweise bringt OpenJDK auch Netbeans Projektdateien mit, so dass es ein Klacks ist, das Projekt mit Netbeans zu verwenden.)

Nachdem ich folgenden Patch geschrieben habe habe:

diff -r 9b8c96f96a0f src/share/classes/sun/security/ssl/SSLContextImpl.java
--- a/src/share/classes/sun/security/ssl/SSLContextImpl.java	Mon Jun 27 13:21:34 2011 -0700
+++ b/src/share/classes/sun/security/ssl/SSLContextImpl.java	Mon Jul 25 19:30:11 2011 +0200
@@ -871,7 +871,7 @@
                 }
             } catch (CertPathValidatorException cpve) {
                 throw new CertificateException(
-                    "Certificates does not conform to algorithm constraints");
+                    "Certificates does not conform to algorithm constraints", cpve);
             }
         }
     }

ist jetzt auch zu sehen, was die Ursache fuer den SSL Fehler ist:

Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed: MD2withRSA
	at sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:200)
	at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:870)
	... 21 more org.kapott.hbci.manager.HBCIUtils.log(HBCIUtils.java:1052)

OpenJDK kommt übrigens ohne Root Zertifikate daher, so dass man sich nicht über einen solchen Dialog wundern sollte:

Nachdem man die Exception genauer ansieht, ist man auch etwas schlauer geworden: Irgendein Zertifikat ist mit einem nicht mehr als sicher geltenden Algorithmus signiert. Das der Apobank selbst ist es offensichtlich jedoch nicht, also muss die gesamte Zertifikatskette untersucht werden.
Hier habe ich etwas Shell-Magie und das OpenSSL Kommandozeilentool verwendet:

openssl s_client -showcerts -connect hbcibanking.apobank.de:443 < /dev/null | awk -v c=-1 '/-----BEGIN CERTIFICATE-----/{inc=1;c++} inc {print > ("cert-" c ".pem")}/---END CERTIFICATE-----/{inc=0}'; for i in cert-?.pem; do openssl x509 -noout -serial -subject -issuer -in "$i"; done

Danach finden sich alle Zertifikate in cert-1.pem, cert-2.pem usw., die Ausgabe der Seriennummern, Subject und Issuer sah bei mir so aus:

serial=4FCD4C50631D3BB4C747A319E816AD5D
subject= /C=DE/ST=NRW/L=Duesseldorf/O=Deutsche Apotheker- und Aerztebank/OU=Terms of use at www.verisign.com/rpa (c)05/CN=hbcibanking.apobank.de
issuer= /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
serial=254B8A853842CCE358F8C5DDAE226EA4
subject= /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
serial=70BAE41D10D92934B638CA7B03CCBABF
subject= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

Nun müssen alle Zertifikate untersucht werden:

openssl x509 -text -in cert-0.pem

Und entsprechend für die anderen Zertifikate in der Kette. Ich wurde dann bei dem dritten Zertifikat fündig:

tkruse@charix:~$ openssl x509 -text -in cert-2.pem
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
Signature Algorithm: md2WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Validity
Not Before: Jan 29 00:00:00 1996 GMT
Not After : Aug 1 23:59:59 2028 GMT
Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority

Ein „betagtes“ altes VeriSign Zertifikat das mit MD2 und RSA signiert wurde. Auch wenn der MD2 Signaturalgorithmus noch nicht gebrochen ist, gibt es einige Angriffe, die dazu geführt haben, dass MD2 seit 2009 nicht mehr in OpenSSL verwendet wird.
Was heißt das nun für das konkrete SSL Problem? Die ApoBank wird sich eh um Januar 2012 herum spätestens ein neues SSL Zertifikat besorgen. Dann sollte der Spuk zu ende sein. Besser wäre es allerdings wenn die betroffenen Anbieter ihre SSL Zertifikate jetzt erneuern – es geht schließlich um Online Banking!
Und wieso fällt das erst seit Java 7 auf? Seit Java 7 ist offenbar die Möglichkeit neu hinzugekommen die Algorithmen zu prüfen oder wurde geändert. Eigentlich sollte seit Java 6u17 bereits MD2 nicht mehr unterstützt werden, zumindest gibt es einen entsprechenden Eintrag in den Release notes: http://www.oracle.com/technetwork/java/javase/6u17-141447.html.

Ich habe ein merkwuerdiges SSL Problem mit Java 7 (Build 147, dem Release Candidate) im Zusammenhang mit Online-Banking und Jameica/Hibiskus:

Caused by: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
 at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:873)
 at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:804)
 at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1319)
 ... 19 more

Schaut man sich dazu den Source Code an, sieht man schnell, dass leider die verursachende Exception verschluckt wird. (Das kommt davon, wenn Committer und Reviewer identisch sind…)
Meine Idee war also, OpenJDK selber zu bauen und da ggf. besseres Logging einzubauen. Die im Internet veröffentlichten Anleitungen sind alle ein paar Jahre alt und nicht mehr ganz korrekt, daher hier meine Ergebnisse zum Nachmachen.
Ich habe Ubuntu als System verwendet, dort ist eine Übersetzung von OpenJDK / Java 7 sehr einfach.
OpenJDK wird mittels Mercurial verwaltet, zur Hierarchiebildung wird die Mercurial Forest extension benötigt (und Mercurial). Ist das „mercurial“ Paket bereits installiert so kann man die Forest extension einfach herunterladen:

hg clone http://bitbucket.org/pmezard/hgforest-crew hgforest

Diese muss nun in die .hgrc eingetragen werden: (das „….“ durch den Pfad zum Download ersetzen)

[extensions]
forest=......hgforest/forest.py
fetch=

Danach installiert man die Build Abhängigkeiten:

sudo apt-get install build-essential gawk libasound2-dev libfreetype6-dev libcups2-dev libxt-dev libx11-dev libxtst-dev libxrender-dev

Und checkt per mercurial-forest die Sourcen fuer OpenJDK aus:

hg fclone http://hg.openjdk.java.net/jdk7/jdk7 jdk7

Da beim späteren Build noch Java Abhängigkeiten heruntergeladen werden müssen, hab ich noch folgendens in die Ant Konfiguration eingesetzt: ~/.antrc

ANT_OPTS=”$ANT_OPTS -Dallow.downloads=true”

Für den build benötigt man ein existierendes Java, und setzt folgenden Umgebungsvariablen:

export ALT_BOOTDIR=/usr/lib/jvm/java-6-sun
unset JAVA_HOME
export LANG="C"
make sanity

Da sollten keine Fehler zu sehen sein und gibt dann den „make“ Befehl (dauert bei mir rund 40 Minuten):

make

Und kann es dann aus dem aktuellen Verzeichnis testen ob „java“ vorhanden ist:

build/linux-amd64/bin/java -version

Bei mir sieht das dann folgendermassen aus:

openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-tkruse-b00)
OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)

Fertig.
(Ja man benötigt wirklich keine „binary plugs“ o.a“. mehr!)

Update: Für Ubuntu 12.04 benötigt man folgende Pakete:

libcups2-dev, libfreetype6-dev, liboss4-salsa-dev

Und muss (Stand Mai 2012) auch wegen der neueren Kernelversion als die bei OpenJDK bekannten eine Environment Variable setzen:
export DISABLE_HOTSPOT_OS_VERSION_CHECK=ok

Bei jedem einzelnen Anruf „von O2“ habe ich bisher gesagt: Ich möchte keine weiteren Anrufe. Das scheint getrost ignoriert zu werden.

Ich glaube nun auch zu wissen, wieso: Es ruft nie O2 an. Das sind Callcenter die outbound Vertrieb machen. Besonders dreist war heute 0209 15704778 (Sucht man bei Google nach „O2 und 0209“ findet man auch weitere Berichte über aggressives Vorgehen eines Callcenters in Gelsenkirchen.)

Mir sollte heute ein Auslandstarif aufgeschwatzt werden, die Dame war unhöflich als ich sagte dass ich keine Werbeanrufe möchte. Und sowieso man könne nicht speichern dass ich keine Anrufe möchte, das gehöre zum Vertrag. Als man merkte dass ich nichts kaufen möchte, wurde dann kurzerhand aufgelegt. So schafft O2 sich keine zufriedenen Kunden…

Ein Link bei Google führt zu einer 404 Seite – blöd, kann passieren. Einen typischen „einselfer“ hätte ich Google jedoch nicht zugetraut. Oder handelt es sich da um einen subtilen Witz?