Squid-Einführung - Versionsgeschichte

Thomas.will am 13. Februar 2023 um 13:18 Uhr

2023-02-13T13:18:27Z

Thomas.will: /* ads mitglied */

2022-09-27T07:54:49Z

ads mitglied

Thomas.will: /* ads mitglied */

2022-09-27T07:53:16Z

ads mitglied

Thomas.will: /* ads mitglied */

2022-09-27T07:52:46Z

ads mitglied

Thomas.will: /* sarg */

2022-09-27T07:52:30Z

sarg

Thomas.will am 4. September 2022 um 17:54 Uhr

2022-09-04T17:54:26Z

Thomas.will: /* Sinnvolles Caching */

2022-09-04T17:53:20Z

Sinnvolles Caching

Thomas.will: /* Funktionsbeschreibung */

2022-09-04T17:48:05Z

Funktionsbeschreibung

Thomas.will: /* =Entkernen der squid.conf */

2022-09-04T17:34:40Z

=Entkernen der squid.conf

Thomas.will: /* Konfiguration */

2022-09-04T17:34:31Z

Konfiguration

← Nächstältere Version		Version vom 13. Februar 2023, 13:18 Uhr
Zeile 1:		Zeile 1:
−	*[[Squid Grundlagen]]	+

	=Squid unter Ubuntu=		=Squid unter Ubuntu=

@@ Zeile 423: / Zeile 423: @@
 =ads mitglied=
-*http://blog.stefan-betz.net/2009/1/7/hochzeit:-squid-3-und-active-directory/
+*https://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos
-*http://www.woy.de/?p=29
 =Sarg=
 *[[Squid Sarg]]

@@ Zeile 425: / Zeile 425: @@
 *http://blog.stefan-betz.net/2009/1/7/hochzeit:-squid-3-und-active-directory/
 *http://www.woy.de/?p=29
+=Sarg=
 *[[Squid Sarg]]

← Nächstältere Version		Version vom 27. September 2022, 07:52 Uhr
Zeile 426:		Zeile 426:
	*http://www.woy.de/?p=29		*http://www.woy.de/?p=29

−	*[[Squid ~~Sqrg~~]]	+	*[[Squid Sarg]]

← Nächstältere Version		Version vom 27. September 2022, 07:52 Uhr
Zeile 426:		Zeile 426:
	*http://www.woy.de/?p=29		*http://www.woy.de/?p=29

−	~~=sarg=~~	+	*[[Squid Sqrg]]
−
−	~~sudo apt-get install sarg apache2~~
−	~~sudo cp /etc/sarg/sarg.conf /etc/sarg/sarg.conf.old~~
−	~~sudo cat /etc/sarg/sarg.conf.old \| grep -v ^# \| grep -v ^$ > /etc/sarg/sarg.conf~~
−
−	~~Beim Benutzen von '''squid3''' muss der log-Pfad in der sarg.conf angepasst werden!~~
−	~~access_log /var/log/squid/access.log~~
−	~~ändern in~~
−	~~access_log /var/log/squid3/access.log~~
−
−	~~sudo ln -sv /var/lib/sarg/ /var/www/~~
−
−	~~==apache==~~
−	~~vi /etc/apache2/sites-available/000-default.conf~~
−	~~<pre>~~
−	~~<VirtualHost~~ *~~:80>~~
−	~~ServerAdmin technik@xinux.de~~
−	~~DocumentRoot /var/www/sarg~~
−	~~<Directory />~~
−	~~Options FollowSymLinks~~
−	~~AllowOverride None~~
−	~~</Directory>~~
−	~~<Directory /var/www/sarg/>~~
−	~~AllowOverride None~~
−	~~Order allow,deny~~
−	~~Allow from all~~
−	~~</Directory>~~
−	~~ErrorLog ${APACHE_LOG_DIR}/error-sarg.log~~
−	~~LogLevel warn~~
−	~~CustomLog ${APACHE_LOG_DIR}/access-sarg.log combined~~
−	~~</VirtualHost>~~
−	~~</pre>~~
−
−	~~echo "ServerName $HOSTNAME" >> /etc/apache2/apache2.conf~~
−	~~service apache2 restart~~
−
−	~~sudo sarg-reports today~~
−	~~http://SERVERIP/sarg~~

