LUGS - Vorträge: Proxy-Server Squid vom 15.1.1998
LUGS Über die LUGS Statuten und Protokolle Sektionen Terminliste IRC Mailinglisten Kontaktadressen Mitglied werden Internes Mitgliederliste LINUX Was ist Linux?    Screenshots Distributionen    kmLinux Firmen Ressourcen LIB Dokumentation Events Projekte Vorträge Allgemeines ChangeLog Sprache Galerie	Am 15.1.1998 hat Neil Franklin einen Vortrag über Squid, einen Internet-Proxy-Cache, gehalten. Er hat im Wesentlichen die Konfiguration für einen Heim-Benutzer mit Dial-Up-Verbindung zum Internet besprochen. Was ist ein Internet-Proxy-Cache Gemäss FAQ (diese ist übrigens sehr lesenswert) leistet Squid folgendes: Er speichert Internet-Objekt, die über http-, ftp- oder gopher-Abfragen schon mal nachgefragt wurden, um sie bei einer erneuten Abfrage direkt aus seinem Speicher zu liefern. Die zeit-, telefonkosten- und bandbreitenintensive Abfrage über das Internet entfällt also. Dazu muss ein Client (z. B. Netscape oder ftp) seine Anfrage für ein Internet-Objekt (html-Seite, Bild, etc.) an den Proxy-Server und nicht direkt an den betroffenen Server im Internet richten. Dieser holt die verlangten Daten aus dem Internet und reicht sie an den Client weiter. Er funktioniert in gleicher Weise, wie oben beschrieben, auch als DNS-Cache. Um die Last auf verschiedene Rechner zu verteilen, kann man ganze Hierarchien von Squid-Servern, die untereinander kommunizieren, gründen. Geschwister teilen sich die Arbeit und fragen Ihren Vater, bevor sie direkt aufs Internet zugreifen. Squid auf dem Internet Squid wird relativ häufig aktualisiert, Informationen dazu holt man sich am Besten auf der Squid-Homepage. Die Sourcen kann man auch bei Switch haben. Aktuell ist im Moment die Version 1.1.20, aber wem häufige Core-Dumps nichts ausmachen, der kann sich an der Beta-Version 1.2.beta probieren. Wer sich als Squid-Benutzer beraten lassen will, greift zu einer der vielen Mailing-Listen, die in der FAQ erwähnt sind. Squid ist auf den meisten modernen Unix-Platformen lauffähig: AIX, FreeBSD, HP-UX, IRIX, Linux, NeXTStep, OSF/1, Solaris und SunOS. Konfiguration Mit dem Source-Code (Squid untersteht der GPL und wird von den Verantwortlichen nur im Source-Code verteilt.) kommt ein sehr gut dokumentiertes Konfigurationsfile mit. Es wird mit make install in /etc/squid installiert. Die Voreinstellungen dort sind eigentlich brauchbar. Für den Heim-Anwender gibt es allerdings einige Verbesserungsvorschläge: cache_mem begrenzt den benutzten Plattenplatz. Neils Vorschlag: auf 1 GB einstellen und von Zeit zu Zeit von Hand die nicht benötigten Objekte löschen (wie das geht später). dns_children ist die Anzahl von DNS-Cache-Servern gestartet werden sollen. Für den Heim-Gebrauch reicht einer. refresh_pattern bestimmt verschiedene Parameter für den Frische-Algorithmus mit dem Squid bestimmt, ob ein Objekt im Cache als fresh (frisch) oder stale (alt, abgestanden) zu betrachten ist. Abgestandene Objekte werden bei Nachfrage neu aus dem Internet geholt und frische direkt dem Client übergeben. Mit refresh_pattern . 512460 20% 512460 bleiben alle Objekte (auch mit deklariertem Ablaufdatum) ein Jahr (Voreinstellung: drei Tage) lang frisch und damit im Lager (Cache). Der anfragende Client kann sich allerdings über diese Daten hinwegsetzen - Squid muss neu aus dem Internet laden. quick_abort bestimmt, ob ein Objekt fertig geladen werden soll, obwohl der Benutzer den Stopp-Knopf gedrückt hat. Normalerweise lädt Squid fertig, mir scheint das auch sinnvoll. negative_ttl gibt an, wie lange eine Fehlermeldung im Cache bleiben soll (0 ist sinnvoll für Leute die oft vergessen online zu gehen). Lynx und Netscape für einen Proxy konfigurieren Die Konfiguration von Netscape für einen Proxy ist ein bisschen versteckt. Sobald die Adresse (Name des Hosts auf dem der Proxy läuft) und der Port bekannt sind, kann man diese Daten ins Proxy-Dialogfeld eintragen. Bei der Version 3 von Netscape ist dieses unter Options-Network Preferences zu finden und bei Version 4 unter Edit-Preferences-Advanced-Proxies. In diesem Dialog-Feld wählt man Manual proxy configuration und anschliessend View. Für Lynx ist die Konfiguration so, wie man es sich für Linux gewohnt ist: über das File /etc/lynx.cfg mit einer Zeile pro unterstütztem Protokoll (z. B. http_proxy:http://www.niederglatt.lugs.ch:3128/ bei mir) oder mit dem Setzen der Environment-Variable http_proxy (z. B. in der Bash: export http_proxy=http://www.niederglatt.lugs.ch:3128/). Die Port-Nummer 3128 ist der Standard-Port für Proxy-Server und Squid kommt so voreingestellt. Objekte von Hand löschen Die Objekte im Cache von Squid kann man von Hand (oder besser halbautomatisch löschen), indem man die zugehörige Zeile im File /var/spool/squid/log löscht. Allerdings muss das geschehen, wenn Squid nicht läuft. Alternativ kann man Squid killen bevor man das File wieder speichert. Denn beim Beenden überschreibt Squid das File komplett. Vorschlag von Neil: man soll sich durch die interessanten Seiten durchklicken und anschliessend offline gehen. Nun kann man in aller Ruhe diese Seiten durchlesen und entscheiden, welche aufbewahrenswert sind und welche nicht. Die Informationen kommen alle aus dem Squid und dort sollen sie auch bleiben. Die Zeilen, die zu den unerwünschten Seiten gehören löscht man im log-File. Wenn man alle Seiten beurteilt hat, schickt man ein kill-Signal an Squid und schreibt anschliessend das log-File. Damit fehlen dann dort die Einträge der unerwünschten Seiten. Beim nächsten Start von Squid löscht dieser allmählich die Dateien in seinem Cache, welche keinen Eintrag im log-File haben (dieser Vorgang kann allerdings an die zwei Stunden dauern). Einen ganzen Server in den Proxy laden Um sich einen ganzen Server runterzuladen gibt es das Programm wget. Wenn es sich des Proxy's bedient, dann bleibt natürlich der ganze Server dort drin hängen. Man setzt die Adresse des Proxy's in die Environment-Variable http_proxy und lässt dann wget seine Arbeit tun. Mit der Option --delete-after hinterlässt dieses selber nach Beendigung keine Spuren. Dieses Verfahren ist allerdings nicht sehr empfehlenswert, da bei vielen Webservern nur ein kleiner Teil der vorhandenen Dateien auch wirklich in Gebrauch ist. Aber wenn man schon am Vorabend weiss, dass am nächsten Tag viele User eine bestimmte Site verlangen werden (z. B. über den Mars), dann rechtfertigt sich sowas schon. Happy Surfing... Zusammenfassung des Vortrages durch Philipp Frauenfelder.