Nach dem Upload von Dateien, die Umlaute im Dateinamen enthalten, liefert Django folgenden Fehler:

[Sat Mar 26 22:18:53 2011] [error] [client x.x.x.x] UnicodeEncodeError: ’ascii’ codec can’t encode character u’\\xf6′ in position 17: ordinal not in range(128)

Ursache hierfür ist, dass der Dateiname Umlaute enthält, die mit UTF-8 encodiert sind – Python bzw. Django allerdings kein UTF-8 verarbeiten will.

Apache2 wird unter Debian standardmäßig mit “LANG=C” gestartet – er berücksichtigt also keinerlei Locales.

Um UTF-8 auch im Dateisystem verarbeiten zu können (os.path() o.ä.), muss dem Apache die korrekte Locale mitgeteilt werden.

Falls noch nicht geschehen, muss das Paket “locales” installiert werden:

aptitude install locales

Nun die nötige Änderung in der Datei /etc/apache2/envvars vornehmen:

## The locale used by some modules like mod_dav
export LANG=C
## Uncomment the following line to use the system default locale instead:
. /etc/default/locale

(Entfernen des Kommentarzeichens in der letzten hier aufgeführten Zeile)

Die genannte Datei /etc/default/locale wird über folgenden Befehl konfiguriert:

dpkg-reconfigure locales

Hier muss darauf geachtet werden, dass Locales mit UTF-8 selektiert werden – und in der zweiten Auswahl eine entsprechende als Standard gesetzt wird. Zu empfehlen ist entweder en_US.UTF-8 oder de_DE.UTF-8.

Somit befindet sich in der Datei /etc/default/locale beispielsweise folgender Inhalt:

# File generated by update-locale
LANG=de_DE.UTF-8

Nach dem Neustart des Apache sollte Python respektive die Django-Anwendung nun auch Dateien mit UTF-8-Umlauten verarbeiten können.

Die von uns eingesetzt Version 3.3.2 von Confixx zeigte gestern einige Fehler, die anfangs unerklärlich waren.

Das Hinzufügen von Umlaut-Domains zu einem Kunden-Account war nicht möglich. Confixx entfernte den Umlaut vor der Umwandlung zu Punycode, weshalb der Domain-Name nicht konvertiert wurde. Aus “müller.de” wurde “mller.de”, was natürlich keine IDN-Domain mehr darstellt.

Nach Durchsicht des Quellcodes und einigem Debugging zeigte sich, dass die Umlaute durch die Funktion “escapeshellarg()” entfernt werden.

Nach Beiträgen auf drupal.org bzw. im PHP-Handbuch tritt der Fehler genau dann auf, wenn die verwendete Locale am Server kein UTF-8 kann.

Der Apache wird bei Debian Lenny fix auf “LANG=C” festgesetzt, was genau die Ursache zu sein scheint: mit Debian Etch wurden UTF8-Encodierungen als gültige Zeichen der Shell erkannt, mit Debian Lenny nicht mehr.

Abhilfe schafft der Aufruf von “setlocale()” direkt im PHP-Code, hier in die “idn-functions.php” eingefügt, da nur für IDN-Domains benötigt:

setlocale(LC_ALL, "de_DE.UTF-8");

Nun werden die Umlaute nicht mehr aus dem Domain-Namen entfernt, und die Konvertierung nach Punycode funktioniert.

Liebe Confixx-Entwickler, falls ihr das hier lesen solltet: Es gibt tolle PEAR-Module für IDN-Unterstützung, dann muss nicht extra ein externes Perl-Skript aufgerufen werden, nur um einen Domain-Namen zu konvertieren.

Da Debian Lenny bereits seit längerem Stable ist, und die Tests intern problemlos verliefen, beginnen wir derzeit mit dem Upgrade aller eigenen und der durch uns betreuten Hosting-Systeme.

Probleme gab es bisher wenige, auf überschriebene Config-Dateien oder ähnliches waren wir dank der Tests bereits vorbereitet, so dass die Änderungen sofort wieder zurückgenommen werden konnten.

Lediglich Confixx zickte etwas: Das Update-Script, das Änderungen im Webinterface effektiv in das System überträgt, basiert auf einem verschlüsseltem Perl-Code. Das Filter-Modul, um das Skript aufrufen zu können, machte jedoch in der von uns eingesetzten Confixx-Version 3.3.2 Probleme. Die Installation des Moduls aus Confixx 3.3.4 brachte Abhilfe.