@@ Zeile 1: / Zeile 1: @@
-=Einleitung=
+*[[Squid Grundlagen]]
 =Squid unter Ubuntu=
 ==Installation==

@@ Zeile 30: / Zeile 30: @@
 [[Image:squid2.jpg]]
 ==Sinnvolles Caching==
-*Um ein sinnvolles Caching zu erreichen, müssen gewisse Voraussetzungen gegeben sein.
+*Ein viel größeres Problem ist es, daß die Lebensdauer von Web-Seiten sehr unterschiedlich ist.
-*Diese fangen damit an, daß die Maschine, auf der ein solcher Proxy-Server läuft von der Hardware entsprechend ausgestattet sein muß.
+*Dadurch kann nie mit Sicherheit bestimmt werden, wann sich eine Seite ändert und dadurch veraltet ist und aus dem Cache gelöscht, bzw. beim Server neu angefordert werden soll.
-*Je nach der Anzahl der Clients, die den Proxy benutzen muß die Leistungsfähigkeit des Rechners ausgelegt sein, damit auch genügend Anfragen gleichzeitig bearbeitet werden können.
+*Es kann also immer vorkommen, daß der Cache ein veraltetes Dokument an den Client liefert.
-*Um die Trefferquote auf die im Cache abgelegten Objekte zu erhöhen, sollte auch entsprechende Speicherkapazität vorhanden sein.
+*Durch verschiedene Strategien wird versucht, dieses Manko so weit wie möglich auszugleichen.
-*Diese sollte auf jeden Fall mehrere Gigabyte umfassen.
+*HTTP bietet dazu zwei Möglichkeiten: Last-Modified und Expires.
-*Da aber in der letzten Zeit die Preise für Festplattenspeicher enorm nach unten gegangen sind, sollte dies heute kein größeres Problem mehr darstellen.
+*Mit der Antwort des Servers werden diese Information an den Proxy mitgeteilt.
-Die Hardwarevoraussetzungen alleine machen aber noch keinen guten Proxy-Cache aus, sondern bilden nur eine solide Grundlage. Ein viel größeres Problem ist es, daß die Lebensdauer von Web-Seiten sehr unterschiedlich ist. Dadurch kann nie mit Sicherheit bestimmt werden, wann sich eine Seite ändert und dadurch veraltet ist und aus dem Cache gelöscht, bzw. beim Server neu angefordert werden soll. Es kann also immer vorkommen, daß der Cache ein veraltetes Dokument an den Client liefert. Durch verschiedene Strategien wird versucht, dieses Manko so weit wie möglich auszugleichen.
+*Mit Last-Modified wird angezeigt, wann das Dokument das letzte mal geändert wurde.
-HTTP bietet dazu zwei Möglichkeiten: Last-Modified und Expires. Mit der Antwort des Servers werden diese Information an den Proxy mitgeteilt. Mit Last-Modified wird angezeigt, wann das Dokument das letzte mal geändert wurde. Mit der Angabe Expires erhält der Client (in diesem Falle der Proxy) Informationen, wann er das Dokument als veraltet ansehen soll und vom Server neu anfordern muß. In einem HTML-Dokument werden diese Angaben im Header generiert. Dazu wird das META-Element benutzt. Die Informationen sehen dann wie im folgenden Beispiel aus:
+*Mit der Angabe Expires erhält der Client (in diesem Falle der Proxy) Informationen, wann er das Dokument als veraltet ansehen soll und vom Server neu anfordern muß.
+*In einem HTML-Dokument werden diese Angaben im Header generiert.
 <META HTTP-EQUIV=“Last-Modified“ CONTENT=“Thu Jan 1 12:00:00 GMT DST 1998“>
@@ Zeile 44: / Zeile 46: @@
 <META HTTP-EQUIV=“Expires“ CONTENT=“Thu Dec 31 12:00:00 GMT DST 1998“>
