Perl und Unicode

Obwohl ich eigentlich ganz gut verstehe, wie Unicode in seinen verschiedenen Ausprägungen funktioniert, war mir (und ist zum Teil noch) ein Rätsel, wie Perl damit umgeht. In der Vergangenheit hatte ich vornehmlich das Problem, dass Skripte obskure Unicode-Fehlermeldungen an Stellen produzierten, an denen ich garantiert nicht mit Unicode arbeiten wollte. Ursache ist die Verwendung eines Unicode-Locales unter Linux, z.B. das bei uns standardmäßig eingesetzte „de_DE.UTF-8“. Dafür benutze ich seit einiger Zeit diesen Quickfix:

if (defined $ENV{"LANG"}) {
exec 'env', 'LANG=C', $0, @ARGV unless $ENV{"LANG"} eq "C";
}

Damit wird das Skript garantiert im Locale „C“ ausgeführt.

Jetzt hatte ich zum ersten Mal eine Situation, in der ich wirklich Unicode benutzen wollte. Es ging darum, Umlaute im Input in die Umschreibung „ae“ etc. umzuwandeln. Mein erster Versuch dafür war grundsätzlich richtig:

$input =~ s/ä/ae/g;

Das funktionierte aber nicht, d.h. die Umlaute blieben erhalten. Nach etwas Suchen habe ich gefunden, dass man das Pragma utf8 setzen muss, wenn solche Zeichen im Skripttext auftauchen. So funktioniert es also:

use utf8;

$input =~ s/ä/ae/g;

NB: das setzt voraus, dass das Skript mit einem UTF8-fähigen Editor geschrieben und gespeichert ist.

Phishers Fritz

… fängt frische Phishe.

Derzeit sind wieder Phishing-Mails im Umlauf, die gezielt Passwörter von Nutzern der Uni Köln abphishen wollen. Hintergrund ist, dass mit Hilfe der Passwörter Spamkampagnen geskriptet über das Webmail-System der Uni gefahren werden können. Das ist kürzlich bereits einmal gelungen. Wir haben das Problem recht schnell erkannt und den geknackten Account temporär gesperrt, aber die Gefahr ist damit nicht grundsätzlich gebannt. Und es beweist, dass es immer wieder leichtgläubige Opfer gibt. Ein einziges reicht ja schon, um potenziell viel Schaden anzurichten.

Das größte Problem bei solchen Spam-Wellen ist aus unserer Sicht, dass die Reputation der Uni sinkt – sowohl die reale als auch die virtuelle. Mit Letzterem meine ich, dass Mailserver der Provider nur noch gedrosselt von uns Mail annehmen, bzw. wir im schlimmsten Fall auf sog. Blacklists landen und gar keine Mail mehr von uns angenommen wird. Beides ist in der Vergangenheit schon vorgekommen.

Fehler in Gnome bei Aufruf eines Webservers

Mir ist im Rahmen der Arbeit mit dem Modul “webserver” von Python aufgefallen, dass Gnome bzw. GTK einen kleinen Fehler aufweist. Beim Aufruf einer URL erscheint nämlich ggf. die Nachricht “Error: Failed to send command: 500 command not parseable” auf stderr. Der folgende Aufruf behebt das Problem (für Firefox als Webbrowser, eine Zeile):

gconftool –set /desktop/gnome/url-handlers/http/command
–type=string ‘firefox -remote openurl('/%s,new-tab')’

Ob der Fehler überhaupt existiert, kann mit folgendem Befehl geprüft werden:

gconftool –get /desktop/gnome/url-handlers/http/command

Wenn bei der Ausgabe die “openurl” Option in Anführungsstrichen steht, existiert der Fehler.

Die Kontrolle nochmal mit Python und dem subprocess-Modul:

>>> import subprocess
>>> p1 = subprocess.Popen([“gconftool”,”–get”,
”/desktop/gnome/url-handlers/http/command”],stdout=subprocess.PIPE)
>>> p1.communicate()[0]
‘firefox -remote “openurl('/%s,new-tab')”n’

Das Geheimnis der Semaphoren

Nein, hier geht es nicht etwa um die Hüter des schringseldingselnden Donnerwutzes aus Harry Potter, sondern um Datenstrukturen zur Prozesssynchronisation, die mich auf unseren Linuxservern schonmal des öfteren ärgern. Wenn beispielsweise Apacheprozesse mit einem “Segmentation fault” abrauchen oder mit der Meldung “no space left on device” die Arbeit verweigern, obwohl die Platte mehr als genug Platz bietet, sind nicht selten die Semaphoren daran schuld (wer nicht weiß, was Semaphoren sind: http://de.wikipedia.org/wiki/Semaphor_%28Informatik%29).

Nun gibt es zwei Wege, sich zu behelfen, wenn einem die Semaphoren ausgehen: Die Anzahl der Semaphoren erhöhen oder die bestehenden abschießen.

Die Anzahl der Semaphoren erfährt man im (virtuellen) proc-Dateisystem unter “/proc/sys/kernel/sem”. Die 4 Zahlen repräsentieren die Kernelparameter SEMMSL, SEMMNS, SEMOPM, SEMMNI (Google kennt die Bedeutung ;) ).

Die folgende Einstellung hat uns wesentlich mehr Ruhe vor diesen Plagegeistern verschafft:

sysctl -w kernel.sem=”1000 96000 128 500″

Zum Abschießen hat sich bei uns ein kleines Shellskript bewährt, das vor allem darauf achtet, keine Semaphoren des Users “root” zu erwischen, was unangenehme Folgen haben könnte (ohnehin übernehme ich für die Tipps keine Garantie in Bezug auf unerwünschte Nebenwirkungen!):

#!/bin/bash
sem=`sudo ipcs -s | grep -v root | grep 0×00 | cut -d’ ‘ -f2`
for i in $sem; do sudo ipcrm sem $i; done

Ein weiterer Beitrag zum Thema: http://www.cryptronic.de/wiki/Blogs/20070211_vserver_und_semaphores