Auf einem Kunden-System kam es zu komplett unerwarteten Problemen: Debian Lenny bringt keine Unterstützung für Apache1 und – hier Grund gewesen – PHP4 mit. Da der Server bereits seit längerem läuft, und der Kunde die Hosting-Accounts nur zögerlich auf PHP5 migriert hat, musste schnell Abhilfe geschaffen werden. Der Versuch, das vorhandene PHP4-Paket aus Etch neu für Lenny zu übersetzen, scheiterte. In Rücksprache mit dem Kunden haben wir dann den gesamten Server auf PHP5 umgestellt, die Sicht-Überprüfung der Webseiten zeigte keine Fehler. Bisher kam es auch zu keinen Beschwerden.

Wann unsere Hosting-Systeme Mars und Venus migriert werden, steht noch nicht fest – wir werden alle Kunden aber in einer Rundmail über die Wartungsarbeiten informieren.

Seit dem 14. Februar 2009 (Valentinstag – Zufall?) ist Debian in Version 5.0 (Codename “Lenny”) stabil.

Was gibt es neues?

Für uns – wenig: neuere Versionen von Apache, PHP, MySQL, dabei aber keine großen Versionssprünge. Lediglich mit XEN 3.2 gibt es größere Neuerungen (Virtualisierung von Windows ist nun direkt möglich).

Die Umstellung lief auf dem Test-System relativ problemlos, wenn man von Konfigurations-Problemen mit Postfix und Freeradius absieht – hier war Handarbeit notwendig.

Wichtig ist auch die Reihenfolge des Upgrades: Während bei Etch nach dem Anpassen der sources.list ein “aptitude update && aptitude upgrade && aptitude dist-upgrade” reichte, sollte man beim Wechsel auf Lenny etwas anders vorgehen (siehe MDlog/sysadmin):

1. Anpassen der sources.list:

   sed -i 's/etch/lenny/g' /etc/apt/sources.list

2. Update der Paketlisten:

   aptitude update

3. Upgrade der Paketverwaltungs-Programme auf Lenny:

   aptitude install apt dpkg aptitude

4. Nun das Upgrade von etch nach Lenny:

   aptitude full-upgrade

Wird der 3. Schritt nicht durchgeführt, versucht aptitude von Etch, die Abhängigkeiten zu lösen – und scheitert daran.

Statt “dist-upgrade” wird nun “full-upgrade” verwendet, was der Funktionalität aber keinen Abbruch tut.

Im Zuge der Einführung von mod_itk auf unseren internen Systemen haben wir einen direkten Vergleich “suPHP gegen mod_itk mit mod_php” durchgeführt.

Das Tool “Apache Benchmark” hat dabei auf die gleiche Webseite (Output von phpinfo()) jeweils 1.000 Anfragen durchgeführt – die Ergebnisse sprechen für sich:

