Tag Archives: HowTo

Gebrauchte Daten kaufen

In den letzten Wochen habe ich für dienstliche Zwecke vier alte Speicherkarten vom Typ MMC gebraucht bei der elektronischen Bucht erstanden. Auf allen vieren waren noch Daten drauf. Sicher, die waren frisch formatiert, aber alle nur im Schnelldurchlauf. Neues Dateisystem anlegen und fertig. Kein einziger der Verkäufer hielt es für notwendig, wirklich alle Daten zu löschen.

Ich bin nun kein Forensiker und meine Zeit für solchen Spielkram ist begrenzt. Aber da ich den coolen Hex-Editor Bless sowieso installiert und Images der Karten angelegt hatte, um Partitionstabellen und Volume Boot Records zu untersuchen, hab ich natürlich noch kurz weiter über die Dumps geschaut. Beim wirklich nur flüchtigen drüber Gucken habe ich Kartendaten für ein Navigationsgerät, Musikdateien im mp3-Format und Tabellen mit Adressen von Ärzten1 gefunden. Gerade bei letzterem handelt es sich um sensible Daten, die man vermutlich nicht wissentlich weitergegeben hat. Da rollen sich mir ja dann schon die Fußnägel hoch.

Damit die ganze Aufregung hier nicht umsonst ist, noch ein kleiner Tipp, wie man hier zwei Fliegen mit einer Klappe schlagen kann. Man benutzt einfach das Tool badblocks unter Linux im Schreibmodus. Vorsicht ist angebracht, mit Datenträgern, die man noch braucht, wenn aber wirklich alles gelöscht werden kann, dann hier der Auszug aus der manpage mit der passenden Option:

-w Use write-mode test. With this option, badblocks scans for bad blocks by writing some patterns (0xaa, 0x55, 0xff, 0x00) on every block of the device, reading every block and comparing the contents.

Das Programm schreibt also bestimmte Muster auf die Karte und liest diese dann nochmal zurück und zwar für jeden einzelnen Block. Wenn Fehler dabei auftreten, werden die gemeldet und man kann den Datenträger wegwerfen. Wenn keine Fehler auftreten, kann man die Karte ruhigen Gewissens verkaufen und sicher sein, dass ausschließlich Nullen drauf stehen.

Ganz wichtig: damit das funktioniert, führt man badblocks mit root-Rechten aus und lässt es auf das ganze Device los. Da muss man vorher das passende rausfinden und 100% (und kein µ weniger) sicher sein, dass man das richtige erwischt hat. Wenn noch ein Filesystem auf der Karte ist, einfach mounten und mit mount nach dem Device gucken. Oder mit dmesg anzeigen lassen, wie die Karte beim Anstecken erkannt wurde. Oder aus /proc/partitions das Device mit der passenden Größe ablesen. Oder am besten alle Möglichkeiten zusammen. Der fertige Befehl in meinem Fall hier und heute:

badblocks -sw /dev/sde

Falls man nun gerade kein Linux zur Hand hat, bitte in Windows beim Formatieren unbedingt vermeiden die »Schnellformatierung« zu aktivieren. Oder am besten nach der Formatierung nochmal das Programm h2testw der c’t drüber laufen und Daten schreiben lassen, damit wenigstens die Adressdaten der Homöopathen verschwinden. Nicht dass die am Ende noch wer aufsucht, oder vermöbelt oder potenziert oder so …

Ach ja und abgesehen vom Verkaufen von alten Datenträgern: die erwähnten Programme sollte man auch auf jeden frisch neu erworbenen Datenträger loslassen, um sicherzugehen, dass der auch funktioniert. Ist mir nämlich in den letzten Wochen mit einer neuen Festplatte und einem neuen USB-Stick passiert, dass die gleich vom Start weg defekt waren und umgetauscht werden mussten.

  1. und Homöopathen, man beachte die Unterscheidung … ;) []

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/ []

Zurück im Jahr 2000 mit fli4l

Ich befinde mich gerade auf den Chemnitzer Linux-Tagen 2010 am Stand von eisfair und fli4l. Unser überaus schicker Standrouter1 ist ein sogenanntes WRAP Board, also schon bisschen abgehangen. Der Hersteller hat hier leider keine Pufferbatterie für die RTC vorgesehen, so dass die Uhr nach jedem Stromausfall am 1.1.2000 um 0:00 (UTC) losläuft.

