WWW-Proxy-Cache-Server mit Offline-Zugriff

Vor- und Nachteile von Dial-Up-Internetzugängen:

1. Vorteile:
   • Online-Verbindung und Kosten entstehen nur bei Bedarf
   • günstiger Anschaffungspreis (2-MBit-Standleitungen sind ganz (un)schön teuer!)
2. Nachteile:
   • vergleichsweise niedriger Durchsatz (mit ISDN max. 64 kBit/s = ca. 7500 Byte/s ohne Protokolloverhead)
   • Dokumente aus dem Internet stehen nicht ständig zur Verfügung
   • es entstehen Telefonkosten und bei einigen Providern noch Kosten je nach Datenvolumen

Da wir besonders im ODS auf eine extreme Kostenminimierung achten müssen, sind größere »Sessions« zur Zeit noch ein Luxus, den wir uns nicht regelmäßig oder in brauchbarem Rahmen leisten können

Eine weitere Eigenschaft des Internet besteht darin, daß man selbst eine 28.8k-Verbindung nur selten ausreizen kann, weil die Antwortzeiten der entfernten Server viel zu lang sind oder die Daten aufgrund überlasteter Leitungen nur tröpfchenweise eintrudeln. Daran ändert in den meisten Fällen auch ein Zugang über die TU Chemnitz-Zwickau, die über eine leistungsfähige Hochgeschwindigkeitsanbindung verfügt, nichts.

Das WWW wird leider zu recht oft als World Wide Wait bezeichnet.

Ansätze

Wie lassen sich mit vertretbarem, d.h. möglichst kostenlosem oder -günstigen, Aufwand die o.g. Nachteile aufheben oder zumindest mindern?

1. Wir könnten durch den Einsatz von Caches die benötigte Bandbreite verringern, weil oft benötigte Dokumente auf der lokalen Platte oder zumindest im dicken TU-Cache liegen.
2. Wir könnten einen bestehenden Cache ohne Online-Verbindung, also offline benutzen.
3. Ein Robot (z.B. webcow) könnte zu günstigen Tarifzeiten in Verbindung mit dem lokalen Cache ganze Server spiegeln, die dann z.B. im Unterricht offline zumindest teilweise zur Verfügung stehen würden.

Lösung

Die o.g. Ansätze sind am Carl-Friedrich-Gauß-Gymnasium bereits realisiert. Als WWW-Proxy kommt der CERN httpd 3.0 zum Einsatz, der zwar ein paar Nachteile (zum Beispiel in der Performance) hat, mit dem sich allerdings alle drei Ansätze verwirklichen lassen. Der webcow-Robot befindet sich noch im frühen Entwicklungsstadium, kann zur Zeit allerdings schon begrenzt eingesetzt werden, um Seiten in den Cache zu schaufeln.

Im folgenden will ich die Konfiguration des Systems näher betrachten.

Umsetzung

Voraussetzungen

1. Ein funktionierendes Linux-System. (Im Gauß-Gymnasium eine SuSE 4.4)
2. Ein installierter CERN httpd 3.0
3. Ein installierter named. (z.B. von der SuSE) Wichtig: inklusive einer Datei root.cache!
4. Funktionierende PPP-Dial-Up-Verbindung.

Konfigurationen

Für den httpd Daemon werden zwei unterschiedliche Konfigurationen benötigt - eine für den offline-Betrieb und eine für den online-Betrieb, die automatisch beim Wechsel von offline zu online und vice versa entsprechend verwendet werden.

1. HTTPD-Online Konfiguration (Original: httpd-online.conf)
2. HTTPD-Offline Konfiguration (Original: httpd-offline.conf)
3. PPP-Konfiguration
4. named-Konfiguration

Let's go

Das war's im Großen und Ganzen zum WWW-Proxy-Cache-Server. Zwei kleine Skripte /go.internet und /leave.internet machen das Leben noch etwas leichter.

Diese Seiten wurde gestaltet von Tino Schwarze im Rahmen eines Vortrages für die Chemnitz Linux User Group. Bei Fragen -> Fragen!