• suPHP:

  Requests per second:    22.25 [#/sec] (mean)
  Time per request:       44.938 [ms] (mean)

• mod_itk mit mod_php:

  Requests per second:    45.77 [#/sec] (mean)
  Time per request:       21.850 [ms] (mean)

Das heißt, dass mit suPHP pro Sekunde ca. 22 Anfragen möglich waren, bei mod_php jedoch 45. Die Zeit pro Anfrage war bei mod_php halb so lang, wie bei suPHP.

Wir versprechen uns somit von dem Wechsel auf mod_itk eine deutliche Steigerung der Performance.

Dies ist nicht der einzige Vorteil – mod_itk bietet weiteres:

Da die gesamte Anfrage in andere Benutzerrechte verschoben wird, gelten diese Rechte auch für andere Webserver-Module, nicht nur PHP. Konkret bedeutet dies, dass mod_python genauso von der Sicherheit einzustufen ist wie PHP.

Weiter testen wir derzeit noch den Einsatz von WebDAV: über WebDAV lassen sich Inhalte auf den Servern, die bisher nur via FTP erreichbar waren, genauso verwalten – nur erfolgt der Down- und Upload aller Daten über HTTP, bzw. sogar verschlüsselt über HTTPS – und ist damit über so gut wie jeden Proxyserver erreichbar, was bei FTP nicht immer möglich ist.

Wie bekannt, setzen wir derzeit auf den Webhosting-Servern ausschließlich suPHP, und nicht mod_php ein, um die Sicherheit der einzelnen Kundenwebseiten – und der gesamten Systeme – zu verbessern. Ohne suPHP wären Angriffe auf einzelne Kundenwebseiten deutlich weitgreifender gewesen, und hätten auch andere Kundenseiten beeinträchtigen können.

Leider bringen diese Sicherheitsvorteile auch Nachteile mit sich: Da PHP bei jeder Anfrage neu gestartet wird, kostet dies sehr viel Zeit – die Requests werden langsamer abgearbeitet, bei vielen Zugriffen steigt die Serverlast deutlich an.

Abhilfe soll hier mod_itk schaffen: Dieser setzt nicht bei PHP an, sondern direkt im Webserver. Jeder ankommende Request wird entgegengenommen, und je nach Ziel-Domain sofort in eine andere Rechteumgebung (konkret: Die Benutzerrechte des FTP-Users) gebracht. Erst danach wird der Request weiter bearbeitet. Statt suPHP verwenden wir nun mod_php, da dieses dauerhaft im Speicher geladen ist. Anfragen werden nun unter den korrekten Rechten bearbeitet, unabhängig der verwendeten Programmiersprache oder ähnlichem, wie bei suPHP, jedoch mit der Performance von mod_php. Der einzige Nachteil an der Sache: Auch Anfragen an Bilder, CSS-Dateien oder ähnlichem, die vom Apache direkt verarbeitet werden, müssen in der Rechteumgebung geändert werden. Der Performanceverlust wird auf unseren internen Systemen derzeit genauer untersucht, wird sich jedoch vermutlich nicht auf die allgemeine Einführung auswirken.

Wir werden informieren, wenn die Tests abgeschlossen sind, und mod_itk allgemein eingeführt wurde!

Eine Bitte an alle Kunden:

Wenn eine Subdomain nicht mehr benötigt wird, nicht nur das Verzeichnis via FTP löschen, sondern auch die entsprechende Subdomain im Confixx.

Wenn dieser Eintrag nicht entfernt wird, meldet der Webserver bei jedem Reload eine Warnung, dass ein Verzeichnis nicht existiert.

Vielen Dank!

Am gestrigen Dienstag, den 18.12.2007, kam es von 06:30 bis 11:45 zu einer Störung des Webservers auf unserem Hosting-System Venus.

Grund hierfür war eine Konfigurationsänderung, die fehlerhaft vom System interpretiert wurde. Nach dem täglichen Neustart gegen 06:30 verweigert der Apache-Webserver (zuständig für die Erreichbarkeit Ihrer Webseiten) den Start, es waren somit keine Webseiten abrufbar.

Die Änderung am Webserver war notwendig, da ein Fake-Bot (Automatisiertes Programm), das auf Webseiten eMail-Adressen u.ä. gesammelt hat, große Mengen an Datentransfer auf einigen Kundenwebseiten erzeugt hat. Durch das Auslesen des übermittelten User-Agents verbieten wir nun diesem Bot den Zugriff auf die Webseiten.

Durch eine Verkettung unglücklicher Umstände dauerte der Ausfall des Webservers länger, als uns lieb ist.

Gegen 06:30 fiel auf Venus der Webserver Apache aus noch ungeklärten Umständen aus. Das Monitoring, das in diesem Fall die Mitarbeiter benachrichtigen sollte, konnte aber nicht aktiv werden, da auf Mars die Festplatte durch Logfiles vollgeschrieben war. Aus dem gleichen Grund wurden dann auch Webseiten auf Mars nicht mehr angezeigt, da der Webserver keine temporären Dateien mehr schreiben konnte.

Maßnahmen, um diesen Fall zu vermeiden, sind in Vorbereitung und werden Anfang August umgesetzt.

Am heutigen 08.April 2007 wurde der Nachfolger von Debian Sarge veröffentlicht. Die neue “stable”-Version des Debian-Projektes hört auf den Namen Etch und ist ab sofort auf CD/DVD verfügbar (vorzugsweise via BitTorrent).

Im Zuge der neuen Debian-Version werden wir ebenfalls Upgrades der Systeme durchführen, was auch für Sie als Kunden Vorteile bringen wird.

So gehört neben der neuen Apache 2.2.3-Version auch PHP 5.2.0 zu den Paketen. Der MySQL-Server ist in Version 5.0.32 verfügbar, Perl in Version 5.8.8. Das von uns eingesetzte suPHP gibt es in der neuesten Version 0.6.2.

Da es bei so großen Umstellungen immer zu Problemen kann, werden wir alle Kunden via Kundenrundschreiben über die Änderungen informieren und dann auch einen genauen Termin bekannt geben. Wir erwarten jedoch keine großen Schwierigkeiten, in den von uns genutzten Test-Umgebungen ist Etch bereits seit längerem problemlos im Einsatz, PHP5 verwenden wir bereits seit längerem auf allen Servern, was bisher nur geringfügige Änderungen nötig machte.

Sehr geehrte Kunden,

Nachdem am 28.7.06 eine Lücke in den Apache-Webservern entdeckt und behoben wurde, haben wir nun die heute veröffentlichten Pakete für Debian eingespielt.

Durch das Upgrade kam es zu einem Ausfall der Webseiten von ca. 3 Minuten.