Author Archives: mrtux

Java Enterprise Loop

Following a discussion in the Netz39 IRC channel I created a short Java Enterprise Loop for those in need.

package com.penguineering.seriousnonsense;

/*
 * Short usage instructions:
 *
 * 		final Runnable loopee = ... // Acquire some runnable instance
 * 		EnterpriseLoop.forRunnable(loopee).run();
 *
 * or put it in a thread:
 * 
 * 		new Thread(EnterpriseLoop.forRunnable(loopee)).start();
 *
 *
 * Whatever kills your design best.
 */

public class EnterpriseLoop implements Runnable {
	public static EnterpriseLoop forRunnable(final Runnable _loopee) throws NullPointerException {
		return new EnterpriseLoop(_loopee);
	}
	
	private final Runnable loopee;
	
	private EnterpriseLoop(final Runnable _loopee) throws NullPointerException {
		if (_loopee == null)
			throw new NullPointerException("Runnable _loopee must not be null!");
		
		this.loopee = _loopee;
	}
	
	public Runnable getLoopee() {
		return loopee;
	}
	
	@Override
	public void run() {
		while (true)
			try {
				loopee.run();
			} catch {Throwable t) {
				// ignore
			}
	}
}

To adhere to development standards usually found in situations leading to the need of an enterprise loop, I neither documented the code (except for a short usage instruction to save you from thinking about those lines you are going to copy) nor tested it.

I leave this to the public domain to successfully serve as a bad example.

Raspberry Pi automatisch mit dem Freifunk-WLAN verbinden

Ich setze gerade diverse Mini-Knoten auf Raspberry-Pi-Basis auf, die sich für den Internet-Zugang automatisch mit dem Magdeburger Freifunk verbinden sollen.

Anleitungen zur Verbindung mit einem WPA-verschlüsselten WLAN gibt es genug. Nur leider schweigen die zur Frage, was man denn mit einem unverschlüsselten WLAN1 macht.

Schließlich bin ich doch auf Stack Exchange und auf der man page des wpa_supplicant fündig geworden. An dieser Stelle sei die notwendige Konfiguration noch einmal zusammengefasst.

Ich nutze einen USB-WLAN-Adapter von CLS mit externer Antenne; intern ist das ein RTL8191SU 802.11n WLAN Adapter,der direkt unterstützt wird.

In /etc/network/interfaces wird für das WLAN-Device (wlan0) folgendes angefügt:

allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

iface default inet dhcp

Der Eintrag in /etc/wpa_supplicant/wpa_supplicant.conf sieht dann so aus:

network={
    ssid="md.freifunk.net"
    key_mgmt=NONE
    id_str="default"
}

Durch den Eintrag key_mgmt=NONE , der  meist verschwiegen wird, stellt der wpa_supplicant keine verschlüsselte Verbindung her, sondern nutzt das WLAN unverschlüsselt, wie es für Freifunk notwendig ist. In einem anderen Freifunk-Netzwerk muss natürlich die ESSID angepasst werden.

Nach einem Neustart verbindet der Raspberry Pi sich nun automatisch mit dem Freifunk-Netzwerk, sofern es erreichbar ist.

  1. zum Beispiel einem Freifunk-WLAN []

JavaMail and TLS: Turn on the security switch!

While talking to Ge0rg about latest issues in Java TLS we stumbled upon the question whether the JavaMail API would have similar problems.

Naturally one would expect that Java’s SSL implementation is secure. However, this is not the case: Special care needs to be taken regarding Man-In-The-Middle attacks: While a certificate may turn out to be valid, you cannot be sure that it has the right origin!

The problem is known for a while and library maintainers are taking steps to avoid it. However, for compatibility reasons those features may need to be turned on.

For JavaMail version 1.5.2 the SSLNOTES.TXT says specifically:

— Server Identity

Check RFC 2595 specifies addition checks that must be performed on the server’s certificate to ensure that the server you connected to is the server you intended to connect to. This reduces the risk of “man in the middle” attacks. For compatibility with earlier releases of JavaMail, these additional checks are disabled by default. We strongly recommend that you enable these checks when using SSL. To enable these checks, set the “mail..ssl.checkserveridentity” property to “true”.

Here is the thing that most examples forget: You need to switch that feature on!

final Authenticator auth = ... // somewhere in your application
final Properties p = new Properties();

// add your JavaMail configuration here

// this is implied by the protocol "imaps"
p.put("mail.imap.starttls.enable", "true");

