Dieses Dokument enthält eine Liste von häufig über WWWOFFLE 2.6d gestellten Fragen und passende Antworten dazu.
Nicht alle hier gestellten Fragen sind "echte" Benutzerfragen, einige wurden einfach eingefügt, um dem Benutzer einen Einstieg in WWWOFFLE zu geben und wahrscheinlichen Fragen vorzubeugen.Sektion 0 - Warum beantwortet diese FAQ meine Frage(n) nicht?
Sektion 1 - Was kann WWWOFFLE (nicht)?
Q 1.1 Beherrscht WWWOFFLE http, https, ftp, finger, gopher, ...?
Q 1.2 Läuft WWWOFFLE auf anderen (nicht-UNIX) Systemen?
Q 1.3 Können die von WWWOFFLE erstellten Seiten angepaßt werden.?
Sektion 2 - WWWOFFLE im Intranet
Q 2.1 Kann WWWOFFLE von anderen Rechnern im Netz benutzt werden?
Q 2.2 Warum können andere Rechner im Netz nicht auf WWWOFFLE zugreifen?
Q 2.3 Warum können andere Rechner im Netz den Verweisen ("links") auf WWWOFFLE's Seiten nicht folgen?
Q 2.4 Gibt es Sicherheitsprobleme im Mehrbenutzerbetrieb?
Q 2.5 Wie kann ich verschiedene Konfigurationen für verschiedene Benutzer einrichten?
Sektion 3 - Hilfe, mein WWWOFFLE funktioniert nicht
Q 3.1 Warum liefert mein Browser eine leere Seite mit WWWOFFLE, funktioniert aber ohne?
Q 3.2 Warum kann WWWOFFLE Adressen nicht finden, die mein Browser findet?
Q 3.3 Warum sagt mein Browser etwas wie "Verbindung von Ihnen geschlossen"?
Q 3.4 Warum führt ein Verweis von einer FTP Adresse zum falschen Rechner?
Q 3.5 Warum behandelt WWWOFFLE Cookies nicht korrekt?
Q 3.6 Warum holt WWWOFFLE alle Seiten neu, die im Offline-Modus betrachtet werden?
Q 3.7 Warum erlaubt WWWOFFLE zu einige kennwortgeschützten Seiten keinen Zugriff?
Sektion 4 - Applets
Q 4.1 Warum startet mein Browser das Applet XYZ nicht?
Q 4.2 Werden unicoded Applets unterstützt?
Q 4.3 Warum zeigt mir Netscape eine 'trustProxy' Fehlermeldung an?
Sektion 5 - Undokumentierte Geheimfunktionen ;-)
Q 5.1 Wie sehe ich, welche abonnierten Seiten letztes Mal geholt wurden?
Q 5.2 Wie kann ich Seiten rekursiv regelmäßig holen (abonnieren)?
Q 5.3 Wie verhindere ich den Zugriff auf den Index?
Q 5.5 Wie kann ich die Performance von WWWOFFLE erhöhen?
Sektion 6 - Mehr Information über WWWOFFLE
Q 6.1 Wer hat WWWOFFLE geschrieben, wann und warum?
Q 6.2 Gibt es WWWOFFLE Mailinglisten?
Q 6.3 Wie/Wem melde ich Programmfehler (Bugs) vom WWWOFFLE?
Diese FAQ wird mit jeder neuen Version von WWWOFFLE mitgeliefert. Falls Sie also eine Frage über diese Version von WWWOFFLE haben, kann sie hier noch nicht enthalten sein. Sie wird allerdings ggf. gerne in die Online-Version der FAQ auf http://www.gedanken.demon.co.uk/wwwoffle/version-2.4/ aufgenommen.
Ein paar.
| http | Ja | Die ursprüngliche Version von WWWOFFLE konnte nur http. |
| ftp | Ja | Seit Version 2.0 gibt es auch Unterstützung für FTP. |
| finger | Ja | Seit Version 2.1. Es ist zwar kein Standardprotokoll für Proxies, aber es gibt keinen Grund es nicht einzubauen. |
| https | Ja! | Seit Version 2.4 beherrscht WWWOFFLE transparent verschlüsselte Verbindungen (SSL). Dies beinhaltet auch HTTPS. |
| gopher | Nein. | Es ist zwar nicht unmöglich, aber ich sehe keinen Grund es zu programmieren, da es offensichtlich von http (bzw. dem WWW) ersetzt wurde. |
Ja, zum Beispiel Win95 / WinNT.
| UNIX | Ja | Hier wurde es ursprünglich entwickelt und es sollte eigentlich auf jeder UNIX Variante laufen. Getestet wurde es unter Linux, SunOS 4.1.x, Solaris 2.x, und allen BSD Varianten. |
| DOS/Windows 3.x | Nein. | Weder die Dateiverwaltung noch die Multiprozessnatur (es sind fast immer mehrere Unterprozesse von wwwoffle gleichzeitig am arbeiten) erlauben eine Version für DOS. |
| Windows | Ja | Es gibt jetzt eine 32-bit Windows Version von WWWOFFLE. Dank dafür an das Cygwin Entwicklungskit, welches alle UNIX Systemaufrufe in einer Windows-Umgebung zur Verfügung stellt. |
| OS/2 | Vielleicht | Es gibt die EMX-Libraries für OS/2, die ähnlich CygWin arbeiten. Damit sollte es kein Problem sein es ebenfalls zu portieren. |
Diese Frage wird häufig gestellt. Manche wollen Javascript, Bilder, und mehr bunte Farben ;-) auf den WWWOFFLE Seiten.
Ab Version 2.2 ist dies kein Problem mehr, da die Seiten, die WWWOFFLE generiert, von HTML Seiten erstellt werden, die jeder an seinen Geschmack anpassen kann. Normalerweise liegen diese Seiten im /var/cache/wwwoffle/html/messages/ Verzeichnis, dort ist auch eine README Datei, die die Struktur erklärt.
Falls Sie WWWOFFLE aus Ihrer Distribution (Redhat, Debian, SuSE, ...) installiert haben, können die Dateien auch in /usr/share/wwwoffle zu finden sein.
Natürlich, das ist doch eine der Hauptfunktionen von WWWOFFLE. Dies ist seit der ersten Version möglich.
WWWOFFLE kann von sämtlichen Rechnern benutzt werden, die das TCP/IP Protokoll verstehen und in irgendeiner Weise mit dem Rechner vernetzt sind, auf dem WWWOFFLE läuft. Die einzige Bedingung ist, dem jeweiligen Browser zu sagen, daß er WWWOFFLE auch benutzen soll, d.h. WWWOFFLE als Proxy einzustellen.
Die Standardeinstellung in der Datei wwwoffle.conf verbietet Zugriff auf den Proxy für alle Rechner außer localhost. Wenn Sie anderen Rechnern Zugriff erlauben wollen, müssen Sie die Datei wie unten beschrieben ändern.
Der AllowedConnect Abschnitt in der Konfigurationsdatei enthält eine Liste von Rechnern, die Zugriff bekommen. Diese Namen werden mit den Namen, mit den sich die Rechner im Netzwerk identifizieren, verglichen und dann wird Zugriff erlaubt oder eben nicht. Es ist möglich, Wildcards zu benutzen, es werden aber keine Hostnamen aufgelöst oder Nameserver befragt.
Zum Beispiel wollen Sie das gesamte Netz 192.168.*.* (Ihr Intranet) auf WWWOFFLE zugreifen lassen. Dann muß die Konfiguration folgendermaßen aussehen:
AllowedConnect
{
192.168
}
Dies erlaubt allen Rechnern, die dazu passende IPs besitzen, den WWWOFFLE Server zu benutzen.
Einige der Links auf den WWWOFFLE-internen Webseiten zeigen auf andere Seiten innerhalb des Proxys. Hierfür muß dem WWWOFFLE Programm der Name des Rechners bekannt sein, auf dem er läuft, und der auch allen anderen Rechner im Netzwerk bekannt ist. Dies ist der erste Name, der im LocalHost Abschnitt der Konfigurationsdatei auftritt.
Ist Ihr Proxy z.B. allen Rechnern unter dem Namen www-proxy bekannt, müße der Abschnitt so aussehen:
LocalHost
{
www-proxy
localhost
127.0.0.1
}
Der erste wird von WWWOFFLE für Links "auf sich selbst" benutzt, die anderen werden lediglich auf keinen Fall im Cache gehalten.
Sicherheit ist eine ernste Sache, obwohl sie bei der Entwicklung von WWWOFFLE nicht im Vordergrund stand. Einige Sachen, die es zu beachten gibt, werde ich hier erläutern.
Für die Windows-Versionen ist klar, daß es keine Sicherheitsmechanismen vom System her gibt, wie bei UNIX Systemen. Es ist zum Beispiel unmöglich, Dateien zu erstellen, die von WWWOFFLE aber nicht von anderen Benutzern auf dem System gelesen werden können. Die Sicherheitsfunktionen von WWWOFFLE sind daher nur für UNIX Systeme wirksam.
Die Konfigurationsdatei kann durch ein Kennwort geschützt werden. Dieses wird dann benötigt, um WWWOFFLE online oder offline zu schalten, den Cache zu leeren, zu beenden oder neu zu starten, die Konfiguration zu verändern usw. Da das Kennwort im Klartext in der Konfigurationsdatei angegeben wird, sollte diese Datei auch nur von WWWOFFLE (und ggf. von Administratoren) lesbar sein. Das Kennwort wird von dem wwwoffle Programm nicht verschlüsselt, von dem wwwoffle Server übers Netzwerk nur trivial verschlüsselt.
Die Möglichkeit, WWWOFFLE mit der "HTTP/1.1 Proxy Authentification" zu benutzen, birgt allerdings dieselben Sicherheitsrisiken wie das Kennwort für die Konfigurationsdatei: Die Kennwörter und die Benutzernamen sind im Klartext in der Konfigurationsdatei enthalten und werden bei der Übertragung übers Netz trivial verschlüsselt. Wie gesagt, Bombensicherheit war nicht der primäre Grund für WWWOFFLE.
Die
User/Gruppen-IDs, unter denen der WWWOFFLE Server läuft, können
in der Konfigurationsdatei (Abschnitt Startup) eingestellt werden.
Der Benutzer oder die Gruppe, unter der WWWOFFLE läuft, muß die
Konfigurationsdatei lesen können (Schreibzugriffe sind nur nötig,
wenn die Datei mit der Interaktiven Konfiguration per Browser
verändert werden soll), und müssen in das Cache-Verzeichnis
(/var/cache/wwwoffle normalerweise) schreiben und lesen
können.
Wenn diese Option benutzt werden soll, dann muß der
WWWOFFLE Server von root gestartet werden (sonst kann er seine eigene
Benutzer-ID nicht nach dem Start noch ändern).
Nur derjenige, der die jeweilige
URL bestellt hat, kann die Bestellung löschen, und auch nur solange,
wie diese Bestellung noch nicht ausgeführt wurde. Dies wird erreicht,
indem ein Kennwort über eine Checksumme aus der Bestellung (der
entsprechenden Datei aus dem outgoing Verzeichnis) berechnet
wird.
Dies ist natürlich nur solange sicher, wie der WWWOFFLE
Server der einzige Prozeß ist, der dieses Verzeichnis lesen kann.
Ein sehr simpler Webserver ist in WWWOFFLE
eingebaut. Er folgt symbolischen Links, aus Sicherheitsgründen zeigt
er aber nur Dateien an, die sowieso jeder lesen kann, und die in
einem Verzeichnis liegen, welches von WWWOFFLE gelesen werden kann.
Das
heißt allerdings auch, daß von jedem lesbare Dateien, die in
einem Verzeichnis stecken, das nur WWWOFFLE lesen kann, nicht sicher
sind!
Normalerweise gibt es keine Probleme, Benutzern (Lese-)Rechte auf den Cache zu geben. Eine Ausnahme sind URLs, die ein Kennwort benötigen. Das einzige, was es zu bedenken gibt, ist daß das Aufräumen des Caches ("purge") nicht korrekt funktioniert, wenn jemand z.B. 'grep' auf den gesamten Cache losgelassen hat und in der Konfigurationsdatei der letzte Zugriff auf die jeweiligen Dateien als 'Aufräumzeit'-Basis benutzt wird, da dann alle Dateien als 'neu' erscheinen (weil ja vor kurzem auf sie zugegriffen wurde).
URLs mit Kennwörtern müssen ebenfalls im Cache gespeichert werden. Um die Sache nicht zu kompliziert zu machen, sind sie in keiner Weise versteckt. Das heißt, jede URL, die eine Benutzerkennung und/oder ein Kennwort benötigt, erscheint in Protokolldateien (logfiles) (nur mit "Debug" oder "ExtraDebug"). Diese Dateien liegen inklusive der Benutzername/Kennwort-Kombination im Cache, deshalb sollte der Cache u.U. mit den Standard-UNIX MItteln für andere Benutzer verborgen werden (Leserechte verweigern).
Der Zugriff auf den Proxy ist durch die
Liste von Addressen und Rechnernamen im AllowedConnectHosts
Abschnitt beschränkt. Standardmäßig steht dieses bloss auf
localhost. Zugriffe von anderen Rechnern werden vom Proxy
nicht ausgewertet, müssen aber angenommen und verarbeitet werden (damit der
Proxy diese Entscheidung treffen kann). Dies kann unter gewissen Umständen
einen DoS (Denial of Service) ermöglichen, wo nicht autorisierte Rechner
den WWWOFFLE Proxy mit verboteten Anfragen so beschäftigen, daß er auf
legitime Anfragen nicht mehr reagieren kann.
Um dies zu umgehen, benutzen Sie am besten die Paketfilter-/Firewallfähigkeit Ihres Betriebssytems (unter Windows ist diese Funktionalität allerdings nicht vorhanden), um nicht autorisierte Zugriffe zu verhindern. Bei Linux geht das folgendermaßen:
# Kernel 2.2.x: Proxy-Zugriffe nur von localhost erlauben
/sbin/ipchains -A input -i lo --dport 8080:8081 -p tcp -j ACCEPT
/sbin/ipchains -A input --dport 8080:8081 -p tcp -j DENY -l
# Kernel 2.4.x: Proxy-Zugriffe nur von localhost erlauben
/sbin/iptables -A INPUT -i lo --dport 8080:8081 -p tcp -j ACCEPT
/sbin/iptables -A INPUT --dport 8080:8081 -p tcp -j REJECT
# Kernel 2.4.x: Proxy-Zugriffe nur von best. Addressen erlauben
# (geht ähnlich auch mit 2.2.x)
for ADR in 192.168.1.1 192.168.1.4 192.168.1.24; do
/sbin/iptables -A INPUT -i eth0 -s $ADR --dport 8080:8081 -p tcp -j ACCEPT
done
/sbin/iptables -A INPUT -i eth0 --dport 8080:8081 -p tcp -j REJECT
Um differenziertere Firewall-Regeln aufzustellen, sollten Sie die
Manual-Pages für iptables oder ipchains lesen.
Falls es zwei Gruppen von Benutzern gibt, die den WWWOFFLE Proxy mit verschiedenen Konfigurationen benutzen wollen, gibt es die Möglichkeit, mehrere WWWOFFLE Instanzen laufen zu lassen.
Beispielsweise möchten in einer Schule die Lehrer neue Seiten abfragen können dürfen, aber die Schüler sollen nur im Cache surfen können. Dann ist etwa folgende Konfiguration nötig:
| wwwoffle.student.conf | wwwoffle.teacher.conf |
|---|---|
StartUp
{
http-port = 8080
wwwoffle-port= 8081
password = secret
}
OfflineOptions
{
<*://*/*> dont-request = yes
}
AllowedConnectUsers
{
}
AllowedConnectHosts
{
}
|
StartUp
{
http-port = 9080
wwwoffle-port= 9081
password = teacher
}
OfflineOptions
{
}
AllowedConnectUsers
{
teacher1:password1
teacher2:password2
}
AllowedConnectHosts
{
teacher1pc
teacher2pc
}
|
Die beiden WWWOFFLE-Instanzen müssen verschiedene Ports benutzen. Sie
benutzen dieselben Verzeichnisse für den Cache und somit sind dieselben
Webseite für beide Gruppen erreichbar. Für die Schüler sollte ein Kennwort
auf den WWWOFFLE-Proxy gesetzt werden, damit sie ihre eigene Konfiguration
nicht ändern können, für die Lehrer ist das nicht notwendig. Für die Lehrer
ist es sinnvoll, entweder AllowedConnectUsers oder
AllowedConnectHosts zur Zugangsbeschränkung zu benutzen.
In dem obigen Beispiel können dann die Schüler im Offline-Modus keine Seiten bestellen und der Online-Modus ist wegen der Kennwortsicherung nicht aktivierbar. Sie starten die beiden WWWOFFLE-Instanzen dann mit der passenden Konfigurationsdatei als Parameter.
Problem: Ohne WWWOFFLE funktioniert alles. Mit WWWOFFLE liefert Ihr Browser nur leere Seiten.
Mögliche Lösungen: (Alle wurden mir von anderen Benutzern mitgeteilt, oder selbst getestet):
Die häufigste Ursache ist, daß der DNS-Server seit dem Start von
WWWOFFLE ungültig geworden ist. Das kann passieren, wenn die Datei
/etc/resolv.conf geändert wurde (und quasi jedes Programm zum
Herstellen von Internetverbindungen tut dies). Die Lösung ist, daß Sie den
WWWOFFLE Proxy nach dem Verbindungsvorgang (und nach dem Auflegen)
einmal neu starten, dies läßt sich gängigerweise über Skripte in den
/etc/ppp/ip-{up,down}.d/ Verzeichnissen realisieren.
WWWOFFLE benutzt die UNIX-Systemfunktion gethostbyname(), um Rechnernamen auflösen zu können. Diese Funktion liefert nur ein Ergebnis, wenn der zurückgelieferte Name 'authorative' ist, d.h. das Ergebnis "sicher" ist -- sonst gibts eine Fehlermeldung..
"Große" Browser wie Netscape benutzen auch 'unsichere' (non-authorative) Informationen, wenn sie verfügbar sind. Das heißt, daß Netscape auf Adressen zugreifen kann, die für WWWOFFLE nicht erreichbar sind. Die Funktionen, die Netscape dafür benutzt, sind weder eindeutig noch 'sauber' und benötigen relativ viel Arbeit auf einer tiefen Ebene direkt in der Bibliothek, die für das Namensauflösen verantwortlich ist (libresolv). Ich möchte diese Funktionen nicht benutzen, weil sie die Kompatibilität zu vielen UNIX-Derivaten brechen würde und mir kein Standard garantiert, daß diese Funktionalität dort erhalten bleibt.
Dieses Problem tritt allerdings nur auf, wenn Ihr Nameserver eine sehr schlechte Verbindung hat oder Sie ein Konfigurationsproblem haben. Falls ersteres, sollten Sie sich einen anderen Nameserver suchen, oder natürlich bei Ihrem Internet Service Provider (ISP) einmal anklopfen.
ist, einen lokalen DNS-Server zu benutzen. Das Paket
bind, der Standard DNS-Server im Internet, ist af, wenn I
Seit Version 2.4 beherrscht WWWOFFLE transparent verschlüsselte
Verbindungen (SSL). Dies beinhaltet auch HTTPS.
Ja, zum Beispiel Win95 / WinNT.
| UNIX | Ja | Hier wurde es ursprünglich entwickelt und es sollte eigentlich auf jeder UNIX Variante laufen. Getestet wurde es unter Linux, SunOS 4.1.x, Solaris 2.x, und allen BSD Varianten. |
| DOS/Windows 3.x | Nein. | Weder die Dateiverwaltung noch die Multiprozessnatur (es sind fast immer mehrere Unterprozesse von wwwoffle gleichzeitig am arbeiten) erlauben eine Version für DOS. |
| Windows | Ja | Es gibt jetzt eine 32-bit Windows Version von WWWOFFLE. Dank dafür an das Cygwin Entwicklungskit, welches alle UNIX Systemaufrufe in einer Windows-Umgebung zur Verfügung stellt. |
| OS/2 | Vielleicht | Es gibt die EMX-Libraries für OS/2, die ähnlich CygWin arbeiten. Damit sollte es kein Problem sein es ebenfalls zu portieren. |
Diese Frage wird häufig gestellt. Manche wollen Javascript, Bilder, und mehr bunte Farben ;-) auf den WWWOFFLE Seiten.
Ab Version 2.2 ist dies kein Problem mehr, da die Seiten, die WWWOFFLE generiert, von HTML Seiten erstellt werden, die jeder an seinen Geschmack anpassen kann. Normalerweise liegen diese Seiten im /var/cache/wwwoffle/html/messages/ Verzeichnis, dort ist auch eine README Datei, die die Struktur erklärt.
Falls Sie WWWOFFLE aus Ihrer Distribution (Redhat, Debian, SuSE, ...) installiert haben, können die Dateien auch in /usr/share/wwwoffle zu finden sein.
Natürlich, das ist doch eine der Hauptfunktionen von WWWOFFLE. Dies ist seit der ersten Version möglich.
WWWOFFLE kann von sämtlichen Rechnern benutzt werden, die das TCP/IP Protokoll verstehen und in irgendeiner Weise mit dem Rechner vernetzt sind, auf dem WWWOFFLE läuft. Die einzige Bedingung ist, dem jeweiligen Browser zu sagen, daß er WWWOFFLE auch benutzen soll, d.h. WWWOFFLE als Proxy einzustellen.
Die Standardeinstellung in der Datei wwwoffle.conf verbietet Zugriff auf den Proxy für alle Rechner außer localhost. Wenn Sie anderen Rechnern Zugriff erlauben wollen, müssen Sie die Datei wie unten beschrieben ändern.
Der AllowedConnect Abschnitt in der Konfigurationsdatei enthält eine Liste von Rechnern, die Zugriff bekommen. Diese Namen werden mit den Namen, mit den sich die Rechner im Netzwerk identifizieren, verglichen und dann wird Zugriff erlaubt oder eben nicht. Es ist möglich, Wildcards zu benutzen, es werden aber keine Hostnamen aufgelöst oder Nameserver befragt.
Zum Beispiel wollen Sie das gesamte Netz 192.168.*.* (Ihr Intranet) auf WWWOFFLE zugreifen lassen. Dann muß die Konfiguration folgendermaßen aussehen:
AllowedConnect
{
192.168
}
Dies erlaubt allen Rechnern, die dazu passende IPs besitzen, den WWWOFFLE Server zu benutzen.
Einige der Links auf den WWWOFFLE-internen Webseiten zeigen auf andere Seiten innerhalb des Proxys. Hierfür muß dem WWWOFFLE Programm der Name des Rechners bekannt sein, auf dem er läuft, und der auch allen anderen Rechner im Netzwerk bekannt ist. Dies ist der erste Name, der im LocalHost Abschnitt der Konfigurationsdatei auftritt.
Ist Ihr Proxy z.B. allen Rechnern unter dem Namen www-proxy bekannt, müße der Abschnitt so aussehen:
LocalHost
{
www-proxy
localhost
127.0.0.1
}
Der erste wird von WWWOFFLE für Links "auf sich selbst" benutzt, die anderen werden lediglich auf keinen Fall im Cache gehalten.
Sicherheit ist eine ernste Sache, obwohl sie bei der Entwicklung von WWWOFFLE nicht im Vordergrund stand. Einige Sachen, die es zu beachten gibt, werde ich hier erläutern.
Für die Windows-Versionen ist klar, daß es keine Sicherheitsmechanismen vom System her gibt, wie bei UNIX Systemen. Es ist zum Beispiel unmöglich, Dateien zu erstellen, die von WWWOFFLE aber nicht von anderen Benutzern auf dem System gelesen werden können. Die Sicherheitsfunktionen von WWWOFFLE sind daher nur für UNIX Systeme wirksam.
Die Konfigurationsdatei kann durch ein Kennwort geschützt werden. Dieses wird dann benötigt, um WWWOFFLE online oder offline zu schalten, den Cache zu leeren, zu beenden oder neu zu starten, die Konfiguration zu verändern usw. Da das Kennwort im Klartext in der Konfigurationsdatei angegeben wird, sollte diese Datei auch nur von WWWOFFLE (und ggf. von Administratoren) lesbar sein. Das Kennwort wird von dem wwwoffle Programm nicht verschlüsselt, von dem wwwoffle Server übers Netzwerk nur trivial verschlüsselt.
Die Möglichkeit, WWWOFFLE mit der "HTTP/1.1 Proxy Authentification" zu benutzen, birgt allerdings dieselben Sicherheitsrisiken wie das Kennwort für die Konfigurationsdatei: Die Kennwörter und die Benutzernamen sind im Klartext in der Konfigurationsdatei enthalten und werden bei der Übertragung übers Netz trivial verschlüsselt. Wie gesagt, Bombensicherheit war nicht der primäre Grund für WWWOFFLE.
Die
User/Gruppen-IDs, unter denen der WWWOFFLE Server läuft, können
in der Konfigurationsdatei (Abschnitt Startup) eingestellt werden.
Der Benutzer oder die Gruppe, unter der WWWOFFLE läuft, muß die
Konfigurationsdatei lesen können (Schreibzugriffe sind nur nötig,
wenn die Datei mit der Interaktiven Konfiguration per Browser
verändert werden soll), und müssen in das Cache-Verzeichnis
(/var/cache/wwwoffle normalerweise) schreiben und lesen
können.
Wenn diese Option benutzt werden soll, dann muß der
WWWOFFLE Server von root gestartet werden (sonst kann er seine eigene
Benutzer-ID nicht nach dem Start noch ändern).
Nur derjenige, der die jeweilige
URL bestellt hat, kann die Bestellung löschen, und auch nur solange,
wie diese Bestellung noch nicht ausgeführt wurde. Dies wird erreicht,
indem ein Kennwort über eine Checksumme aus der Bestellung (der
entsprechenden Datei aus dem outgoing Verzeichnis) berechnet
wird.
Dies ist natürlich nur solange sicher, wie der WWWOFFLE
Server der einzige Prozeß ist, der dieses Verzeichnis lesen kann.
Ein sehr simpler Webserver ist in WWWOFFLE
eingebaut. Er folgt symbolischen Links, aus Sicherheitsgründen zeigt
er aber nur Dateien an, die sowieso jeder lesen kann, und die in
einem Verzeichnis liegen, welches von WWWOFFLE gelesen werden kann.
Das
heißt allerdings auch, daß von jedem lesbare Dateien, die in
einem Verzeichnis stecken, das nur WWWOFFLE lesen kann, nicht sicher
sind!
Normalerweise gibt es keine Probleme, Benutzern (Lese-)Rechte auf den Cache zu geben. Eine Ausnahme sind URLs, die ein Kennwort benötigen. Das einzige, was es zu bedenken gibt, ist daß das Aufräumen des Caches ("purge") nicht korrekt funktioniert, wenn jemand z.B. 'grep' auf den gesamten Cache losgelassen hat und in der Konfigurationsdatei der letzte Zugriff auf die jeweiligen Dateien als 'Aufräumzeit'-Basis benutzt wird, da dann alle Dateien als 'neu' erscheinen (weil ja vor kurzem auf sie zugegriffen wurde).
URLs mit Kennwörtern müssen ebenfalls im Cache gespeichert werden. Um die Sache nicht zu kompliziert zu machen, sind sie in keiner Weise versteckt. Das heißt, jede URL, die eine Benutzerkennung und/oder ein Kennwort benötigt, erscheint in Protokolldateien (logfiles) (nur mit "Debug" oder "ExtraDebug"). Diese Dateien liegen inklusive der Benutzername/Kennwort-Kombination im Cache, deshalb sollte der Cache u.U. mit den Standard-UNIX MItteln für andere Benutzer verborgen werden (Leserechte verweigern).
Der Zugriff auf den Proxy ist durch die
Liste von Addressen und Rechnernamen im AllowedConnectHosts
Abschnitt beschränkt. Standardmäßig steht dieses bloss auf
localhost. Zugriffe von anderen Rechnern werden vom Proxy
nicht ausgewertet, müssen aber angenommen und verarbeitet werden (damit der
Proxy diese Entscheidung treffen kann). Dies kann unter gewissen Umständen
einen DoS (Denial of Service) ermöglichen, wo nicht autorisierte Rechner
den WWWOFFLE Proxy mit verboteten Anfragen so beschäftigen, daß er auf
legitime Anfragen nicht mehr reagieren kann.
Um dies zu umgehen, benutzen Sie am besten die Paketfilter-/Firewallfähigkeit Ihres Betriebssytems (unter Windows ist diese Funktionalität allerdings nicht vorhanden), um nicht autorisierte Zugriffe zu verhindern. Bei Linux geht das folgendermaßen:
# Kernel 2.2.x: Proxy-Zugriffe nur von localhost erlauben
/sbin/ipchains -A input -i lo --dport 8080:8081 -p tcp -j ACCEPT
/sbin/ipchains -A input --dport 8080:8081 -p tcp -j DENY -l
# Kernel 2.4.x: Proxy-Zugriffe nur von localhost erlauben
/sbin/iptables -A INPUT -i lo --dport 8080:8081 -p tcp -j ACCEPT
/sbin/iptables -A INPUT --dport 8080:8081 -p tcp -j REJECT
# Kernel 2.4.x: Proxy-Zugriffe nur von best. Addressen erlauben
# (geht ähnlich auch mit 2.2.x)
for ADR in 192.168.1.1 192.168.1.4 192.168.1.24; do
/sbin/iptables -A INPUT -i eth0 -s $ADR --dport 8080:8081 -p tcp -j ACCEPT
done
/sbin/iptables -A INPUT -i eth0 --dport 8080:8081 -p tcp -j REJECT
Um differenziertere Firewall-Regeln aufzustellen, sollten Sie die
Manual-Pages für iptables oder ipchains lesen.
Falls es zwei Gruppen von Benutzern gibt, die den WWWOFFLE Proxy mit verschiedenen Konfigurationen benutzen wollen, gibt es die Möglichkeit, mehrere WWWOFFLE Instanzen laufen zu lassen.
Beispielsweise möchten in einer Schule die Lehrer neue Seiten abfragen können dürfen, aber die Schüler sollen nur im Cache surfen können. Dann ist etwa folgende Konfiguration nötig:
| wwwoffle.student.conf | wwwoffle.teacher.conf |
|---|---|
StartUp
{
http-port = 8080
wwwoffle-port= 8081
password = secret
}
OfflineOptions
{
<*://*/*> dont-request = yes
}
AllowedConnectUsers
{
}
AllowedConnectHosts
{
}
|
StartUp
{
http-port = 9080
wwwoffle-port= 9081
password = teacher
}
OfflineOptions
{
}
AllowedConnectUsers
{
teacher1:password1
teacher2:password2
}
AllowedConnectHosts
{
teacher1pc
teacher2pc
}
|
Die beiden WWWOFFLE-Instanzen müssen verschiedene Ports benutzen. Sie
benutzen dieselben Verzeichnisse für den Cache und somit sind dieselben
Webseite für beide Gruppen erreichbar. Für die Schüler sollte ein Kennwort
auf den WWWOFFLE-Proxy gesetzt werden, damit sie ihre eigene Konfiguration
nicht ändern können, für die Lehrer ist das nicht notwendig. Für die Lehrer
ist es sinnvoll, entweder AllowedConnectUsers oder
AllowedConnectHosts zur Zugangsbeschränkung zu benutzen.
In dem obigen Beispiel können dann die Schüler im Offline-Modus keine Seiten bestellen und der Online-Modus ist wegen der Kennwortsicherung nicht aktivierbar. Sie starten die beiden WWWOFFLE-Instanzen dann mit der passenden Konfigurationsdatei als Parameter.
Problem: Ohne WWWOFFLE funktioniert alles. Mit WWWOFFLE liefert Ihr Browser nur leere Seiten.
Mögliche Lösungen: (Alle wurden mir von anderen Benutzern mitgeteilt, oder selbst getestet):
Die häufigste Ursache ist, daß der DNS-Server seit dem Start von
WWWOFFLE ungültig geworden ist. Das kann passieren, wenn die Datei
/etc/resolv.conf geändert wurde (und quasi jedes Programm zum
Herstellen von Internetverbindungen tut dies). Die Lösung ist, daß Sie den
WWWOFFLE Proxy nach dem Verbindungsvorgang (und nach dem Auflegen)
einmal neu starten, dies läßt sich gängigerweise über Skripte in den
/etc/ppp/ip-{up,down}.d/ Verzeichnissen realisieren.
WWWOFFLE benutzt die UNIX-Systemfunktion gethostbyname(), um Rechnernamen auflösen zu können. Diese Funktion liefert nur ein Ergebnis, wenn der zurückgelieferte Name 'authorative' ist, d.h. das Ergebnis "sicher" ist -- sonst gibts eine Fehlermeldung..
"Große" Browser wie Netscape benutzen auch 'unsichere' (non-authorative) Informationen, wenn sie verfügbar sind. Das heißt, daß Netscape auf Adressen zugreifen kann, die für WWWOFFLE nicht erreichbar sind. Die Funktionen, die Netscape dafür benutzt, sind weder eindeutig noch 'sauber' und benötigen relativ viel Arbeit auf einer tiefen Ebene direkt in der Bibliothek, die für das Namensauflösen verantwortlich ist (libresolv). Ich möchte diese Funktionen nicht benutzen, weil sie die Kompatibilität zu vielen UNIX-Derivaten brechen würde und mir kein Standard garantiert, daß diese Funktionalität dort erhalten bleibt.
Dieses Problem tritt allerdings nur auf, wenn Ihr Nameserver eine sehr schlechte Verbindung hat oder Sie ein Konfigurationsproblem ha