Diese Ausgabe gilt für:
Außerdem gilt diese Ausgabe für alle nachfolgenden Releases und Änderungen, sofern in den neuen Ausgaben keine anderen Hinweise enthalten sind.
Veröffentlichungen können über den zuständigen IBM Ansprechpartner oder die zuständige IBM Geschäftsstelle bezogen werden.
Diese Veröffentlichung ist eine Übersetzung des Handbuchs
IBM WebSphere Application Server Caching Proxy Administration Guide, Version 6.1,
IBM Form GC31-6920-00,
herausgegeben von International Business Machines Corporation, USA
(C) Copyright International Business Machines Corporation 2006
(C) Copyright IBM Deutschland GmbH 2006
Informationen, die nur für bestimmte Länder Gültigkeit haben und für Deutschland, Österreich und die Schweiz nicht zutreffen, wurden in dieser Veröffentlichung im Originaltext übernommen.
Möglicherweise sind nicht alle in dieser Übersetzung aufgeführten Produkte in Deutschland angekündigt und verfügbar; vor Entscheidungen empfiehlt sich der Kontakt mit der zuständigen IBM Geschäftsstelle.
Änderung des Textes bleibt vorbehalten.
Dieses Vorwort beschreibt Zielgruppe, Zweck und Aufbau des Handbuchs, Eingabehilfen, Konventionen und Terminologie sowie Referenzliteratur.
Das Caching Proxy Administratorhandbuch wurde für erfahrene Netz- und Systemadministratoren geschrieben, die mit ihrem Betriebssystem und mit der Bereitstellung von Internet-Services vertraut sind. Vorkenntnisse in Caching Proxy sind nicht erforderlich.
Dieses Handbuch bietet keine Unterstützung für frühere Releases von Caching Proxy.
Diese Dokumentation richtet sich in Bezug auf Typografie und Hervorhebung nach den folgenden Konventionen.
Konvention | Bedeutung |
---|---|
Fettschrift | Bei Bezugnahme auf grafische Benutzerschnittstellen (GUIs) werden Menüs, Menüpunkte, Titel, Knöpfe (Schaltflächen), Symbole und Ordner in Fettschrift dargestellt. Die Fettschrift kann auch zum Hervorheben von Befehlsnamen verwendet werden, die sonst mit dem Begleittext verwechselt werden könnten. |
Monospace-Schrift | Kennzeichnet Text, der an der Eingabeaufforderung eingegeben werden muss. In Monospace-Schrift werden auch Anzeigetexte, Codebeispiele und Dateiauszüge hervorgehoben. |
Kursivschrift | Kennzeichnet Variablenwerte, die eingegeben werden müssen (z. B. müssen Sie Dateiname durch den Namen einer Datei ersetzen). Kursivschrift wird außerdem für Hervorhebungen und Handbuchtitel verwendet. |
Strg-x | Diese Angabe kennzeichnet eine Tastenkombination mit der Steuerungstaste. x steht hier für eine Tastenbezeichnung. Beispielsweise bedeutet die Angabe <Strg-c>, dass Sie die Taste Strg gedrückt halten und gleichzeitig die Taste c drücken sollen. |
Eingabetaste | Bei dieser Angabe müssen Sie die Eingabetaste drücken. |
% | Steht in der Linux- und UNIX-Befehlsumgebung für die Aufforderung zur Eingabe eines Befehls, der keine Root-Berechtigung erfordert. |
# | Steht in der Linux- und UNIX-Befehlsumgebung für die Aufforderung zur Eingabe eines Befehls, der Root-Berechtigung erfordert. |
C:\ | Steht für die Eingabeaufforderung in der Windows-Umgebung. |
Befehlseingabe | Wenn Sie aufgefordert werden, einen Befehl einzugeben, geben Sie den Befehl ein und drücken Sie dann die Eingabetaste. Beispiel: Die Anweisung "Geben Sie den Befehl ls ein" bedeutet, dass Sie an der Eingabeaufforderung ls eingeben und anschließend die Eingabetaste drücken müssen. |
[ ] | In eckigen Klammern werden optionale Elemente in Syntaxbeschreibungen angegeben. |
{ } | In geschweiften Klammern werden Listen in Syntaxbeschreibungen angegeben, aus denen Sie einen Eintrag auswählen können. |
| | Dieses Zeichen trennt in Syntaxbeschreibungen die Einträge in einer Auswahlliste, die in geschweiften Klammern ({ }) angegeben ist. |
... | Drei Punkte in Syntaxbeschreibungen bedeuten, dass der vorherige Eintrag einmal oder mehrmals wiederholt werden kann. Drei Punkte in Beispielen bedeuten, dass Informationen weggelassen wurden, um die Darstellung zu vereinfachen. |
Features zur Erleichterung des Zugriffs helfen körperbehinderten Benutzern (mit eingeschränkter Beweglichkeit oder Sehschwäche), Softwareprodukte erfolgreich anzuwenden. WebSphere Application Server Version 6.1 bietet im Wesentlichen die folgenden Features für verbesserte Zugriffsmöglichkeiten an:
Ihre Rückmeldung ist uns wichtig, damit wir möglichst genaue und hochwertige Informationen bieten können. Wenn Sie Kommentare zu diesem Handbuch oder anderen Dokumentationen zu Edge Components von WebSphere Application Server abgeben möchten, gehen Sie wie folgt vor:
Dieser Teil enthält eine Übersicht über die Komponente Caching Proxy, Anweisungen zur Verwendung der Konfigurations- und Verwaltungsformulare und des Konfigurationsassistenten, Anweisungen zum manuellen Editieren der Datei ibmproxy.conf und Prozeduren zum Starten und Stoppen des Proxy-Servers.
Dieser Teil enthält die folgenden Kapitel:
Konfigurations- und Verwaltungsformulare verwenden
Den Konfigurationsassistenten verwenden
Die Datei ibmproxy.conf manuell editieren
Caching Proxy starten und stoppen
Die Komponente Caching Proxy fängt Datenanforderungen von Clients ab, ruft die angeforderten Informationen von den Maschinen ab, die Inhalte bereitstellen, und liefert die abgerufenen Inhalte an die Clients. Meistens beziehen sich die Anforderungen auf Dokumente, die auf Webserver-Maschinen (auch Ursprungsserver oder Inhaltshosts genannt) gespeichert und mit Hypertext Transfer Protocol (HTTP) zugestellt werden. Sie können Caching Proxy jedoch auch für die Verwendung anderer Protokolle wie File Transfer Protocol (FTP) und Gopher konfigurieren.
Caching Proxy legt Inhalte, die zwischengespeichert werden können, vor der Zustellung an den Requester in einem lokalen Cache ab. Beispiele für solche im Cache speicherbaren Inhalte sind statische Webseiten und JSP-Dateien mit dynamisch generierten, aber sich nur selten ändernden Fragmenten. Durch die Zwischenspeicherung (oder Caching) ist Caching Proxy in der Lage, nachfolgende Anforderungen für denselben Inhalt direkt aus dem Cache bereitzustellen, was sehr viel schneller ist als ein erneuter Abruf des Inhalts vom Inhaltshost.
Wichtig: Caching Proxy ist mit folgender Ausnahme in allen Edge-Components-Installationen verfügbar:
Die beiden Basiskonfigurationen des Proxy-Servers sind Reverse Proxy und Forward Proxy.
Caching Proxy ist standardmäßig als Reverse-Proxy-Server konfiguriert. In einer Reverse-Proxy-Konfiguration befindet sich ein Proxy-Server zwischen einem oder mehreren Inhaltsservern und dem Internet. Er akzeptiert Anforderungen von Internet-Clients für Inhalt, der auf der Home-Site des Proxy-Servers gespeichert ist. Für den Client scheint der Proxy-Server der ursprüngliche Inhaltsserver zu sein. Ihm wird nicht gewahr, dass die Anforderung an einen anderen Server gesendet wurde.
Alternativ können Sie Caching Proxy als Forward-Proxy-Server konfigurieren. Client-Browser müssen zur Verwendung des Proxy-Servers jedoch individell konfiguriert werden. In einer Forward-Proxy-Konfiguration befindet sich ein Proxy-Server zwischen dem Client und dem Internet. Caching Proxy leitet eine Clientanforderung an Inhaltshosts im Internet weiter, stellt die abgerufenen Daten in den Cache und stellt die abgerufenen Daten dem Client zu.
Nehmen Sie die folgenden Änderungen in der Konfigurationsdatei ibmproxy.conf vor, um die Forward-Proxy-Konfiguration zu aktivieren:
Proxy http:* Proxy ftp:* Proxy gopher:*
SSLTunneling OnWeitere Informationen zur SSL-Tunnelung finden Sie im Abschnitt SSL-Tunnelung konfigurieren.
Enable CONNECT OutgoingPorts Alloder
Enable CONNECT OutgoingPorts 443
Weitere Informationen zum Format und den verfügbaren Optionen für die Methode Enable CONNECT finden Sie im Abschnitt SSL-Tunnelung konfigurieren.
Wenn Sie diese Änderungen vornehmen, kann der Forward Proxy die folgenden Aktionen ausführen:
Eine Variante von Caching Proxy als Forward-Proxy-Server ist ein transparenter Caching Proxy. In dieser Rolle führt Caching Proxy dieselbe Funktion wie ein Basis-Forward-Caching-Proxy aus, aber der Client ist sich seiner Präsenz nicht bewusst. Die transparente Caching-Proxy-Konfiguration wird nur auf Linux-Systemen unterstützt.
Wie der reguläre Forward-Caching-Proxy wird der transparente Caching Proxy auf einer Maschine in der Nähe des Internet/Gateway installiert, aber die Client-Browser-Programme werden nicht so konfiguriert, dass sie Anforderungen an einen Forward-Caching-Proxy weiterleiten. Die Clients sind sich nicht bewusst, dass ein Proxy-Server in der Konfiguration vorhanden ist. Stattdessen wird ein Router konfiguriert, der die Clientanforderungen abfängt und an den transparenten Caching Proxy weiterleitet.
Weitere Informationen zur Anweisung für diese Konfiguration finden Sie im Abschnitt TransparentProxy - Für Linux den transparenten Proxy-Server aktivieren.
Das Caching Proxy Administratorhandbuch für Version 6.1 dokumentiert neue Features und fehlerbehebende Aktualisierungen.
Im Folgenden sind die wichtigsten Features aufgelistet:
Informationen zum Konfigurieren eines Forward Proxy finden Sie im Abschnitt Forward Proxy.
Informationen zur Anweisung für transparente (Forward) Proxy-Konfigurationen finden Sie im Abschnitt TransparentProxy - Für Linux den transparenten Proxy-Server aktivieren.
Informationen zu diesen Methoden finden Sie im Abschnitt WebDAV-Methoden, MS-Exchange-Methoden und benutzerdefinierte Methoden.
Informationen zu diesen Anweisungen finden Sie in den Abschnitten CompressionFilterAddContentType - Inhaltstyp der zu komprimierenden HTTP-Antwort angeben und CompressionFilterEnable - Enable the compression filter to compress the HTTP responses.
Informationen zu dieser Anweisung finden Sie im Abschnitt NoCacheOnRange - Angeben, das für Range-Anforderungen kein Caching verwendet wird.
Informationen zu dieser Anweisung finden Sie im Abschnitt OptimizeRuleMapping - Regelzuordnungsprozess für eingehende Anforderungen bei zunehmender Anzahl von Regeln optimieren.
Ähnlich wie die Anweisung Map verwendet die Anweisung MapQuery den Pfad und die Abfragezeichenfolge für den Abgleich mit der Regel.
Informationen zu dieser Anweisung finden Sie im Abschnitt MapQuery - Anforderungen, deren Anforderungspfad und Abfragezeichenfolge der Regel entsprechen, in eine neue Anforderungszeichenfolge ändern.
Informationen zu dieser Anweisung finden Sie im Abschnitt RuleCaseSense - Anforderungen von Anwendungs-URL zuordnen, die nicht zwischen Groß- und Kleinschreibung unterscheiden.
Informationen zu diesen Anweisungen finden Sie im Abschnitt PKCS11DefaultCert, PKCS11DriverPath, PKCS11TokenPassword - Unterstützung für IBM 4960 PCI Cryptographic Accelerator Card (nur AIX).
Informationen zur Angabe von logischen Ausdrücken in dieser Anweisung finden Sie im Abschnitt SSLCertificate - Schlüsselkennsätze für Zertifikate angeben.
Caching Proxy unterstützt Anweisungen, die zur Laufzeit eine zusätzlichen Mustererkennung erfordern. Zur Verbesserung der Caching-Proxy-Leistung können Sie diese Anweisungen als Optionen in der Proxy- oder ProxyWAS-Regel verwenden. Weitere Informationen zu diesen zusätzlichen Optionen für Proxy- und ProxyWAS-Regeln finden Sie im Abschnitt Proxy - Proxy-Protokolle oder einen Reverse Proxy angeben.
Caching Proxy stellt HTML-Formulare bereit, die an die anfragenden Clients gesendet und zur Konfiguration des Proxy-Servers verwendet werden können. Diese Formulare führen CGI-Programme aus, die die lokale Konfigurationsdatei des Proxy-Servers, ibmproxy.conf, editieren. Zur Verwendung dieser Formulare muss der Proxy-Server aktiv und so konfiguriert sein, dass er die Formulare aus dem lokalen Verzeichnis, in dem sie gespeichert sind, bereitstellt.
Standardmäßig wird Caching Proxy so installiert, dass die Datei ibmproxy.conf Pass-Anweisungen enthält, die den Zugriff auf die Konfigurations- und Verwaltungsformulare ermöglichen. Wenn ein Client die Standard-Homepage von diesem Proxy-Server anfordert, wird die Datei Frntpage.html zurückgegeben. Diese Seite enthält einen Hypertext-Link auf die Startseite der Konfigurations- und Verwaltungsformulare (wte.html).
Die Konfigurations- und Verwaltungsformulare sind geschützt und erfordern eine Clientauthentifizierung, bevor sie den Clients bereitgestellt werden. Anweisungen zur Konfiguration von ID und Kennwort des Administrators finden Sie im Abschnitt Das Administratorkennwort festlegen.
Ein Webbrowser, der für den Zugriff auf die Konfigurations- und Verwaltungsformulare verwendet wird, muss Folgendes unterstützen:
Empfohlene Browser sind Mozilla und Firefox (für Linux-, UNIX- und Windows-Systems) sowie Internet Explorer (für Windows-Systeme). Informationen zu speziellen Versions der Browser Mozilla, Firefox und Internet Explorer finden Sie auf der folgenden Website. Folgen Sie den Links zur Webseite mit Informationen zur unterstützten Software: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Gehen Sie wie folgt vor, um die Konfigurations- und Verwaltungsformulare aufzurufen:
http://Name.Ihres.Servers[:Port][/Verzeichnis][/Seite.html]Die Parameter sind im Folgenden erläutert:
Die gewünschten Konfigurationsänderungen wurden erfolgreich durchgeführt.Wird die Eingabe nicht akzeptiert, erscheint im oberen Rahmen eine Fehlernachricht, die die ungültigen Einstellungen enthält.
Nach der Installation der Caching-Proxy-Pakete müssen Sie eine Administrator-ID und ein Administratorkennwort für den Zugriff auf die Konfigurations- und Verwaltungsformulare erstellen. In der Standardkonfiguration des Proxy-Servers werden Benutzer, die die Konfigurations- und Verwaltungsformulare anfordern, anhand der Kennwortdatei webadmin.passwd im Verzeichnis /opt/ibm/edge/cp/server_root/protect/ (Linux- und UNIX-Systeme) bzw. im Verzeichnis \Programme\IBM\edge\cp\etc\ (Windows-Systeme) authentifiziert. Wenn die Datei webadmin.passwd vorhanden ist, wird diese bei der Installation eines Pakets nicht überschrieben.
Mit den folgenden Befehlen können Sie der Datei webadmin.passwd einen Administratoreintrag hinzufügen:
# htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwdGeben Sie auf Anforderung den Benutzernamen, das Kennwort und den realen Namen des Administrators für das Programm htadm ein.
cd "\Programme\IBM\edge\cp\server_root\protect\" htadm -adduser webadmin.passwd"Geben Sie auf Anforderung den Benutzernamen, das Kennwort und den realen Namen des Administrators für das Programm htadm ein.
Eine detaillierte Beschreibung des Befehls htadm finden Sie im Abschnitt Befehl htadm.
Mit dem Konfigurationsassistenten von Caching Proxy können Sie einen installierten Caching-Proxy-Server schnell konfigurieren. Dieses Programm legt nur die grundlegenden Anweisungen fest, die erforderlich sind, um das Verhalten von Caching Proxy in der Weise zu ändern, dass dieser als Ersatzserver verwendet wird. Möglicherweise müssen für den Proxy-Server noch weitere Konfigurationseinstellungen vorgenommen werden.
Gehen Sie wie folgt vor, um den Konfigurationsassistenten von Caching Proxy zu verwenden:
Klicken Sie unter Windows auf Start -> Programme -> IBM WebSphere -> Edge Components -> Caching Proxy -> Konfigurationsassistent.
Geben Sie auf Linux- und UNIX-Systemen den Befehl /opt/ibm/edge/cp/cpwizard/cpwizard.sh ein.
Port Port-Nummer Proxy /* http://Inhaltsserver :Port
Beispiele:
Proxy /* http://Inhaltsserver :443
oder
Proxy /* https://Inhaltsserver :443
Einschränkungen auf Linux-Systemen: Die Tastaturkurzbefehle funktionierten nicht für den Konfigurationsassistenten von Caching Proxy.
Caching Proxy kann durch Editieren der Konfigurationsdatei ibmproxy oder mit den Konfigurations- und Verwaltungsformularen manuell konfiguriert werden.
Die Konfigurationsdatei setzt sich aus Anweisungen zusammen. Zum Ändern der Konfiguration müssen Sie die Konfigurationsdatei in einem Editor öffnen, die Anweisungen ändern und Ihre Änderungen anschließend speichern. Sie können beinahe jeden Texteditor, z. B. emacs und vi, zum Editieren der Konfigurationsdatei verwenden.
Die in der Konfigurationsdatei vorgenommenen Änderungen werden nach dem Neustart des Servers wirksam, sofern Sie keine der Anweisungen geändert haben, die in der Tabelle 6 aufgeführt sind. Wenn Sie eine der Anweisungen aus dieser Liste geändert haben, müssen Sie den Server stoppen und anschließend erneut starten. Diesbezügliche Anweisungen finden Sie in Caching Proxy starten und stoppen.
Anhang B. Anweisungen in der Konfigurationsdatei beschreibt jede der Anweisungen in der Konfigurationsdatei und enthält detaillierte Angaben zu deren Syntax.
Die Komponente Caching Proxy ist so konzipiert, dass sie fortlaufend als Hintergrundprozess ausgeführt wird und nur sehr wenige Bedienereingriffe erfordert. In der Regel wird der Proxy-Server während des Boot-Zyklus der Maschine gestartet und nur gestoppt, wenn Wartungsmaßnahmen durchgeführt werden müssen. Der Proxy-Server kann bei Bedarf manuell gestartet werden. Außerdem kann dem Proxy-Server eine Neustartanweisung übergeben werden, die den Proxy-Server stoppt und dann erneut startet, ohne aktive Clientverbindungen zu unterbrechen.
Auf Linux- und UNIX-Systemen werden bei der Installation von Caching Proxy ein Initialisierungs-Script mit dem Namen ibmproxy und die zugehörigen symbolischen Verbindungen in den entsprechenden /etc/-Verzeichnissen gespeichert. Die Scripts werden dann in die Start- und Systemabschlussroutinen des Betriebssystems integriert. Sie können die Konfigurationseinstellungen für automatischen Neustart ändern, indem Sie das Script ibmproxy editieren und die Optionen des Befehls ibmproxy ändern.
Es ist möglich, dass das Initialisierungs-Script von Caching Proxy wegen des systemweiten Grenzwerts für Dateideskriptoren unter Solaris nicht die gewünschte maximale Anzahl von Dateideskriptoren festlegen kann. Ist der systemweite Maximalwert niedriger als die Einstellung im Initialisierungs-Script von Caching Proxy, wird der systemweite Grenzwert verwendet. Um Probleme mit der Proxy-Leistung zu vermeiden, die aus einem zu niedrigen Wert (unter 1024) resultieren, können Sie den Grenzwert für die Dateideskriptoren ändern. Führen Sie den Befehl ulimit aus, um die Anzahl der Deskriptoren anzuzeigen, die derzeit verfügbar sind. Liegt der Wert unter 1024, erhöhen Sie den Grenzwert. Um den Grenzwert für Dateideskriptoren auf 1024 zu erhöhen, fügen Sie der Datei /etc/system die folgende Zeile hinzu:
set rlim_fd_cur=0x400
Automatisches Starten und Stoppen inaktivieren
Gehen Sie wie folgt vor, um das automatische Starten und Stoppen zu inaktivieren:
Entfernen Sie unter SUSE Linux die folgenden Verbindungen zur Datei ibmproxy:
Der Befehl ibmproxy wird unabhängig von der Startmethode entweder direkt von der Eingabeaufforderung oder aus einem Script heraus aufgerufen. Eine detaillierte Beschreibung des Befehls ibmproxy finden Sie im Abschnitt Befehl ibmproxy. Beispiele für die am häufigsten verwendeten Argumente folgen.
startsrc -s ibmproxy
startsrc -s ibmproxy -e "LC_ALL=Locale"
ibmproxy
/sbin/init.d/ibmproxy start
/usr/sbin/ibmproxy
/usr/sbin/ibmproxy -nobg
/etc/rc.d/init.d/ibmproxy start
/usr/sbin/ibmproxy
/usr/sbin/ibmproxy -nobg
squidConfig.file -r /etc/errors_icons.conf
Dabei legt die Datei errors_icons.conf die Symbole fest, die beim Durchsuchen von Verzeichnissen für die zugeordneten Dateitypen verwendet werden sollen.
/etc/init.d/ibmproxy start
/usr/sbin/ibmproxy
/usr/sbin/ibmproxy -nobg
Wird Caching Proxy als Windows-Dienst installiert, wird er wie jeder andere Windows-Dienst gestartet:
Ist Caching Proxy als Dienst installiert, kann er so konfiguriert werden, dass er automatisch beim Start von Windows gestartet wird. In diesem Fall müssen Sie sich nicht anmelden, damit der Proxy-Server Anforderungen beantworten kann. Führen Sie folgende Schritte aus, damit der Proxy-Server automatisch gestartet wird:
Umgebungsvariable PATH aktualisieren
Wird für Caching Proxy in der Anzeige Dienste der Status Gestartet angezeigt, obwohl der Proxy-Server nicht aktiv ist, wurde die Maschine eventuell nach der Installation des Proxy-Servers nicht neu gestartet. Wurde die Komponente Caching Proxy so definiert, dass sie interaktiv mit dem Desktop arbeitet, und wurde sie danach nicht neu gestartet, wird eventuell folgende Fehlernachricht in einem Dialogfenster angezeigt: Message catalog error: the message catalog could not be loaded or is invalid (Nachrichtenkatalogfehler: Der Nachrichtenkatalog konnte nicht geladen werden oder ist ungültig).
Die Maschine muss jedoch neu gestartet werden, damit der Wert der Umgebungsvariablen PATH in der Windows-Registry aktualisiert wird. Wird die Registry nicht aktualisiert, zeigt die Variable PATH möglicherweise die richtigen Pfade für Caching Proxy und GSK7 an, funktioniert aber nicht ordnungsgemäß.
Dieses Problem kann auftreten, wenn in der Windows-Umgebungsvariablen PATH der Pfad für den Dateisystemdienst vor dem Pfad für den Caching-Proxy-Dienst angegeben ist. Sie können das Problem lösen, indem Sie Dateisystemdienste in der Variablen PATH möglichst am Ende angeben.
Dieses Problem hat keine Auswirkung auf ferne Laufwerke, die von Anwendungen bereitgestellt werden, die nicht als Windows-Dienste ausgeführt werden. Beispielsweise kann Caching Proxy auf freigegebene Laufwerke auf anderen Windows-Maschinen zugreifen, die in einem lokalen Netz (LAN) sichtbar sind.
Bei der Installation von Caching Proxy als Windows-Anwendung wird im Menü Start ein Untermenü Caching Proxy erstellt. Zum Starten von Caching Proxy als Anwendung klicken Sie auf Start -> Programme -> IBM WebSphere -> Edge Components -> Caching Proxy.
Diese Startprozedur führt den Proxy-Server mit den aktuellen Konfigurationseinstellungen aus. Wenn Sie beim Start andere Einstellungen festlegen möchten, müssen Sie den Server von der Eingabeaufforderung aus starten. Nähere Informationen hierzu finden Sie im folgenden Abschnitt.
Wenn Sie den Server von einer Windows- oder DOS-Eingabeaufforderung aus starten möchten, verwenden Sie den Befehl ibmproxy. Sollten Sie Windows seit der Installation des Servers noch nicht heruntergefahren und erneut gestartet haben, müssen Sie (standardmäßig) mit dem Befehl den vollständigen Pfadnamen angeben. Beispiel:
c:\Programme\IBM\edge\cp\bin\ibmproxy.exe
Der Befehl ibmproxy startet den Server mit den aktuellen Konfigurationseinstellungen. Wenn Sie die Serverkonfiguration seit der Installation nicht geändert haben, basiert die aktuelle Konfiguration auf den Informationen, die Sie während der Installation angegeben haben, und auf den Standardoptionen.
Mit dem Befehl ibmproxy wird der Server als Anwendung gestartet, selbst wenn Sie Caching Proxy als Dienst installiert haben. Damit der Server als Anwendung ausgeführt wird, können Sie auch die Befehlsoption -noservice angeben. Mit anderen Befehlsoptionen können Sie die Konfigurationseinstellungen während der Laufzeit ändern.
Sie können mehrere Instanzen des Proxy-Servers parallel ausführen, aber jede Instanz muss an einem gesonderten Port empfangsbereit sein. Auf AIX-Systemen kann mit SRC nur eine Instanz gestartet werden. Für alle Instanzen des Servers müssen eindeutige Konfigurationsdateien angegeben werden, weil in der Konfigurationsdatei eine Port-Nummer festgelegt ist und diese Nummer für jeden Server auf einer bestimmten Maschine eindeutig sein muss. Zum Starten einer weiteren Instanz des Servers (wenn mindestens eine Serverinstanz aktiv ist) geben Sie an der Eingabeaufforderung folgenden Befehl ein:
ibmproxy -r andere_Konfigurationsdatei
ibmproxy -noservice -r andere_Konfigurationsdatei
andere_Konfigurationsdatei steht für eine eindeutige Konfigurationsdatei.
Beim Starten mehrerer Instanzen des Servers müssen Sie die Prozess-ID notieren, die für jede Instanz angezeigt wird. Sie benötigen diese IDs, damit Sie bestimmte Instanzen des Servers stoppen können.
Gehen Sie wie folgt vor, um den Server zu stoppen:
Startmethode | Stoppmethode |
In /etc/inittab (unter AIX) | Geben Sie Folgendes ein: stopsrc -s ibmproxy |
In /sbin/init.d (unter HP-UX) | Geben Sie Folgendes ein: /sbin/init.d/ibmproxy stop |
In /etc/rc.d/init.d (unter Linux) | Geben Sie Folgendes ein: /etc/rc.d/init.d/ibmproxy stop |
ibmproxy |
Zum Stoppen aller Server auf dieser Maschine geben Sie Folgendes ein: killall ibmproxy |
ibmproxy -nobg | Drücken Sie die Tastenkombination Strg-c. |
ibmproxy -r -andere_Konfigurationsdatei (unter AIX) | Geben Sie Folgendes ein: stopsrc -s ibmproxy -p Prozess-ID |
ibmproxy -r -andere_Konfigurationsdatei (unter Linux) |
|
ibmproxy -unload
Zum Stoppen des Servers melden Sie sich als root an und geben dann an der Eingabeaufforderung Folgendes ein:
Bei Verwendung der Stoppbefehle stoßen Sie möglicherweise auf die folgenden Einschränkungen:
Auf AIX-, HP-UX- und Linux-Systemen beenden die Befehle zum Stoppen des Caching-Proxy-Systems manchmal nur den Caching-Proxy-Prozess. Dieses Verhalten ist beim AIX-Befehl stopsrc -s ibmproxy zu beobachten. Dasselbe gilt für den Befehl ibmproxy -stop unter HP-UX und Linux.
Der vom LDAP-Server verwendete PACD-Prozess bleibt möglicherweise auch nach dem Stoppen des Proxy-Servers aktiv. Der PACD-Prozess kann mit dem Befehl kill wie folgt zuverlässig gestoppt werden:
kill -15 PACD-Prozess-ID
Wird der Befehl ibmproxy -stop auf einem Solaris-System ausgeführt, hat dies nicht dasselbe Ergebnis wie die Ausführung dieses Befehls auf anderen Betriebssystemen. Aufgrund einer Einschränkung im Solaris-Code wird der Schritt zur Serverbeendigung nicht ausgeführt, wenn der Befehl ibmproxy -stop auf einer Solaris-Plattform ausgeführt wird.
Diese Einschränkung hat sowohl Auswirkungen auf die Proxy-Server-Software als auch auf die Plug-ins, die vom Kunden implementiert werden.
Es ist möglich, dass der vom LDAP-Server verwendete PACD-Prozess auch nach dem Stoppen des Proxy-Servers aktiv bleibt. Der PACD-Prozess kann mit dem Befehl kill wie folgt zuverlässig gestoppt werden:
kill -15 PACD-Prozess-ID
Sie können den Caching-Proxy-Server auf dieselbe Art und Weise stoppen wie andere Windows-Programme.
Ist der Proxy-Server als Dienst installiert, gehen Sie wie folgt vor:
Ist der Proxy-Server nicht als Dienst installiert, führen Sie einen der folgenden Schritte aus, um Caching Proxy zu stoppen:
Nachdem die Serverkonfiguration (mit den Konfigurations- und Verwaltungsformularen oder durch Editieren der Datei ibmproxy.conf) geändert wurde, müssen Sie den Server erneut starten, damit die Änderungen wirksam werden. In den meisten Fällen können Sie den Server erneut starten, ohne ihn zuerst zu stoppen. Einige Einstellungen werden jedoch durch einen einfachen Neustart nicht aktualisiert. Nähere Informationen hierzu finden Sie in Tabelle 6.
Um für den Server einen Neustart durchzuführen, ohne ihn vorher zu stoppen, klicken Sie in einem Konfigurations- und Verwaltungsformular auf Neustart oder geben Sie folgenden Befehl ein: ibmproxy -restart
In diesem Teil wird die Zusammenarbeit zwischen der Komponente Caching Proxy und dem Betriebssystem, der Computerhardware und dem Netzwerk beschrieben. Außerdem beschreibt dieser Teil die Prozeduren zum Konfigurieren dieser Zusammenarbeit. Diese Elemente der Proxy-Server-Konfiguration werden in der Regel vom Systemadministrator verwaltet und müssen sorgfältig auf die Netzressourcen wie IP-Adressen und Hostnamen sowie auf die Systemressourcen wie den verfügbaren Speicher und die CPU-Zyklen abgestimmt werden.
Dieser Teil enthält die folgenden Kapitel:
Das Eigentumsrecht an Prozessen festlegen
Proxy-Server-Prozess optimieren
Caching Proxy wird in der Regel als Hintergrundprozess auf einem Hostcomputersystem ausgeführt, das als Netzserver konfiguriert ist. Dieser Prozess wird einer oder allen aktiven IP-Adressen (Internet Protocol) auf dem Hostcomputersystem zugeordnet (an diese gebunden). Caching Proxy wartet an angegebenen Ports auf verschiedene Internet-Protokolle wie FTP und HTTP und führt gemäß der Verhaltenskonfiguration bestimmte Aktionen für diese Anforderungen aus. (Nähere Informationen hierzu finden Sie in Das Verhalten von Caching Proxy konfigurieren.)
Standardmäßig setzt Caching Proxy den Namen des Hostcomputersystems voraus. Sie können dieses Standardverhalten jedoch außer Kraft setzen, indem Sie explizit einen Hostnamen für den Proxy-Server angeben. Wenn Sie Caching Proxy an eine bestimmte IP-Adresse binden möchten, müssen Sie den dieser IP-Adresse entsprechenden Hostnamen für den Proxy-Server wählen.
Der Hostname des Proxy-Servers hat keinen Einfluss darauf, wie der Clientdatenverkehr aufgelöst wird. Der Proxy-Server vergleicht seinen Hostnamen nicht mit dem Wert des Arguments Hostname im Header der HTTP-Anforderung. Der Hostname des Proxy-Servers wird gelegentlich in dynamisch generierte lokale Inhaltsseiten wie Fehlernachrichten eingebunden. Er wird außerdem als Wert des Arguments "Via" im HTTP-Header an den Anforderungsclient zurückgegeben.
Der Proxy-Server kann so konfiguriert werden, dass der Hostname des Anforderungsclients durch den Hostnamen des Proxy-Servers ersetzt wird, bevor die Anforderung an den Zielserver übergeben wird. Auf diese Weise wird der Zielserver gezwungen, den Übertragungskanal über den Proxy-Server aufrecht zu erhalten, anstatt eine Direktverbindung zum Client aufzubauen.
Geben Sie zur Definition des Proxy-Server-Prozesses mit den Anweisungen ServerRoot, Hostname und Port die physischen Adressen der Proxy-Server-Dateien auf dem Hostcomputersystem, den Namen, den der Proxy-Server verwendet, um auf sich selbst zu verweisen, und die Ports an, an denen der Proxy-Server empfangsbereit ist. Falls der Host mehrere IP-Adressen besitzt, kann der Proxy-Server an eine bestimmte Adresse gebunden werden. Setzen Sie hierfür die Anweisung BindSpecific auf "On" und die Anweisung "Hostname" auf die IP-Adresse.
Ein Verwaltungs-Port ist eine Methode für den Zugriff auf die Konfigurations- und Verwaltungsformulare und die Verwaltung des Servers. Wenn Sie den Zugriff auf den Proxy-Server über einen Verwaltungs-Port zulassen möchten, geben Sie mit der Anweisung AdminPort einen Wert an. Am Verwaltungs-Port empfangene Anforderungen werden nicht in dieselbe Warteschlange eingereiht wie Anforderungen, die am Standard-Port empfangen werden. Sie können Zuordnungsregeln schreiben, um den Zugriff auf die Konfigurations- und Verwaltungsformulare über diesen Port zuzulassen.
Wenn die Anweisung BindSpecific aktiviert ist, wird Caching Proxy mit der IP-Adresse, die aus dem Wert der Anweisung Hostname abgeleitet wird, an den mit der Anweisung Port angegebenen Port gebunden. Der mit der Anweisung AdminPort angegebene Port wird an alle auf dem System verfügbaren IP-Adressen gebunden.
Wenn Sie den Standardnamen des aktiven Servers, z. B. IBM-PROXY oder IBM_HTTP_SERVER, ändern möchten, geben Sie einen Wert für die Anweisung HeaderServerName an. Dieser Wert wird in das Serverfeld der HTTP-Antwort übernommen.
Zur Steigerung der Proxy-Leistung können Sie die Anweisung PureProxy auf "On" setzen. Mit dieser Einstellung werden alle Cache-Funktionen inaktiviert.
Der Proxy-Server-Prozess kann mit den folgenden Anweisungen definiert werden:
Nähere Informationen hierzu finden Sie in Die Datei ibmproxy.conf manuell editieren.
Mit den folgenden Konfigurations- und Verwaltungsformularen können Sie die Werte der zugehörigen Anweisungen ändern:
Nähere Informationen hierzu finden Sie in Konfigurations- und Verwaltungsformulare verwenden.
Wenn ein anderer Benutzer als der Superuser root die Komponente Caching Proxy startet, hat dieser Benutzer das Eigentumsrecht an allen Prozessen, die dem Proxy-Server zugeordnet sind. Wird Caching Proxy jedoch vom Superuser root gestartet, liest eine Proxy-Server-Funktion zum Festlegen der Benutzer-IDs die Anweisungen UserId und GroupId aus der Datei ibmproxy.conf und erteilt dem angegebenen Benutzer und der angegebenen Gruppe das Eigentumsrecht an den Prozessen zu. Auf diese Weise wird der Dateizugriff beschränkt und das Computersystem geschützt. Wenn Sie die Anweisungen UserId und GroupId ändern, müssen Sie das Eigentumsrecht und die Berechtigungen für die Protokollverzeichnisse und andere Dateien wie ACLs (Access Control List, Zugriffssteuerungsliste), die der Proxy-Server verwendet, aktualisieren.
Sie legen das Eigentumsrecht für den Proxy-Server-Prozess fest, indem Sie mit den Anweisungen UserID, GroupID und PidFile die Benutzer-ID, die Gruppen-ID und die Position der Datei angeben, in der die Prozess-ID aufgezeichnet ist.
Wenn Sie die Ausführung des Proxy-Server-Prozesses im Vordergrund erzwingen möchten, setzen Sie die Anweisung NoBG auf "On".
Auf Linux-Systemen:
Auf Linux-Systemen wird das Eigentumsrecht nur für Prozesse und Threads geändert, die für den Empfang von Verbindungen verantwortlich sind. Der Eigner von Prozessen und Threads, die für andere Aktivitäten im Arbeitsablauf zuständig sind, ist weiterhin root. Alle Prozesse und Threads erhalten eine Prozess-ID (PID). Der Befehl ps listet alle Prozess-IDs auf, unabhängig davon, ob sie einem Prozess oder einem Thread zugeordnet sind.
Gruppen für Benutzer nobody können nicht initialisiert werden. errno: 1Sie können diese Fehlernachricht ignorieren, weil sie keine Auswirkung auf die Ausführung von Caching Proxy hat. Sie können die Generierung dieser Fehlernachricht verhindern, indem Sie vor dem Starten von Caching Proxy die folgenden Umgebungsvariablen exportieren:
export RPM_FORCE_NPTL=1 export LD_ASSUME_KERNEL=2.4.19:
Mit den folgenden Anweisungen legen Sie das Eigentumsrecht für den Proxy-Server-Prozess fest:
Nähere Informationen hierzu finden Sie in Die Datei ibmproxy.conf manuell editieren.
Mit den folgenden Konfigurations- und Verwaltungsformularen können Sie die Werte der zugehörigen Anweisungen ändern:
Nähere Informationen hierzu finden Sie in Konfigurations- und Verwaltungsformulare verwenden.
Caching Proxy erzeugt für die Bearbeitung jeder Clientanforderung einen neuen Thread. Wenn keine Threads verfügbar sind, bewahrt der Proxy-Server die Anforderungen so lange auf, bis wieder Threads verfügbar sind. Mit zunehmender Anzahl aktiver Threads verbraucht der Proxy-Server auch mehr Speicher. Sie legen die maximale Anzahl aktiver Threads mit dem Wert für die Anweisung MaxActiveThreads fest.
Die Einstellung "ListenBacklog" gibt die maximale Anzahl anstehender Anforderungen für Clientverbindungen an, die der Server protokolliert, bevor er Verbindungen mit neuen Clients zurückweist. Legen Sie diesen Wert unter Berücksichtigung der Anzahl von Anforderungen fest, die der Server in wenigen Sekunden verarbeiten kann. Ein Server muss auf eine Clientverbindung reagieren, bevor das Clientzeitlimit abläuft. Geben Sie mit der Anweisung ListenBacklog die maximale Anzahl von Verbindungen an, die aufbewahrt werden soll.
Der Proxy-Server kann persistente Client/Server-Verbindungen verwalten. Bei der Verwendung einer persistenten Verbindung nimmt der Server mehrere Anforderungen des Clients entgegen und sendet seine Antworten über dieselbe TCP/IP-Verbindung. Persistente Verbindungen verringern die Latenzzeit für Clients und die CPU-Last auf dem Proxy-Server und verbrauchen nur geringfügig mehr Systemspeicher. Der Gesamtdurchsatz erhöht sich, wenn der Server nicht für jede Anforderung und Antwort eine gesonderte TCP/IP-Verbindung herstellen muss, und die TCP/IP-Verbindung kann am effektivsten genutzt werden, wenn sie persistent ist.
Durch die Bündelung von Verbindungen (Verbindungs-Pooling) auf Serverseite kommen die Vorteile persistenter Verbindungen auf Serverseite zum Tragen, weil vorhandene Verbindungen zwischen einem Proxy-Server und den Ursprungsservern wiederverwendet werden können. Bei jeder wiederverwendeten Verbindung werden drei TCP-Pakete eingespart (zwei Three-Way-Handshake-Pakete zum Herstellen der Verbindung und eines zum Schließen der Verbindung). Im Folgenden sind einige Vorteile der Bündelung von Verbindungen auf Serverseite aufgeführt:
Wenn die Bündelung von Verbindungen auf Serverseite aktiviert ist, werden HTTP-Verbindungen zu den Ursprungsservern im Pool gespeichert. SSL-Verbindungen werden in Konfigurationen, in denen die Anweisung SSLEnable für den Proxy-Server auf "on" gesetzt ist, ebenfalls im Pool gespeichert.
Sie können den Verbindungspool durch Angabe der folgenden Einstellungen konfigurieren: maximale Anzahl nicht verwendeter Sockets, die pro Server bereitgehalten werden sollen, die Wartezeit für den Server, bevor dieser eine nicht genutzte persistente Verbindung beendet, das Zeitintervall, in dem der Garbage-Collection-Thread den Pool auf verfallene Verbindungen überprüft (das Standardzeitlimit für Verbindungen sind zwei Minuten).
Sie können den Zeitraum definieren, für den verschiedene Verbindungen geöffnet bleiben, indem Sie Werte für die Anweisungen InputTimeout, OutputTimeout, PersistTimeout, ReadTimeout und ScriptTimeout festlegen.
Mit den folgenden Anweisungen können Sie Verbindungen mit dem Proxy-Server-Prozess verwalten:
Nähere Informationen hierzu finden Sie in Die Datei ibmproxy.conf manuell editieren.
Mit den folgenden Konfigurations- und Verwaltungsformularen können Sie die Werte der zugehörigen Anweisungen ändern:
Nähere Informationen hierzu finden Sie in Konfigurations- und Verwaltungsformulare verwenden.
Sie können die Leistung von Caching Proxy merkbar verbessern, indem Sie das System ordnungsgemäß konfigurieren und optimieren. Nachfolgend sind Empfehlungen zur Verbesserung der Konfiguration und zur Optimierung aufgeführt.
Die folgenden Anweisungen wirken sich erheblich auf die Leistung des Proxy-Server-Prozesses aus:
In den folgenden Feldern der Konfigurations- und Verwaltungsformulare können Sie die Werte der zugehörigen Anweisungen ändern:
Überprüfen Sie die Service- und Dämonprozesse, die auf dem System ausgeführt werden, und entfernen Sie die nicht benötigten Prozesse, um Speicher freizugeben und die CPU zu entlasten. Wenn auf dem System beispielsweise ein Webserver ausgeführt wird, der nur wenige Webseiten bereitstellt, sollten Sie in Erwägung ziehen, Caching Proxy als einzigen Webserver einzusetzen. Inaktivieren Sie andere Webserver wie folgt:
Stellen Sie sicher, dass Ihr System über einen ausreichenden Paging-Bereich verfügt, um einen ordnungsgemäßen Betrieb zu gewährleisten. Das System benötigt einen Paging-Bereich, der doppelt so groß ist wie der Arbeitsspeicher. Verteilen Sie den Paging-Bereich, sofern möglich, auf mehrere physische Laufwerke. Beispielsweise ist für einen Server des Typs Netfinity 5000 mit 512 MB Arbeitsspeicher und fünf SCSI-Laufwerken ein Gesamt-Paging-Bereich von 1 GB mit ungefähr 200 MB auf jedem Laufwerk erforderlich.
Caching Proxy erstellt und löscht während seiner Ausführung viele Dateien. Wenn der Proxy-Server Zugriffe protokolliert (im Zugriffsprotokoll, im Proxy-Zugriffsprotokoll oder im Cache-Zugriffsprotokoll), sollte jedem Protokoll ein eigenes Dateisystem zugewiesen werden. Auf diese Weise können Sie verhindern, dass bei einem unerwarteten Anschwellen der Protokolle kein Speicher belegt wird, der für eine andere Funktion vorgesehen ist (z. B. für den Cache).
Caching Proxy reagiert sensibel auf Änderungen der TCP/IP-Konfiguration. Wenn Sie die TCP/IP-Werte in einem Betriebssystem verringern, kann dies ein unerwartetes Verhalten des Proxy-Servers zur Folge haben. Falls zu niedrige TCP/IP-Werte verwendet werden, kann es vorkommen, dass Verbindungen von den Clients, die Verbindungen zum Proxy-Server herstellen, oder vom Ursprungsserver, zu dem der Proxy-Server eine Verbindung aufbaut, zurückgesetzt werden. Dies gilt insbesondere für Clients, die mit niedriger Bandbreite (56700 bps oder weniger) mit dem Proxy-Server verbunden sind. Gehen Sie deshalb vorsichtig vor, wenn Sie die TCP/IP-Parameterwerte herabsetzen müssen.
Das TCP-Warteintervall gibt an, wie lange ein Socket auf ein FIN-Paket vom Sender wartet, bevor er das Schließen der Verbindung erzwingt. In Umgebungen mit hoher Arbeitslast scheint der Proxy-Server zu blockieren, wenn viele Sockets im Status TIME_WAIT verbleiben, nachdem ihre Verbindungen geschlossen wurden. Die Wahl eines kürzeren TCP-Warteintervalls verringert die Anzahl der Sockets im Wartezustand und kann in Umgebungen mit hoher Arbeitslast das scheinbare Blockieren des Proxy-Servers verhindern. Es wird empfohlen, dieses Intervall auf 5 Sekunden einzustellen.
Gehen Sie wie folgt vor, um das TCP-Warteintervall auf 5 Sekunden einzustellen:
Geben Sie den folgenden Befehl ein:
ndd /dev/tcp -set tcp_time_wait_interval 5000
Verwenden Sie das Dienstprogramm "sam", um den Kernel-Parameter max_thread_proc auf 2048 oder höher zu setzen.
Geben Sie die folgenden Befehle ein:
echo "1024 61000" > /proc/sys/net/ipv4/ip_local_port_range echo "5" > /proc/sys/net/ipv4/tcp_fin_timeout
Geben Sie den folgenden Befehl ein:
ndd /dev/tcp -set tcp_time_wait_interval 5000
Öffnen Sie die Datei /etc/system in einem Editor und ändern Sie sie wie folgt:
set tcp:tcp_conn_hash_size=8129
Sie müssen einen Eintrag in der Registrierungsdatenbank erstellen, um das TCP-Warteintervall festzulegen. Nähere Informationen hierzu finden Sie in der Windows-Dokumentation.
Einige Grenzwerte im Linux-Kernel sind niedrig und können geändert werden. Einige Grenzwerte können über das Dateisystem /proc geändert werden, andere erfordern ein erneutes Kompilieren des Kernel.
Anmerkung: Das Dateisystem /proc ist virtuell, d. h., es existiert nicht physisch auf dem Datenträger. Es ist vielmehr eine Schnittstelle zum Linux-Kernel. Da es physisch nicht existiert, gehen Ihre Eingabewerte bei einem Neustart verloren. Daher sollten Änderungen am Dateisystem /proc unter RedHat in der Datei /etc/rc.d/rc.local und unter SUSE in der Datei /etc/rc.config vorgenommen werden. In diesem Fall werden die Änderungen beim Neustart aktiviert.
Im Folgenden sind einige Empfehlungen aufgelistet:
echo 32768 > /proc/sys/fs/file-max
echo 65536 > /proc/sys/fs/inode-max
echo 32768 61000 > /proc/sys/net/ipv4/ip_local_port_range
Wenn Sie den Kernel neu generieren möchten, aktivieren Sie nur Optionen, die Sie wirklich benötigen. Wenn Sie einen bestimmten Dämon nicht benötigen, führen Sie ihn nicht aus.
Auf AIX-Systemen kann die Leistung von Caching Proxy durch Verwendung von System-Threads und mehrerer Heap-Speicher für die Threads verbessert werden. Die Leistung ist von der Mehrprozessorunterstützung des Betriebssystems und der Thread-Planung des Betriebssystems abhängig. Sie können eine Leistungsverbesserung erzielen, indem Sie die Variablen für die Thread-Optimierung unter AIX wie folgt definieren:
export AIXTHREAD_SCOPE=S export SPINLOOPTIME=500 export YIELDLOOPTIME=100 export MALLOCMULTIHEAP=1
Sie können diese Umgebungsvariablen vor dem Start von /usr/sbin/ibmproxy setzen oder der Datei /etc/rc.ibmproxy hinzufügen, falls Sie den Proxy-Server mit startsrc -s ibmproxy starten. Nach der Anpassung dieser Variablen für die Thread-Optimierung ist auf SMP-Systemen eine deutliche Leistungsverbesserung erkennbar. In manchen Fällen kann auch auf Einzelprozessorsystemen eine Leistungsverbesserung festgestellt werden.
Dieser Teil erläutert, wie die Komponente Caching Proxy Clientanforderungen beantwortet, und beschreibt die Prozeduren zum Konfigurieren dieses Verhaltens. Diese Elemente der Proxy-Server-Konfiguration werden in der Regel von einem Webadministrator verwaltet und haben keine Auswirkung auf andere Prozesse auf dem Hostcomputersystem oder andere Computersysteme im Netzwerk.
Dieser Teil enthält die folgenden Kapitel:
Verarbeitung von Anforderungen verwalten
Bereitstellung lokaler Inhalte verwalten
Informationen zur Anwendungsprogrammierschnittstelle
Wenn Caching Proxy eine Clientanforderung empfängt, führt er die im Methodenfeld angegebene Aktion für das im URL-Feld angegebene Objekt aus, sofern die angeforderte Methode aktiviert ist. Der Proxy-Server löst den URL gemäß einer Reihe vom Administrator definierten Zuordnungsregeln auf. Diese Zuordnungsregeln können Caching Proxy beispielsweise anweisen, als Webserver aufzutreten und das Objekt aus dem lokalen Dateisystem abzurufen oder als Proxy-Server aufzutreten und das Objekt von einem Ursprungsserver abzurufen.
Dieses Abschnitt beschreibt, wie Sie Methoden aktivieren, Zuordnungsregeln definieren und einen Ersatz-Proxy-Server konfigurieren.
Clientanforderungen an den Server enthalten ein Methodenfeld, das die Aktion angibt, die der Server für das angegebene Objekt ausführen soll.
In der folgenden Liste sind die Methoden aufgeführt, die vom Proxy-Server unterstützt werden. Außerdem wird beschrieben, wie der Proxy-Server auf eine Clientanforderung, die die Methode enthält, reagiert, wenn die Methode aktiviert ist.
Weitere Informationen zum Format und den verfügbaren Optionen für die Methode Enable CONNECT finden Sie im Abschnitt SSL-Tunnelung konfigurieren.
Die Methode POST ist so konzipiert, dass sie Anhänge vorhandener Ressourcen bearbeiten kann. Beispiele hierfür sind das Senden einer Nachricht an ein Schwarzes Brett, eine Newsgroup, eine Mailing-Liste oder eine ähnliche Gruppe von Ressourcen, die Bereitstellung eines Datenblocks, z. B. aus einem Formular an ein Datenverarbeitungsprogramm, oder die Erweiterung einer Datenbank durch eine Anfügeoperation (append). Für Caching Proxy wird die Methode POST für die Verarbeitung der Konfigurations- und Verwaltungsformulare verwendet.
Diese Methode kann in persistenten Verbindungen verwendet werden.
Wenn Sie die Methode PUT aktivieren, können Dateien mit HTTP und FTP in Caching Proxy geschrieben werden. Da die Clients mit der Methode PUT in Caching Proxy schreiben können, müssen Sie mit den Zugriffsschutzkonfigurationen für den Server definieren, wer die Methode PUT für welche Dateien verwenden darf. (Nähere Informationen hierzu finden Sie in Zugriffsschutzkonfigurationen für den Server.)
Mit den folgenden Anweisungen können Sie die HTTP/FTP-Methoden aktivieren:
Nähere Informationen hierzu finden Sie in Die Datei ibmproxy.conf manuell editieren.
In den folgenden Konfigurations- und Verwaltungsformularen können Sie die Werte der zugehörigen Anweisungen ändern:
Nähere Informationen hierzu finden Sie in Konfigurations- und Verwaltungsformulare verwenden.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Zusätzlich zu den HTTP-Standardmethoden unterstützt Caching Proxy die Weiterleitung anderer Methoden, die in RFCs definiert oder von anderen Anwendungen verwendet werden. Caching Proxy unterstützt außerdem benutzerdefinierte Methoden und deren Weiterleitung über den Proxy-Server.
Web-based Distributed Authoring and Versioning (WebDAV) ist eine Gruppe von Erweiterungen für das Protokoll HTTP, mit denen Sie Dateien auf fernen Webservern bearbeiten und verwalten können. Caching Proxy unterstützt WebDAV-Methoden, Methoden, die von Microsoft Exchange Server verwendet werden, und benutzerdefinierte (angepasste) Methoden.
Diese Methoden sind fest codiert und werden mit den Anweisungen Enable und Disable verwaltet. Administratoren können mit der entsprechenden Methodenmaske, die in der Anweisung PROTECT definiert wird, die Verwendung dieser Methoden autorisieren.
Die unterstützten WebDAV-Methoden (RFC 2518) sind PROPFIND , PROPPATCH , MKCOL, COPY, MOVE, LOCK, UNLOCK und SEARCH.
Die unterstützten MS-Exchange-Methoden sind BMOVE, BCOPY, BDELETE, BPROPFIND, BPROPPATCH, POLL, NOTIFY, SUBSCRIBE, UNSUBSCRIBE, ACL, SUBSCRIPTIONS und X_MS_ENUMATTS.
Wenn die WebDAV- oder MS-Exchange-Server-Methoden aktiviert sind, leitet Caching Proxy die Anforderungen nur an die Zielserver weiter und schreibt keine Ressourcenverbindungen im Anforderungshauptteil um.
Caching Proxy kann auch benutzerdefinierte Methoden an den Backend-Server weiterleiten. Verwenden Sie die folgende Syntax für die Anweisung Enable in der Datei ibmproxy.conf, um eine angepasste Methode zu aktivieren:
Enable benutzerdefinierte_Methode [WithBody | WithoutBody]
Mit den Werten WithBody und WithoutBody informieren Sie den Proxy-Server darüber, ob die benutzerdefinierte Methode einen Anforderungshauptteil erfordert.
Die folgende Beispielanwendung aktiviert eine benutzerdefinierte Methode Meine_METHODE und informiert den Proxy-Server darüber, dass die Methode einen Anforderungshauptteil erfordert:
Enable Meine_METHODE WithBody
Die folgenden Anweisungen aktivieren WebDAV-Methoden, MS-Exchange-Methoden und benutzerdefinierte Methoden:
Nähere Informationen hierzu finden Sie in Die Datei ibmproxy.conf manuell editieren.
Zuordnungsregeln sind Konfigurationsanweisungen, die dafür sorgen, dass Clientanforderungen für Caching Proxy auf eine bestimmte Weise verarbeitet werden, z. B. dass die Anforderungen (über einen Proxy) an einen Ursprungsserver weitergeleitet, umgeleitet oder zurückgewiesen werden. Die korrekte Definition von Zuordnungsregeln ist für eine ordnungsgemäße Funktionsweise von Caching Proxy von entscheidender Bedeutung. Zuordnungsregeln wirken sich auf Folgendes aus:
Die Anweisungen für Zuordnungsregeln haben das folgende Format:
Regel Schablone Ziel [IP-Adresse | Hostname]:[Port]
Nur die Anforderungen, die der angegebenen Schablone und der IP/Port-Kombination entsprechen, unterliegen dieser Regel. Eine Schablone kann Platzhalterzeichen enthalten, z. B. https://**/*.asp.
Die Reihenfolge, in der die Regeln in der Konfigurationsdatei angegeben sind, ist von entscheidender Bedeutung. Wenn eine Anforderung einer Schablone entspricht, wird sie sofort verarbeitet, und alle nachfolgenden Regeln werden nicht mehr ausgewertet. Dies gilt jedoch nicht für Map-Anweisungen. Die Anweisung Map ersetzt den URL in der Anforderung. Diese neue Anforderung wird anschließend mit den verbleibenden Zuordnungsregeln verglichen.
Die folgenden Zuordnungsregeln gelten für Clientanforderungen, die der angegebenen Schablone entsprechen:
Die folgende Zuordnungsregel gilt für Antworten des Ursprungsservers:
Die folgenden Zuordnungsregeln gelten für API-Anwendungen:
Gehen Sie wie folgt vor, um einen Standardersatzserver zu konfigurieren:
Port 80
Proxy /* http://der.Inhalts.Server.com/* :80
AdminPort 8080
Damit wird der gesamte HTTP-Datenverkehr an Port 80 an den Ursprungsserver weitergeleitet. Datenverkehr, der am Verwaltungs-Port empfangen wird, entspricht nicht der ersten Proxy-Regel mit Platzhalterzeichen und bleibt deshalb von dieser Regel unberührt. Die verbleibenden Zuordnungsregeln werden für die Bearbeitung der Anforderung verwendet.
Mit den folgenden Anweisungen definieren Sie die Zuordnungsregeln:
Nähere Informationen hierzu finden Sie in Die Datei ibmproxy.conf manuell editieren.
Mit den folgenden Konfigurations- und Verwaltungsformularen können Sie die Werte der zugehörigen Anweisungen ändern:
Nähere Informationen hierzu finden Sie in Konfigurations- und Verwaltungsformulare verwenden.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Die Anweisung JunctionRewrite aktiviert die Routine für das Umschreiben von Junctions in Caching Proxy, die die Antworten von den Ursprungsservern so umschreibt, dass URLs, die relativ zum Server angegeben sind, dem richtigen Ursprungsserver zugeordnet werden, wenn Junctions verwendet werden. Das Plug-in JunctionRewrite muss ebenfalls aktiviert sein. Junctions werden mit den Proxy-Zuordnungsregeln definiert.
Wenn Sie die Junction mit den Proxy-Zuordnungsregeln definieren, können Sie die Anweisung Proxy mit oder ohne die Option JunctionPrefix verwenden.
Die folgenden Beispiele sind gültige Junctions, die von der Routine für das Umschreiben von Junctions bearbeitet werden können:
Das folgende Beispiel zeigt eine gültige Junction, die von der Routine für das Umschreiben von Junctions nicht bearbeitet wird:
Im Folgenden sehen Sie Beispiele für ungültige Junctions:
Diese Zuordnungsregeln erstellen Junctions für shopserver, authserver, und b2bserver. shopserver gibt ein HTML-Dokument mit den folgenden URLs zurück, die in die entsprechenden HTML-Tags eingeschlossen sind:
Die Routine für das Umschreiben von Junctions schreibt die relativ zum Server angegebenen Referenzen gemäß den Proxy-Zuordnungsregeln wie folgt um:
Wenn Sie die Option JunctionPrefix mit der Anweisung Proxy verwenden, anstatt das Junction-Präfix aus dem ersten URL-Muster in der Proxy-Regel abzuleiten, können Sie das Junction-Präfix mit dem folgenden Format in der Proxy-Regel deklarieren:
Proxy URL-Muster1 URL-Muster2 JunctionPrefix:URL-Präfix
Wenn Sie die Option JunctionPrefix verwenden, gibt es bezüglich des Formats des ersten URL-Musters keine Einschränkungen. Damit das Umschreiben von Junctions unterstützt wird, auch wenn die Option JunctionPrefix nicht verwendet wird, muss der Proxy-URL das folgende Format haben: Proxy /market/* http://b2bserver/*. Wenn Sie die Option JunctionPrefix jedoch verwenden, ist die folgende Proxy-Regel für das Umschreiben von Junctions gültig:
Proxy /market/partners/*.html http://b2bserver.acme.com/*.html junctionprefix:/market/partners
Die Routine für das Umschreiben von Junctions wirkt sich auf die folgenden Tags aus:
Tag | Attribute |
---|---|
!-- | URL |
a | href |
applet | archive, codebase |
area | href |
base | href |
body | background |
del | cite |
embed | pluginspage |
form | action |
input | src |
frame | src, longdesc |
iframe | src, longdesc |
ilayer | src, background |
img | src, usemap, lowsrc, longdesc, dynsrc |
layer | src, background |
link | href |
meta | url |
object | data, classid, codebase, codepage |
script | src |
table | background |
td | background |
th | background |
tr | background |
Sie können zum Aktivieren der Routine für das Umschreiben von Junctions und des zugehörigen Plug-in die folgenden Anweisungen verwenden:
Nähere Informationen hierzu finden Sie in Die Datei ibmproxy.conf manuell editieren.
Verwenden Sie das folgende Konfigurations- und Verwaltungsformular, um das Plug-in JunctionRewrite zu aktivieren:
Nähere Informationen hierzu finden Sie in Konfigurations- und Verwaltungsformulare verwenden.
Mit Cookies können Informationen zum Back-End-Server gespeichert werden. Es wird ein Cookie an den Client-Browser gesendet. Wenn der Browser Ressourcen in der HTML-Seite anfordert, hängt er ein Cookie an diese Anforderungen an, damit Caching Proxy die Anforderungen an den richtigen Back-End-Server weiterleitet.
Wenn Sie Cookies als Alternative zu JunctionRewrite verwenden möchten, müssen Sie die folgenden Änderungen in der Datei ibmproxy.conf vornehmen:
Es folgt ein Vergleich zwischen dem Plug-in JunctionRewrite und der Cookie-Implementierung.
Proxy /no-juntion.jpg http://login-server/no-junction.jpg
Es wir ein anpassbarer Beispielcode bereitgestellt, der JavaScript(TM)- (SCRIPT) und Applet-Tag-Blöcke (APPLET) in HTML-Dateien umschreibt und syntaktisch analysiert. Das Plug-in JunctionRewrite ist allein nicht in der Lage, die Ressourcenverknüpfungen in JavaScript oder in Parameterwerten von Java(TM) zu verarbeiten.
Nach der Installation von Caching Proxy können Sie denselben Code kompilieren und für die Ausführung mit JunctionRewrite konfigurieren.
Die folgenden Beispieldateien sind im Unterverzeichnis ...samples/cp/ des Verzeichnisses gespeichert, in das Sie den Fixpack heruntergeladen haben.
Die Zuordnungsregeln Pass und Exec werden verwendet, um einem anfordernden Client lokale Inhalte bereitzustellen. Standardmäßig wird eine Pass-Regel mit einer Schablone mit Platzhalterzeichen als letzte Zuordnungsregel angegeben. Diese Regel weist alle Anforderungen, die nicht mit vorherigen Schablonen übereinstimmen, an, Dateien aus einem Zielverzeichnis abzurufen, das im Allgemeinen als Dokumentstammverzeichnis bezeichnet wird.
Wenn ein URL empfangen wird, der keinen Dateinamen enthält, durchsucht Caching Proxy das angegebene Verzeichnis bzw., sofern kein Verzeichnis angegeben ist, das Dokumentstammverzeichnis nach einer Datei, die der Liste der Begrüßungsseiten entspricht, die in der Konfigurationsdatei angegeben sind. Wenn mehrere Begrüßungsseiten definiert sind, sucht der Proxy-Server die Seiten in der Reihenfolge, in der sie definiert worden sind. Die erste gefundene Begrüßungsseite wird bereitgestellt.
Die Server-Homepage ist die Webseite, die der Server standardmäßig bereitstellt, wenn er eine Anforderung empfängt, die nur den URL des Servers ohne Angabe eines Verzeichnisses oder eines Dateinamens enthält. Wie zuvor erläutert, erfordert die Standardzuordnungsregel mit Platzhalterzeichen, dass die Server-Homepage im Dokumentstammverzeichnis gespeichert ist und dass der Dateiname der Homepage einer definierten Begrüßungsseite entspricht.
Dieses Abschnitt beschreibt, wie Sie das Dokumentstammverzeichnis und Begrüßungsseiten definieren.
Folgende Verzeichnisse werden standardmäßig als Dokumentstammverzeichnisse verwendet:
Mit der folgenden Anweisung definieren Sie das Dokumentstammverzeichnis:
Nähere Informationen hierzu finden Sie in Die Datei ibmproxy.conf manuell editieren.
Gehen Sie wie folgt vor, um das Dokumentstammverzeichnis mit den Konfigurations- und Verwaltungsformularen zu ändern:
Nach dem Neustart verwendet der Server das neue Dokumentstammverzeichnis.
Nähere Informationen hierzu finden Sie in Konfigurations- und Verwaltungsformulare verwenden.
Der Server sucht im Dokumentstammverzeichnis nach der Homepage. Welche Datei jedoch zurückgegeben wird, bestimmt die Liste der Begrüßungsseiten.
Informationen zu Begrüßungsseiten
Wenn der Server eine URL-Anforderung empfängt, die keinen Dateinamen enthält, versucht er, die Anforderung anhand einer Liste von Begrüßungsseiten zu bearbeiten, die in der Konfigurationsdatei des Servers definiert ist. Diese Liste definiert die Dateien, die als Standard-Homepages zu verwenden sind. Der Server ermittelt Ihre Homepage, indem er die Liste der Begrüßungsseiten mit den Dateien in Ihrem Dokumentstammverzeichnis auf Entsprechungen abgleicht. Die erste gefundene Übereinstimmung ist die Datei, die als Homepage zurückgegeben wird. Wird keine Übereinstimmung gefunden, zeigt der Server eine Auflistung der Dokumente im Dokumentstammverzeichnis an.
Soll eine bestimmte Datei als Homepage des Servers verwendet und zurückgegeben werden, wenn eine Anforderung kein Verzeichnis oder keinen Dateinamen enthält, müssen Sie die Datei im Dokumentstammverzeichnis speichern und sicherstellen, dass ihr Name mit einem in der Liste der Begrüßungsseiten gespeicherten Dateinamen übereinstimmt.
Die Standardkonfigurationsdatei legt fest, dass folgende Dateinamen in der angegebenen Reihenfolge als Begrüßungsseiten verwendet werden sollen:
Der Server gibt die erste Datei zurück, die mit einem Dateinamen in der Liste übereinstimmt. Solange Sie keine Datei mit dem Namen welcome.html oder index.html erstellt und im Dokumentstammverzeichnis gespeichert haben, verwendet der Server die Datei Frntpage.html als Homepage.
Wenn Sie beispielsweise die Standardkonfiguration verwenden und Ihr Dokumentstammverzeichnis keine Datei welcome.html, aber Dateien mit den Namen index.html und FrntPage.html, wird die Datei index.html als Homepage verwendet.
Falls der Server keine Homepage findet, wird der Inhalt des Dokumentstammverzeichnisses als Verzeichnis angezeigt.
Mit der folgenden Anweisung definieren Sie die Begrüßungsseiten:
Nähere Informationen hierzu finden Sie in Die Datei ibmproxy.conf manuell editieren.
Mit den folgenden Konfigurations- und Verwaltungsformularen definieren Sie die Begrüßungsseiten:
Nähere Informationen hierzu finden Sie in Konfigurations- und Verwaltungsformulare verwenden.
Dies gilt nur für Forward-Proxy-Konfigurationen.
Caching Proxy leitet Anforderungen für FTP-URLs an den entsprechenden FTP-Server weiter, kann jedoch nicht dazu verwendet werden, Anforderungen von einem FTP-Client weiterzuleiten. Caching Proxy unterstützt nur FTP-Anforderungen, die von einem HTTP-Client (mit dem Protokollschema ftp://) empfangen werden.
Es werden nur die Methoden GET, PUT und DELETE für Anforderungen für FTP-Dateien unterstützt. Für Anforderungen, die sich auf FTP-Verzeichnislisten beziehen, wird nur die Methode GET unterstützt. Standardmäßig sind die Methoden PUT und DELETE in Caching Proxy inaktiviert. Nähere Informationen hierzu finden Sie im Abschnitt HTTP/FTP-Methoden aktivieren.
Dieses Abschnitt beschreibt, wie Sie FTP-Dateien schützen und Anmeldungen am FTP-Server, Verzeichnispfade und Verkettung verwalten.
Wenn Sie die Methode PUT zum Hochladen von FTP-Dateien oder die Methode DELETE zum Löschen von FTP-Dateien aktiviert haben, müssen Sie den FTP-Proxy-Zugriffsschutz zumindest für die Anforderungen PUT und DELETE definieren, um zu verhindern, dass unberechtigte Benutzer die Dateien auf Ihrem FTP-Server aktualisieren.
Zum Festlegen des Zugriffsschutzes für FTP-Proxy-Anforderungen wählen Sie in den Konfigurations- und Verwaltungsformularen Serverkonfiguration -> Zugriffsschutz für Dokumente aus. Um eine Zugriffsschutzkonfiguration für FTP-Dateianforderungen zu erstellen, muss die Anforderungsschablone mit ftp:// beginnen. Verwenden Sie z. B. zum Schutz der Dateien im Verzeichnis exams die Schablone ftp://exams/*.
Nähere Informationen zum Erstellen von Zugriffsschutzkonfigurationen finden Sie in Zugriffsschutzkonfigurationen für den Server.
Falls im Anforderungs-URL keine Benutzer-ID und kein Kennwort angegeben sind, versucht Caching Proxy, sich anonym beim angefragten FTP-Server anzumelden (mit der Benutzer-ID ANONYMOUS). Viele FTP-Server erfordern die Angabe einer E-Mail-Adresse als Kennwort für die anonyme FTP-Anmeldung. Wenn der FTP-Server nach einem Kennwort für die anonyme Anmeldung fragt, sendet Caching Proxy die E-Mail-Adresse, die in der Anweisung WebmasterEmail in der Konfigurationsdatei angegeben ist.
Zum Festlegen der E-Mail-Adresse des Webmaster wählen Sie in den Konfigurations- und Verwaltungsformularen Serverkonfiguration -> Systemverwaltung -> SNMP-MIB aus. Die E-Mail-Adresse kann auch mit der Anweisung WebmasterEmail festgelegt werden. Einzelheiten hierzu finden Sie im Abschnitt WebMasterEMail - Eine E-Mail-Adresse für den Empfang von ausgewählten Serverberichten festlegen.
Wenn der FTP-Server im Anforderungs-URL eine bestimmte Benutzer-ID und ein bestimmtes Kennwort für die Anmeldung erfordert, kann der Benutzer die Benutzer-ID und das Kennwort im Anforderungs-URL eingeben. Beispiel:
ftp://Benutzer-ID:Kennwort@ftpserverhost/
Wenn Sie das Kennwort für die FTP-Benutzer-ID nicht im Anforderungs-URL angeben möchten, kann der Benutzer auch nur die Benutzer-ID in die URL-Adresse aufnehmen: ftp://Benutzer-ID@ftpserverhost. Caching Proxy versucht zuerst, sich mit der angegebenen Benutzer-ID und ohne Kennwort beim FTP-Server anzumelden. Sollte die Anmeldung ohne Kennwort nicht erfolgreich sein, fordert der Browser die Eingabe des Kennworts für die angegebene Benutzer-ID an.
Für alle anderen Anmeldungen als die anonyme Anmeldung muss mindestens die Benutzer-ID im URL angegeben werden. Wenn die Benutzer-ID nicht angegeben ist, wird versucht, eine anonyme Anmeldung durchzuführen, und der Client wird nicht zur Eingabe der Benutzer-ID aufgefordert.
Sie müssen Caching Proxy mitteilen, ob die Pfadnamen in FTP-URLs relativ zum Arbeitsverzeichnis des Benutzers oder relativ zum Stammverzeichnis interpretiert werden sollen. Wenn ein Benutzer, der an einem FTP-Server angemeldet ist, beispielsweise ein Standardarbeitsverzeichnis mit dem Namen /export/home/user1 hat und eine Datei mit dem Namen test1.exe aus einem Unterverzeichnis mit dem Namen test abrufen möchte, verwendet der Proxy-Server, abhängig davon, wie die FTP-URLs zu interpretieren sind, die folgenden URLs für den Abruf der Datei vom FTP-Server:
Wenn relative FTP-URL-Pfade festgelegt wurden, können Benutzer trotzdem einen absoluten Pfadnamen angeben, indem sie der Konvention folgend als erstes Zeichen %2F anstelle des Anfangsschrägstrichs (/) für das Stammverzeichnis angeben. Falls user1, der das Arbeitsverzeichnis /export/home/user1 hat, beispielsweise auf eine Datei im Arbeitsverzeichnis von user2, /export/home/user2, zugreifen möchte, wird die Anforderung ftp://user1:user1pw@FTPhost/%2Fexport/home/user2/Datei ordnungsgemäß als relativer URL zum Stammverzeichnis / (d. h. als absoluter Pfadname) interpretiert, auch wenn relative FTP-URL-Pfadnamen ausgewählt wurden.
Sie können die Interpretation von FTP-URL-Pfaden im Konfigurations- und Verwaltungsformular Proxy-Konfiguration -> Leistung des Proxy-Servers definieren. Wählen Sie im unteren Teil des Formulars unter Pfade der FTP URL: entweder Absolute Pfade aus, wenn Sie das Stammverzeichnis des Servers angeben möchten, oder wählen Sie Relative Pfade aus, wenn Sie das Arbeitsverzeichnis des Benutzers als Pfadanfang festlegen möchten.
Sie können diese Einstellung auch in der Konfigurationsdatei des Proxy-Servers ändern. Nähere Informationen hierzu finden Sie im Abschnitt FTPUrlPath - Angeben, wie FTP-URLs interpretiert werden sollen.
Wenn Sie mehrere Web-Proxy-Server verketten, können Sie festlegen, dass Anforderungen, die FTP-URLs enthalten, an einen verketteten Web-Proxy-Server und nicht direkt an den FTP-Server gesendet werden. Wählen Sie in den Konfigurations- und Verwaltungsformularen Proxy-Konfiguration -> Proxy-Kettung und Nicht-Proxy-Domänen aus, wenn Sie einen verketteten Proxy-Server für FTP-Anforderungen festlegen möchten. Für die Angabe des URL eines verketteten Proxy-Servers wird das Protokollschema http:// verwendet, auch wenn Anforderungen für ein Protokollschema ftp:// verkettet werden.
Informationen zur Konfiguration der FTP-Verkettung in der Konfigurationsdatei des Proxy-Servers finden Sie im Abschnitt ftp_proxy - Für FTP-Anforderungen einen anderen Proxy-Server angeben.
In diesem Abschnitt wird beschrieben, wie Sie mit SSI-Anweisungen (Server-Side Includes) Informationen in CGI-Programme und HTML-Dokumente einfügen, die an einen Client übermittelt werden. Außerdem werden die Anpassung der Fehlernachrichten des Servers sowie die Zuordnung von Ressourcen beschrieben.
Mit Server-Side Includes können Sie CGI-Programmen und HTML-Dokumenten Informationen hinzufügen, die der Server an den Client sendet, wenn er als Ursprungsserver auftritt (weitergeleitete und zwischengespeicherte Objekte sind nicht betroffen). Das aktuelle Datum, die Dateigröße und das Datum der letzten Änderung einer Datei sind Beispiele für die Art von Informationen, die an den Client gesendet werden können. Dieser Abschnitt beschreibt das Befehlsformat für Server-Side Includes und erläutert die Schritte, die erforderlich sind, damit Server-Side-Include-Befehle in CGI-Programmen und HTML-Dokumenten funktionieren. Sie können Server-Side Includes auch zum Anpassen von Fehlerseiten verwenden.
Bevor Sie Server-Side Includes auf Ihrem Server verwenden, sollten Sie folgende Aspekte bezüglich Leistung, Sicherheit und Risiken bedenken:
Wählen Sie in den Konfigurations- und Verwaltungsformularen Serverkonfiguration -> Basiseinstellungen aus, um die Unterstützung für Server-Side Includes zu aktivieren. In diesem Formular können Sie angeben, welche der folgenden Arten von Server-Side Includes akzeptiert werden:
Außerdem können Sie in diesem Formular festlegen, ob die Verarbeitung von Server-Side Includes zusätzlich zu anderen Dateitypen auch für Text- und HTML-Dokumente vorgenommen werden soll.
Stellen Sie außerdem sicher, dass die Dateierweiterung, die Sie für Server-Side Includes verwenden, erkannt wird. Wählen Sie in den Konfigurations- und Verwaltungsformularen Serverkonfiguration -> MIME-Typen und -Codierung aus und rufen Sie das Formular MIME-Typen auf. Standardmäßig werden die Erweiterungen shtml und htmls erkannt.
Die folgenden Referenzabschnitte beschreiben, wie Sie durch Ändern der Anweisungen in der Konfigurationsdatei Ihren Proxy-Server für die Unterstützung von Server-Side Includes konfigurieren:
Include-Befehle müssen in Form von Kommentaren in das HTML-Dokument oder CGI-Programm eingefügt werden. Die Befehle müssen das folgende Format haben:
<!--#Anweisung Tag=Wert ... --> oder <!--#Anweisung Tag="Wert" ... -->
Die Werte müssen nur dann in Anführungszeichen gesetzt werden, wenn sie Leerzeichen enthalten.
In diesem Abschnitt werden die Anweisungen beschrieben, die der Server für Server-Side Includes akzeptiert. (Verwechseln Sie diese Anweisungen nicht mit den Anweisungen für die Konfigurationsdatei des Proxy-Servers, die in Anhang B. Anweisungen in der Konfigurationsdatei beschrieben werden.)
config - Dateiverarbeitung steuern
Mit dieser Anweisung können Sie bestimmte Aspekte der Dateiverarbeitung steuern. Die gültigen Tags sind cmntmsg, errmsg, sizefmt und timefmt.
Beispiel:
<!--#config cmntmsg="[Dies ist ein Kommentar]" --> <!-- #echo var=" " zusätzlicher Text -->
Ergebnis: <!--[Dies ist ein Kommentar] zusätzlicher Text -->
Standard: [Folgendes war zusätzlich in der Anweisung]
Beispiel:
<!-- #config errmsg="[Es ist ein Fehler aufgetreten]" -->
Standard: "[Fehler beim Verarbeiten dieser Anweisung]"
Beispiel 1:
<!--#config sizefmt=bytes --> <!--#fsize file=foo.html -->
Ergebnis: 1024
Beispiel 2:
<!--#config sizefmt=abbrev --> <!--#fsize file=foo.html -->
Ergebnis: 1 KB
Standard: "abbrev"
Beispiel:
<!--#config timefmt="%D %T" --> <!--#flastmod file=foo.html -->
Ergebnis: "18/10/95 12:05:33"
Standard: "%a, %d %b %Y %T %Z"
Die folgenden Formate für strftime() können für das Tag timefmt verwendet werden:
Kennung | Bedeutung |
---|---|
%% | Durch % ersetzen |
%a | Durch den abgekürzten Namen des Wochentags ersetzen |
%A | Durch den vollständigen Namen des Wochentags ersetzen |
%b | Durch den abgekürzten Namen des Monats ersetzen |
%B | Durch den vollständigen Namen des Monats ersetzen |
%c | Durch Datum und Uhrzeit ersetzen |
%C | Durch die Jahreszahl ersetzen (Jahr dividiert durch 100 und abgeschnitten) |
%d | Durch den Tag des Monats ersetzen (01-31) |
%D | Datum im Format %m/%t/%j einfügen |
%e | Monat als Dezimalzahl einfügen (01-12) (unter C POSIX ist dies ein zweistelliges, rechtsbündiges Feld mit Leerzeichen) |
%E[cCxyY] | Wenn das alternative Datum/Uhrzeit-Format nicht verfügbar ist, werden die %E-Deskriptoren ihren nicht erweiterten Entsprechungen zugeordnet (%EC wird z. B. %C zugeordnet). |
%Ec | Durch die alternative Darstellung von Datum und Uhrzeit ersetzen |
%EC | Durch den Namen des Basisjahrs (Zeitraum) in der alternativen Darstellung ersetzen |
%Ex | Durch die alternative Darstellung des Datums ersetzen |
%EX | Durch die alternative Darstellung der Uhrzeit ersetzen |
%Ey | Durch die Jahreszahl ohne Jahrhundert (%EC) in der alternativen Darstellung ersetzen |
%EY | Durch die vollständige alternative Jahresdarstellung ersetzen |
%h | Durch den abgekürzten Namen des Monats ersetzen (wie %b) |
%H | Durch die Stunde (23-Stunden-Format) in Dezimalformat (00-23) ersetzen |
%I | Durch die Stunde (12-Stunden-Format) in Dezimalformat (00-12) ersetzen |
%j | Durch den Tag des Jahres (001-366) ersetzen |
%m | Durch den Monat (01-12) ersetzen |
%M | Durch die Minute (00-59) ersetzen |
%n | Durch eine neue Zeile ersetzen |
%O[deHlmMSUwWy] | Wenn das alternative Datum/Uhrzeit-Format nicht verfügbar ist, werden die %E-Deskriptoren ihren nicht erweiterten Entsprechungen zugeordnet (%Od wird z. B. %d zugeordnet). |
%Od | Durch den Tag des Monats unter Verwendung der alternativen numerischen Symbole, nach Bedarf aufgefüllt mit führenden Nullen ersetzen, falls es ein alternatives Symbol für Null gibt, andernfalls mit führenden Leerzeichen |
%Oe | Durch den Tag des Monats unter Verwendung der alternativen numerischen Symbole, nach Bedarf aufgefüllt mit führenden Leerzeichen ersetzen |
%OH | Durch die Stunde (24-Stunden-Format) unter Verwendung der alternativen numerischen Symbole ersetzen |
%OI | Durch die Stunde (12-Stunden-Format) unter Verwendung der alternativen numerischen Symbole ersetzen |
%Om | Durch den Monat unter Verwendung der alternativen numerischen Symbole ersetzen |
%OM | Durch die Minuten unter Verwendung der alternativen numerischen Symbole ersetzen |
%OS | Durch die Sekunden unter Verwendung der alternativen numerischen Symbole ersetzen |
%OU | Durch die Kalenderwoche (Sonntag als erster Tag der Woche, Regeln wie bei %U) unter Verwendung der alternativen numerischen Symbole ersetzen |
%Ow | Durch den Wochentag (Sonntag=0) unter Verwendung der alternativen numerischen Symbole ersetzen |
%OW | Durch die Kalenderwoche (Montag als erster Tag der Woche) unter Verwendung der alternativen numerischen Symbole ersetzen |
%Oy | Durch das Jahr (ohne Jahrhundert (%C)) in der alternativen Darstellung und unter Verwendung der alternativen numerischen Symbole ersetzen |
%p | Durch die lokale Entsprechung für AM und PM ersetzen |
%r | Durch die Zeichenfolgeentsprechung für %I:%M:%S %p ersetzen |
%R | Durch die Uhrzeit im 24-Stunden-Format (%H:%M) ersetzen |
%S | Durch die Sekunden (00-61) ersetzen |
%t | Durch einen Tabulator ersetzen |
%T | Durch die Zeichenfolgeentsprechung für %H:%M:%S ersetzen |
%u | Durch den Wochentag im Dezimalformat (1-7) ersetzen, wobei die 1 für Montag steht |
%U | Durch die Kalenderwoche (00-53) ersetzen, wobei Sonntag der erste Tag der Woche ist |
%V | Durch die Kalenderwoche (01-53) ersetzen, wobei Montag der erste Tag der Woche ist |
%w | Durch den Wochentag (0-6) ersetzen, wobei die 0 für Sonntag steht |
%W | Durch die Kalenderwoche (00-53) ersetzen, wobei Montag der erste Tag der Woche ist |
%x | Durch die entsprechende Datumsdarstellung ersetzen |
%X | Durch die entsprechende Uhrzeitdarstellung ersetzen |
%y | Durch die zweistellige Jahresangabe (ohne Jahrhundert) ersetzen |
%Y | Durch die vollständige vierstellige Jahresangabe ersetzen |
%Z | Durch den Namen der Zeitzone bzw. eine leere Zeichenfolge ersetzen, falls die Zeitzone unbekannt ist |
Die Konfiguration des Betriebssystems legt die vollständigen und abgekürzten Angaben für Monate und Jahre fest.
echo - Variablenwerte anzeigen
Mit dieser Anweisung können Sie den Wert von Umgebungsvariablen anzeigen, die mit dem Tag var angegeben werden. Wenn eine Variable nicht gefunden wurde, wird (None) angezeigt. Außerdem können Sie mit echo einen Wert anzeigen, der mit der Anweisung set oder global festgelegt wurde. Folgende Umgebungsvariablen können angezeigt werden:
Beispiel:
<!--#echo var=SSI_DIR -->
exec - CGI-Programme angeben
Mit dieser Anweisung können Sie die Ausgabe eines CGI-Programms einfügen. Die Anweisung exec verwirft alle HTTP-Header, die vom CGI-Programm ausgegeben werden, mit Ausnahme der folgenden:
cgi - URL-Adresse des CGI-Programms angeben
Mit dieser Anweisung können Sie den URL eines CGI-Programms angeben.
In diesem Beispiel ist program das CGI-Programm, das ausgeführt werden soll. path_info und query_string stehen für einen oder mehrere Parameter, die als Umgebungsvariablen an das Programm übergeben werden.
<!--#exec cgi="/cgi-bin/program/path_info?query_string" -->
Dieses Beispiel zeigt die Verwendung der Variablen:
<!--#exec cgi="&path;&cgiprog;&pathinfo;&querystring;" -->
flastmod - Datum und Uhrzeit der letzten Dokumentänderung anzeigen
Mit dieser Anweisung können Sie Datum und Uhrzeit der letzten Dokumentänderung anzeigen. Das Format dieser Variablen wird mit der Anweisung config timefmt festgelegt. Die gültigen Tags für diese Anweisung sind file und virtual, die im Folgenden beschrieben werden.
Anweisungsformate:
<!--#flastmod file="/Pfad/Datei" --> <!--#flastmod virtual="/Pfad/Datei" -->
<!--#flastmod file="/Pfad/Datei" -->
<!--#flastmod virtual="/Pfad/Datei" -->
Beispiel:
<!--#flastmod file="foo.html" -->
Ergebnis: 12May96
fsize - Dateigröße anzeigen
Mit dieser Anweisung können Sie die Größe der angegebenen Datei anzeigen. Das Format dieser Variablen wird mit der Anweisung config sizefmt festgelegt. Die gültigen Tags für diese Anweisung sind file und virtual, die im Abschnitt zur Anweisung flastmod beschrieben sind.
Beispiel:
<!--#fsize file="/Pfad/Datei" --> <!--#fsize virtual="/Pfad/Datei" -->
Ergebnis: 1K
global - Globale Variablen definieren
Mit dieser Anweisung können Sie globale Variablen definieren, die zu einem späteren Zeitpunkt von dieser Datei oder anderen eingefügten Dateien zurückgemeldet werden können.
Beispiel:
<!--#global var=Variablenname value="einWert" -->
Wenn Sie beispielsweise auf ein übergeordnetes Dokument außerhalb der virtuellen Grenzen verweisen möchten, müssen Sie die globale Variable DOCUMENT_URI definieren. Außerdem müssen Sie im untergeordneten Dokument auf die globale Variable verweisen. Dieses Beispiel zeigt die HTML-Codierung, die Sie in das übergeordnete Dokument einfügen müssen:
<!--#global var="PARENT_URI" value=&DOCUMENT_URI; -->
Dieses Beispiel zeigt die HTML-Codierung, die Sie in das untergeordnete Dokument einfügen müssen:
<!--#flastmod virtual=&PARENT_URI; -->
include - Ein Dokument in die Ausgabe einfügen
Mit dieser Anweisung können Sie den Text eines Dokuments in die Ausgabe einfügen. Die gültigen Tags für diese Anweisung sind file und virtual, die im Abschnitt zur Anweisung flastmod beschrieben werden.
set - Zurückzumeldende Variablen festlegen
Mit dieser Anweisung können Sie eine Variable definieren, die zu einem späteren Zeitpunkt von dieser Datei (ausschließlich) zurückgemeldet werden kann.
Beispiel:
<!--#set var="Variable 2" value="AndererWert" -->
Wenn Sie eine Anweisung definieren, können Sie innerhalb von value eine Zeichenfolge zurückgeben. Beispiel:
<!--#include file="&Dateiname;" -->
Variablen: Einer auf Serverseite definierten Anweisung set folgt im Allgemeinen eine Anweisung echo, d. h. die definierte Variable wird gesucht und, sofern möglich, zurückgemeldet. Anschließend wird die Ausführung der Funktion fortgesetzt. Die Anweisung kann mehrere Verweise auf Variablen enthalten. Außerdem können Sie mit set-Anweisungen auf Serverseite eine bereits definierte Variable zurückmelden. Falls keine definierte Variable gefunden wird, wird nichts angezeigt.
Wenn eine auf Serverseite definierte Anweisung set in einer SSI-Anweisung einen Variablenverweis findet, versucht sie, diesen Verweis auf Serverseite aufzulösen. In der zweiten Zeile des folgenden Beispiels bildet die Servervariable &index; zusammen mit der Zeichenfolge var den Variablennamen var1. Anschließend wird der Variablen &var1; ein Wert zugeordnet, indem dem Et-Zeichen (&) im Ausdruck ê ein Escape-Zeichen vorangestellt wird, damit dieser Ausdruck nicht als Variable interpretiert wird. Er wird vielmehr als Zeichenfolge verwendet, um den Wert frêd bzw. fred mit einem Zirkumflex über dem e zu bilden. Die Variable ê ist eine clientseitige Variable.
<!--#set var="index" value="1" --> <!--#set var="var&index;" value="fr\êd" --> <!--#echo var="var1" -->
Die folgenden Zeichen können durch Voranstellen eine Backslash (\) geschützt werden:
Zeichen | Bedeutung |
---|---|
\a | Alert (Signalton) |
\b | Rückschritt |
\f | Formularvorschub (Seitenvorschub) |
\n | Neue Zeile |
\r | Zeilenschaltung |
\t | Horizontaltabulator |
\v | Vertikaltabulator |
\' | Einfaches Anführungszeichen |
\" | Doppeltes Anführungszeichen |
\? | Fragezeichen |
\\ | Umgekehrter Schrägstrich |
\- | Silbentrennungsstrich |
\. | Punkt |
\& | Et-Zeichen |
Sie können die von Caching Proxy zurückgegebenen Fehlernachrichten anpassen und für bestimmte Fehlerbedingungen spezielle Nachrichten definieren. Wählen Sie in den Konfigurations- und Verwaltungsformularen Serverkonfiguration -> Anpassung von Fehlernachrichten aus. In diesem Formular können Sie eine Fehlerbedingung auswählen und eine bestimmte HTML-Datei angeben, die für diese Bedingung verwendet werden soll.
Informationen zum Anpassen von Fehlermeldungen durch Editieren der Anweisungen in der Konfigurationsdatei des Proxy-Servers finden Sie im Abschnitt zur Anweisung ErrorPage - Für eine bestimmte Fehlerbedingung eine angepasste Nachricht angeben.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Mit RTSP Redirector, einem neuen Feature von WebSphere Application Server Version 6.1, wird jetzt das Streaming von Multimediadateien unterstützt. Mit RTSP ist Caching Proxy in der Lage, Kontakt zu Media-Playern herzustellen und deren Anforderungen an einen geeigneten Proxy-Server oder Content-Server weiterzuleiten, der die angeforderten Multimediainhalte bereitstellt.
RTSP (Real Time Streaming Protocol) ist in RFC 2326 definiert und ein Internet-Standardprotokoll für die Steuerung von Datenströmen. Obwohl RTSP keine Technologie zum Senden von Datenströmen beinhaltet, ist es so flexibel, dass es zur Steuerung von Datenströmen eingesetzt werden kann, die sich nicht auf die Video- oder Audiowiedergabe beschränken.
Mit der Umleitungsfunktion von RTSP kann Caching Proxy Anforderungen für jede von RTSP gesteuerte Multimediasitzung umleiten, die Streaming unterstützt. Dies betrifft folgende Multimediatypen:
Jede Wiedergabeeinheit (Player), deren Konfiguration die Kontaktaufnahme zu einem Proxy-Server am RTSP-Port (in der Regel 554) unterstützt, kann dieses Framework in Caching Proxy verwenden, um ihre Anforderungen von RTSP Redirector bearbeiten zu lassen.
Multimediapräsentationen werden von RTSP Redirector weder zwischengespeichert noch direkt umgeleitet. Für die Unterstützung dieser beiden Funktionen muss RTSP Redirector zusammen mit einem Multimediaserver eines Fremdanbieters eingesetzt werden, der Streaming unterstützt. Wenn RTSP Redirector in Caching Proxy verwendet wird, muss der Zugriff auf einen oder mehrere RTSP-Proxy-Server über das Netz möglich sein.
Für diese Funktion gilt folgende Einschränkung:
Derzeit werden nur RealNetworks-Technologien unterstützt. Dazu gehören der RealProxy-Proxy-Server, der RealServer-Ursprungsserver sowie der RealPlayer.
In früheren Versionen unterlag RTSP Redirector der Einschränkung, dass alle Anforderungen an denselben Ursprungsserver für alle URLs auf dieselbe Weise umgeleitet wurden. Eine Umleitung basierend auf Dateinamen oder anderen Teilen des angeforderten URL war nicht möglich. Diese Einschränkung gilt nicht mehr. RTSP Redirector verwendet jetzt den vollständigen URL aus den empfangenen Anforderungen zusammen mit dem Schwellenwert (rtsp_proxy_threshold), der in der Konfigurationsdatei von Caching Proxy festgelegt ist, um zu bestimmen, ob die Clientanforderungen an den Ursprungsserver oder an einen Proxy-Server umgeleitet werden. Anforderungen an denselben Ursprungsserver werden individuell behandelt.
Mit den folgenden Anweisungen in der Konfigurationsdatei können Sie die RTSP-Umleitung steuern. Die Einstellungen für diese Anweisungen werden bei einem Neustart des Servers nicht aktualisiert. Sie müssen den Server vollständig stoppen und anschließend erneut starten, damit die an diesen Anweisungen vorgenommenen Änderungen wirksam werden.
Beim Anfordern von Dokumenten senden Web-Clients Header, die zusätzliche Informationen zum Browser oder zur Anforderung enthalten. Header werden automatisch generiert, wenn eine Anforderung gesendet wird.
Caching Proxy unterstützt verschiedene Optionen zur Anpassung von Header-Informationen, damit diese dem Zielserver verborgen bleiben. Obwohl das Ersetzen des aktuellen Header durch einen allgemeineren Header die Anonymität der Clients erhöht, hat dies den Nachteil, dass dadurch Header-basierte Seitenanpassungen, die in manche Webseiten geschrieben werden, inaktiviert werden.
In der Regel haben Header das folgende Format:
User-Agent: Mozilla 2.02/OS2 Client-IP: 45.37.192.3 Referer: http://www.bigcompany.com/WebTrafficExpress/main.html
Dieser Header enthält die folgenden Felder:
Die meisten Header können durch entsprechende Einstellungen in der Proxy-Konfiguration blockiert werden. Einige Header-Felder werden jedoch von den Ursprungsservern benötigt. Werden diese Felder blockiert, werden Webseiten daher nicht ordnungsgemäß angezeigt. (Beispielsweise können manchmal falsche Webseiten angezeigt werden, wenn das Header-Feld "host" blockiert ist.) Nähere Informationen zu den Header-Feldern finden Sie in der Spezifikation von HTTP Version 1.1.
Informationen zum Ändern von Header-Optionen durch Editieren der Konfigurationsdatei des Proxy-Servers finden Sie in den Referenzabschnitten zu den folgenden Anweisungen:
Nähere Informationen hierzu finden Sie in Die Datei ibmproxy.conf manuell editieren.
Die Header-Optionen können in zwei Konfigurations- und Verwaltungsformularen definiert werden:
Wählen Sie dieses Markierungsfeld aus, wenn die IP-Adresse des anfragenden Clients an den Zielserver (Inhaltsserver) weitergeleitet werden soll. Wenn Sie dieses Feld nicht auswählen, empfängt der Zielserver die IP-Adresse des Proxy-Servers. Wird dieses Feld nicht ausgewählt, erhöht sich außerdem die Anonymität des Client beim Surfen im Web.
Geben Sie die Zeichenfolge ein, die im Header an den Zielserver gesendet werden soll. Diese Zeichenfolge ersetzt den Browser-Typ und das Betriebssystem, die ein Client verwendet. Beispiel: Die Angabe Caching Proxy4.0 ersetzt im folgenden Header Mozilla 2.02/OS2:
Content-Type:MIME User-Agent: Mozilla 2.02/OS2 Referer: http://www.ics.raleigh.ibm.com/WebTrafficExpress/main.html Pragma:no-cache
Geben Sie die E-Mail-Adresse ein, die der Zielserver bei der Syntaxanalyse des Header "From:" liest. In der Regel wird die E-Mail-Adresse des Proxy-Administrators angegeben, da der Administrator die Berichte zu Problemen und Fehlern erhalten sollte.
Nähere Informationen hierzu finden Sie in Konfigurations- und Verwaltungsformulare verwenden.
Eine vollständige Beschreibung der Anwendungsprogrammierschnittstelle (API) finden Sie in der Veröffentlichung Programming Guide for Edge Components. API-Anweisungen in der Konfigurationsdatei aktivieren Plug-in-Routinen, die in bestimmten Schritten während der Anforderungsverarbeitung aufgerufen werden. Diese Plug-in-Routinen können integrierte Routinen ersetzen oder zusätzlich zu diesen ausgeführt werden.
Im Folgenden sind die API-Anweisungen aufgeführt:
Nähere Informationen hierzu finden Sie in Die Datei ibmproxy.conf manuell editieren.
Im folgenden Konfigurations- und Verwaltungsformular können Sie die Werte der zugehörigen Anweisungen ändern:
Nähere Informationen hierzu finden Sie in Konfigurations- und Verwaltungsformulare verwenden.
Dieser Teil beschreibt den Proxy-Cache und erläutert, wie Sie ihn konfigurieren. Der Cache kann so konfiguriert werden, dass Dateien im Hauptspeicher (Speicher-Cache) oder auf einer oder mehreren Speichereinheiten (Platten-Cache) gespeichert werden. Sie können einen Agenten für die Cache-Aktualisierung konfigurieren, der häufig angeforderte Dateien vorab in den Cache lädt. Darüber hinaus sind verschiedene URL-Filter für das Caching verfügbar. In diesem Teil wird ferner beschrieben, wie der Cache über fernen Cache-Zugriff oder das Plug-in ICP (Internet Caching Protocol) gemeinsam genutzt werden kann, wie veraltete Dateien mit der Garbage-Collection aus dem Cache gelöscht und wie dynamisch generierte Dateien im Cache gespeichert werden können.
Dieser Teil enthält die folgenden Kapitel:
Beim Caching speichert der Proxy-Server lokale Kopien der von den Clients angeforderten Dateien im Cache, so dass er bei erneuter Anforderung von demselben oder anderen Clients diese Dateien direkt aus dem Cache bereitstellen kann.
Caching Proxy ist mit HTTP 1.1 kompatibel und folgt im Allgemeinen dem Protokoll HTTP 1.1 für das Caching und für die Überprüfung der Dokumentaktualität.
Dieses Kapitel beschreibt einige Funktionen des Proxy-Server-Cache. In den folgenden Kapiteln wird beschrieben, wie Sie die richtigen Konfigurationswerte für diese Funktionen definieren.
Der Proxy-Server kann den Cache auf einer physischen Speichereinheit oder im Systemspeicher speichern. Welche Art von Cache-Speicher für Ihr System besser geeignet ist, hängt vom Leistungsspektrum Ihrer Hardware und davon ab, ob Ihnen kürzere Cache-Antwortzeiten oder eine höhere Maximalanzahl von Elementen im Cache wichtiger ist. Die Antwortzeiten eines Speicher-Cache sind in der Regel kürzer als die eines Platten-Cache, aber die Größe des Speicher-Cache wird durch die RAM-Kapazität der Proxy-Server-Maschine begrenzt. Die Größe eines Platten-Cache wird durch die Kapazität der Speichereinheit beschränkt, die in der Regel sehr viel höher ist als die RAM-Kapazität.
Für Platten-Caches verwendet Caching Proxy reines Platten-Caching, d. h. der Proxy-Server schreibt direkt auf die Cache-Einheit, ohne die Lese- und Schreibprotokolle des Betriebssystems zu verwenden. Die Speichereinheit für einen Platten-Cache muss mit dem Befehl htcformat vorbereitet werden. Nähere Informationen zum Befehl htcformat finden Sie in Basiseinstellungen für das Caching.
Sowohl beim Speicher-Cache als auch beim Platten-Cache legt Caching Proxy einen Cache-Index im Systemspeicher ab, der die Verarbeitungszeit für das Suchen der im Cache gespeicherten Dateien verringert.
Die Cache-Verzeichnisstruktur und die Suchfunktionen von Caching Proxy unterscheiden sich von denen anderer Proxy-Server. Caching Proxy verwaltet im Hauptspeicher einen Index mit Informationen zu den Dateien im Cache. Wenn der RAM anstelle einer Platte oder eines anderen Datenträgers zum Suchen verwendet wird, sind Such- und Abrufoperationen schneller.
Der Index enthält URLs, Cache-Positionen und Verfallsinformationen für Objekte im Cache. Aus diesem Grund verhält sich die für den Index erforderliche Speicherkapazität proportional zur Anzahl der Objekte im Cache.
Wenn eine Anforderung von einem Client empfangen wird, prüft der Proxy-Server, ob dieser URL in dem im Systemspeicher abgelegten Cache-Index enthalten ist.
Wenn im Proxy-Server das Zwischenspeichern (Caching) von Anforderungen konfiguriert ist, kann er sowohl FTP- als auch HTTP-Dateianforderungen zwischenspeichern. Da FTP-Dateien jedoch nicht dieselben Header-Informationen wie HTTP-Dateien enthalten, wird das Verfallsdatum für zwischengespeicherte FTP-Dateien anders als für andere zwischengespeicherte Dateien berechnet.
Wenn der FTP-Server eine Anforderung zum Abrufen einer Datei empfängt, sendet der Proxy-Server zunächst eine LIST-Anforderung für die Datei an den FTP-Server, um FTP-Verzeichnisinformationen zu dieser Datei zu erhalten. Falls der FTP-Server auf die LIST-Anforderung hin mit einer Ausführungsbestätigung und die Verzeichnisinformationen zu der Datei sendet, erstellt der Proxy-Server einen HTTP-Header "Last-Modified" mit dem Datum, das aus diesen FTP-Verzeichnisinformationen ermittelt wird. Die Caching-Funktion des Proxy-Servers verwendet diesen Header "Last-Modified" anschließend zusammen mit dem Wert der Anweisung CacheLastModifiedFactor aus der Konfigurationsdatei, um die maximale Verweildauer der FTP-Datei im Cache-Speicher zu bestimmen.
Nähere Informationen zur Verwendung des Header "Last-Modified" und der Anweisung CacheLastModifiedFactor zur Bestimmung der Verweildauer einer Datei im Cache-Speicher finden Sie in Cache-Inhalt verwalten.
FTP-Dateien, die nicht durch anonyme Anmeldung, sondern für eine bestimmte Benutzer-ID abgerufen werden, werden als private Dateien behandelt und nicht zwischengespeichert.
Zusätzlich zum Caching von Webinhalten führt der Proxy-Server DNS-Caching (DNS = Domänennamensserver) durch. Wenn ein Client beispielsweise einen URL von der Website www.meineWebsite.com anfordert, fordert der Proxy-Server seinen DNS-Server auf, den Hostnamen www.meineWebsite.com in eine IP-Adresse aufzulösen. Die IP-Adresse wird dann in den Cache gestellt, um die Antwortzeit bei zukünftigen Anforderungen für diesen Hostnamen zu verbessern. DNS-Caching wird automatisch durchgeführt, und die Konfiguration kann diesbezüglich nicht geändert werden.
Einige Dateien und Dokumente werden nie im Cache gespeichert. Dazu gehören die folgenden Dateien:
Sie können die im Cache gespeicherten Elemente noch weiter einschränken, indem Sie Caching-Filter definieren. Beispielsweise könnten Sie festlegen, dass der Proxy-Server keine Dateien im Cache speichern soll, die lokal vom Proxy-Server bereitgestellt werden. Nähere Informationen hierzu finden Sie in Zwischenzuspeichernde Inhalte steuern.
Zum Verwalten eines Cache gehören viele Faktoren. Als Serveradministrator können Sie Folgendes festlegen:
Zusätzlich können Anpassungen der Cache-Konfiguration vorgenommen werden, um die Gesamtleistung von Caching Proxy zu verbessern. Nähere Informationen zur Leistungsoptimierung finden Sie in Proxy-Server-Cache optimieren.
Wenn Sie zum Installieren von Caching Proxy im Produktinstallationsprogramm von Edge Components die Standardeinstellungen verwendet haben, ist das Caching aktiviert, und der Cache wird im Hauptspeicher gespeichert. Mit den folgenden Basiseinstellungen für das Caching können Sie den Cache an die Anforderungen Ihres Systems anpassen.
Falls Sie das Installationsprogramm nicht verwendet haben, konfigurieren Sie diese Einstellungen, um das Caching zu aktivieren.
Im Folgenden sind die grundlegenden Schritte für die Konfiguration des Caching aufgeführt:
Nach der Konfiguration der Basiseinstellungen für den Cache können Sie die Einstellungen für die folgenden Funktionen hinzufügen oder ändern:
Anleitungen zum Ändern dieser Einstellungen finden Sie in diesem Kapitel.
Zum Aktivieren des Caching setzen Sie die Anweisung Caching auf "on" oder wählen Sie im Konfigurationsformular Cache-Konfiguration -> Cache-Einstellungen das Feld Proxy-Caching aktivieren aus. Wenn Sie keine Cache-Einheit angeben, wird der Cache im Speicher abgelegt. Zum Erstellen eines Platten-Cache führen Sie die Schritte im Abschnitt 2. Cache-Speicher konfigurieren aus.
Die Aufgaben zum Konfigurieren eines Cache-Speichers richten sich danach, ob Sie einen Speicher-Cache oder einen Platten-Cache verwenden möchten.
Wenn Sie einen Speicher-Cache verwenden möchten, müssen Sie den Wert für die Einstellung "Cache-Speicher" so wählen, dass der gesamte Inhalt eines Cache aufgenommen werden kann. Informationen zu den empfohlenen Größen für den Cache-Speicher finden Sie im Abschnitt Cache-Speicher festlegen.
Wenn Sie einen Platten-Cache verwenden möchten, gehen Sie wie folgt vor:
Für den Cache ist eine speziell formatierte Einheit erforderlich. Es empfiehlt sich, eine vollständige Einheit oder Plattenpartition für den Cache zu reservieren. Die Mindestgröße für einen Cache sind 16.392 KB.
Gehen Sie wie folgt vor, um die Cache-Einheit zu formatieren:
htcformat Pfad_der_unformatierten_Einheit [-blocksize Blockgröße] [-blocks Anzahl_Blöcke]Die Argumente -blocksize und -blocks sind optional. Die Standardblockgröße sind 8192 Bytes. Wenn die Anzahl der Blöcke nicht angegeben ist, wird die maximal mögliche Anzahl von Blöcken auf die Plattenpartition geschrieben.
Achten Sie bei der Angabe des Einheitenpfades darauf, dass Sie den Pfad der unformatierten Einheit angeben.
raw /dev/raw/raw1 dev/sdb1
Zusätzliche Informationen zum Zugriff auf unformatierte Einheiten finden Sie im Referenzmaterial zu Ihrem Dateisystem.
Wenn das Betriebssystem versucht, auf die Cache-Einheit zu schreiben, können zwischengespeicherte Daten verloren gehen. Sie können dies verhindern, indem Sie mit dem Windows-Dienstprogramm "Datenträgerverwaltung" die Platte vorbereiten, bevor Sie den Befehl htcformat ausführen. Löschen Sie zur Vorbereitung der Platte mit dem Plattendienstprogramm die Einheit oder Partition, die Sie verwenden möchten, und erstellen Sie sie anschließend erneut, ohne sie zu formatieren. Dieser Schritt bewirkt, dass das System die Einheit für den Systemspeicher als nicht verfügbar einstuft.
Legen Sie den Wert gemäß den folgenden Richtlinien mit der Anweisung CacheMemory (oder im Feld Cache-Speicher des Konfigurationsformulars Cache-Einstellungen) fest. Die mit diesem Wert festgelegte Speicherkapazität wird für die Unterstützung der Cache-Infrastruktur einschließlich des Cache-Index und, sofern das Speicher-Caching konfiguriert wurde, für das Speichern des Cache-Inhalts verwendet.
Damit Platten-Caches mit optimaler Leistung arbeiten können, wird für die Einstellung "Cache-Speicher" ein Mindestwert von 64 MB für die Unterstützung der Cache-Infrastruktur einschließlich Cache-Index empfohlen. Mit zunehmender Größe des Cache wächst auch der Cache-Index an, und es wird zusätzlicher Cache-Speicher für das Speichern des Index benötigt. 64 MB für den Cache-Speicher reichen aus, um die Unterstützung der Cache-Infrastruktur zu gewährleisten und den Cache-Index für einen Platten-Cache mit einer Größe von bis zu 6,4 GB zu speichern. Für größere Platten-Caches sollte der Cache-Speicher 1 % der Cache-Größe betragen.
Bei Speicher-Caches entspricht der Wert für den Cache-Speicher der Speicherkapazität, die für die Unterstützung der Cache-Infrastruktur und den Cache selbst reserviert wurde. Für den Cache-Speicher wird ein Mindestwert von 64 MB empfohlen.
Wenn zu viel physischer Speicher für den Speicher-Cache reserviert wird, können unerwünschte Folgen auftreten, z. B. Fehler wegen mangelnder Speicherkapazität oder Fehler des Proxy-Servers. Die Einschränkungen bezüglich der Einstellung des Cache-Speichers sind auf die Einschränkungen von 32-Bit-Anwendungen zurückzuführen. Da Caching Proxy eine 32-Bit-Anwendung ist, können maximal 2 GB Hauptspeicher verwendet werden.
Caching Proxy reserviert den mit der Anweisung CacheMemory definierten Hauptspeicher und verwendet diesen als Cache für das Speichern von Objekten. Unabhängig davon, ob der Cache ein Speicher-Cache oder ein Platten-Cache ist, müssen Sie zusätzlichen Speicher für die Cache-Datenstrukturen, die Netz-E/A- und Verbindungspuffer, die Sitzungspuffer und den Hauptprozess und alle Threads reservieren. Darüber hinaus kann es erforderlich sein, für Anforderungen bestimmter Clients einen größeren Speicherpoolblock zu reservieren als standardmäßig vorgesehen. Wenn mit der Anweisung CacheMemory ein Wert knapp unterhalb des 2-GB-Grenzwerts festgelegt wurde, steht Caching Proxy möglicherweise nicht genügend Speicher für die Ausführung zur Verfügung, insbesondere dann, wenn die Arbeitslast sehr hoch ist.
Es wird empfohlen, die Anweisung CacheMemory auf einen Wert kleiner-gleich 1.600 MB zu setzen. Falls Sie einen höheren Wert als 1.600 MB angeben, geht dies zu Lasten des Speichers, den Caching Proxy für den normalen Betrieb benötigt, und verursacht nachteilige Nebeneffekte. Diese Nebeneffekte äußern sich normalerweise, aber nicht ausschließlich in einer erhöhten CPU-Belastung (möglicherweise bis zu einer Belastung von 100 %), im Auftreten von Fehlern wegen mangelnder Speicherkapazität und in einer schlechteren Leistung. Ist insgesamt ein größerer Cache erforderlich, sollten Sie Cache-Einheiten verwenden oder eine Konfiguration implementieren, die einen gemeinsam genutzten Cache mit RCA oder ICP vorsieht.
Sie können den Cache-Inhalt aus einer Speicherauszugsdatei importieren oder in eine Speicherauszugsdatei exportieren. Dies ist nützlich, wenn bei einem Neustart Cache-Speicher verloren geht oder wenn derselbe Cache für mehrere Proxy-Server implementiert wird.
Sie können den Umfang der zwischenzuspeichernden Inhalte einschränken, indem Sie Filter für den Abgleich von URL-Anforderungsformaten verwenden. Nähere Informationen zum Konfigurieren von Filtern finden Sie in Zwischenzuspeichernde Inhalte steuern.
Sie können den Proxy-Server so konfigurieren, dass die Ergebnisse von Abfrageanforderungen zwischengespeichert werden. Standardmäßig werden URLs, die ein Fragezeichen (?) enthalten, nicht zwischengespeichert. Nähere Informationen hierzu finden Sie im Abschnitt Abfrageantworten zwischenspeichern.
Es können auch die Ergebnisse einer Servlet- oder JSP-Ausführung in einem IBM WebSphere Application Server zwischengespeichert werden. Nähere Informationen hierzu finden Sie in Caching von dynamisch erstelltem Inhalt.
In Cache-Inhalt verwalten wird beschrieben, wie Sie das Verfallsdatum für Dateien im Cache konfigurieren und festlegen können, wie veraltete Dateien gelöscht werden sollen.
Der Cache kann so konfiguriert werden, dass die am häufigsten verwendeten Dateien täglich aktualisiert werden, bevor sie angefordert werden. Nähere Informationen hierzu finden Sie in Den Cache-Agenten für automatische Aktualisierung und Vorabladen konfigurieren.
In bestimmten Situationen kann durch die Verwendung eines gemeinsam genutzten Cache die Wahrscheinlichkeit erhöht werden, dass eine angeforderte Datei im Cache gefunden wird. Nähere Informationen hierzu finden Sie in Gemeinsamen Cache verwenden.
Die Verwaltung exakter Protokolle ist für die Verwaltung von Caching Proxy von entscheidender Bedeutung. In Caching Proxy überwachen finden Sie Informationen zum Konfigurieren und Verwenden der Proxy-Server-Protokolle.
Caching Proxy stellt mehrere Filtermethoden zur Verfügung, mit denen Sie steuern können, welche Dateien, Dokumente und anderen Objekte zwischengespeichert werden:
Der Proxy-Server kann so konfiguriert werden, dass er Anforderungen mit einer URL-Schablone vergleicht, um festzustellen, ob eine Datei zwischengespeichert wird. Zur Konfiguration dieser Funktion werden Schablonen für Anforderungen definiert, deren Dateien immer zwischengespeichert werden. Außerdem können separate Schablonen für die Anforderungen definiert werden, deren Dateien nicht zwischengespeichert werden dürfen. Es können mehrere Schablonen verwendet werden.
Ein ähnliches Verfahren wird verwendet, um das Caching für Abfrageantworten zu aktivieren. Nähere Informationen hierzu finden Sie im Abschnitt Abfrageantworten zwischenspeichern.
Wenn Sie die URL-Caching-Filter in der Datei ibmproxy.conf definieren möchten, finden Sie diesbezügliche Anleitungen in den Abschnitten CacheOnly - Nur Dateien im Cache speichern, deren URLs mit einer Schablone übereinstimmen und NoCaching - Dateien, deren URLs mit einer Schablone übereinstimmen, nicht im Cache speichern.
Wenn Sie die URL-Caching-Filter in den Konfigurations- und Verwaltungsformularen definieren möchten, verwenden Sie hierfür das Feld Filter für Zwischenspeicherung nach URL im Formular Cache-Konfiguration -> Cache-Verhalten. In diesem Abschnitt geben Sie die URLs, deren Dateien immer zwischengespeichert werden, oder die URLs an, deren Dateien nicht zwischengespeichert werden. Wenn Sie zwei Listen anlegen möchten, eine mit den Dateien, die immer zwischengespeichert werden sollen, und eine andere mit Dateien, die nicht zwischengespeichert werden sollen, müssen Sie zuerst die eine Liste erstellen und dann auf die Schaltfläche Übergeben klicken, bevor Sie die andere Liste erstellen.
Die Antworten, die auf Abfragen (d. h. auf URL-Anforderungen, die ein Fragezeichen (?) enthalten), zurückgegeben werden, können unter Verwendung von Caching-Filtern zwischengespeichert werden. Dies kann in Szenarios mit einem Reverse Proxy (Ersatz) hilfreich sein, wenn viele Clients dieselbe Abfrage senden.
Sie können das Caching für Abfragen konfigurieren, indem Sie die Anweisung CacheQueries in der Konfigurationsdatei ibmproxy.conf editieren. Die Anweisung CacheQueries unterstützt folgende Optionen:
Zusätzliche Informationen zu diesen Optionen finden Sie im Abschnitt CacheQueries - Cache-Antworten auf URLs festlegen, die ein Fragezeichen (?) enthalten.
Wenn Sie das Caching für Abfrageantworten mit den Konfigurations- und Verwaltungsformularen konfigurieren möchten, verwenden Sie hierfür das Feld Abfrage/Antwortfilter für Zwischenspeicherung nach URL im Formular Cache-Konfiguration -> Cache-Verhalten. Wenn Sie zwei Listen anlegen möchten, müssen Sie zuerst die eine Liste erstellen und dann auf Übergeben klicken, bevor Sie die andere Liste erstellen.
Nachdem Sie die Einstellung für das Caching von Abfragen konfiguriert haben, müssen Sie sich vergewissern, ob die folgenden Einstellungen für das Caching von Abfrageantworten richtig konfiguriert sind. Informationen zum Festlegen dieser Optionen in den Konfigurations- und Verwaltungsformularen finden Sie im Abschnitt Cache-Aktualität konfigurieren.
Da eine Zwischenspeicherung der vom Proxy-Server bereitgestellten Dateien in der Regel nicht effizient ist, werden Dateien, die aus der lokalen Domäne des Servers stammen, standardmäßig nicht zwischengespeichert. Wenn Sie Objekte, die aus der lokalen Domäne des Servers stammen, zwischenspeichern möchten, wählen Sie das Feld Lokalen Domänendateien zwischenspeichern im Konfigurations- und Verwaltungsformular Cache-Konfiguration -> Cache-Verhalten aus. Alternativ können Sie die Anweisung CacheLocalDomain in der Konfigurationsdatei des Proxy-Servers auf on setzen.
Für die Entscheidung, ob ein Objekt zwischengespeichert wird, kann anstelle des vollständigen URL auch nur ein bestimmter (signifikanter) Teil des eingehenden URL herangezogen werden. Diese Art von Filter ist für die transaktionsgesteuerte Bereitstellung von Webinhalten und für dynamisches Caching nützlich, da für diverse eingehende Anforderungen häufig dieselbe Antwort zurückgegeben wird, wenn signifikante Teile der URLs eingehender Anforderungen identisch sind.
Das auf Teil-URLs basierende Caching kann nicht in den Konfigurations- und Verwaltungsformularen festgelegt werden. Sie müssen die Anweisung SignificantUrlTerminator in der Konfigurationsdatei des Proxy-Servers verwenden, um einen Beendigungscode für URL-Anforderungen anzugeben. Diese Spezifikation bewirkt, dass Caching Proxy bei der Verarbeitung der Anforderung nur die Zeichen vor dem Beendigungscode auswertet und anhand des Ergebnisses bestimmt, ob die angeforderte Datei zwischengespeichert wird. Falls mehrere Beendigungscodes definiert sind, vergleicht Caching Proxy die eingehenden URLs in der Reihenfolge mit den Beendigungscodes, in der diese in der Datei ibmproxy.conf definiert sind. Nähere Informationen hierzu finden Sie im Abschnitt SignificantURLTerminator - Abschlusscode für URL-Anforderungen festlegen.
Die Referenzabschnitte zu den folgenden Anweisungen beschreiben, wie Sie Caching-Filter direkt in der Konfigurationsdatei des Proxy-Servers definieren können:
Informationen zu Dokumenten, die nicht zwischengespeichert werden können, finden Sie in Übersicht über das Proxy-Server-Caching.
Da beim Caching eine Kopie der bereitgestellten Datei erstellt und gespeichert wird, müssen routinemäßig Pflegemaßnahmen ergriffen werden, damit der Cache ordnungsgemäß funktioniert. Die Dateien im Cache müssen auf Aktualität geprüft und ungültig gemacht werden, wenn sie nicht mehr mit den Dateien auf dem Ursprungsserver konsistent sind. Dieser Dateiverfallsprozess wird im Abschnitt Dateiverfall beschrieben. Außerdem müssen ungültige und nicht mehr verwendete Dateien aus dem Cache gelöscht werden, um Platz für neue Dateien zu machen. Dieser Cache-Bereinigungsprozess wird im Abschnitt Garbage-Collection beschrieben.
Die Aufgabe, die Objekte im Cache mit den Originalobjekten auf dem Inhaltsserver konsistent zu halten, wird als Aufrechterhalten der Cache-Aktualität bezeichnet. Für jedes Dokument oder andere Objekt, das Caching Proxy im Cache speichert, wird ein Zeitpunkt errechnet, zu dem das Dokument verfällt.
Für HTTP-Seiten enthält der Header des Dokuments, der vom Inhaltsserver generiert wird, die Informationen zum Verfallszeitpunkt.
Weil das Protokoll FTP keine äquivalenten Informationen zur Verfallszeit enthält, generiert Caching Proxy für FTP-Dateien einen eigenen Header Last-Modified:, der auf den FTP-Verzeichnisinformationen der Dateien basiert, und berechnet anhand dieser Informationen die Verfallszeit. Kann der Proxy-Server für eine Datei auf dem FTP-Server keine Verzeichnisinformation abrufen, wird der für den FTP-URL passende Standardwert verwendet. Weil für FTP-Server kein Standarddatumsformat existiert, kann Caching Proxy die von einigen FTP-Servern gesendeten Angaben zu Datum und Uhrzeit möglicherweise nicht interpretieren. In diesen Fällen wird die Standardverfallszeit des Proxy-Servers verwendet. Durch Verwendung dieser Prozedur kann der Proxy-Server das Caching von HTTP-Seiten und FTP-Dateien auf ähnliche Weise durchführen.
Der Verfallszeitpunkt kann von einem Inhaltsserver auf eine der folgenden Arten angegeben werden (in der gewünschten Reihenfolge):
Nachdem die Verfallszeit wie oben beschrieben berechnet wurde, prüft Caching Proxy, ob ein Wert für die Mindesthaltezeit für diesen URL existiert. Ist dies der Fall und ist die angegebene Zeit länger als die errechnete Verfallszeit, wird die angegebene Mindesthaltezeit als Verfallszeit des Objekts verwendet. Dies gilt auch, wenn Caching Proxy für ein Dokument eine Verfallszeit von 0 Minuten berechnet. Sie müssen deshalb bei der Einstellung der Mindesthaltezeit sorgfältig vorgehen, um zu verhindern, dass veraltete Inhalte bereitgestellt werden. (Verwenden Sie zum Festlegen der Mindesthaltezeit die Anweisung CacheMinHold oder die Einstellung URL-Verfallszeit im Formular Cache-Konfiguration -> Einstellungen für Verfallszeit des Cache. Nähere Informationen hierzu finden Sie im Abschnitt Cache-Aktualität konfigurieren.)
Der endgültige Wert für die Verfallszeit wird mit der Zeit verglichen, die die Einstellung Zeitlimit angibt. Ist die Verfallszeit größer als der Wert für Zeitlimit, wird das Dokument zwischengespeichert. Andernfalls wird es dem Cache nicht hinzugefügt. (Anweisungen zum Festlegen des Werts für Zeitlimit finden Sie im Abschnitt Cache-Aktualität konfigurieren.)
Wenn das Dokument im Cache gefunden wird, die Verfallszeit aber überschritten ist, sendet Caching Proxy eine spezielle Anforderung, if-modified-since, an den Inhaltsserver. Diese Anforderung veranlasst den Inhaltsserver, das Dokument nur in dem Fall zu senden, wenn es seit dem letzten Empfang auf dem Proxy-Server geändert wurde. Wenn das Dokument nicht geändert wurde, sendet der Inhaltsserver nur eine entsprechende Nachricht und sendet die Seite nicht erneut. In diesem Fall ruft der Proxy-Server das Dokument aus dem Cache ab. Für FTP-Dateien simuliert der Proxy-Server diesen "if-modified-since"-Prozess. Wenn festgestellt wird, dass die Datei auf dem FTP-Server nicht geändert wurde, wird die Datei aus dem Cache abgerufen. Andernfalls wird die neuere Version vom FTP-Server abgerufen.
Dies gilt nur für Forward-Proxy-Konfigurationen.
Da das Protokoll FTP nicht über so strenge Definitionen für Datum und Uhrzeit verfügt wie das Protokoll HTTP, können einige Faktoren dazu führen, dass der Header "Last-Modified", den der Proxy-Server für FTP-Dateien generiert, geringfügig vom tatsächlichen Datum der Datei abweicht. Dazu zählen folgende Faktoren:
Wenn eine FTP-Datei im Cache verfällt, simuliert der Proxy-Server die HTTP-Gültigkeitsüberprüfung "if modified since" für die FTP-Datei. Dazu wird erneut der FTP-Befehl LIST für die angeforderte Datei ausgeführt, wobei das Dateidatum aus der vom FTP-Server zurückgegebenen Antwort abgerufen und mit dem Datum verglichen wird, das der Proxy-Server beim ursprünglichen Anfordern der Datei aus dem Header "Last-Modified" generiert hat. Ist das Dateidatum unverändert, kennzeichnet der Proxy-Server die FTP-Datei im Cache als neu überprüft, setzt eine neue Verfallszeit für die Datei und gibt die Datei aus dem Cache zurück, anstatt sie erneut vom FTP-Server abzurufen. Weichen die beiden Dateidaten voneinander ab, ruft der Proxy-Server die Datei erneut vom FTP-Server ab und speichert die neue Kopie mit dem neuen Dateidatum im Cache.
Die Verzeichnisinformationen zu der Datei können nicht immer vom FTP-Server abgerufen werden. Falls der Proxy-Server das Dateidatum für die FTP-Datei nicht bestimmen kann, generiert er für die Datei keinen Header "Last-Modified". Stattdessen verwendet er den mit der Anweisung CacheDefaultExpiry angegebenen Wert für den URL, um zu bestimmen, wie lange die Datei zwischengespeichert bleiben soll. Nach Ablauf dieser Zeit ruft der Proxy-Server die Datei erneut vom FTP-Server ab. Wenn es den Anschein hat, dass die Anweisung CacheDefaultExpiry für bestimmte FTP-Dateien im Cache sehr häufig verwendet wird und diese Dateien häufig abgerufen werden (und auf diese Weise einen hohen Datenverkehr im Netz verursachen), sollten Sie in Erwägung ziehen, für diese speziellen Dateien eine differenziertere Angabe der Anweisung CacheDefaultExpiry zu verwenden. Auf diese Weise werden diese Daten länger zwischengespeichert.
Wenn Sie die Einstellungen für die Cache-Verfallszeiten mit den Konfiguration- und Verwaltungsformularen festlegen möchten, verwenden Sie das Formular Cache-Konfiguration -> Einstellungen für Verfallszeit des Cache -> Zeitlimit für Dateien im Cache. Ausführliche Informationen zum Festlegen von Verfallsdaten für Dateien im Cache finden Sie im Abschnitt Dateiverfall.
Wählen Sie in den Konfigurations- und Verwaltungsformularen Cache-Konfiguration -> Einstellungen für Verfallszeit des Cache aus, um die Verfallszeiten für Dateien im Cache festzulegen. Die folgenden Formulare sind hilfreich.
Legen Sie in diesem Formular die Mindestzeit fest, für die Dateien basierend auf ihren URLs im Cache gespeichert bleiben. Sie können für verschiedene URL-Anforderungsschablonen ein unterschiedliches Cache-Verhalten festlegen.
Die Referenzabschnitte zu den folgenden Anweisungen in Anhang B. Anweisungen in der Konfigurationsdatei beschreiben, wie Sie die Verfallszeit für Dateien auf URL-Basis in der Konfigurationsdatei des Proxy-Servers festlegen:
Im Formular Einstellungen für Verfallszeit des Cache können Sie die Standardeinstellungen für die Verfallszeiten von verwendeten oder nicht verwendeten Dateien definieren. Sie können für HTTP-, FTP- und Gopher-Dateien und für verwendete und für nicht verwendete Dateien verschiedene Werte festlegen.
Außerdem enthält dieses Formular weitere Optionen für die Verfallszeit von Dateien:
Die Referenzseiten zu den folgenden Anweisungen beschreiben, wie Sie die Einstellungen für die Standardverfallszeit in der Konfigurationsdatei des Proxy-Servers festlegen:
Im Formular Faktor letzte Änderung wird der Wert festgelegt, mit dem der Proxy-Server das Verfallsdatum für Cache-Dateien berechnet, die keine Verfallsdaten im Header enthalten. Sie können für Dateien, die mit verschiedenen Anforderungsschablonen übereinstimmen, unterschiedliche Werte definieren. Die erste Schablone, mit der eine Übereinstimmung erzielt wird, wird zur Berechnung des Verfallsdatums verwendet.
Informationen zum Festlegen des Faktors letzte Änderung (Last Modified) durch direktes Editieren der Konfigurationsdatei des Proxy-Servers finden Sie im Abschnitt CacheLastModifiedFactor - Wert zur Berechnung der Verfallsdaten angeben.
Im Konfigurationsformular Zeitlimit für Dateien im Cache können Sie die maximale Verweildauer einer Datei im Cache definieren. Die Zeitlimits werden basierend auf den Anforderungsschablonen definiert. Sie können festlegen, dass Dateien nach Ablauf des Zeitlimits gelöscht oder neu überprüft werden sollen. Mit diesen Einstellungen können Dateien, deren Verfallsdaten ungültig sind, oder Dateien mit sehr langen Verfallszeiten verwaltet werden.
Informationen zum Festlegen der maximalen Verfallszeit für Dateien im Cache durch Editieren der Konfigurationsdatei des Proxy-Servers finden Sie in den folgenden Abschnitten:
Zu den Strategien, häufig aufgerufene URLs im Cache zu speichern und die Verwendung der Systemressourcen zu minimieren, gehört, dass Caching Proxy einen Bereinigungsprozess, die so genannte Garbage-Collection durchführt, bei dem alte oder nicht verwendete Dateien aus dem Cache entfernt werden, um Platz für aktuelle Dateien zu schaffen.
Bei der Garbage-Collection werden die Dateien im Cache-Verzeichnis zunächst überprüft. Die verfallenen Dateien werden gelöscht, um den Cache zu verkleinern und Platz für neue Dateien zu schaffen. Die Garbage-Collection wird automatisch durchgeführt. Sie können jedoch einige Einstellungen konfigurieren, um den Prozess an Ihre Voraussetzungen anzupassen.
Zum Konfigurieren der Garbage-Collection wählen Sie in den Konfigurations- und Verwaltungsformularen Cache-Konfiguration -> Einstellungen für Garbage-Collection aus. In diesem Formular können Sie den oberen Grenzwert und den unteren Grenzwert definieren. Diese Werte legen fest, wann die Garbage-Collection gestartet und gestoppt wird. Wenn der vom Cache belegte Speicherplatz den als oberen Grenzwert festgelegten Prozentsatz erreicht oder überschreitet, wird die Garbage-Collection gestartet. Die Garbage-Collection wird so lange fortgesetzt, bis der Prozentsatz des durch den Cache belegten Speicherplatzes kleiner-gleich dem unteren Grenzwert ist.
Sie können zwischen zwei Algorithmen für die Garbage-Collection wählen. Der Algorithmus responsetime (Antwortzeit) optimiert die Antwortzeiten, indem vorzugsweise große Dateien aus dem Cache entfernt werden. Der Algorithmus bandwidth (Bandbreite) optimiert die Nutzung der Netzbandbreite, indem vorzugsweise kleinere Dateien aus dem Cache entfernt werden. Sie können einen der beiden Algorithmen oder eine Kombination aus beiden auswählen.
Informationen zum Konfigurieren der Garbage-Collection durch Editieren der Konfigurationsdatei des Proxy-Servers finden Sie in den Referenzabschnitten zu den folgenden Anweisungen:
Die meisten Proxy-Server, die Caching unterstützen, speichern eine Datei nur dann im Cache, wenn ein Benutzer sie anfordert. Caching Proxy verfügt über einen Cache-Agenten, der ein automatisches Vorabladen in den Cache durchführt. Sie können festlegen, dass der Cache-Agent bestimmte URLs automatisch abruft und/oder dass er die am häufigsten angeforderten URLs abruft und diese im Cache speichert, bevor sie angefordert werden.
In einigen Fällen müssen der Hostname des Proxy-Servers und das Cache-Zugriffsprotokoll angegeben werden, damit der Cache vorab geladen werden kann. Wählen Sie zum Konfigurieren des Cache-Agenten in den Konfigurations- und Verwaltungsformularen Cache-Konfiguration aus und rufen Sie dann die Formulare Vorabladen des Cache und Cache-Aktualisierung auf. Dateien, die Abfrageergebnisse enthalten (d. h. deren URLs das Fragezeichen (?) enthalten), werden nur dann zwischengespeichert, wenn das Caching von Abfragen aktiviert ist.
Die automatische Cache-Aktualisierung und das automatische Vorabladen des Cache bieten folgende Vorteile:
Die Nachteile sind:
Aus Gründen der Effizienz sollte der Agent zur Cache-Aktualisierung so konfiguriert werden, dass er ausgeführt wird, wenn der Server freie Kapazitäten aufweist und bevor der Server durch Clientanforderungen in Anspruch genommen wird. In diesem Fall stehen die Dateien im Cache bereit und können schnell abgerufen werden, wenn der Benutzer diese zum ersten Mal anfordert. Standardmäßig wird der Cache-Agent jede Nacht um 3 Uhr Ortszeit gestartet.
Spezielle Hinweise für Reverse-Proxy-Konfigurationen:
Aus Sicherheitsgründen sollte die Regel Proxy http:* standardmäßig inaktiviert werden, wenn eine Reverse-Proxy-Konfiguration verwendet wird (d. h. diese Regel ist in der Datei ibmproxy.conf auf Kommentar gesetzt). Wenn diese Regel inaktiviert ist, kann der Cache-Agent jedoch keine Anforderungen senden und den Cache-Inhalt von Caching Proxy aktualisieren. Im Fehlerprotokoll erscheint der Fehler "403 Forbidden By Rule Error", und die Cache-Aktualisierung wird nicht durchgeführt.
Sie können dieses Problem vermeiden, indem Sie den Service cacheAgentService verwenden, einen internen Service, der von Caching Proxy bereitgestellt wird. Zum Aktivieren des Service fügen Sie die folgende Service-Anweisung vor den anderen Zuordnungsregeln in der Datei ibmproxy.conf ein:
Service /gültige_Zeichenfolge* INTERNAL:cacheAgentService
Die Variable gültige_Zeichenfolge steht für eine beliebige Zeichenfolge, die gültig ist und mit keiner der anderen Zuordnungsregeln in der Datei ibmproxy.conf in Konflikt steht.
Caching Proxy und der Cache-Agent analysieren die Syntax des URI basierend auf dieser Service-Anweisung. Anstatt den URI direkt an Caching Proxy zu senden, stellt der Cache-Agent dem URI das Muster /gültige_Zeichenfolge aus der Service-Anweisung voran.
Der Cache-Agent setzt den URI
http://www.ibm.com/
beispielsweise wie folgt um:
/gültige_Zeichenfolge/http://www.ibm.com/
Der Cache-Agent sendet den URI mit dem Präfix an Caching Proxy. Beim Empfang der Anforderung entfernt Caching Proxy das Präfix /gültige_Zeichenfolge/. Wenn der verbleibende URI eine vollständig qualifizierte Einheit ist, bearbeitet Caching Proxy die Anforderung direkt, ohne den URI mit anderen Regeln abzugleichen.
Außerdem kann der Cache-Agent einen relativen URI an Caching Proxy senden. Wenn Sie beispielsweise LoadURL /abc/ mit der zuvor beschriebenen Service-Anweisung in der Datei ibmproxy.conf hinzufügen, setzt der Cache-Agent diesen URI in /gültige_Zeichenfolge/abc/ um und sendet ihn an Caching Proxy. Caching Proxy empfängt den URL, entfernt das Präfix, gleicht /abc/ mit anderen Zuordnungsregeln ab und bearbeite die Anforderung, sofern eine Übereinstimmung vorliegt.
Weitere Informationen zur Anweisung Service finden Sie im Abschnitt Service - Schritt "Service" anpassen.
Legen Sie auf Linux- und UNIX-Plattformen den Hostnamen des Proxy-Servers fest, dessen Cache vorab geladen oder aktualisiert werden soll. Legen Sie auf Windows-Plattformen den Hostnamen nur dann fest, wenn der zu aktualisierende Proxy-Server nicht auf der lokalen Maschine ausgeführt wird. (Beachten Sie, dass das Aktualisieren des Cache eines fernen Servers basierend auf den Dateien, auf die am häufigsten zugegriffen wird, nicht möglich ist, da der lokale Cache-Agent keinen Zugriff auf das Cache-Zugriffsprotokoll eines fernen Servers hat.)
Zum Festlegen des Hostnamens für den Proxy-Server wählen Sie in den Konfigurations- und Verwaltungsformularen Cache-Konfiguration -> Cache-Aktualisierung: Cache-Zielserver angeben aus.
Um den Inhalt bestimmter URLs vorab in den Cache zu laden, wählen Sie in den Konfigurations- und Verwaltungsformularen Cache-Konfiguration -> Vorabladen des Cache aus. In diesem Formular können Sie die URLs angeben, die der Cache-Agent laden soll. Der Proxy-Server ruft diese Seiten ab, wenn der Cache-Agent gestartet wird, unabhängig davon, ob diese bereits im Cache enthalten waren. (Diese URLs werden in der Konfigurationsdatei des Proxy-Servers mit der Anweisung LoadURL angegeben.) Dieses Formular kann auch verwendet werden, um URLs zu definieren, deren Inhalt nicht im Cache gespeichert werden soll. Für diese Art des Vorabladens in den Cache ist kein Zugriff auf ein Cache-Zugriffsprotokoll erforderlich.
Mit dem Formular Vorabladen des Cache können folgende Optionen konfiguriert werden:
Damit die am häufigsten aufgerufenen Seiten automatisch vorab geladen werden, verwenden Sie das Formular Cache-Konfiguration -> Cache-Aktualisierung. Diese Funktion setzt voraus, dass der Proxy-Server über ein Cache-Zugriffsprotokoll verfügt. (Position und Name des Protokolls können geändert werden. Nähere Informationen finden Sie in Caching Proxy überwachen.) Die am häufigsten aufgerufenen URLs werden automatisch anhand des Cache-Zugriffsprotokolls ermittelt. Der Administrator kann darüber hinaus eine Anzahl von häufig verwendeten Seiten festlegen, die in den Cache geladen werden sollen. (Diese Anzahl wird in der Konfigurationsdatei des Proxy-Servers mit der Anweisung LoadTopCached festgelegt.)
Mit dem Formular Cache-Aktualisierung können Sie folgende Optionen konfigurieren:
Delving ist eine optionale Teilfunktion der Funktion für automatische Cache-Aktualisierung. Die meisten Webseiten enthalten Links zu anderen Seiten mit zugehörigen Informationen. Benutzer folgen oft den Link-Pfaden von einer Seite zu einer anderen und von einer Site zu einer anderen. Mit Delving können diese logischen Informationspfade im Cache gespeichert werden. Beim Delving folgt der Cache-Agent einer festgelegten Anzahl von HTML-Links auf den Seiten, die er lädt, und lädt auch alle diese über Links verknüpften Seiten in den Cache. Die über Links verknüpften Seiten können sich auf demselben Host wie die Ursprungsseite oder auf anderen Hosts befinden. Abb. 1 zeigt eine grafische Darstellung dieser Links.
Zum Steuern des Delving-Prozesses legt der Administrator für den Cache-Agenten eine maximale Anzahl URLs fest, die dieser laden kann (die Standardeinstellung ist 2000), sowie eine maximale Zeitdauer für die Ausführung (die Standardeinstellung ist zwei Stunden) und eine maximale Anzahl Threads, die verwendet werden kann (die Standardeinstellung ist vier). Darüber hinaus kann der Administrator weitere Steuerelemente konfigurieren. Standardmäßig ist Delving für zwei Hierarchieebenen aktiviert, aber nicht hostübergreifend möglich. Zusätzlich dazu wird zwischen den einzelnen Anforderungen eine Verzögerung eingefügt. Informationen zum Ändern dieser Einstellungen enthält der Abschnitt Zugehörige Anweisungen in der Konfigurationsdatei des Proxy-Servers.
Der Cache-Agent lädt und aktualisiert den Cache anschließend in dieser Reihenfolge:
Beachten Sie, dass der Cache-Agent erst beim Starten des Link-übergreifenden Delving prüft, ob die maximale Anzahl Seiten erreicht wurde. Wenn der Wert für die maximale Anzahl Seiten (in der Konfigurationsdatei des Proxy-Servers mit MaxURLs festgelegt) kleiner ist als die Anzahl Seiten, die in den Schritten 1 und 2 bereits abgerufen wurden, werden keine weiteren über Links verknüpften Seiten abgerufen.
Die folgenden Beispiele veranschaulichen, wie der Cache-Agent die Prioritäten für die Cache-Aktualisierung und die Delving-Funktion abhängig von der festgelegten maximalen Anzahl URLs behandelt. (Dabei wird angenommen, dass die Delving-Funktion für alle diese Beispiele konfiguriert ist.)
Einstellung in der Konfigurationsdatei | Ergebnis |
---|---|
LoadURL http://www.getthis.com/main.html LoadURL http://www.getmetoo.com/welcome.htm LoadTopCached 30 MaxURLs 50 |
Wenn das Cache-Zugriffsprotokoll mehr als 30 eindeutige URLs enthält, ruft der Cache-Agent die Seiten main.html, welcome.htm und die 30 URLs ab, die gemäß dem Cache-Zugriffsprotokoll am häufigsten angefordert wurden. Da der Wert für MaxURLs nicht erreicht wurde, ruft der Cache-Agent ausgehend von den Seiten, die bereits im Cache gespeichert wurden, bis zu 18 über Links verknüpfte URLs ab und lädt sie. |
LoadURL http://ww.joesmith.edu/favorites.html LoadURL http://www.janesmith.edu/dislikes.html LoadTopCached 30 MaxURLs 25 |
Wenn das Cache-Zugriffsprotokoll mehr als 30 eindeutige URLs enthält, ruft der Cache-Agent die Seiten favorites.html und dislikes.html sowie die 30 URLs ab, die gemäß dem Cache-Zugriffsprotokoll am häufigsten angefordert wurden. Es werden keine anderen Dateien abgerufen, da der Wert von MaxURLs erreicht wurde. |
LoadURL http://www.hello.com/hi.htm LoadURL http://www.ballyhoo.com/index.html LoadTopCached 20 MaxURLs 25 |
Wenn das Cache-Zugriffsprotokoll mehr als 20 eindeutige URLs enthält, ruft der Cache-Agent die Seiten hi.htm und index.html, die 20 URLs, die gemäß dem Cache-Zugriffsprotokoll am häufigsten angefordert wurden, und 3 über Links verknüpfte URLs von bereits abgerufenen Seiten ab. Es werden keine anderen Dateien abgerufen, da der Wert von MaxURLs erreicht wurde. |
Der Cache-Agent kann auch durch direktes Editieren der entsprechenden Anweisungen in der Konfigurationsdatei des Proxy-Servers konfiguriert werden. Informationen zu den Anweisungen in der Konfigurationsdatei des Proxy-Servers, die sich auf den Cache-Agenten beziehen, finden Sie auf den folgenden Referenzseiten in Anhang B. Anweisungen in der Konfigurationsdatei:
Wenn die automatische Cache-Aktualisierung aktiviert ist, führt der Cache-Agent zur angegebenen Zeit automatisch eine Cache-Aktualisierung durch. Sie können den Cache-Agenten jedoch auch zu einem beliebigen Zeitpunkt von einer Befehlszeile aus starten.
Verwenden Sie hierfür die folgende ausführbare Datei:
Dabei steht Serverstammverzeichnis für das Laufwerk und das Verzeichnis, in dem Caching Proxy installiert wurde (z. B. C:\Programme\IBM\edge\cp).
Auf Linux- und UNIX-Plattformen können Sie den Cache-Agenten über den Dämon cron automatisch zu verschiedenen Zeitpunkten ausführen. Über cron gesteuerte Jobs werden durch Hinzufügen einer Zeile zur Systemdatei crontab angegeben. Beispiel für einen Eintrag in der Befehlsdatei unter Linux und UNIX:
45 16 * * * /usr/sbin/cacheagt
Mit diesem Befehl wird der Cache-Agent jeden Tag um 16:45 Ortszeit gestartet. Wenn der Cache-Agent mehrmals täglich ausgeführt werden soll, können Sie mehrere Einträge verwenden. Nähere Informationen hierzu finden Sie in der Dokumentation zum Betriebssystem zum Thema Dämon cron.
Wenn Sie den Dämon cron verwenden, um den Cache-Agenten auszuführen, achten Sie darauf, dass Sie die Option für automatische Aktualisierung entweder über das Konfigurationsformular Cache-Konfiguration -> Cache-Aktualisierung oder durch Editieren der Konfigurationsdatei des Proxy-Servers inaktivieren. Andernfalls wird der Cache-Agent mehr als einmal täglich ausgeführt.
Es ist nicht ungewöhnlich, dass ein Zugangspunkt (Point of Presence) im Web mehr Datenverkehr verarbeiten muss, als ein Server bewältigen kann. Dieses Problem kann durch das Hinzufügen von Servern gelöst werden. Bei der Verwendung mehrerer Proxy-Server, die Caching unterstützen, können sich die Inhalte der Caches überlappen. Die Überlappung hat neben unnötigen Redundanzen zur Folge, dass keine maximalen Bandbreiteneinsparungen erzielt werden, weil Dateien im Cache erneut von den Ursprungsservern abgerufen werden müssen, wenn ein Proxy-Server Anforderungen für diese Dateien erhält und diese nicht aus seinem eigenen Cache bedienen kann. Obwohl mehrfaches Caching durch Verwendung einer hierarchischen Kette von Proxy-Servern minimiert werden kann, erfordert dies zusätzliche Datenübertragungen über einen bestimmten Server, und jeder zusätzliche Link in der Kette bedeutet eine zusätzliche Latenzzeit.
Diese Probleme können durch die Verwendung eines gemeinsamen Cache gelöst werden, indem jedem Cache erlaubt wird, seine Inhalte anderen Caches zur Verfügung zu stellen. Bandbreite kann durch folgende Tatsachen eingespart werden:
Es werden zwei Methoden bereitgestellt, mit denen mehrere Caches so verwendet werden können, als wären sie ein einziger logischer Cache:
RCA und ICP können zusammen verwendet werden.
Beachten Sie bei der Planung eines fernen Cache-Zugriffs die folgenden Empfehlungen:
Es sollte auf den fernen Cache-Zugriff verzichtet werden, falls eine dieser Bedingungen nicht erfüllt ist oder unterschiedliche Organisationen unterschiedliche Server verwalten, die Member des RCA-Bereichs sind.
Zum Konfigurieren des fernen Cache-Zugriffs wählen Sie in den Konfigurations- und Verwaltungsformularen Cache-Konfiguration -> Ferner Cache-Zugriff aus. Die Felder in diesem Formular definieren einen benannten Bereich, der einen einzigen logischen Cache verwendet. Geben Sie die erforderlichen Informationen für jedes Member des Bereichs ein.
Informationen zum Konfigurieren des fernen Cache-Zugriffs durch Editieren der Konfigurationsdatei des Proxy-Servers finden Sie in Anhang B. Anweisungen in der Konfigurationsdatei in den Referenzabschnitten zu folgenden Anweisungen:
Das Plug-in Internet Caching Protocol (ICP) erlaubt Caching Proxy, bei der Suche nach HTML-Seiten oder anderen Ressourcen, die im Cache gespeichert werden können, ICP-kompatible Caches abzufragen. Wenn der Proxy-Server eine HTTP-Anforderung empfängt, durchsucht er seinen eigenen Cache nach der Ressource. Wird die Ressource im lokalen Cache nicht gefunden und ist das Plug-in ICP aktiviert, packt der Proxy-Server den URL in ein ICP-Abfragepaket und übermittelt dieses Paket an alle identifizierten ICP-Peer-Caches. Falls ein Peer-Cache antwortet, dass er die Ressource besitzt, ruft der Proxy-Server die Ressource aus dem Cache dieses Peer ab. Antworten zwei oder mehr Peers positiv, wird die erste Antwort verarbeitet. Falls keiner der Peers mit einem Treffer antwortet, wird die Anforderung vom ursprünglichen Server gemäß seines definierten Arbeitsablaufs verarbeitet. Der Proxy-Server kann beispielsweise ein anderes Plug-in aufrufen, mit der RCA-Routine fortfahren (sofern RCA aktiviert ist) oder die angeforderte Ressource selbst abrufen.
Sie können das Plug-in ICP in der Konfigurationsdatei des Proxy-Servers, ibmproxy.conf, aktivieren und konfigurieren. Die Anweisung ServerInit und/oder die Anweisung PreExit muss in der Konfigurationsdatei zum Abschnitt mit den API-Anweisungen hinzugefügt werden, damit das Plug-in ICP verwendet werden kann. Welche Anweisung verwendet wird, ist vom Aufgabenbereich von Caching Proxy im ICP-System abhängig:
Zum Erstellen dieser Anweisungen können Sie die Datei ibmproxy.conf manuell editieren oder, falls der Proxy-Server bereits aktiv ist, eine Verbindung zum Konfigurations- und Verwaltungsformular Serverkonfiguration-> Anforderungsverarbeitung -> Verarbeitung von API-Anforderungen herstellen.
Beachten Sie, dass die Prototypanweisungen (in Form von Kommentaren) zum API-Abschnitt der Datei ibmproxy.conf hinzugefügt wurden. Diese API-Anweisungen sind in einer zweckmäßigen Reihenfolge angeordnet. Wenn Sie API-Anweisungen hinzufügen, um neue Funktionen und Plug-in-Module zu aktivieren, sollten Sie die Anweisungen wie im Prototypabschnitt der Konfigurationsdatei gezeigt anordnen. Alternativ dazu können Sie, falls erforderlich, die Kommentarzeichen für API-Anweisungen entfernen und API-Anweisungen editieren, um die Unterstützung für jede gewünschte Funktion oder jedes gewünschte Plug-in hinzuzufügen.
Die Anweisungen ServerInit und PreExit unterstützen zwei Argumente: (1) den vollständig qualifizierten Pfad der gemeinsam benutzten Bibliothek und (2) den Funktionsaufruf. Diese Argumente werden durch einen Doppelpunkt (:) getrennt. Das erste Argument ist systemspezifisch und abhängig davon, wo die Plug-in-Komponenten installiert sind. Das zweite Argument ist in der gemeinsam genutzten Bibliothek fest codiert und muss wie gezeigt eingegeben werden.
Jede Anweisung in der Konfigurationsdatei des Proxy-Servers muss in einer gesonderten Zeile stehen.
ServerInit Pfad_der_gemeinsam_benutzten_Bibliothek:icpServer
Linux- und UNIX-Systeme:
ServerInit /opt/ibm/edge/cp/internet/lib/plugins/icp/libicp_plugin.so:icpServer
Beispiel für Windows:
ServerInit C:\Programme\IBM\edge\cp\Bin\plugins\icp\icpplugin.dll:icpServer
PreExit Pfad_der_gemeinsam_benutzten_Bibliothek:icpClient
Linux- und UNIX-Systeme:
PreExit /opt/ibm/edge/cp/internet/lib/plugins/icp/libicp_plugin.so:icpClient
Beispiel für Windows:
PreExit C:\Programme\IBM\edge\cp\Bin\plugins\icp\icpplugin.dll:icpClient
Zum Konfigurieren der Plug-in-Einstellungen können Sie die ICP*-Anweisungen in der Konfigurationsdatei des Proxy-Servers hinzufügen oder ändern. Nähere Informationen hierzu finden Sie in den Beschreibungen der folgenden Anweisungen.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Die Funktion für dynamisches Caching ermöglicht Caching Proxy, dynamisch generierten Inhalt in Form von Antworten von JavaServer Pages (JSP) und Servlets, die von einem IBM WebSphere Application Server erstellt wurden, zwischenzuspeichern. Im Anwendungsserver wird ein Caching-Proxy-Adaptermodul verwendet, damit die Antworten so abgeändert werden, dass sie sowohl im Cache des Proxy-Servers als auch im dynamischen Cache des Anwendungsservers gespeichert werden können. Auf diese Weise ist es möglich, dynamisch erstellten Inhalt am Rand des Netzes im Cache zu speichern und den Inhaltshost von der Aufgabe zu befreien, wiederholt Anforderungen an den Anwendungsserver zu senden, wenn mehrere Clients denselben Inhalt anfordern.
Manchmal muss das Caching von Abfragen aktiviert werden, damit die Funktion für dynamisches Caching funktioniert, z. B. wenn die Servlets URLs in Form von Abfragen verwenden. Der Proxy-Server betrachtet jeden URL, der ein Fragezeichen (?) enthält, als Abfrage.
Das Caching von dynamisch generiertem Inhalt bietet folgende Vorteile:
Der Anwendungsserver exportiert nur vollständig erstellte öffentliche Seiten für das Caching durch den Proxy-Server. Private Seiten werden vom Proxy-Server nicht im Cache gespeichert. Beispielsweise kann eine dynamisch generierte Seite von einer öffentlichen Site, die Wettervorhersagen enthält, von IBM WebSphere Application Server exportiert und von Caching Proxy im Cache gespeichert werden. Andererseits kann eine dynamisch generierte Seite, die den Inhalt des elektronischen Warenkorbs eines Benutzers enthält, vom Proxy-Server nicht im Cache gespeichert werden. Damit eine dynamisch generierte Seite im Cache gespeichert werden kann, müssen auch alle Teilkomponenten dieser Seite im Cache speicherbar sein.
Dynamische Dateien im Cache verfallen nicht wie reguläre Dateien, sondern müssen von dem Anwendungsserver, von dem sie generiert wurden, ungültig gemacht (invalidiert) werden.
Die Einträge im dynamischen Cache werden in folgenden Fällen ungültig gemacht:
Einträge des dynamischen Cache werden ungültig gemacht, indem für die spezielle Instanz des Caching-Proxy-Plug-in für dynamisches Caching eine Invalidierungsnachricht generiert wird. Caching Proxy empfängt diese Nachricht als Post-Nachricht an /WES_External_Adapter. Daraufhin löscht Caching Proxy die ungültigen Einträge aus seinem Cache.
Für das dynamische Caching sind folgende Konfigurationsschritte erforderlich.
Befolgen Sie die Anweisungen in der Dokumentation zu IBM WebSphere Application Server, um Ihren Anwendungsserver für die Verwendung des lokalen dynamischen Cache (auch Cache für dynamische Fragmente genannt) zu konfigurieren. Der Cache für dynamische Fragmente arbeitet mit dem externen Cache von Application Server Caching Proxy zusammen.
IBM WebSphere Application Server kommuniziert mit Caching Proxy über ein Softwaremodul, das als Adapter für externen Cache (External Cache Adapter) bezeichnet und mit Application Server installiert wird.
Damit der Proxy-Server dynamisch generierten Inhalt (Ergebnisse von Servlets und JSPs) zwischenspeichern kann, müssen Sie in der Konfigurationsdatei des Proxy-Servers, ibmproxy.conf, zwei Änderungen vornehmen. Die erste Änderung aktiviert das Plug-in-Modul für dynamisches Caching, und die zweite Änderung konfiguriert dieses Plug-in-Modul in der Weise, dass es die Quellen des dynamischen Inhalts, der zwischengespeichert werden kann, erkennt.
Das Plug-in für dynamisches Caching wird mit einer API-Anweisung für den Schritt "Service" aktiviert. Zum Erstellen dieser Anweisung können Sie entweder die Datei ibmproxy.conf manuell editieren, oder, falls der Proxy-Server bereits aktiv ist, in den Konfigurations- und Verwaltungsformularen Folgendes auswählen: Serverkonfiguration -> Anforderungsverarbeitung -> Verarbeitung von API-Anforderungen. Der Inhalt der Anweisung wird in Beispielen weiter hinten in diesem Abschnitt gezeigt.
Eine Prototypanweisung Service zur Aktivierung des dynamischen Caching ist als Kommentar im API-Abschnitt der Datei ibmproxy.conf enthalten. Sie hat den Titel JSP Plug-in. Beachten Sie, dass die API-Prototypanweisungen in einer zweckmäßigen Reihenfolge angeordnet sind. Wenn Sie API-Anweisungen hinzufügen, um neue Funktionen und Plug-in-Module zu aktivieren, sollten Sie die Anweisungen wie im Prototypabschnitt der Konfigurationsdatei gezeigt anordnen. Alternativ dazu können Sie die Kommentarzeichen vor den API-Prototypanweisungen entfernen und sie gegebenenfalls editieren, um die Unterstützung für eine gewünschte Funktion oder ein Plug-in hinzuzufügen.
Definieren Sie die Anweisung Service wie in den folgenden Beispielen gezeigt. (Beachten Sie, dass jede Anweisung in der Konfigurationsdatei des Proxy-Servers in einer Zeile stehen muss, auch wenn die folgenden Beispiele aus Gründen der besseren Lesbarkeit Zeilenumbrüche enthalten.)
Service /WES_External_Adapter /opt/ibm/edge/cp/lib/plugins/ dynacache/libdyna_plugin.o:exec_dynacmd
Service /WES_External_Adapter /opt/ibm/edge/cp/lib/plugins/ dynacache/libdyna_plugin.so:exec_dynacmd
Service /WES_External_Adapter /usr/lib/libdyna_plugin.so:exec_dynacmd
Service /WES_External_Adapter C:\Programme\IBM\edge\cp\bin\plugins\ dynacache\dyna_plugin.dll:exec_dynacmd
Falls Sie die Software Caching Proxy nicht im Standardverzeichnis installiert haben, verwenden Sie Ihren Installationspfad.
Jeder Caching-Proxy-Server muss so konfiguriert sein, dass er die Quelle der dynamisch generierten Dateien erkennt. Fügen Sie für jeden Anwendungsserver, der dynamisch generierten Inhalt auf dem Proxy-Server zwischenspeichert, eine Anweisung ExternalCacheManager zur Datei ibmproxy.conf hinzu. Diese Anweisung gibt einen WebSphere Application Server an, der Ergebnisse auf dem Proxy-Server zwischenspeichert, und definiert eine maximale Verfallszeit für den Inhalt, der von diesem Server stammt. Ausführliche Informationen hierzu finden Sie im Abschnitt ExternalCacheManager - Caching Proxy für dynamisches Caching vom IBM WebSphere Application Server konfigurieren.
Die Server-ID, die in der Anweisung ExternalCacheManager verwendet wird, muss mit der Gruppen-ID übereinstimmen, die in der Zeilengruppe für externe Cache-Gruppen in der Datei dynacache.xml des Anwendungsservers angegeben ist.
Fügen Sie für das vorherige Beispiel folgenden Eintrag zur Datei ibmproxy.conf eines jeden Proxy-Servers hinzu:
ExternalCacheManager IBM-edge-cp-XYZ-1 20 seconds
Caching Proxy speichert nur den Inhalt eines IBM WebSphere Application Server im Cache, dessen Gruppen-ID mit einem ExternalCacheManager-Eintrag in der Datei ibmproxy.conf übereinstimmt.
Wenn das Caching aktiviert ist, ist die Geschwindigkeit der Cache-Speichereinheiten für die Leistung von Caching Proxy von entscheidender Bedeutung. Dieser Abschnitt enthält Empfehlungen zur Auswahl der Cache-Speicherart und zur optimalen Konfiguration der Cache-Speichereinheiten.
Caching Proxy kann zwei verschiedene Arten von Cache-Speichermedien verwenden:
Ein Speicher-Cache ist die schnellste Methode zum Abrufen von Dateien, aber die Größe eines solchen Cache wird durch die Größe des verfügbaren Speichers auf der Proxy-Server-Maschine beschränkt. Ein Platten-Cache, der sich aus einer oder mehreren unformatierten Plattenpartitionen zusammensetzt, ist langsamer als ein Speicher-Cache, unterstützt jedoch in den meisten Fällen größere Caches.
Die für das Platten-Caching verwendeten Einheitenpartitionen müssen für den Cache reserviert werden, d. h. verwenden Sie diese physischen Platten nicht für andere Dateisysteme und für keinen anderen Zweck als zum Speichern des Proxy-Cache. Verwenden Sie außerdem auf keiner der für den Proxy-Cache vorgesehenen Platten Datenkomprimierung. Dadurch wird die Leistung beeinträchtigt.
Jede Cache-Speichereinheit (ob Platte oder Datei) bedeutet zusätzlichen Hauptspeicherbedarf für den Proxy-Server. Im Allgemeinen wird bei Verwendung eines vollständigen physischen Datenträgers als Cache-Einheit die beste Leistung erzielt. Der Einsatz von RAID oder anderen Methoden zum Kombinieren mehrerer physischer Datenträger zu einem einzelnen logischen Datenträger kann eine Verschlechterung der Leistung zur Folge haben. Wenn Sie mehrere Platten verwenden möchten, definieren Sie diese im Konfigurationsformular Cache-Einstellungen oder durch Editieren der Anweisung CacheDev in der Konfigurationsdatei des Proxy-Servers einzeln als Cache-Einheiten. Diese Methode ermöglicht dem Proxy-Server, die gleichzeitigen Lese- und Schreibvorgänge auf mehreren Datenträgern zu steuern, ohne dabei von der Leistung des Betriebssystems oder eines Plattensubsystems abhängig zu sein.
Bei der Garbage-Collection des Proxy-Server-Cache werden verfallene Dateien aus dem Cache gelöscht, wodurch Speicher für das Caching von Dateien für neue Anforderungen freigemacht wird. Die Garbage-Collection wird automatisch ausgelöst, wenn die Auslastung des Speichers den vom Administrator festgelegten Grenzwert erreicht, der als oberer Grenzwert bezeichnet wird. Sie wird fortgesetzt, bis der untere Grenzwert für die Auslastung des Speichers erreicht ist.
Da bei der Garbage-Collection ein Minimum an CPU-Ressourcen verbraucht wird und die Verfügbarkeit der noch nicht verfallenen, zwischengespeicherten Dateien nicht beeinträchtigt wird, ist es nicht erforderlich, die Garbage-Collection zu bestimmten Zeiten durchzuführen.
Zur Verbesserung der Leistung der Garbage-Collection können Sie einen oberen Grenzwert und einen unteren Grenzwert festlegen. Sie können außerdem den Algorithmus konfigurieren, den die Garbage-Collection verwenden soll. Nähere Informationen zum Ändern der Garbage-Collection finden Sie im Abschnitt Garbage-Collection.
Nachfolgend sind zusätzliche Vorschläge für die Optimierung der Cache-Leistung auf jeder Plattform aufgeführt.
Erstellen Sie einen logischen Datenträger auf einer Platte, vorzugsweise unter Einbeziehung aller verfügbaren physischen Partitionen. Erstellen Sie beispielsweise auf einer 9-GB-Platte einen logischen Datenträger mit einer Größe von 9 GB und dem Namen cpcache1. Formatieren Sie ihn und legen Sie ihn als Proxy-Cache-Einheit fest. Verwenden Sie dazu den unformatierten logischen Datenträger /dev/rcpcache1.
Erstellen Sie auf der Cache-Einheit eine Partition (oder einen Sektor) in der Gesamtgröße des Datenträgers. Beispiel: Erstellen Sie auf einer 9-GB-Platte eine 9-GB-Partition mit dem Namen c1t3d0s0. Formatieren Sie die Partition und legen Sie sie als Proxy-Cache-Einheit fest. Verwenden Sie dazu die unformatierte Einheit (Raw Device) /dev/rdsk/c1t3d0s0.
Erstellen Sie eine Partition in der Gesamtgröße des Datenträgers. Beispiel: Erstellen Sie auf einer 9-GB-Platte eine 9-GB-Partition mit dem Namen i:. Formatieren Sie die Partition und legen Sie sie als Proxy-Cache-Einheit fest. Verwenden Sie dazu die unformatierte Einheit \\.\i:.
Informationen zum Konfigurieren des Proxy-Server-Cache und zum Formatieren und Definieren der Cache-Einheiten finden Sie in Proxy-Server-Caching konfigurieren.
Dieser Teil enthält Informationen zur Basissicherheit, zur Verwendung von SSL in Caching Proxy, zum Aktivieren von Verschlüsselungshardware sowie zur Verwendung des Plug-in IBM Tivoli Access Manager (früher Tivoli Policy Director) und des Autorisierungsmoduls PAC-LDAP.
Dieser Teil enthält die folgenden Kapitel:
Informationen zur Sicherheit von Proxy-Servern
Zugriffsschutzkonfigurationen für den Server
Unterstützung für Verschlüsselungshardware aktivieren
Das Plug-in Tivoli Access Manager verwenden
PAC-LDAP-Autorisierungsmodul verwenden
Jeder über das Internet zugängliche Server ist dem Risiko ausgesetzt, dass dem System, auf dem er ausgeführt wird, unerwünschtes Interesse geschenkt wird. Nicht autorisierte Personen könnten versuchen, Kennwörter zu erraten, Dateien zu aktualisieren oder auszuführen oder vertrauliche Daten zu lesen. Teil der Anziehungskraft des World Wide Web ist seine Zugänglichkeit für jedermann. Diese Zugänglichkeit ist jedoch nicht nur von Vorteil, sondern fördert auch den Missbrauch.
In den folgenden Abschnitten wird beschrieben, wie Sie den Zugriff auf Dateien kontrollieren können, die sich auf dem Caching-Proxy-Server befinden.
Caching Proxy unterstützt SSL-Verbindungen (Secure Sockets Layer), in denen Daten zwischen dem Client-Browser und dem Zielserver (ein Inhaltsserver oder ein Ersatz-Proxy-Server) durch Ver- und Entschlüsselung sicher übertragen werden.
Ist Caching Proxy als Ersatzserver definiert, kann er sichere Verbindungen zu Clients und/oder zu Inhaltsservern aufbauen. Wenn Sie SSL-Verbindungen mit den Konfigurations- und Verwaltungsformularen aktivieren möchten, wählen Sie Proxy-Konfiguration -> SSL-Einstellungen aus. Wählen Sie in diesem Formular das Markierungsfeld SSL aktivieren aus und geben Sie eine Schlüsselringdatenbank und eine Kennwortdatei für die Schlüsselringdatenbank an.
Ist Caching Proxy als Forward Proxy konfiguriert, verwendet er ein Durchgriffsprotokoll, das als SSL-Tunnelung (SSL Tunneling) bezeichnet wird, um verschlüsselte Anforderungen zwischen Client und Inhaltsserver zu übertragen. Die verschlüsselten Daten werden nicht im Cache gespeichert, weil der Proxy-Server im Tunnelungsverfahren übertragene Anforderungen nicht entschlüsselt. In einer Forward-Proxy-Installation ist die SSL-Tunneling aktiviert. Um sie zu inaktivieren, wählen Sie in den Konfigurations- und Verwaltungsformularen Konfiguration des Proxy -> Einstellungen für Proxy aus, und löschen Sie die Markierung des Felds SSL-Tunnelung.
Sie können mehrere grundlegende Vorsichtsmaßnahmen zum Schutz Ihres Systems treffen:
Mit Paketfiltern können Sie die Quelle und den Zielort von Daten definieren. Sie können Ihr System so konfigurieren, dass bestimmte Kombinationen von Quelle und Ziel zurückgewiesen werden.
Eine Firewall trennt das interne Netz von einem öffentlich zugänglichen Netz, wie z. B. dem Internet. Die Firewall kann eine Gruppe von Computern oder ein einzelner Computer sein, der als Gateway in beide Richtungen agiert und den Datenverkehr reguliert und verfolgt. Als Firewall-Software können Sie z. B. IBM Firewall einsetzen.
Beispiele:
Proxy /* http://content server :443
oder
Proxy /* https://content server :443
Dieses Kapitel beschreibt, wie Sie die Daten und Dateien auf Ihrem Server mit Zugriffsschutzkonfigurationen schützen können. Zugriffsschutzkonfigurationen werden auf der Grundlage der Anforderung ausgelöst, die der Server empfängt. Dabei spielen insbesondere das angeforderte Verzeichnis, die Datei oder der Dateityp, die in der Anforderung angegeben sind, eine Rolle. In einer Zugriffsschutzkonfiguration steuern untergeordnete Anweisungen die Erteilung bzw. Verweigerung von Zugriffsrechten auf der Grundlage der Merkmale der geschützten Verzeichnisse oder Dateien.
Um eine Zugriffsschutzkonfiguration zu definieren und ihre Anwendung festzulegen, wählen Sie in den Konfigurations- und Verwaltungsformularen Serverkonfiguration -> Zugriffsschutz für Dokumente aus. Legen Sie in diesem Formular Folgendes fest:
Regeln für den Zugriffsschutz werden in der Reihenfolge angewendet, in der sie in der Tabelle im Konfigurationsformular aufgeführt sind. Im Allgemeinen sind in der Tabelle zuerst die speziellen und dann die generischen Regeln aufgelistet.
Legen Sie mit dem Dropdown-Menü und den Schaltflächen im Formular die Position einer Zugriffsschutzregel fest.
Der Zugriffsschutz wird auf der Grundlage der Anforderungsschablonen aktiviert, die mit dem Inhalt der Anforderungen verglichen werden, die die Clients an Ihren Proxy-Server senden.
Eine Anforderung ist der Teil eines vollständigen URL, der dem Hostnamen des Servers folgt. Wenn Ihr Server beispielsweise den Namen fine.feathers.com hat und ein Browser den URL http://fine.feathers.com/waterfowl/schedule.html sendet, empfängt der Server die Anforderung /waterfowl/schedule.html. Anforderungsschablonen spezifizieren Verzeichnis- und/oder Dateinamen, die dem Zugriffsschutz unterliegen. Beispiele für Anforderungen, die den Zugriffsschutz auf der Basis der gerade beschriebenen Schablone (/waterfowl/schedule.html) aktivieren, sind /waterfowl/* und /*schedule.html.
Geben Sie im Feld URL-Anforderungsschablone die Anforderungsschablone ein.
Eine Zugriffsschutzkonfiguration weist Caching Proxy an, wie vorzugehen ist, wenn eine Anforderung mit einer Anforderungsschablone übereinstimmt. Sie können eine benannte Zugriffsschutzkonfiguration verwenden oder im Formular Zugriffsschutz für Dokumente eine neue Konfiguration definieren.
Wenn Sie eine benannte Konfiguration verwenden möchten, klicken Sie auf den Radioknopf Benannter Zugriffsschutz und geben Sie den Namen im dafür vorgesehenen Feld ein. Wenn Sie eine neue Zugriffsschutzkonfiguration definieren möchten, klicken Sie auf den Radioknopf Inline und befolgen Sie die angezeigten Anweisungen (siehe Schritt 6).
Auf Anforderungen von unterschiedlichen Serveradressen können unterschiedliche Regeln angewendet werden. Beispielsweise könnten Sie für Anforderungen von Protokolldateien eine andere Zugriffsschutzkonfiguration anwenden, wenn diese Anforderungen von IP-Adressen Ihres Unternehmens stammen.
Wenn die Requester-Adresse in der Regel enthalten sein soll, geben Sie sie im Feld IP-Adresse oder Hostname des Servers ein.
Wenn Sie eine benannte Zugriffsschutzkonfiguration verwenden, sind keine weiteren Eingaben erforderlich. Haben Sie eine Inline-Zugriffsschutzkonfiguration ausgewählt oder eine benannte Konfiguration angegeben, die nicht existiert, werden vom System weitere Formulare angezeigt.
Wenn Sie keine vorhandene Zugriffsschutzkonfiguration angegeben haben, wird ein weiteres Formular geöffnet, in dem Sie festlegen können, welche Benutzer auf die Dokumente oder Verzeichnisse zugreifen dürfen, die mit der Anforderungsschablone übereinstimmen, und für welche Aktionen die Benutzer berechtigt sind.
Wenn Sie den Zugriffsschutz durch Editieren der Konfigurationsdatei von Caching Proxy definieren möchten, muss Ihnen Folgendes bekannt sein:
Mit Anweisungen für Anforderungs-Routing wie Map, Exec, Pass und Proxy steuern Sie, welche Anforderungen Ihr Server akzeptiert und wie er Anforderungen an die Dateiadressen weiterleitet. Die Anweisungen für Anforderungs-Routing verwenden dieselben Anforderungsschablonen wie Zugriffsschutzanweisungen. Da die Anweisungen ausgeführt werden, die mit der ersten übereinstimmenden Schablone für jede Anforderung verknüpft sind, müssen die Zugriffsschutzanweisungen vor den Routing-Anweisungen in der Konfigurationsdatei stehen, damit der Zugriffsschutz ordnungsgemäß funktioniert. Nähere Informationen hierzu finden Sie im Abschnitt Protect - Eine Zugriffsschutzkonfiguration für Anforderungen aktivieren, die mit einer Schablone übereinstimmen.
Mit der Protect-Anweisung können Sie eine Inline-Zugriffsschutzkonfiguration angeben oder auf eine vorhandene benannte Konfiguration verweisen. Die Syntax der beiden Angaben unterscheidet sich nur minimal. Nähere Informationen finden Sie im Abschnitt Protect - Eine Zugriffsschutzkonfiguration für Anforderungen aktivieren, die mit einer Schablone übereinstimmen.
Eine Zugriffsschutzkonfiguration besteht aus einer Folge von Angaben, die die untergeordneten Anweisungen für Zugriffsschutz enthalten. Syntax und Referenzinformationen zum Schreiben von Zugriffsschutzkonfigurationen finden Sie in Anhang B. Anweisungen in der Konfigurationsdatei in den folgenden Abschnitten:
Die Standardkonfigurationsdatei des Proxy-Servers enthält eine Zugriffsschutzkonfiguration, die für den Zugriff auf die Dateien im Verzeichnis /admin-bin/ die Angabe einer Administrator-ID und eines Kennworts erfordert. Diese Einstellung schränkt den Zugriff auf die Konfigurations- und Verwaltungsformulare ein.
SSL (Secure Sockets Layer) ist ein System, mit dem Informationen, die über das Internet gesendet werden, automatisch verschlüsselt und beim Empfänger vor ihrer Verwendung wieder entschlüsselt werden. Auf diese Weise werden sensible Informationen wie Kreditkartennummern während der Übertragung über das Internet geschützt.
Caching Proxy verwendet SSL für den Schutz von Ersatzservern und für eine sichere Fernverwaltung. Nähere Informationen hierzu finden Sie in den folgenden Abschnitten. Mit SSL können auch Verbindungen zu Back-End-Servern (z. B. Inhalts- oder Anwendungsservern) und Datenübertragungen zwischen dem Proxy-Server und seinen Clients geschützt werden.
Für Forward-Proxy-Server unterstützt Caching Proxy die SSL-Tunnelung, bei der SSL umgangen wird und die bereits verschlüsselten Daten unverändert gesendet werden.
Der SSL-Zugriffsschutz wird aktiviert, wenn eine Anforderung für eine sichere Verbindung von einer Maschine an eine andere gesendet wird, z. B. wenn ein Browser eine Anforderung an einen Ersatz-Proxy-Server sendet. Die Anforderungssyntax https:// anstelle von http:// teilt dem Browser mit, dass die Anforderung an Port 443 gesendet werden soll. Dies ist der Port, an dem der Server geschützte Verbindungsanforderungen empfängt (im Unterschied zu Port 80, an dem Routineanforderungen empfangen werden). Zum Aufbau einer sicheren Sitzung zwischen Browser und Server führen die beiden Maschinen einen Informationsaustausch aus, den so genannten SSL-Handshake. Mit diesem Austausch legen die beiden Parteien eine Verschlüsselungsspezifikation fest und wählen den Schlüssel aus, mit dem die Informationen ver- und entschlüsselt werden sollen. Die Schlüssel werden automatisch generiert und verfallen mit Beendigung der Sitzung. Im Folgenden wird ein typisches Szenario (mit SSL Version 3) beschrieben:
Der Client leitet eine SSL-Sitzung mit Caching Proxy ein, indem er eine Hello-Nachricht sendet, die die Verschlüsselungsfunktionen des Clients beschreibt.
Der Server sendet sein Zertifikat an den Client und wählt die Cipher Suite aus, die zur Datenverschlüsselung verwendet werden soll.
Der Client sendet die Informationen zum Chiffrierschlüssel, mit dem die symmetrischen Chiffrierschlüssel für die verschlüsselten Daten erstellt werden. Diese Schlüsselinformationen werden als Premaster Secret bezeichnet und sind mit dem öffentlichen Schlüssel des Servers (aus dem Serverzertifikat, siehe Schlüssel- und Zertifikatverwaltung) verschlüsselt. Server und Client können die symmetrischen Chiffrierschlüssel zum Lesen und Schreiben aus dem Premaster Secret abrufen.
Der Server sendet die Abschlussbestätigung und einen Nachrichtenauthentifizierungscode (Message Authentication Code, MAC) für das gesamte Handshake-Protokoll.
Der Client sendet eine Nachricht, um die Abschlussnachricht des Servers zu überprüfen.
Nachdem der Client die Server-Finish-Nachricht überprüft hat, kann der verschlüsselte Datenfluss beginnen.
Mit einem Caching-Proxy-Server als Endpunkt für sichere Verbindungen können Sie die Arbeitslast auf Ihren Inhaltsservern und Anwendungsservern verringern. Wenn ein Caching-Proxy-Server eine sichere Verbindung verwaltet, ist er für die Verschlüsselung, Entschlüsselung und die Generierung der Schlüssel zuständig. Bei allen Vorgängen handelt es sich um CPU-intensive Operationen. Außerdem können Sie in Caching Proxy SSL-Sitzungszeitlimits konfigurieren, um eine möglichst lange Verwendung jedes Schlüssels zu gewährleisten.
Einschränkungen von SSL
In WebSphere Application Server Caching Proxy gelten folgende SSL-Einschränkungen:
Bei hohem HTTPS-Datenverkehrsaufkommen kann der Caching-Proxy-Server eine hohe CPU-Belastung verursachen. Optimierungsänderungen an einer Umgebungsvariablen (GSK_V3_SIDCACHE_SIZE) und einer Proxy-Anweisung (SSLV3Timeout) können dem Proxy-Server helfen, die Last zu bewältigen und die CPU-Belastung zu reduzieren.
Die SSL-Sitzungs-ID identifiziert wiederverwendbare SSL-Sitzungen, einschließlich Ver- und Entschlüsselungsschlüsseln, die von Browsern und Servern verwendet werden, und wird verwendet, um unnötige SSL-Handshakes in neuen Verbindungen zu vermeiden, die viel CPU-Zeit des Servers verbrauchen. Die GSKit-Bibliothek für den Caching-Proxy-Server unterstützt SSL-Sitzungs-IDs und enthält einen Cache für SSL-Sitzungs-IDs. Standardmäßig enthält der Cache für SSL-Sitzungs-IDs 512 Einträge. Wenn das Eintragslimit erreicht ist, wird der älteste Sitzungseintrag entfernt und der neue Eintrag dem Cache hinzugefügt.
Verwenden Sie die Umgebungsvariable GSK_V3_SIDCACHE_SIZE, um die Standardgröße des Cache für SSL-Sitzungs-IDs zu ändern. Die gültigen Werte für diese Variable liegen zwischen 1 und 4096. Wenn Sie die Größe heraufsetzen, erhöht sich damit auch die Zeit, die zum Suchen einer zwischengespeicherten SSL-Sitzung erforderlich ist. Die erhöhte Suchzeit ist jedoch im Vergleich mit dem Aufwand für das Einrichten einer SSL-Verbindung unerheblich. Mit einem größeren Cache ist der Proxy-Server bei hohem HTTPS-Datenverkehrsaufkommen in der Lage, mehr SSL-Sitzungen gleichzeitig zu verarbeiten und die CPU-Belastung zu senken.
Caching Proxy besitzt außerdem eine optimierbare Anweisung SSLV3Timeout. (Siehe SSLV3Timeout - Die Wartezeit vor dem Ablaufen einer SSLV3-Sitzung angeben.) Der Standardwert der Anweisung sind 1000 Sekunden. Diese Anweisung definiert die Lebensdauer einer SSL-Sitzung im Sitzungs-Cache. Wenn keine eingehende SSL-Verbindung eine vorhandene SSL-Sitzung verwendet und die Sitzungslebensdauer diesen Wert überschreitet, wird diese Sitzung aus dem Sitzungs-Cache entfernt. Es wird empfohlen, für den Wert von SSLV3Timeout die Dauer einer typischen sicheren Clientsitzung zu verwenden. Wenn ein zu kurzes Zeitlimit gewählt wird, kann dies die Leistung des Proxy-Servers beeinträchtigen, weil mehrere SSL-Handshake-Sitzungen erforderlich sind, um eine einzelne sichere Sitzung einzurichten. Wird jedoch ein zu hoher Wert gewählt, kann sich dies auch negativ auf die Sicherheit einer sicheren Sitzung auswirken.
Dies gilt nur für Forward-Proxy-Konfigurationen.
Ist Caching Proxy als Forward Proxy konfiguriert, verwendet er die SSL-Tunnelung, um sichere Verbindungen zwischen Clients und Inhaltsservern zu unterstützen. Bei der SSL-Tunnelung werden verschlüsselte Daten unverändert über den Proxy-Server übergeben. Da der Proxy-Server die Daten nicht entschlüsselt, werden Funktionen, bei denen der Proxy-Server Anforderungen oder Dokument-Header lesen muss, von der SSL-Tunnelung nicht unterstützt. Außerdem werden im Tunnelungsverfahren übertragene Anforderungen nicht im Cache gespeichert.
Abb. 2 zeigt einen Verbindungsaufbau unter Verwendung der SSL-Tunnelung.
Die SSL-Tunnelung wird wie folgt ausgeführt:
In der Konfiguration als Forward Proxy ist nur die SSL-Tunnelung verfügbar. Um die SSL-Tunnelung zu aktivieren, wählen Sie in den Konfigurations- und Verwaltungsformularen Konfiguration des Proxy -> Einstellungen für Proxy aus. Wählen Sie das Markierungsfeld SSL-Tunnelung aus.
Für Verbindungen, die das SSL-Tunnelungsverfahren verwenden, muss die Methode CONNECT (die standardmäßig inaktiviert ist) ebenfalls aktiviert sein. Wählen Sie dazu in den Konfigurationsformularen Serverkonfiguration -> Anforderungsverarbeitung aus und rufen Sie das Formular HTTP-Methoden auf.
Für die Anweisung Enable CONNECT werden für die erweiterte Sicherheit bei der SSL-Tunnelung drei Optionen bereitgestellt: OutgoingPorts, OutgoingIPs und IncomingIPs. Sie müssen zumindest für OutgoingPorts einen Wert angeben, andernfalls wird die Methode CONNECT nicht aktiviert.
Enable CONNECT OutgoingPorts [all | [port1|port1-port2|port1-*],...]Setzen Sie die folgenden Anweisungen, wenn Clients für die SSL-Tunnelung nur Verbindungen zum fernen Server-Port 443 herstellen dürfen: (Normalerweise ist Port 443 für HTTPS-Anforderungen auf dem fernen Server reserviert.)
Enable CONNECT OutgoingPorts 443 SSLTunneling onSetzen Sie die folgenden Anweisungen, wenn Clients für die SSL-Tunnelung Verbindungen zu jedem fernen Server-Port 443 herstellen dürfen:
Enable CONNECT OutgoingPorts all SSLTunneling onSetzen Sie die folgenden Anweisungen, wenn Clients für die SSL-Tunnelung Verbindungen zu den fernen Server-Port 80, 8080-8088 und 9000 (und höheren Ports) herstellen dürfen:
Enable CONNECT OutgoingPorts 80,8080-8088,9000-* SSLTunneling on
Ports und Port-Bereiche werden in der Liste durch Kommata (ohne Leerzeichen) getrennt.
Wichtiger Hinweis: Geben Sie für Forward-Proxy-Konfigurationen mindestens 443 oder all für die Option OutgoingPorts an, um eine normale SSL-Tunnelung zuzulassen.
Enable CONNECT OutgoingIPs [[!]IP-Muster,...]Setzen Sie die folgenden Anweisungen, um Clients die Verbindungsherstellung zu jedem Port auf den fernen Servern zu erlauben, die der IP-Adresse bzw. dem Hostnamen *.ibm.com und nicht der Angabe 192.168.*.* entsprechen:
Enable CONNECT OutgoingPorts all OutgoingIPs *.ibm.com,!192.168.*.* SSLTunneling on
Enable CONNECT IncomingIPs [[!]IP-Muster,...]Setzen Sie die folgenden Anweisungen, wenn Sie beispielsweise Clients mit der IP-Adresse 192.168.*.* für die SSL-Tunnelung die Verbindungsherstellung zu jedem Port auf den fernen Servern erlauben möchten, auf den fernen erlauben möchten:
Enable CONNECT OutgoingPorts all IncomingIPs 192.168.*.* SSLTunneling on
Weitere Informationen zum Aktivieren der SSL-Tunnelung und der CONNECT-Anweisungen durch Editieren der Konfigurationsdatei des Proxy-Servers finden Sie in den Referenzabschnitten zu den folgenden Anweisungen in Anhang B. Anweisungen in der Konfigurationsdatei:
Die Fernverwaltung von Caching Proxy kann mit den SSL-Sicherheitsfunktionen (Secure Sockets Layer) und der Kennwortauthentifizierung durchgeführt werden. Dadurch verringert sich das Risiko, dass nicht autorisierte Personen auf den Proxy-Server zugreifen.
Wenn Sie für die Fernverwaltung Ihres Servers SSL einsetzen möchten, verwenden Sie zum Öffnen der Konfigurations- und Verwaltungsformulare eine https://-Anforderung anstelle einer http://-Anforderung. Beispiel:
https://Name.Ihres.Servers/IhreFrontPage.html
Wie bereits erwähnt, müssen Sie vor der Konfiguration von SSL eine Schlüsseldatenbank einrichten und ein Zertifikat erstellen oder abrufen. Zertifikate dienen der Authentifizierung von Servern. Verwenden Sie zum Definieren Ihrer Zertifizierungsdateien das Dienstprogramm IBM Key Management (auch iKeyman genannt). Dieses Dienstprogramm ist Teil der GSKit-Software, die im Produktumfang von Application Server enthalten ist. Außerdem enthält GSKit eine Java-basierte Grafikschnittstelle zum Öffnen von Zertifikatdateien.
Nachfolgend sind die grundlegenden Schritte zum Definieren der SSL-Schlüssel und Zertifikate beschrieben.
Wenn das Zertifikat abgelaufen ist, wird Caching Proxy auf allen Betriebssystemen mit Ausnahme von Linux nicht ordnungsgemäß gestartet, und es erscheint eine Fehlernachricht, die Sie darauf hinweist, dass die Schlüsseldatenbank verfallen ist. Unter Linux scheint der Proxy-Server zu starten, aber der Prozess wird sofort wieder beendet, und es wird keine Fehlernachricht generiert.
Sie können dieses Problem auf Systemen mit Red Hat Enterprise Linux 3.0 verhindern, indem Sie sicherstellen, dass die GCC-Paket die folgenden Versionen (oder höher) haben:
Ihrem öffentlichen Schlüssel muss ein digital signiertes Zertifikat einer Zertifizierungsstelle (CA) zugeordnet sein, die als vertrauenswürdige Stamm-CA auf Ihrem Server festgelegt ist. Sie können ein signiertes Zertifikat erwerben, indem Sie eine Zertifikatanforderung an den Provider der Zertifizierungsstelle (CA) senden. Caching Proxy unterstützt die folgenden externen Zertifizierungsstellen:
Standardmäßig sind die folgenden Zertifizierungsstellen als Trusted-CAs definiert:
Dieser Abschnitt enthält eine Kurzübersicht über die Verwendung des Dienstprogramms IBM Key Management (iKeyman). Mit diesem Dienstprogramm erstellen Sie Ihre SSL-Schlüsseldatenbankdatei, öffentlich-private Schlüsselpaare und Zertifikatanforderungen. Nachdem Sie das von der Zertifizierungsstelle signierte Zertifikat empfangen haben, legen Sie es mit IBM Key Management in der Schlüsseldatenbank ab, in der Sie die ursprüngliche Zertifikatanforderung erstellt haben.
Weitere ausführliche Informationen finden Sie in der Dokumentation zu IBM Key Management und GSKit, die der GSKit-Software beiliegt.
Das System für die Ausführung von IBM Key Management konfigurieren
Gehen Sie vor dem Start der GUI von IKeyman wie folgt vor:
ibmjcefw.jar ibmpkcs11.jar
ibmjceprovider.jar ibmpkcs.jar
local_policy.jar US_export_policy.jar
Aktualisieren Sie die Datei JAVA_HOME/jre/lib/security/java.security, indem Sie hinter dem Sun-Provider die Provider IBM CMS und IBM JCE hinzufügen. Beispiel:
security.provider.1=sun.security.provider.Sun security.provider.2=com.ibm.spi.IBMCMSProvider security.provider.3=com.ibm.crypto.provider.IBMJCE
Eine Beispieldatei java.security ist im folgenden Verzeichnis enthalten: GSKit-Installationspfad/classes/gsk_java.security
security.provider.1=sun.security.provider.Sun security.provider.2=com.ibm.spi.IBMCMSProvider security.provider.3=com.ibm.crypto.fips.provider.IBMJCEFIPS security.provider.4=com.ibm.crypto.provider.IBMJCE
security.provider.1=sun.security.provider.Sun security.provider.2=com.ibm.crypto.provider.IBMJCE security.provider.3=com.ibm.crypto.pkcs11.provider.IBMPKCS11
IBM Key Management starten
Starten Sie wie folgt die grafische Benutzerschnittstelle von IBM Key Management:
Wenn Sie während dieser Sitzung eine neue Schlüsseldatenbankdatei erstellen, wird diese Datei in dem Verzeichnis gespeichert, in dem Sie IBM Key Management gestartet haben.
Bei einer Schlüsseldatenbank handelt es sich um eine Datei, in der der Server ein oder mehrere Schlüsselpaare und Zertifikate speichert. Für sämtliche Schlüsselpaare und Zertifikate können Sie entweder eine Schlüsseldatenbank verwenden oder mehrere Datenbanken erstellen. Mit dem Dienstprogramm IBM Key Management können Sie neue Schlüsseldatenbanken erstellen und die zugehörigen Kennwörter und Dateien zur Kennwortspeicherung festlegen.
So erstellen Sie eine Schlüsseldatenbank und eine Datei zur Kennwortspeicherung:
Das Kennwort, das Sie beim Erstellen einer neuen Schlüsseldatenbank angeben, schützt den privaten Schlüssel. Der private Schlüssel ist der einzige Schlüssel, der Dokumente signieren oder Nachrichten entschlüsseln kann, die mit dem öffentlichen Schlüssel verschlüsselt wurden.
Beachten Sie bei der Festlegung des Kennworts folgende Richtlinien:
Es wird empfohlen, das Kennwort der Schlüsseldatenbank regelmäßig zu ändern. Wenn Sie ein Verfallsdatum für das Kennwort festlegen, sollten Sie sich auf jeden Fall notieren, wann Sie das Kennwort ändern müssen. Sollten Sie das Verfallsdatum des Kennworts verpassen, wird eine Nachricht in das Fehlerprotokoll geschrieben. Der Server wird dann zwar gestartet, kann aber keine sicheren Netzverbindungen herstellen.
So ändern Sie das Kennwort für die Schlüsseldatenbank:
Wenn Sie zwischen einem Proxy-Server und einem LDAP-Server eine SSL-Verbindung herstellen möchten, müssen Sie das Kennwort für die Schlüsseldatenbank in der Datei pac_keyring.pwd speichern. (Die Datei pac_keyring.pwd ist nicht die verdeckte Datei, die von iKeyman generiert wird.)
Ein neues Schlüsselpaar und eine neue Zertifikatanforderung erstellen
In der Schlüsseldatenbank sind Schlüsselpaare und Zertifikatanforderungen gespeichert. So erstellen Sie ein öffentlich-privates Schlüsselpaar und eine Zertifikatanforderung:
Eine neue Zertifikatanfrage wurde erfolgreich in der Datei Name_der_Schlüsseldatenbankname erstellt.
Selbst signiertes Zertifikat erstellen
Erstellen Sie mit IBM Key Management ein selbst signiertes Serverzertifikat, um damit SSL-Sitzungen zwischen Clients und dem Proxy-Server zu aktivieren, während Sie auf die Ausstellung des angeforderten Zertifikats warten. Außerdem können Sie selbst signierte Zertifikate zu Testzwecken verwenden.
Gehen Sie wie folgt vor, um ein selbst signiertes Zertifikat zu erstellen:
Schlüssel exportieren
So exportieren Sie Schlüssel in eine andere Schlüsseldatenbank:
Schlüssel importieren
So importieren Sie Schlüssel aus einer anderen Schlüsseldatenbank:
Zertifizierungsstellen auflisten
So können Sie eine Liste mit vertrauenswürdigen Zertifizierungsstellen (Trusted-CAs) in einer Schlüsseldatenbank anzeigen:
Gehen Sie wie folgt vor, um ein Zertifikat zu empfangen, das Sie per E-Mail von einer Zertifizierungsstelle erhalten haben, die standardmäßig als Trusted-CA definiert ist (siehe die Liste im Abschnitt Zertifizierungsstellen). Wenn es sich bei der Zertifizierungsstelle (CA), die Ihr Zertifikat ausstellt, nicht um eine in der Schlüsseldatenbank gespeicherte vertrauenswürdige Zertifizierungsstelle handelt, müssen Sie zunächst das Zertifikat dieser Instanz speichern und die CA als vertrauenswürdige CA festlegen. Anschließend können Sie Ihr von der CA signiertes Zertifikat in die Datenbank laden. Sie können kein signiertes Zertifikat von einer Zertifizierungsstelle empfangen, die nicht als vertrauenswürdig eingestuft wurde (siehe Abschnitt Ein CA-Zertifikat speichern).
So laden Sie das von der Zertifizierungsstelle signierte Zertifikat in eine Schlüsseldatenbank:
Zum Aufbau sicherer Verbindungen werden nur Zertifikate akzeptiert, die von einer vertrauenswürdigen Zertifizierungsstelle signiert wurden. Wenn Sie der Liste der vertrauenswürdigen Stellen eine Zertifizierungsstelle hinzufügen möchten, müssen Sie ihr Zertifikat abrufen und als vertrauenswürdig abspeichern. Gehen Sie wie folgt vor, um ein Zertifikat von einer neuen Zertifizierungsstelle zu speichern:
Standardschlüssel in einer Schlüsseldatenbank anzeigen
Gehen Sie wie folgt vor, um den Eintrag für den Standardschlüssel anzuzeigen:
In der folgenden Tabelle sind die Verschlüsselungsalgorithmen und Hash-Verfahren aufgeführt, die für die SSL-Versionen 2 und 3 verwendet werden.
Generierung von Schlüsselpaaren: RSA 512-1024 (Größe von privaten Schlüsseln)
SSL Version 2
US-Version | Exportversion |
RC4 US | RC4 Export |
RC2 US | RC2 Export |
DES 56-Bit | nicht zutreffend |
Triple DES US | nicht zutreffend |
RC4 Export | nicht zutreffend |
RC2 Export | nicht zutreffend |
SSL Version 3
US-Version | Exportversion |
Triple DES SHA US | DES SHA Export |
DES SHA Export | RC2 MD5 Export |
RC2 MD5 Export | RC4 MD5 Export |
RC4 SHA US | NULL SHA |
RC4 MD5 US | NULL MD5 |
RC4 MD5 Export | NULL NULL |
RC4 SHA 56-Bit | nicht zutreffend |
DES CBC SHA | nicht zutreffend |
NULL SHA | nicht zutreffend |
NULL MD5 | nicht zutreffend |
NULL NULL | nicht zutreffend |
Diese SSL-Spezifikationen können auch direkt durch Editieren der Konfigurationsdatei des Proxy-Servers konfiguriert werden. Einzelheiten hierzu finden Sie in Anhang B. Anweisungen in der Konfigurationsdatei in den Referenzabschnitten zu den folgenden Anweisungen:
128-Bit-Verschlüsselung für Caching Proxy
Es wird nur eine 128-Bit-Verschlüsselungsversion von Caching Proxy bereitgestellt. Die 56-Bit-Version ist nicht mehr verfügbar. Wenn Sie eine ältere Version aktualisieren, können Sie Caching Proxy direkt in Ihrer derzeit installierten 128-Bit- oder 56-Bit-Version installieren. Falls Sie vorher einen 56-Bit-Browser (Export) verwendet haben, müssen Sie einen Upgrade auf einen 128-Bit-Browser durchführen, damit Sie die 128-Bit-Verschlüsselung im Proxy-Server nutzen können.
Falls nach dem Upgrade von einer 56-Bit-Version von Caching Proxy auf die 128-Bit-Version die für die Verschlüsselung von Zertifikaten verwendete Schlüsselgröße auf 1024 gesetzt ist, müssen keine Änderungen an der Konfiguration vorgenommen werden. Ist die Schlüsselgröße auf 512 gesetzt, müssen Sie neue Zertifikate mit einer Schlüsselgröße von 1024 erstellen, damit Sie die 128-Bit-Verschlüsselung des Proxy-Servers nutzen können. Erstellen Sie neue Schlüssel mit dem Dienstprogramm IBM Key Management (iKeyman).
Eine detaillierte Beschreibung des Dienstprogramms IBM Key Management finden Sie im Abschnitt Schlüssel- und Zertifikatverwaltung.
Beachten Sie, dass diese Produktversion unter SUSE Linux keine Verschlüsselung unterstützt.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Gehen Sie wie folgt vor, wenn die SSL-Handshake-Routine auf eine Hardwareverschlüsselungskarte ausgelagert werden soll:
Informationen zur Unterstützung der IBM 4960 PCI Cryptographic Accelerator Card finden Sie im Abschnitt PKCS11DefaultCert, PKCS11DriverPath, PKCS11TokenPassword - Unterstützung für IBM 4960 PCI Cryptographic Accelerator Card (nur AIX).
Mit Tivoli Access Manager (früher Tivoli Policy Director) wird ein Plug-in für Caching Proxy bereitgestellt. Über dieses Plug-in kann Caching Proxy Access Manager zur Authentifizierung und Autorisierung verwenden. Dieses Plug-in bietet Unternehmen, die Access Manager für die Webzugriffssteuerung verwenden, die Möglichkeit, mit der Edge-Technologie zu arbeiten, ohne für den Proxy-Server separate Autorisierungsschemata einrichten zu müssen.
Nähere Informationen zu Tivoli Access Manager finden Sie auf der Produkt-Website http://www.ibm.com/software/tivoli/products/. Nähere Informationen zu den Software- und Hardwarevoraussetzungen und zur Installation des Plug-in finden Sie in der Dokumentation, die mit Tivoli Access Manager geliefert wird.
Zusammen mit dem Plug-in Access Manager wird ein Konfigurations-Script für Caching Proxy bereitgestellt.
Gehen Sie vor dem Ausführen des Script wie folgt vor:
Das Konfigurations-Script hat den Namen wslconfig.sh und ist im Verzeichnis /opt/pdweb-lite/bin/ enthalten. Geben Sie bei entsprechender Aufforderung die Administrator-ID für Access Manager und die Administrator-ID für LDAP ein.
Das Konfigurations-Script führt die folgenden Schritte automatisch aus:
ServerInit /opt/pdweb-lite/lib/wesauth.so:WTESeal_Init /opt/pdweb-lite/etc/ibmwesas.conf
PreExit /opt/pdweb-lite/lib/wesauth.so:WTESeal_PreExit
Authorization * /opt/pdweb-lite/lib/wesauth.so:WTESeal_Authorize
ServerTerm /opt/pdweb-lite/lib/wesauth.so:WTESeal_Term
Eine Protect-Anweisung und eine Zugriffsschutzkonfiguration (Protection) werden erstellt, die alle Anforderungen an den Authentifizierungsprozess von Access Manager wie folgt weiterleiten:
Protection PROXY-PROT { ServerId WebSEAL-Lite Mask All@(*) AuthType Basic } Protect * PROXY-PROT
Nachdem der Proxy-Server und das Plug-in Access Manager konfiguriert wurden, führen Sie zum Starten des Proxy-Servers den Befehl wslstartwte anstelle des Befehls ibmproxy start aus. Mit dem Befehl wslstartwte werden automatisch Umgebungsvariablen geladen, die das Plug-in Access Manager zur Initialisierung benötigt. Wenn Sie den Befehl wslstartwte nicht zum Starten des Proxy-Servers verwenden, erscheinen Fehlernachrichten zum Plug-in Access Manager. Der entsprechende Befehl zum Stoppen, ibmproxy stop, ist auch bei Verwendung des Plug-in gültig.
Das PAC-LDAP-Autorisierungsmodul erlaubt Caching Proxy bei Ausführung von Autorisierungs- und Authentifizierungsroutinen den Zugriff auf einen LDAP-Server (Lightweight Directory Access Protocol). Das Modul besteht aus zwei Komponentengruppen: einem Paar gemeinsam genutzter Bibliotheken, durch die die LDAP-Funktionalität zur API von Caching Proxy hinzugefügt wird, und einem PAC-Dämon (Policy Authentication Control). Eine Anweisung ServerInit in der Datei ibmproxy.conf weist die gemeinsam genutzte Bibliothek an, einen oder mehrere PAC-Dämonprozesse zu starten, wenn Caching Proxy gestartet wird. Die gemeinsam genutzten Bibliotheken lesen die Datei paccp.conf, um die Anzahl und Merkmale der PAC-Dämonprozesse zu bestimmen. Während der Initialisierung liest der Dämon die Konfigurationsanweisungen in der Datei pac.conf und die Policy-Informationen in der Datei pacpolicy.conf. Anschließend weist entweder eine Authentication-Anweisung in der Datei ibmproxy.conf den Proxy-Server an, die gemeinsam genutzte Bibliothek jedesmal aufzurufen, wenn eine Authentifizierung erforderlich ist, oder eine Authorization-Anweisung kontrolliert während der Verarbeitung von Standard-HTTP-Anforderungen den Arbeitsablauf in Caching Proxy.
Bei der Authentifizierung wird ermittelt, ob die übergebenen Berechtigungsnachweise (Benutzername und Kennwort) gültig sind. Es wird geprüft, ob ein Benutzer in der Registrierungsdatenbank enthalten ist und ob das angegebene Kennwort mit dem in der Registrierungsdatenbank gespeicherten Kennwort übereinstimmt. Diese Aktionen werden ausgeführt, wenn das Modul PAC-LDAP während der Authentifizierung verwendet wird.
Wird das PAC-LDAP-Autorisierungsmodul für die Authentifizierung aktiviert, wird es zum Standard-Repository, aus dem die Benutzer-IDs, Kennwörter und Gruppen abgerufen werden. Wenn eine HTTP-Anforderung den Caching-Proxy-Arbeitsablauf durchläuft, vergleicht jede Protect-Anweisung den angeforderten URL mit ihrer Anforderungsschablone. Bei Übereinstimmung ruft die Protect-Anweisung ein Zugriffsschutzschema auf, das die Server-ID, die Art der zu verwendenden Authentifizierung, die Maskierungsregeln, die auf den Anforderungsclient angewendet werden sollen, sowie die Positionen der Kennwörter und Gruppendateien umfasst. Ist keine Kennwortdatei definiert, werden Benutzer-ID und Kennwort über das PAC-LDAP-Autorisierungsmodul abgerufen. Die Policys des Typs 0, 1, 2 und 3 definieren Authentifizierungsschemata. Bei erfolgreicher Authentifizierung wird die Anforderung bearbeitet. Andernfalls gibt Caching Proxy den Fehler 401 an den Client zurück.
Bei der Autorisierung wird ermittelt, ob ein Benutzer die erforderliche Berechtigung für den Zugriff auf eine geschützte Ressource besitzt. Wenn das Modul PAC-LDAP verwendet wird, werden während dieses Prozesses Autorisierungsregeln angewendet, die in der Datei pacpolicy.conf für die HTTP-Anforderung enthalten sind.
Ist das PAC-LDAP-Autorisierungsmodul für die Autorisierung aktiviert, werden auf die HTTP-Anforderung Autorisierungsregeln aus der Datei pacpolicy.conf angewendet. Wenn die HTTP-Anforderung den Caching-Proxy-Arbeitsablauf durchläuft, vergleicht jede Protect-Anweisung den angeforderten URL mit ihrer Anforderungsschablone. Bei Übereinstimmung ruft die Protect-Anweisung ein Zugriffsschutzschema auf. In diesem Fall entspricht das Zugriffsschutzschema der vom PAC-LDAP-Autorisierungsmodul kontrollierten Autorisierungsroutine. Die Authorization-Anweisung vergleicht den angeforderten URL mit ihrer Anforderungsschablone. Bei Übereinstimmung wird das PAC-LDAP-Autorisierungsmodul aufgerufen. Policys vom Typ 4, die in der Datei pacpolicy.conf definiert sind, grenzen die Authentifizierung weiter ein, die für verschiedene URL-Anforderungen erforderlich ist.
LDAP erlaubt den interaktiven Zugriff auf X.500-Verzeichnisse bei minimalem Verbrauch von Systemressourcen. IANA hat LDAP den TCP-Port 389 und den UDP-Port 389 zugeordnet. Nähere Informationen finden Sie in RFC 1777, der LDAP definiert.
Beispiele für unterstützte LDAP-Clients sind der IBM Tivoli-LDAP-Client und der IBM SecureWay-LDAP-Client.
Alle Komponenten des PAC-LDAP-Autorisierungsmoduls werden automatisch installiert, wenn das Caching-Proxy-System von WebSphere Application Server Version 6.1 installiert wird. Auf Linux- und UNIX-Systemen werden ein Verzeichnis für die Caching-Proxy-Bibliothek (./lib/), ein Verzeichnis für die Bibliothek des PAC-LDAP-Autorisierungsmoduls (./lib/plugins/pac/), ein Verzeichnis für die Binärdateien (./bin/) und ein Verzeichnis für die Konfiguration (./etc/) im Verzeichnis /opt/ibm/edge/cp/ erstellt. Anschließend werden von den Verzeichnissen /usr/lib/, /usr/sbin/ und /etc aus symbolische Verbindungen zu diesen produktspezifischen Verzeichnissen erstellt.
Verzeichnisstruktur
Linux- und UNIX-Verzeichnis | Windows-Verzeichnis | Inhalt |
---|---|---|
/opt/ibm/edge/cp/ | \Programme\IBM\edge\cp\ | CP-Basisverzeichnis (cp_root) |
cp_root/sbin/ | \Programme\IBM\edge\cp\Bin\ | CP-Binärdateien und -Scripts |
/usr/sbin/ | Symb. Verbindungen zu cp_root/sbin/ | |
cp_root/etc/ | \Programme\IBM\edge\cp\etc\ | CP-Konfigurationsdatei |
/etc/ | Symb. Verbindungen zu cp_root/etc/ | |
cp_root/lib/ | \Programme\IBM\edge\cp\lib\ plugins\ | CP-Bibliotheken |
cp_root/lib/ plugins/pac/ | \Programme\IBM\edge\ cp\lib\plugins\pac\ | Bibliotheken des PAC-LDAP-Autorisierungsmoduls |
/usr/lib/ | Symb. Verbindungen zu cp_root/lib/ und cp_root/lib/ plugins/pac/ | |
cp_root/server_root/pac/data/ | \Programme\IBM\ edge\cp\server_root\pac\data\ | Datenspeicher für PAC-LDAP-Autorisierungsmodul |
cp_root/server_root/ pac/creds/ | \Programme\IBM\ edge\cp\server_root\pac\creds\ | Berechtigungsnachweise für PAC-LDAP-Autorisie- rungsmodul |
Dateien des LDAP-Plug-in
Linux- und UNIX-Dateiname | Windows-Dateiname | Beschreibung |
---|---|---|
libpacwte.so | pacwte.dll | gemeinsam genutzte Bibliothek |
libpacman.so | pacman.dll | gemeinsam genutzte Bibliothek |
pacd_restart.sh | pacd_restart.bat | Script für Neustart des PAC-Dämons |
paccp.conf, pac.conf, pacpolicy.conf | paccp.conf, pac.conf, pacpolicy.conf | Konfigurations- und Policy-Dateien |
Damit zwischen dem PACD-Dämon und dem LDAP-Server sichere SSL-Verbindungen (SSL = Secure Sockets Layer) hergestellt werden können, müssen Sie das vom LDAP-Clientpaket vorausgesetzte GSKit-Paket installieren. GSKit 7 ist die erforderliche Version und wird standardmäßig auf der Caching-Proxy-Maschine bereitgestellt. Möglicherweise ist diese jedoch nicht die Version, die der LDAP-Client auf der Maschine voraussetzt. Es ist möglich, verschiedene GSKit-Versionen für verschiedene Prozesse auf einer Maschine zu verwenden.
Kopieren Sie die GSKit-Schlüsseldatei nach $pacd_creds_dir/pac_keyring.kdb und das Kennwort in die Datei $pacd_creds_dir/pac_keyring.pwd.
Auf Linux-Systemen muss die Umgebungsvariable LD_PRELOAD wie folgt konfiguriert werden, damit SSL-Verbindungen zwischen dem PACD-Dämon und dem LDAP-Server hergestellt werden können. Setzen Sie die Variable auf den folgenden Wert:
LD_PRELOAD=/usr/lib/libstdc++-libc6.1-1.so.2
Die in diesem Abschnitt beschriebenen GSKit-Voraussetzungen gelten auch für Linux-Systeme.
Auf Systemen mit Red Hat Enterprise Linux 4.0 wird der PACD-Prozess nicht gestartet, wenn Caching Proxy das LDAP-Plug-in von ITDS 6.0 für die Authentifizierung verwendet. Die folgende Fehlernachricht wird angezeigt:
"error while loading shared libraries: /usr/lib/libldapiconv.so: R_PPC_REL24 relocation at 0x0fb58ad0 for symbol 'strpbrk' out of range"
Systeme mit RHEL 4.0 werden derzeit von ITDS 6.0 nicht unterstützt.
Wenn der LDAP-Client von ITDS verwendet wird, kann der PACD-Prozess auf AIX-System aufgrund von nicht aufgelösten Verbindungen nicht gestartet werden. Beim Starten des PACD-Prozesses kann die folgende Fehlernachricht angezeigt werden:
exec(): 0509-036 Das Programm /usr/sbin/pacd kann aufgrund der folgenden Fehler nicht geladen werden: 0509-022 Das Modul /usr/lib/libpacman.a kann nicht geladen werden. 0509-150 Das abhängige Modul libldap.a konnte nicht geladen werden. 0509-022 Das Modul libldap.a kann nicht geladen werden.
Zum Umgehen dieses Problems mit dem LDAP-Client von ITDS Version 5 erstellen Sie die folgende symbolische Verbindung:
ln -s /usr/lib/libibmldap.a /usr/lib/libldap.a
Zum Umgehen dieses Problems mit dem LDAP-Client von ITDS Version 6 erstellen Sie die folgende symbolische Verbindung:
ln -s /opt/IBM/ldap/V6.0/lib/libibmldap.a /usr/lib/libldap.a
Drei Anweisungen, ServerInit, Authorization oder Authentication und ServerTerm, müssen zum Abschnitt mit den API-Anweisungen der Datei ibmproxy.conf hinzugefügt werden, damit das PAC-LDAP-Autorisierungsmodul initialisiert wird. Zum Erstellen dieser Anweisungen müssen Sie entweder die Datei ibmproxy.conf manuell editieren, oder, falls der Proxy-Server bereits aktiv ist, die Konfigurations- und Verwaltungsformulare in einem Internet-Browser aufrufen und das Formular "Verarbeitung von API-Anforderungen" öffnen. (Klicken Sie nacheinander auf Serverkonfiguration -> Anforderungsverarbeitung-> Verarbeitung von API-Anforderungen.) Jede Anweisung in der Konfigurationsdatei des Proxy-Servers muss in einer gesonderten Zeile stehen, auch wenn die hier aufgeführten Beispiele aus Gründen der besseren Lesbarkeit Zeilenumbrüche enthalten.
Beachten Sie die Prototypanweisungen (in Form von Kommentaren) im API-Abschnitt der Datei ibmproxy.conf. Diese API-Anweisungen sind in einer zweckmäßigen Reihenfolge angeordnet. Wenn Sie API-Anweisungen hinzufügen, um neue Funktionen und Plug-in-Module zu aktivieren, sollten Sie die Anweisungen wie im Prototypabschnitt der Konfigurationsdatei gezeigt anordnen. Alternativ dazu können Sie, falls erforderlich, die Kommentarzeichen für API-Anweisungen entfernen und API-Anweisungen editieren, um die Unterstützung für jede gewünschte Funktion oder jedes gewünschte Plug-in hinzuzufügen.
Die Anweisung ServerInit unterstützt drei Argumente: (1) den vollständig qualifizierten Pfad der gemeinsam genutzten Bibliothek, (2) den Funktionsaufruf und (3) den vollständig qualifizierten Pfad der Datei paccp.conf. Das erste und zweite Argument werden durch einen Doppelpunkt (:) getrennt. Das zweite und dritte Argument werden durch ein Leerzeichen getrennt. Das erste Argument und das dritte Argument sind systemspezifisch und abhängig davon, wo die Plug-in-Komponenten installiert sind. Das zweite Argument ist in der gemeinsam genutzten Bibliothek fest codiert und muss wie gezeigt eingegeben werden. Beim Erstellen einer Anweisung ServerInit im Formular "Verarbeitung von API-Anforderungen" müssen das zweite und dritte Argument im Feld Funktionsname eingegeben werden. Das dritte Argument wird in der Spalte IP-Schablone angezeigt.
Die Anweisung Authorization unterstützt drei Argumente: (1) eine Anforderungsschablone, (2) den vollständig qualifizierten Pfad der gemeinsam genutzten Bibliothek und (3) den Funktionsnamen. Die HTTP-Anforderungen werden mit der Anforderungsschablone verglichen, um zu bestimmen, ob eine Anwendungsfunktion aufgerufen werden muss. Die Anforderungsschablone kann ein Protokoll, eine Domäne und einen Host enthalten. Sie darf als vorangestelltes Zeichen einen Schrägstrich (/) und als Platzhalterzeichen einen Stern (*) verwenden. Beispielsweise sind folgende Schablonen gültig: /front_page.html , http://www.ics.raleigh.ibm.com , /pub*, /* und *. Der Funktionsname ist der Name, den Sie Ihrer Anwendungsfunktion im Programm zugewiesen haben. Dieser Name ist fest codiert und muss wie gezeigt eingegeben werden. Die ersten zwei Argumente werden durch ein Leerzeichen getrennt. Die letzten beiden Argumente werden durch einen Doppelpunkt (:) getrennt.
Die Anweisung Authentication unterstützt zwei Argumente: (1) den vollständig qualifizierten Pfad der gemeinsam genutzten Bibliothek und (2) den Funktionsnamen. Diese Argumente werden durch einen Doppelpunkt (:) getrennt. Das erste Argument ist systemspezifisch und abhängig davon, wo die gemeinsam genutzte Bibliothek installiert ist. Die URL-Schablone für das erste Argument muss mit dem Dokumentstammverzeichnis (/) beginnen, wenn Caching Proxy als Reverse Proxy verwendet wird. Das zweite Argument ist in der gemeinsam benutzten Bibliothek fest codiert und muss wie angezeigt eingegeben werden.
Die Anweisung ServerTerm unterstützt zwei Argumente: (1) den vollständig qualifizierten Pfad der gemeinsam genutzten Bibliothek und (2) den Funktionsnamen. Diese Argumente werden durch einen Doppelpunkt (:) getrennt. Das erste Argument ist systemspezifisch und abhängig davon, wo die gemeinsam genutzte Bibliothek installiert ist. Das zweite Argument ist in der gemeinsam genutzten Bibliothek fest codiert und muss wie gezeigt eingegeben werden. Diese Anweisung beendet den PAC-Dämon, wenn der Proxy-Server beendet wird. Ist der Dämon einem anderen Eigner zugeordnet als der Proxy-Server, kann der Proxy-Server den Dämon möglicherweise nicht stoppen. In diesem Fall muss der Dämon vom Administrator manuell gestoppt werden.
ServerInit Pfad_der_gemeinsamen Bibliothek:pacwte_auth_init Pfad_der_Konfigurations-/Policy-Datei
Linux- und UNIX-Systeme:
ServerInit /usr/lib/libpacwte.so:pacwte_auth_init /etc/pac.conf
Beispiel für Windows:
ServerInit C:\Progra ~1\IBM\edge\cp\lib\plugins\ pac\pacwte.dll:pacwte_auth_init C:\Progra ~1\IBM\edge\cp
Authorization Anforderungsschablone Pfad_der_gemeinsamen_Bibliothek:pacwte_auth_policy
Linux- und UNIX-Systeme:
Authorization http://* /usr/lib/libpacwte.so:pacwte_auth_policy
Beispiel für Windows:
Authorization http://* C:\Programme\IBM\edge\cp\lib\plugins\ pac\pacwte.dll:pacwte_auth_policy
Authentication BASIC Pfad_der_gemeinsamen_Bibliothek:pacwte_auth_policy
Linux- und UNIX-Systeme:
Authentication BASIC /usr/lib/plugins/pac/libpacwte.so:pacwte_auth_policy
Beispiel für Windows:
Authentication BASIC C:\Programme\IBM\edge\cp\lib\plugins\ pac\pacwte.dll:pacwte_auth_policy
ServerTerm Pfad_der_gemeinsamen_Bibliothek:pacwte_shutdown
Linux- und UNIX-Systeme:
ServerTerm /usr/lib/libpacwte.so:pacwte_shutdown
Beispiel für Windows:
ServerTerm BASIC C:\Programme\IBM\edge\cp\lib\plugins\ pac\bin\pacwte.dll:pacwte_shutdown
Die Konfigurations- und Policy-Dateien des PAC-LDAP-Autorisierungsmoduls müssen in einem Texteditor manuell editiert werden. Der Name einer Anweisung muss vom ersten Argument durch einen Doppelpunkt (:) getrennt werden. Mehrere Argumente werden durch Kommas (,) voneinander getrennt. Die Konfigurations- und Policy-Datei enthält Anmerkungen, die Sie beim Editieren unterstützen. Wichtige Policy-Anweisungen sind unten aufgeführt.
Die Datei paccp.conf wird während der Initialisierung von Caching Proxy von den gemeinsam genutzten Bibliotheken gelesen und enthält Definitionen (Zeilengruppe [PAC_MAN_SERVER]) für jeden PAC-Dämon, der gestartet wird. Für jeden PAC-Dämon muss eine eigene Zeilengruppe [PAC_MAN_SERVER] vorhanden sein.
[PAC_MAN_SERVER] hostname: # Name des PAC-Dämons port: # Port, an dem pacd Anforderungen empfängt. [PACWTE_PLUGIN] hostname_check:[true|false] # Aktiviert die DNS-Suche. Damit ibmproxy # funktioniert, muss die DNS-Suche aktiviert sein.
Die Datei pac.conf legt den LDAP-Server fest, zu dem der PAC-Dämon eine Verbindung herstellt.
[PAC_MAN_SERVER]
hostname: # Name des PAC-Dämons
port: # Port, an dem pacd Anforderungen empfängt.
conn_type:ssl # Setzen Sie dies auf Kommentar,
# wenn SSL nicht verwendet wird.
authentication_sequence: [primary|secondary|none]
authorization_sequence: [primary|secondary|none]
[LDAP_SERVER]
hostname: # Hostname des LDAP-Servers.
port:389 # Der Port, an dem LDAP Anforderungen empfängt.
ssl_port:636 # SSL-Port, der vom LDAP-Server verwendet wird.
admin_dn: # Benutzer mit Zugriffsberechtigung für LDAP-Server.
# Geben Sie admin_dn:NULL für die Unterstützung
# anonymer Bindungen an.
search_base: # Der Abschnitt der LDAP-Baumstruktur, der nach
# Policy-Informationen durchsucht werden soll.
# Sofern nicht erforderlich, geben
# Sie search_base:NULL an.
search_key: # ID-Feld, das gesucht werden soll.
[CACHE]
cred_cache_enabled [TRUE|FALSE] # Berechtigungs-Cache aktivieren.
cred_cache_min_size:100 # Mindestanzahl an Berechtigungen, die im Cache
# von pacd gespeichert werden sollen.
cred_cache_max_size:64000 # Maximale Anzahl an Berechtigungen, die im Cache
# von pacd gespeichert werden sollen.
cred_cache_expiration:86400 # Das Verfallsdatum einer Berechtigung.
policy_cache_enabled:[TRUE|FALSE] # Aktiviert/inaktiviert den Policy-Cache.
policy_cache_min_size:100 # Mindestanzahl an Policy-Einträgen, die im Cache
# gespeichert werden sollen.
policy_cache_max_size:64000 # Maximale Anzahl an Policy-Einträgen, die im Cache
# gespeichert werden sollen.
policy_cache_expiration:86400 # Verfallsdatum eines Policy-Eintrags.
Jede LDAP-Policy verwendet die folgende Schablone in der Konfigurations- und Policy-Datei. Jede Policy muss mit dem Schlüsselwort POLICY beginnen, das in Großbuchstaben geschrieben und in eckige Klammern eingeschlossen werden muss.
[POLICY] default_policy:[grant|deny] # Beschreibt die Standard-Policy für Benutzer, # die nicht im Abschnitt POLICY beschrieben sind. pac_client_hostname: # Die Instanzen von Caching-Proxy, die # eine Policy-Liste verwenden dürfen. id: # Die ID für den LDAP-Eintrag oder IP/Hostnamen # (Platzhalterzeichen werden unterstützt, # z. B. *.ibm.com). grant:[true|false] # true bedeutet den Zugriff erlauben, false bedeutet # den Zugriff verweigern. type:[0|1|2|3|4] # 0 ist ein LDAP-Eintrag, der eine Gruppe ist # 1 ist ein LDAP-Eintrag, der keine Gruppe ist # 2 ist eine IP-Adresse # 3 ist ein Hostname # 4 ist ein URL propagate:[true|false] # true bedeutet, dass die Zugriffsrechte (Zugriff # erteilen oder verweigern) an alle # untergeordneten Einträge oder Member # weitergegeben werden. stop_entry:[entry|NULL] # Die Weitergabe der Zugriffsrechte endet # bei diesem Eintrag. Ist die ID eine Gruppe, # muss stop_entry auf NULL gesetzt werden. # stop_entry kann auf eine IP-Adresse oder einen # Hostnamen angewendet werden. Jede Anweisung der # Art stop_entry muss in einer separaten Zeile stehen. exception_entry:[entry|NULL] # Beim Zuordnen der Zugriffsrechte werden diese # Einträge übersprungen, jedoch nicht die # untergeordneten Baumstrukturen. Hierbei kann # es sich um eine Liste von Einträgen handeln. # exception_entry kann auf eine Gruppe, eine # IP-Adresse oder einen Hostnamen angewendet werden. # Jede Anweisung vom Typ exception_entry muss in # einer separaten Zeile stehen. Exception_type: Exception:
Platzhalterzeichen (*) werden nur für den letzten Teil einer IP-Adresse oder für den ersten Teil eines Hostnamens in den Anweisungen id und stop_entry akzeptiert. Für Anweisungen vom Typ exception_entry werden keine Platzhalterzeichen unterstützt. Für alle Felder in LDAP-Einträgen werden ebenfalls keine Platzhalterzeichen unterstützt.
Die Angabe mehrerer Policy-Anweisungen wird unterstützt, wobei in den Fällen, in denen Policy-Anweisungen in Konflikt miteinander stehen, der Wert "false" immer Priorität hat, d. h., eine einzige Verweigerung in einer beliebigen Policy blockiert den Zugriff. Die Reihenfolge, in der die Policy-Anweisungen in der Konfigurations- und Policy-Datei aufgelistet sind, ist nicht relevant und stellt keine Priorität her.
Eine Reihe von Policy-Beispielen finden Sie in der Datei pacpolicy.conf im Verzeichnis mit den Konfigurationsdateien.
Erstellen Sie eine Textdatei mit dem Namen pac_ldap.cred im Verzeichnis /cp_root/server_root/pac/creds. Diese Datei enthält das Kennwort für den Benutzernamen, der mit der Anweisung admin_dn in der Datei pac.conf angegeben wurde.
Der PAC-Dämon verschlüsselt das Kennwort, wenn er die Datei zum ersten Mal liest.
Setzen Sie auf Linux- und UNIX-Plattformen die folgenden Befehle ab, um die Datei pac_ldap.cred zu erstellen:
cd cp_root/server_root/pac/creds echo "password" > pac_ldap.cred chown nobody pac_ldap.cred chgrp nobody pac_ldap.cred (unter SUSE Linux muss chgrp nogroup pac_ldap.cred verwendet werden)
Zum Erstellen der Datei auf einer Windows-Plattform geben Sie das Kennwort in einer Textdatei ein und speichern Sie diese Datei im Verzeichnis server_root\pac\creds\.
Der LDAP-Berechtigungsdämon wird als pacd-Prozess ausgeführt. Sie können den LDAP-Berechtigungsdämon mit den bereitgestellten Scripts starten, ohne Caching Proxy zu unterbrechen. Führen Sie das Script pacd wie folgt aus:
/usr/sbin/pacd_restart.sh Benutzer-ID_für_pacd
C:\Programme\IBM\edge\cp\Bin\pacd_restart.bat CP-Installationsstammverzeichnis
kill -15 pacd-Prozess-ID
Unter HP-UX: Möglicherweise laden das Plug-in PAC-LDAP und pacd zur Laufzeit nicht alle abhängigen gemeinsam genutzten Bibliotheken. Prüfen Sie daher vor ihrer Verwendung, ob die Systemvariablen wie folgt festgelegt sind:
SHLIB_PATH=/usr/lib:/usr/IBMldap/lib PATH=/usr/IBMldap/bin:$PATH PATH=/usr/IBMldap/bin/usr/IBMldap/
ist der Standardinstallationspfad für den LDAP-Client unter HP-UX. Ändern Sie die Angaben für PATH und SHLIB_PATH entsprechend ab, falls der LDAP-Client in einem anderen Verzeichnis installiert ist. Falls diese Variablen nicht festgelegt werden, können folgende Fehler auftreten:
"Fehler bei der Serverinitialisierung: Einige Funktionen aus dem DLL-Modul /opt/ibm/edge/cp/lib/plugins/pac/libpacwte.sl wurden nicht geladen."
"/usr/lib/dld.sl: Can't find path for shared library: libibmldap.sl /usr/lib/dld.sl: No such file or directory Abort"
Unter Linux: Für SUSE Linux Enterprise Server 9 kann der Befehl ldd pacd melden, dass die Datei libldap.so nicht gefunden wurde. Sie können dieses Problem umgehen, indem Sie die folgende symbolische Verbindung erstellen:
ln -s /usr/lib/libldap.so.19 /usr/lib/libldap.so
Unter AIX: Wenn Sie pacd mit IBM Tivoli Directory Server 5.2 starten, kann das Modul PAC-LDAP möglicherweise nicht geladen werden. In diesem Fall wird der folgende Fehler angezeigt:
exec(): 0509-036 Das Programm /usr/sbin/pacd kann aufgrund der folgenden Fehler nicht geladen werden: 0509-022 Das Modul /usr/lib/libpacman.a kann nicht geladen werden. 0509-150 Das abhängige Modul libldap.a konnte nicht geladen werden. 0509-022 Das Modul libldap.a kann nicht geladen werden.
Sie können dieses Problem umgehen, indem Sie die folgende symbolische Verbindung erstellen:
ln -s /usr/lib/libibmldap.a /usr/lib/libldap.a
Für Uid konnte kein Wert extrahiert werden. Rückkehrcode: 3Dieser Fehler wird auch angezeigt, wenn die LDAP-Authentifizierung ordnungsgemäß funktioniert, und kann deshalb ignoriert werden.
Dieser Teil enthält Anweisungen zum Überwachen von Caching Proxy mit Protokollen und dem Überwachungsprogramm für Serveraktivitäten (Server Activity Monitor).
Dieser Teil enthält die folgenden Kapitel:
Überwachung der Serveraktivität
Zum Anpassen der Protokollierung können Sie entweder die Konfigurations- und Verwaltungsformulare verwenden oder Anweisungen in der Konfigurationsdatei des Proxy-Servers editieren. Sie können folgende Optionen festlegen:
Caching Proxy kann drei Arten von Zugriffsprotokollen sowie ein Ereignisprotokoll und ein Fehlerprotokoll erstellen:
Caching Proxy beginnt jeden Tag um 00:00 Uhr mit der Erstellung neuer Protokolldateien. Ist der Proxy-Server um 00:00 Uhr nicht aktiv, werden die neuen Protokolle beim ersten Start an diesem Tag erstellt. Sie können für jede Protokolldatei das Verzeichnis sowie das Dateinamenspräfix angeben. Jede Protokolldatei, die erstellt wird, enthält außerdem ein Datumssuffix im Format .Mmmttjjjj (z. B. .Apr142000).
Da Protokolle sehr viel Plattenspeicherplatz belegen können, sollten Sie, um Fehler zu vermeiden, die Protokolldateien nicht auf der Speichereinheit speichern, auf der sich das Betriebssystem und der Cache befinden, sondern auf einer separaten Speichereinheit. Darüber hinaus sollten Sie die Routinen zur Protokollverwaltung, wie im Abschnitt Protokolle verwalten und archivieren beschrieben, konfigurieren.
Zum Festlegen der Basiskonfiguration für die Protokolle des Proxy-Servers wählen Sie in den Konfigurations- und Verwaltungsformularen Serverkonfiguration -> Protokollierung -> Protokolldateien aus. Geben Sie für jede Protokolldatei, die Sie verwenden möchten, den Pfad und Dateinamen an. Der aktuelle Dateiname für jedes Protokoll wird im zugehörigen Textfeld angezeigt. Wenn Sie keinen Pfad angegeben haben, wird der Standardwert angezeigt.
Die in den Protokollen des Proxy-Servers aufgezeichneten Informationen werden nicht automatisch in das Systemprotokoll geschrieben. Caching Proxy kann jedoch so konfiguriert werden, dass die Protokolleinträge zusätzlich oder ausschließlich in das Systemprotokoll geschrieben werden. Wählen Sie im Formular Protokolldateien das Markierungsfeld Information in Syslog protokollieren aus. Das Systemprotokoll muss vor Auswahl dieser Option bereits erstellt worden sein.
Wenn die Informationen des Proxy-Server-Protokolls nur in das Systemprotokoll geschrieben werden sollen, müssen Sie die Konfigurationsdatei des Proxy-Servers editieren. Informationen hierzu finden Sie im zugehörigen Abschnitt LogToSyslog - Angeben, ob Zugriffsinformationen an das Systemprotokoll gesendet werden sollen (nur Linux und UNIX).
Zugehörige Anweisungen in der Konfigurationsdatei
Wenn Sie die Protokolle in der Konfigurationsdatei des Proxy-Servers definieren möchten, lesen Sie in Anhang B. Anweisungen in der Konfigurationsdatei die zugehörigen Abschnitte zu folgenden Anweisungen:
In Zugriffsprotokollen werden die Aktivitäten der Hostmaschine, des Proxy-Servers und des Cache aufgezeichnet. Für jede Zugriffsanforderung, die der Proxy-Server empfängt, wird im entsprechenden Zugriffsprotokoll ein Eintrag eingefügt, der folgende Angaben enthält:
Zugriffsfehler werden im Fehlerprotokoll des Servers protokolliert.
Es gibt mehrere Gründe, weshalb die Informationen, die protokolliert werden, eingeschränkt werden sollten:
Die Protokolldateien eines ausgelasteten Servers können so groß werden, dass sie den gesamten Plattenspeicherplatz des Servers belegen. Standardmäßig werden alle Zugriffsanforderungen protokolliert, was bedeutet, dass nicht nur für eine HTML-Seite, sondern auch für jedes Bild, das diese Seite enthält, Protokolleinträge geschrieben werden. Werden nur wichtige Zugriffsanforderungen protokolliert, reduziert sich die Anzahl der Einträge im Protokoll erheblich. Beispielsweise können Sie die Zugriffsprotokolle so konfigurieren, dass Zugriffsanforderungen für HTML-Seiten protokolliert werden, jedoch keine Anforderungen für GIF-Bilder.
Wenn Sie beispielsweise wissen möchten, wer von außerhalb Ihres Unternehmens auf den Server zugreift, können Sie Zugriffsanforderungen, die von IP-Adressen innerhalb Ihres Unternehmens stammen, herausfiltern. Wenn Sie die Größe der Zielgruppe für eine bestimmte Website ermitteln möchten, können Sie ein Zugriffsprotokoll erstellen, in dem nur die Zugriffsanforderungen für diesen URL aufgezeichnet werden.
Aus Zugriffsprotokollen ausgeschlossene Informationen werden in keinem Zugriffsbericht aufgezeichnet und sind für eine spätere Verwendung nicht verfügbar. Wenn Sie aus diesem Grund nicht sicher sind, wie viele Zugriffsinformationen Sie protokollieren müssen, sollten Sie beim Herausfiltern von Informationen vorsichtig sein, bis Sie mehr Erfahrung mit der Überwachung des Servers gesammelt haben.
Zugriffsprotokolleinträge können basierend auf einem der folgenden Attribute gefiltert werden:
Zum Festlegen von Filtern wählen Sie in den Konfigurations- und Verwaltungsformularen Serverkonfiguration -> Protokollierung -> Ausschlüsse aus dem Zugriffsprotokoll aus. Legen Sie nur die gewünschten Ausschlüsse fest. Sie müssen nicht alle Kategorien verwenden.
Klicken Sie auf Übergeben.
Zugehörige Anweisungen in der Konfigurationsdatei
Wenn Sie die Filter für das Zugriffsprotokoll in der Konfigurationsdatei des Proxy-Servers definieren möchten, lesen Sie in Anhang B. Anweisungen in der Konfigurationsdatei die zugehörigen Abschnitte zu folgenden Anweisungen:
Alle Protokolle sind in der Standardkonfiguration von Caching Proxy aktiviert. Sie sind im Unterverzeichnis logs/ des Installationsverzeichnisses gespeichert. Die Standardpfade lauten wie folgt:
Jeder Protokolldateiname ist eine Kombination aus dem Basisdateinamen und einem Datumssuffix im Format .Mmmttjjjj, z. B. proxy.Feb292000.
Protokolle werden standardmäßig im einheitlichen Dateiformat (Common File Format) gespeichert. Ein kombiniertes Protokollformat ist auch verfügbar und kann durch Einfügen der folgenden Zeile zur Konfigurationsdatei des Proxy-Servers (ibmproxy.conf) festgelegt werden:
LogFileFormat combined
Das kombinierte Protokollformat ähnelt dem einheitlichen Format, verfügt jedoch über zusätzliche Felder mit Informationen zu Herkunftsadressen, Benutzeragenten und Cookies. Die Ortszeit ist das Standardzeitformat.
Standardmäßig werden alle Zugriffsanforderungen im entsprechenden Zugriffsprotokoll aufgezeichnet, während im Systemprotokoll keine Informationen zu Zugriffen protokolliert werden. Informationen zu Fehlern werden nur im Fehlerprotokoll und Informationen zu Ereignissen nur im Ereignisprotokoll aufgezeichnet.
In der Standardkonfiguration werden Protokolle weder archiviert noch gelöscht.
Caching Proxy verwaltet die Protokolle mit Hilfe eines Plug-in. Nähere Informationen finden Sie in Anhang B. Anweisungen in der Konfigurationsdatei auf der zugehörigen Seite zur Anweisung Midnight - API-Plug-in für die Archivierung von Protokollen angeben in der Konfigurationsdatei.
Sie können festlegen, wie die Tagesprotokolle archiviert und entfernt werden sollen. Grundlegende Optionen:
Standardmäßig werden die Protokolle des aktuellen und des vorangegangenen Tages von den Verwaltungsagenten niemals entfernt. Alle Protokolle des aktuellen Tages und alle Cache-Zugriffsprotokolle des vorangegangenen Tages werden von den Verwaltungsagenten niemals komprimiert.
Zum Konfigurieren der Protokollverwaltung wählen Sie in den Konfigurations- und Verwaltungsformularen Serverkonfiguration -> Protokollierung -> Protokollarchivierung aus. Legen Sie in diesem Formular mit dem Dropdown-Fenster die Verwaltungsmethode fest.
Zugehörige Anweisungen in der Konfigurationsdatei
Informationen zum Konfigurieren der Protokollarchivierung unter Verwendung der Konfigurationsdatei des Proxy-Servers finden Sie in Anhang B. Anweisungen in der Konfigurationsdatei auf den Seiten zu folgenden Anweisungen:
Das folgende Beispiel zeigt, wie Sie die Protokollierung an Ihre Erfordernisse anpassen können. Angenommen, Sie haben Caching Proxy gerade erst erworben und installiert. Sie möchten den Server so einrichten, dass Zugriffs- und Fehlerinformationen unter Berücksichtigung folgender Kriterien protokolliert werden:
Um Caching Proxy so zu konfigurieren, dass die Protokolle gemäß diesen Kriterien verwaltet werden, wählen Sie in den Konfigurations- und Verwaltungsformularen zunächst Serverkonfiguration -> Protokollieren aus.
Nach Ausführung dieser Schritte werden in der Konfigurationsdatei des Proxy-Servers folgende Zeilen erzeugt:
LogArchive purge PurgeAge 30 PurgeSize 25 AccessLogExcludeURL *.gif NoLog 130.128.*.* AccessLogExcludeReturnCode 300
Die Überwachung der Serveraktivität (Server Activity Monitor) von Caching Proxy zeigt Statistiken zu Server- und Netzleistung, den Server- und Netzstatus sowie die Zugriffsprotokolleinträge an. Diese Überwachungsfunktion kann fern genutzt werden und muss nicht auf derselben Maschine installiert sein, auf der der Server ausgeführt wird. Die Überwachung der Serveraktivität ist standardmäßig aktiviert und erfordert keine Konfiguration.
Die Funktion zur Überwachung der Serveraktivität (Server Activity Monitor) kann auf zwei Arten aufgerufen werden:
http://Name.Ihres.Servers/Usage/Initial
Anders als bei anderen Formularen im Konfigurationsclient werden mit den Formularen dieser Kategorie keine Konfigurationen für den Server festgelegt, sondern Daten zur Serverauslastung angezeigt. Diese Formulare enthalten wesentlich mehr Informationen, als in einem Konsolfenster angezeigt werden können.
In den folgenden Abschnitten werden die Informationen erläutert, die die Überwachung der Serveraktivität liefert. Außerdem werden Empfehlungen gegeben, wie Sie diese Informationen zur Leistungsoptimierung nutzen können.
Unter Überwachung der Serveraktivität sind mehrere Seiten verfügbar:
Auf jeder dieser Seiten wird die Schaltfläche Aktualisieren angezeigt. Wenn Sie diese Schaltfläche anklicken, werden die Informationen aktualisiert.
Aktivitätsstatistik
Tabelle 4 zeigt ein Beispiel der Seite Aktivitätsstatistik.
Aktivitätsstatistik | |
---|---|
Verbindungen | 1 aktiv, 431 maximal |
Antwortzeit | Nicht verfügbar |
Durchsatz | 0 Verbindungen/Sekunde |
Heute verarbeitete Anforderungen | 0 |
Summe verarbeiteter Anforderungen | 114 |
Anforderungsfehler | 3 |
Mit diesen Statistiken zur Serveraktivität kann der Datenverkehr auf dem Server unter den Aspekten Anzahl der Zugriffsanforderungen, Antwortzeit, Durchsatz, Anzahl Anforderungen, die heute verarbeitet wurden, Gesamtzahl der verarbeiteten Anforderungen und Fehler überwacht werden. Die folgenden Konfigurationsänderungen haben Auswirkungen auf die Seite Aktivität.
Netzstatistik
Tabelle 5 zeigt ein Beispiel der Seite Netzstatistik.
Netzstatistik | |
---|---|
Abgehende Daten: | 1KB/Sekunde |
Ankommende Daten: | 1KB/Sekunde |
Eingesparte Bandbreite | 3 KB (0KB/Sekunde) |
Heute eingesparte Bandbreite: | 0 KB (0 KB/Sekunde) |
Das Formular Netzstatistik enthält Informationen zu dem Netz, in dem der Proxy-Server läuft, einschließlich der Datenübertragungsgeschwindigkeiten für gesendete und empfangene Bytes.
Zugriffsstatistik
Auf der Seite Zugriffsstatistik werden die letzten 20 Einträge aus den Zugriffsprotokollen angezeigt. Die Seite zeigt die aktuellen Einträge aus dem Zugriffsprotokoll des Proxy-Servers (in schwarzer Schrift) und aus dem Cache-Zugriffsprotokoll (in blauer Schrift) an. Sie können die Anzeige anpassen, indem Sie die zu protokollierenden Objekte festlegen. Nähere Informationen zu den Zugriffsprotokollstatistiken finden Sie im Abschnitt Filter für Zugriffsprotokolle.
Statistik über Proxyzugriff
Das Formular Statistik über Proxyzugriff enthält Informationen zur Aktivität des Proxy-Servers, z. B. welche URLs angefordert wurden und ob diese aus dem Cache bereitgestellt wurden. Nach den URLs werden die an die Clients zurückgegebenen Rückkehrcodes sowie die Dateigröße in Byte angezeigt. Die folgenden Einstellungen können die Proxy-Zugriffsstatistik verbessern:
Cache-Statistik
Ist das Caching aktiviert, zeigt die Seite Cache-Statistik aktuelle Informationen zu den Cache-Zugriffen an. Unter anderem werden die folgenden Informationen zu Cache und Index angezeigt:
Viele Cache-Konfigurationsoptionen wirken sich auf die Ergebnisse der Cache-Statistik aus (siehe Proxy-Server-Caching konfigurieren).
Übersicht über die Cache-Aktualisierung
Wurde der Cache-Agent so konfiguriert, dass Dateien vorab in den Cache geladen werden, zeigt die Seite Übersicht über die Cache-Aktualisierung Informationen zur letzten Ausführung des Cache-Agenten an. Der Cache-Agent muss mindestens einmal ausgeführt werden, damit Informationen angezeigt werden können. Wenn Sie die Arbeitsweise des Cache-Aktualisierungsagenten ändern möchten, müssen Sie Folgendes berücksichtigen:
Dieser Abschnitt enthält eine Referenz für die Caching-Proxy-Befehle.
Verwenden Sie den Befehl cgiparse, um die Umgebungsvariable QUERY_STRING für CGI-Scripts syntaktisch zu analysieren (Parsing). Wenn die Umgebungsvariable QUERY_STRING nicht definiert ist, liest der Befehl die CONTENT_LENGTH-Zeichen aus der Standardeingabe. Die gesamte zurückgegebene Ausgabe wird in die Standardausgabe geschrieben.
cgiparse -Flag [Wert]
Im Folgenden sind die gültigen Flags, die zugehörigen Optionen (-k -f -v -r -i -s -p -c -q -P) und ihre Funktionen aufgeführt:
eval 'cgiparse -init'
Dieser Befehl setzt die Umgebungsvariable QUERY_STRING, unabhängig davon, ob die Methode GET oder POST verwendet wurde.
Bei Verwendung der Methode GET kann cgiparse in einem Script mehrfach aufgerufen werden. cgiparse darf bei Verwendung der Methode POST nur einmal angegeben werden. Wenn die Methode POST verwendet wird und die Standardeingabe gelesen wurde, findet der nächste Befehl cgiparse die Standardeingabe leer vor und wartet unbegrenzt.
In den folgenden Beispielen wird die Tatsache ignoriert, dass QUERY_STRING bereits vom Server definiert wurde. $ steht in den folgenden Beispielen für die Eingabeaufforderung der Bourne-Shell.
$ QUERY_STRING="is+2%2B2+really+four%3F" $ export QUERY_STRING $ cgiparse -keywords is 2+2 really four? $
$ export QUERY_STRING="name1=Value1&name2=Value2%3f+That%27s+right%21"; $ cgiparse -form FORM_name1='Value1'; FORM_name2='Value2? That'\'s right!' $ eval `cgiparse -form` $ set | grep FORM FORM_name1="Value1" FORM_name2="Value2? That's right!" $
$ QUERY_STRING="name1=value1&name2=Second+value%3F+That'\'s%27s $ cgiparse -value name1 value1 $ cgiparse -value name2 Second value? That's right! $
Verwenden Sie den Befehl cgiutils in NPH-Programmen (No-Parse Header), um eine vollständige HTTP-1.0-Anwort zu generieren.
cgiutils -Flag [Wert]
Wenn der Wert Leerzeichen enthält, setzen Sie ihn in Anführungszeichen ("").
cgiutils -ct text/html
Wenn Sie den Typ/Subtyp weglassen, wird der MIME-Inhaltstyp auf den Standardwert text/plain festgelegt. In diesem Beispiel wird der MIME-Inhaltstyp auf text/plain festgelegt.
cgiutils -ct
cgiutils -ce x-compress
cgiutils -cl en_UK
cgiutils -expires 2 days 12 hours
Mit dem Befehl cgiutils wird die Zeitspanne, die Sie angeben, zur aktuellen Westeuropäischen Zeit addiert, um das Verfallsdatum zu errechnen. Das Verfallsdatum wird im HTTP-Format in den Header Expires: gestellt.
cgiutils -expires "1 year 3 months 2 weeks 4 days 12 hours 30 mins"
cgiutils -status 200 -reason "Virtual doc follows" -expires now
Dadurch können Header wie dieser hier generiert werden:
HTTP/1.0 200 Virtual doc follows MIME-Version: 1.0 Server: IBM-ICS Date: Tue, 05 Jan 1996 03:43:46 GMT Expires: Tue, 05 Jan 1996 03:43:46 GM
Der Befehl cgiutils generiert automatisch den Header Server:, da dieser in der CGI-Umgebung zur Verfügung steht. Das Feld Date: wird ebenfalls automatisch generiert, es sei denn, das Flag -nodate ist angegeben.
Hinter der Ausgabe wird eine Leerzeile eingefügt, um das Ende des Abschnitts mit den MIME-Headern zu markieren. Falls Sie hinter diesem Abschnitt weitere Header einfügen möchten, verwenden Sie das Flag -noel (NO-Empty-Line), wie im nächsten Beispiel gezeigt.
cgiutils -noel -expires "2 days" -nodate
HTTP/1.0 200 Virtual doc follows MIME-Version: 1.0 Server: IBM-ICS Expires: Tue, 07 Jan 1996 03:43:46 GMT
Verwenden Sie den Befehl htadm, um die Kennwortdateien des Servers zu verwalten. Der Server verwendet Kennwortdateien, um den Zugriff auf Ihre Dateien zu steuern. Mit diesem Befehl können Sie einer Kennwortdatei einen Benutzernamen hinzufügen, einen Benutzer aus einer Kennwortdatei löschen, das Kennwort eines Benutzers überprüfen und eine leere Kennwortdatei erstellen. Außerdem können Sie das Kennwort eines Benutzers ändern, indem Sie zuerst das Kennwort des Benutzers löschen und anschließend ein neues Kennwort erstellen.
htadm -Flag [Wert]
Verwenden Sie nur alphabetische und numerische Zeichen für den Benutzernamen. Verwenden Sie keine Sonderzeichen.
Der Befehl schlägt fehl, wenn es bereits einen Benutzer mit demselben Namen in der Kennwortdatei gibt.
Kennwörter können bis zu 32 Zeichen lang sein. Verwenden Sie nur alphabetische und numerische Zeichen für das Kennwort. Verwenden Sie keine Sonderzeichen.
Kennwörter können bis zu 32 Zeichen lang sein. Verwenden Sie nur alphabetische und numerische Zeichen für das Kennwort. Verwenden Sie keine Sonderzeichen.
htadm -adduser /opt/ibm/edge/cp/server_root/protect/heroes.pwd clark superman "Clark Kent"
htadm -adduser "C:\Programme\IBM\edge\cp\server_root\protect\ heroes.pwd" clark superman "Clark Kent"
htadm -deluser /opt/ibm/edge/cp/server_root/protect/ heroes.pwd clark superman "Clark Kent"
htadm -deluser "C:\Programme\IBM\edge\cp\server_root\protect\ heroes.pwd" clark superman "Clark Kent"
Verwenden Sie den Befehl htcformat, um eine unformatierte Einheit oder eine Datei für die Speicherung des Proxy-Server-Cache vorzubereiten. Dieser Formatierungsbefehl muss verwendet werden, bevor die Einheit für den Proxy-Server-Cache angegeben wird.
Im Einheitenpfad muss die unformatierte Einheit angegeben sein. Nähere Informationen zum Zugriff auf unformatierte Einheiten finden Sie in der Dokumentation zu Ihrem Dateisystem. Beispiele sind in Proxy-Server-Caching konfigurieren enthalten.
Die Mindestgröße für einen Caching-Proxy-Cache sind 16.392 KB. Dies entspricht 2.049 Blöcken.
htcformat Einheit [-blocksize <Blockgröße>] [-blocks Anzahl Blöcke] htcformat -file Dateipfad [-blocksize Blockgröße] -blocks Anzahl Blöcke
Das Caching-System teilt die Cache-Dateien oder -Einheiten zusätzlich in Container für Indexierung und Garbage-Collection auf. Für die Größe der Container wird eine bestimmte Anzahl von Blöcken festgelegt. Die Größe eines Containers kann nicht konfiguriert werden. Damit die Funktion Garbage-Collection ausgeführt werden kann, sind mindestens zwei Container erforderlich. Die Mindestgröße des Cache beträgt 16.392 KB.
Der Befehl htcformat weist Formatierungsanforderungen für Cache-Einheiten mit weniger als zwei Containern zurück.
Der folgende Beispielbefehl formatiert eine Plattenpartition mit dem Namen c0t0d0s0 unter Solaris.
htcformat /dev/rdsk/c0t0d0s0
Der folgende Beispielbefehl formatiert eine Plattenpartition mit dem Namen lv02 unter AIX.
htcformat /dev/rlv02
Der folgende Beispielbefehl formiert eine Plattenpartition mit dem Namen d: unter Windows.
htcformat \\.\d:
Der folgende Beispielbefehl erstellt die Datei filecache mit einer Größe von ca. 1 GB.
htcformat -file /opt/ibm/edge/cp/filecache -blocks 131072
Verwenden Sie den Befehl ibmproxy, um den Server zu starten.
Sie können alle Flags (außer -r) mit den Anweisungen in der Konfigurationsdatei des Servers definieren.
Es ist üblich, eine Readme-Datei mit Anweisungen und Hinweisen zu erstellen, die von allen Benutzern, die anfangen, mit dem Verzeichnis arbeiten, gelesen werden sollte. Standardmäßig bettet der Befehl ibmproxy alle Readme-Dateien in die Hypertextversion eines Verzeichnisses ein. Die Anweisungen für die Readme-Datei können auch mit der Konfigurationsanweisung DirReadme definiert werden.
ibmproxy [-Flag [-Flag [-Flag..]]]
Da der http-Dämon die vom Server derzeit verwendete Konfigurationsdatei lesen muss, um auf die PID-Datei zuzugreifen, müssen Sie beim Neustart dieselbe Konfigurationsdatei angeben. Wenn Sie beim Start des Servers das Flag -r und eine bestimmte Konfigurationsdatei verwendet haben, müssen Sie dieses Flag und diese Datei mit -restart angeben.
Optionen für die Signalverarbeitung sind ebenfalls nur auf Linux- und UNIX-Plattformen verfügbar. Auf Linux- und UNIX-Plattformen stehen folgende Optionen zur Verfügung.
ibmproxy -p 8080 -r /usr/etc/ibmproxy.conf
startsrc -s ibmproxy
Falls die Standardkonfigurationsdatei nicht vorhanden ist, exportiert der Befehl ibmproxy die Verzeichnisstruktur /Public. Diese Verzeichnisstruktur kann Softlinks zu anderen Verzeichnisstrukturen enthalten.
In diesem Abschnitt werden die Anweisungen beschrieben, die in der Konfigurationsdatei ibmproxy.conf enthalten sind.
Verwenden Sie diese Informationen als Referenz, wenn Sie den Server durch Editieren der Datei ibmproxy.conf konfigurieren. Falls Sie die Konfigurations- und Verwaltungsformulare verwenden, können Sie dieses Kapitel ignorieren.
Die Anweisungen sind in alphabetischer Reihenfolge aufgeführt.
Einige Anweisungen werden bei einem Neustart des Servers nicht aktualisiert. Wenn Sie die folgenden Anweisungen ändern, während der Server aktiv ist, müssen Sie den Server manuell stoppen und anschließend erneut starten. (Nähere Informationen hierzu finden Sie in Caching Proxy starten und stoppen.)
Anweisungsgruppe | Anweisungen |
CGI | DisinheritEnv, InheritEnv |
Caching | Caching |
Protokollierung | AccessLog, CacheAccessLog, ErrorLog, ProxyAccessLog, ServerRoot |
Netzzugriff | BindSpecific, Hostname, ListenBacklog, Port |
Leistung | MaxActiveThreads |
RTSP | Alle RTSP-Anweisungen |
SSL | Alle SSL-Anweisungen |
Prozesssteuerung unter Linux und UNIX | GroupId, UserId |
Verschiedenes | TransparentProxy |
Dieser Anhang enthält zu jeder Anweisung folgende Informationen:
Anweisungsname Wert
Dies sind die in der Standardkonfigurationsdatei ursprünglich codierten Werte. Ändern Sie nur die Teile der Konfigurationsdatei, für die Sie von den Standardeinstellungen abweichende Werte verwenden möchten. Eine Anweisung, für die kein Standardwert definiert ist, ist in der Datei auf Kommentar gesetzt (# ist das erste Zeichen in der entsprechenden Zeile). Wenn Sie für eine solche Anweisung einen Wert festlegen möchten, entfernen Sie das Kommentarzeichen und fügen Sie den Wert zu dieser Zeile der Konfigurationsdatei hinzu.
Die folgende Liste enthält Werte, die in der Konfigurationsdatei angegeben werden können:
Alle Einträge werden in Sekunden umgewandelt und addiert.
Beachten Sie beim Editieren der Konfigurationsdatei Folgendes:
Nachfolgend werden die Anweisungen von Caching Proxy beschrieben.
Mit dieser Anweisung können Sie festlegen, dass Dateien einem Client auch dann bereitgestellt werden, wenn der MIME-Typ der Datei nicht mit dem vom Client gesendeten Header ACCEPT: übereinstimmt. Wenn diese Anweisung auf OFF gesetzt ist, werden Dateien, deren MIME-Typ nicht mit den vom Client akzeptierten Typen übereinstimmt, nicht angezeigt. Stattdessen wird eine Fehlerseite angezeigt.
AcceptAnything {on | off}
AcceptAnything off
AcceptAnything on
Mit dieser Anweisung können Sie das Verzeichnis und die Datei angeben, in der der Server Zugriffsstatistiken protokollieren soll. Standardmäßig schreibt der Server einen Eintrag in das Protokoll, wenn ein Client eine Datenanforderung für auf dem lokalen Server gespeicherte Daten an den Server sendet. Normalerweise gehören zu diesen Einträgen ausschließlich Anforderungen des Konfigurationsclients und Zugriffsanforderungen, wenn die Caching-Proxy-Maschine als Ursprungsserver eingesetzt wird. Dieses Protokoll enthält keine Informationen zu Proxy- oder Cache-Zugriffen.
Mit der Anweisung NoLog können Sie Clients angeben, deren Anforderungen nicht protokolliert werden sollen. Eine Beschreibung der Anweisung NoLog finden Sie im Abschnitt NoLog - Protokolleinträge für bestimmte Hosts oder Domänen, die mit einer Schablone übereinstimmen, unterdrücken.
Wenn der Server aktiv ist, startet er täglich um 00:00 Uhr eine neue Protokolldatei. Andernfalls wird eine neue Protokolldatei gestartet, wenn der Server zum ersten Mal am Tag gestartet wird. Beim Erstellen der Datei verwendet der Server den von Ihnen angegebenen Dateinamen und hängt ein Datumssuffix an. Das Datumssuffix hat das Format TTMmmJJJJ, wobei Mmm für die ersten drei Buchstaben des Monats, TT für den Tag des Monats und JJJJ für das Jahr stehen.
Es empfiehlt sich, alte Protokolldateien zu löschen, weil sie erheblich viel Speicherplatz auf dem Festplattenlaufwerk belegen können.
AccessLog /Verzeichnispfad/Name_der_Protokolldatei
AccessLog /logs/accesslog
Mit dieser Anweisung können Sie verhindern, dass mit einer bestimmten Methode angeforderte Zugriffe auf Dateien oder Verzeichnisse protokolliert werden. Sie könnten beispielsweise festlegen, dass DELETE-Anforderungen für Dateien und Verzeichnisse nicht protokolliert werden.
Es können mehrere Vorkommen dieser Anweisung in der Konfigurationsdatei enthalten sein. Sie können mit einer Anweisung auch mehrere Methoden angeben, wenn Sie sie durch Leerzeichen voneinander trennen.
AccessLogExcludeMethod Methode [...]
AccessLogExcludeMethod GET AccessLogExcludeMethod PUT AccessLogExcludeMethod POST AccessLogExcludeMethod DELETE AccessLogExcludeMethod GET PUT
Keiner. Der Server zeichnet unabhängig von der Methode alle Anforderungen für Dateien und Verzeichnisse im Zugriffsprotokoll auf.
Mit dieser Anweisungen können Sie verhindern, dass Zugriffsanforderungen für Verzeichnisse und Dateien eines bestimmten MIME-Typs im Proxy-Zugriffsprotokoll aufgezeichnet werden. (Beispiele für MIME-Typen sind text/html, image/gif und image/jpeg.) Sie könnten beispielsweise festlegen, dass keine Zugriffsanforderungen für Grafiken im GIF-Format protokolliert werden.
Es können mehrere Vorkommen dieser Anweisung in der Konfigurationsdatei enthalten sein. Sie können mit einer Anweisung auch mehrere MIME-Typen angeben, indem Sie sie durch mindestens ein Leerzeichen voneinander trennen.
AccessLogExcludeMimeType MIME-Typ [...]
AccessLogExcludeMimeType image/gif AccessLogExcludeMimeType text/html AccessLogExcludeMimeType image/gif text/html
Keiner. Der Server zeichnet unabhängig vom MIME-Typ alle Anforderungen für Dateien und Verzeichnisse im Zugriffsprotokoll auf.
Mit dieser Anweisung können Sie festlegen, dass Zugriffsanforderungen, denen ein Fehlercode aus einem bestimmten Bereich zugeordnet ist, nicht protokolliert werden. Diese Fehlercodenummern sind Statuscodes des Proxy-Servers. Es können keine einzelnen Codes angegeben werden. Wenn Sie beispielsweise 300 angeben, werden die Zugriffsanforderungen mit Umleitungsrückkehrcodes (301, 302, 303 und 304) von der Protokollierung ausgeschlossen.
Es können mehrere Vorkommen dieser Anweisung in der Konfigurationsdatei enthalten sein. Sie können mit einer Anweisung auch mehrere Rückkehrcodes angeben, indem Sie sie durch mindestens ein Leerzeichen voneinander trennen.
AccessLogExcludeReturnCode Bereich
AccessLogExcludeReturnCode 300
Keiner. Der Server zeichnet unabhängig vom Rückkehrcode alle Anforderungen im Zugriffsprotokoll auf.
Mit dieser Anweisung können Sie festlegen, dass Zugriffsanforderungen für bestimmte Dateien oder Verzeichnisse, die einer bestimmten URL-Schablone entsprechen, nicht protokolliert werden. Sie könnten beispielsweise festlegen, dass Zugriffsanforderungen für GIF-Dateien oder Zugriffsanforderungen für eine bestimmte Datei oder ein bestimmtes Verzeichnis auf Ihrem Server nicht protokolliert werden.
Es können mehrere Vorkommen dieser Anweisung in der Konfigurationsdatei enthalten sein. Sie können mit einer Anweisung auch mehrere Einträge angeben, indem Sie sie durch mindestens ein Leerzeichen voneinander trennen.
AccessLogExcludeURL Datei_oder_Typ [...]
AccessLogExcludeURL *.gif AccessLogExcludeURL /Freebies/* AccessLogExcludeURL *.gif /Freebies/*
Keiner. Der Server protokolliert die Zugriffanforderungen für alle Dateien und Verzeichnisse.
Mit dieser Anweisung können Sie festlegen, dass Zugriffsanforderungen von bestimmten Benutzeragenten (z. B. Internet Explorer 5.0) nicht protokolliert werden.
Es können mehrere Vorkommen dieser Anweisung in der Konfigurationsdatei enthalten sein. Sie können mit einer Anweisung auch mehrere Einträge angeben, indem Sie sie durch mindestens ein Leerzeichen voneinander trennen.
AccessLogExcludeUserAgent Benutzeragent [...]
AccessLogExcludeUserAgent *Mozilla/2.0 AccessLogExcludeUserAgent *MSIE 5*
Standardmäßig enthält die Datei ibmproxy.conf die folgenden Definitionen für die Anweisung AccessLogExcludeUserAgent:
AccessLogExcludeUserAgent IBM_Network_Dispatcher_HTTP_Advisor AccessLogExcludeUserAgent IBM_Network_Dispatcher_WTE_Advisor
Die aufgelisteten Benutzeragenten sind für bestimmte Load-Balancer-Advisor definiert, die dem Caching-Proxy-Server normalerweise vorgeschaltet sind. Anforderungen dieser Benutzeragenten werden standardmäßig nicht protokolliert, um die Schreibzugriffe auf das Protokoll zu verringern und dadurch einen höheren Durchsatz zu erzielen. Die Zugriffsanforderungen aller anderen Benutzeragenten werden standardmäßig vom Server protokolliert.
Mit dieser Anweisung können Sie ein Symbol angeben, das zum Ausrichten der Überschriften in Verzeichnislisten verwendet werden soll, die zurückgegeben werden, wenn der Server als Proxy-Server für FTP-Anforderungen auftritt. Die Symbole erscheinen neben den zugehörigen Dateien, um dem Benutzer die Unterscheidung zwischen den Dateien zu erleichtern.
Sie können ein leeres oder jedes andere Symbol angeben. Für eine ordnungsgemäße Ausrichtung muss das verwendete Symbol dieselbe Größe besitzen wie die anderen Symbole in den Verzeichnislisten.
AddBlankIcon Symbol-URL alternativer_Text
Gibt den letzten Teil des URL für das Symbol an. Der Server hängt diesen Wert an das Verzeichnis /icons/ an, um die vollständige URL-Anforderung zu bilden. Falls sich die Anforderung auf eine lokale Datei bezieht, übersetzt der Server sie gemäß den Zuordnungsanweisungen. Damit das Symbol abgerufen werden kann, müssen die Zuordnungsanweisungen die Übergabe der Anforderung zulassen.
Wenn Sie den Server als Proxy-Server verwenden, muss die vollständige Anforderung ein vollständig qualifizierter URL sein, der auf Ihren Server verweist.
AddBlankIcon logo.gif Logo
Standardmäßig ist kein alternativer Text angegeben, weil das Symbol leer ist.
Mit dieser Anweisung können Sie ein Symbol für die Darstellung eines Verzeichnisses in einer Verzeichnisliste angeben.
AddDirIcon Symbol-URL alternativer_Text
Gibt den letzten Teil des URL für das Symbol an. Der Server hängt diesen Wert an das Verzeichnis /icons/ an, um die vollständige URL-Anforderung zu bilden. Falls sich die Anforderung auf eine lokale Datei bezieht, übersetzt der Server sie gemäß den Zuordnungsanweisungen. Damit das Symbol abgerufen werden kann, müssen die Zuordnungsanweisungen die Übergabe der Anforderung zulassen.
Wenn Sie den Server als Proxy-Server verwenden, muss die vollständige Anforderung ein vollständig qualifizierter URL sein, der auf Ihren Server verweist. Sie müssen den URL einer lokalen Datei zuordnen und sicherstellen, dass die Zuordnungsanweisungen die Übergabe des URL zulassen.
AddDirIcon direct.gif DIR
Mit dieser Anweisung können Sie Dateien mit einem bestimmten Suffix an einen MIME-Codierungstyp binden. Diese Anweisung wird selten verwendet.
AddEncoding .Erweiterung Codierung
AddEncoding .qp quoted_printable
AddEncoding .Z x-compress
Mit dieser Anweisung können Sie Symbole für die Darstellung von Dateien mit einem bestimmten MIME-Inhaltstyp oder MIME-Codierungstyp angeben. Der Server verwendet diese Symbole in Verzeichnislisten, einschließlich FTP-Verzeichnislisten.
AddIcon Symbol-URL alternativer_Text Schablone_für_MIME-Typ
Gibt den letzten Teil des URL für das Symbol an. Der Server hängt diesen Wert an das Verzeichnis /icons/ an, um die vollständige URL-Anforderung zu bilden. Falls sich die Anforderung auf eine lokale Datei bezieht, übersetzt der Server sie gemäß den Zuordnungsanweisungen. Damit das Symbol abgerufen werden kann, müssen die Zuordnungsanweisungen die Übergabe der Anforderung zulassen.
Wenn Sie den Server als Proxy-Server verwenden, muss die vollständige Anforderung ein vollständig qualifizierter URL sein, der auf Ihren Server verweist. Sie müssen den URL einer lokalen Datei zuordnen und sicherstellen, dass die Zuordnungsanweisungen die Übergabe des URL zulassen.
AddIcon video_file.m.pm.gif MOV video/*
In der Konfigurationsdatei ibmproxy.conf sind mehrere Standardwerte für die Anweisung AddIcon gesetzt.
Mit dieser Anweisung können Sie ein Symbol für die Darstellung eines Elternverzeichnisses in Verzeichnislisten angeben.
AddParentIcon Symbol-URL alternativer_Text
Gibt den letzten Teil des URL für das Symbol an. Der Server hängt diesen Wert an das Verzeichnis /icons/ an, um die vollständige URL-Anforderung zu bilden. Falls sich die Anforderung auf eine lokale Datei bezieht, übersetzt der Server sie gemäß den Zuordnungsanweisungen. Damit das Symbol abgerufen werden kann, müssen die Zuordnungsanweisungen die Übergabe der Anforderung zulassen.
Wenn Sie den Server als Proxy-Server verwenden, muss die vollständige Anforderung ein vollständig qualifizierter URL sein, der auf Ihren Server verweist. Sie müssen den URL einer lokalen Datei zuordnen und sicherstellen, dass die Zuordnungsanweisungen die Übergabe des URL zulassen.
AddParentIcon parent.gif UP
AddParentIcon dir-up.gif UP
Mit dieser Anweisung können Sie Dateien mit einem bestimmten Suffix an einen MIME-Typ oder -Subtyp binden. Es können mehrere Vorkommen dieser Anweisung in der Konfigurationsdatei enthalten sein. Für die gebräuchlichsten Suffixe stellt der Server Standardwerte bereit.
AddType .Erweiterung Typ/Subtyp Codierung [Qualität[ Zeichensatz]]
Jeder andere Codierungswert wird als Binärtyp behandelt und in MIME-Headern als MIME-Header für Inhaltscodierung übergeben. Die Spezifikationen 7bit und 8bit werden nicht in MIME-Headern gesendet.
AddType .ps application/postscript 8bit 1.0 AddType *.* application/binary binary 0.3
AddType .bin application/octet-stream binary 0.8
In der Konfigurationsdatei ibmproxy.conf sind mehrere Standardwerte für die Anweisung AddType gesetzt.
Mit dieser Anweisung können Sie ein Symbol für die Darstellung von Dateien mit unbekannten Dateitypen in der Verzeichnisliste angeben.
AddUnknownIcon Symbol-URL alternativer_Text
Gibt den letzten Teil des URL für das Symbol an. Der Server hängt diesen Wert an /icons/ an, um die vollständige URL-Anforderung zu bilden. Falls sich die Anforderung auf eine lokale Datei bezieht, übersetzt der Server sie gemäß den Zuordnungsanweisungen. Damit das Symbol abgerufen werden kann, müssen die Zuordnungsanweisungen die Übergabe der Anforderung zulassen.
Wenn Sie den Server als Proxy-Server verwenden, muss die vollständige Anforderung ein vollständig qualifizierter URL sein, der auf Ihren Server verweist. Sie müssen den URL einer lokalen Datei zuordnen und sicherstellen, dass die Zuordnungsanweisungen die Übergabe des URL zulassen.
AddUnknownIcon saywhat.gif unknown
Mit dieser Anweisung können Sie einen Port angeben, den Administratoren für den Zugriff auf Statusseiten oder Konfigurationsformulare des Servers verwenden können. Anforderungen an diesen Port werden nicht zusammen mit den anderen eingehenden Anforderungen am Standard-Port oder an Ports, die mit der Anweisung Port definiert wurden, in einer Warteschlange gespeichert. Auf die Anforderungen an den Verwaltungs-Port werden jedoch dieselben Zugriffssteuerungs- und Anforderungszuordnungsregeln (z. B. Pass, Exec, Protect) angewendet.
AdminPort Port-Nummer
AdminPort 2001
AdminPort 8008
Mit dieser Anweisung können Sie festlegen, ob vom Ursprungsserver zurückgegebene Dateien, die als nicht zwischenspeicherbar gekennzeichnet sind, trotzdem im Cache gespeichert werden sollen. Dateien, die als nicht zwischenspeicherbar gekennzeichnet sind und von dieser Anweisung erfasst werden, werden mit der Angabe must revalidate (müssen überprüft werden) gekennzeichnet. Jedesmal, wenn die Datei angefordert wird, sendet der Proxy-Server eine Anforderung If-Modified-Since (Anfrage, ob die Datei in der Zwischenzeit geändert wurde) an den Ursprungsserver, damit die Antwort überprüft wird, bevor sie aus dem Cache bereitgestellt wird. Derzeit sind die einzigen durch diese Anweisung betroffenen Dateien die vom Ursprungsserver zurückgegebenen Antworten, die den Cache Header cache-control: no-cache enthalten. Sie können mehrere dieser Anweisungen definieren.
AggressiveCaching URL-Muster
AggressiveCaching http://www.hosta.com/* AggressiveCaching http://www.hostb.com/*
Aus Gründen der Abwärtskompatibilität wird die frühere Syntax dieser Anweisung ( AggressiveCaching {on | off}) jetzt wie folgt behandelt:
Keiner.
Bei Anforderungen, die einen Verzeichnisnamen, aber keinen Dateinamen enthalten, steuert die Anweisung AlwaysWelcome, ob der Server in diesem Verzeichnis nach einer Begrüßungsdatei sucht. Standardmäßig ist AlwaysWelcome auf on festgelegt. Damit sucht der Server immer im angeforderten Verzeichnis nach einer Datei, deren Name mit dem in einer Welcome-Anweisung angegebenen Namen übereinstimmt. Wenn der Server eine Übereinstimmung findet, gibt er die Datei an den Anfordernden zurück. Falls der Server in einem Verzeichnis mehrere Dateien findet, die den in Welcome-Anweisungen angegebenen Dateinamen entsprechen, bestimmt die Reihenfolge der Welcome-Anweisungen, welche Datei zurückgegeben wird. Der Server verwendet die Welcome-Anweisung verwendet, die in der Konfigurationsdatei zuerst angegeben ist.
AlwaysWelcome on | off
AlwaysWelcome on
Mit dieser Anweisung können Sie URLs angeben, für die Caching Proxy die Zeichen für Zeilenschaltung und Zeilenvorschub (CRLF, Carriage Return Line Feed) am Ende des Hauptteils einer POST-Anforderung einfügen soll. Sie können mehrere dieser Anweisungen definieren.
appendCRLFtoPost URL-Muster
appendCRLFtoPost http://www.hosta.com/
Keiner.
Mit dieser Anweisung können Sie den fernen Cache-Bereich konfigurieren, der von den Servern gemeinsam genutzt werden soll.
ArrayName Bereichsname
Keiner.
Mit dieser Anweisung können Sie eine angepasste Anwendungsfunktion angeben, die der Server während der Bearbeitung einer Anforderung im Schritt "Authentication" aufrufen soll. Dieser Code wird entsprechend dem Authentifizierungsschema ausgeführt. Es wird nur die Basisauthentifizierung unterstützt.
Authentication Schema /Pfad/Datei:Funktionsname
Authentication BASIC /ics/api/bin/icsextpgm.so:basic_authentication
Keiner.
Mit dieser Anweisung können Sie eine angepasste Anwendungsfunktion angeben, die der Server während der Bearbeitung einer Anforderung im Schritt "Authorization" aufrufen soll. Dieser Code prüft, ob das angeforderte Objekt dem Client bereitgestellt werden kann.
Authorization Anforderungsschablone /Pfad/Datei:Funktionsname
Authorization /index.html /api/bin/icsextpgm.so:auth_url
Keiner.
Mit dieser Anweisung können Sie die Cache-Aktualisierung aktivieren und inaktivieren. Wenn die Cache-Aktualisierung aktiviert ist, wird der Cache-Inhalt automatisch aktualisiert. Ist die Cache-Aktualisierung inaktiviert, wird der Cache-Agent nicht aufgerufen, und alle Einstellungen werden ignoriert. Wenn Sie den Cache-Agenten mit einer anderen Methode starten, z. B. mit einem cron-Job auf Linux- und UNIX-Systemen, setzen Sie diese Anweisung auf off (Aktualisierung inaktivieren).
AutoCacheRefresh {on | off}
AutoCacheRefresh On
Mit dieser Anweisung können Sie auf einem System mit mehreren Schnittstellenadressen (Multihomed) angeben, ob der Server eine einzige Netzadresse überwachen soll. Wenn Sie diese Anweisung auf On setzen, wird der Server an die mit der Anweisung Hostname angegebene IP-Adresse anstatt an alle lokalen IP-Adressen gebunden.
Falls Sie diese Anweisung nicht angeben, wird der Server an den Standardhostnamen gebunden.
Sollten Sie diese Anweisung ändern, müssen Sie den Server manuell stoppen und anschließend erneut starten. Der Server führt die Änderungen erst dann aus, wenn Sie ihn erneut starten. (Nähere Informationen hierzu finden Sie in Caching Proxy starten und stoppen.)
BindSpecific {on | off} [OutgoingSrcIp IP-Adresse | Hostname]
BindSpecific Off
Mit dieser Anweisung wird die Größe (in Byte) der Blöcke auf dem Datenträger der Cache-Einheit festgelegt. Der Standardwert ist 8192. Ändern Sie diesen Wert nicht, da dies die einzige unterstützte Größe ist. Nähere Informationen finden Sie im Abschnitt Befehl htcformat.
BlockSize Größe
Standardmäßig ist in der Konfigurationsdatei keine Einstellung für BlockSize enthalten. (Der Standardwert ist 8192.)
Mit dieser Anweisung können Sie den Pfad und die Datei angeben, in der der Server ein Protokoll zu den Zugriffen auf den Proxy-Cache speichern soll. Diese Anweisung ist nur zulässig, wenn der Server als Proxy-Server ausgeführt wird. Nähere Informationen finden Sie im Abschnitt CacheRefreshTime - Startzeitpunkt für Cache-Agenten angeben.
Wenn Sie die Protokollierung von Anforderungen an den Proxy-Cache aktivieren möchten, müssen Sie die Anweisung Caching auf ON setzen und Wert für die Anweisungen CacheMemory und CacheAccessLog definieren. Es können wahlweise eine oder mehrere Cache-Einheiten mit der Anweisung CacheDev definiert werden.
Der Wert von CacheAccessLog kann ein absoluter Pfad oder ein Pfad relativ zum Serverstammverzeichnis (ServerRoot) sein. (Für jeden Pfad wird ein Beispiel gezeigt.)
CacheAccessLog Pfad/Datei
CacheAccessLog /absolute/path/logfile CacheAccessLog /logs/logfile
Mit dieser Anweisung können Sie den Cache-Algorithmus angeben, den der Server für die Garbage-Collection verwenden soll.
CacheAlgorithm {bandwidth | responsetime | blend}
CacheAlgorithm bandwidth
Mit dieser Anweisung können Sie festlegen, ob der eingehende URL der Anforderung als Basis für die generierten Namen der Dateien im Cache verwendet werden soll.
Wenn Sie diese Anweisung auf on setzen, werden die Namen für die Dateien im Cache auf der Basis des eingehenden URL generiert. Wenn Sie die Anweisung auf off setzen, wird der eingehende URL zuerst an alle gültigen Plug-ins für Namensübersetzung, MAP-Regeln und PROXY-Regeln übergeben. Der daraufhin generierte URL wird dann als Basis für die Namen der Dateien im Cache verwendet.
CacheByIncomingUrl {on | off}
CacheByIncomingURL off
Mit dieser Anweisung können Sie angeben, wie lange der Server Dateien im Cache halten soll. Wenn die Garbage-Collection ausgeführt wird, löscht der Server die Dateien im Cache, die dieses Zeitlimit überschreiten, ungeachtet ihres Verfallsdatums. Wird eine Datei angefordert, die das mit dieser Anweisung festgelegte Zeitlimit überschritten hat, überprüft der Server die Datei, um sicherzustellen, dass sie gültig ist, bevor er sie zurückgibt.
CacheClean Zeitangabe
CacheClean 2 weeks
CacheClean 1 month
Mit dieser Anweisung können Sie eine Standardverfallszeit für Dateien festlegen, für die der Server keinen Header des Typs Expires oder Last-Modified bereitstellt. Geben Sie eine URL-Schablone und die Verfallszeit für die Dateien an, deren URLs mit der Schablone übereinstimmen. Es können mehrere Vorkommen dieser Anweisung in der Konfigurationsdatei enthalten sein. Fügen Sie für jede Schablone eine eigene Anweisung ein. Die URL-Schablone muss das Protokoll enthalten. Geben Sie die Zeit in einer beliebigen Kombination aus Monaten, Wochen, Tagen und Stunden an.
CacheDefaultExpiry URL-Schablone Verfallszeit
CacheDefaultExpiry ftp:* 1 day CacheDefaultExpiry gopher:* 2 days CacheDefaultExpiry http:* 0 days
Mit dieser Anweisung können Sie eine Speichereinheit für den Cache angeben. Sie können eine Datei oder eine unformatierte Plattenpartition angeben. Auf AIX-Plattformen kann ein logischer Datenträger ohne Dateisystem angegeben werden. (Wenn kein Hauptspeicher-Cache verwendet wird, erzielen Sie durch die Verwendung eines Datenträgers ohne Dateisystem für den Cache die beste Leistung.)
Cache-Einheiten müssen vorbereitet werden, bevor sie als solche festgelegt werden. Verwenden Sie den Befehl htcformat, um eine Cache-Einheit vorzubereiten. Nähere Informationen hierzu finden Sie im Abschnitt Befehl htcformat.
Es können mehrere Cache-Einheiten angegeben werden. Jeder Einheit werden dieselben Werte für CacheMemory und BlockSize zugewiesen. Jedoch belegt jede Cache-Einheit auf der Proxy-Server-Maschine einen Speicher von etwa 8 MB. Weniger, aber dafür größere Einheiten sind effektiver als eine größere Anzahl kleinerer Einheiten. Die beste Effizienz wird bei der Verwendung eines vollständigen Datenträgers als eine große Partition erreicht, die für keinen anderen Zweck vorgesehen ist. Nähere Informationen zum Cache-Speicher finden Sie im Abschnitt Die Leistung des Platten-Cache optimieren.
CacheDev {unformatierte_Plattenpartition | Datei}
AIX: CacheDev /dev/rlv02
HP-UX: CacheDev /dev/rdsk/c1t15d0
Linux: CacheDev /opt/IBMWTE/filecache1
Solaris: CacheDev /dev/rdsk/clt3d0s0
Windows: CacheDev \\.\E:
Keiner.
Mit dieser Anweisung können Sie angeben, ob der Server Dateien im Cache, deren Verfallszeit überschritten ist, zurückgeben soll. Setzen Sie den Wert auf Off, wenn der Server auch verfallene Dateien zurückgeben soll. Verwenden Sie den Standardwert On, falls der Proxy-Server bei Anforderung einer verfallenen Datei durch einen Client auf dem Ursprungsserver nach einer neueren Version der Datei suchen soll. Im Allgemeinen lehnen Administratoren die Rückgabe verfallener Dateien ab und machen nur für Demonstrationszwecke eine Ausnahme, wenn der zurückgegebene Inhalt nicht von Bedeutung ist.
CacheExpiryCheck {on | off}
CacheExpiryCheck On
Mit dieser Anweisung können Sie die maximale Größe von Dateien im Cache angeben. Dateien, deren Größe diesen Wert überschreitet, werden nicht in den Cache gestellt. Der Wert kann in Byte (B), Kilobyte (K), Megabyte (M) oder Gigabyte (G) angegeben werden. Zwischen Zahl und Maßeinheit (B, K, M, G) kann ein Leerzeichen eingefügt werden.
CacheFileSizeLimit Maximum {B | K | M | G}
CacheFileSizeLimit 4000 K
Mit dieser Anweisung können Sie den Wert angeben, der zur Berechnung der Verfallsdaten für bestimmte URLs oder für alle URLs, die mit einer Schablone übereinstimmen, verwendet werden soll.
HTTP-Server liefern für eine Datei anstelle eines Verfallsdatums häufig die Zeit der letzten Änderung (last-modified). In ähnlicher Weise können FTP-Dateien anstelle eines Verfallsdatums eine Zeitmarke für die letzte Änderung besitzen. Caching Proxy berechnet für diese Dateien auf der Basis der Zeit der letzten Änderung ein Verfallsdatum. Dabei wird der Zeitpunkt der letzten Änderung verwendet, um die Zeitspanne seit der letzten Änderung zu ermitteln, die anschließend mit dem in der Anweisung CacheLastModifiedFactor angegebenen Wert multipliziert wird. Das Ergebnis dieser Berechnung ist die Lebensdauer dieser Datei bzw. die Zeitperiode, nach deren Ablauf die Datei als veraltet gilt.
Sie können auch off oder -1 angeben, um die Anweisung zu inaktivieren und kein Verfallsdatum zu berechnen. Der Proxy-Server liest die CacheLastModifiedFactor-Anweisungen in der Reihenfolge, in der sie in der Konfigurationsdatei angegeben sind. Er verwendet die erste Anweisung, die auf die zwischengespeicherte Datei angewendet werden kann.
CacheLastModifiedFactor URL Faktor
CacheLastModifiedFactor *://hosta/* off CacheLastModifiedFactor ftp://hostb/* 0.30 CacheLastModifiedFactor ftp://* 0.25 CacheLastModifiedFactor http://* 0.10 CacheLastModifiedFactor * 0.50
CacheLastModifiedFactor http://*/ 0.10 CacheLastModifiedFactor http://*.htm* 0.20 CacheLastModifiedFactor http://*.gif 1.00 CacheLastModifiedFactor http://*.jpg 1.00 CacheLastModifiedFactor http://*.jpeg 1.00 CacheLastModifiedFactor http://*.png 1.00 CacheLastModifiedFactor http://*.tar 1.00 CacheLastModifiedFactor http://*.zip 1.00 CacheLastModifiedFactor http:* 0.15 CacheLastModifiedFactor ftp:* 0.50 CacheLastModifiedFactor * 0.10
Der Standardwert von 0,14 führt dazu, dass eine Woche zuvor geänderte Dateien nach einem Tag verfallen.
Mit dieser Anweisung können Sie festlegen, ob URLs von Hosts aus derselben Domäne wie der Proxy-Server in den Cache gestellt werden sollen. Lokale Sites in einem Intranet müssen normalerweise nicht in den Cache gestellt werden, weil die interne Bandbreite ausreicht, um die URLs schnell zu laden. Werden lokale Sites nicht in den Cache gestellt, steht für URLs, deren Abrufen längere Zeit in Anspruch nimmt, mehr Cache-Speicher zu Verfügung.
CacheLocalDomain {on | off}
CacheLocalDomain on
Wenn der Back-End-Server in der Lage ist, Inhalte für denselben URL in mehreren Sprachen zurückzugeben, können Sie diese Anweisung für die Unterstützung des Caching von Inhalten für URLs in mehreren Sprachen verwenden. Mit dieser Anweisung kann Caching Proxy die Sprachvorgabe in den Anforderungen mit der Sprache der Antworten im Cache vergleichen.
Wenn CacheMatchLanguage aktiviert ist, vergleicht Caching Proxy vor dem Laden des Inhalts aus dem Cache die Sprachvorgabe im Header Accept-Language Ihrer Anforderung mit der Sprache des Inhalts im Cache. Außerdem stellt Caching Proxy die Abweichung von der Vorgabe fest. Falls die Abweichung von der Vorgabe kleiner als der angegebene Grenzwert ist, wird die Kopie aus dem Cache zurückgegeben. Andernfalls leitet der Proxy-Server die Anforderung an den Back-End-Server weiter, um eine aktuelle Kopie in der angeforderten Sprache abzurufen.
CacheMatchLanguage {on | off} Abweichung_Sprachvorgabe Sonder-ID_für_alle_Sprachen
Das folgende Beispiel zeigt die Konfiguration der Anweisung, des Cache-Objekts und der Anforderung:
CacheMatchLanguage On 0.2
Das Cache-Objekt ist vereinfachtes Chinesisch (zh_cn), und die Anforderung ist wie folgt:
GET / HTTP/1.1 ... Accept-Language: en_US;q=1.0, zh_cn;q=0.7, ja;q=0.3 ....
In diesem Beispiel fordert der Benutzer eine Seite in Englisch (mit Code und Qualität en_US/1.0), dann in vereinfachtem Chinesisch (mit Code und Qualität zh_cn/0.7) und dann in Japanisch (mit Code und Qualität ja/0.3) an. Das Cache-Objekt liegt in vereinfachtem Chinesisch vor. Die Abweichung von der Vorgabe zwischen höchster erwarteter Qualität und gefundener Sprachqualität ist 1.0 - 0.7 = 0.3. Da in der Anweisung CacheMatchLanguage ein Grenzwert von 0.2 angegeben ist und 0.3 größer als der Grenzwert ist, fordert der Proxy-Server eine neue Kopie dieses URL vom Server an, anstatt das Cache-Objekt zurückzugeben.
Falls der Server beim Zurückgegeben der Antwort keine Sprache und auch keine Sonder-ID für alle Sprachen im Header Content-Language zurückgibt, vergleicht der Proxy-Server bei der nächsten eingehenden Anforderung die Sprachvorgabe nicht und gibt die Kopie aus dem Cache zurück.
CacheMatchLanguage off
Mit dieser Anweisung können Sie die maximale Verweildauer für Dateien im Cache festlegen. Die Lebensdauer einer Cache-Datei entspricht der Zeitdauer, während der die Datei aus dem Cache bereitgestellt wird, ohne dass der Ursprungsserver auf Aktualisierungen überprüft wird. In einigen Fällen kann die für eine Cache-Datei berechnete Lebensdauer länger sein als die gewünschte Dauer der Speicherung. Die Lebensdauer der Datei, entweder durch den Ursprungsserver vorgegeben oder von Caching Proxy berechnet, darf nicht größer sein als der mit der Anweisung CacheMaxExpiry angegebene Grenzwert.
Es können mehrere Vorkommen dieser Anweisung in der Konfigurationsdatei enthalten sein. Fügen Sie für jede Schablone eine eigene Anweisung ein.
CacheMaxExpiry URL Lebensdauer
CacheMaxExpiry ftp:* 1 month CacheMaxExpiry http://www.santaclaus.np/* 2 days 12 hours
CacheMaxExpiry 1 month
Mit dieser Anweisung können Sie die für den Cache zu reservierende Speicherkapazität festlegen. Für eine optimale Leistung der Platten-Caches wird für den Cache-Speicher ein Mindestwert von 64 MB zur Unterstützung der Cache-Infrastruktur und des Cache-Indexes empfohlen. Mit zunehmender Größe des Cache wächst auch der Cache-Index an, und es wird zusätzlicher Cache-Speicher für das Speichern des Index benötigt. Ein Cache-Speicherwert von 64 MB ist groß genug zur Unterstützung der Cache-Infrastruktur und zum Speichern eines Cache-Indexes für einen Platten-Cache mit ca. 6,4 GB. Für größere Platten-Caches sollte der Cache-Speicher 1 % der Cache-Größe betragen.
Wird ein Hauptspeicher-Cache verwendet, sollte diese Anweisung auf einen Wert gesetzt werden, der die Cache-Größe plus die für den Cache-Index benötigte Speicherkapazität umfasst.
Der empfohlene Maximalwert für diese Anweisung sind 1600 MB. Dieser Grenzwert ergibt sich aus der Tatsache, dass Caching Proxy als 32-Bit-Anwendung maximal 2 GB Speicher verwenden kann. Wenn sich der Speicherbereich, der sich aus dem Speicher für den Cache plus dem Speicher für die Routineverarbeitung ergibt, dem Grenzwert von 2 GB nähert oder diesen überschreitet, arbeitet Caching Proxy nicht mehr ordnungsgemäß.
Die Speicherkapazität kann in Byte (B), Kilobyte (K), Megabyte (M) oder Gigabyte (G) angegeben werden.
CacheMemory amount {B | K | M | G}
CacheMemory 64 M
Geben Sie mit dieser Anweisung die URLs für Dateien an, deren Verfallszeiten außer Kraft gesetzt werden sollen. Einige Sites legen als Verfallszeit von Dateien einen Zeitpunkt fest, der vor Ablauf ihrer Lebensdauer liegt, so dass der Server diese Dateien häufiger abrufen muss. Die Anweisung CacheMinHold bewirkt, dass die verfallene Datei für die angegebene Zeit im Cache gespeichert bleibt, bevor sie erneut abgerufen wird. Sie können mehrere dieser Anweisungen definieren.
CacheMinHold http://www.cachebusters.com/* 1 hour
Keiner.
Geben Sie mit dieser Anweisung an, ob der Proxy-Server Dateien von fernen Servern abruft. Bei Verwendung des Standardwerts (Off) kann der Server Dateien von fernen Servern abrufen. Bei Verwendung des Werts On wird der Server im eigenständigen Cache-Modus ausgeführt. Das bedeutet, dass der Server nur die Dateien zurückgeben kann, die sich bereits in seinem Cache befinden. Wenn der Server in diesem Modus arbeitet, sollte die Anweisung CacheExpiryCheck auf zusätzlich auf Off gesetzt werden.
Die Ausführung des Servers im eigenständigen Cache-Modus kann sinnvoll sein, wenn Sie den Server für Demonstrationszwecke verwenden. Wenn Sie sicher sind, dass im Cache alle für die Demonstration benötigten Dateien gespeichert sind, ist keine Netzverbindung erforderlich.
CacheNoConnect {on | off}
CacheNoConnect Off
Mit dieser Anweisung können Sie festlegen, dass nur die Dateien in den Cache gestellt werden sollen, deren URLs mit einer bestimmten Schablone übereinstimmen. Diese Anweisung kann in der Konfigurationsdatei mehrfach angegeben werden. Fügen Sie für jede Schablone eine eigene Anweisung ein. Die URL-Schablone muss das Protokoll enthalten. Wird für diese Anweisung kein Wert angegeben, können alle URLs im Cache gespeichert werden, die nicht durch eine NoCaching-Anweisung ausgeschlossen werden. Enthält die Konfigurationsdatei weder eine CacheOnly-Anweisung noch eine NoCaching-Anweisung, können alle URLs im Cache gespeichert werden.
CacheOnly URL-Muster
CacheOnly http://realstuff/*
Keiner.
Geben Sie mit dieser Anweisung die URLs an, für die die Antworten auf Abfragen im Cache gespeichert werden sollen. Bei Verwendung des Werts PUBLIC URL-Muster werden Antworten auf GET-Anforderungen, die ein Fragezeichen im URL enthalten, dann im Cache gespeichert, wenn der Ursprungsserver den Header cache-control: public angibt und ein Caching der Antwort möglich ist. Bei Verwendung des Werts ALWAYS URL-Muster werden Antworten auf GET-Anforderungen, die ein Fragezeichen im URL enthalten, immer im Cache gespeichert, sofern das Caching der Antworten generell möglich ist.
Sie können mehrere dieser Anweisungen definieren.
CacheQueries {ALWAYS | PUBLIC} URL-Muster
CacheQueries ALWAYS http://www.hosta.com/* CacheQueries PUBLIC http://www.hostb.com/*
Keiner.
Legen Sie mit dieser Anweisung das Zeitintervall fest, in dem auf dem Ursprungsserver überprüft werden soll, ob eine im Cache gespeicherte Datei in der Zwischenzeit geändert wurde.
Obwohl die Anweisung CacheClean eine Ähnlichkeit mit dieser Anweisung aufweist, besteht doch ein Unterschied. Die Anweisung CacheRefreshInterval legt lediglich fest, dass der Proxy-Server die Gültigkeit einer Datei überprüfen soll, bevor er sie verwendet, während die Anweisung CacheClean bewirkt, dass die Datei nach einer angegebenen Zeitperiode aus dem Cache gelöscht wird.
CacheRefreshInterval URL_Muster Zeitperiode
CacheRefreshInterval Zeitperiode
CacheRefreshInterval *.gif 8 hours CacheRefreshInterval 1 week
CacheRefreshInterval 2 weeks
Geben Sie mit dieser Anweisung den Startzeitpunkt des Cache-Agenten an. Der Cache-Agent kann zu einer bestimmten Uhrzeit gestartet werden.
CacheRefreshTime HH:MM
CacheRefreshTime 03:00
Mit der Anweisung CacheTimeMargin wird festgelegt, wie lang die Lebensdauer einer Datei mindestens sein muss, damit sie im Cache gespeichert wird.
Caching Proxy ermittelt für jede Datei eine Verfallszeit. Wenn es unwahrscheinlich ist, dass die Datei vor Ablauf ihrer Verfallszeit von einer anderen Anforderung abgerufen wird, betrachtet Caching Proxy die Lebensdauer der Datei als zu kurz für das Caching. Standardmäßig werden von Caching Proxy keine Dateien im Cache gespeichert, deren Lebensdauer kürzer ist als 10 Minuten. Sollte der Cache noch nicht nahe an seiner maximalen Kapazitätsgrenze arbeiten, verwenden Sie für diese Anweisung den Anfangswert. Ist die Kapazitätsgrenze des Cache fast erreicht, sollten Sie den Wert für die Mindestlebensdauer eventuell erhöhen.
CacheTimeMargin Mindestlebensdauer
CacheTimeMargin 10 minutes
Geben Sie mit dieser Anweisung die maximale Zeit an, während der der Server ungenutzte Dateien, die mit einer angegebenen Schablone übereinstimmen, im Cache speichern soll. Der Server löscht die ungenutzten Dateien, deren URLs mit der Schablone übereinstimmen, ungeachtet ihres Verfallsdatums nach der angegebenen Speicherzeit aus dem Cache. Sie können mehrere dieser Anweisungen in der Konfigurationsdatei definieren. Fügen Sie für jede Schablone eine eigene Anweisung ein. Die URL-Schablone muss das Protokoll enthalten. Geben Sie die Zeit in einer beliebigen Kombination aus Monaten, Wochen, Tagen und Stunden an.
CacheUnused URL-Schablone Zeitperiode
CacheUnused ftp:* 3 weeks CacheUnused gopher:* 3 days 12 hours CacheUnused * 4 weeks
CacheUnused ftp:* 3 days CacheUnused gopher:* 12 hours CacheUnused http:* 2 days
Mit dieser Anweisung können Sie das Caching für Dateien aktivieren. Wenn das Caching aktiviert ist, stellt der Proxy-Server die Dateien, die er von anderen Servern abruft, in einen lokalen Cache. Der Proxy-Server kann nachfolgende Anforderungen für dieselben Dateien aus dem Cache bedienen, ohne die Dateien von anderen Servern abrufen zu müssen.
Caching {on | off}
Caching On
Mit dieser Anweisung können Sie festlegen, wann Protokolle komprimiert werden sollen. Wenn die Protokolle älter sind als der mit CompressAge gesetzte Wert, werden sie komprimiert. Wenn CompressAge den Wert 0 hat, werden keine Protokolle komprimiert. Die Protokolle für den aktuellen Tag und den Tag davor werden nicht komprimiert.
CompressAge Anzahl_Tage
CompressAge 1
Mit dieser Anweisung können Sie einen Befehl erstellen, der das Dienstprogramm zum Komprimieren der Protokolle festlegt und Parameter an dieses Dienstprogramm übergibt. Geben Sie auch den Pfad für die archivierten Protokolle mit an.
Das Komprimierungsdienstprogramm muss in einem Verzeichnis installiert werden, das im Pfad für diese Maschine enthalten ist.
CompressCommand Befehl
CompressCommand tar -cf /logarchs/log%%DATE%%.tar %%LOGFILES%% ; gzip /logarchs/log%%DATE%%.tar CompressCommand tar -cf /logarchs/log%%DATE%%.tar %%LOGFILES%% ; compress /logarchs/log%%DATE%%.tar CompressCommand zip -q /logarchs/log%%DATE%%.zip %%LOGFILES%%
CompressCommand pkzip -q d:\logarchs\log%%DATE%%.tar %%LOGFILES%%
Keiner.
Mit dieser Anweisung können Sie angeben, wann ein komprimiertes Protokoll gelöscht werden soll. Wenn ein Protokoll älter ist als die für CompressDeleteAge angegebenen Tage, wird es gelöscht. Ist die Anweisung CompressDeleteAge auf 0 gesetzt oder ist ihr Wert niedriger als der Wert für die Anweisung CompressAge, wird ein Protokoll nicht gelöscht.
CompressDeleteAge Anzahl_Tage
CompressDeleteAge 7
Mit dieser Anweisung können Sie den Inhaltstyp der HTTP-Antwort angeben, die Sie komprimieren möchten.
Die Komprimierung der HTTP-Antwort trägt zur Senkung der Netzlast und zur Verbesserung der Leistung des Proxy-Servers bei. Wenn die Komprimierungsfilterfunktion aktiviert ist, der Browser HTTP-Komprimierung unterstützt und die HTTP-Antwort noch nicht komprimiert ist, komprimiert Caching Proxy die HTTP-Antwort und gibt den komprimierten Inhalt an den Browser zurück.
Sie können die Komprimierungsfilterfunktion aktivieren, indem Sie der Datei ibmproxy.conf die folgenden beiden Anweisungen hinzufügen:
CompressionFilterEnable /opt/ibm/edge/cp/lib/mod_z.sl CompressionFilterAddContentType type-1[,type-n]
CompressionFilterEnable /opt/ibm/edge/cp/lib/mod_z.so CompressionFilterAddContentType type-1[,type-n]
CompressionFilterEnable C:\Progra~1\IBM\edge\cp\Bin\mod_z.dll CompressionFilterAddContentType type-1[,type-n]
Die in der Anweisung CompressionFilterEnable referenzierte Bibliothek mod_z ist die dynamische Version von zlib1.1.4.
Die Variable type-n kann durch jeden gültigen Wert für den Header Content-Type ersetzt werden, z. B. text/html oder image/bmp.
Keiner.
Mit dieser Anweisung können Sie den Komprimierungsfilter aktivieren, um die HTTP-Antworten zu komprimieren, die vom Backend-Server oder aus dem Cache des Proxy-Servers stammen.
Beispiele zur Verwendung dieser Anweisung finden Sie im Abschnitt CompressionFilterAddContentType - Inhaltstyp der zu komprimierenden HTTP-Antwort angeben.
Keiner.
Mit dieser Anweisung können Sie Namen und Position einer zusätzlichen Konfigurationsdatei angeben. Die in der angegebenen Konfigurationsdatei enthaltenen Anweisungen werden im Anschluss an die aktuelle Konfigurationsdatei abgearbeitet.
Keiner.
Mit dieser Anweisung können Sie die Anzahl der Verbindungs-Threads festlegen, die für die Verwaltung von Verbindungen zu verwenden sind.
ConnThreads Anzahl
ConnThreads 5
Mit dieser Anweisung können Sie angeben, wie viel Prozent der angeforderten Datei übertragen werden müssen, damit Caching Proxy die Cache-Datei vollständig erstellen kann, selbst wenn die Clientverbindung beendet wird. Gültige Werte für diese Variable sind ganze Zahlen im Bereich von 0 - 100.
Wird beispielsweise ContinueCaching 75 angegeben, setzt Caching Proxy die Übertragung der Datei vom Inhaltsserver fort und generiert die Cache-Datei, wenn mindestens 75 % der Datei bereits übertragen wurden, bevor Caching Proxy feststellt, dass die Clientverbindung beendet wurde.
ContinueCaching Prozentsatz
ContinueCaching 75
Legen Sie mit dieser Anweisung die Informationen für den Proxy-Server fest, die erforderlich sind, damit URLs auf Inhalte gefiltert werden, die Informationen zum Bewertungsservice enthalten. Sie können mehrere dieser Anweisungen angeben.
DefinePicsRule "Filtername" {
DefinePicsRule "RSAC-Beispiel" {
Mit dieser Anweisung können Sie den Anforderungen, die mit einer Schablone übereinstimmen, eine Standardzugriffsschutzkonfiguration zuordnen.
DefProt Anforderungsschablone Zugriffsschutzkonfiguration [FOR Server-IP-Adresse | Hostname]
Der Zugriffsschutz wird jedoch bei Übereinstimmung von Anforderungen mit der Schablone noch nicht aktiviert, es sei denn, die Anforderung stimmt ebenfalls mit der Schablone einer nachfolgenden Protect-Anweisung überein. Eine Beschreibung dazu, wie die Anweisung Protect mit DefProt verwendet wird, finden Sie im Abschnitt Protect - Eine Zugriffsschutzkonfiguration für Anforderungen aktivieren, die mit einer Schablone übereinstimmen.
Sie können eine IP-Adresse angeben (z. B. FOR 240.146.167.72) oder einen Hostnamen (z. B. FOR hostA.bcd.com).
Dieser Parameter ist optional. Ohne Angabe dieses Parameters verwendet der Server die Anweisung für alle Anforderungen ungeachtet der IP-Adresse, unter der die Anforderungen ankommen, oder des Hostnamens im URL.
Für die IP-Adresse eines Servers kann kein Platzhalterzeichen verwendet werden.
DefProt /secret/* /server/protect/setup1.acc
DefProt /secret/* SECRET-PROT
DefProt { AuthType Basic ServerID restricted PasswdFile /docs/etc/WWW/restrict.password GroupFile /docs/etc/WWW/restrict.group GetMask authors PutMask authors }
DefProt /secret/* CustomerA-PROT 0.67.106.79 DefProt /secret/* CustomerB-PROT 0.83.100.45
DefProt /secret/* CustomerA-PROT hostA.bcd.com DefProt /secret/* CustomerB-PROT hostB.bcd.com
Keiner.
Geben Sie mit dieser Anweisung an, ob der Cache-Agent zwischen dem Senden von Anforderungen an die Zielserver warten soll. Durch Angabe einer Verzögerung zwischen den Anforderungen wird die Last auf der Proxy-Maschine und der Netzverbindung sowie auf den Zielservern reduziert. Wird keine Verzögerung angegeben, wird der Cache-Agent mit maximaler Geschwindigkeit ausgeführt. Bei langsamen Internet-Verbindungen empfiehlt es sich, keine Verzögerung festlegen, um das Netz maximal auszulasten.
DelayPeriod {on | off}
DelayPeriod On
Geben Sie mit dieser Anweisung an, ob der Cache-Agent hostübergreifenden Hypertext-Links folgen soll. Wenn ein zwischengespeicherter URL Links zu anderen Servern enthält, kann der Server sie entweder ignorieren oder ihnen folgen. Wird die Anweisung DelveInto auf never gesetzt, wird sie nicht angewendet.
DelveAcrossHosts {on | off}
DelveAcrossHosts Off
Geben Sie mit dieser Anweisung die Anzahl der Link-Ebenen an, denen gefolgt werden soll, wenn der Server nach Seiten sucht, die in den Cache geladen werden sollen. Ist die Anweisung DelveInto auf never gesetzt, wird sie nicht angewendet.
DelveDepth Anzahl_Link-Ebenen
DelveDepth 2
Geben Sie mit dieser Anweisung an, ob der Cache-Agent Seiten laden soll, die über Links mit den URLs im Cache verknüpft sind.
DelveInto {always | never | admin | topn}
DelveInto always
Mit dieser Anweisung können Sie für Verzeichnislisten, die vom Proxy-Server generiert werden, ein Hintergrundbild festlegen. Verzeichnislisten werden generiert, wenn mit dem Proxy-Server FTP-Sites durchsucht werden.
Geben Sie einen absoluten Pfad für das Hintergrundbild an. Befindet sich das Bild auf einem anderen Server, müssen Sie das Hintergrundbild als vollständigen URL angeben. Wird kein Hintergrundbild angegeben, wird ein einfacher weißer Hintergrund verwendet.
DirBackgroundImage /Pfad/Datei
DirBackgroundImage /images/corplogo.png DirBackgroundimage http://www.somehost.com/graphics/embossed.gif
Keiner.
Legen Sie mit dieser Anweisung fest, ob in Verzeichnislisten für Dateien, die kleiner sind als 1 KB, die exakte Bytezahl angezeigt werden soll. Bei der Angabe von Off wird für alle Dateien, die bis zu 1 KB groß sind, eine Dateigröße von 1 KB angezeigt.
DirShowBytes {on | off}
DirShowBytes Off
Legen Sie mit dieser Anweisung fest, ob beim Sortieren der Dateien in Verzeichnislisten zwischen Groß- und Kleinbuchstaben unterschieden werden soll.
Bei der Angabe von On werden Namen in Großbuchstaben in der Dateiliste vor den Namen in Kleinbuchstaben angezeigt.
DirShowCase {on | off}
DirShowCase On
Legen Sie mit dieser Anweisung fest, ob in Verzeichnislisten für jede Datei das Datum der letzten Änderung angezeigt werden soll.
DirShowDate {on | off}
DirShowDate On
Legen Sie mit dieser Anweisung fest, ob in Verzeichnislisten Beschreibungen für HTML-Dateien angezeigt werden sollen. Die Beschreibungen werden aus den HTML-Tags <title> übernommen.
Beschreibungen für FTP-Verzeichnislisten enthalten die MIME-Typen der Dateien, falls diese ermittelt werden können.
DirShowDescription {on | off}
DirShowDescription On
Legen Sie mit dieser Anweisung fest, ob in Verzeichnislisten verdeckte Dateien im Verzeichnis angezeigt werden sollen. Der Server betrachtet jede Datei, deren Name mit einem Punkt (.) beginnt, als verdeckte Datei.
DirShowHidden {on | off}
DirShowHidden On
Geben Sie mit dieser Anweisung an, ob der Server Symbole in Verzeichnislisten anzeigt. Symbole können verwendet werden, um in der Liste eine grafische Darstellung des Inhaltstyps von Dateien zu erhalten. Die Symbole selbst werden mit den Anweisungen AddBlankIcon, AddDirIcon, AddIcon, AddParentIcon und AddUnknownIcon definiert.
DirShowIcons {on | off}
DirShowIcons On
Mit dieser Anweisung können Sie die maximale Anzahl der Zeichen festlegen, die im Beschreibungsfeld von Verzeichnislisten dargestellt werden.
DirShowMaxDescrLength Anzahl_Zeichen
DirShowMaxDescrLength 25
Geben Sie mit dieser Anweisung die maximale Anzahl Zeichen an, die für Dateinamen in Verzeichnislisten verwendet werden kann.
DirShowMaxDescrLength Anzahl_Zeichen
DirShowMaxLength 25
Geben Sie mit dieser Anweisung die Mindestanzahl Zeichen an, die in Verzeichnislisten immer für Dateinamen reserviert ist. Diese Feldlänge kann durch die Dateinamen im Verzeichnis überschritten werden. Jedoch können die Dateinamen nicht länger sein, als in der Anweisung DirShowMaxLength festgelegt.
DirShowMinLength Anzahl_Zeichen
DirShowMinLength 15
Legen Sie mit dieser Anweisung fest, ob in Verzeichnislisten die Größe jeder Datei angezeigt werden soll.
DirShowSize {on | off}
DirShowSize On
Legen Sie mit dieser Anweisung fest, welche HTTP-Methoden der Server nicht akzeptiert. Geben Sie für jede Methode, die vom Server zurückgewiesen werden soll, eine separate Disable-Anweisung ein.
In der Standardkonfigurationsdatei sind die Methoden GET, HEAD, OPTIONS, POST und TRACE aktiviert und alle anderen unterstützten HTTP-Methoden inaktiviert. Um eine aktivierte Methode zu inaktivieren, löschen Sie sie aus der Anweisung Enable und fügen Sie sie zur Anweisung Disable hinzu.
Disable Methode
Disable PUT Disable DELETE Disable CONNECT
Geben Sie mit dieser Anweisung die Umgebungsvariablen an, die durch Ihre CGI-Programme nicht übernommen werden sollen (andere Variablen als die CGI-Umgebungsvariablen, die speziell für die CGI-Verarbeitung vorgesehen sind).
Standardmäßig werden durch CGI-Programme alle Umgebungsvariablen übernommen. Mit dieser Anweisung können Sie einzelne Umgebungsvariablen von der Übernahme durch GGI-Programme ausschließen.
DisInheritEnv Umgebungsvariable
DisInheritEnv PATH DisInheritEnv LANG
In diesem Beispiel werden alle Umgebungsvariablen außer PATH und LANG durch CGI-Programme übernommen.
Keiner.
Geben Sie mit dieser Anweisung an, ob der Server die Hostnamen der anfragenden Clients suchen soll.
DNS-Lookup {on | off}
Der verwendete Wert beeinflusst folgende Faktoren des Servers:
DNS-Lookup Off
Legen Sie mit dieser Anweisung fest, welche HTTP-Methoden der Server akzeptiert.
Es können alle benötigten HTTP-Methoden aktiviert werden. Geben Sie für jede Methode, die der Server akzeptieren soll, eine separate Enable-Anweisung ein.
Enable Methode
Wenn für einen bestimmten URL keine Service-Anweisung vorhanden ist, kann mit der Anweisung Enable eine angepasste Programmierung für eine HTTP-Methode erfolgen. Das mit dieser Anweisung angegebene Programm setzt die Standardverarbeitung für diese Methode außer Kraft.
Enable Methode /Pfad/DateiDLL:Funktionsname
Weitere Informationen zum Format und den verfügbaren Optionen für die Methode Enable CONNECT finden Sie im Abschnitt SSL-Tunnelung konfigurieren.
Enable GET Enable HEAD Enable POST Enable TRACE Enable OPTIONS
Mit dieser Anweisung können Sie die Socket-Option TCP NODELAY aktivieren.
Die Anweisung EnableTcpNodelay verbessert die Leistung, wenn kleine IP-Paket wie SSL-Handshake- oder HTTP-Kurzantworten zwischen Caching Proxy und dem Client übertragen werden. Die Option TCP NODELAY ist standardmäßig für alle Sockets aktiviert.
EnableTcpNodelay {All | HTTP | HTTPS | None}
EnableTcpNodelay All
Mit dieser Anweisung können Sie eine angepasste Anwendungsfunktion angeben, die der Server während des Schritts "Error" aufrufen soll. Dieser Code wird ausgeführt, um beim Auftreten eines Fehlers angepasste Fehlerroutinen bereitzustellen.
Error Anforderungsschablone /Pfad/Datei:Funktionsname
Error /index.html /ics/api/bin/icsext05.so:error_rtns
Keiner.
Mit dieser Anweisung können Sie den Pfad und den Namen der Datei angeben, in der der Server die internen Fehler protokollieren soll.
Wenn der Server aktiv ist, startet er täglich um 00:00 Uhr eine neue Protokolldatei. Andernfalls startet der Server eine neue Protokolldatei, wenn er zum ersten Mal am Tag gestartet wird. Beim Erstellen der Datei verwendet der Server den von Ihnen angegebenen Dateinamen und hängt ein Datumssuffix an. Für das Datumssuffix wird das Format TTMmmJJJJ verwendet, wobei Mmm die ersten drei Buchstaben des Monatsnamens, TT der Tag des Monats und JJJJ das Jahr sind.
ErrorLog /Pfad/logs-Verzeichnis/Dateiname
Legen Sie mit dieser Anweisung den Namen einer Datei fest, die an den anfragenden Client gesendet werden soll, wenn der Server eine bestimmte Fehlerbedingung feststellt. Die Konfigurationsdatei ibmproxy.conf enthält ErrorPage-Anweisungen, in denen den Fehlerschlüsselwörtern bestimmte Fehlernachrichtendateien zugeordnet sind.
Zur Anpassung von Fehlernachrichten können Sie die ErrorPage-Anweisungen in der Weise ändern, dass sie den Fehlerschlüsselwörtern andere Dateien zuordnen, oder aber Sie können die bereitgestellten Fehlernachrichtendateien ändern. Zum Beispiel kann eine Nachricht so geändert werden werden, dass sie mehr Informationen zur Fehlerursache und Vorschläge zur Fehlerbehebung enthält. In internen Netzen könnten Sie den Benutzern eine Kontaktperson angeben.
ErrorPage-Anweisungen können in der Konfigurationsdatei an beliebiger Stelle stehen. Tritt der Fehler auf, wird die Datei gemäß den in der Konfigurationsdatei definierten Zuordnungsregeln verarbeitet. Deshalb muss die Datei, die gesendet werden soll, an einer Position befinden, die durch die mit den Anweisungen Fail, Map, NameTrans, Pass, Redirect und Service definierten Zuordnungsregeln erreicht werden kann. Es wird mindestens eine Pass-Anweisung benötigt, damit der Server die Fehlernachrichtendatei übergeben kann.
ErrorPage Schlüsselwort /Pfad/Dateiname.html
ErrorPage scriptstart /HTML/errorpages/scriptstart.htmls
In diesem Beispiel sendet der Server, wenn die Bedingung scriptstart festgestellt wird, die Datei scriptstart.htmls, die sich im Verzeichnis /HTML/errorpages/ befindet, an den Client.
Der folgende HTML-Text ist ein Beispiel für den Inhalt einer solchen Datei:
<HTML> <HEAD> <TITLE>Nachricht für Bedingung SCRIPTSTART</TITLE> </HEAD> <BODY> Das CGI-Programm konnte nicht gestartet werden. <P> <A HREF="mailto:admin@websvr.com">Benachrichtigen Sie den Administrator</A> über dieses Problem. </BODY> </HTML>
Falls in der Konfigurationsdatei PASS /* /wwwhome/* die Anweisung ist, die mit dem Pfad oben übereinstimmt, wird als vollständiger Pfad für diese Nachrichtendatei /wwwhome/HTML/errorpages/scriptstart.htmls eingesetzt.
Jede Fehlerbedingung wird durch ein Schlüsselwort identifiziert. Bevor Sie entscheiden, welche Fehlernachrichten angepasst werden sollen, lassen Sie sich zuerst die mit Caching Proxy gelieferten Fehlernachrichtendateien, die sich im Verzeichnis /HTML/errorpages befinden, anzeigen. Die Fehlerseite enthält die Fehlernummer, die Standardnachricht, eine Erklärung der Ursache sowie eine geeignete Maßnahme zur Fehlerbehebung.
Führen Sie in diesem Fall einen der folgenden Schritte aus, um eine Fehlernachricht zu ändern:
Alle Fehlerschlüsselwörter und Standardfehlernachrichtendateien sind in der Datei ibmproxy.conf im Abschnitt zur Anweisung ErrorPage aufgelistet. Die Fehlernachrichtendateien enthalten Nummer und Schlüsselwort für die Fehlernachricht, die Standardnachricht, eine Erklärung sowie eine Benutzeraktion.
In der Datei ibmproxy.conf sind mehrere Standardwerte gesetzt.
Falls Sie eine ErrorPage-Anweisung für eine Fehlerbedingung nicht ändern, wird die für diese Bedingung festgelegte Standardfehlerseite des Servers gesendet.
Mit dieser Anweisung können Sie den Pfad und den Namen der Datei für das Ereignisprotokoll angeben. Im Ereignisprotokoll werden Informationsnachrichten über den Cache selbst aufgezeichnet.
Wenn der Server aktiv ist, startet er täglich um 00:00 Uhr eine neue Protokolldatei. Andernfalls startet der Server eine neue Protokolldatei, wenn er zum ersten Mal am Tag gestartet wird. Beim Erstellen der Datei verwendet der Server den von Ihnen angegebenen Dateinamen und hängt ein Datumssuffix an. Für das Datumssuffix wird das Format TTMmmJJJJ verwendet, wobei Mmm die ersten drei Buchstaben des Monatsnamens, TT der Tag des Monats und JJJJ das Jahr sind.
EventLog /Pfad/logs-Verzeichnis/Dateiname
Mit dieser Anweisung können Sie eine Schablone für Anforderungen festlegen, auf die mit der Ausführung eines CGI-Programms reagiert werden soll. Wenn eine Anforderung mit einer Schablone für eine Exec-Anweisung übereinstimmt, wird diese Anforderung nicht mehr mit der Anforderungsschablone nachfolgender Anweisungen verglichen.
Exec Anforderungsschablone Programmpfad [Server-IP-Adresse | Hostname]
Als Platzhalterzeichen muss sowohl in der Anforderungsschablone als auch im Programmpfad ein Stern (*) verwendet werden. Der Teil der Anforderung, der mit Anforderungsschablone übereinstimmt, muss mit dem Namen der Datei beginnen, die das CGI-Programm enthält.
Die Anforderung kann außerdem zusätzliche Daten enthalten, die an das CGI-Programm in der Umgebungsvariable PATH_INFO übergeben werden. Die zusätzlichen Daten befinden sich hinter dem ersten Schrägstrich (/), der in der Anforderung nach dem Namen der CGI-Programmdatei steht. Die Daten werden entsprechend den CGI-Spezifikationen übergeben.
Die Anweisung Exec ist rekursiv und gilt für alle Unterverzeichnisse. Für die Verzeichnisse unter cgi-bin und admin-bin ist keine separate Exec-Anweisung notwendig.
Sie können eine IP-Adresse (z. B. 240.146.167.72) oder einen Hostnamen (z. B. hostA.bcd.com) angeben.
Dieser Parameter ist optional. Ohne diesen Parameter verwendet der Server die Anweisung für alle Anforderungen ungeachtet der IP-Adresse, unter der die Anforderungen eingehen, oder des Hostnamens im URL.
Platzhalterzeichen dürfen zur Angabe von Server-IP-Adressen nicht verwendet werden.
In diesem Beispiel führt der Server beim Empfang einer Anforderung von /idd/depts/plan/c92 das CGI-Programm in /depts/bin/plan.exe aus, wobei c92 als Eingabe an das Programm übergeben wird.
Im folgenden Beispiel wird der optionale Parameter IP-Adresse verwendet. Wenn der Server Anforderungen empfängt, die mit /cgi-bin/, beantwortet er die Anforderung aus einem anderen Verzeichnis, basierend auf der IP-Adresse der Netzverbindung, in der die Anforderung empfangen wurde. Für Anforderungen, die an der Adresse 130.146.167.72 empfangen werden, verwendet der Server das Verzeichnis /CGI-BIN/customerA. Für Anforderungen, die über eine Verbindung zur Adresse 0.83.100.45 empfangen werden, verwendet der Server das Verzeichnis /CGI-BIN/customerB.
Exec /cgi-bin/* /CGI-BIN/customerA/* 130.129.167.72 Exec /cgi-bin/* /CGI-BIN/customerB/* 0.83.100.45
Im folgenden Beispiel wird der optionale Parameter Hostname verwendet. Wenn der Server Anforderungen empfängt, die mit /cgi-bin beginnen, beantwortet er die Anforderung aus einem anderen Verzeichnis, basierend auf dem Hostnamen im URL. Für Anforderungen, die für hostA.bcd.com empfangen werden, verwendet der Server das Verzeichnis /CGI-BIN/customerA. Bei für hostB.bcd.com eingehenden Anforderungen verwendet der Server das Verzeichnis /CGI-BIN/customerB.
Exec /cgi-bin/* /CGI-BIN/customerA/* hostA.bcd.com Exec /cgi-bin/* /CGI-BIN/customerB/* hostB.bcd.com
Exec /cgi-bin/* /opt/ibm/edge/cp/server_root/cgi-bin/* Exec /admin-bin/* /opt/ibm/edge/cp/server_root/admin-bin/*
Exec server_root/cgi-bin/* Exec server_root/admin-bin/* Exec server_root/DOCS/admin-bin/*
Mit dieser Anweisung können Sie den Cache-Inhalt in eine Speicherauszugsdatei exportieren. Dies ist nützlich, wenn bei einem Neustart Cache-Speicher verloren geht oder wenn derselbe Cache für mehrere Proxys implementiert wird.
ExportCacheImageTo Name_der_Exportdatei
Keiner.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Mit dieser Anweisung können Sie den Caching-Proxy-Server so konfigurieren, dass er einen IBM WebSphere Application Server (der mit einem Caching-Proxy-Adaptermodul konfiguriert ist) erkennt, von dem er dynamisch erstellte Ressourcen in den Cache abrufen kann. Caching Proxy speichert Kopien der JSP-Ergebnisse, die auch im dynamischen Cache von Application Server gespeichert sind. Caching Proxy speichert nur Inhalte eines IBM WebSphere Application Server im Cache, dessen Gruppen-ID mit einem ExternalCacheManager-Eintrag übereinstimmt.
Beachten Sie, dass Sie außerdem eine Service-Anweisung zur Konfigurationsdatei von Caching Proxy hinzufügen müssen, um diese Funktion zu aktivieren. Außerdem sind im Anwendungsserver zusätzliche Konfigurationsschritte erforderlich. Nähere Informationen finden Sie in Caching von dynamisch erstelltem Inhalt.
ExternalCacheManager ID_des_externen_Cache-Managers Maximale_Verfallszeit
Der folgende Eintrag definiert einen externen Cache-Manager (einen IBM WebSphere Application Server) in der Domäne www.xyz.com, dessen Ressourcen nach maximal 20 Sekunden verfallen.
ExternalCacheManager IBM-CP-XYZ-1 20 seconds
Keiner.
Mit dieser Anweisung können Sie für Anforderungen, die der Server nicht verarbeiten soll, eine Schablone festlegen. Wenn eine Anforderung mit einer Schablone für eine Fail-Anweisung übereinstimmt, wird diese Anforderung nicht mehr mit der Anforderungsschablone nachfolgender Anweisungen verglichen.
Fail Anforderungsschablone [Server-IP-Adresse | Hostname]
In der Schablone kann als Platzhalterzeichen der Stern verwendet werden. Für das Tilde-Zeichen (~) direkt nach dem Schrägstrich (/) muss eine exakte Übereinstimmung bestehen. Ein Platzhalterzeichen wird nicht als Übereinstimmung gewertet.
Sie können eine IP-Adresse (z. B. 240.146.167.72) oder einen Hostnamen (z. B. hostA.bcd.com) angeben.
Dieser Parameter ist optional. Ohne diesen Parameter verwendet der Server die Anweisung für alle Anforderungen ungeachtet der IP-Adresse, unter der die Anforderungen eingehen, oder des Hostnamens im URL.
Für die IP-Adresse eines Servers kann kein Platzhalterzeichen verwendet werden.
Im folgenden Beispiel weist der Server alle Anforderungen zurück, die mit /usr/local/private/ beginnen.
Fail /usr/local/private/*
Die folgenden Beispiele verwenden den optionalen Parameter IP-Adresse. Der Server weist alle Anforderungen zurück, die mit /customerB/ beginnen, wenn diese in einer Netzverbindung mit der IP-Adresse 240.146.167.72 empfangen werden. Der Server weist alle Anforderungen zurück, die mit /customerA/ beginnen, wenn diese an einer Netzverbindung mit der IP-Adresse 0.83.100.45 empfangen werden.
Fail /customerB/* 240.146.167.72 Fail /customerA/* 0.83.100.45
In den folgenden Beispielen wird der optionale Parameter Hostname verwendet. Der Server weist alle Anforderungen zurück, die mit /customerB/ beginnen, wenn diese für hostA.bcd.com empfangen werden. Der Server weist alle Anforderungen zurück, die mit /customerA/ beginnen, wenn diese für hostB.bcd.com empfangen werden.
Fail /customerB/* hostA.bcd.com Fail /customerA/* hostB.bcd.com
Keiner.
Verwenden Sie diese Anweisung, wenn Sie FIPS-konforme Verschlüsselungen für die Protokolle SSLV3 und TLS in SSL-Verbindungen aktivieren möchten. Wenn diese Anweisung definiert ist, wird die Liste der unterstützten Verschlüsselungsspezifikationen für SSLV3 (Anweisung V3CipherSpecs) ignoriert. Außerdem werden die zulässigen TLS-Verschlüsselungsspezifikationen auf 352F0AFF09FE und die SSLV3-Verschlüsselungsspezifikationen auf FFFE gesetzt.
FIPSEnable {on | off}
FIPSEnable off
Mit dieser Anweisung können Sie den Proxy-Server anweisen, die Art der Verbindung, die hergestellt werden soll, anhand der SOCKS-Konfigurationsdatei zu bestimmen.
flexibleSocks {on | off}
flexibleSocks on
Mit dieser Anweisung können Sie festlegen, dass FTP-Server für ein Verzeichnis eine Begrüßungs- oder eine beschreibende Nachricht generieren sollen. Diese Nachricht kann wahlweise als Bestandteil von FTP-Auflistungen angezeigt werden. Mit der Anweisung FTPDirInfo kann auch gesteuert werden, wo diese Nachricht angezeigt wird.
FTPDirInfo {top | bottom | off}
FTPDirInfo top
Falls Ihr Proxy-Server Teil einer Kette von Proxy-Servern ist, geben Sie mit dieser Anweisung den Namen eines anderen Proxy-Servers an, den dieser Server für FTP-Anforderungen kontaktieren soll. Sie müssen einen vollständigen URL einschließlich des nachgestellten Schrägstrichs ( /) angeben. Nähere Informationen zur Verwendung eines optionalen Domänennamens oder einer Schablone finden Sie im Abschnitt no_proxy - Schablonen für Direktverbindungen zu Domänen angeben.
Dies gilt nur für Forward-Proxy-Konfigurationen.
ftp_proxy vollständiger_URL [Domänenname_oder_Schablone]
ftp_proxy http://outer.proxy.server/
Keiner.
Mit dieser Anweisung können Sie angeben, ob die Pfadinformationen in den FTP-URLs relativ zum Arbeitsverzeichnis des angemeldeten Benutzers oder als relativ zum Stammverzeichnis interpretiert werden sollen.
FTPUrlPath {relative | absolute}
Wird die Anweisung FTPUrlPath auf absolute gesetzt, muss FTP-Arbeitsverzeichnis des angemeldeten Benutzers in den FTP-URL-Pfad aufgenommen werden. Wird FTPUrlPath Relative angegeben, darf das FTP-Arbeitsverzeichnis des angemeldeten Benutzers nicht im FTP-URL-Pfad angegeben werden. Beispielsweise müssen abhängig von der Einstellung der Anweisung FTPUrlPath folgende URL-Pfade angegeben werden, um auf die Datei test1.html im Arbeitsverzeichnis /export/home/user1 des angemeldeten Benutzers zuzugreifen:
Keiner.
Geben Sie mit dieser Anweisung an, ob die Garbage-Collection verwendet werden soll. Ist das Caching aktiviert, verwendet der Server den Prozess der Garbage-Collection zum Löschen von Dateien, die nicht mehr im Cache gespeichert werden dürfen. Die Dateien werden auf Basis ihres Verfallsdatums und anderer Werte von Proxy-Anweisungen gelöscht. Im Allgemeinen wird die Garbage-Collection durchgeführt, wenn das Caching aktiviert ist. Wird keine Garbage-Collection verwendet, wird der Proxy-Cache nicht effizient genutzt.
Gc {on | off}
Gc On
Mit dieser Anweisung können Sie eine angepasste Anwendung angeben, die der Server für die Garbage-Collection verwenden soll.
GCAdvisor /Pfad/Datei:Funktionsname
GCAdvisor /api/bin/customadvise.so:gcadv
Legen Sie mit dieser Anweisung den Prozentsatz der Gesamtkapazität des Cache fest, der erreicht werden muss, damit die Garbage-Collection ausgelöst wird. Dieser Prozentsatz wird als oberer Grenzwert bezeichnet. Dieser obere Grenzwert wird als Prozentsatz der gesamten Kapazität des Cache angegeben. Die Garbage-Collection wird so lange fortgesetzt, bis der untere Grenzwert erreicht ist. Informationen zu dieser Einstellung finden Sie im Abschnitt GcLowWater - Das Ende der Garbage-Collection festlegen. Der Prozentsatz für den oberen Grenzwert kann auf eine Zahl zwischen 50 und 95 gesetzt werden.
GcHighWater Prozentsatz
GcHighWater 90
Legen Sie mit dieser Anweisung den Prozentsatz der Gesamtkapazität des Cache fest, der erreicht werden muss, damit der Prozess der Garbage-Collection beendet wird. Dieser Prozentsatz wird als unterer Grenzwert bezeichnet. Dieser untere Grenzwert wird als Prozentsatz der gesamten Kapazität des Cache angegeben. Er muss auf einen niedrigeren Wert als der obere Grenzwert gesetzt werden. Informationen zum oberen Grenzwert enthält der Abschnitt GcHighWater - Den Beginn der Garbage-Collection festlegen.
GcLowWater Prozentsatz
GcLowWater 60
Falls Ihr Proxy-Server Teil einer Kette von Proxy-Servern ist, geben Sie mit dieser Anweisung den Namen eines anderen Proxy-Servers an, den dieser Server für Gopher-Anforderungen kontaktieren soll. Sie müssen einen vollständigen URL einschließlich des nachgestellten Schrägstrichs ( /) angeben. Nähere Informationen zur Verwendung eines optionalen Domänennamens oder einer Schablone finden Sie im Abschnitt no_proxy - Schablonen für Direktverbindungen zu Domänen angeben.
Dies gilt nur für Forward-Proxy-Konfigurationen.
gopher_proxy vollständiger_URL[Domänenname_oder_Schablone]
gopher_proxy http://outer.proxy.server/
Keiner.
Mit dieser Anweisung können Sie den Gruppennamen oder die Gruppennummern angeben, die der Server annehmen soll, bevor er auf Dateien zugreift.
Wenn Sie diese Anweisung ändern, müssen Sie den Server manuell stoppen und anschließend erneut starten, damit die Änderung wirksam wird. Die Änderung wird erst wirksam, wenn Sie den Server erneut starten. (Nähere Informationen hierzu finden Sie in Caching Proxy starten und stoppen.)
GroupId { Gruppenname | Gruppennummer}
AIX: GroupId nobody
HP-UX: GroupId other
Linux:
Solaris: GroupId nobody
Mit dieser Anweisung können Sie den Namen des Proxy-Servers angeben, der im HTTP-Header zurückgegeben wird.
HeaderServerName Name
Keiner.
Mit dieser Anweisung können Sie den Domänennamen oder eine IP-Adresse angeben, die für Dateianforderungen an die Clients zurückgegeben werden soll. Wird ein Domänenname angegeben, muss ein Domänennamensserver in der Lage sein, den Namen in eine IP-Adresse aufzulösen. Bei Angabe einer IP-Adresse wird der Domänennamensserver nicht benötigt.
Hostname {Name | IP-Adresse}
Diese Anweisung ist in der ursprünglichen Konfigurationsdatei standardmäßig nicht angegeben. Falls Sie diese Anweisung in der Konfigurationsdatei nicht angeben, wird standardmäßig der Hostname verwendet, der im Domänennamensserver definiert ist.
Falls Ihr Proxy-Server Teil einer Kette von Proxy-Servern ist, geben Sie mit dieser Anweisung den Namen eines anderen Proxy-Servers an, den dieser Server für HTTP-Anforderungen kontaktieren soll. Sie müssen einen vollständigen URL einschließlich des nachgestellten Schrägstrichs ( /) angeben. Nähere Informationen zur Verwendung eines optionalen Domänennamens oder einer Schablone finden Sie im Abschnitt no_proxy - Schablonen für Direktverbindungen zu Domänen angeben.
http_proxy vollständiger_URL[Domänenname_oder_Schablone]
http://outer.proxy.server/
Keiner.
Geben Sie mit dieser Anweisung an, ob Caching Proxy die nicht geschützte Homepage für den URL abruft und versucht, Kennsätze darin zu finden. Werden Kennsätze gefunden, werden sie auf die sichere Anforderung angewendet. Beispiel: Bei Anforderung von https://www.ibm.com/ ruft Caching Proxy den URL http://www.ibm.com/ ab, durchsucht ihn nach Kennsätzen und verwendet die gefundenen Kennsätze als Filter für https://www.ibm.com/.
Ist HTTPSCheckRoot auf off gesetzt, ruft Caching Proxy keine ungeschützten Homepage ab, um sie nach Kennsätzen zu durchsuchen.
HTTPSCheckRoot {on | off}
HTTPSCheckRoot on
Legen Sie mit dieser untergeordneten Anweisung eine IP-Adresse fest, die zum Senden und Empfangen von ICP-Abfragen verwendet wird. Die Anweisung muss in die Anweisungen <MODULEBEGIN> ICP und <MODULEEND> eingeschlossen werden.
ICP_Address IP-Adresse
Diese Anweisung ist in der ursprünglichen Konfigurationsdatei standardmäßig nicht angegeben. Falls Sie diese Anweisung in der Konfigurationsdatei nicht angeben, werden ICP-Abfragen standardmäßig akzeptiert und an jede Schnittstelle gesendet.
Legen Sie mit dieser untergeordneten Anweisung die Anzahl der Threads fest, die zum Empfangen von ICP-Abfragen generiert wurden. Die Anweisung muss in die Anweisungen <MODULEBEGIN> ICP und <MODULEEND> eingeschlossen werden.
ICP_MaxThreads Anzahl_Threads
ICP_MaxThreads 5
Ist der Proxy-Server Teil eines ICP-Cluster, geben Sie mit dieser untergeordneten Anweisung die ICP-Peers an. Die Anweisung muss in die Anweisungen <MODULEBEGIN> ICP und <MODULEEND> eingeschlossen werden.
Wird ein neuer Peer zum ICP-Cluster hinzugefügt, müssen die Informationen zum ICP-Peer zur Konfigurationsdatei aller vorhandenen Peers hinzugefügt werden. Geben Sie jeden Peer in einer separaten Zeile an. Beachten Sie, dass der aktuelle Host ebenfalls in die Peer-Liste aufgenommen werden kann. Beim Initialisieren ignoriert ICP den Eintrag des aktuellen Host. Daher können Sie eine einzelne Konfigurationsdatei verwenden und diese auf andere Peer-Maschinen kopieren, ohne dass es erforderlich wäre, diese Datei zu editieren und den aktuellen Host aus der Datei zu löschen.
ICP_Peer Hostname HTTP-Port ICP-Port
Mit der folgenden Zeile wird der Host abc.xcompany.com mit dem Proxy-Port 80 und dem ICP-Port 3128 als Peer hinzugefügt.
ICP_Peer abc.xcompany.com 80 3128
Keiner.
Legen Sie mit dieser untergeordneten Anweisung die Port-Nummer fest, an der der ICP-Server ICP-Anforderungen empfängt. Die Anweisung muss in die Anweisungen <MODULEBEGIN> ICP und <MODULEEND> eingeschlossen werden.
ICP_Port Port-Nummer
ICP_Port 3128
Legen Sie mit dieser untergeordneten Anweisung die maximale Zeit fest, während der Caching Proxy auf Antworten auf ICP-Abfragen warten soll. Die Zeit wird in Millisekunden angegeben. Die Anweisung muss in die Anweisungen <MODULEBEGIN> ICP und <MODULEEND> eingeschlossen werden.
ICP_Timeout Zeitlimit_in_Millisekunden
ICP_Timeout 2000
Mit dieser Anweisung können Sie URLs angeben, die vom Cache-Agenten nicht geladen werden sollen. Diese Anweisung ist nützlich, wenn der Cache-Agent Seiten lädt, die über Links mit den URLs im Cache verknüpft sind. Sie können die Anweisung IgnoreURL mehrfach angeben, um unterschiedliche URLs oder URL-Masken festzulegen. Der Wert für diese Anweisung kann Sterne (*) als Platzhalterzeichen enthalten und ist auf diese Weise als Maske anwendbar.
IgnoreURL URL
IgnoreURL http://www.yahoo.com/ IgnoreURL http://*.ibm.com/*
IgnoreURL */cgi-bin/*
Mit dieser Anweisung können Sie angeben, ob Server-Side Includes für Dateien, die vom Dateisystem und/oder von CGI-Programmen bereitgestellt werden, verarbeitet werden sollen. Die Verarbeitung von Server-Side Includes erfolgt für Dateien mit dem Inhaltstyp ext/x-ssi-html. Sie können wahlweise festlegen, dass die Verarbeitung von Server-Side Includes auch für Dateien mit dem Inhaltstyp text/html erfolgen soll. Nähere Informationen zu den Inhaltstypen finden Sie im Abschnitt AddType - Datentyp für Dateien mit bestimmten Suffixen angeben.
Darüber kann die Verarbeitung von Server-Side Includes auch dazu verwendet werden, Informationen dynamisch in die Datei einzufügen, die zurückgegeben wird. Dazu gehören Informationen wie das Datum, die Größe einer Datei, das Datum der letzten Änderung einer Datei, Umgebungsvariablen für CGI oder Server-Side Includes oder Textdokumente. Die Verarbeitung von Server-Side Includes wird nur für Dateien durchgeführt, die lokal erstellt wurden. Caching Proxy führt keine Verarbeitung von Server-Side Includes für Proxy- oder Cache-Objekte durch.
Bei der Verarbeitung von Server-Side Includes durchsucht der Server die Dateien jedesmal, wenn sie ihm bereitgestellt werden, auf spezielle Befehle. Dies kann die Leistung des Servers beeinflussen und die Antwortzeit gegenüber Clients erhöhen.
imbeds {on | off | files | cgi | noexec} {SSIOnly | html}
Der Server überprüft den Inhaltstyp jeder empfangenen Datei und die Ausgabe jedes abgearbeiteten CGI-Programms.
Die Verarbeitung von Server-Side Includes erfolgt normalerweise nur für Dateien mit dem Inhaltstyp text/x-ssi-html. Allerdings können Sie festlegen, dass Dateien mit dem Inhaltstyp text/html für Server-Side Includes verarbeitet werden sollen.
Jeder Suffix muss eine AddType-Anweisung mit dem richtigen Inhaltstyp besitzen. Bei Verwendung anderer Suffixe als .htm oder .html sollten Sie sicherstellen, dass eine AddType-Anweisung mit dem Inhaltstyp text/x-ssi/html definiert wurde.
imbeds on SSIOnly
Mit dieser Anweisung können Sie den Cache-Inhalt aus einer Speicherauszugsdatei importieren. Dies ist nützlich, wenn bei einem Neustart Cache-Speicher verloren geht oder wenn derselbe Cache für mehrere Proxys implementiert wird.
ImportCacheImageFrom Name_der_Importdatei
Keiner.
Mit dieser Anweisung können Sie die Umgebungsvariablen angeben, die Ihre CGI-Programme übernehmen sollen (andere Variablen als die CGI-Umgebungsvariablen, die speziell für die CGI-Verarbeitung vorgesehen sind).
Wird keine InheritEnv-Anweisung verwendet, werden durch CGI-Programme alle Umgebungsvariablen übernommen. Bei Verwendung von InheritEnv-Anweisungen werden nur die in diesen InheritEnv-Anweisungen angegebenen Umgebungsvariablen gemeinsam mit den speziellen CGI-Umgebungsvariablen übernommen. Die Anweisung ermöglicht es, den Wert übernommener Variablen wahlfrei zu initialisieren.
InheritEnv Umgebungsvariable
InheritEnv PATH InheritEnv LANG=ENUS
In diesem Beispiel werden durch CGI-Programme nur die Umgebungsvariablen PATH und LANG übernommen. Dabei wird die Umgebungsvariable LANG mit dem Wert ENUS initialisiert.
Keiner. Standardmäßig werden durch CGI-Programme alle Umgebungsvariablen übernommen.
Mit dieser Anweisung können Sie eine Zeitspanne angeben, die einem Client nach dem Aufbau einer Verbindung zum Server zugestanden wird, um eine Anforderung zu senden. Ein Client stellt zuerst die Verbindung zum Server her und sendet dann eine Anforderung. Sendet der Client innerhalb der in dieser Anweisung angegebenen Zeitspanne keine Anforderung, schließt der Server die Verbindung. Geben Sie die Zeitperiode in einer beliebigen Kombination aus Stunden, Minuten und Sekunden an.
InputTimeout Zeit
InputTimeout 3 mins 30 secs
InputTimeout 2 minutes
Diese Anweisung überschreibt die Standardaktion des Plug-in JunctionRewrite und erlaubt damit dem Proxy-Server, bestimmte URL-Links in der HTML-Seite zu korrigieren. Sie wird in Kombination mit der Anweisung JunctionRewrite verwendet.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Die Anweisung JunctionReplaceUrlPrefix weist das Plug-in JunctionRewrite an, den URL aus URL-Muster_1 durch URL-Muster_2 zu ersetzen, anstatt ein Präfix am Anfang des URL einzufügen.
JunctionReplaceUrlPrefix URL-Muster_1 URL-Muster_2
JunctionReplaceUrlPrefix /server1.internaldomain.com/* /server1/*
In diesem Beispiel wird angenommen, dass der URL /server1.internaldomain.com/notes.nsf und das Präfix /server1 ist. Anstatt das Präfix einzufügen, um den URL in /server1/server1.internaldomain.com/notes.nsf umzuschreiben, ändert das Plug-in JunctionRewrite den URL in /server1/notes.nsf.
Keiner.
Diese Anweisung aktiviert die Routine für das Umschreiben von Junctions im Caching Proxy, die die Antworten von den Ursprungsservern so umschreibt, dass URLs, die relativ zum Server angegeben werden, dem richtigen Ursprungsserver zugeordnet werden, wenn Junctions verwendet werden.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Das Plug-in für das Umschreiben von Junctions (JunctionRewrite) muss ebenfalls aktiviert sein, wenn JunctionRewrite on ohne die Option UseCookie festgelegt wird. Junctions werden durch die Proxy-Zuordnungsregeln definiert.
Nähere Informationen zu JunctionRewrite enthalten die Abschnitte UseCookie als Alternative zu JunctionRewrite und Beispiel-Plug-in Transmogrifier zur Erweiterung der Funktionalität von JunctionRewrite.
JunctionRewrite {on | on UseCookie | off}
JunctionRewrite off
Mit dieser Anweisung kann der Proxy-Server die Pfadoption im Header Set-Cookie umschreiben, wenn eine Übereinstimmung mit dem Cookie-Namen gefunden wird. Wenn die Antwort eine Junction erfordert und ein Junction-Präfix definiert ist, wird das Präfix vor jedem Pfad eingefügt. Die Anweisung kann für das Plug-in JunctionRewrite und zusammen mit der Anweisung RewriteSetCookieDomain verwendet werden.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
JunctionRewriteSetCookiePath Cookie-Name1 Cookie-Name2...
Keiner.
Diese Anweisung überschreibt die Standardaktion des Plug-in JunctionRewrite und überspringt das Umschreiben von URLs, falls eine Übereinstimmung mit dem URL-Muster gefunden wird. Die Anweisung kann für das Plug-in JunctionRewrite verwendet werden und bietet die Möglichkeit, einige URL-Links in der HTML-Seite zu korrigieren. Normalerweise wird die Anweisung verwendet, um die URLs zu überspringen, die bereits ein Präfix enthalten.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
JunctionSkipUrlPrefix URL-Muster
JunctionSkipUrlPrefix /server1/*
In diesem Beispiel wird angenommen, dass der URL /server1/notes.nsf und das Junction-Präfix /server1/ ist. Anstatt den URL in /server1/server1/notes.nsf umzuschreiben, überspringt das Plug-in JunctionRewrite das Umschreiben des URL, d. h. der URL /server1/notes.nsf wird weiterhin verwendet.
Keiner.
Verwenden Sie diese Anweisung, um eine Überflutung der Back-End-Server mit Anforderungen zu verhindern, während ein Cache-Objekt erneut validiert wird.
Wenn ein Cache-Objekt erneut mit dem Inhalt auf dem Back-End-Server validiert wird, werden Anforderungen für diese Ressource an den Back-End-Server weitergeleitet. Manchmal führt die Flut solcher Anforderungen dazu, dass der Back-End-Server abstürzt. Durch die Definition dieser Anweisung kann diese Situation vermieden werden. Wenn Sie die Anweisung definieren, wird eine verfallene oder veraltete Kopie der Ressource zurückgegeben, wenn die Ressource auf dem Proxy-Server aktualisiert wird.
KeepExpired {on | off}
KeepExpired off
Mit dieser Anweisung können Sie den Dateipfad der Schlüsselringdatenbank angeben, die der Server für SSL-Anforderungen verwendet. Schlüsselringdateien werden mit dem Schlüsselverwaltungsprogramm iKeyman generiert.
KeyRing Dateiname
Windows: KeyRing c:\Programme\IBM\edge\cp\\key.kdb
Linux und UNIX: KeyRing /etc/key.kdb
Keiner.
Mit dieser Anweisung können Sie den Dateipfad der Kennwortdatei der Schlüsselringdatenbank angeben. Die Kennwortdatei wird beim Erstellen einer Schlüsselringdatenbankdatei vom Schlüsselverwaltungsprogramm iKeyman generiert.
KeyRingStash Dateipfad
Windows: KeyRingStash c:\Programme\IBM\edge\cp\key.sth
Linux und UNIX: KeyRingStash /etc/key.sth
Keiner.
Mit dieser Anweisung können Sie die maximale Größe des Hauptteils in PUT- oder POST-Anforderungen festlegen. Die LimitRequest-Anweisungen werden dazu verwendet, den Proxy vor Attacken zu schützen.
Der Wert kann in Kilobyte (K), Megabyte (M) und Gigabyte (G) angegeben werden.
LimitRequestBody maximale_Größe_des_Hauptteils {K | M | G}
LimitRequestBody 10 M
Geben Sie mit dieser Anweisung die maximale Anzahl Header an, die in Clientanforderungen gesendet werden dürfen. Die LimitRequest-Anweisungen werden dazu verwendet, den Proxy vor Attacken zu schützen.
LimitRequestFields Anzahl_Header
LimitRequestFields 32
Legen Sie mit dieser Anweisung die maximale Länge der Anforderungszeile fest und die maximale Länge jedes Header in einer Anforderung. Die LimitRequest-Anweisungen werden dazu verwendet, den Proxy vor Attacken zu schützen.
Der Wert kann in Byte (B) und Kilobyte (K) angegeben werden.
LimitRequestFieldSize maximale_Header-Länge {B | K}
LimitRequestFieldSize 4096 B
Geben Sie mit dieser Anweisung die zulässige Anzahl der Clientverbindungen an, die sich im Empfangsrückstand (listen-Backlog) befinden dürfen, bevor der Server an die Clients eine Nachricht über die Ablehnung ihrer Verbindungsanforderungen sendet. Diese Zahl ist abhängig von der Anzahl Anforderungen, die der Server in wenigen Sekunden verarbeiten kann. Legen Sie keinen höheren Wert fest als die Zahl, die der Server verarbeiten kann, bevor das Zeitlimit für die Verbindung vom Client überschritten wird und die Verbindung abgebrochen wird.
ListenBacklog Anzahl_Anforderungen
ListenBacklog 128
Legen Sie mit dieser Anweisung fest, ob der Cache-Agent eingebettete Grafiken abrufen soll. Ist LoadInlineImages auf on gesetzt, werden Grafiken, die in einer im Cache gespeicherten Seite eingebettet sind, ebenfalls im Cache gespeichert. Ist die Anweisung auf off gesetzt, werden eingebettete Grafiken nicht im Cache gespeichert.
LoadInlineImages {on | off}
LoadInlineImages on
Mit dieser Anweisung können Sie den Cache-Agenten anweisen, das Cache-Zugriffsprotokoll der vergangenen Nacht zu lesen und die am häufigsten angeforderten URLs zu laden.
Wenn Sie für die Anweisung LoadTopCached einen Wert definieren, muss die Anweisung Caching auf On gesetzt und für die Anweisung CacheAccessLog ein Wert festgelegt sein.
LoadTopCached Anzahl_Seiten
LoadTopCached 100
Mit dieser Anweisung können Sie URLs angeben, die der Cache-Agent in den Cache laden soll. In der Konfigurationsdatei können mehrere LoadURL-Anweisungen enthalten sein, die Verwendung von Platzhalterzeichen ist jedoch nicht zulässig.
LoadURL URL
LoadURL http://www.ibm.com/
Keiner.
Mit dieser Anweisung können Sie eine angepasste Anwendungsfunktion angeben, die der Server im Schritt "Log" aufrufen soll. Dieser Code unterstützt die Protokollierung und andere Verarbeitungsfunktionen, die nach Beendigung der Verbindung ausgeführt werden.
Log Anforderungsschablone /Pfad/Datei:Funktionsname
Log /index.html /api/bin/icsextpgm.so:log_url
Keiner.
Legen Sie mit dieser Anweisung das Verhalten der Archivierungsroutine fest. Diese Anweisung gilt für alle Protokolle mit globalen Einstellungen. Sie legt fest, ob Protokolle komprimiert oder gelöscht werden sollen oder ob keine Aktion stattfinden soll.
Bei Angabe von Compress legen Sie mit den Anweisungen CompressAge und CompressDeleteAge fest, wann die Protokolle komprimiert oder gelöscht werden sollen. Geben Sie mit der Anweisung CompressCommand den Befehl und die zugehörigen Parameter an, die verwendet werden sollen.
Bei Angabe von Purge legen Sie mit den Anweisungen PurgeAge und PurgeSize fest, wann die Protokolle gelöscht werden sollen.
LogArchive {Compress | Purge | none}
LogArchive Purge
Mit dieser Anweisung können Sie das Dateiformat für die Zugriffsprotokolldateien angeben.
LogFileFormat {common | combined}
Standardmäßig werden Protokolle im NCSA Common Log Format angezeigt. Geben Sie combined an, um Protokolle stattdessen im "NCSA Combined Log Format" anzuzeigen. In diesem Format werden die Felder Referring URL, User Agent und Cookie hinzugefügt (soweit in der Anforderung vorhanden).
LogFileFormat common
Nur für Windows-Systeme: Wenn Sie den Proxy-Server in der Befehlszeile ausführen, können Sie mit dieser Anweisung die Ausgabe in das Zugriffsprotokoll umleiten. Zur Optimierung der Serverleistung ist diese Anweisung standardmäßig auf off (inaktiviert) gesetzt.
LogToGUI {on | off}
LogToGUI off
Diese Anweisung ist nur für Linux- und UNIX-Systeme gültig. Mit dieser Anweisung können Sie angeben, ob der Server Zugriffsanforderungen und Zugriffsfehler nicht nur in den Zugriffs- und den Fehlerprotokolldateien, sondern zusätzlich auch im Systemprotokoll protokollieren soll.
LogToSyslog {on | off}
Die Systemprotokolldatei muss sich auf Ihrem Server befinden, bevor Sie festlegen, dass die Fehlerprotokollinformationen in diese Datei geschrieben werden sollen. Sie können wählen, ob Zugriffs- oder Fehlerinformationen oder beide Arten von Informationen protokolliert werden sollen.
Damit nur Fehlerinformationen an das Systemprotokoll gesendet werden, fügen Sie folgende Zeile zur Datei /etc/syslog.conf hinzu:
user.err syslog-Ausgabedatei_für_Fehlerinformationen
Damit nur Zugriffsinformationen an das Systemprotokoll gesendet werden, fügen Sie folgende Zeile zur Datei /etc/syslog.conf hinzu:
user.info syslog-Infodatei_für_Zugriffsinformationen
Damit sowohl Fehler- als auch Zugriffsinformationen an das Systemprotokoll gesendet werden, fügen Sie beide Zeilen zur Datei /etc/syslog.conf hinzu:
Geben Sie die syslog-Ausgabedatei und die syslog-Infodatei im folgenden Format an:
Nachdem Sie die Systemprotokolldatei erstellt haben, können Sie sie mit dem folgenden Befehl neu starten:
kill -HUP 'cat /etc/syslog.pid'
LogToSyslog Off
Mit dieser Anweisung können Sie eine Schablone für Anforderungen angeben, die Sie in eine neue Anforderungszeichenfolge ändern möchten. Nachdem der Server die Anforderung geändert hat, gleicht er die neue Anforderungszeichenfolge mit den Anforderungsschablonen nachfolgender Anweisungen ab.
Die Anweisung Map verwendet die Pfadzeichenfolge der eingehenden Anforderung, um die Anforderung so zu ändern, dass sie der Regel entspricht. Weitere Informationen finden Sie im Abschnitt MapQuery - Anforderungen, deren Anforderungspfad und Abfragezeichenfolge der Regel entsprechen, in eine neue Anforderungszeichenfolge ändern.
Map Anforderungsschablone neue_Anforderung [Server-IP-Adresse | Hostname]
In der Schablone kann ein Stern (*) als Platzhalterzeichen verwendet werden. Für das Tilde-Zeichen (~) direkt nach dem Schrägstrich (/) muss eine exakte Übereinstimmung bestehen. Ein Platzhalterzeichen wird nicht als Übereinstimmung gewertet.
Sie können eine IP-Adresse (z. B. 240.146.167.72) oder einen Hostnamen (z. B. hostA.raleigh.ibm.com) angeben.
Dieser Parameter ist optional. Ohne diesen Parameter verwendet der Server die Anweisung für alle Anforderungen ungeachtet der IP-Adresse, unter der die Anforderungen eingehen, oder des Hostnamens im URL.
Für die IP-Adresse eines Servers kann kein Platzhalterzeichen verwendet werden.
Map /stuff/* /good/stuff/*
Map /stuff/* /customerA/good/stuff/* 240.146.167.72 Map /stuff/* /customerB/good/stuff/* 0.83.104.45
Map /stuff/* /customerA/good/stuff/* hostA.bcd.com Map /stuff/* /customerB/good/stuff/* hostB.bcd.com
Keiner.
Mit dieser Anweisung können Sie eine Schablone für Anforderungen angeben, die Sie in eine neue Anforderungszeichenfolge ändern möchten. Nachdem der Server die Anforderung geändert hat, gleicht er die neue Anforderungszeichenfolge mit den Anforderungsschablonen nachfolgender Anweisungen ab.
Die Funktionalität dieser Anweisung ist nahezu identisch mit der der Regel Map (siehe Map - Anforderungen, deren Anforderungspfadzeichenfolge der Regel entspricht, in eine neue Anforderungszeichenfolge ändern). Für die Bearbeitung eines URL mit einer Abfragezeichenfolge verwendet MapQuery den Pfad und die Abfragezeichenfolge für den Regelabgleich. Wenn der eingehende URL einer MapQuery-Regel entspricht, wird der umgesetzte URL für den Abgleich mit den restlichen Regeln verwendet.
MapQuery kann einen URL auch mit einer Abfragezeichenfolge in einen anderen URL mit einem anderen Pfad oder einer anderen Abfragezeichenfolge umsetzen. Da jedoch alle anderen Zuordnungsanweisungen nur den Anforderungspfad verwenden, wird die geänderte Abfragezeichenfolge nur an den umgesetzten URL angehängt (und nicht für den Musterabgleich verwendet), wenn der Anforderungspfad übereinstimmt.
MapQuery Anforderungsschablone neue_Anforderung [Server-IP-Adresse | Hostname]
In der Schablone kann ein Stern (*) als Platzhalterzeichen verwendet werden. Für das Tilde-Zeichen (~) direkt nach dem Schrägstrich (/) muss eine exakte Übereinstimmung bestehen. Ein Platzhalterzeichen wird nicht als Übereinstimmung gewertet.
Sie können eine IP-Adresse (z. B. 240.146.167.72) oder einen Hostnamen (z. B. hostA.raleigh.ibm.com) angeben.
Dieser Parameter ist optional. Ohne diesen Parameter verwendet der Server die Anweisung für alle Anforderungen ungeachtet der IP-Adresse, unter der die Anforderungen eingehen, oder des Hostnamens im URL.
Für die IP-Adresse eines Servers kann kein Platzhalterzeichen verwendet werden.
Angenommen, der eingehende URL lautet
/getsomthing?type=1
und die MapQuery-Regel folgendermaßen:
MapQuery /getsomething?type=* /gettype/*
Der umgesetzte URL ist dann /gettype/1 und wird in der nächsten Regelzuordnung verwendet.
Proxy /gettype/* http://server/gettype/*
Der umgesetzte URL ist http://server/gettype/1.
Keiner.
Mit dieser Anweisung können Sie die maximale Anzahl Threads festlegen, die gleichzeitig aktiv sein sollen. Wird diese Zahl erreicht, hält der Server neue Anforderungen in einer Warteschleife, bis eine andere Anforderung beendet ist und Threads verfügbar werden. Im Allgemeinen gilt: Je höher die Leistungsfähigkeit einer Maschine ist, desto größer kann der für diese Anweisung angegebene Wert sein. Wenn eine Maschine für System-Tasks, wie zum Beispiel das Auslagern von Speicher, zu viel Zeit benötigt, sollten Sie diesen Wert verkleinern.
MaxActiveThreads Anzahl_Threads
MaxActiveThreads 100
Mit dieser Anweisung können Sie die Größe des Puffers für die durch den Server generierten dynamischen Daten festlegen. Dynamische Daten werden als Ausgabe von CGI-Programmen, Server-Side Includes und API-Programmen erzeugt.
Der Wert kann in Byte (B), Kilobyte (K), Megabyte (M) oder Gigabyte (G) angegeben werden. Zwischen Zahl und Maßeinheit (B, K, M, G) kann ein Leerzeichen stehen oder nicht.
MaxContentLengthBuffer Größe
MaxContentLengthBuffer 100 K
Legen Sie mit dieser Anweisung die maximale Größe jeder Protokolldatei fest. Eine Protokolldatei darf die mit dieser Anweisung definierte Größe nicht überschreiten. Sobald eine Protokolldatei die definierte maximale Größe erreicht, wird sie geschlossen, und eine neue Protokolldatei mit demselben Namen wird erstellt. An den Namen wird die nächsthöhere ganze Zahl angehängt.
Der empfohlene Wert für die Einstellung der Anweisung MaxLogFileSize ist mindestens 10 M, aber kleiner als 200 M. Die tatsächliche Größe der Protokolldatei ist geringfügig größer als die Größe, die Sie festlegen. Die Wahl eines zu niedrigen Wertes wirkt sich auf die Leistung des Proxy-Servers aus, weil der Proxy-Server die Protokolldatei häufiger schließt und öffnet. Auf einigen Plattformen bewirkt die Wahl eines zu hohen Wertes, dass der Proxy-Server mehr Speicher für den E/A-Puffer verbraucht. Wenn die Protokolldatei größer wird, kann dies dazu führen, dass dem Proxy-Server der Speicher ausgeht oder der Eindruck entsteht, dass ein Speicherleck vorliegt, obwohl die E/A-Puffer vom Betriebssystem gesteuert werden.
Die maximale Größe kann in Byte (B), Kilobyte (K), Megabyte (M) und Gigabyte (G) angegeben werden.
MaxLogFileSize maximale_Größe {B | K | M | G}
MaxLogfileSize 128 M
Geben Sie mit dieser Anweisung die maximale Anzahl der Anforderungen an, die der Server über eine persistente Verbindung empfangen kann. Berücksichtigen Sie beim Festlegen dieses Wertes die Anzahl der Grafiken, die auf Ihren Seiten verwendet werden. Für jede Grafik ist eine eigene Anforderung erforderlich.
MaxPersistRequest Anzahl
MaxPersistRequest 5
Mit dieser Anweisung können Sie die maximale Länge für die Warteschlange des Cache-Agenten angeben, in der die anstehende Anforderungen für Seitenabfragen gespeichert werden. Bei einem großen System mit einer hohen Speicherkapazität können Sie eine größere Warteschlange für Anforderungen von Seitenabfragen definieren, ohne den gesamten verfügbaren Speicher zu belegen.
Die Warteschlange für URLs, die im Cache gespeichert werden soll, wird bei jedem Start des Cache-Agenten definiert. Wird der Cache-Agent angewiesen, den Hypertext-Links zu anderen URLs zu folgen, werden diese anderen URLs bei der Cache-Warteschlangenlänge nicht berücksichtigt. Sobald der in der Anweisung MaxURLs angegebene Wert erreicht wird, wird der Cache-Agent gestoppt, auch wenn sich in der Warteschlange noch weitere URLs befinden.
MaxQueueDepth maximale_Warteschlangenlänge
MaxQueueDepth 250
Mit dieser Anweisung können Sie festlegen, wieviel Zeit dem Cache-Agenten maximal für den Abruf von URLs zugestanden wird. Der 0 bedeutet, dass der Cache-Agent so lange ausführt wird, bis alle URLs abgerufen sind.
MaxRuntime {0 | maximale_Zeit}
MaxRuntime 2 hours 10 minutes
MaxRuntime 2 hours
Mit dieser Anweisung können Sie die maximale Anzahl offener, inaktiver Sockets angeben, die für einen Ursprungsserver verwaltet werden sollen. Diese Anweisung sollte nur verwendet werden, wenn die Anweisung ServerConnPool auf on gesetzt ist.
MaxSocketPerServer Anzahl
MaxSocketPerServer 10
MaxSocketPerServer 5
Mit dieser Anweisung können Sie die maximale Anzahl der URLs angeben, die der Cache-Agent in einem Verarbeitungsdurchlauf abrufen darf. Wenn keine Begrenzung vorgesehen ist, muss der Wert 0 eingegeben werden. Wird der Cache-Agent im Automatikmodus ausgeführt, haben die Anweisungen LoadURL und LoadTopCached Vorrang vor der Anweisung MaxURLs.
MaxURLs maximale_Anzahl
MaxURLs 2000
Mit dieser Anweisung können Sie die Member für die Bereiche angeben, die von den Servern, die den Fernzugriff auf den Cache (RCA = Remote Cache Access) verwenden, gemeinsam genutzt werden.
Member Name { untergeordnete_Anweisung untergeordnete_Anweisung . . }
Folgende untergeordnete Anweisungen sind verfügbar:
Member bittersweet.chocolate.ibm.com { RCAAddr 127.0.0.1 RCAPort 6294 CacheSize 25G Timeout 500 milliseconds BindSpecific On ReuseAddr Off }
Keiner.
Mit dieser Anweisung können Sie das Anwendungs-Plug-in angeben, das um 00:00 Uhr zur Archivierung der Protokolle ausgeführt wird. Diese Anweisung wird während der Installation initialisiert. Falls Sie diese Anweisung in der Konfigurationsdatei nicht angeben, findet keine Archivierung statt.
Midnight /Pfad/Datei:Funktionsname
Mit dieser Anweisung können Sie eine angepasste Anwendungsfunktion angeben, die der Server im Schritt "Name Translation" aufruft. Dieser Code stellt eine Methode bereit, mit der der virtuelle Pfad in der Anforderung in den physischen Pfad im Server übersetzt wird, wobei die URLs spezifischen Objekten zugeordnet werden.
NameTrans Anforderungsschablone /Pfad/Datei:Funktionsname [Server-IP-Adresse | Hostname]
Für die IP-Adresse eines Servers kann kein Platzhalterzeichen verwendet werden.
NameTrans /index.html /api/bin/icsextpgm.so:trans_url
Keiner.
Mit dieser Anweisung können Sie auf Linux- und UNIX-Plattformen verhindern, dass der Caching-Proxy-Serverprozess automatisch im Hintergrund ausgeführt wird. Diese Anweisung, die standardmäßig auf off gesetzt ist, hat folgendes Format:
NoBG [on | off]
NoBG on
NoBG off
Legen Sie mit dieser Anweisung fest, dass der Server Dateien, deren URLs mit der angegebenen Schablone übereinstimmen, nicht im Cache speichern soll. Sie können mehrere dieser Anweisungen in der Konfigurationsdatei definieren. Fügen Sie für jede Schablone eine eigene Anweisung ein. Die URL-Schablone muss das Protokoll enthalten.
Wird weder die Anweisung CacheOnly noch die Anweisung NoCaching festgelegt, wird jeder URL im Cache gespeichert.
NoCaching URL-Muster
NoCaching http://joke/*
Keiner.
Legen Sie mit dieser Anweisung fest, dass Zugriffsanforderungen von bestimmten Hosts oder Domänen, die mit einer bestimmten Schablone übereinstimmen, nicht protokolliert werden. Auf diese Weise kann zum Beispiel das Protokollieren von Zugriffsanforderungen von lokalen Hosts unterdrückt werden.
Sie können mehrere dieser Anweisungen in der Konfigurationsdatei angeben. Außerdem können mit derselben Anweisung mehrere Schablonen erfasst werden. Dazu sind diese Schablonen durch ein oder mehrere Leerzeichen voneinander zu trennen. In den Schablonen können Hostnamen oder numerische IP-Adressen verwendet werden.
NoLog {Hostname | IP-Adresse} [...]
NoLog 128.0.* *.edu localhost.*
Keiner.
Falls Sie eine der Anweisungen http_proxy, ftp_proxy oder gopher_proxy für die Kettung von Proxy-Servern verwenden, können Sie mit dieser Anweisung die Domänen angeben, zu denen der Server keine Proxy-Server-Verbindung, sondern eine Direktverbindung herstellt.
Geben Sie den Wert als Zeichenfolge von Domänennamen oder Domänennamenschablonen ein. Trennen Sie die einzelnen Einträge in der Zeichenfolge mit einem Komma (,). Fügen Sie keine Leerzeichen in die Zeichenfolge ein.
Bei dieser Anweisung werden die Schablonen auf andere Weise eingegeben als bei anderen Anweisungen. Der wichtigste Unterschied besteht darin, dass kein Platzhalterzeichen (*) verwendet werden darf. Eine Schablone kann angegeben werden, indem nur der letzte Teil eines Domänennamens eingegeben wird. Der Server stellt zu jeder Domäne, deren letzter Namensteil mit der angegebenen Schablone übereinstimmt, eine Direktverbindung her. Diese Anweisung gilt nur für die Kettung von Proxy-Servern und entspricht der Zeile @/= in der SOCKS-Konfigurationsdatei.
no_proxy Domänenname_oder_Schablone[,...]
no_proxy www.someco.com,.raleigh.ibm.com,.some.host.org:8080
In diesem Beispiel verwendet der Server für die folgenden Anforderungen keine Proxy-Verbindung:
Keiner.
Wenn eine Range-Anforderung von Browsern empfangen wird, erfordert Caching Proxy standardmäßig eine vollständige Antwort vom Backend-Server. Caching Proxy entfernt den Range-Header aus der Anforderung und leitet anschließend die Anforderung an den Backend-Server weiter. Sobald die Antwort im Proxy-Server zwischengespeichert ist, werden alle nachfolgenden Anforderungen für dieselben Ressourcen vom Proxy-Server bereitgestellt, egal ob es sich bei den Anforderungen um Range-Anforderungen handelt oder nicht. Die Standardaktion von Caching Proxy bedeutet gewöhnlich eine Leistungsverbesserung und kürzere Antwortzeiten für die Clients. Wenn die Anforderung jedoch nicht zwischengespeichert werden kann oder die Antwort sehr groß ist, beeinträchtigt die Standardaktion die Leistung.
Verwenden Sie die Anweisung NoCacheOnRange, die angibt, dass kein Caching für Range-Anforderungen verwendet werden soll, um das Problem zu beheben, das für die Verwendung der Standardkonfiguration beschrieben wurde.
Wenn Sie die Anweisung in der Datei ibmproxy.conf global oder als Option für die Zuordnungsanweisung PROXY aktivieren, leitet Caching Proxy den Range-Anforderungsheader an den Backend-Server weiter. Die Antwort vom Typ 206 (Teilinhalt) des Backend-Servers wird von Caching Proxy jedoch nicht zwischengespeichert.
Durch das Aktivieren der Anweisung NoCacheOnRange kann die Leistung des Proxy-Servers in den folgenden Fällen verbessert werden:
NoCacheOnRange [on | off]
Sie können die Anweisung NoCacheOnRange auch in einer Proxy-Zuordnungsregel aktivieren:
Proxy /not-cachable/* http://server.com/no-cachable-resources/* NoCacheOnRange
NoCacheOnRange off
Mit dieser Anweisung können Sie die Client-URL-Header angeben, die blockiert werden sollen. Jeder durch einen Client gesendete HTTP-Header kann blockiert werden, auch erforderliche Header. Gehen Sie beim Blockieren von Headern sehr sorgfältig vor. Zu den allgemeinen Headern gehören:
Einzelheiten zu diesen und anderen Headern finden Sie in der Spezifikation des HTTP-Protokolls. Sie können mehrere dieser Anweisungen angeben.
NoProxyHeader Header
NoProxyHeader Referer:
Keiner.
Mit dieser Anweisung können Sie die Anzahl der Threads angeben, die der Cache-Agent zum Abrufen von Seiten in die Warteschlange verwendet. Richten Sie sich bei der Angabe der Anzahl Threads nach der Übertragungsgeschwindigkeit Ihres internen Netzes und Ihrer Internet-Verbindung. Der gültige Bereich liegt zwischen 1 und 100.
NumClients Zahl
NumClients 4
Mit dieser Anweisung können Sie eine angepasste Anwendungsfunktion angeben, die der Server im Schritt "Object Type" aufrufen soll. Mit diesem Code wird das angeforderte Objekt im Dateisystem gesucht und sein MIME-Typ angegeben.
ObjectType Anforderungsschablone /Pfad/Datei:Funktionsname
ObjectType /index.html /api/bin/icsextpgm.so:obj_type
Keiner.
Diese Anweisung beschleunigt den Regelzuordnungsprozess für eingehende Anforderungen bei zunehmender Anzahl von Regeln.
Wenn Sie die Anweisung OptimizeRuleMapping aktivieren, gleicht der Proxy-Server die eingehenden URI-Anforderungen nicht nacheinander mit den einzelnen Regeln ab, sondern mit einer Präfixstruktur. Die Präfixstruktur hilft dem Proxy-Server, den redundanten Zeichenfolgevergleich in den Zuordnungsregeln zu vermeiden. Damit erzielt Caching Proxy eine bessere Leistung, wenn mehr als 300 Regeln in Ihrer Konfiguration enthalten sind.
OptimizeRuleMapping [on | off ]
OptimizeRuleMapping off
Mit dieser Anweisung können Sie festlegen, wie viel Zeit dem Server für das Senden der Ausgabe an einen Client zugestanden wird. Das Zeitlimit gilt für Anforderungen von lokalen Dateien und für Anforderungen, bei denen der Server als Proxy-Server agiert. Das Zeitlimit gilt nicht für Anforderungen, mit denen ein lokales CGI-Programm gestartet wird.
Sendet der Server innerhalb der in dieser Anweisung angegebenen Zeitperiode nicht die vollständige Antwort, beendet der Server die Verbindung. Geben Sie die Zeitperiode in einer beliebigen Kombination aus Stunden, Minuten und Sekunden an.
OutputTimeout Zeit
OutputTimeout 30 minutes
Mit dieser Anweisung können Sie das Verzeichnis für die PAC-Dateien (PAC = Proxy Autoconfiguration Files) angeben, die mit dem Formular für die Fernkonfiguration der PAC-Datei generiert wurden.
PacFilePath Verzeichnispfad
Legen Sie mit dieser Anweisung eine Schablone für Anforderungen fest, die akzeptiert und mit einer Datei von Ihrem Server beantwortet werden sollen. Wenn eine Anforderung mit einer Schablone einer Pass-Anweisung übereinstimmt, wird diese Anforderung nicht mehr mit den Anforderungsschablonen nachfolgender Anweisungen verglichen.
Pass Anforderungsschablone [Dateipfad [IP-Adresse_des_Servers | Hostname]]
In der Schablone kann ein Stern (*) als Platzhalterzeichen verwendet werden. Für das Tilde-Zeichen (~) direkt nach dem Schrägstrich (/) muss eine exakte Übereinstimmung bestehen. Ein Platzhalterzeichen wird nicht als Übereinstimmung gewertet.
Dieser Parameter ist optional. Falls kein Pfad angegeben wird, wird die Anforderung selbst als Pfad verwendet.
Sie können eine IP-Adresse (z. B. 240.146.167.72) oder einen Hostnamen (z. B. hostA.raleigh.ibm.com) angeben.
Dieser Parameter ist optional. Ohne diesen Parameter verwendet der Server die Anweisung für alle Anforderungen ungeachtet der IP-Adresse, unter der die Anforderungen eingehen, oder des Hostnamens im URL.
Für die IP-Adresse eines Servers kann kein Platzhalterzeichen verwendet werden.
Pass /gooddoc/*
Pass /parts/* /customerA/catalog/* 240.146.167.72 Pass /parts/* /customerB/catalog/* 0.83.100.45
Pass /Admin/* /usr/lpp/internet/server_root/Admin/* Pass /Docs/* /usr/lpp/internet/server_root/Docs/* Pass /errorpages/* /usr/lpp/internet/server_root/pub/errorpages/* Pass /* /usr/lpp/internet/server_root/pub/*
Pass /Admin/* /opt/ibm/edge/cp/server_root/Admin/* Pass /Docs/* /opt/ibm/edge/cp/server_root/Docs/* Pass /errorpages/* /opt/ibm/edge/cp/server_root/pub/errorpages/* Pass /* /opt/ibm/edge/cp/server_root/pub/*
Pass /Admin/* /usr/lpp/internet/server_root/Admin/* Pass /Docs/* /usr/lpp/internet/server_root/Docs/* Pass /errorpages/* /usr/lpp/internet/server_root/pub/errporpages/* Pass /* /usr/lpp/internet/server_root/pub/*
Pass /Admin/* /opt/ibm/edge/cp/server_root/Admin/* Pass /Docs/* /opt/ibm/edge/cp/server_root/Docs/* Pass /errorpages/* /opt/ibm/edge/cp/server_root/pub/errorpages/* Pass /* /opt/ibm/edge/cp/server_root/pub/*
Pass /icons/* C:\Programme\IBM\edge\cp\icons\* Pass /Admin/* C:\Programme\IBM\edge\cp\Admin\* Pass /Docs/* C:\Programme\IBM\edge\cp\Docs\* Pass /erropages/* C:\Programme\IBM\edge\cp\pub\errorpages\* Pass /* C:\Programme\IBM\edge\cp\pub\*
Mit dieser Anweisung können Sie angeben, wie lange der Server zwischen Clientanforderungen wartet, bevor er eine persistente Verbindung abbricht. Als Zeit kann jede gültige Zeitangabe verwendet werden, normalerweise wird die Zeit jedoch in Sekunden und Minuten angegeben.
Mit Hilfe einer anderen Zeitlimitanweisung, der Anweisung InputTimeout, bestimmt der Server, wie lange er auf die erste Clientanforderung wartet, nachdem die Verbindung hergestellt wurde. Nähere Informationen über das Zeitlimit für die Eingabe finden Sie im Abschnitt InputTimeout - Zeitlimit für Eingabe festlegen.
Nachdem der Server sein erste Antwort gesendet hat, bestimmt er anhand des mit der Anweisung PersistTimeout festgelegten Werts, wie lange er auf die nachfolgende Anforderung warten soll, bevor er die persistente Verbindung abbricht.
PersistTimeout Zeit
PersistTimeout 4 seconds
Mit dieser Anweisung können Sie eine angepasste Anwendungsfunktion angeben, die der Server aufruft, um PICS-Kennsätze für einen angegebenen URL abzurufen. Diese Funktion kann einen PICS-Kennsatz entweder dynamisch für die angeforderte Datei erstellen oder in einer alternativen Datei oder Datenbank nach einem PICS-Kennsatz suchen.
PICSDBLookup /Pfad/Datei:Funktionsname
PICSDBLookup /api/bin/icsext05.so:get_pics
Keiner.
Diese Anweisung ist nur für Linux- und UNIX-Systeme gültig. Mit dieser Anweisung können Sie die Adresse der Datei angeben, die die Prozess-ID von Caching Proxy enthält. Wenn der Serverprozess startet, zeichnet er seine Prozess-ID (PID) in einer Datei auf. Werden auf einem System mehrere Instanzen des Servers ausgeführt, muss jede Instanz eine eigene Anweisung PidFile besitzen.
PidFile Pfad_zur_PID-Dateiinformation
PidFile /usr/pidinfo
Für die Unterstützung der IBM 4960 PCI Cryptographic Accelerator Card auf AIX-Systemen werden zusätzliche Anweisungen bereitgestellt.
Verwenden Sie diese drei Anweisungen, damit der Proxy-Server den Einheitentreiber laden, die Token-Einheit öffnen und auf die auf der Einheit gespeicherten Zertifikate zugreifen kann. Wenn der Einheitentreiber geladen ist, verwendet der Proxy-Server die Einheit automatisch, um die Geschwindigkeit von SSL-Übertragen zu erhöhen.
Weitere Informationen finden Sie im Abschnitt SSLCryptoCard - Die installierte Verschlüsselungskarte angeben.
PKCS11DefaultCert Standdardzertifikatkenndatz
Geben Sie den Kennsatz des auf der Token-Einheit gespeicherten SSL-Standardzertifikats an.
PKCS11DriverPath absoluter_Pfad_des_Kartentreibers
Geben Sie den absoluten Pfad des Einheitentreibers für die Cryptographic Accelerator Card an.
PKCS11TokenPassword Kennwort
Geben Sie das Kennwort zum Öffnen der Token-Einheit an.
PKCS11DefaultCert MeinStandardZertimToken PKCS11DriverPath /usr/lib/pkcs11/PKCS11_API.so PKCS11TokenPassword MeinKennwortZumÖffnenDesToken
Keiner.
Die nachfolgend aufgeführten Anweisungen wurden zur Datei ibmproxy.conf von Caching Proxy hinzugefügt, um neue Funktionen und Plug-ins zu aktivieren. Zum Editieren der meisten Anweisungen stehen keine Konfigurations- und Verwaltungsformulare zur Verfügung. Die Anweisungen müssen in einem Standardtexteditor wie vi oder emacs editiert werden. Nähere Informationen zu jeder der folgenden neuen Anweisungen sind in diesem Kapitel in alphabetischer Reihenfolge enthalten.
In der Datei ibmproxy.conf müssen Anweisungen zum Konfigurieren von Plug-in-Modulen für Caching Proxy im folgenden Format eingegeben werden:
<MODULEBEGIN> Name des Plug-in untergeordnete_Anweisung1 untergeordnete_Anweisung2 <MODULEEND>
Jedes Plug-in-Programm führt eine Syntaxanalyse der Datei ibmproxy.conf durch und liest nur den eigenen Block mit untergeordneten Anweisungen. Der Parser von Caching Proxy ignoriert alle Einträge zwischen <MODULEBEGIN> und <MODULEEND>.
Für die Plug-in-Module von Caching Proxy und für einige neuen Funktionen müssen API-Anweisungen zur Datei ibmproxy.conf hinzugefügt werden. Weil der Proxy-Server die Plug-in-Module in der Reihenfolge verarbeitet, in der sie aufgelistet sind, müssen Sie beim Anordnen der Anweisungen in der Konfigurationsdatei des Proxy-Servers sorgfältig vorgehen. Beachten Sie, dass die prototype-Anweisungen (in Form von Kommentaren) zum API-Abschnitt der Datei ibmproxy.conf hinzugefügt wurden. Diese API-Anweisungen sind in einer zweckmäßigen Reihenfolge angeordnet. Wenn Sie API-Anweisungen hinzufügen, um neue Funktionen und Plug-in-Module zu aktivieren, sollten Sie die Anweisungen wie im Prototypabschnitt der Konfigurationsdatei gezeigt anordnen. Alternativ dazu können Sie, falls erforderlich, die Kommentarzeichen für API-Anweisungen entfernen und API-Anweisungen editieren, um die Unterstützung für jede gewünschte Funktion oder jedes gewünschte Plug-in hinzuzufügen. Plug-in-Module, die vom Benutzer erstellt wurden, müssen hinter den Plug-in-Modulen des Produkts hinzugefügt werden.
Mit dieser Anweisung können Sie die Nummer des Port angeben, an dem der Server auf Anforderungen wartet. Die Standard-Port-Nummer für HTTP ist 80. Andere Port-Nummern unter 1024 sind für andere TCP/IP-Anwendungen reserviert und dürfen nicht verwendet werden. Die für Proxy-Webserver verwendeten allgemeinen Ports sind 8080 und 8008.
Wird eine andere Port-Nummer als 80 verwendet, sind Clients erforderlich, um für Anforderungen an den Server eine spezielle Port-Nummer anzusprechen. Vor der Port-Nummer steht ein Doppelpunkt (:), und die Port-Nummer wird im URL an den Hostnamen angehängt. Beispielsweise wird bei Angabe des URL http://www.turfco.com:8008/ im Browser die Standardbegrüßungsseite des Host mit dem Namen www.turfco.com angefordert, der an Port 8008 Anforderungen empfängt.
Sie können die Option -p im Befehl ibmproxy angeben, um diese Einstellung beim Starten des Servers außer Kraft zu setzen.
Port Nummer
Wenn Sie diese Anweisung ändern, müssen Sie den Server manuell stoppen und anschließend erneut starten, damit die Änderung wirksam wird. Der Server erkennt die Änderung erst, wenn Sie ihn erneut starten. (Nähere Informationen hierzu finden Sie in Caching Proxy starten und stoppen.)
Port 80
Mit dieser Anweisung können Sie eine angepasste Anwendungsfunktion angeben, die der Server während des Schritts "PostAuth" aufrufen soll. Dieser Code wird ohne Berücksichtigung der Rückkehrcodes früherer Schritte oder anderer PostAuth-Steuerroutinen ausgeführt. Er ermöglicht die Bereinigung aller Ressourcen, die zur Verarbeitung der Anforderung zugewiesen wurden.
PostAuth /Pfad/Datei:Funktionsname
AuthExit /ics/api/bin/icsext05.so:post_exit
Keiner.
Mit dieser Anweisung können Sie eine angepasste Anwendungsfunktion angeben, die der Server während des Schritts "PostExit" aufrufen soll. Dieser Code wird ohne Berücksichtigung der Rückkehrcodes früherer Schritte oder anderer PostExit-Steuerroutinen ausgeführt. Er ermöglicht die Bereinigung aller Ressourcen, die zur Verarbeitung der Anforderung zugewiesen wurden.
PostExit /Pfad/Datei:Funktionsname
PostExit /ics/api/bin/icsext05.so:post_exit
Keiner.
Mit dieser Anweisung können Sie eine angepasste Anwendungsfunktion angeben, die der Server während des Schritts "PreExit" aufrufen soll. Dieser Code wird nach dem Lesen einer Clientanforderung, aber vor allen weiteren Verarbeitungsschritten ausgeführt. In diesem Schritt kann das Modul GoServe aufgerufen werden.
PreExit /Pfad/Datei:Funktionsname
PreExit /ics/api/bin/icsext05.so:pre_exit
Keiner.
Mit dieser Anweisung können Sie für Anforderungen, die mit einer Schablone übereinstimmen, die Zugriffsschutzkonfiguration aktivieren.
Eine Zugriffsschutzkonfiguration wird mit untergeordneten Anweisungen für den Zugriffsschutz definiert. Das Format der Anweisung Protect ist davon abhängig, ob auf einen Kennsatz oder eine Datei verwiesen werden soll, die die untergeordneten Anweisungen für Zugriffsschutz enthält, oder ob die einzelnen untergeordneten Anweisungen für Zugriffsschutz als Bestandteil der Anweisung Protect eingegeben werden sollen.
Dieser Parameter kann folgende Formate verwenden:
Protect Anforderungsschablone [Konfigurationsdatei | Kennsatz[ [FOR Server-IP-Adresse | Hostname]
Protect Anforderungsschablone [FOR Server-IP-Adresse | Hostname] untergeordnete Anweisung Wert untergeordnete Anweisung Wert . . . }
Folgende Parameter werden verwendet:
Dieser Parameter ist optional. Wird dieser Parameter weggelassen, wird die Zugriffsschutzkonfiguration aktiviert, die durch die zuletzt bearbeitete DefProt-Anweisung mit einer übereinstimmenden Schablone definiert wurde.
Beispiel:
Protect http://x.x.x.x PROT-ADMIN
In einem Webbrowser:
Beispiel:
Protect http://hostname.Beispiel.com PROT-ADMIN
In einem Webbrowser:
Sie können eine IP-Adresse (z. B. FOR 240.146.167.72) oder einen Hostnamen (z. B. FOR hostA.bcd.com ) angeben.
Platzhalterzeichen dürfen zur Angabe von Server-IP-Adressen nicht verwendet werden.
Dieser Parameter ist optional. Ohne diesen Parameter verwendet der Server die Anweisung für alle Anforderungen ungeachtet der IP-Adresse, unter der die Anforderungen eingehen, oder des Hostnamens im URL.
Diese Beispiele verwenden IP-Adressen. Wenn der Server Anforderungen empfängt, die mit /secret/ oder /topsecret/ beginnen, aktiviert er auf der Basis der IP-Adresse der Netzverbindung, in der eine Anforderung empfangen wird, die unterschiedlichen Zugriffsschutzkonfigurationen für die Anforderungen.
Protection BUS-PROT { UserID busybody GroupID webgroup AuthType Basic ServerID restricted PasswdFile /docs/WWW/restrict.pwd GroupFile /docs/WWW/restrict.grp GetMask authors PutMask authors } DefProt /secret/* /server/protect/setup1.acc Protect /secret/scoop/* Protect /secret/business/* BUS-PROT Protect /topsecret/* { AuthType Basic ServerID restricted PasswdFile /docs/WWW/restrict.pwd GroupFile /docs/WWW/restrict.grp GetMask topbrass PutMask topbrass } Pass /secret/scoop/* /WWW/restricted/* Pass /secret/business/* /WWW/confidential/* Pass /topsecret/* /WWW/topsecret/*
Protect /secret/* CustomerA-PROT FOR 0.67.106.79 Protect /secret/* CustomerB-PROT FOR 0.83.100.45 Protect /topsecret/* 0.67.106.79 { AuthType Basic ServerID restricted PasswdFile /docs/WWW/customer-A.pwd GroupFile /docs/WWW/customer-A.grp GetMask A-brass PutMask A-brass } Protect /topsecret/* 0.83.100.45 { AuthType Basic ServerID restricted PasswdFile /docs/WWW/customer-B.pwd GroupFile /docs/WWW/customer-B.grp GetMask B-brass PutMask B-brass }
Protect http://host1/* proxy-prot
Protect /secret/* CustomerA-PROT FOR hostA.bcd.com Protect /secret/* CustomerB-PROT FOR hostB.bcd.com Protect /topsecret/* hostA.bcd.com { AuthType Basic ServerID restricted PasswdFile /docs/WWW/customer-A.pwd GroupFile /docs/WWW/customer-A.grp GetMask A-brass PutMask A-brass } Protect /topsecret/* hostB.bcd.com { AuthType Basic ServerID restricted PasswdFile /docs/WWW/customer-B.pwd GroupFile /docs/WWW/customer-B.grp GetMask B-brass PutMask B-brass }
Standardmäßig wird der Zugriffsschutz für die Konfigurations- und Verwaltungsformulare durch eine Protect-Anweisung mit der Anforderungsschablone /admin-bin/* bereitgestellt.
Mit dieser Anweisung können Sie in der Konfigurationsdatei eine Zugriffsschutzkonfiguration definieren. Weisen Sie der Zugriffsschutzkonfiguration einen Namen zu und definieren Sie mit Hilfe der untergeordneten Anweisungen für den Zugriffsschutz die Art des Zugriffsschutzes.
Protection Kennsatzname { untergeordnete Anweisung Wert untergeordnete Anweisung Wert . . . }
Beschreibungen der untergeordneten Anweisungen für den Zugriffsschutz finden Sie im Abschnitt Untergeordnete Anweisungen für den Zugriffsschutz - Angeben, wie eine Gruppe von Ressourcen geschützt wird.
Protection NAME-ME { AuthType Basic ServerID restricted PasswdFile /WWW/password.pwd GroupFile /WWW/group.grp GetMask groupname PutMask groupname }
Protect /admin-bin/* { ServerId Private_Authorization AuthType Basic GetMask All@(*) PutMask All@(*) PostMask All@(*) Mask All@(*) PasswdFile /opt/ibm/edge/cp/server_root/protect/webadmin.passwd }
Nachstehend finden Sie die Beschreibungen der untergeordneten Anweisungen für den Zugriffsschutz, die in einer Zugriffsschutzkonfiguration verwendet werden können. Die untergeordneten Anweisungen werden in alphabetischer Reihenfolge aufgeführt.
Zugriffsschutzkonfigurationen können entweder in separaten Dateien definiert sein oder in der Konfigurationsdatei als Teil von DefProt-, Protect- oder Protection-Anweisungen.
Verwenden Sie diese untergeordnete Anweisung für den Zugriffsschutz, wenn der Zugriff über Benutzernamen und Kennwörter eingeschränkt werden soll. Geben Sie die Authentifizierungsart an, die zu verwenden ist, wenn der Client an den Server ein Kennwort sendet. Bei der Authentifizierungsart Grundeinstellungen (AuthType Basic) werden die Kennwörter an den Server als Textdatei gesendet. Sie werden zwar codiert, aber nicht verschlüsselt.
AuthType Basic
Verwenden Sie diese untergeordnete Anweisung für den Zugriffsschutz zur Angabe von Schablonen für die Benutzernamen, Gruppen und Adressen, die berechtigt sind, DELETE-Anforderungen für ein geschütztes Verzeichnis auszuführen.
DeleteMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
Verwenden Sie diese untergeordnete Anweisung für den Zugriffsschutz zur Angabe von Schablonen für die Benutzernamen, Gruppen und Adressen, die zu GET-Anforderungen für ein geschütztes Verzeichnis berechtigt sind.
GetMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
GetMask All@(*)
Verwenden Sie diese untergeordnete Anweisung für den Zugriffsschutz zur Angabe des Pfades und des Dateinamens der Servergruppendatei, die von dieser Zugriffsschutzkonfiguration verwendet wird. Die Gruppen, die in der Servergruppendatei definiert sind, können anschließend von folgenden Komponenten verwendet werden:
GroupFile /docs/etc/WWW/restrict.group
Verwenden Sie diese untergeordnete Anweisung zur Angabe von Schablonen für die Benutzernamen, Gruppen und Adressen, die zur Ausführung von HTTP-Anforderungen berechtigt sind, die von keiner anderen untergeordneten Anweisungen für Maskierung abgedeckt werden.
Mask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
MASK WEBADM,webadm
Verwenden Sie diese untergeordnete Anweisung für den Zugriffsschutz, wenn der Zugriff über Benutzernamen und Kennwörter eingeschränkt werden soll. Geben Sie den Pfad und den Dateinamen der Kennwortdatei an, die von dieser Zugriffsschutzkonfiguration verwendet werden soll.
Weil einige Browser Benutzer-IDs und Kennwörter im Host nach Sicherheitsbereichen (ServerID) im Cache zwischenspeichern, sollten Sie bei Angabe der Server-ID und Kennwortdateien die folgenden Richtlinien beachten:
PasswdFile /docs/etc/WWW/restrict.password
PasswdFile "c:\test this\admin.pwd"
Verwenden Sie in einem sicheren Server diese untergeordnete Anweisung für den Zugriffsschutz zur Angabe von Schablonen für die Benutzernamen, Gruppen und Adressen, die zu POST-Anforderungen für ein geschütztes Verzeichnis berechtigt sind.
PostMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
Verwenden Sie diese untergeordnete Anweisung für den Zugriffsschutz zur Angabe von Schablonen für die Benutzernamen, Gruppen und Adressen, die zu PUT-Anforderungen für ein geschütztes Verzeichnis berechtigt sind.
PutMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
Verwenden Sie diese untergeordnete Anweisung für den Zugriffsschutz, wenn der Zugriff über Benutzernamen und Kennwörter eingeschränkt werden soll. Geben Sie einen Namen an, der der Kennwortdatei, die verwendet wird, zugeordnet werden soll. Der Name muss nicht der Name einer realen Maschine sein.
Der Name wird als Kennung für den Requester verwendet. Da unterschiedliche Zugriffsschutzkonfigurationen unterschiedliche Kennwortdateien verwenden können, wird dem Client durch die Zuordnung eines Namens für die Zugriffsschutzkonfiguration die Entscheidung erleichtert, welches Kennwort er zu senden hat. Die meisten Clients zeigen diesen Namen an, während Sie die Eingabe eines Benutzernamens und eines Kennwortes anfordern.
Weil einige Browser Benutzer-IDs und Kennwörter im Host nach Sicherheitsbereichen (ServerID) im Cache zwischenspeichern, sollten Sie bei Angabe der Server-ID und Kennwortdateien die folgenden Richtlinien beachten:
ServerID restricted
Mit dieser Anweisung können Sie die Protokolle angeben, die Caching Proxy verarbeiten soll, einem Server Anforderungen zuordnen. Gültige Protokolle sind http, ftp und gopher.
Diese Proxy-Anweisung übergibt die Anforderung an einen fernen Server. Beispielsweise bewirkt die folgende Anweisung, dass alle Anforderungen an den angegebenen URL weitergeleitet werden:
Proxy /* http://Name.des.Proxy-Servers/*
Verwenden Sie für einen geschützten Reverse Proxy die folgende Anweisung:
Proxy /* https://Name.des.Proxy-Servers/*
Wenn der Proxy-Server weniger restriktiv funktionieren soll, entfernen Sie die Kommentarzeichen vor den folgenden Anweisungen in der Konfigurationsdatei. (Diese Anweisungen können allerdings ein Sicherheitsproblem verursachen, wenn der Proxy als Reverse Proxy konfiguriert ist.)
Proxy http:* Proxy ftp:* Proxy gopher:*
Optionale Parameter:
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Diese Option weist Caching Proxy an, eine Eins-zu-eins-Zuordnung zwischen dem clientseitigen Socket und dem Ausgangs-Socket zu verwalten. Diese Option ist für einige Anwendungen, z. B. verbindungsbasierte Authentifizierung, hilfreich, die den Proxy-Server benötigen, um den serverseitigen Socket aktiv zu halten und den Socket für die Anforderungen wiederzuverwenden, die von demselben clientseitigen Socket stammen.
Wenn eine Übereinstimmung mit der Proxy-Regel vorliegt, weist diese Option den Proxy-Server an, die entsprechenden Antworten nicht zwischenzuspeichern.
Wenn eine Übereinstimmung mit der Proxy-Regel vorliegt und die Anforderung einen Range-Header enthält, weist diese Option den Proxy-Server an, die entsprechenden Antworten nicht zwischenzuspeichern. Nähere Informationen hierzu finden Sie im Abschnitt NoCacheOnRange - Angeben, das für Range-Anforderungen kein Caching verwendet wird.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Verwenden Sie diese Option, wenn das Plug-in JunctionRewrite aktiviert ist. Wenn diese Option aktiviert ist, darf der Proxy-Server Antworten nicht umschreiben, wenn der eingehende URL der Regel entspricht. Nähere Informationen hierzu finden Sie in den Abschnitten Umschreiben von Junctions aktivieren (optional) und Junction mit der Option JunctionPrefix definieren (empfohlene Methode).
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Verwenden Sie diese Option, wenn das Plug-in JunctionRewrite aktiviert ist. Anstatt das Junction-Präfix aus dem ersten URL-Muster in der Proxy-Regel abzuleiten, deklariert die Option das Präfix für JunctionRewrite explizit. Nähere Informationen hierzu finden Sie in den Abschnitten Umschreiben von Junctions aktivieren (optional) und Junction mit der Option JunctionPrefix definieren (empfohlene Methode).
Proxy Anforderungsschablone Pfad_des_Zielservers [[IP]:Port] [UseSession | NoCaching | NoCacheOnRange | NoJunction | JunctionPrefix:/URL-Präfix]
Das folgende Beispiel zeigt die Verwendung der Option UseSession in der Anweisung Proxy:
Proxy /abc/* http://server1/default/abc/* :80 UseSession
Wenn die Clientanforderung an Port 80 eingeht und der URL in der Clientanforderung dem Muster /abc/* entspricht, wird der URL http://server1/default/abc/* zugeordnet.
Keiner.
Mit dieser Anweisung können Sie den Pfad und Namen der Datei angeben, in der der Server die Zugriffsstatistik für Proxy-Anforderungen protokollieren soll. Standardmäßig schreibt der Server jedes Mal einen Eintrag in dieses Protokoll geschrieben, wenn der Server für eine Clientanforderung als Proxy-Server auftritt. Sie können die Anweisung NoLog verwenden, falls Anforderungen von bestimmten Clients nicht protokolliert werden sollen.
Wenn der Server aktiv ist, startet er täglich um 00:00 Uhr eine neue Protokolldatei. Andernfalls startet der Server eine neue Protokolldatei, wenn er zum ersten Mal am Tag gestartet wird. Beim Erstellen der Datei verwendet der Server den von Ihnen angegebenen Dateinamen und hängt an diesen ein Suffix für das Datum oder eine Erweiterung an. Für das Datumssuffix oder die Erweiterung wird das Format TTMmmJJJJ verwendet, wobei Mmm die ersten drei Buchstaben des Monatsnamens, TT der Tag des Monats und JJJJ das Jahr sind.
Es ist sinnvoll, alte Protokolldateien zu löschen, weil sie viel Speicher auf dem Festplattenlaufwerk belegen können.
ProxyAccessLog Pfad/Datei
Mit dieser Anweisung können Sie eine angepasste Anwendung angeben, die der Server während des Schritts "Proxy Advisor" aufrufen soll. Dieser Code verarbeitet die Anforderung.
ProxyAdvisor /Pfad/Datei:Funktionsname
ProxyAdvisor /api/bin/customadvise.so:proxyadv
Keiner.
Verwenden Sie die Anweisung ProxyForwardLabels, um für den Proxy-Server und für den Client oder für zwei Proxy-Server in einer Proxy-Hierarchie eine PICS-Filterung zu definieren.
Wird ProxyForwardLabels auf on gesetzt, generiert der Proxy-Server HTTP-Header des Typs PICS-Label: für alle gefundenen PICS-Kennsätze, einschließlich der Kennsätze vom Ursprungsserver, Kennsätze von Kennsatzbüros, Kennsätze aus dem Kennsatz-Cache von Caching Proxy sowie Kennsätze von Plug-ins, die Kennsätze bereitstellen.
Wird ProxyForwardLabels auf Off gesetzt, werden keine HTTP-Header des Typs PICS-Label: generiert.
ProxyForwardLabels {on | off}
ProxyForwardLabels Off
Mit dieser Anweisung können Sie einen Header des Typs From: generieren. Dieser Header wird normalerweise zur Angabe der E-Mail-Adresse des Proxy-Administrators verwendet.
ProxyFrom E-Mail-Adresse
Die Einstellung ProxyFrom webmaster@proxy.ibm.com bewirkt folgende Änderungen im Header:
Original-Header | Geänderter Header |
---|---|
Location: http://www.ibm.com/ | Location: http://www.ibm.com/ |
Last Modified: Tue 5 Nov 1997 10:05:39 GMT | Last Modified: Tue 5 Nov 1997 10:05:39 GMT |
Pragma: no-cache | From: webmaster@proxy.ibm.com |
Pragma: no-cache |
Keiner.
Mit dieser Anweisung können Sie festlegen, wie der Server reagiert, wenn Benutzer im Browser die Schaltfläche Aktualisieren anklicken. Ist die Anweisung ProxyIgnoreNoCache auf on gesetzt, dann wird die Seite bei hoher Serverauslastung nicht vom Ursprungsserver angefordert, sondern eine Kopie der Datei wird aus dem Cache bereitgestellt, falls vorhanden. Der Server ignoriert im Wesentlichen den vom Browser gesendeten Header Pragma: no-cache.
ProxyIgnoreNoCache {on | off}
ProxyIgnoreNoCache off
Geben Sie mit dieser Anweisung an, ob eine persistente Verbindung zum Client bestehen soll. Eine persistente Verbindung reduziert die Wartezeit für Benutzer und verringert die CPU-Auslastung auf dem Proxy-Server. Sie erfordert jedoch eine größere Anzahl Ressourcen. Für eine persistente Verbindung sind zusätzliche Threads und folglich zusätzlicher Speicher im Proxy-Server erforderlich.
Persistente Verbindungen dürfen in einer Konfiguration mit Proxy-Servern auf mehreren Ebenen nicht verwendet werden, wenn ein Proxy-Server HTTP/1.1 nicht unterstützt.
ProxyPersistence {on | off}
ProxyPersistence on
Legen Sie mit dieser Anweisung fest, ob der Proxy die IP-Adresse des Client an den Zielserver weiterleitet.
ProxySendClientAddress {Client-IP: | OFF}
Die Anweisung ProxySendClientAddress Client-IP: bewirkt folgende Änderungen der Header:
Original-Header | Geänderter Header |
---|---|
Location: http://www.ibm.com/ | Location: http://www.ibm.com |
Last Modified: Tue 5 Nov 1997 10:05:39 GMT | Last Modified: Tue 5 Nov 1997 10:05:39 GMT |
Pragma: no-cache | Client-IP: 0.67.199.5 |
Pragma: no-cache |
Keiner.
Legen Sie mit dieser Anweisung eine Zeichenfolge für den User Agent (Benutzeragent) fest, die die vom Client gesendete Zeichenfolge ersetzt. Dadurch wird beim Besuch von Websites eine größere Anonymität erreicht. Allerdings besitzen einige Websites angepasste Seiten, die auf der Zeichenfolge User Agent basieren. Bei Verwendung der Anweisung ProxyUserAgent werden diese angepassten Seiten nicht angezeigt.
ProxyUserAgent Produktname/Version
Die Anweisung ProxyUserAgent Caching Proxy/6.1 bewirkt folgende Änderungen im Header:
Original-Header | Geänderter Header |
---|---|
Location: http://www.ibm.com/ | Location: http://www.ibm.com |
Last Modified: Tue 5 Nov 1997 10:05:39 GMT | Last Modified: Tue 5 Nov 1997 10:05:39 GMT |
User Agent: Mozilla/ 2.02 OS2 | User Agent: Caching Proxy/6.1 |
Pragma: no-cache | Pragma: no-cache |
Keiner.
Mit dieser Anweisung können Sie das Format des HTTP-Header festlegen. Für diese Anweisung gibt es vier mögliche Werte. Ist ProxyVia auf Full gesetzt, fügt Caching Proxy in die Anforderung oder in die Antwort einen Via-Header ein. Ist bereits ein Via-Header im Datenstrom vorhanden, fügt Caching Proxy die Hostdaten an das Ende des Datenstroms an. Ist diese Anweisung auf Set gesetzt, setzt Caching Proxy den Via-Header auf die Hostdaten. Ist der Via-Header bereits im Datenstrom enthalten, wird er von Caching Proxy entfernt. Wird diese Anweisung auf Pass gesetzt, werden von Caching Proxy alle Header-Daten unverändert weitergeleitet. Bei Angabe von Block für die Anweisung werden von Caching Proxy keine Via-Header weitergeleitet.
ProxyVia {Full | Set | Pass | Block}
ProxyVia Pass
ProxyVia Full
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Die Zuordnungsanweisung ProxyWAS funktioniert genauso wie die Proxy-Anweisung, legt für Caching Proxy jedoch zusätzlich fest, dass übereinstimmende Anweisungen an einen WebSphere Application Server gesendet werden. Beispiele zur Verwendung dieser Anweisung finden Sie im Abschnitt Proxy - Proxy-Protokolle oder einen Reverse Proxy angeben.
ProxyWAS Anforderungsschablone Pfad_des_Zielservers [[IP]:Port] [UseSession | NoCaching | NoCacheOnRange | NoJunction | JunctionPrefix:/URL-Präfix]
Keiner.
Geben Sie mit dieser Anweisung an, ob der Server als Proxy-Server oder als Proxy- und Inhaltsserver auftritt. Es wird empfohlen, Caching Proxy ausschließlich als Proxy-Server zu verwenden.
PureProxy {on | off}
PureProxy on
Geben Sie mit dieser Anweisung das Alter eines Protokolls in Tagen an, bei dessen Erreichen das Protokoll gelöscht wird. Ist PurgeAge auf 0 gesetzt, wird das Protokoll niemals gelöscht.
PurgeAge Zahl
PurgeAge 7
Geben Sie mit dieser Anweisung die zulässige Größe der Protokolldateien in Megabyte fest, bei deren Überschreiten das Protokollarchiv gelöscht wird. Wird die Anweisung PurgeSize auf 0 gesetzt, besteht keine Größenbeschränkung, und es werden keine Dateien gelöscht.
Die Einstellung für PurgeSize bezieht sich auf alle Protokolle einer Protokollart. Werden z. B. Fehler protokolliert (d. h., wurde in die Konfigurationsdatei ein ErrorLog-Eintrag geschrieben) und ist PurgeSize auf 10 MB gesetzt, berechnet Caching Proxy die Größen aller Fehlerprotokolle, addiert diese und löscht anschließend Protokolle, bis die Gesamtgröße aller Protokolle unter 10 MB liegt.
PurgeSize Anzahl_MB
PurgeSize 0
Mit dieser Anweisung können Sie den Namen und die Position der RCA-Konfigurationsdatei (RCA = Remote Cache Access) angeben.
RCAConfigFile /etc/Dateiname
RCAConfigFile /etc/user2rca.conf
RCAConfigFile /etc/rca.conf
Geben Sie mit dieser Anweisung die Anzahl Threads an, die an einem RCA-Port aktiv sind.
RCAThreads Anzahl_Threads
RCAThreads 50
MaxActiveThreads x [(ArraySize -1) / (2 x ArraySize -1)]
Geben Sie mit dieser Anweisung das zulässige Zeitlimit an, in dem keine Netzaktivitäten stattfinden können, ohne dass die Netzverbindung abgebrochen wird.
ReadTimeout Zeit
ReadTimeout 5 minutes
Legen Sie mit dieser Anweisung eine Schablone für Anforderungen fest, die akzeptiert und an einen anderen Server gesendet werden sollen. Wenn eine Anforderung mit einer Schablone einer Redirect-Anweisung übereinstimmt, wird diese Anforderung nicht mehr mit Schablonen anderer Anweisungen in der Konfigurationsdatei verglichen.
Redirect Anforderungsschablone URL [Server-IP-Adresse | Hostname]
In der Schablone kann ein Stern (*) als Platzhalterzeichen verwendet werden. Für das Tilde-Zeichen (~) direkt nach dem Schrägstrich (/) muss eine exakte Übereinstimmung bestehen. Ein Platzhalterzeichen wird nicht als Übereinstimmung gewertet.
URL muss die Angaben eines Protokolls enthalten sowie den Namen des Servers, an den die Anforderung gesendet werden soll. Er kann auch einen Pfad oder einen Dateinamen enthalten. Wird in der Anforderungsschablone ein Platzhalterzeichen verwendet, kann im Pfad oder Dateinamen im URL ebenfalls ein Platzhalterzeichen verwendet werden. Der Teil der Anforderung, der mit dem Platzhalter in der Anforderungsschablone übereinstimmt, wird an die Stelle des Platzhalters im URL eingesetzt.
Sie können eine IP-Adresse (z. B. 240.146.167.72) oder einen Hostnamen (z. B. hostA.bcd.com) angeben.
Dieser Parameter ist optional. Ohne diesen Parameter verwendet der Server die Anweisung für alle Anforderungen ungeachtet der IP-Adresse, unter der die Anforderungen eingehen, oder des Hostnamens im URL.
Für die IP-Adresse eines Servers kann kein Platzhalterzeichen verwendet werden.
Redirect /chief/stuff/* http://www.other.org/wahoo/*
Redirect /stuff/* http://www.chief.org/wahoo/* 240.146.167.72 Redirect /stuff/* http://www.dawg.com/pound/* 0.83.100.45
Redirect /stuff/* http://www.chief.org/wahoo/* hostA.bcd.com Redirect /stuff/* http://www.dawg.com/pound/* hostB.bcd.com
Keiner.
Verwenden Sie diese Anweisung, wenn Caching Proxy in der Lage sein soll, basierend auf dem Header Cookie mehr als eine Variante einer Ressource (URI) zu speichern.
Nähere Informationen hierzu finden Sie im Abschnitt SupportVaryHeader -- Basierend auf dem Header HTTP Vary mehr als eine Variante einer Ressource zwischenspeichern.
RegisterCacheIdTransformer Cookie Cookie-Name
Cookie-Name steht für den Namen im Header Cookie der Clientanforderung.
RegisterCacheIdTransformer Cookie Usergroup
Ein Beispiel für die Verwendung dieser Anweisung zusammen mit der Anweisung SupportVaryHeader finden Sie im Abschnitt SupportVaryHeader -- Basierend auf dem Header HTTP Vary mehr als eine Variante einer Ressource zwischenspeichern.
Keiner.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Die Zuordnungsanweisung ReversePass untersucht den Datenstrom der Serverantwort auf direkte Anforderungen, die im Rahmen einer automatischen Umadressierung umgeschrieben wurden. Wenn ein Server einen HTTP-Code der Klasse 3xx sendet (z. B. 301, d. h. permanent verschoben, oder 303, d. h. siehe andere Adresse), dann sendet der Server in der Regel eine Nachricht mit der Antwort, in der der anfordernde Client angewiesen wird, künftige Anforderungen an den richtigen URL und die richtige IP-Adresse zu senden. In einer Konfiguration mit einem Reverse Proxy kann eine Umadressierungsnachricht vom Ursprungsserver dazu führen, dass Client-Browser den Proxy-Server bei nachfolgenden Anforderungen übergehen. Um zu verhindern, dass Clients direkt mit dem Ursprungsserver kommunizieren, sollte die Anweisung ReversePass verwendet werden, mit der Anforderungen, die speziell an den Ursprungsserver gerichtet sind, abgefangen werden.
Anders als andere Zuordnungsanweisungen, die den Anforderungsdatenstrom verarbeiten, vergleicht die Anweisung ReversePass ihre Schablone mit dem Antwortdatenstrom. Der Antwortdatenstrom ist die Antwort, die der Proxy-Server vom Ursprungsserver abruft und an den Client sendet.
ReversePass umgeschriebener_URL Proxy-URL [Host:Port]
Mit der Option Host:Port kann der Proxy-Server basierend auf dem Hostnamen und Port des Back-End-Servers eine jeweils unterschiedliche ReversePass-Regel anwenden.
ReversePass http://backend.company.com:9080/* http://edge.company.com/*Port 9080 ist der Standard-Port für Application Service at the Edge. Diese Art Anforderung könnte generiert werden, wenn der ursprüngliche Anwendungsserver einen Code vom Typ 3xx an den Client zurückgegeben hat.
ReversePass http://edge.company.com:9080/* http://edge.company.com/*
Keiner.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Mit dieser Anweisung können Sie das Domänenmuster angeben, das umgeschrieben werden muss. Die Anweisung setzt die Domäne von Domänenmuster1 in Domänenmuster2 um.
RewriteSetCookieDomain Domänenmuster1 Domänenmuster2
RewriteSetCookieDomain .internal.com .external.com
Keiner.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Mit dieser Anweisung wird die RTSP-Umleitung aktiviert bzw. inaktiviert. Mögliche Optionen sind on und off.
RTSPEnable {on | off}
RTSPEnable on
Keiner.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Mit dieser Anweisung werden die RTSP-Proxy-Server angegeben, die umgeleitete Anforderungen erhalten sollen. Für verschiedene Datenstromtypen können verschiedene Server angegeben werden. Das Format der Anweisung lautet wie folgt:
rtsp_proxy_server DNS-Adresse_des_Servers[:Port] Standardrang [Liste_der_MIME-Typen]
rtsp_proxy_server rproxy.meinefirma.com:554 1 rtsp_proxy_server fw1.meinefirma.com:554 2 rtsp_proxy_server fw1.meinefirma.com:555 3 rtsp_proxy_server fw2.meinefirma.com:557 4
Keiner.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Mit dieser Anweisung wird festgelegt, wie viele Anforderungen empfangen werden sollen, bevor eine RTSP-Anfrage an einen Proxy-Server anstatt an den Ursprungsserver umgeleitet wird. RealNetworks leiten Cache-Datenströme bei der ersten Anforderung weiter, und das Caching erfordert anfangs die doppelte Bandbreite, die beim Empfang eines Datenstroms belegt wird. Wird ein Schwellenwert größer als 1 angegeben, wird verhindert, dass Anforderungen, die nur einmal gestellt werden, im Cache gespeichert werden. Das Format der Anweisung lautet wie folgt:
rtsp_proxy_threshold Anzahl_Treffer
rtsp_proxy_threshold 5
Keiner.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Mit dieser Anweisung wird die Anzahl der eindeutigen URLs angegeben, die zur Umleitung im Speicher verbleiben. Der Proxy-Server ermittelt anhand dieser Liste, ob ein bestimmter URL bereits vorgekommen ist. Umfangreiche Listen verbessern die Fähigkeit des Proxy-Servers, eine nachfolgende Anforderung an denselben Proxy-Server zu senden, der die vorherige Anforderung erhalten hat. Jeder Listeneintrag belegt jedoch etwa 16 Bytes im Speicher.
rtsp_url_list_size Größe_der_Liste
rtsp_url_list_size 8192
Keiner.
Das Abgleichverfahren unterscheidet standardmäßig zwischen Groß- und Kleinschreibung, wenn Caching Proxy Anforderungen mit den in der Datei ibmproxy.conf definierten Regeln abgleicht. Einige Anwendungs-URLs unterscheiden jedoch nicht zwischen Groß- und Kleinschreibung. Damit diese Anforderungen ordnungsgemäß bearbeitet werden, wird die Anweisung RuleCaseSense bereitgestellt. Wenn diese Anweisung auf off gesetzt ist, gleicht der Proxy-Server die Anforderungen ohne Berücksichtigung der Groß-/Kleinschreibung ab.
RuleCaseSense {on | off}
RuleCaseSense on
Mit dieser Anweisung können Sie die maximale Ausführungsdauer für ein CGI-Programm festlegen, das vom Server gestartet wird. Nach Ablauf dieser Zeit beendet der Server das Programm. Auf Linux- und UNIX-Plattformen wird hierfür das Signal KILL verwendet.
Geben Sie die Zeitspanne in einer beliebigen Kombination aus Stunden, Minuten und Sekunden an.
ScriptTimeout Zeitlimit
ScriptTimeout 5 minutes
Legen Sie mit dieser Anweisung fest, dass Anforderungen, die von Caching Proxy an einen Downstream-Server gesendet werden, das Protokoll HTTP Version 1.0 verwenden müssen. (Ein Downstream-Server ist ein anderer Proxy-Server in einer Kette von Proxy-Servern oder ein Ursprungsserver, der die Anforderung verarbeiten wird.)
Wird diese Anweisung verwendet, legt Caching Proxy das Protokoll HTTP 1.0 als Protokoll für die Anforderungen fest. In diesem Fall werden an den Downstream-Server nur Funktionen aus dem Funktionsumfang von HTTP 1.0 sowie bestimmte Funktionen von HTTP 1.1 gesendet. Zu den Letzteren gehören zum Beispiel Header zur Steuerung der Cache-Funktion (cache-control), die durch die meisten HTTP-1.0-Server unterstützt werden. Verwenden Sie diese Anweisung, falls Sie einen Downstream-Server einsetzen, der Anforderungen nach dem Protokoll HTTP 1.1 nicht ordnungsgemäß verarbeiten kann.
Wird die Anweisung SendHTTP10Outbound nicht angegeben, legt Caching Proxy für die Anforderungen das Protokoll HTTP 1.1 fest. Die Funktionalität von HTTP 1.1, z. B. persistente Verbindungen, darf in der Anforderung ebenfalls verwendet werden.
SendHTTP10Outbound URL-Muster
Diese Anweisung kann auch mehrfach angegeben werden, zum Beispiel:
SendHTTP10Outbound http://www.hosta.com/* SendHTTP10Outbound http://www.hostb.com/*
Aus Gründen der Abwärtskompatibilität wird die frühere Syntax von SendHTTP10Outbound wie folgt behandelt:
Keiner.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Bei Verwendung als Reverse Proxy empfängt Caching Proxy HTTP-Anforderungen von einem Client und sendet die Anforderungen an den Ursprungsserver. Standardmäßig schreibt Caching Proxy den Hostnamen des Ursprungsservers in den Header HOST der Anforderung, die er an den Ursprungsserver sendet. Ist die Anweisung SendRevProxyName auf "yes" gesetzt, schreibt Caching Proxy stattdessen seinen eigenen Hostnamen in den Header HOST. Diese Anweisung kann dazu verwendet werden, eine spezielle Konfiguration für Back-End-Server zu aktivieren, weil damit eine Anforderung an den Ursprungsserver immer so angezeigt wird, als würde sie vom Proxy-Server stammen, selbst dann, wenn sie von einem Back-End-Server an einen anderen umgeleitet wurde.
Diese Anweisung weicht in folgendem Punkt von der Zuordnungsanweisung ReversePass ab: Mit der Anweisung ReversePass werden Anforderungen, die eine angegebene Syntax enthalten, abgefangen und durch einen anderen Anforderungsinhalt, den Sie angeben, ersetzt. Durch die Anweisung SendRevProxyName wird lediglich der Hostname des Ursprungsservers durch den Hostnamen von Caching Proxy ersetzt. Diese Anweisung ist nicht sinnvoll bei der Konfiguration von Application Service at the Edge.
SendRevProxyName {yes | no}
Mit dieser Anweisung wird das Intervall festgelegt, in dem der Garbage-Collection-Thread ausgeführt wird und nach Serververbindungen sucht, deren Zeitlimit (das mit der Anweisung ServerConnTimeout festgelegt wird) abgelaufen ist. Diese Anweisung sollte nur verwendet werden, wenn die Anweisung ServerConnPool auf on gesetzt ist.
ServerConnGCRun Zeitintervall
ServerConnGCRun 2 minutes
ServerConnGCRun 2 minutes
Mit dieser Anweisung kann der Proxy-Server seine abgehenden Verbindungen an Ursprungsserver in einem Pool zusammenfassen. Wird diese Anweisung auf on gesetzt, verbessert sich die Leistung und die Ursprungsserver, die persistente Verbindungen zulassen, können besser genutzt werden. Sie können außerdem mit der Anweisung ServerConnTimeout festlegen, wie lange eine nicht verwendete Verbindung beibehalten werden soll.
ServerConnPool {on | off}
ServerConnPool off
Mit dieser Anweisung können Sie das Zeitlimit für Netzinaktivität festlegen, nach dessen Ablauf die Netzverbindung abgebrochen wird. Diese Anweisung sollte nur verwendet werden, wenn die Anweisung ServerConnPool auf on gesetzt ist.
ServerConnTimeout Zeitangabe
ServerConnTimeout 30 seconds
ServerConnTimeout 10 seconds
Mit dieser Anweisung können Sie eine angepasste Anwendungsfunktion angeben, die der Server während der Ausführung der Initialisierungsroutinen aufrufen soll. Dieser Code wird vor dem Lesen einer Clientanforderung und nach jedem Neustart des Servers ausgeführt.
Werden die GoServe-Module in den Schritten "PreExit" oder "Service" verwendet, muss das Modul gosclone an dieser Stelle aufgerufen werden.
ServerInit /Pfad/Datei:Funktionsname [Initialisierungszeichenfolge]
ServerInit /ics/api/bin/icsext05.so:svr_init
Keiner.
Mit dieser Anweisung können Sie das Verzeichnis angeben, in dem das Serverprogramm installiert ist (das aktuelle Arbeitsverzeichnis des Servers). Die Protokollierungsanweisungen verwenden das aktuelle Arbeitsverzeichnis als Standardstammverzeichnis, wenn relative Pfadnamen verwendet werden.
Auf Windows-Systemen wird das Verzeichnis während der Installation angegeben.
ServerRoot Verzeichnispfad
Mit dieser Anweisung können Sie eine angepasste Anwendungsfunktion angeben, die der Server im Schritt "Server Termination" aufrufen soll. Dieser Code wird beim ordnungsgemäßen Beenden und bei jedem Neustart des Servers ausgeführt. Er ermöglicht die Freigabe der Ressourcen, die durch eine PreExit-Anwendungsfunktion zugewiesen wurden.
ServerTerm /Pfad/Datei:Funktionsname
ServerTerm /ics/api/bin/icsext05.so:shut_down
Keiner.
Mit dieser Anweisung können Sie eine angepasste Anwendungsfunktion angeben, die der Server im Schritt "Service" aufrufen soll. Dieser Code bearbeitet die Clientanforderung. Er sendet beispielsweise eine Datei oder führt das CGI-Programm aus.
Es gibt für diese Anweisung keinen Standardwert. Falls die Anforderung mit einer Service-Regel übereinstimmt (d. h., falls eine in einer Service-Anweisung angegebene Anwendungsfunktion ausgeführt wird), aber von der Funktion HTTP_NOACTION zurückgegeben wird, generiert der Server einen Fehler, und die Anforderung wird zurückgewiesen.
Service Anforderungsschablone/Pfad/Datei:Funktionsname [Server-IP-Adresse | Hostname]
Für die IP-Adresse eines Servers kann kein Platzhalterzeichen verwendet werden.
Service /index.html /ics/api/bin/icsext05.so:serve_req Service /cgi-bin/hexcalc* /ics/api/calculator:HEXcalc*
Keiner.
Legen Sie mit dieser Anweisung einen Abschlusscode für URL-Anforderungen fest. Wird in einer Anforderung ein Abschlusscode verwendet, werden nur die Zeichen vor dem Abschlusscode von Caching Proxy ausgewertet, wenn die Anforderung verarbeitet wird oder wenn überprüft wird, ob das Ergebnis bereits im Cache gespeichert ist. Sind mehrere Abschlusscodes definiert, vergleicht Caching Proxy die ankommenden URLs in der Reihenfolge mit den Abschlusscodes, in der diese in der Datei ibmproxy.conf definiert sind.
SignificantURLTerminator Abschlusszeichenfolge
SignificantURLTerminator &.
In diesem Beispiel werden die folgenden beiden Anforderungen als identische Anforderungen behandelt:
http://www.exampleURL.com/tx.asp?id=0200&.;x=004;y=001 http://www.exampleURL.com/tx.asp?id=0200&.;x=127;y=034
Keiner.
Legen Sie mit dieser Anweisung den SMTP-Server fest, der von der internen Sendmail-Routine innerhalb des Caching Proxy für Windows verwendet wird. Die folgenden zwei Anweisungen müssen für diese Routine ebenfalls festgelegt werden: WebMasterEMail - Eine E-Mail-Adresse für den Empfang von ausgewählten Serverberichten festlegen und WebMasterSocksServer (nur Windows) - Einen Socks-Server für die Sendmail-Routine festlegen.
SMTPServer IP-Adresse oder Hostname des SMTP-Servers
SMTPServer meinebox.com
Keiner.
Mit dieser Anweisung können Sie die SNMP-Unterstützung aktivieren und inaktivieren.
SNMP {on | off}
SNMP off
Mit dieser Anweisung können Sie das Kennwort für die Kommunikation zwischen dem DPI-Subagenten des Webservers (DPI = Distributed Protocol Interface) und dem SNMP-Agenten definieren. Der Name der SNMP-Community berechtigt einen Benutzer, die Leistungsvariablen anzuzeigen, die SNMP für eine bestimmte Community von Servern überwacht. Der Systemadministrator definiert, von welchen Servern welche Variablen nach der Eingabe eines Kennwortes angezeigt werden können. Wenn Sie den Namen der SNMP-Community ändern, müssen Sie auch den in der Datei /etc/snmpd.conf angegebenen Community-Namen ändern.
SNMPCommunity Name
SNMPCommunity public
Mit dieser Anweisung können Sie den Inhalt einer gesicherten Anforderung in den Cache stellen, wenn ein Reverse Proxy verwendet wird. Diese Anweisung konfiguriert das Caching für alle Verbindungen zum Proxy-Server, d. h. Clientverbindungen und Verbindungen zu einem Back-End-Inhaltsserver.
SSLCaching {on | off}
SSLCaching off
Geben Sie mit dieser Anweisung die Schlüsselkennsätze an, mit denen der Proxy-Server festlegt, welches Zertifikat er an den Client senden soll, wenn Caching Proxy als Reverse Proxy für mehrere Domänen auftritt, die eigene SSL-Zertifikate bereitstellen. Außerdem wird damit der Proxy-Server angewiesen, ein PKI-Zertifikat auf der Clientseite zwecks Clientauthentifizierung abzurufen oder nicht abzurufen.
Wenn Sie die Anweisung SSLCertificate verwenden, kann Caching Proxy zwischen einem von einer Zertifizierungsstelle ausgestellten Zertifikat und einem selbst signierten Zertifikat unterscheiden. Wenn Sie jedoch jedes von einer Zertifizierungsstelle ausgestelltes Zertifikat (Option ClientAuthRequired) akzeptieren und diese Anweisung verwenden, können auch nicht gültige Benutzer Zugriff auf den Proxy-Server erhalten. Wenn Sie die Option ClientAuthRequired in der Anweisung SSLCertificate verwenden, können Sie mit dem logischen Ausdruck bestimmen, welche gültigen Benutzer auf den SSL-Kanal zugreifen dürfen.
Wenn der Anweisung SSLCertificate ein zusätzlicher logischer Ausdruck hinzugefügt wird, extrahiert Caching Proxy Werte aus dem Clientzertifikat und berechnet den logischen Ausdruck. Falls der Ausdruck durch die Werte im Clientzertifikat erfüllt wird, erteilt Caching Proxy dem Client die Berechtigung für die Verwendung der SSL-Verbindung. Andernfalls wird die Verbindung beendet und geschlossen.
SSLCertificate Server-IP/Hostname Zertifikatkennsatz [NoClientAuth | ClientAuthRequired logischer-Ausdruck]
Die Option mit dem logischen Ausdruck ist nur gültig, wenn die Option ClientAuthRequired verwendet wird. Wenn der Anweisung SSLCertificate ein zusätzlicher logischer Ausdruck hinzugefügt wird, extrahiert Caching Proxy Werte aus dem Clientzertifikat und berechnet den logischen Ausdruck. Falls der Ausdruck durch die Werte im Clientzertifikat erfüllt wird, erteilt Caching Proxy dem Client die Berechtigung für die Verwendung der SSL-Verbindung. Andernfalls wird die Verbindung beendet und geschlossen.
SSLCertificate www.abc.com ABCCert SSLCertificate 204.146.167.72 intABCCert SSLCertificate www.xyz.com XYZCert ClientAuthRequired SSLCertificate www.xyz.com XYZCert ClientAuthRequired CN="gültiges.Muster.für.allgemeinen.Benutzernamen" && (L="akzeptiertes.Muster.für.Standort" || C!="nicht.gültiges.Muster.für.Land")
Keiner.
Dies gilt nur für Reverse-Proxy-Konfigurationen.
Mit dieser Anweisung können Sie dem Proxy-Server mitteilen, dass eine Verschlüsselungskarte installiert ist und um welche Karte es sich handelt.
Informationen zur Unterstützung der IBM 4960 PCI Cryptographic Accelerator Card finden Sie im Abschnitt PKCS11DefaultCert, PKCS11DriverPath, PKCS11TokenPassword - Unterstützung für IBM 4960 PCI Cryptographic Accelerator Card (nur AIX).
SSLCryptoCard {rainbowcs | nciphernfast} {on | off}
SSLCryptoCard rainbowcs on
Keiner.
Mit dieser Anweisung können Sie festlegen, dass Caching Proxy an Port 443 sichere Anforderungen empfangen soll.
SSLEnable {on | off}
SSLEnable off
Legen Sie mit dieser Anweisung den Port fest, der für HTTP-Anforderungen verwendet werden soll, die Caching Proxy durch Implementierung von SSL in HTTPS-Anforderungen umwandelt. Geben Sie einen anderen Port als den HTTP-Haupt-Port 80 oder den SSL-Haupt-Port 443 an.
SSLForwardPort Port-Nummer
SSLForwardPort 8888
Keiner.
Mit dieser Anweisung können Sie Empfangs-Threads für Standard-HTTP-Anforderungen (normalerweise an Port 80 und 8080) inaktivieren, wenn SSL (normalerweise an Port 443) aktiviert ist.
SSLOnly {on | off}
SSLOnly off
Mit dieser Anweisung können Sie einen anderen als den Standard-HTTP-Port 442 von ibmproxy als HTTPS-Empfangs-Port angeben.
SSLPort Port-WertPort-Wert
steht für einen ganzzahligen Wert größer als 0. Außerdem muss der Port-Wert vom Betriebssystem unterstützt und darf von keine anderen Anwendung verwendet werden.
SSLPort 8443
443
Dies gilt nur für Forward-Proxy-Konfigurationen.
Setzen Sie diese Anweisung auf on, um für jeden Port des Zielservers die SSL-Tunnelung zu aktivieren. Wird diese Anweisung auf off gesetzt, wird die SSL-Tunnelung nur für die in Proxy-Regeln angegebenen Ports aktiviert. Sind keine Proxy-Regeln für die SSL-Tunnelung angegeben und ist die Anweisung SSLTunneling auf off gesetzt, ist die SSL-Tunnelung nicht aktiviert. Ist die Anweisung SSLTunneling auf on gesetzt, müssen Sie auch die Methode "CONNECT" mit der Anweisung Enable aktivieren.
Aktivieren Sie diese Anweisung, wenn Sie Caching Proxy als Forward Proxy einsetzen. Wenn Sie Caching Proxy jedoch als Reverse Proxy verwenden, können Sie sich durch Inaktivieren dieser Anweisung (Standardeinstellung) gegen Angriffe auf Sicherheitslücken bei der SSL-Tunnelung schützen.
Nähere Informationen hierzu finden Sie im Abschnitt SSL-Tunnelung.
SSLTunneling {on | off}
SSLTunneling off
Geben Sie mit dieser Anweisung an, welche Version von SSL verwendet werden soll: V2, V3 oder alle Versionen. Setzen Sie diese Anweisung auf V2, wenn Sie Server verwenden, die SSL Version 3 nicht unterstützen.
SSLVersion {SSLV2 | SSLV3 | all}
SSLVersion SSLV3
Mit dieser Anweisung geben Sie an, wie lange (in Sekunden) eine SSL-Sitzung (Version 2) inaktiv bleiben kann, bevor sie verfällt.
SSLV2Timeout Sekunden
Dabei steht Sekunden für einen Wert zwischen 0 und 100.
SSLV2Timeout 100
Geben Sie mit dieser Anweisung die Zeit in Sekunden an, während der eine Sitzung mit SSL Version 3 bei Inaktivität warten soll, bevor die Sitzung abläuft.
SSLV3Timeout Sekunden
Dabei steht Sekunden für einen Wert zwischen 1 und 86400 Sekunden (dies entspricht 1 Tag in Sekunden).
SSLV3Timeout 100
Mit dieser Anweisung können Sie festlegen, ob der Server zwischen Großbuchstaben und Kleinbuchstaben unterscheiden soll, wenn in den Anweisungen AddClient, AddCharSet, AddType, AddEncoding und AddLanguage Dateisuffixe mit Suffixmustern verglichen werden. Standardmäßig unterscheidet der Server nicht zwischen Großbuchstaben und Kleinbuchstaben.
SuffixCaseSense {on | Off}
SuffixCaseSense Off
Verwenden Sie diese Anweisung, wenn Caching Proxy in der Lage sein soll, basierend auf dem Header HTTP Vary mehr als eine Variante einer Ressource (URI) zu speichern.
Wenn Sie die Anweisung SupportVaryHeader aktivieren, bildet der Proxy-Server eine Cache-ID basierend auf dem URI und den ausgewählten Header-Werten in der Clientanforderung.
Die Namen der ausgewählten Header sind im Header Vary angegeben, der in einer früheren Antwort vom Server gesendet wurde. Wenn der Server die Gruppe der ausgewählten Header-Namen für eine Ressource ändert, werden alle zuvor zwischengespeicherten Objekte für die Ressource aus dem Cache des Proxy-Servers entfernt.
Diese Anweisung kann zusammen mit der Anweisung RegisterCacheIdTransformer verwendet werden (RegisterCacheIdTransformer -- Basierend auf dem Header Cookie mehr als eine Variante einer Ressource zwischenspeichern).
Wenn beide Anweisungen verwendet werden, erstellt der Proxy-Server basierend auf dem Header Vary des Servers und dem Anforderungs-Header des Clients einen internen Transformator für Cache-IDs. Auf diese Weise ist der Proxy-Server in der Lage, eindeutige Cache-IDs für unterschiedliche Anforderung-Antwort-Paare zu generieren, selbst wenn die angeforderten URIs identisch sind.
Die zwischengespeicherten Objekte desselben URI haben eine individuelle Standardlebensdauer im Cache, die von den Headern Expire und Cache-Control in den Anforderungen/Antworten bzw. anderen Konfigurationseinstellungen abhängig ist. Wenn das Plug-in Dynacache verwendet wird, werden alle Darstellungen desselben URI im Proxy-Cache ungültig.
SupportVaryHeader {on | off}
Für dieses Beispiel werden die folgenden Anweisungen in der Datei ibmproxy.conf wie folgt aktiviert und konfiguriert:
SupportVaryHeader on RegisterCacheIdTransformer Cookie UserGroup
Der Client Guest greift mit
URI [<Code>] http://www.dot.com/group.jpg [</Code>]
und der folgenden Anforderung/Antwort auf den Proxy-Server zu:
GET /group.jpg HTTP/1.1 Host: www.dot.com Cookie: UserGroup=Guest Accept-Language: en_US HTTP/1.1 200 Server: my-server Vary: Accept-Language .......
Anschließend greift der Client Admin mit demselben URI
http://www.dot.com/group.jpg
und der folgenden Anforderung/Antwort auf den Proxy-Server zu:
GET /group.jpg HTTP/1.1 Host: www.dot.com Cookie: UserGroup=Admin Accept-Language: fr_FR HTTP/1.1 200 Server: my-server Vary: Accept-Language .......
Falls die Antworten im Cache gespeichert werden können, generiert der Proxy-Server zwei unterschiedliche Cache-IDs:
1. CacheID(URI, "Guest", "en_US") 2. CacheID(URI, "Admin", "fr_FR")
Der Proxy-Server speichert zwei unterschiedliche Varianten der Antwort vom Server im Cache. Wenn danach ein Client die Ressource (.../group.jpg) mit einer dieser Kombinationen von Sprachvorgabe und Benutzergruppe anfordert, ruft der Proxy-Server die entsprechende Variante der Ressource aus dem Cache ab und stellt diese bereit.
SupportVaryHeader off
Mit dieser Anweisung können Sie das Protokoll TLS Version 1 in SSL-Verbindungen aktivieren. Wenn diese Anweisung auf on gesetzt ist, sucht die SSL-Verbindung zunächst nach dem Protokoll TLS, dann nach dem Protokoll SSLv3 und zuletzt nach dem Protokoll SSLv2.
TLSV1Enable {on | off}
TLSV1Enable on
Keiner.
Mit dieser Anweisung können Sie eine angepasste Anwendungsfunktion abgeben, die der Server im Schritt "Data Manipulation" aufrufen soll. Dieser Code stellt drei Anwendungsfunktionen bereit:
Es können mehrere Transmogrifier für jede Instanz des Servers aktiv sein.
Transmogrifier /Pfad/Datei:Funktionsname:Funktionsname:Funktionsname
Transmogrifier /ics/bin/icsext05.so:open_data:write_data:close_data
Keiner.
Mit dieser Anweisung können Sie eine Nachricht an den Client senden.
transmogrifiedwaning {yes|no}
Yes
Dies gilt nur für Forward-Proxy-Konfigurationen.
Auf Linux-Systemen legen Sie mit dieser Anweisung fest, ob der Server als transparenter Proxy-Server arbeiten kann.
Ist die Anweisung TransparentProxy auf on gesetzt, wird die Anweisung BindSpecific ignoriert und auf den Standardwert off gesetzt. Da der meiste HTTP-Verkehr über den Port 80 abgewickelt wird, wird dringend empfohlen, dass dieser Port ebenfalls konfiguriert wird.
TransparentProxy {on | off} Port 80
TransparentProxy off
Wenn eine IPCHAIN-Firewall verwendet wird, reicht die Aktivierung dieser Anweisung aus, um den transparenten Proxy-Server zu konfigurieren. Wenn eine IPTABLES-Firewall verwendet wird, müssen Sie die Regel für die IPTABLES-Firewall manuell hinzufügen.
Wenn eine IPTABLES-Firewall verwnendet wird und die Anweisung TransparentProxy aktiviert ist, führen Sie vor dem Starten des Proxy-Servers den folgenden Befehl aus, um die Firewall-Regeln zu IPTABLES hinzuzufügen:
iptables -t nat -A PREROUTING -i Ihre_Netzschnittstelle -p tcp --dport 80 -j REDIRECT --to-port Listener_Port_für_ibmproxy
Vorausgesetzt, dass die Firewall und der Proxy-Server auf derselben Maschine installiert sind, weist diese Regeln die IPTABLES-Firewall an, den gesamten TCP-Datenverkehr für Port 80 an den lokalen Listener-Port des Proxy-Servers umzuleiten. Die Regel kann auch in der IPTABLES-Konfiguration hinzugefügt werden. In diesem Fall kann die Regel automatisch beim Systemneustart geladen werden.
Nachdem der transparente Proxy-Server gestartet wurde, müssen Sie außerdem die folgenden Befehle als root ausführen, wenn Caching Proxy gestoppt werden soll:
ibmproxy -unload
Auf Linux-Systemen entfernt dieser Befehl die Umleitungsregeln für die Firewall. Wird dieser Befehl nach dem Stoppen des Servers nicht ausgeführt, wird die Maschine Anforderungen akzeptieren, die nicht für sie bestimmt sind.
Legen Sie mit dieser Anweisung fest, welchen Proxy-Server der Cache-Agent aktualisieren soll. Diese Angabe ist erforderlich, wenn der Cache-Agent einen anderen als den lokalen Proxy-Server, auf dem er läuft, aktualisieren soll. Sie können wahlweise den Port angeben.
Obwohl der Cache-Agent den Cache eines anderen Servers aktualisieren kann, ist er nicht in der Lage, das Cache-Zugriffsprotokoll von dieser Maschine abzurufen. Aus diesem Grund wird, falls in der Anweisung UpdateProxy ein anderer Host als der lokale Host angegeben ist, die Anweisung LoadTopCached ignoriert.
UpdateProxy vollständig_qualifizierter_Hostname_des_Proxy-Servers
UpdateProxy proxy15.ibm.com:1080
Keiner.
Mit dieser Anweisung können Sie den Benutzernamen oder die ID angeben, zu dem bzw. der der Server wechseln soll, bevor er auf Dateien zugreift.
Wenn Sie diese Anweisung ändern, müssen Sie den Server manuell stoppen und anschließend erneut starten, damit die Änderung wirksam wird. Der Server erkennt die Änderung erst, wenn Sie ihn erneut starten. (Nähere Informationen hierzu finden Sie in Caching Proxy starten und stoppen.)
UserId {ID-Name | Nummer}
AIX, Linux, Solaris: UserId nobody
HP-UX: UserId www
Diese Anweisung listet die verfügbare Verschlüsselungsspezifikation für SSL Version 2 auf.
V2CipherSpecs Spezifikation
Jede Kombination der folgenden Werte ist zulässig. Kein Wert darf zweimal verwendet werden.
Keiner (SSL ist standardmäßig inaktiviert).
In dieser Anweisung werden die verfügbaren Spezifikationen zur Verschlüsselung für SSL Version 3 aufgelistet.
Wenn die Anweisung FIPSenable auf "on" eingestellt ist, wird die Anweisung V3CipherSpecs ignoriert. Nähere Informationen hierzu finden Sie im Abschnitt FIPSEnable -- FIPS-konforme (Federal Information Processing Standard) Verschlüsselungen für SSLV3 und TLS aktivieren.
V3CipherSpecs Spezifikation
Es sind die folgenden Werte zulässig:
Keiner (SSL ist standardmäßig inaktiviert).
Mit dieser Anweisung wird eine E-Mail-Adresse festgelegt, an der ausgewählte Caching-Proxy-Berichte empfangen werden, beispielsweise die Benachrichtigung 30 Tage vor Ablauf eines SSL-Zertifikats. Auf Linux- und UNIX-Systemen muss ein Sendmail-Prozess aktiv sein. Bei Windows-Systemen ist der Sendmail-Prozess im Caching Proxy integriert, so dass kein externer Mail-Server erforderlich ist. Außerdem müssen zwei weitere Anweisungen festgelegt werden: WebMasterSocksServer (nur Windows) - Einen Socks-Server für die Sendmail-Routine festlegen und SMTPServer (nur Windows) - Einen SMTP-Server für die Sendmail-Routine festlegen.
WebMasterEMail E-Mail-Adresse_des_Webmaster
WebMasterEmail webmaster@computer.com
WebMasterEmail webmaster
Legen Sie mit dieser Anweisung den Socks-Server fest, der von der internen Sendmail-Routine innerhalb des Caching Proxy für Windows verwendet wird. Die folgenden zwei Anweisungen müssen für diese Routine ebenfalls festgelegt werden: WebMasterEMail - Eine E-Mail-Adresse für den Empfang von ausgewählten Serverberichten festlegen und SMTPServer (nur Windows) - Einen SMTP-Server für die Sendmail-Routine festlegen.
WebMasterSocksServer IP-Adresse oder Hostname des Socks-Servers
WebMasterSocksServer socks.meinebox.com
Keiner.
Mit dieser Anweisung können Sie den Namen einer Begrüßungsdatei abgeben, die der Server als Antwort auf Anforderungen suchen soll, die keinen speziellen Dateinamen enthalten. Sie können eine Liste von Begrüßungsdateien erstellen, indem Sie diese Anweisung in Ihrer Konfigurationsdatei mehrfach angeben.
Bei Anforderungen, die keinen speziellen Datei- oder Verzeichnisnamen enthalten, sucht der Server immer im Dateistammverzeichnis nach einer Datei, deren Name mit dem in einer Welcome-Anweisung angegebenen Namen übereinstimmt. Wenn der Server eine Übereinstimmung findet, gibt er die Datei an den Anfordernden zurück.
Bei Anforderungen, die einen Verzeichnisnamen, aber keinen Dateinamen enthalten, steuert die Anweisung AlwaysWelcome, ob der Server in diesem Verzeichnis nach einer Begrüßungsdatei sucht. Standardmäßig ist AlwaysWelcome auf On festgelegt. Damit sucht der Server immer im angeforderten Verzeichnis nach einer Datei, deren Name mit dem in einer Welcome-Anweisung angegebenen Namen übereinstimmt. Wird eine solche Datei gefunden, wird sie an den Requester zurückgegeben.
Falls der Server in einem Verzeichnis mehrere Dateien findet, die den in Welcome-Anweisungen angegebenen Dateinamen entsprechen, bestimmt die Reihenfolge der Welcome-Anweisungen, welche Datei zurückgegeben wird. Dabei wird die Welcome-Anweisung verwendet, die in der Konfigurationsdatei am weitesten oben steht.
Welcome Dateiname [Server-IP-Adresse | Hostname]
Sie können eine IP-Adresse (z. B. 240.146.167.72) oder einen Hostnamen (z. B. hostA.bcd.com) angeben.
Dieser Parameter ist optional. Ohne Angabe dieses Parameters verwendet der Server die Anweisung für alle Anforderungen ungeachtet der IP-Adresse, unter der die Anforderungen ankommen, oder des Hostnamens in den URLs.
Für die IP-Adresse eines Servers kann kein Platzhalterzeichen verwendet werden.
Welcome letsgo.html Welcome Welcome.html
Welcome CustomerA.html 0.67.106.79 Welcome CustomerB.html 0.83.100.45
Welcome CustomerA.html hostA.bcd.com Welcome CustomerB.html hostB.bcd.com
Diese Standardwerte sind in der Reihenfolge aufgeführt, die in der Standardkonfiguration verwendet wird:
Welcome Welcome.html Welcome welcome.html Welcome index.html Welcome Frntpage.html