middlemouse.contentLoadURL

auf false setzt.

Die Sicherheitshinweise von Debian selbst helfen auch nicht unbedingt weiter, da sie sich ja auf alle Pakete beziehen, nicht nur auf die für einen selbst relevanten.

Abhilfe kann ein Tool schaffen, welches täglich die installierten Pakete überprüft und eine Mail schickt, wenn Updates der Pakete verfügbar sind. Von diesen Tools gibt es im Debian-Repository (mindestens) zwei, nämlich apticron und das wesentlich umfangreichere cron-apt.

Um die Benachrichtigung umzusetzen, versuchte ich zunächst apticron. Dieses einzurichten ist sehr einfach: Nach der Installation des Paketes muss man nur in der Datei /etc/apticron/apticron.conf die E-Mail-Adresse eintragen, an die die Benachrichtigung gehen soll (standardmäßig ist root eingetragen), und schon wird man täglich benachrichtigt, falls es etwas zu installieren gibt:

EMAIL="adresse@host.de"

Unglücklicherweise scheint die aktuell in Etch vorhandene Version allerdings einen Bug zu haben, der dazu führt, dass auf virtuellen Servern apticron mit der folgenden Fehlermeldung abbricht:

RTNETLINK answers: Address family not supported by protocol
Dump terminated

Da ich apticron so nicht zum laufen gebracht habe, versuchte ich mein Glück mit cron-apt. Die Installation aus dem Package Repository geht wiederum ohne Probleme vor sich, und auch die Konfiguration ist relativ einfach: Standardmäßig aktualisiert cron-apt die Paketlisten mit apt-get und läd dann neue Pakete herunter, ohne diese aber schon zu installieren. Wenn man nach dem erfolgreichen Download eine Mail bekommen möchte, muss man in der Konfigurationsdatei nur zwei Einstellungen vornehmen bzw. einkommentieren:

MAILON="upgrade"
MAILTO="systemaccount"

Schon bekommt man bei vorliegenden Updates eine schöne Mail wie diese:

CRON-APT RUN [/etc/cron-apt/config]: Wed Feb 11 16:39:31 UTC 2009
CRON-APT ACTION: 3-download
CRON-APT LINE: /usr/bin/apt-get dist-upgrade -d -y -o APT::Get::Show-Upgraded=true
Reading package lists...
Building dependency tree...
The following packages will be upgraded:
abc def ghi jkl nmo
5 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/11.9MB of archives.
After unpacking 32.8kB of additional disk space will be used.
Download complete and in download only mode

Dann kann man sich schnell auf dem Server einloggen und die Updates einspielen, wobei dies auch sehr schnell geht, da der Download ja bereits stattgefunden hat.

Der Grund scheint irgendwo am Zusammenspiel von Eclipse und Klipper, dem KDE-Zwischenablage-Applet zu liegen, jedenfalls behebt das Beenden von Klipper den Fehler. Helfen soll auch das Deaktivieren der Option “Leere Zwischenablage vermeiden” in der Klipper-Einrichtung, das habe ich jetzt mal gemacht — mal sehen ob es hilft. Es würde mir jedenfalls etliche verlorene Nerven ersparen

ffmpeg -i video.wmv -vcodec flv -acodec mp3 video.flv

aufrufen kann. Die unter (K)Ubuntu aus dem Package Repository installierte Version von FFMpeg kennt aber — wegen Lizenzproblemen bei der MP3-Encodierung — den MP3-Codec nicht. Die Lösung, die ein Selbstkompilieren der FFMpeg-Quellen voraussetzt, dazu aber die FFMpeg-Quellen aus dem Ubuntu Package Repository nutzt, fand ich im MonsterWiki, die dort vorliegende Anleitung bezieht sich zwar auf Feisty Fawn, funktioniert aber unter Hardy Heron ebenso, mit dem einzigen Unterschied, dass das Paket libfaad2-dev inzwischen libfaad-dev heißt.

AUTH_REQUIRED=0

Nanu – was ist denn das, dachte ich so… Na klar soll sich der Nutzer authentisieren müssen, bevor er Mails rausschickt! Also schwupps auf 1 geändert und den Courier neu gestartet. Testen – ja, Mails versenden geht noch. Heute habe ich mich dann gewundert, dass seit gestern abend gar keine Mails mehr angekommen sind… Der Grund war schnell gefunden: Auch der fremde Mail-Server wurde von Courier brav um Authentisierung gebeten, die dieser natürlich nicht leisten konnte :-S

Also habe ich heute die Geschichte schleunigst wieder rückgängig gemacht. Das, was ich eigentlich damit verhindern wollte, nämlich dass irgendjemand fremdes einfach über meinen SMTP-Port irgendwelche Mails an andere Leute schickt, verhindert Courier nämlich schon von ganz alleine… Tja, schön blöd, wenn man sich so seine eigene Grube gräbt.

Nun ging es nur noch darum, herauszufinden, ob an dieser Blockade irgendwelche wichtigen Mails gescheitert waren. Da half mir dann das relativ extensive Logging von Courier weiter:

cat /var/log/mail.err | grep meine@addres.se

Da noch die Nicht-Spam-Mails aussortieren, et voilá!

Grundsätzlich war das Upgrade halbwegs problemlos: Neue Paketquellen in /etc/apt/sources.list eintragen und die alten löschen bzw. auskommentieren, und dann:

apt-get update
apt-get dist-upgrade

…und dann nur warten und alle möglichen Konfigurationsfragen beantworten.

Für mich überraschenderweise funktionierte sofort fast alles: Lediglich das PHP5-Paket musste ich komplett deinstallieren, den Paket-Cache löschen und neu installieren, da die Version aus dem Dritt-Repository eine höhere Versionsnummer hatte als die aus dem Etch-Repository, aber nicht kompatibel zur neu installierten Apache-Version war.

