HowTo: CAcert Zertifikat für eisfair-Webserver

Der Apache-Webserver für eisfair kann selbstverständlich auch mit SSL umgehen. Das ist beispielsweise sinnvoll für alle Anwendungen, die man auf dem heimischen Server laufen lassen möchte und die Authentifizierung verlangen, damit die Passwörter, die über’s Netz gehen definitiv verschlüsselt sind. Auch die Inhalte wie beispielsweise die vom Webmailer bleiben der Öffentlichkeit lieber verborgen.

Wenn man bei CAcert angemeldet ist, liegt es nahe, sich auch für den eisfair-Server zu Haus ein passendes Zertifikat ausstellen zu lassen. Voraussetzung dafür ist folgendes:

  • eisfair-Server mit den installierten Paketen apache2 und certs
  • Account bei CAcert und genügend Punkte zum Erstellen eigener Server-Zertifikate

Sind alle Voraussetzungen erfüllt, geht man wie folgt vor. Zunächst ruft man auf dem eisfair-Server das Setup-Menü auf und geht ins Service-Menü von certs. Dort wählt man den Punkt Manage certificates. Daraufhin ändert man über 1 den key type auf web server. Als nächstes wählt man Punkt 10 (create a new key or select an exiting one [apache]), sonst schlägt der folgende Punkt fehl. Nun wählt man Punkt 11 (create certificate request), das verlangt CAcert nämlich später beim Erstellen des Zertifikats. Bei den Eingaben kann man sich weitestgehend an die Vorgaben halten. Wichtig: Als Common Name die Domain (FQDN) angeben, unter der der Server später erreichbar sein soll, beispielsweise www.example.dyndns.org, wenn man das später von draußen so im Browser eintippt, um den Heimserver zu erreichen. Als Challenge passwort gibt man einen einfachen Punkt ein.

Der Certification Request liegt jetzt unter /var/certs/ssl/csr/apache.csr. Den Inhalt dieser Datei benötigt man, um nun auf der Webseite von CAcert sein Zertifikat zu beantragen. Also kopiert man den Inhalt der Datei und loggt sich bei CAcert ein. Dort wählt man auf der rechten Seite Server Zertifikate und Neu. Nach einem langen, wichtigen Text gibt es unten ein großes Eingabefeld, in das man nun den Inhalt der Zwischenablage beziehungsweise den Certification Request einfügt. Anschließend auf Abschicken klicken, nochmal den Common Name gegenprüfen und nochmal Abschicken klicken.

Daraufhin zeigt die CAcert-Webseite das neue Zertifikat an. Das kopiert man und speichert es auf dem eisfair-Server in eine Datei mit der Endung .pem, beispielsweise www_example_dyndns_org.pem. Diese Datei kopiert man nun mit root-Rechten nach /var/certs/ssl/certs/. Anschließend ruft man ebenfalls mit root-Rechten einmal das Skript /usr/bin/ssl/c_rehash auf.

Mit einem aktuellen apache2 (probiert mit 1.3.4) wird man bei Aktivierung der Option APACHE2_SSL in der Konfiguration beim ersten Aktivieren einmal durch die komplette Zertifikat-Erstellungsprozedur geschickt, die genutzt wird, wenn der eisfair-Server selbst eigene Zertifikate ausstellt. Da wurstelt man sich einmal durch. Anschließend muss man dem Apache aber noch das CAcert-Zertifikat unterschieben. Wenn vHosts verwendet werden, gibt man den oben vergebenen Dateinamen einfach ohne Endung in der Variablen APACHE2_VHOST_?_SSL_CERT_NAME an. Verwendet man keine vHosts ist noch etwas Trickserei erforderlich. Der Apache erwartet das Zertifikat dann in /usr/local/ssl/certs/apache.pem bzw. (da /usr/local/ssl nur noch ein Symlink auf /var/certs/ssl ist) /var/certs/ssl/certs/apache.pem.

Jetzt gibt’s mehrere Möglichkeiten: apache.pem mit der neuen Datei überschreiben, einen symbolischen Link mit dem Namen apache.pem auf die neue Datei setzen oder den entsprechenden Teil aus der neuen Datei im Editor kopieren und in apache.pem ersetzen. Die zweite Variante (root-Rechte):