// not only check the certificate, but also make sure that we are
// connected to the right server.
p.put("mail.imap.ssl.checkserveridentity", "true");

try {
	Session session = Session.getDefaultInstance(p, auth);
	Store store = session.getStore();
	store.connect();

	// do something with the store
} catch (MessagingException e) {
	// do something meaningful(!) with the exception
}

// close the store when you are done

To use SSL at all, you need to turn it on, either by specifying “imaps” in the property mail.store.protocol or by setting mail.imap.starttls.enable to “true”. Replace imap respectively for other protocol suites (e.g. smtp).

Update 2014-08-05: Inserted the Link to Georg’s blog post about latest issues in Java TLS.

HowTo: KMail wechselt Online/Offline je nach Netzwerkverbindung

Einige Probleme lassen sich schnell lösen. Zum Beispiel, dass KMail versucht, E-Mails abzuholen, selbst wenn es keine Netzwerkverbindung gibt.

Über den DBus lässt sich jede KDE-Anwendung fernsteuern, sofern die entsprechenden Interfaces angeboten werden. Mit dem Aufruf von

qdbus org.kde.kmail /KMail

erhält man eine Übersicht der Methoden, die KMail anbietet. Darunter sind auch stopNetworkJobs und startNetworkJobs – genau das, was wir brauchen.

Über die Toolbox des Network Managers, speziell nm-tools, ist es möglich, den Netzwerkstatus zu ermitteln. Jetzt fehlt nur noch ein kleines Script, das je nach Vorhandensein einer Netzwerkverbindung KMail in den Online- bzw. Offline-Modus versetzt.

#!/bin/bash

if [ `nm-tool|grep State|cut -f2 -d' '` == "connected" ]; then
       #Whatever you want to do if the network is online
       echo "Starting KMail network jobs"
       qdbus org.kde.kmail /KMail org.kde.kmail.kmail.resumeNetworkJobs       
else
       #Whatever you want to do if the network is offline - note, this and the else above are optional
       echo "Stopping KMail network jobs"
       qdbus org.kde.kmail /KMail org.kde.kmail.kmail.stopNetworkJobs
fi

Diese Script wird in der Ereignisverwaltung des Network Managers beim Ereignis “Schnittstellenstatus geändert” eingetragen und setzt nun den KMail-Status abhängig von der Verfügbarkeit einer Netzwerkverbindung.

Die Lösung ist sehr einfach, behebt aber die Fehlermeldungen und ist ein Ausgangspunkt für weitere Verbesserungen.

Nachtrag: Schöner wäre es, wenn KMail die Jobs beenden würde, bevor die Verbindung abbricht. Wer spontan einen Ansatzpunkt hat, bitte ab in die Kommentare damit.

Nachtrag2: Eigentlich brauchen wir eine Internetverbindung, d.h. streng genommen müsste ein Internet-Zugriff ausgeführt und dann abhängig vom Erfolg der KMail-Status gesetzt werden.

Web-2.0-Guide

Als ich vor noch nicht allzu langer Zeit einmal wieder Douglas Adams The ultimate Hitchhiker’s Guide to the Galaxy las, fiel mir in der Beschreibung der Geschichte des Guides eine Passage auf, die genauso gut auf Crowdsourcing und insbesondere Wikipedia zutrifft und die ich hier deshalb zitieren möchte:

[The Guide’s founder] also started to develop and explore the role of the editorial lunch break that was subsequently to play such a crucial part in the Guide’s history, since it meant that most of the actual work got done by any passing stranger who happened to wander into the empty offices of an afternoon and saw something worth doing.

Gerade Wikipedia funktioniert ja im Prinzip genauso. Bemerkenswert ist, dass Douglas Adams dies natürlich weit vor deren Gründung aufschrieb.

Logitech-HID mit Debian Sid

Nutzer der Unstable-Variante von Debian (auch als Debian Sid bekannt) bekommen ja bekanntlich regelmäßig Gratisabenteuer aus dem Bereich der Systemadimistration geschenkt; sozusagen ein Quest-Abo.

Problem des Tages: Einen Systemstart nach dem letzten Update funktionierten Bluetooth-Tastatur und -Maus von Logitech nicht mehr, in meinem Fall konkret das Dinovo-Set.

