blogaholic

Der Default-Tag

Kategorie: bitcast, filtersurf, misc. Zeit: 16.04.2006@07:57. Kommentare: Comments Off

Nein, heute ist nicht der Default-Tag, heute ist Ostersonntag (siehe auch den Event in der Sidebar).

Gestern, gestern war der Default-Tag, wie ich auf der Heimfahrt mit Christian festgestellt habe. Warum? Nunja, darum:

1. In Neuburg haben wir ja mit VLANs im Switch experimentiert, um uns eine zusätzliche Netzwerkkarte im Server zu ersparen. Als wir dann eine Weile rumgespielt haben, war der Switch irgendwann komplett verkonfiguriert und es ging gar nichts mehr. Ein Druck auf seine Reset-Taste führte nur zu hektischem Blinken aller LEDs, das Ziehen des Steckers brachte auch keine Besserung. Jedenfalls ließ er sich danach immer noch nicht über seine Default-IP-Adresse ansprechen. Komisch. Erst als wir dann ins Handbuch geschaut hatten und alles einmal durchgelesen hatten, fassten wir uns an den Kopf: Wir hätten nicht den Reset-Knopf, sondern den Factory Defaults Knopf (ebenfalls an der Frontseite, gut beschriftet…) drücken sollen. Oh Mann. Danach ging alles sofort wieder (ich übertreibe hier: wir haben uns die folgenden 2h noch mit den VLANs beschäftigt und wären schon beinahe verzweifelt, bis mir aufgefallen war, dass wir ein Patchkabel in einen falschen Port eingesteckt hatten – nach dem Umstecken lief dann alles sofort zufriedenstellend).
2. Als wir aus Neuburg zurück kamen, kam die zweite Episode, die dem gestrigen Tag seinen Namen gegeben hat. Wir hatten noch ein Problem mit einer FilterSurf-Box. Diese steht in Zuchering in einer Schule und funktionierte nach einem Update auf die Rev3 nicht mehr. Symptom: Alle Requests brauchten erst mal 2:40 min. Bedenkzeit und wurden dann ausgeführt. Christian hatte schon mehrere Fernwartungen durchgeführt, ohne Ergebnis. Die Situation vor Ort: Die FSB befindet sich hinter einem Windows-(Jana)-Proxy-Server, der von der Box als parent zu verwenden ist (was auch einwandfrei klappte). Allerdings gibt es in dem Netzwerk keinen DNS-Server und der Jana-Proxy lässt auch keine DNS-Requests nach draußen durch. Die Fehlerdiagnose zeigte dann, dass der Squid auf der FSB immer zuerst versuchte, die Domain eines Requests selbst aufzulösen und erst nach einem Timeout den Request an den Parent-Proxy weitergab. Offenbar war das in Zuchering die allererste Schule mit so einer verkorksten Infrastruktur, denn wir haben das Problem noch nie gehabt.
   Wieso aber hat unser Squid auf der FSB immer versucht, die DNS-Namen selbst aufzulösen? Inzwischen wissen wir es: Das macht er zur Performance-Steigerung: Er will die DNS-Responses selbst cachen und dann bereits fertig aufgelöste DNS-Namen an den Parent weiterleiten. Obwohl wir den FAQ-Eintrag schon oft gelesen hatten, war und ein entscheidendes Detail entgangen: die parent-Zeile in der squid.conf muss den Zusatz default tragen. Das soll soviel heißen wie: Verwende IMMER diesen Parent-Proxy (z.B. wenn es mehrere zur Auswahl gibt) UND versuche erst gar nicht, die DNS-Requests selbst aufzulösen. Oh Mann, wie kann man so eine wichtige Option nur so unscheinbar benennen!

So, jetzt gehts wieder auf nach Neuburg! Frohe Ostern allen Lesern.