cd /var/certs/ssl/
mv apache.pem apache.pem.bak
ln -s www_example_dyndns_org.pem apache.pem
/usr/bin/ssl/c_rehash

Anschließend den Webserver nochmal neu starten, fertig. Der Apache ist fortan über https://www.example.dyndns.org mit einem von CAcert signierten Zertifikat erreichbar.

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.

Debian und ausgelagerte Firmware in Linux 2.6.29

Mein Notebook arbeitet wie so viele andere mit einem Chipsatz von Intel, d.h. LAN und WLAN läuft beides mit Intel Chips:

lassy:~# lspci | grep 'Network|Ethernet'
02:07.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)
02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet Controller (rev 81)

Nun kam heute früh der neue Linux Kernel 2.6.29 in Debian unstable an. Bei der Installation wunderte ich mich schon, dass das Update der initramfs nicht 100% glatt lief und folgende Meldungen kamen:

W: Possible missing firmware /lib/firmware/e100/d102e_ucode.bin for module e100
W: Possible missing firmware /lib/firmware/e100/d101s_ucode.bin for module e100
W: Possible missing firmware /lib/firmware/e100/d101m_ucode.bin for module e100

Beheben ließ sich das in meiner Debian-Installation dann einfach durch die Installation der Pakete firmware-ipw2x00 und firmware-linux.

Speicherlimits von MiKTeX erhöhen

Vor einiger Zeit hatte ich im Beitrag Schicke Grafiken in LaTeX mit pgfplots (1) eine elegante Möglichkeit vorgestellt, größere externe Datenmengen in schicke LaTeX-Plots zu verwandeln. Ich mache das immer noch sehr ähnlich, bin aber heute auf ein Problem gestoßen, das auch in der Dokumentation zu pgfplots Erwähnung findet. Im Kapitel »7 Memory and Speed considerations« heißt es dort:

The default settings of most TEX-distributions are quite restrictive, so it may be necessary to adjust them.

Dieses Limit hatte ich nun offenbar auf meinem Notebook erreicht. Die Doku zu pgfplots schlägt vor, die Limits mit Kommandozeilenparametern beim Aufruf von pdflatex zu erhöhen. Das funktionierte in meinem Fall leider nicht, da ich gleichzeitig auch noch die Funktionalität von pgf/pgfplots zum Wiederverwenden bereits kompilierter Grafiken einsetze, Stichwort externalize. Dort wird aus pdflatex heraus noch ein weiterer Lauf von pdflatex gestartet. Jetzt hätte ich diesen Aufruf anpassen und mit dem entsprechenden Parameter versehen können, aber dann wäre ich unter Linux auf die Nase gefallen, wo ich das Dokument ebenfalls kompilieren will.

Im Hinterkopf aus meinen ersten Experimenten mit pgfplots hatte ich aber, dass man diese Memory Limits auch irgendwo global setzen kann. In einem alten Thread in de.comp.text.tex hatte ich schon fast die richtige Lösung gefunden, aber der Tipp initexmf --edit-config-file=latex auf der Kommandozeile und dann im Editor den Wert anpassen funktionierte nicht.

Auf die richtige Spur kam ich dann als ich in C:\Programme\MiKTeX 2.7 eine Suche in den Dateien nach dem alten Limit ausführte. Ich erwartete eigentlich eine Konfigurationsdatei zu finden, aber ich wurde mit der Nase auf die Dokumentation von MiKTeX selbst gestoßen: C:\Programme\MiKTeX\2.7\doc\miktex\miktex.pdf. Da steht in Abschnitt »5.4 Changing TEXMF run-time parameters« nämlich genau, was zu tun ist:

initexmf --edit-config-file=pdflatex

Man beachte den kleinen Unterschied zu oben. ;-)
In der Datei hab ich dann jedenfalls folgendes eingetragen:

main_memory=3000000

Jetzt kompiliert mein Dokument wieder, ich kann fröhlich weiter arbeiten und schreibe mir selbst nochmal ein dreifaches RTFM hinter die Ohren.