Nun läuft selbstverständlich fli4l (in der aktuellen Version 3.4.0) auf der Kiste und dort gibt es das Paket (bei fli4l traditionell opt genannt) chrony, was eben chrony bereitstellt, einen kleinen Dienst um die Zeit über NTP abzugleichen. Den Sprung von 2000 auf 2010 möchte der aber nicht automatisch abgleichen, so dass hier ein manueller Eingriff erforderlich ist. Die nötige Prozedur ist leider nicht ganz selbsterklärend, daher hier das kurze HowTo, wie man dort vorgehen kann.

Schritt 1: Den chronyd mit den richtigen Optionen neu starten. Per default wird dort bloß -r gesetzt. Die Option -s erlaubt auch das Setzen der RTC über chrony. Also erstmal per ssh einloggen. Dann:

killall chronyd
chronyd -r -s

Schritt 2: Beim chronyd einloggen. Dazu gibt man auf der Shell einfach chronyc ein. Per default darf man dann erstmal fast nichts, aber man kann das vom Paketmaintainer hinterlegte Passwort eingeben, um mehr Rechte zu erlangen. Bitte wie folgt eingeben:

chronyc
password dummy

Schritt 3: Die Zeit setzen. Dazu erlaubt man sich das zunächst mal mit dem Befehl manual, dann setzt man die Zeit und dann sagt man ihm noch, dass er das auch der RTC verklickern soll. Beim Setzen der Zeit reicht es das auf eine Minute genau zu machen, den Rest erledigt chrony später ganz normal per NTP.

manual on
settime 2010-03-14 08:55

Bei der Eingabe von settime springt die von chronyd erzeugte CPU-Last auf über 90%. Nach einem weiteren Neustart von chronyd, ist die Zeit gesetzt, ich kann nicht sagen warum, aber der pragmatische Ansatz funktioniert hier. Also:

killall chronyd
chronyd -r -s

Jetzt passt schonmal die Systemzeit, ein rtcdata im chronyc zeigt aber noch die alte Zeit der RTC. Also führt man hier nochmal ein trimrtc aus. Die Änderung braucht ein paar Minuten um übernommen zu werden, das geschieht aber dann automatisch.

So, und jetzt wo die Zeit vom Messerouter richtig eingestellt ist, freuen wir uns auf den zweiten Tag hier. Gestern war es schon gut besucht und es waren viele freundliche Interessenten am Stand. Der Sonntag Morgen läuft etwas ruhiger an, da könnte man eigentlich nochmal einen Kaffee trinken …

Update: die so gesetzte Uhrzeit übersteht auch einen Soft Reboot. D.h. wenn man das WRAP hinter eine USV hängt, braucht man die ganze Prozedur nur einmal auszuführen! ;-)

  1. wo alle Besucher nur fragen, wo man die Hardware kaufen kann []

HowTo: Auf Kanal 13 funken mit Debian

Unter uns sind neue Nachbarn eingezogen. Im Gegensatz zu den alten Nachbarn, verfügen diese über WLAN. Damit sind sie nicht die einzigen, im Funkspektrum tummeln sich hier ständig mindestens ein halbes Dutzend Funkzellen – kennt man vermutlich heutzutage aus jedem deutschen Mietshaus.

Grund genug für meinen Mitbewohner, den Kanal unseres WLAN-Access-Points mal in eine bisher wenig genutzte Region zu verschieben: Kanal 13. Nachtigall ick hör Dir trapsen, war da nicht mal was, mit Kanälen, die in den USA verboten sind, in Europa aber nicht? Muss wohl so sein, und da Debian ja fürsorglich ist, ist die Einstellung für USA default – obwohl, wenn man sich die Lösung ansieht, kann man Debian vermutlich nicht mal die Schuld in die Schuhe schieben.

Was also, wenn das Notebook jetzt nur Netze bis Kanal 11 anzeigt? Dann legt man unter Debian eine Datei in /etc/modprobe.d/ an. Wie die heißt, ist nicht so wichtig, bei mir heißt die wlan_EU.conf, auf .conf sollte sie wohl enden. Drin steht bei mir folgendes:

options cfg80211 ieee80211_regdom=EU

Eine Zeile, reicht aus. Die übergibt dem Kernelmodul cfg80211 beim Laden die passende Option und dann sind alle Kanäle sichtbar. An einigen Stellen im Weltnetz steht das “EU” noch in Anführungszeichen, also wenn’s ohne nicht klappt, dann vielleicht mit.

