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$1Richtig ist:
RewriteCond %{HTTP_HOST} ^!www\. [NC]
RewriteRule (.*) http://www.domain.tld/$1Dieses 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.
Weitere Artikel zum Thema:
Über den Autor
Geschäftsführung (bis 11/13)
Krass! Da bin ich ja mal gespannt 🙂
Super! Freut mich, dass Ihr die Server aktualisiert. Nur warum kommen die ManagedServer zum Schluß dran?
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?
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.
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?
Prima, freut mich sehr!
Endlich ist es soweit! Danke!
„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. 🙂
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 🙂
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.
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.
@ 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. 🙂
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.
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!
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
Danke für die Info und Hintergründe, dann weiß man bescheid!
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 🙂
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 … 😉
@ 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.
Sehr gut, das ist mal ne neuerung, ich freu mich drauf!
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
@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.
Ich finde es nicht gut, dass diese Umstellung in der Urlaubszeit erfolgt und nicht mindestens 1 Monat vorher angekündigt worden ist.
Kann mich Katrin S. nur anschliessen: Eine solche Umstellung während der Haupturlaubszeit erzeugt bei mir nur kräftiges Kopfschütteln!