Squid wird mittels einer normalen Textdatei konfiguriert (im Normalfall befindet sich
diese Datei im Installationsverzeichnis und heißt <prefix>
/etc/squid.conf), die logisch in mehrere Teilbereiche unterteilt werden kann. Bei der
Compilierung von Squid wird eine Default-Konfiguration erzeugt, die mit minimalen
Änderungen bereits einen ersten Testlauf ermöglicht. Für die Ausnutzung der vollen
Leistung von Squid sollte jedoch eine individuelle Anpassung erfolgen.
Alle Zeilen von squid.conf, die mit # beginnen, sind Kommentare bzw. nicht aktivierte Optionen.
Als Minimalkonfiguration genügen die in Schnellstart beschriebenen Einstellungen. Für die genaue Syntax von Optionen sei ebenfalls auf squid.conf verwiesen, die folgenden Kapitel geben nur einen groben Überblick über die Möglichkeiten von Squid.
Für einen ersten Testlauf sind nur einige Einstellungen vorzunehmen, die jedoch in der Konfigurationsdatei etwas verstreut sind. Die Optionen werden hier kurz erläutert:
Dieser Eintrag ist erforderlich, wenn der lokale Proxy mit einem Neighbor-Cache verbunden werden soll. Die nötigen Angaben erhält man normalerweise vom Administrator des Neighbor-Cache, ein unbefugtes ,,Anzapfen`` eines anderen Squid-Proxies ist Bandbreitendiebstahl und gehört nicht zum guten Ton im Internet. Neighbor-Caches werden später genauer erläutert.
Dieser Parameter gibt an, wieviel physikalisches RAM zum Caching verwendet werden soll. Squid belegt in der Regel jedoch die zwei- bis vierfache Speichermenge, deshalb sollte der Wert nicht allzu großzügig bemessen sein. Hier sollte man bedenken, daß es für die Performance äußerst ungünstig ist, wenn Squid und seine Unterprozesse ausgelagert werden, da Festplattenzugriffe wesentlich langsamer als Hauptspeicherzugriffe sind. Andererseits sollte man aber bedenken, daß Squid WWW-Objekte zuerst im RAM puffert, um sie nach Bedarf dann auf die Festplatte auszulagern. Die optimale Einstellung der Hauptsspeichergröße hängt also stark von lokalen Gegebenheiten ab.
Die maximale Größe des permanenten Cache-Bereiches auf der Festplatte wird hier angegeben. Man muß jedoch in Betracht ziehen, daß Squid beim ersten Aufruf seine komplette Cache-Struktur in Form einer Verzeichnishierarchie bereits auf der Platte abbildet, was den verfügbaren Plattenplatz beschränkt. Dieser Wert sollte deshalb ca. 10% kleiner als der real verfügbare freie Festplattenspeicher sein, den man verwenden will - die Prozentangabe kann jedoch mit der verwendeten Inode-Dichte variieren. Squid reagiert etwas empfindlich, wenn der verfügbare Platz kleiner ist als der zugeteilte. Programmabbrüche können die Folge sein.
Unter acl versteht man access control lists, also Filter, die den Zugriff auf den Proxy regeln.
Der wichtigste Eintrag ist wohl allowed_hosts, der auf die Netzwerkadresse der
Domain verweisen sollte, für die Squid cachen soll. Nach der Adressangabe (im Format
www.xxx.yyy.zzz), folgt ein Schrägstrich und die verwendete Netzwerkmaske (bei einem
Class C Netz also 255.255.255.0). Für den verwendeten Testaufbau (siehe Kapitel A.1) wurden die in Tabelle 2.2 beschriebene acl verwendet.
Hier trägt man die E-Mail-Adresse des Betreuers ein, damit bei Bedarf ein Ansprechpartner vorhanden ist.
Dieser Eintrag ist erforderlich, wenn squid vom Administrator root gestartet wird (z.B. beim Booten). Hier sollte entweder ein sicherer Benutzer und eine sichere Gruppe eingetragen werden, die im System nur sehr beschränkte Rechte haben (wie nobody/nogroup), oder für squid wird ein neuer Benutzer und eine neue Gruppe angelegt. Nach dem Starten von squid ändert der Prozeß dann seine eigenen Zugriffsrechte, womit eventuelle Sicherheitsprobleme vermieden werden, die auftreten könnten, wenn squid als root-Prozeß läuft. Zu beachten ist hierbei, daß das Verzeichnis für die Cache-Daten sowie die Installationsverzeichnisse ebenfalls dem neuen Benutzer gehören müssen, sonst gibt das Programm etwas irreführende Fehlermeldungen aus, die zwar bei anderen Betriebssystemen gang und gäbe sind, einen Unix-Benutzer aber eher verwirren dürften.
Unter diesem Namen macht sich der Proxy bekannt, dieser Name ist aber nicht frei wählbar, sondern sollte mit dem DNS-Eintrag des Computers übereinstimmen.
Mit diesen Einträgen kann Squid testweise gestartet werden. Dazu ruft man
| Prompt> < prefix >/bin/squid |
auf. Squid beginnt daraufhin, seine Cache-Verzeichnisse anzulegen, was einige Zeit dauert. Anschließend kann man den Cache-Proxy in einem WWW-Client (z.B. Netscape Navigator) eintragen und testen.
Die aktuelle Konfiguration stellt das Minimun dar, für effiziente Ausnutzung sollte Squid individuell angepaßt werden.
In den folgenden Kapiteln können die verwendeten Optionen erneut auftauchen, da sich der Aufbau an der automatisch generierten Squid-Konfigurationsdatei orientiert.
Hiermit wird der von Squid verwendete Port für eingehende HTTP-Requests
konfiguriert. Dieser Wert ist auf 3128 voreingestellt, die Einstellung des HTTP
Accelerators ist Port 80 und kann durch die Kommandozeilenoption -a <port>
beim Starten von Squid eingestellt werden.
Dieser Port wird zur Kommunikation mit Neighbor-Caches verwendet. Die Standard-Einstellung ist 3130. Wird Squid unabhängig von einem Cache-Verbund betrieben, kann mit einer Portangabe von 0 ein Standalone-Betrieb erzwungen werden.
Multicast-Groups sind eigene Netzwerkbereiche, die in einem großen Cache-Verbund verwendet werden. Dies wurde im Rahmen der Diplomarbeit jedoch nicht getestet.
Die folgenden vier Optionen sind für Proxy-Systeme mit mehreren Netzwerkanschlüssen von Bedeutung:
Die IP-Adresse des Netzwerkinterfaces für eingehende Anfragen von Clients und Neighbor-Caches.
Der Netzwerkanschluß für die Verbindung zu WWW-Servern und anderen Neighbor-Caches.
Die Adresse, über die Steuerinformationen von Neighbor-Caches empfangen werden.
Das Interface für Anfragen an Neighbor-Caches. Dieser Wert muß ein anderer sein als udp_incoming_address, da beide den selben Port verwenden.
Sind diese vier Optionen nicht angegeben, werden sie bei Bedarf automatisch zugewiesen. Eine Festlegung kann jedoch den Datenverkehr auf vorhersagbare Netzwerkverbindungen verlagern, was für große Netzwerke zur Lasttrennung nützlich ist.
Dieser Eintrag ist erforderlich, wenn der lokale Proxy mit einem Neighbor-Cache verbunden werden soll. Die nötigen Angaben erhält man normalerweise vom Administrator des Neighbor-Cache, ein unbefugtes ,,Anzapfen`` eines anderen Squid-Proxies ist Bandbreitendiebstahl und gehört nicht zum guten Ton im Internet.
Mit dieser Option kann man den Bereich (Domain) einschränken, für den ein Neighbor-Cache abgefragt werden soll.
Man kann die Rangordnung von Neighbor-Caches auch von der Lage des betroffenen Objekts abhängig machen, die dann als Domain eingetragen wird. So kann derselbe Cache für eine Domain parent und für eine andere sibling sein.
Man kann alle eigenen Domains, die hinter einer gemeinsamen Firewall liegen, hier angeben, um den Algorithmus zur Objektanforderung zu beeinflussen.
Alle hier angebenen Domains werden immer direkt nach Objekten abgefragt, ohne den Umweg über Neighbor-Caches zu gehen.
Funktioniert wie local_domain, nur werden hier IP-Adressen benutzt.
Funktioniert wie inside_firewall, nur werden hier IP-Adressen benutzt.
Ist als Optimierung diese Option aktiviert, wird beim Nachfragen von Objekten im Falle eines einzigen möglichen parents der übliche Ablauf zur Objektfindung umgangen und direkt dieser parent befragt. Dabei spart man ein paar Pakete, die sonst über das Netzwerk gehen würden. Allerdings kann es auch sein, daß der betreffende parent nicht aktiv ist, was zu einer Fehlermeldung führt. Jeder sollte selbst wissen, was ihm lieber ist.
Diese Option dient dazu, Cache-Netzwerke ohne manuelle Aktionen aufzubauen. Das Problem dabei ist, daß die Automatik relativ viel Netzlast erzeugt und nicht immer optimal arbeitet.
Nach dem Ablauf dieser Zeitspanne wird eine von Neighbors nicht beantwortete Nachfrage von der normalen Datenquelle bezogen.
Hier angegebene URL-Textmuster werden vom lokalen Cache bearbeitet und nicht an Neighbors weitergegeben. Ein Anwendungsfall sind cgi-Links, bei denen das Caching unsinnig wäre.
URL-Textmuster hinter dieser Option bewirken, daß das betreffende Objekt nicht im Cache verbleibt, sondern sofort wieder entfernt wird. Auch hier sind cgi-Programme der erste Kandidat.
Wie cache_stoplist, nur daß hier regular expressions unterstützt werden.
Wie cache_stoplist_pattern, nur ist Groß-/Kleinschreibung hier nicht mehr relevant.
Dieser Parameter gibt an, wieviel physikalisches RAM zum Caching verwendet werden soll. Squid belegt in der Regel jedoch die zwei- bis vierfache Speichermenge, deshalb sollte der Wert nicht allzu großzügig bemessen werden. Hier sollte man bedenken, daß es für die Performance äußerst ungünstig ist, wenn Squid und seine Unterprozesse ausgelagert werden, da Festplattenzugriffe wesentlich langsamer als Hauptspeicherzugriffe sind. Andererseits sollte man aber bedenken, daß Squid WWW-Objekte zuerst im RAM puffert, um sie nach Bedarf dann auf die Festplatte auszulagern. Die optimale Einstellung der Hauptsspeichergröße hängt also stark von lokalen Gegebenheiten ab.
Die maximale Größe des permanenten Cache-Bereiches auf der Festplatte wird hier angegeben. Man muß jedoch in Betracht ziehen, daß Squid beim ersten Aufruf seine komplette Cache-Struktur in Form einer Verzeichnisstruktur bereits auf der Platte abbildet, was den verfügbaren Plattenplatz beschränkt. Dieser Wert sollte deshalb ca. 10% kleiner als der real verfügbare freie Festplattenspeicher sein, den man verwenden will - die Prozentangabe kann jedoch mit der verwendeten Inode-Dichte variieren. Squid reagiert etwas empfindlich, wenn der verfügbare Platz kleiner ist als der zugeteilte. Programmabbrüche können die Folge sein.
Squid verwendet LRU -Mechanismen, um Festplattenplatz freizugeben. Dieser Wert gibt an, bei welchem Füllgrad die Freigabe beendet werden soll. Der Wert wird in Prozent angegeben.
Wie cache_swap_low, nur wird hier der Wert angegeben, bei dem das Freigeben beginnen soll.
Dieser Wert gibt an, bei welchem Füllgrad des RAM-Cache das Auslagern auf die Festplatte beendet werden soll. Auch dieser Wert wird in Prozent angegeben.
Analog zu cache_mem_low wird hier der Füllgrad angegeben, bei dem das Auslagern beginnen soll.
Die maximale Größe von Objekten, welche noch im Cache aufbewahrt werden. Die Angabe ist in KByte.
Größe für den IP Cache, der zum Aufbewahren von Adressen benutzt wird.
Wie bei cache_mem und cache_swap kann man hier Schwellenwerte (in Prozent) angeben.
Hier wird das Verzeichnis angegeben, in dem Squid seinen Festplattencache anlegt. Werden mehrere cache_dir-Einträge angegeben, verteilt Squid seinen Cache auf alle Verzeichnisse; dies wirkt sich positiv auf die Performance aus, wenn die Verzeichnisse auf unterschiedlichen Festplatten liegen, da dann parallele Zugriffe möglich werden. Die optimale Lösung ist sicher ein RAID-Array, was jedoch nicht gerade preiswert ist.
Pfad und Name der Logdatei für Anfragen von Client-Rechnern.
Pfad und Name der Datei für Debug-Ausgaben von Squid.
Die Logdatei für den Storage Manager von Squid wird hier angegeben.
Diese Datei enthält die Metadaten für die Cache-Verwaltung. Normalerweise liegt sie im ersten cache_dir-Verzeichnis, man kann jedoch auch eine alternative Datei angeben. Sollte diese Datei gelöscht oder beschädigt werden, hat dies Auswirkungen beim Neustart, da Squid aus dieser Datei den Inhalt des Festplatten-Cache rekonstruiert.
Man kann Squid anweisen, für das Logfile ein Format zu verwenden, das z.B. vom CERN httpd verwendet wird, wenn man für dieses Format bereits Tools zur Auswertung besitzt.
Die MIME-Header von HTTP-Transaktionen können mit dieser Option protokolliert werden.
Der Name des verwendeten Clients kann mit dieser Option protokolliert werden.
In diese Datei schreibt squid seine Prozeß-ID, was für einige Automatisierungen praktisch ist.
Die verschiedenen Debug-Level können hier eingestellt werden.
Auf Wunsch verwendet squid RFC 931-Anfragen, um den jeweiligen Benutzer mitzuprotokollieren.
Mit dieser Option werden die kompletten Rechnernamen von jedem Zugriff mit ins Logfile geschrieben.
Man kann die Host-Bits von geloggten IP-Adressen mit dieser Maske ausblenden, um die Privatsphäre seiner Anwender sicherzustellen.
Hier kann das Programm, das für FTP-Aktionen verwendet werden soll, angegeben werden.
Eventuell erforderliche Parameter für das ftpget_program kann man hier angeben.
Die zu verwendende Login-Kennung für FTP-Aktionen wird hier eingestellt.
Das Programm für DNS-Auflösung wird mit dieser Option spezifiziert.
Die Anzahl von DNS-Serverprozessen wird hier angegeben, ist sie zu gering, nimmt die Performance von squid rapide ab.
Ermöglicht die Auflösung von Rechnernamen, die nur aus der Namenskomponente bestehen (d.h. kein Domainsuffix haben).
Mit diesem Programm werden nicht mehr benötige Cache-Dateien gelöscht.
Dieses Programm wird verwendet, um Neighbors zu kontaktieren.
Das Programm für URL-Redirection kann hier eingestellt werden. Momentan ist dem Squid-Paket noch kein solches Programm beigelegt, man muß also selbst kreativ werden, wenn man diese Funktionalität benötigt.
Gibt an, wie viele Instanzen von redirect_program gestartet werden sollen.
Dient dazu, WAIS (wide area information service) Anfragen an eine konfigurierbaren Rechner weiterzuleiten.
Diese Option dient zur Einstellung der maximalen Größe für Objekte, vor allem bei POST-Operationen (d.h. Upload-Vorgängen) sollte dieser Wert ausreichnend groß dimensioniert sein.
Hier kann der Refresh-Algorithmus von squid für die eigenen Bedürfnisse optimiert werden.
Wie refresh_pattern, nur, daß Musterangaben die Groß-/Kleinschreibung ignorieren.
Diese Angabe verändert den Wert den maximalen Wert für den LRU-Mechanismus des Cache-Systems, was bedeutet, daß Objekte, die im vergangenen Zeitraum reference_age nicht mehr angefordert wurden, aus dem Cache entfernt werden. Diese Option ist nicht gültig für das Entfernen von älteren Objekten, wenn der Cache zu voll wird. Hier werden immer die nach LRU ältesten Einträge zuerst entfernt, was sich auch durch hohe Werte von reference_age nicht unterbinden läßt.
Hier kann eingestellt werden, ob und wann ein vom Benutzer abgebrochener Download eines Objekts trotzdem noch weiter in den Cache geladen werden soll.
Hier kann eine Zeit angegeben werden, in der fehlerhafte Requests nicht neu geholt, sondern sozusagen vom Cache als fehlerhaft eingestuft werden, was auch dem Benutzer mitgeteilt wird. TTL bedeutet time to live.
Der Zeitraum, für den eine erfolgreiche DNS-Auflösung gespeichert wird, kann hier eingestellt werden.
Wie bei negative_ttl kann hier die Speicherdauer von fehlgeschlagenen DNS-Auflösungen parametriert werden.
Timeouts sind erforderlich, um nicht bestätigte Netzwerkanfragen nach einer gewissen Zeitspanne abzubrechen. Würde man das unterlassen, wären sehr bald alle verfügbaren Ports verbraucht und der Proxy wäre nicht mehr fähig, seine Aufgaben zu erfüllen.
Gibt die Zeit an, in der der Verbindungsaufbau zum Cache-Server abgeschlossen sein muß. Bei Überschreitung dieser Zeitspanne wird die Verbindung abgebrochen.
Eine bereits aufgebaute Verbindung wird nach dieser Zeit der Inaktivität wieder beendet.
Die maximale Verbindungszeit für einen Client bei einem Objekttransfer. Bei Modemverbindungen sollte dieser Wert nicht zu knapp bemessen werden, da sonst der Download von größeren Dateien immense Probleme verursacht.
Gibt die Zeit an, die squid nach dem Erhalt von entsprechenden Signalen noch wartet, bis alle Verbindungen getrennt werden.
Dieser Konfigurationspunkt ist in der Datei squid.conf so gut beschrieben, daß man es nicht besser machen kann. Bei Bedarf suche man in dieser Datei im Abschnitt ACCESS CONTROLS nach diesbezüglichen Informationen.
Hier trägt man die E-Mail-Adresse des Betreuers ein, damit bei Bedarf ein Ansprechpartner vorhanden ist.
Dieser Eintrag ist erforderlich, wenn squid vom Administrator root gestartet wird (z.B. beim Booten). Hier sollte entweder ein sicherer Benutzer und eine sichere Gruppe eingetragen werden, die im System nur sehr beschränkte Rechte haben (wie nobody/nogroup), oder für squid wird ein neuer Benutzer und eine neue Gruppe angelegt. Nach dem Starten von squid ändert der Prozeß dann seine eigenen Zugriffsrechte, womit eventuelle Sicherheitsprobleme vermieden werden, die auftreten könnten, wenn squid als root-Prozeß läuft. Zu beachten ist hierbei, daß das Verzeichnis für die Cache-Daten sowie die Installationsverzeichnisse ebenfalls dem neuen Benutzer gehören müssen, sonst gibt das Programm etwas irreführende Fehlermeldungen aus, die zwar bei anderen Betriebssystemen gang und gäbe sind, einen Unix-Benutzer aber eher verwirren dürften.
Unter diesem Namen macht sich der Proxy bekannt. Dieser Name ist aber nicht frei wählbar, sondern sollte mit dem DNS-Eintrag des Computers übereinstimmen.
Dieser Service dient dazu, andere Squid-Betreiber zu finden, um Cache-Hierarchien aufzubauen.
Hier wird die Häufigkeit von Registrierungsmeldungen eingestellt.
Die genaue Adresse vom Empfänger der Registrierungsmeldungen kann hier angegeben werden. Der Inhalt von filename wird, sofern vorhanden, an die Meldung angefügt.
Hinter dieser etwas irreführenden Bezeichnung versteckt sich ein Proxy, der völlig anders funktioniert als man es erwarten würde:
Wegen dieser Arbeitsweise ergeben sich folgende Vorteile:
Die Nachteile seien jedoch auch kurz erwähnt:
Folgende Optionen steuern den HTTP Accelerator:
Gibt die Adresse und den Port des richtigen HTTP-Servers an.
Bei Aktivierung ist squid gleichzeitig Accelerator und Proxy.
Diese Option aktiviert den Accelerator für mehrere verschiedene HTTP-Server, allerdings ist diese Option etwas unsicher, da keine Überprüfung stattfindet. Deshalb sollte diese Option deaktiviert werden.
Diese Option enthält Einträge für den Test der DNS-Server, welcher beim Starten automatisch initiiert wird.
Hier kann angegeben werden, wie viele ältere Logfiles aufzubewahren sind, wenn zyklisch neue Logfiles angelegt werden. Ein Eintrag von 0 ermöglicht die Verwendung diverser Logfile-Auswertetools (siehe 6.2), denn dann kann das Logging kurzzeitig deaktiviert werden.
Der hier angebene Domain-Name (der mit einem Punkt beginnen muß), wird als Domain-Suffix an einzelne Rechnernamen angefügt.
Die Größe der Empfangspuffer für TCP-Sockets kann hier angeben werden.
Ein eventuell vorhandener SSL ( secure socket layer) -Proxy kann hier eingebunden werden.
Dieser Eintrag gibt an, ob alle nicht-GET-Anfragen (wie POST und PUT) weitergeleitet werden sollen, und wenn ja, auf welchen Rechner.
Man kann den Zugriff auf den Proxy auch beschränken und einzelnen Benutzern Paßwörter zur Freischaltung zuweisen.
Dieser HTML-Text wird in Fehlermeldungen eingebunden, um z.B. einen Link auf übergeordnete Seiten oder eine Mail-Funktion einzubauen.
Hier kann im Falle von nicht-öffentlichen Seiten eine Information für alle hinterlegt werden, die keinen Zugriff haben.
Diese Option bestimmt, wie sich squid gegenüber seinen Neighbors verhalten soll.
Hier kann die Puffergröße für UDP-Hit-Verbindungen eingestellt werden.
Diese Option beeinflußt das Speichermanagement von squid.
Die Angabe der Client-Adresse in weitergeleiteten Requests kann mit dieser Option unterdrückt werden.
Steuert das Verhalten beim Logging von ICP-Anfragen.
Bei der Verwendung der ICMP-Optionen werden Objekte, die auf nahegelegenen (d.h. durch weniger als minimum_direct_hops Netzwerkkomponenten getrennten) Servern vorhanden sind, direkt geladen.
Bei der Verwendung des cachemgr.cgi-Programmes können hier die einzelnen Abfragemöglichkeiten durch Paßwörter geschützt werden.
Im Verzeichnis für den Festplattencache wird die hier angegebene Anzahl von Unterverzeichnissen angelegt.
In jedem Unterverzeichnis im Verzeichnis des Festplattencache werden nochmals Verzeichnisse angelegt, die Anzahl kann hier eingestellt werden. Man sollte Bedenken, daß jedes Verzeichnis Platz auf der Festplatte belegt, was den Speicherplatz für Cache-Objekte verringert.
Die durchschnittlich erwartete Objektgröße, dieser Wert wird benötigt, um diverse Statistiken aufstellen zu können.
Objektanzahl in jeder logischen Einheit der Hashtable-Verwaltung für die Cacheobjekte.
Verändert die Angaben, die vom Client-Programm zum jeweiligen Webserver weitergegeben werden. Hier kann die Funktionalität von WWW-Anonymizern nachgebildet werden.
Diese Option faßt alle Statistiken zusammen und unterscheidet nicht nach einzelnen Clients.
Diese Angaben steuern die ICMP-Verwaltung, im Gegensatz zu ähnlichen Optionen sind hier Werte, keine Prozentangaben, anzugeben.
Diese Option gibt die obere Schwelle für die ICMP-Verwaltung an und gehört damit zu netdb_low.
Gibt den Zeitabstand von ICMP-Pings an.
Fordert von Rechnern im Cacheverbund ICMP-Informationen an, um Laufzeitoptimierungen zu ermöglichen.
Aktiviert die Anzeige von Cache-Hits für bereits ,,abgelaufene`` Objekte, was manchmal bei lokalen Cache-Hierarchien praktisch sein kann.
