Neuer Indianer – Oder: Willkommen, Apache 2.2! [Update]

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.

End of article

Sara Marburg

Über den Autor

Sara Marburg

Geschäftsführung (bis 11/13)

24 Kommentare


  • Peter
    Peter - 30. Juli 2010 um 09:35 Uhr

    Krass! Da bin ich ja mal gespannt 🙂

  • Sascha Schoppengerd
    Sascha Schoppengerd - 30. Juli 2010 um 09:41 Uhr

    Super! Freut mich, dass Ihr die Server aktualisiert. Nur warum kommen die ManagedServer zum Schluß dran?

  • Alex Haupt
    Alex Haupt - 30. Juli 2010 um 09:49 Uhr

    Freut mich! Haben schon längere Zeit auf unserem Managed Server für diverse Projekte und insbesonders für SVN einen 2er Indianer am laufen. Werden die nötigen Module aus der mod_dav-Reihe für SVN auch standardmässig aktiviert werden oder kann man auf Wunsch diese von der Technik nachträglich installieren lassen?

  • Sara
    Sara - 30. Juli 2010 um 10:13 Uhr

    Sascha Schoppengerd: Warum nicht? 🙂 So gesehen ist das für ManagedServer-Kunden die beste Option, weil die Kompatibilität durch die vorherigen Umstellungen bei mehreren hundertausend Webseiten bestätigt worden ist.

    Alex Haupt: Kläre ich ab und melde mich dann nochmals.

  • Dominik Pesch
    Dominik Pesch - 30. Juli 2010 um 10:40 Uhr

    Klasse! Das freut uns wirklich sehr. Insbesondere mod_deflate wird herzlichst erwartet.

    Wie schaut das mit dem Thema PHP und FastCGI aus? Gibt’s da auch schon was neues oder wird das gleich mit erledigt?

  • Peter R. Horak
    Peter R. Horak - 30. Juli 2010 um 10:52 Uhr

    Prima, freut mich sehr!

  • Malte Hübner
    Malte Hübner - 30. Juli 2010 um 11:43 Uhr

    Endlich ist es soweit! Danke!

  • U. Klauer
    U. Klauer - 30. Juli 2010 um 12:10 Uhr

    „IPv6 Unterstützung für die Zukunft (auch hier gibt es intern bereits Tests)“ – das wäre doch mal einen Blogbeitrag wert, oder? Nicht speziell bezogen auf Apache, sondern wie dF sich auf den Umstieg vorbereitet, welche Teile der Infrastruktur schon IPv6-fähig sind usw. Da wäre ich sehr neugierig. 🙂

  • Separatist
    Separatist - 30. Juli 2010 um 12:28 Uhr

    Aufrufe von http://IHRE-DOMAIN/system-cgi/cgi-debug/ zeigen aber weiterhin die Error-Events aller Domains des Auftrags an, richtig? – Jedenfalls ist es bei mir so.

    Dadurch lässt sich leider nicht immer jeder Fehler einem bestimmten Projekt zuordnen 🙁

    Jedenfalls freue ich mich über die Umstellung 🙂

  • Daniel Betz
    Daniel Betz - 30. Juli 2010 um 13:02 Uhr

    Alex Haupt: SVN/DAV wird beim Apache 2.2 nicht aktiviert sein.
    Problem ist, dass man die „Dav svn“ etc. Befehle nicht in eine .htaccess setzen kann, sondern diese in der Apache Konfiguration direkt setzen muss. Zumindest ist das laut Dokumentation so.

    Dominik Pesch: FastCGI ist noch nicht integriert.

    U. Klauer: Zu IPv6 gibt es auch schon einen Blog Eintrag: http://blog.df.eu/2009/10/09/ipv6-bei-domainfactory/

    Separatist: Wir haben den Apache 2.2 abgeändert, damit im Errorlog nun auch die Domainnamen stehen. Diese sind dann auch so im CGI-Debugger zu sehen. Dies hilft mit Sicherheit bei der Fehlersuche ein ganzes Stück.

  • Lars
    Lars - 30. Juli 2010 um 14:45 Uhr

    Ist denn dadurch in naher Zeit mit weiteren Tools für Managed Hosting zu rechnen z.B. einen Htaccess Generator der einen Verzeichnisschutz sofort umsetzt ?

    Das wäre super denn bei anderen Hostern habe ich das schon sehr oft gesehen, das erspart einem das manuelle anlegen oder auch Copy und Paste der erstellten Datei.

  • U. Klauer
    U. Klauer - 30. Juli 2010 um 17:18 Uhr

    @ Daniel Betz: Danke für den Hinweis, das war mir entgangen. Allerdings ist da auch nur recht unkonkret von Tests und immerhin einem zugeteilten Subnetz die Rede – es wäre also noch Raum für einen ausführlicheren Beitrag. 🙂

  • Gerald
    Gerald - 30. Juli 2010 um 17:21 Uhr

    Na dann Daumen drück 😉 Mit der .htaccess bin ich mal gespannt. Habe aber schon in der alten Version Probleme mit http_request. Vielleicht funktioniert daß ja mit dem neuen Indianer besser.

  • tregi
    tregi - 30. Juli 2010 um 23:18 Uhr

    Sara du hast Schritt 0 vergessen: Einige Server (z.B. oidipous) laufen auch schon seit heute (30. Juli) mit Apache 2.2

    Umstellung hat reibungslos geklappt. Auch meine .htaccess macht keinen Ärger.

    Weiter so!

  • Enigma
    Enigma - 31. Juli 2010 um 01:46 Uhr

    Ohne es jetzt tatsächlich getestet zu haben, würde ich denken, dass es in den genannten RewriteCond-Zeilen jeweils

    !^www\.

    und nicht

    ^!www\.

    heißen sollte. Dann wird die RegEx negiert; bei den genannten Zeilen ist das Ausrufungszeichen Bestandteil der RegEx.

    Gruß,
    Jan

  • Der Kreuzfahrtinspektor
    Der Kreuzfahrtinspektor - 31. Juli 2010 um 09:59 Uhr

    Danke für die Info und Hintergründe, dann weiß man bescheid!

  • Daniel
    Daniel - 31. Juli 2010 um 10:40 Uhr

    Enigma: Ne, das ist schon korrekt so. Wenn die Domain NICHT mit www. beginnt, dann leite auf http://www.domain.tld um.
    Die Regex oben funktioniert aber mittlerweile auch mit dem 2.2er Apache.
    Nur das FancyIndexing werden wir nicht extra umpatchen, da die Funktion deprecated ist. Mit Options …. gehts ja auch viel besser, da ja zusätzlich noch nettere Features impletementiert wurden 🙂

  • Sebastian
    Sebastian - 31. Juli 2010 um 20:22 Uhr

    Htaccess Generator – Für alle – wäre schon toll 🙂
    Eine saubere Konfiguration übers Kundenmenü, statt tief im Gewusel hier mal ne .HtAccess da mal eine. Wenn man bestimmten Gruppen neue Benutzer zufügen möchte, erleichtert die zentrale Steuerung doch so einiges … 😉

  • U. Klauer
    U. Klauer - 1. August 2010 um 02:05 Uhr

    @ Daniel: Doch, Enigma hat schon recht, das Ausrufezeichen gehört vor das Caret. Siehe auch die Dokumentation des Moduls: „You can prefix the pattern string with a ‚ ! ‚ character …“ Das ganze Muster also, nicht einen Teil.

  • Zeltlager Kiel
    Zeltlager Kiel - 1. August 2010 um 09:21 Uhr

    Sehr gut, das ist mal ne neuerung, ich freu mich drauf!

  • andreaz
    andreaz - 2. August 2010 um 14:43 Uhr

    Also neben den vielen freudigen Stimmen hier, geht meine Stimmung mehr in die Gegenrichtung:

    In meinem kleinen Shared-Hosting-Reseller wurde ich auch bereits umgestellt, ohne dass ich hierüber vorab informiert wurde. Rückwirkend konnte ich zwar feststellen, dass es keine Probleme gab, aber der Workflow misstfällt mir doch – gerade nachdem diese Umstellung wohl kaum „versehentlich“ passiert sein kann, sondern hier scheinbar bewusst heimlich getestet wurde…

    Aber gut, evtl. bin ich auch einfach zu sehr Techniker, nachdem die Umstellung für mich keinerlei Nachteile, sondern vermutlich eher Vorteile gebracht hat, sollte ich evtl. nicht motzen sondern mich freuen…

    Grüße
    Andreas

  • Marcel
    Marcel - 2. August 2010 um 20:05 Uhr

    @andreaz

    Egal für welchen Weg man sich entscheidet, bleibt bei jedem Update ein gewisses Restrisiko, was man jedoch soweit wie möglich einschränken möchte. Doch auch ist bzw. sollte jedem Techniker bekannt, dass aufgrund der Vielzahl von Möglichkeiten dies meistens nicht möglich ist und daher auch Tests im Livebetrieb durchgeführt werden müssen.

    Daher kann ich den entstandenen Unmut gut verstehen, jedoch die Vorgehensweise von dF ebenfalls.

  • Katrin S.
    Katrin S. - 4. August 2010 um 14:09 Uhr

    Ich finde es nicht gut, dass diese Umstellung in der Urlaubszeit erfolgt und nicht mindestens 1 Monat vorher angekündigt worden ist.

  • Kunde
    Kunde - 7. August 2010 um 11:36 Uhr

    Kann mich Katrin S. nur anschliessen: Eine solche Umstellung während der Haupturlaubszeit erzeugt bei mir nur kräftiges Kopfschütteln!