• Café
  • IPv6, Wartungs-Arbeiten und Dowtime von archlinux.de

Da sich kein eigener Beitrag lohnt, fasse ich hier ein paar Hinweise zum Server zusammen.

Zunächst ist die Beta-Phase der IPv6-Anbindung nun abgeschlossen. Leider musste da durch die IP geändert werden; dank DNS wird das aber niemand bemerkt haben. 🙂 Die IP besitzt nun auch einen korrekten reverse-Eintrag für IPv6, so dass es hier keine Probleme mehr geben sollte. (Zumindest ein Mail-Provider (freenet)) hat Mails fälschlicherweise als Spam markiert, da kein reverse-Eintrag vorhanden war. Alle Dienste sind sowohl per ipv4 als auch unter ipv6 erreichbar; für die Zukunft sind wir also gerüstet. (es handelt sich übrigens um native ipv6-Anbindung, also kein Tunnel o.Ä.; die Performance oder Erreichbarkeit unter ipv6 leidet also nicht)

Des weiteren war zwischen Sonntag (25.4.) von etwa 22 Uhr bis Montag (26.4.) 7 Uhr der Webserver nicht erreichbar. Was genau passiert war kann ich leider noch nicht sagen. Der lighttpd-Prozess lief einfach nicht mehr. (die PHP-Prozesse liefen allerdings noch). In den Logs war nichts offensichtliches zu finden und es gab auch keine Anzeichen für hohe Last oder Traffic zu diesem Zeitpunkt.

Für Dienstag den 04.05.2010 hat Strato zwischen 23:30 und 01:30 Wartungsarbeiten am Netz angekündigt, so dass der Server evtl. für ein paar Minuten nicht erreichbar sein wird.

Und wo wir gerade bei Problemen sind: die Tage hatte ich eine ziemlich lange Verzögerung beim Aufruf der Webseiten. Allerdings immer nur bei der ersten Anfrage. Mein Verdacht ist, dass hier der Aufbau der SSL-Session sehr lange dauerte. Hat jemand vielleicht ähnliche Beobachtungen gemacht? Serverseitig war weder hohe Last noch besondere Log-Einträge vorhanden.
Pierre schriebUnd wo wir gerade bei Problemen sind: die Tage hatte ich eine ziemlich lange Verzögerung beim Aufruf der Webseiten. Allerdings immer nur bei der ersten Anfrage. Mein Verdacht ist, dass hier der Aufbau der SSL-Session sehr lange dauerte. Hat jemand vielleicht ähnliche Beobachtungen gemacht? Serverseitig war weder hohe Last noch besondere Log-Einträge vorhanden.
Das habe ich auch beobachtet. Aber nicht nur bei der ersten Anfrage, sondern auch mitten drin. Allerdings nicht immer. Es scheint von der Tagesform ab zu hängen.
karotium schrieb
Pierre schriebUnd wo wir gerade bei Problemen sind: die Tage hatte ich eine ziemlich lange Verzögerung beim Aufruf der Webseiten. Allerdings immer nur bei der ersten Anfrage. Mein Verdacht ist, dass hier der Aufbau der SSL-Session sehr lange dauerte. Hat jemand vielleicht ähnliche Beobachtungen gemacht? Serverseitig war weder hohe Last noch besondere Log-Einträge vorhanden.
Das habe ich auch beobachtet. Aber nicht nur bei der ersten Anfrage, sondern auch mitten drin. Allerdings nicht immer. Es scheint von der Tagesform ab zu hängen.
Ja, ich kann natürlich Probleme bestätigen.
Das laden des Zitat-Editors hier hat zB 12 Sekunden benötigt.
Warum das so ist, dafür habe ich noch keine Vermutung, jedoch war ich seit dem Öffnen des Threads knapp 5 Minuten woanders.

