von Sara Veröffentlicht in Allgemein, Fachchinesisch

Seit langer, langer, langer Zeit setzen wir eine stark modifizierte und angepasste Version von Apache 1.3 auf unseren Webservern ein. In der Praxis hat sich daher bis jetzt ein Umstieg auf Apache 2 nicht ergeben, da der spürbare Nutzwert für Kunden in SharedHosting-Umgebungen gering gewesen wäre aber der Aufwand für diese Umstellung (eben aufgrund des hohen Anpassungsgrades an unsere eigenen Anforderungen) ganz erheblich ist. Immerhin müssen auch nach einem solchen Update viele hundertausend Webseiten auf mehreren tausend Servern einwandfrei laufen. Dabei war “unser” Apache 1.3 auch keineswegs veraltet, sondern wurde laufend gepflegt, weiter optimiert und angepasst.

Selbstverständlich war klar, dass der Schritt hin zu Apache 2 irgendwann erfolgen muss – und zwar dann, wenn lange genug Erfahrungen vorliegen, um die Nutzung für SharedHosting bei uns rechtfertigen zu können.

Inzwischen ist es nun auch nach langen interne Vorarbeiten, umfangreichen Entwicklungen, umfassenden Tests und den nötigen Anpassungen soweit und wir sind dabei, alle Webserver auf Apache 2.2.16 zu aktualisieren.  Dazu einige Informationen von unserer Technik:

Die Umstellung wird in drei Schritten erfolgen:

  • 1. Schritt: Montag,   den  9.8.10 Webslave 1-200
  • 2. Schritt: Dienstag, den 10.8.10 die restlichen Shared-Webslaves
  • 3. Schritt: Mittwoch, den 11.8.10 alle ManagedServer

Das Update sollte für den Kunden keinerlei Auswirkungen haben, wobei im Einzelfall kleinere Probleme aufgrund ganz spezifischer Konfigurationen (.htacess) o.ä. nicht 100%ig auszuschließen sind, zumal Apache 1.3 Fehler in .htacess-Dateien teilweise ignoriert hat, was in der neuen Apache-Version nicht mehr der Fall ist. Durch umfangreiche Tests und Vorarbeiten sowie Anpassungen haben wir dem jedoch so gut wie möglich entgegen gewirkt. So funktionieren bei “unserem” Apache 2.2 z.B. AuthDigistFile und AuthUserFile, was normalerweise nicht der Fall ist.

Sofern Kunden nach der Umstellung einen “Internal Server Error” erhalten, mögen diese sich bitte bei unserem Kundenservice bzw. direkt bei der Technik melden. Wir helfen dann gerne weiter.

Während dem Update muss der Webserver neugestartet werden was zu einem kurzen Ausfall von wenigen Sekunden führen wird.

Einen Sonderfall beim vielgenutzten Modul “mod_rewrite” um URLs automatisch zu verändern gibt es leider. So ist folgende Regel syntaktisch falsch und funktioniert beim Apache 2.2 so nicht mehr (Umleitungsfehler):

RewriteCond %{HTTP_HOST} ^!www\. [NC]
RewriteRule (.*) http://www.domain.tld$1

Richtig ist:

RewriteCond %{HTTP_HOST} ^!www\. [NC]
RewriteRule (.*) http://www.domain.tld/$1

Dieses Verhalten ist teilweise unter bestimmten vorraussetzungen beim Apache 1.3 auch schon so.

Die Vorteile von Apache 2.2 gegenüber dem bisherigen 1.3 sind nun und nach den Anpassungen für unsere Zwecke:

  • Performancegewinn auch in SharedHosting-Umgebungen
  • Vorteile im Bereich der Serversicherheit
  • Apache 1.3 hat “End-Of-Live” erreicht und wird nicht mehr weiterentwickelt. Es wäre daher eine Sackgasse gewesen, nun nicht umzustellen.
  • Neues Modul “mod_deflate“ (DER Dauerbrenner bei unseren Kunden :-) )
  • viele neue Funktionen auf Serverebene
  • IPv6 Unterstützung für die Zukunft (auch hier gibt es intern bereits Tests)

Selbstverständlich informieren wir alle Kunden per E-Mail über die Umstellung.

Danke, Apache 1.3 für die vielen Jahre der guten Zusammenarbeit. Und Welcome!, Apache 2 – mögest Du uns und unseren Kunden ebenso gute Dienste leisten, wie Dein Vorgänger.

[Update 2010-07-30 10:08 Uhr]

Die Option “FancyIndexing On” wird durch Apache 2 bei Directory-Listings nicht mehr unterstützt. Es kommt daher in solchen Fällen die folgende Fehlermeldung: “The FancyIndexing directive is no longer supported. Use IndexOptions FancyIndexing.”

In .htacess-Dateien ist diesbezüglich eine Änderung erforderlich:

FancyIndexing On

ersetzen durch

IndexOptions FancyIndexing

Und noch ein Tipp unserer Technik:

Das eigentlich wichtigste, wie sich die Kunden selbst helfen können ist: Auf alle Fälle bei Fehlern in den CGI-Debugger unter http://IHRE-DOMAIN/system-cgi/cgi-debug/ schauen. Apache 2.2 hat ausführliche Fehlermeldungen, weshalb man sofort sieht was den Skriptfehler verursacht.