Xen: Debian Squeeze DomU in Debian Lenny Dom0

Aus der Reihe »Sonntag nachmittag für Frustrationstolerante« heute Folge 137 aus der Reihe »Virtualisierte Maschinen und freie Betriebssysteme«. Folgende Ausgangssituation: Server mit installiertem Debian Lenny als Xen Host (Dom0), es laufen diverse virtuelle Maschinen (DomU), unter anderem welche mit Debian Etch, eisfair-1, eisfair-2 und eben auch eine mit Debian Squeeze, dem aktuellen Testing-Zweig der Debian-Distribution. Bis auf die DomU mit eisfair-1 liefen alle virtuellen Maschinen bis dato mit dem Kernel 2.6.26-2-xen-686, der auch auf dem Host zum Einsatz kommt.

Vor einigen Tagen nun gab es in Debian Squeeze ein Update von udev 149 auf 150. Das Paket verweigerte dann aber die Installation mit dem Hinweis, dass der verwendete Kernel zu alt sei. Das war durchaus nervig, weil dadurch auch die Updates anderer Pakete nicht mehr eingespielt wurden, also hieß es: Kernel-Update.

Einfach mal schnell Kernel-Update gestaltete sich dann leider nicht so einfach. Debian hat Xen quasi aus der Distribution rausgeworfen bzw. bietet keine dedizierten Xen-Kernel mehr an. Gut, das ließ sich noch relativ problemlos lösen. Die Wahl fiel auf linux-image-2.6.30-bpo.2-686-bigmem von backports.org, denn dort heißt es:

This kernel also runs on a Xen hypervisor. It supports only unpriviledged (domU) operation.

Also fix den Kernel in der Dom0 installiert. DomU runtergefahren, Config angepasst, Kernelmodule ins Dateisystem der DomU kopiert, DomU gestartet und dann – nichts. Beim Hochfahren blieb die virtuelle Maschine einfach hängen, und zwar schon so früh im Bootprozess, dass ich keine Ahnung hatte, woran das lag.

Der nächste Schritt bestand dann darin eine weitere VM zum Testen aufzusetzen und die Suchmaschine der Wahl zu befragen. Ich weiß nicht, wo ich überall gelesen habe und was ich alles probiert habe. Am Ende funktionierte der Kernel, es waren nur Anpassungen an der Xen-Config notwendig, daher erstmal hier die Config und dann noch ein paar Kommentare dazu:

kernel  = '/boot/vmlinuz-2.6.30-bpo.2-686-bigmem'
ramdisk = '/boot/initrd.img-2.6.30-bpo.2-686-bigmem'
memory  = '128'
root    = '/dev/xvda1 ro'
disk    = [ 'phy:heaven/falbala_root,xvda1,w',
            'phy:heaven/falbala_swap,xvda2,w' ]
name    = 'falbala'
vif  = [ 'mac=00:16:3e:7d:4b:a2, bridge=eth0' ]
extra = 'xencons=hvc0 console=hvc0'
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

Wie man sieht, sind die Block-Devices, die in die VM gereicht werden, LVM Logical Volumes. Hier musste ich die Durchgereichten von /dev/sda* auf /dev/xvda* wechseln. Das hat definitiv mit dem verwendeten Kernel zu tun, der die Blockdevices nur noch dort ähm findet, oder so. Ich denke das war die entscheidende Änderung. In der mit »extra« beginnenden Zeile, habe ich die Angaben für die Xen-Konsole noch angepasst, irgendwo hatte ich gelesen, dass das jetzt hvc0 und nicht mehr xvc0 heißen muss. Die entsprechenden Änderungen an /etc/fstab und /etc/inittab innerhalb der virtuellen Maschine mussten natürlich auch noch vorgenommen werden, aber danach lief die DomU wieder und auch das Update von udev ließ sich problemlos einspielen. :-)

HowTo: Windows booten mit Debian und GRUB 2

Bei Debian wurde vor einigen Wochen das neue GRUB 2 in Debian Testing (Squeeze) gespült, das alte GRUB, welches das jetzt offiziell »GRUB Legacy« heißen soll, ablöst. Bei Ubuntu ist das übrigens auch für das nächste Release (Karmic) geplant, das in wenigen Tagen rauskommen wird. Wer diese Systeme als einzige auf einem 08/15-PC einsetzt, wird von dem Wechsel vermutlich kaum etwas mitbekommen.