Ich bin ja immer noch für eine Abschaltung des Zwangs-SSL; Und sei es meinetwegen Standard, aber man würde dennoch noch auf normales HTTP zurückgreifen können.
Für mich wird das Forum so langsam unbenutzbar.
Witzig, gerade bemerke ich die Verzögerungen auch, aber wohl nur, weil ich mal draufschaue. Die Lori-Extension von Firefox hat für das Aufrufen der Forumseite hier 10 Sekunden gemessen, aber die Editorseite hier, in der ich gerade tippe, hat nur die üblichen 0,2 Sekunden gebraucht.
Mir kommt langsam der Verdacht, dass es indirekt mit Firefox zusammenhängt. Wer möchte kann temporär mal die Zertifikats-Prüfung im FF abschalten und testen, ob es dann immer noch Probleme gibt: Bearbeiten->Einstellungen->Erweitert->Verschlüsselung->Validierung->OCSP deaktivieren.

Alternativ wäre noch interessant zu wissen, ob Nutzer anderer Browser das gleiche Problem haben.
Unter Midori habe ich bis jetzt keine solche Verzögerung feststellen können.
Dito, hier läufts mit Midori ebenfalls einwandfrei.
konnte mit konqueror auch keine probleme feststellen
mit uzbl habe ich auch verzoegerungen - stoeren mich aber nicht o_0
Pierre schriebMir kommt langsam der Verdacht, dass es indirekt mit Firefox zusammenhängt.
Ich benutze im Moment hauptsächliche Chrome. Aber unter Firefox ist es genauso. Ich glaube bei Epiphany, Midori und Konqueror habe ich dieses Problem noch nicht beobachtet.
Unter conkeror keine Probleme, obwohl wie Firefox auf xulrunner basierend.
Mmhh, ich nutze den Firefox und habe solche Problem nicht.
Aber ich habe am Anfang mal Probleme gehabt und mit network.dns.disableIPv6 true IPV6 deaktiviert.

Vielleicht hilft das.

cu
piet schriebMmhh, ich nutze den Firefox und habe solche Problem nicht.
Aber ich habe am Anfang mal Probleme gehabt und mit network.dns.disableIPv6 true IPV6 deaktiviert.

Vielleicht hilft das.

cu
Bei mir ist IPV6 schon deaktiviert. Ich glaube nicht das es daran liegt.
Chromium checkt auch OCSP; andere Browser evtl. nicht. Das wäre mein Tipp gewesen. Ansonstnen stehen wir wieder im Dunkeln. Das Haupt-Problem ist, dass es nicht reproduzierbar scheint. Daher sind eigentlich nur noch Informationen sinnvoll, wenn es nicht funktioniert.

PS: Für diejenigen, die das Problem beobachtet haben: wann etwa tart es das erste Mal auf?
Ich nutz auch Chrome. Das erste Mal? Seit der Umstellung auf SSL 🙂
Die Änderungen sollten uns zwar nicht betreffen, aber ich habe mal auf lighttpd 1.4.27 rc1 aktualisiert.
Hallo zusammen,

ich bin ja meistens spät nachts bzw. früh morgens aktiv (mit firefox). Wartezeiten von mind. 5 Sek. wären mir dabei sicher aufgefallen, gab es aber nicht.

Gruß, LessWire.
Mir sind bisher auch keine Wartezeiten im FF aufgefallen.

Grüße
Na, für mich sieht das sehr stark danach aus, dass der OCSP-Server von CAcert manchmal einfach überlastet ist. An der Stelle hängt er ja offensichtlich. Wenn man im FF dann noch "When an OCSP server connection fails, treat the certificate as invalid" aktiviert, kriegt man nach der Wartezeit auch das hier:
An error occurred during a connection to forum.archlinux.de.

The OCSP server returned unexpected/invalid HTTP data.

(Error code: sec_error_ocsp_bad_http_response)
Und ein Besuch auf http://ocsp.cacert.org/ verrät:
Too many users

Please try again later
Wenn das Forum aber schnell da ist, dann kriegt man auch eine richtige Antwort von http://ocsp.cacert.org/.
Gute Idee diese Funktion in FF einzuschalten. OSCP hatte ich vorher auch schon in Verdacht, konnte es aber nicht wirklich nachweisen. (FF scheint das nicht immer zu prüfen und der oscp-Server ist wohl auch nicht immer down)

Ich werde mal bei cacert nachfragen, was der Spaß soll. Das kann ja nicht sein, dass alle Seiten, die deren certs nutzen down sind, sobald deren oscp nicht mehr funktioniert.