Internet-Zensur bald auch in Deutschland?!

Die Zeitschrift c’t ist in erster Linie ein Computermagazin. Was sie von anderen Zeitschriften in dieser Sparte unterscheidet ist der Blick über den technischen Tellerrand hinaus zu den politischen und gesellschaftlichen Aspekten der Technik. In der aktuellen Ausgabe wird der Vorstoß der Bundesfamilienministerin Ursula von der Leyen beleuchtet, die sich vehement für die Filterung von Kinderpornographie im Internet einsetzt, wohl gemerkt Filterung, nicht Abschaltung. Der c’t-Redakteur findet sehr deutliche Worte:

Was steckt also wirklich hinter all diesen Hirngespinsten? Wenn es nicht die Bekämpfung von Kinderpornos ist, dann kann es nur um die Installation der Sperren selbst gehen. Das würde bedeuten, dass hier mit einem Vorwand eine geheime Liste eingeführt wird, die man nach und nach um weitere strafbare und unliebsame Inhalte erweitern kann. Die viel gelobten skandinavischen Länder zeigen bereits die Richtung: In Schweden versuchte die Polizei 2007 auf Lobbydruck hin, Adressen der Tauschbörsen-Suchmaschine Pirate Bay auf die Kinderporno-Sperrliste zu heben. Ähnliches ereignete sich 2008 in Dänemark.

Oder um es noch deutlicher auszudrücken: hier soll anscheinend unter dem Vorwand des Kampfes gegen Kinderpornographie eine Zensurinfrastruktur geschaffen werden, wie man sie bisher nur aus China kennt. Dass derartige Systeme über kurz oder lang nicht nur für den zur Zeit propagierten Zweck genutzt werden, sondern weitere Begehrlichkeiten wecken und letztlich wohl auch zur Zensur aller möglichen anderen Inhalte dienen werden, davon kann man nach aller Erfahrung ausgehen. Wie weit ist es dann noch bis Kritiker hierzulande auch mundtot gemacht und möglicherweise wegen ihrer Gesinnung verhaftet werden?

Zum nach- bzw. weiterlesen:

Letztere ist durchaus interessant, weil die Argumente, auf die Frau von der Leyen nicht hören will, alle nochmal mit Links hinterlegt sind.

Cloud Messaging

Moderne Instant-Messaging-Protokolle, wie zum Beispiel Jabber, erlauben es bereits mit mehreren Clients gleichzeitig online zu sein. Auch das Problem der durch mehrere Rechner verteilten Nachrichtenhistorie kann mit Tools wie IMPULS, über das wir auch schon berichtet haben, gelöst werden.

Übrig bleibt das Problem, dass eingehende Nachrichten nur bei einem der angemeldeten Clients erscheinen. Bei Jabber ist das der Client mit der höchsten Priorität. Sitzt man gerade an einem der anderen Rechner, hat man Pech und wird über die Nachricht nicht informiert. Auch, wenn man den Rechner wechselt oder der Gesprächspartner an eine bestimmte Ressource schreibt, erfährt man von der Nachricht erst, wenn man genau den Zielclient öffnet.

Es fehlt ein System, bei dem man auf allen angemeldeten Clients jederzeit denselben Zustand vorfindet. Inklusive der aktuellen Nachrichten. Das entspräche auch der Vorstellung des Geprächspartners, der oft gar nicht weiß, welche Infrastruktur man selbst hat und welche Nachricht wo empfangen wird.

Der Begriff “Cloud Messaging” für dieses Konzept ist vom Cloud Computing abgeleitet, bei dem es ja auch darum geht, an jedem beliebigen Ort seine Daten und Applikationen vorfinden zu können. In diesem Fall geht es nicht allgemein um die Berechnung, sondern um Kommunikation, also eine Unterkategorie des Computings.

