Wir betreiben neben Ironport für die zentralen Mailserver noch eine weitere Anti-Spam- und Anti-Viren-Infrastruktur als „Altlast“ für Institute, die keinen LDAP-Server betreiben. Dort wird als Anti-Virus-Software seit vielen Jahren ClamAV und Sophos Antivirus eingesetzt. Für Letzteres musste jetzt ein Update installiert werden, weil die alte Version demnächst nicht mehr unterstützt wird. Sophos wird bei uns mit dem Perl-Modul SAVI-Perl in amavisd-new eingebunden. Das ging nach dem Update zunächst nicht mehr, obwohl ich das Modul gegen die neue Sophosversion gebaut hatte. Die Ursache ist, dass sich der Pfad der .vdl- und .ide-Dateien geändert hat. Zwar kann man SAVI-Perl beim Kommando load_data diesen Pfad übergeben, aber (unsere Version von) amavisd-new unterstützt das nicht. Die einfachste Lösung war deshalb ein symbolischer Link vom aktuellen Pfad /opt/sophos/lib/sav auf den bisherigen Pfad /opt/sophos/sav.
Kategorie: Perl
Tips und Tricks zur Programmiersprache Perl
Probleme mit Unicode bei OTRS-Update beseitigen
Nach einem Update auf die OTRS-Version 2.3.4 war die Administrationsseite unseres OTRS (a.k.a. SysConfig) nicht mehr erreichbar. Es stellte sich heraus, dass diese wohl gegen den Einsatz von Unicode, also UTF-8 rebellierte, eine temporäre Umstellung auf Latin-1 förderte die Adminseite wieder ans Tageslicht. Weitere Nachforschungen ergaben, dass ein Auskommentieren des ConfigCaches in der Datei /opt/otrs/Kernel/System/Config.pm auch wieder UTF-8 ermöglichte. Das System wurde hierdurch jedoch verlangsamt. Die optimale Lösung liegt wohl darin, alle Dateien, die mit „SysConfig“ beginnen, unterhalb von /opt/otrs/var/tmp zu löschen und OTRS sowie den dazugehörigen Apache neuzustarten. Dabei wird der Cache dann mit der korrekten Codierung reinitialisiert.
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.