Ich habe häufiger Ärger mit Logitech unter Linux, meistens ließ sich das aber mit einem Reset des Bluetooth-Dongles1 beheben. Dieses Mal nicht, der Fehler war persistent.
dmesg, logs und Modulliste waren soweit korrekt, es war alles da, was für die Geräte gebraucht würde und es wurde laut lsusb auch alles erkannt. Nur funktionierte einfach nichts. $SUCHMASCHINE lieferte dafür auch keine weiteren Ergebnisse.

Letztendlich habe ich das Problem in den udev-Regeln2, speziell der Datei 70-hid2hci.rules gefunden. Dort steht in Zeile 15:

RUN+="hid2hci --method=logitech-hid --devpath=%p"

Ein kurzer Blick auf die Manpage zeigt, dass der Aufruf nicht korrekt ist. Ich habe die Zeile so abgeändert:

RUN+="hid2hci --method=logitech --mode=hid --devpath=%p"

Seit dem funktionieren Tastatur und Maus wieder einwandfrei.

Die Regel deckt einen großen Bereich von Logitech-Produkten ab, das Problem tritt also wohl auch dort auf. Debian-Bugreport kommt dann später noch.

  1. Abziehen und wieder dranstecken. ;) []
  2. zu finden unter /lib/udev/rules.d/ []

SpamAssassin: Von der Zeit eingeholt

Heute kam die berechtigte Beschwerde eines Webserver-Mitnutzers, dass viele E-Mails neuerdings fehlerhaft als Spam klassifiziert würden. Als fähiger Informatiker hat er auch gleich noch ein Beispiel mitgeliefert. Darin wurde eine Regel sichtbar, die ich bislang noch gar nicht weiter beachtet habe und die bis zum Beginn dieses Jahres durchaus sinnvoll war:

FH_DATE_PAST_20XX

Diese Regel vergibt Punkte fuer alle E-Mails die ab dem 01.01.2010 datiert sind. Und nicht nur ein paar Zehntel, sondern bis zu 3.5 Punkte — bei insgesamt 5 nötigen Punkten für eine Spam-Klassifizierung macht das sehr viel aus. Effektiv wurde damit die Grenze für Spam auf 1.5 Punkte herabgesetzt.

Die Lösung ist im Apache-Wiki zu finden und wurde gleich noch mitgeliefert: In der lokalen Konfiguration muss diese Regel manuell deaktiviert werden, indem man die vergebenen Punkte auf 0.0 setzt. (Ein sa-update hatte bei mir keinen Effekt.)

Das ist mal ein schönes Beispiel dafür, dass insbesondere Regeln, die nicht global gültig sind und bleiben, regelmäßig begutachtet und gegebenenfalls überarbeitet werden müssen.

Coffee Connection: Netzwerkverbindungen mit Java im Debian Sid

Ein länglicher Titel für ein ärgerliches Problem mit kurzer Lösung:

Seit einigen Tagen mag sich Eclipse unter Debian Sid auf meinem Arbeitsnotebook nicht mehr mit dem Internet verbinden. Die Fehlermeldungen sind, je nach Modul, verschieden, laufen letztendlich aber immer auf etwas in der Form “Network noch reachable” hinaus. Erst dann fällt auch auf, wie oft ich doch bei der Entwicklung auf das Internet zugreife: Subversion und Maven funktionieren nicht mehr, Updates und das Einspielen von Plugins ist unmöglich und irgendwann – ein wichtiger Hinweis auf die Fehlerursache – stellte sich heraus, dass gar keine Java-Anwendung mehr Zugang zum Netzwerk hat.

Nachdem ich zunächst nach Fehlern bei Eclipse gesucht habe, war die Lösung nun recht nahe: Ein Blick in die Fehlerberichte für das Paket sun-java6-jdk zeigt den Bug #560044, der genau mein Problem beschreibt. Offenbar hält SUNs Java sich nicht an die Konventionen für den Umgang mit IPv4- und IPv6-Verbindungen, so dass IPv4 gar nicht mehr funktioniert.

Der Fehlerbericht enthält am Ende auch einen Workaround, der bei mir funktioniert: In der Datei /etc/sysctl.d/bindv6only.conf die Variable net.ipv6.bindv6only von 1 auf 0 setzen, und schon dürfen IPv6-Sockets auch IPv4-Pakete empfangen. [Update: Mit dem Aufruf invoke-rc.d procps restart muss die Konfiguration dann noch neu geladen werden.] Problem solved.

Nun muss dieser Bug nur noch unter dem Google-Query “Debian Eclipse network connection error” erscheinen, dann wäre er auch keinen Blogeintrag mehr wert. 8-)

Resistente Virenschleuder