Es gibt eine einfache Lösung, die ich für ICQ schon lange anwende: Der Client (licq) läuft als Konsolen-Applikation in einer virtuellen Konsole mit screen. Über ssh kann ich mich mit meinem Server verbinden und dann auch auf mein ICQ zugreifen. Die Lösung erfüllt alle oben gemachten Forderungen. Sie hat aber drei Nachteile:

  1. Ich brauche dafür einen Server, auf dem meine Software laufen kann.
  2. Die Hardware, mit der ich zugreife, muss eine entsprechende Konsole darstellen können. Bei einem Handy wird das schon schwierig. Das Benutzerinterface lässt sich nicht an das jeweilige Gerät anpassen.
  3. Da die Kopplung zwischen Applikation und Betriebssystem durch ssh und screen sehr lose ist, können spezielle Mechanismen des Zielgeräts – zum Beispiel das Abspielen eines Sounds bei eingehenden Nachrichten – nicht genutzt werden. Die Integration ist sehr schlecht.

Gerade offene Protokolle mit entsprechenden Client-Bibliotheken laden dazu ein, auf das jeweilige Gerät angepasste Applikationen zu schreiben. Deshalb muss das Cloud Messaging über das Protokoll realisiert werden.

Möglich ist zum Beispiel folgende Lösung: Der Server versendet nicht sofort die Nachrichten, sondern informiert alle Clients über die anstehende Nachricht. Falls sich Clients anmelden, wenn noch wartende Nachrichten vorhanden sind, werden diese ebenfalls informiert. Erst wenn ein Client die Nachricht wirklich angenommen hat, der Nutzer die Nachricht also aktiv auf dem Client empfangen hat, wird sie vom Server entfernt. Die übrigen Clients werden darüber informiert, dass die Nachricht empfangen wurde. Effektiv werden damit keine Nachrichten mehr verschickt, sondern Informationen über eine Änderung des Messaging-Zustandes des betroffenen Nutzers. Dieser liegt auf dem Server, wie das auch derzeit mit nicht abgerufenen Nachrichten der Fall ist.

Wenn dieses Konzept auf den Status erweitert wird, ist es außerdem möglich, transparent mit nur einem Gerät zu erscheinen, während man gleichzeitig mit dem Desktop-PC, dem Notebook und dem Handy online ist und die Wahl hat, auf welchem der Geräte man die Nachricht empfangen und die Antwort verfassen möchte.

Scrollbalken im Midnight Commander

Ein interessantes, wenn auch eher unwichtiges Problem kam kürzlich in einem Chat des fli4l/eisfair-Teams auf. Der Entwicklungsserver wurde umgebaut und das System neu aufgesetzt. Mit dem Upgrade auf Debian Lenny hielt auch UTF-8 Einzug und sorgte natürlich für allgemeine Verwirrung. Viele Nutzer arbeiten mit PuTTY auf der Maschine. Dort muss man nicht nur das Locale des Servers richtig einstellen, sondern auch die Line Drawing Character auf Unicode stellen und eine passende Schrift auswählen. Dass dies nicht so einfach ist, habe ich letztens erst ausführlich beschrieben.

Im konkreten Fall hatte einer der Entwickler PuTTY korrekt eingerichtet und als Schrift die Courier New ausgewählt. Das Problem: der Midnight Commander stellt alles korrekt dar, bis auf die Scrollbalken, wo nur hässliche Kästchen erscheinen. Das Problem ließ sich relativ leicht verifizieren. Auf einem Debian Lenny, sieht das mit Courier New tatsächlich so aus, bei einer Verbindung zu einem Debian Etch sieht man mit Courier New hingegen korrekt dargestellte Pfeile. Ein Umschalten auf die von mir bevorzugte DejaVu Sans Mono bewirkte in beiden Sessions eine korrekte Darstellung. Wenn man genau hinsah, zeigten sich aber subtile Unterschiede.

Ich hab dann die entsprechenden Zeichen kopiert und im Hex-Editor unter die Lupe genommen. Auf dem Rechner mit Etch gab ein `mc --version` (gekürzt) folgendes:

GNU Midnight Commander 4.6.1

Mit dem Wissen aus meinem früheren Beitrag »Wie funktioniert UTF-8?« sah meine Analyse der Zeichen dann so aus:

▲ – E296B2h – 11100010 10010110 10110010 – 00010010110110010b – 9650 – U+25B2
● – E2978Fh – 11100010 10010111 10001111 – 00010010111001111b – 9679 – U+25CF
▒ – E29692h – 11100010 10010110 10010010 – 00010010110010010b – 9618 – U+2592
▒ – E29692h – 11100010 10010110 10010010 – 00010010110010010b – 9618 – U+2592
▼ – E296BCh – 11100010 10010110 10111100 – 00010010110111100b – 9660 – U+25BC

In den letzten beiden Spalten stehen die Unicode-Nummern der Zeichen in dezimal und hexadezimal. Auf decodeunicode.org findet man raus, dass diese alle zur Gruppe »Geometric Shapes« gehören und korrekt encodiert sind. Diese Zeichen werden mit Courier New wie bereits erwähnt korrekt dargestellt. Bei Lenny gibt es eine neuere Version des Midnight Commander:

GNU Midnight Commander 4.6.2-pre1

Bei dieser Version sehen die Scrollbalken dann so aus:

▴ – E296B4h – 11100010 10010110 10110100 – 00010010110110100b – 9652 – U+25B4
◈ – E29788h – 11100010 10010111 10001000 – 00010010111001000b – 9672 – U+25C8
▒ – E29692h – 11100010 10010110 10010010 – 00010010110010010b – 9618 – U+2592
▒ – E29692h – 11100010 10010110 10010010 – 00010010110010010b – 9618 – U+2592
▾ – E296BEh – 11100010 10010110 10111110 – 00010010110111110b – 9662 – U+25BE

Auch diese Zeichen gehören zur Unicode-Untergruppe »Geometric Shapes« und sind absolut korrekt encodiert, aber sie sind leider nicht in Courier New enthalten. Davon kann man sich unter Windows XP überzeugen, indem man im Startmenü unter Zubehör und Systemprogramme die Zeichentabelle öffnet. Als Schriftart dann Courier New wählen, erweiterte Ansicht auswählen, als Zeichensatz Unicode, Gruppieren nach Unicode-Unterbereich und dort dann Block-/geometr. Elemente. Die dicken Pfeile vom mc 4.6.1 sind drin, die kleineren nicht.

Diese unscheinbare Änderung lässt sich tatsächlich auf den Midnight Commander zurückführen. Wenn man sich mal den UTF-8 Patch im Downloadbereich auf midnight-commander.org ansieht, dann findet man an entsprechender Stelle im Quellcode genau diese Zeichen.

Simple Lösung: eine andere Schrift als Courier New auswählen. Das gilt übrigens auch für den Browser, falls in obigem Beispiel anstelle der Pfeile auch nur komische Zeichen zu sehen sind. ;-)

1234567890 Sekunden Unixzeit

Unix und viele verwandte Systeme speichern Zeitangaben in Sekunden, die seit dem 1. Januar 1970 00:00 Uhr nach koordinierter Weltzeit (UTC) vergangen sind. Das ist nicht immer ganz unproblematisch, aber wie man unter anderem der deutschen Wikipedia entnehmen kann, gibt es ein paar besondere Werte, die für uns Geeks ein netter Vorwand sind, die Gläser zu erheben und anzustoßen.

Heute Nacht nun wird in dieser Zeitrechnung die Marke 1234567890 Sekunden erreicht. Nach deutscher Zeit (UTC+1) also in der Nacht von Freitag, dem 13. Februar 2009 auf Sonnabend, den 14. Februar 2009 um genau 00:31:30 Uhr.

Für viele Geeks rund um den Globus ist das auch ein Grund zum Feiern, zumindest ist die Trefferliste von Google zu utc 1234567890 ziemlich lang.

Ein besonderes Kuriosum: in Pennsylvania (USA) gibt es einen GeoCache mit dem Titel »When The Clock Strikes 1234567890«! *gg*

Wer mit Tux und mir heute nacht zusammen anstoßen will: wir halten uns in der Stadt Otto-von-Guerickes in der Schenke zur kräftigen Blume auf. ;-)

Nachtrag: ich hab nicht von webvariants abgeschrieben sondern von Stories of a KDE programmer. Den Link hatte Tux am Montag in seinem identi.ca Stream. 8-)

Es gibt (k)eine perfekte Schrift für die Konsole