-Allein die Expires-Angabe würde reichen, um den Cache in dieser Hinsicht zu optimieren. Jedoch sind diese Angaben optional und werden sehr selten eingesetzt. Außerdem ist es oft schwierig die Lebensdauer einer Web-Seite vorauszusagen. Daher sind die meisten Web-Seiten einfach so lange gültig, bis der Autor eine neue Version erstellt. Anders sieht es bei Last-Modified aus. Diese Angabe findet sich zwar selten explizit in HTML-Dokumenten, jedoch trägt jedes Dokument als Datei einen Zeitstempel, welcher vom Server dann als Last-Modified-Header mitgeliefert wird.
+*Allein die Expires-Angabe würde reichen, um den Cache in dieser Hinsicht zu optimieren.
+*Jedoch sind diese Angaben optional und werden sehr selten eingesetzt.
-Die Proxy-Server wenden damit ein einfaches Verfahren ein, um die Lebensdauer eines Dokumentes zu „erraten“. Dabei wird zugrunde gelegt, daß die Wahrscheinlichkeit recht gering ist, daß ein recht altes Dokument in den nächsten Stunden geändert wird. Bei einem Dokument, welches dagegen erst vor kurzem geändert wurde, ist die Möglichkeit einer baldigen Aktualisierung eher vorhanden.Sofern ein Objekt keinen Expires-Header aufweist, erzeugt der Proxy-Server mit Hilfe des Last-Modified-Headers ein künstliches Verfallsdatum. Dazu bestimmt er das Alter der Datei und schlägt einen Prozentsatz dazu, der bei der Konfiguration des Proxy-Servers eingetragen wird (Direktive refresh_pattern), und holt frühestens nach Ablauf dieser Zeit von sich aus das Dokument erneut vom Server.
+*Außerdem ist es oft schwierig die Lebensdauer einer Web-Seite vorauszusagen.
+*Daher sind die meisten Web-Seiten einfach so lange gültig, bis der Autor eine neue Version erstellt.
+* Anders sieht es bei Last-Modified aus.
+*Diese Angabe findet sich zwar selten explizit in HTML-Dokumenten, jedoch trägt jedes Dokument als Datei einen Zeitstempel,
-Ist beispielsweise ein Dokument zum Zeitpunkt der ersten Anfrage des Proxies bereits 150 Tage alt und der Prozentsatz aus der Konfiguration ist 20%, so vergehen weitere 30 Tage, bis der Proxy-Server eine erneute Anfrage an den Originalserver stellt.
+*Dieser wird vomServer dann als Last-Modified-Header mitgeliefert.
+*Die Proxy-Server wenden damit ein einfaches Verfahren ein, um die Lebensdauer eines Dokumentes zu „erraten“.
-Um dies weiter zu optimieren wird das Dokument nur dann übertragen, wenn die Version auf dem Originalserver wirklich neuer ist, als die im Cache gespeicherte. Dazu schickt der Proxy eine Anfrage an den Originalserver, in der nur der Zeitstempel der Datei enthalten ist. Der Server vergleicht nun den empfangenen Zeitstempel der angeforderten Datei und sendet diese nur dann vollständig zurück, wenn sie jünger ist, als die im Proxy-Cache hinterlegte Kopie. Im anderen Falle erhält der Proxy nur eine kurze, aus HTTP-Headern bestehende Antwort, die signalisiert, daß keine Änderung stattgefunden hat. Der Proxy registriert dies und errechnet ein neues Verfallsdatum.
+*Dabei wird zugrunde gelegt, daß die Wahrscheinlichkeit recht gering ist, daß ein recht altes Dokument in den nächsten Stunden geändert wird.
+*Bei einem Dokument, welches dagegen erst vor kurzem geändert wurde, ist die Möglichkeit einer baldigen Aktualisierung eher vorhanden.
-Neben diesen statischen Objekten, die eine gewisse Lebensdauer haben, gibt es aber auch dynamische Objekte, bei denen eine Zwischenspeicherung nicht angebracht ist. Dies sind beispielsweise HTML-Seiten, die ein CGI-Skript für Datenbankabfragen enthalten oder Seiten, die eine Berechtigung verlangen.
+*Sofern ein Objekt keinen Expires-Header aufweist, erzeugt der Proxy-Server mit Hilfe des Last-Modified-Headers ein künstliches Verfallsdatum.
+*Dazu bestimmt er das Alter der Datei und schlägt einen Prozentsatz dazu, der bei der Konfiguration des Proxy-Servers eingetragen wird *(Direktive refresh_pattern)
-Es kann von beiden Seiten erzwungen werden, daß ein Objekt nicht im Cache gespeichert wird. Auf Seiten des Proxy-Servers erfolgt dies durch eine Einstellung in der Konfiguration. Damit ist es möglich, daß Seiten, die bestimmte Elemente (z.B. cgi-bin, ?, o.ä.) im URL enthalten nicht gespeichert werden. Dies kann man auch für ausgewählte Domänen angeben, was dann sinnvoll ist, wenn sich der Cache in einem Netz befindet, in dem selbst Web-Seiten angeboten werden.
+*Es holt frühestens nach Ablauf dieser Zeit von sich aus das Dokument erneut vom Server.
-Befindet sich beispielsweise der Proxy-Cache in dem Netz der Domäne testdomain.de, womöglich sogar auf dem selben Rechner wie der Web-Server, so wäre es Unsinn, die Seiten, die dort angeboten werden in den Cache zu legen, da dies unnötig Speicher verbraucht. Von Seiten des Anbieters kann dies über den Einbau einer Authentisierung erfolgen. Dadurch wird bei der Abfrage eines Objektes nach einer Benutzerkennung und einem Paßwort gefragt. Diese Informationen und auch Seiten, die eine Identifikation verlangen, werden standardmäßig nicht vom Proxy gespeichert und müssen jedesmal neu vom Originalserver geholt werden.
+*Ist beispielsweise ein Dokument zum Zeitpunkt der ersten Anfrage des Proxies bereits 150 Tage alt
 ==Hierarchisches Caching==