Als die Europäer das amerikanische Festland eroberten und die fälschlicherweise als Indianer bezeichneten Ureinwohner verdrängten, brachten sie neben Waffen und billigen Geschenken unbeabsichtigt noch etwas anderes mit: Krankheiten, gegen die sie selbst resistent waren, die den Indianern aber schwer zusetzten.

Warum erzähle ich das?

Als Linux in verschiedenen Distributionen begann, den Desktop zu erobern und mit der Ausbreitung des Internets auch Viren, Würmer und andere Malware populär wurden, stellte sich eines heraus: So richtig betroffen waren nur die Windows-Nutzer. Einen Virus für Linux zu schreiben, war ungleich schwerer und die Zahl der Nutzer war doch nicht hoch genug, als dass es sich lohnte. Folglich ist der Linux-Nutzer (und jeder Nutzer anderer Betriebssysteme) gegen die Windows-Viren resistent. Was besagten Nutzer jedoch nicht davor bewahrt, unwissend Überträger zu sein. Denn niemand verhindert, dass er auf seiner Festplatte, seinem USB-Stick und in seinen E-Mails Dateien hat, die eine Form von Schädling enthalten. Ein Windows-Nutzer, der eine Datei eines Linux-Nutzers weniger argwöhnisch öffnet, weil er ihm vertraut, wird so doch das Opfer einer Attacke gegen sein System. Ein Vertrauensbruch, der so nicht beabsichtigt war.

Jeder Windows-Nutzer lernt beizeiten, einen Virenscanner zu installieren, um sich gegen Schädlinge zu schützen. Linux-Nutzer fühlen sich sicher und brauchen solche Software nicht. Damit werden sie zum idealen Überträger, da sie nicht einmal wissen, was sich auf ihrer Platte tummelt.

Aufgefallen ist mir das, als mir jemand schrieb, in einer von mir hochgeladenen Datei (die ich auch von anderer Stelle per USB-Stick empfangen habe) einen Virus entdeckt zu haben. Zwar handelte es sich um einen Fehlalarm, trotzdem macht dies eines klar: Selbst wer nicht betroffen ist, sollte seinen Datenbestand hin und wieder nach Viren untersuchen!

Freie Virenscanner gibt es zum Beispiel mit ClamAV, die man per Cron-Job regelmäßig über seine Daten jagen kann. USB-Sticks lassen sich bei Bedarf automatisch überprüfen, wenn man auf die Daten zugreift, und schon ist das Netz ein wenig dichter und die Gefahr, selbst zur Virenschleuder zu werden, ein Stück geringer.

IT-Projekte 2009

Das Jahr ist zwar schon etwas fortgeschritten, trotzdem habe ich mir vorgenommen, bis zum Ende des Jahres in meiner Freizeit ein paar IT-Projekte voranzubringen. Aus der doch recht großen Auswahl der Projekte, die mich interessieren, habe ich die folgenden herausgepickt:

  1. IMPULS: Dieses Projekt hat inzwischen doch schon ein paar Jahre hinter sich und es gab diverse Situationen, in denen ich es gebraucht hätte. Bis Ende des Jahres sollten hier ein lauffähiger Daemon (aber auf Java-Basis) und ein paar Clients sowie mindestens ein Reader stehen.
  2. Antiblau: Den Server haben wir seit Ende 2005, aber noch immer sind ein paar Funktionen nicht verfügbar und auch die vorhandene Administrations-Infrastruktur kann mal modernisiert werden.
  3. Debian: Entwickler werde ich wohl in diesem Jahr nicht, aber ein paar Pakete aus eigenen Sachen möchte ich bauen und wenigstens soweit in die Community reinschauen, dass ich sicher entscheiden kann, ob ich überhaupt Entwickler werden will.
  4. QCaff: Eine grafische (Qt-basierte) Variante von CAFF, die sowohl unter Windows als auch unter Linux laufen soll und das Management von GPG-Keys für Jedermann ermöglichen soll. Insbesondere bei der Nachbereitung von Keysigning-Parties besteht hier offenbar Softwarebedarf. Wenn alles klappt, ist das aber trotzdem ein recht überschaubares Tool. Sofern vorhanden, werde ich bestehende Lösungen weiterverwenden.

Weiterhin warten auch bei UniMentor interessante Programmieraufgaben und der FaRaFIN kann ebenfalls mit einem interessanten Projekt aufwarten. Anfang 2010 werden wir sehen, was davon ich umsetzen konnte.