Auf meinem neuen Netbook ist nun Windows XP Home vorinstalliert gewesen. Ich hab das mitbezahlen müssen und ich gebe zu, dass ich es draufgelassen habe, einfach um ab und zu nochmal Diablo II spielen zu können, ohne da im Linux große Verrenkungen anstellen zu müssen mit Installation, Spiele-3D-Grafik oder gar Wine. Nun ist es drauf und ich will es auch booten können. Der Installer von Debian Stable (Lenny) hatte das seinerzeit korrekt erkannt und in der Konfiguration von GRUB Legacy eingetragen.

Beim Upgrade auf GRUB 2 hat Debian diesen Eintrag nun schlichtweg ignoriert. Es hat auch keine neue Suche nach alternativen Betriebssystemen angestrengt, obwohl man vermutlich nur ein bisschen Code aus dem Installer hätte nutzen müssen. In der Liste der zum Boot möglichen Systeme tauchte Windows jedenfalls nicht auf.

Wie das nun bei dicken Rewrites so ist, die noch während des Beta-Stadiums ohne richtige Dokumentation auf die Nutzer losgelassen werden: man steht erstmal im Regen. Dazu kommt, dass der Distributor sich dann noch was ausdenkt, um das sauber in sein System zu integrieren. Bei der Suche, wo ich das nun eintragen müsste, hab ich dann folgendes herausgefunden:

Die neue Config-Datei von GRUB 2 ist /boot/grub/grub.cfg. Das erste was bei Debian drin steht:

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

Soviel Hilfe hätte ich gar nicht erwartet. In /etc/default/grub kann man zunächst mal ein paar Optionen für den Kernel zum Laden setzen. Sowas wie quiet oder vga=789 oder ähnliches. Die Syntax ist selbsterklärend.

In /etc/grub.d liegen dann verschiedene Skripte:

-rwxr-xr-x 1 root root 3223 12. Sep 18:08 00_header
-rwxr-xr-x 1 root root 1152 12. Sep 17:56 05_debian_theme
-rwxr-xr-x 1 root root 3221 10. Aug 19:49 10_linux
-rwxr-xr-x 1 root root 4418 12. Sep 18:08 30_os-prober
-rwxr-xr-x 1 root root  281  7. Okt 23:07 40_custom
-rw-r--r-- 1 root root  483 10. Aug 19:49 README

Die sollte man auch alle brav in Ruhe lassen, wenn man sich nicht wirklich gut mit Shell-Scripting auskennt. Allerdings ist 40_custom genau der richtige Ort für unseren Eintrag um Windows zu booten. Dieser Eintrag sieht dann ungefähr so aus, bzw. gleich mal die ganze Datei, damit das klar wird:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Windows XP" {
    set root=(hd0,2)
    chainloader +1
}

Auch dies ist nur ein Shell-Script, das irgendwann im Update-Prozess für die Konfigurationsdatei von GRUB 2 ausgeführt wird. Bei der Angabe der Partitionsnummer aufpassen, da gab es eine Verschiebung um +1 gegenüber GRUB Legacy. Jetzt also noch den abschließenden Debian-spezifischen Befehl ausführen, um die neue grub.cfg zu schreiben und schon kann man wieder Windows booten:

update-grub

Update: Seit dem Update von heute, 24.01.2010, erkennt Debian Squeeze die Windows-Installation wieder automatisch. D.h. man kann den Inhalt aus /etc/grub.d/40_custom wieder rausnehmen. Einmal update-grub aufrufen sollte danach genügen, um Einträge für Windows in die Liste zu zaubern.

Update: Die Option vga=789 ist übrigens keine gute Wahl mehr. Spätestens seit Kernel 2.6.32-3 ist KMS, also Kernel Based Mode Setting, aktiv und funktioniert auch und wenn man dann vga setzt, kommt man aus dem X nicht mehr per Strg+Alt+F2 auf die »normale« Konsole.

Einheitliches Verhalten des Compose Key unter Debian

