Liebe Mitglieder, Liebe Hostsharing-Nutzer und Interessenten,
zum Ausfall von gestern fehlen mir selbst die Worte. Diesmal war es ein
ganz klarer Fehler von uns Hostmastern, womit auch jede Bitte nach
Entschuldigung fehl am Platze ist. Vor allem fehlte es an einer Richtlinie
f�r Software-Installationen, die derartige Inkompatiblit�ten
ber�cksichtigt und fr�hzeitig erkennbar macht. Daher m�chte ich meine
Worte statt eines unsinnigen Entschuldigungsversuches, lieber einer
m�glichen L�sung widmen.
Nachdem ich eine Nacht dr�ber geschlafen habe, habe ich auch Ideen, wie
ein wiederholtes Fiasko aufgrund dieser Ursache mit guter Chance
verhindert werden kann, ohne dass Hostsharing weitere Kosten entstehen.
Das Problem ist, dass f�r die ideale L�sung, einen reinen Test-Server, der
nicht zum produktiven Betrieb genutzt wird, unsere finanzielle Decke noch
nicht ausreicht.
Ich schlage daher folgende Regel vor, um inkompatible Software in Zukunft
zumindest sofort zu entdecken: Bei Installation neuer Software, ebenso
Upgrades von bestehender Software, die den Webserver oder eines seiner
Module (in diesem Fall war es ja ein PHP4-Modul) betrifft, diese m�glichst
einzeln installiert werden sollte und nach jeder Einzel-Installation der
Webserver f�r das Test-Paket xyz00 neu gestartet werden muss. Ggf. m�ssen
daf�r neue Apache-Module erstmal in die Konfig dieses Paketes integriert
werden, damit diese �berhaupt angezogen werden.
Desweiteren schlage ich vor, dass neue Module in diesem Test-Paket xyz00,
mit eigenem Webserver, dann auch dort getestet werden m�ssen. Dazu geh�rt
dann bei Software-W�nschen von Mitgliedern, dass diese VOR Installation
eine Test-Szenario bereitstellen. Bei Sicherheitskritischer Software
(besonders Skripting-Modulen f�r den Apache), d�rfen diese eh erst dann in
die Haupt-Webserver Konfig integriert werden, wenn sichergestellt ist,
dass dadurch niemand Daten lesen oder gar �ndern kann, an denen er keinen
Rechte haben sollte. Dies passiert n�mlich leicht, weil die
Skripting-Umgebungen selbst unter der Userkennung des Webservers laufen,
die innerhalb aller DocumentRoots weitestgehende Rechte hat.
Eine Variante w�re auch, ein Paket hsh02 einzurichten, welches auch eine
eigene httpd.conf hat, und ausschlie�lich f�r Installations-Tests
verwendet wird. Dort k�nnten auch verschiedene Feature-Tests der Module
gesammelt und nach jeder Installation bzw. jedem Upgrade als
Regressionstest durchgef�hrt werden.
Wenn dann diese Tests fehlschlagen, m�sste die gerade installierte Sofware
wieder deinstalliert, bzw. ein Downgrade auf die alte Version durchgef�hrt
werden. Solange in dem Zeitraum des Tests kein Neustart eines der anderen
Webserver notwendig w�re (was eigentlich nur bei �berlast passiert),
bekommen diese derartige Software-Upgrades i.d.R. gar nicht mit, und
laufen somit weiter. Wenn zudem derartige Installationen zu
Low-Traffic-Zeiten gemacht werden, was wir eh immer tun, sollte auch diese
�berlast-Situation nicht auftauchen.
Ungekl�rt ist nach wie vor, warum entweder durch das Einrichten eines
neuen Paketes (xyz01 f�r die Zope-Tests) oder einer Domain in diesem
Paket, der Webserver gestern �berhaupt neu gestartet (restart) statt nur
neu geladen (reload) wurde. Bemerkt hatte ich den nicht mehr laufenden
Webserver jedenfalls schon vor dem SMS-Alarm, da die neu eingerichtete
Domain, trotz lokal gepatchter /etc/hosts, nicht nur nicht funktioniert,
sondern offenbar der ganze Webserver nicht mehr antwortete. Wir hatten
dennoch eine so lange Auszeit, da es keinerlei Fehlermeldung gab, die
einen Hinweis auf die Ursache des Problem gegeben h�tte. Die Fehlersuche
war also reines Trial-und-Error.
Zu den statistischen Auswertungen auf unserer Homepage sind folgende Dinge
zu sagen: Die Verf�gbarkeit/Woche ist nicht schlechter als gestern, da der
vorherige Ausfall (bedingt duch einen Fehler unseres Housers) nun 8 Tage
her ist und damit in der Wochenstatistik nicht mehr enthalten ist. Heute
morgen hatten wir eine falsche Anzeige von 91% f�r gestern, weil der
Output der Logfiles einen Fehler hatte, so dass f�r jede Fehlmessung ZWEI
Zeilen, f�r jede gute Messung aber nur ein Eintrag geschrieben wurde. Das
habe ich im Log-Skript korrigiert und die Logfiles um die falschen Zeilen
bereinigt. Trotz 75 min�tigem Ausfall, was 5,2% entspricht, bzw. einer
Verf�gbarkeit von 94,8%, zeigt die Anzeige 95,8%, weil zun�chst nur der
allgemeine Webserver betroffen war. Erst im Rahmen des Trial-und-Error
hatte ich dann auch die anderen Webserver neu gestartet (wir hatten schon
F�lle, wo ein Webserver einen anderen blockierte, wenn auch bisher immer
nur mit Fehlermeldung). Die Anzahl der Zugriffe ins Gewicht genommen, w�re
der Wert sogar noch etwas h�her, da die Power-Sites fast alle �ber eine
eigene Webserver-Konfig verf�gen.
Ich hoffe, mit diesen Vorschl�gen eine Grundlage f�r eine h�here
Service-Qualit�t zu schaffen. Was uns sicher mehr bringt, als �ber den
gestrigen Vorfall zu lamentieren. Ansosten kann ich nur sagen, dass jeder
hier eingeladen ist, eigene Verbesserungs-Vorschl�ge anzubringen.
Alles Gute w�nscht
Michael H�nnig
- Hostmaster -
--
Hostsharing eG / c/o Michael H�nnig / Boytinstr. 10 / D-22143 Hamburg
phone:+49/40/67581419 / mobile:+49/177/3787491 / fax:++49/40/67581426
http://www.hostsharing.net ---> Webhosting Spielregeln selbst gemacht
_______________________________________________
Global mailing list
[EMAIL PROTECTED]
http://lists.hostsharing.net/mailman/listinfo/global