@@ Zeile 81: / Zeile 81: @@
 =Funktionsbeschreibung=
-Squid, der Internet Object Cache, ist jedoch mehr als ein einfacher Cache-Proxy. Durch die Unterstützung von Neighbor-Caches, die entweder als parent oder sibling verwendet werden, kann man einen Cache-Verbund aufbauen, der einen hohen Prozentsatz von Anfragen beantworten kann, ohne langwierige Internet-Zugriffe zu erfordern. Dieses Verfahren verwenden zum Beispiel einige der großen Internet-Provider (wie ECRC in München), um den Datentransfer wenn möglich auf der eigenen Netzwerkstruktur abzuwickeln und damit Kosten für externe Zugriffe zu umgehen.
+*Squid, der Internet Object Cache, ist jedoch mehr als ein einfacher Cache-Proxy.
-Die Arbeitsweise von Squid ist einfach:
+==Die Arbeitsweise von Squid ist einfach==
-Eine Anfrage eines Clients wird zuerst auf die Zugriffsberechtigung untersucht, so kann man z.B. gewissen Rechnern einen Zugriff auf den Proxy ganz verbieten (siehe Konfiguration).
+*Eine Anfrage eines Clients wird zuerst auf die Zugriffsberechtigung untersucht, so kann man z.B. gewissen Rechnern einen Zugriff auf den Proxy ganz verbieten (siehe Konfiguration).
+*Es wird versucht, die gewünschten Daten im lokalen Cache zu finden. Sollte dies fehlschlagen, werden andere Proxies im Cache-Verbund (sofern vorhanden), abgefragt.
-Es wird versucht, die gewünschten Daten im lokalen Cache zu finden. Sollte dies fehlschlagen, werden andere Proxies im Cache-Verbund (sofern vorhanden),
+*Sind die Daten vorhanden, wird ihre Aktualität geprüft. Sind die Daten veraltet, werden neue in den Cache geholt und an den Client weitergegeben.
-abgefragt.
+*Bei aktuellen Daten wird das Neuladen übersprungen.
+*Sind die Daten nicht vorhanden, werden sie in den Cache geladen und an den Client weiter-gereicht.
-Sind die Daten vorhanden, wird ihre Aktualität geprüft. Sind die Daten veraltet, werden neue in den Cache geholt und an den Client weitergegeben. Bei aktuellen Daten wird das Neuladen übersprungen.
+*Wie lange Daten im Cache verbleiben, ist abhängig von der Konfiguration (siehe dort)
+*Eine Beschreibung der internen Abläufe wurde im Sinne der Übersichtlichkeit weggelassen.
 =Hilfe und Dokumentation zu Squid=

@@ Zeile 212: / Zeile 212: @@
 *Kann man sie zunächst einmal auf das Wichtigste reduzieren.
 *Vorher sollte die originale squid.conf gesichert werden:
-==Entkernen der squid.conf=
+==Entkernen der squid.conf==
 *cp squid.conf squid.conf.org
 *grep  "^[^#]" squid.conf.org > squid.conf