Ursprünglich hatte ich vor einen Beitrag darüber zu schreiben, dass ich es nicht geschafft habe, für Windows eine Schriftart zu finden, die ich zum Programmieren und als Konsolenschrift nutzen kann, also primär in PuTTY. Nun hat sich das etwas anders gegeben, aber der Reihe nach. Die Anforderungen waren folgende:

  • Festbreitenschriftart, monospace quasi
  • saubere Darstellung in Schriftgröße 9 auf dem Notebook, sprich auf TFT-Bildschirmen
  • gute Unterscheidung von den kritischen Zeichen beim Programmieren: l vs. I und 1, 0 vs. O usw.
  • »Line drawing characters« für Pseudofensteranwendungen auf der Konsole (mc, ncurses-basierte…)
  • als Bonus eine breite Auswahl an Unicode-Zeichen

Courier New

Los geht’s erstmal mit Courier New. Die ist ziemlich ausgelutscht, ist aber schon da und hat neben den Strichzeichen auch eine recht breite Unicode-Unterstützung. Die Unterscheidung zwischen kleinem l und der 1 ist nicht so schön. Die zwischen dem großen O und der 0 könnte auch besser sein, ansonsten aber ganz brauchbar.

Schriftprobe Courier New

Lucida Console

Nächster Kandidat ist die Lucida Console, ebenfalls bei Windows dabei. Die sieht sehr klar aus. Die Unterscheidung zwischen O und 0 gelingt nicht so gut. Mir persönlich ist sie in der gewünschten Schriftgröße zu breit und die Zeilenabstände sind recht eng. Das geht noch besser.

Schriftprobe Lucida Console

Consolas

Bei Windows Vista dabei, aber auch separat von Microsoft zu bekommen ist die Consolas. Die sieht unter den richtigen Voraussetzung rein optisch am besten aus. Die Schrift wurde speziell für TFT-Bildschirme und das dort verwendete Sub-Pixel-Hinting und ClearType optimiert, sieht auf alten Monitoren daher leider grauselig aus. Zum Programmieren eignet sie sich super. Leider gibt es einen ganz großen Haken: sie hat nur einen sehr kleinen Zeichenvorrat und die Strichzeichen sind nicht dabei, was sie für die Konsole komplett disqualifiziert, so bleibt sie leider nur etwas zum reinen Programmieren unter Windows.

Schriftprobe Consolas

Andale Mono

Danach habe ich lange mit der Andale Mono gearbeitet, die früher bei Windows dabei war und auch noch im Netz zu finden ist. Diese Schrift lässt recht viel Raum und wirkt recht klein, was zunächst mal ungewohnt ist, aber dann im täglichen Gebrauch nicht weiter stört. Leider hat diese Schrift einen Pferdefuß, der mich dann doch wieder auf die Suche nach einer besseren Alternative geführt hat. Bei 9pt sind ; und : kaum zu unterscheiden. Für einen Chat im irssi ist das doof, weil man ;-) und :-) kaum noch unterscheiden kann.

Schriftprobe Andale Mono

DejaVu Sans Mono

Gestern dann telefonierte ich mit meinem Bruder, einem studierten Experten auf dem Gebiet der Typographie. Von ihm bekam ich den Tipp es mal mit der DejaVu Sans Mono zu versuchen. Diese ist mir unter Linux natürlich schon das eine oder andere Mal begegnet. Die Schrift selbst wird als offenes Projekt auf dejavu-fonts.org entwickelt und man kann sie als OpenType TTF auch unter Windows nutzen. Sie enthält eine sehr breite Auswahl an Unicode-Zeichen und natürlich auch die gewünschten line drawing characters. Die beim Programmieren relevanten Zeichen sind ausreichend gut zu unterscheiden. Im Terminal wirkt sie sehr hoch und lässt wenig Raum zwischen den Zeilen, wirkt aber ausgewogener als die Lucida Console und ist insgesamt gut lesbar. Das macht sie nicht ganz perfekt aber sie ist frei und daher ab sofort meine erste Wahl als Konsolenschrift.

Schriftprobe DejaVu Sans Mono

eisfair-HowTo: richtig krasse Spam-Mails automatisch löschen