Ich bin gerade dabei mein neues Netbook (Samsung NC10) einzurichten. Ein Problem, das ich auch schon beim alten Notebook hatte: das Verhalten des Compose Key, den ich übrigens gern auf Caps Lock lege, ist in Gnome bzw. GTK-Anwendungen nicht deckungsgleich mit anderen Anwendungen in X wie beispielsweise Qt-Anwendungen. Man findet dann im Netz häufig den Tipp, man müsse die Umgebungsvariable GTK_IM_MODULE="xim" setzen. Nur wird immer nicht so recht klar, wo genau. Ich hab die Zeile unter Debian Squeeze jetzt in $HOME/.xsessionrc eingetragen bzw. die Datei extra dafür angelegt. Das funktioniert jetzt so und beim nächsten Mal, wenn ich das Problem hab, schlage ich hier nach anstatt ewig zu probieren und zu suchen…

Nachtrag: Um die Frage aus den Kommentaren noch aufzugreifen, ich habe natürlich keine dedizierte Compose-Taste, so wie in der Wikipedia auf den Bildern zu sehen. Vielmehr kann man unter Linux andere Tasten mit dieser Funktion belegen. Ich verwende dazu die ansonsten nutzlose Taste Caps Lock. Die Verwendung des Compose Key ist dann simpel. Einmal Compose Key drücken und dann eine meist intuitive Sequenz von anderen Tasten danach. So gibt beispielsweise Compose + T + M das hier: ™. Praktisch ist das auch, wenn man oft ausländische Buchstaben hat. Das norwegische ‘ö’ gebe ich ein, indem ich Compose + / + o drücke: ø. Viele dieser Kombinationen sind wirklich intuitiv und man erreicht so auf einfache Weise eine große Vielzahl von Unicode-Zeichen, die man sonst nur schwierig einfügen kann. :-) Hier nun noch ein Foto von der deutschen Tastatur des Samsung NC10:

Keyboard Layout Samsung NC10

Automatische Keyword-Ersetzung mit Mercurial

In der Diskussion zu CRE130 über verteilte Versionsverwaltungssysteme kam die Frage auf, ob man Mercurial für die Bearbeitung von LaTeX-Files nutzen und dort dann vielleicht sogar eines der Pakete rcs, rcsinfo, rcs-multi, svn, svninfo, svn-multi oder vc verwenden kann. Ersteres ist kein Problem. Selbstverständlich kann man mit Mercurial seine LaTeX-Dokumente versionieren.

Die automatische Ersetzung von sogenannten Keywords, wie man das von RCS, CVS oder Subversion kennt, lässt sich bei Mercurial über die Erweiterung Keyword Extension realisieren, die bei Mercurial gleich dabei ist. Damit das möglicherweise mit einem der oben genannten LaTeX-Pakete zusammenspielt, beschreibe ich nun, wie man die Keywords denen von Subversion maximal ähnlich aussehen lässt.

Zunächst muss man die Erweiterung aktivieren. Das macht man am besten nicht global sondern einzeln im Repository, indem man im Repo in die Datei .hg/hgrc folgendes einfügt:

[extensions]
keyword =

Auf welche Dateien die automatische Ersetzung angewendet wird, bestimmt man in einem weiteren Abschnitt, hier z.B. für alle Dateien mit der Endung .txt in allen Unterordnern des Repositorys:

[keyword]
**.txt =

Die Ausgestaltung der Keywords kann man nun mit der Template Engine (in anderem Zusammenhang in Kapitel »Customizing the output of Mercurial« des großartigen Mecurial Buchs beschrieben) von Mercurial selbst vornehmen. Es gibt zwar default Keywords, aber in der .hg/hgrc definiert man die besser selbst. Meine aktuellen Einstellungen sehen wie folgt aus:

[keywordmaps]
Author = {author}
Date = {date|isodate}
Id = {file|basename} {rev}:{node|short} {date|isodate} {author|user}
Revision = {rev}:{node|short}

In einer Testdatei führt das dann zu folgendem Ergebnis bei der Ersetzung:

$Author: Alexander Dahl <alex@antiblau.de> $
$Date: 2009-08-13 10:43 +0200 $
$Id: bar.txt 1:986b794ecbb1 2009-08-13 10:43 +0200 alex $
$Revision: 1:986b794ecbb1 $

Um das dem Output von Subversion noch ähnlicher zu machen, könnte man den Teil für die Revision sogar noch auf {rev} abkürzen. Hier ist allerdings zu beachten, dass die Revisionsnummern von Mercurial nicht global eindeutig sind, sondern nur für das jeweilige Repository gelten.

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.

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!