Ein weiterer seltsamer Fehler trat noch mit dem Courier Mailserver auf: Irgendwie wollte er zunächst keine Mails empfangen… Aber mit einem

makehosteddomains
makealiases
makeacceptmailfor
/etc/init.d/courier-mta restart

waren auch diese Probleme gegessen… Vielleicht waren einfach die Daten-Dateien für hosteddomains, aliases und acceptmailfor nicht korrekt gewesen, aber who cares…

apt-get install courier-imap-ssl

Bei der Installation wird bereits fast alles so eingerichtet, wie es sein muss, dazu erzeugt sich Courier-IMAP-SSL ein selbstsigniertes Zertifikat. Als nächstes kann man dann einfopenssl genrsa -des3 -out ca.key 2048
openssl req -new -x509 -days 3650 -key ca.key -out ca.crtach z.B. mit Thunderbird bzw. Icedove versuchen, auf den verschlüsselten Mail-Account zuzugreifen (indem man einfach in den Konteneinstellungen das Häkchen bei “SSL” setzt):

Beim Abrufen von neuer Mail kommen daraufhin aber zwei Fehlermeldungen:

• Das Zertifikat kommt nicht von einer gültigen Zertifizierungsstelle (klar, Courier hat es ja auch selbst signiert).
• Das Zertifikat ist nicht auf den Namen des Mailservers, z.B. mail.example.org, sondern auf localhost ausgestellt.

Also brauchen wir ein neues Zertifikat, am besten von einer “echten” Zertifizierungsstelle. Thawte, Verisign & co. verlangen heftige Preise für ihre Zertifikate, aber es gibt auch Alternativen wie cacert.org. Hier kann man sich ziemlich leicht selber Zertifikate ausstellen lassen, die auch nichts kosten. Leider ist auch hier das Root-Zertifikat nicht automatisch in Thunderbird/Icedove installiert, man muss es zunächst von cacert.org herunterladen und über Einstellungen -> Erweitert -> Zertifikate -> Zertifikate importieren.

Nachdem man sich bei CACert angemeldet hat und seine Domain hinzugefügt hat (dazu muss auch die E-Mail-Adresse überprüft werden), kann man ein Zertifikat erstellen. Dazu benötigt man ein sogenanntes “Certificate Signing Request”, also eine Anforderung zum signieren des eigenen Schlüssels. Dieses lässt sich auf dem Server wie folgt erzeugen:

openssl genrsa -out courier.key 2048
openssl req -new -key courier.key -out courier.csr

Bei dem zweiten Befehl kann man für ein CACert-Zertifikat alles außer Common Name freilassen, bei letzterem muss der Name des Servers eingetragen werden, also z.B. mail.example.org (auch wenn das “YOUR name”, was OpenSSL einem anzeigt, etwas irreführend ist…).

Das in courier.csr gespeicherte CSR kann man jetzt bei CACert eingeben und erhält sein Zertifikat als Textblock. Diesen speichert man auf dem Server in die Datei courier.crt und führt noch folgende Befehle aus:

cat courier.key courier.crt > courier.pem
openssl gendh >> courier.pem

Anschließend muss noch die Datei courier.pem an die richtige Stelle kopiert werden und Courier neu gestartet werden:

cp courier.pem /etc/courier/imapd.pem
chmod 0600 /etc/courier/imapd.pem
/etc/init.d/courier-imap-ssl restart

Beim nächsten Abrufen von Mails sollten danach keine Warnungen mehr auftreten, und die Mails werden verschlüsselt bis zum Server geschickt.

Bisher bin ich ganz zufrieden mit dem System, insbesondere läuft Firefox aus irgendeinem Grunde schneller als das Debian-Pendant Iceweasel. Nervend war nur der standardmäßig installierte Firefox 3 Beta, der keine meiner Extensions akzeptierte. Zwar ist mir klar, dass man die Extensions mit ein paar Tricks dazu zwingen kann, auch unter FF3 zu arbeiten, aber das war mir zu viel Aufwand, und so habe ich den FF2 aus dem Repository installiert.

Mit etwas Aufwand ließ sich auch KDE dazu bewegen, eine etwas weniger Platz beanspruchende Kontrollleiste (essenzielle Anforderung auf einem 1024×768-Notebookdisplay) anzuzeigen, wobei ich nach wie vor der Meinung bin, dass in Punkto “Screen Real Estate” Gnome die Nase vorn hat. Da mir ansonsten aber so gut wie alle KDE-Programme besser gefallen als ihre Gnome-Entsprechungen (Debian lief bei mir unter Gnome) habe ich mich wieder für die KDE-Oberfläche mit Kubuntu entschieden.

Was Hardware-Unterstützung angeht, ist (K)ubuntu natürlich wesentlich benutzerfreundlicher als Debian. Für meine IPW2200-WLAN-Hardware muss ich nicht erst selbst Firmware herunterladen, sondern diese ist schon auf der Installations-CD mit dabei, somit musste ich mein Netzwerkkabel für die Installation nicht einmal verwenden. Glücklicherweise hatte ich mein WLAN-Aktivierungs-Programm vorher gesichert, womit das auch nicht zu einem Problem wurde.

Der eigentliche Moment der Wahrheit wird aber wohl in einem halben Jahr kommen, wenn die nächste Distribution von Kubuntu vorliegt. Bei den bisherigen dist-upgrades war bei mir immer irgendetwas schief gegangen, so dass eine komplette Neuinstallation nötig war – ein Grund für meinen Wechsel zu Debian. Inzwischen aber soll sich der Upgrade-Prozess bei (K)ubuntu ja wesentlich verbessert haben, und so bin ich mal gespannt auf meine Erfahrungen mit der neuen Version.