Spam, Spam, Spam, Spam und das jeden Tag. Mein Setup sieht derzeit so aus, dass auf meinem eisfair-Server das Paket mail installiert ist. Dies sammelt via fetchmail die Mails von meinen Mailkonten ein, jagt die durch ClamAV und durch SpamAssassin und verteilt die dann wahlweise auf mein IMAP-Konto oder zum User spam. Das funktioniert sehr gut, auch die false positive Rate des Spam-Filters ist traumhaft, ich kann mich an keinen einzigen in den letzten drei Jahren erinnern.

Nichtsdestotrotz kommen immernoch zu viele Spam-Mails durch. Peter vom Fli4l-Team wurde das bei derselben Software zu viel und kam im IRC mit folgender Lösung um die Ecke: alle Spam-Mails, die von SpamAssassin einen Score größer als 10 bekommen, werden direkt nach /dev/null verschoben, also unwiderruflich gelöscht. Als ich gestern die aktuelle Welle in meinem Spam-Ordner anrollen sah, hab ich beschlossen, das auch umzusetzen.

Mit eisfair ist das zum Glück spielend leicht. Man erstellt als root einfach eine Datei namens custom-systemfilter.rm_spam_mail im Ordner /var/spool/exim und übergibt die dann mit

chown exim:trusted /var/spool/exim/custom-systemfilter.rm_spam_mail

dem passenden Systemnutzer. Der Inhalt muss wie folgt aussehen:

# Exim custom filter
#------------------------------------------------------------------------------
if $h_X-Spam-Score: contains "++++++++++++"
then
    logfile /tmp/exim_filter_rm_spam.log
    logwrite "$tod_log To=$h_to Subject=$h_subject From=$h_from Id=$message_id"
    save /dev/null
endif

(Bei neueren Versionen des Pakets mail kann man die Datei direkt aus /usr/local/exim/examples kopieren.)

Dann geht man ins Setup-Menü, dort in die Konfiguration vom Paket mail und lässt die einmal neu durchlaufen. Das Paket erkennt die zuvor erstellte Datei und meldet folgendes:

adding custom system filter /var/spool/exim/custom-systemfilter.rm_spam_mail ...

Fertig, naja fast. Wer den Filter aufmerksam angesehen hat, erkennt, dass das Log erstmal provisorisch in /tmp/exim_filter_rm_spam.log landet. Eleganter ist es, das Logfile dahin schreiben zu lassen, wo die anderen Logfiles von exim landen, nämlich nach /var/spool/exim/log. Dazu ändert man den Pfad im obigen Beispiel entsprechend ab. Jetzt fehlt noch das logrotate dafür. Dazu kopiert man am besten /etc/logrotate.d/mail in eine neue Datei, beispielsweise /etc/logrotate.de/exim_filter_rm_spam. Diese Datei passt man nun an seine Bedürfnisse an, d.h. man schmeißt den Abschnitt für fetchmail raus, ändert die Pfadangabe für das Logfile und spielt dann noch bisschen mit den eigentlichen Einstellungen. Bei mir sieht das Ergebnis so aus:

#------------------------------------------------------------------
# Creation: 2009-07-07 alex
#------------------------------------------------------------------
/var/spool/exim/log/exim_filter_rm_spam.log {
    rotate 53
    weekly
#    compress
    missingok
    notifempty
    sharedscripts
    create 640 exim trusted
    postrotate
        /etc/init.d/mail -quiet reload exim
    endscript
}

Ich lasse in dem Fall recht viele wöchentliche Logfiles übrig und lasse die nicht komprimieren. Das ermöglicht eine einfache statistische Auswertung, wieviel Spam tatsächlich gelöscht wurde (auch wenn ich das noch nicht umgesetzt habe).

Mehr Infos über das eisfair-Paket gibt’s in der eisfair-Dokumentation im Abschnitt Mail-Package. Die Filter vom Mailserver Exim sind detailliert auf exim.org beschrieben.

Ach und wer erkannt hat, dass ich in meinem Filter die Mails erst ab einen Score von 12 wegwerfe und nicht wie Peter schon bei 10, bekommt ein Bienchen!