Versione 7.0
Numero documento GC31-6920-00
Prima edizione (giugno 2008)
Questa edizione si applica a:
e a tutte le release e modifiche successive, finché non verrà diversamente indicato nelle nuove edizioni.
Ordinare le pubblicazioni mediante il rappresentante IBM o gli uffici IBM del proprio paese.
(C) Copyright International Business Machines Corporation 2008. Tutti i diritti riservati.
Limitazioni previste per gli utenti del Governo degli Stati Uniti - L'uso, la duplicazione o la divulgazione sono limitati dal GSA ADP Schedule Contract con la IBM Corp.
Configurazione e ottimizzazione del processo Caching Proxy
Configurazione del funzionamento di Caching Proxy
Configurazione della memorizzazione nella cache del server proxy
Configurazione della sicurezza di Caching Proxy
Questa prefazione descrive i destinatari e lo scopo della presente guida, la sua organizzazione, le funzioni di accessibilità, le convenzioni, la terminologia e la documentazione correlata.
La Guida alla gestione di Caching Proxy è scritta per amministratori di rete e di sistema esperti, con una buona conoscenza dei propri sistemi operativi e della fornitura di servizi Internet. Non è richiesta alcuna precedente esperienza con Caching Proxy.
Questo manuale non è destinato a supportare release precedenti di Caching Proxy.
Questa documentazione utilizza le seguenti convenzioni tipografiche e di definizione
dei tasti.
Tabella 1. Convenzioni utilizzate in questa guida
Convenzione | Significato |
---|---|
Grassetto | Quando si fa riferimento alle GUI (Graphical User Interface), il grassetto evidenzia menu, voci di menu, etichette, pulsanti, icone e cartelle. Inoltre, può essere utilizzato per enfatizzare i nomi di comandi che, altrimenti, verrebbero confusi con il testo circostante. |
A spaziatura fissa | Indica il testo da inserire davanti a un prompt di comandi. Inoltre, indica il testo su video, gli esempi di codice ed estratti di file. |
Corsivo | Indica i valori delle variabili che l'utente deve inserire (ad esempio, il nome per sostituire nomeFile con il nome effettivo di un file). Il corsivo viene inoltre utilizzato per enfatizzare un concetto ed evidenziare i titoli di manuali. |
Ctrl-x | Dove x è il nome di un tasto, indica una sequenza di caratteri di controllo. Ad esempio, Ctrl-c indica: tenere premuto il tasto Ctrl e contemporaneamente premere il tasto c. |
Invio | Indica il tasto etichettato con la parola Invio, Enter, Return o con una freccia verso sinistra. |
% | Rappresenta il prompt della shell di comandi Linux(TM) e UNIX(R) per un comando che non richieste privilegi root. |
# | Rappresenta il prompt della shell dei comandi in ambiente Linux e UNIX per un comando che richiede i privilegi root. |
C:\ | Rappresenta il prompt dei comandi di Windows(R). |
Immissione di comandi | Quando si invita l'utente a "immettere" o "inserire" un comando, immettere il comando e premere Invio. Ad esempio, l'istruzione "Immettere il comando ls" significa immettere ls al prompt dei comandi e premere Invio. |
[ ] | Racchiude le voci facoltative nelle descrizioni della sintassi. |
{ } | Racchiude gli elenchi da cui è necessario scegliere una voce nelle descrizioni della sintassi. |
| | Separa le voci in un elenco di opzioni racchiuse tra parentesi { } nelle descrizioni della sintassi. |
... | I puntini di sospensione nelle descrizioni della sintassi indicano che è possibile ripetere la voce precedente una o più volte. Negli esempi, indicano che le informazioni sono state omesse dall'esempio per motivi di brevità. |
Le funzioni di accesso facilitato consentono a un utente con svantaggi fisici, quali una mobilità o una vista limitata, di utilizzare agevolmente prodotti software. Queste sono le principali funzioni di accesso facilitato in WebSphere(R) Application Server, versione 7.0:
I vostri commenti risultano di estrema importanza poiché consentono di fornire informazioni della massima accuratezza e qualità. In caso di commenti su questa guida o su altra documentazione relativa a Edge Components di WebSphere Application Server:
Questa sezione fornisce una panoramica del componente Caching Proxy, istruzioni per l'uso dei moduli di e del wizard di configurazione, istruzioni per la modifica manuale del file ibmproxy.conf e procedure per l'avvio e l'arresto del server proxy.
Questa sezione contiene i seguenti argomenti:
Utilizzo dei moduli di configurazione e amministrazione
Utilizzo della procedura guidata di configurazione
Modifica manuale del file ibmproxy.conf
Avvio e arresto di Caching Proxy
Funzionando da proxy inverso o da proxy diretto, Caching Proxy intercetta le richieste di dati da un client, richiama le informazioni richieste dalle macchine degli host del contenuto e restituisce il contenuto al client. Di norma, le richieste riguardano documenti memorizzati su server Web, detti anche server di origine o host di contenuti, e fornite mediante il protocollo HTTP (Hypertext Transfer Protocol). Tuttavia, è possibile configurare Caching Proxy per la gestione di altri protocolli, quali FTP (File Transfer Protocol) e Gopher.
Caching Proxy memorizza il contenuto che può essere archiviato in una cache locale prima di distribuirlo al richiedente. Tra gli esempi di contenuto memorizzabile nella cache sono comprese pagine Web statiche e FILE JSP (JavaServer Page) con frammenti generati in modo dinamico ma soggetti a modifiche poco frequenti. La memorizzazione nella cache consente a Caching Proxy di soddisfare le successive richieste dello stesso contenuto fornendolo direttamente dalla cache locale, con una velocità molto maggiore di quanto avverrebbe recuperandolo di nuovo dall'host dei contenuti.
IMPORTANTE: Caching Proxy è disponibile su tutte le installazioni di Edge Components, con le seguenti eccezioni:
Le due configurazioni proxy di base sono il proxy inverso e il proxy diretto.
Per impostazione predefinita, Caching Proxy è configurato come server proxy inverso. In una configurazione di questo tipo, un server proxy si trova tra uno o più server del contenuto e Internet. Esso accetta le richieste dai client Internet per il contenuto memorizzato sul sito del server proxy. Il server proxy funziona da client sul server di origine (contenuto); il client non è a conoscenza della richiesta inviata a un altro server.
In alternativa, è possibile configurare Caching Proxy come server proxy diretto. Tuttavia, i browser del client devono essere configurati singolarmente per utilizzare il proxy. In una configurazione di proxy diretto, un server proxy è ubicato tra il client e Internet. Caching Proxy inoltra la richiesta di un client agli host del contenuto su Internet, memorizza nella cache i dati richiamati e distribuisce tali dati sul client.
Per abilitare una configurazione di proxy diretto, è necessario apportare le seguenti modifiche al file di configurazione ibmproxy.conf:
Proxy http:* Proxy ftp:* Proxy gopher:*
SSLTunneling On
Per ulteriori informazioni sul tunneling SSL, fare riferimento a Configurazione del tunneling SSL.
Enable CONNECT OutgoingPorts All
o
Enable CONNECT OutgoingPorts 443
Per informazioni sul formato e sulle opzioni disponibili per il metodo Enable CONNECT, fare riferimento a Configurazione del tunneling SSL.
Queste modifiche consentono al proxy diretto di:
Una variazione del Caching Proxy diretto è un Caching Proxy trasparente. In questo ruolo, il Caching Proxy esegue le stesse funzioni di un Caching Proxy diretto di base, ma le esegue senza che il client si accorga della sua presenza. La configurazione trasparente di Caching Proxy è supportata solo su sistemi Linux.
Come con il Caching Proxy diretto regolare, il Caching Proxy trasparente viene installato su una macchina del Internet/gateway, ma i browser del client non sono configurati per indirizzare le richieste a un Caching Proxy diretto. I client non sono a conoscenza della presenza di un proxy nella configurazione. Invece, è configurato un router che intercetta le richieste dei client e le indirizza al Caching Proxy trasparente.
Per informazioni sulla direttiva per questa configurazione, fare riferimento a TransparentProxy -- Abilita il proxy trasparente su Linux.
Il manuale Guida alla gestione per Caching Proxy Versione 6.1 include le funzioni appena documentate e i relativi aggiornamenti correttivi.
Le funzioni più significative sono:
Per informazioni sulla configurazione di un proxy diretto, fare riferimento a Proxy diretto.
Per informazioni sulla direttiva del proxy trasparente (diretto), fare riferimento a TransparentProxy -- Abilita il proxy trasparente su Linux.
Per informazioni su questi metodi, fare riferimento a Abilitazione dei metodi WebDAV, dei metodi MS Exchange e dei metodi dell'interfaccia utente.
Per informazioni su queste direttive, fare riferimento aCompressionFilterAddContentType -- Specifica del tipo di contenuto della risposta HTTP che si desidera comprimere eCompressionFilterEnable -- Abilitazione del filtro di compressione per comprimere le risposte HTTP.
Per informazioni su questa direttiva, fare riferimento a NoCacheOnRange -- Specifica nessuna memorizzazione nella cache per le richieste di intervallo.
Per informazioni su questa direttiva, fare riferimento a OptimizeRuleMapping -- Ottimizza il processo di associazione delle regole per le richieste in entrata quando aumenta il numero di regole
Simile all'istruzione Map, MapQuery utilizza la stringa path e la stringa query per associare la regola.
Per informazioni su questa direttiva, fare riferimento a MapQuery -- Modifica le richieste corrispondenti a una nuova stringa di richiesta utilizzando la stringa del percorso della richiesta e la stringa della query in modo da corrispondere alla regola.
Per informazioni su questa direttiva, fare riferimento a RuleCaseSense -- Associa le richieste dagli URL dell'applicazione che non sono sensibili al maiuscolo/minuscolo.
Per informazioni su queste direttive, fare riferimento a PKCS11DefaultCert, PKCS11DriverPath, PKCS11TokenPassword -- Supporta IBM 4960 PCI Cryptographic Accelerator Card (solo AIX).
Per informazioni sull'opzione di espressione logica su questa direttiva, fare riferimento a SSLCertificate -- Specifica le etichette chiave per i certificati.
Caching Proxy fornisce istruzioni che richiedono un'ulteriore associazione del modello durante il runtime. Per migliorare le prestazioni di Caching Proxy, è possibile utilizzare queste istruzioni come opzioni nella regola Proxy o ProxyWAS. Per ulteriori informazioni su queste opzioni aggiuntive per la regola Proxy o ProxyWAS, fare riferimento a Proxy -- Specifica dei protocolli proxy o del proxy inverso.
Caching Proxy comprende moduli HTML che possono essere forniti ai client richiedenti e utilizzati per configurare il server proxy. Tali moduli eseguono programmi CGI che modificano il file di configurazione del server proxy locale, ibmproxy.conf. Per utilizzare tali moduli, il server proxy deve essere in esecuzione e configurato in modo da inoltrare i moduli alla directory locale in cui si trovano.
Per impostazione predefinita, Caching Proxy viene installato con direttive Pass comprese nel file ibmproxy.conf, che consentono l'accesso ai moduli di configurazione e amministrazione. Quando un client richiede la pagina iniziale predefinita da questo server proxy, viene fornita la pagina Frntpage.html. Questa contiene un collegamento ipertestuale alla pagina iniziale dei moduli di configurazione e amministrazione, wte.html.
I moduli di configurazione e amministrazione sono protetti e richiedono l'autenticazione del client prima della trasmissione. Per le istruzioni su come impostare l'ID e la password dell'amministratore, fare riferimento a Impostazione della password dell'amministratore.
Un browser Web utilizzato per accedere ai moduli di configurazione e amministrazione deve supportare quanto segue:
I browser consigliati sono Mozilla and o Mozilla 1.7 (per i sistemi Linux e UNIX) o Internet Explorer (per i sistemi Windows). Per le versioni consigliate dei browser Mozilla, Firefox e Internet Explorer, fare riferimento al seguente sito Web e seguire i collegamenti alla pagina Web del software supportato: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921 .
Note:
Per accedere ai moduli di configurazione e amministrazione:
http://nome.server[:porta][/directory][/pagina.html]
in cui
Note:
Fare clic sul puntatore triangolare sulla sinistra di un'intestazione per espandere l'elenco dei moduli di configurazione in quella categoria. Fare clic su un modulo per aprirlo. Il modulo illustra i valori di configurazione attuali (se presenti) nei campi di immissione; se la configurazione non è stata modificata dopo l'installazione, si tratta dei valori predefiniti.
Le modifiche alla configurazione richieste sono state completate correttamente
Se i dati immessi non vengono accettati, nel frame superiore viene visualizzato un messaggio di errore che indica le impostazioni non accettabili.
Dopo aver installato i package di Caching Proxy, è necessario creare un ID amministratore e una password per accedere ai moduli di configurazione e amministrazione. La configurazione predefinita del server proxy prevede l'autenticazione degli utenti che richiedono i moduli di configurazione e amministrazione mediante il file di password webadmin.passwd nella directory /opt/ibm/edge/cp/server_root/protect/ su sistemi Linux e UNIX o nella directory \Program Files\IBM\edge\cp\etc\ sui sistemi Windows. L'installazione dei package non sovrascrive un file webadmin.passwd esistente.
Per aggiungere una voce amministratore al file webadmin.passwd, utilizzare i comandi seguenti:
# htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwd
Quando richiesto, fornire al programma htadm un nome utente, una password e un nome completo per l'amministratore.
cd "\Program Files\IBM\edge\cp\server_root\protect\" htadm -adduser webadmin.passwd"
Quando richiesto, fornire al programma htadm un nome utente, una password e un nome completo per l'amministratore.
Per una descrizione dettagliata del comando htadm, fare riferimento alla sezione Comando htadm.
La procedura guidata di configurazione di Caching Proxy consente di configurare rapidamente un Caching Proxy installato. Questo programma imposta solo le direttive essenziali richieste per modificare il comportamento del Caching Proxy in modo che funzioni come surrogato. Il server proxy può richiedere una configurazione aggiuntiva.
Per utilizzare la procedura guidata di configurazione di Caching Proxy:
Su sistemi Windows, fare clic su Start -> Programmi -> IBM WebSphere -> Edge Components -> Caching Proxy -> Procedura guidata di configurazione.
Su sistemi Linux e UNIX, immettere il comando /opt/ibm/edge/cp/cpwizard/cpwizard.sh
Note:
Port porta Proxy /* http://server di contenuto :porta
Esempi:
Proxy /* http://server contenuto:443
o
Proxy /* https://server contenuto:443
Limitazioni su sistemi Linux: i tasti di scelta rapida non funzionano per la procedura guidata di configurazione di Caching Proxy.
È possibile configurare Caching Proxy manualmente, modificando il file di configurazione ibmproxy, oppure utilizzando i moduli di Configurazione e amministrazione.
Il file di configurazione è composto da istruzioni dette direttive. Per cambiare la configurazione, modificare il file di configurazione modificando le direttive, quindi salvare le modifiche apportate. È possibile utilizzare qualsiasi editor di testo, quali emacs e vi, per modificare il file di configurazione.
Appendice B, Direttive del file di configurazione descrive le direttive del file di configurazione e fornisce i dettagli relativi alla sintassi.
Caching Proxy è progettato per l'esecuzione continuativa come processo in background con intervento minimo da parte dell'operatore. In genere, Caching Proxy viene avviato durante il ciclo di avvio della macchina e arrestato solo in caso di interventi di manutenzione. Il server proxy può essere avviato manualmente in caso di necessità. Inoltre, è possibile passare al server proxyun'istruzione di riavvio, che arresta e riavvia il server senza danni per le connessioni client attive.
Su sistemi Linux e UNIX, lo script di inizializzazione ibmproxy e i collegamenti simbolici associati sono inseriti nelle directory /etc/ appropriate durante l'installazione di Caching Proxy. Tali script vengono quindi integrati nelle routine di avvio e arresto del sistema operativo. È possibile modificare le impostazioni di configurazione per il riavvio automatico modificando lo script ibmproxy e cambiando le opzioni del comando ibmproxy.
È possibile che lo script di inizializzazione di Caching Proxy non imposti il numero massimo desiderato per i descrittori dei file a causa di un limite di tutto il sistema Solaris relativo ai descrittori di file. Se il valore di sistema massimo è inferiore all'impostazione nello script di inizializzazione di Caching Proxy, viene utilizzato il limite per il sistema. È possibile modificare il limite di descrittori di file per evitare problemi di prestazioni del proxy dovute a un valore troppo basso (inferiore a 1024). Immettere il comando ulimit per visualizzare il numero di descrittori attualmente disponibili. Se il valore è inferiore a 1024, aumentare il limite dei descrittori di file. Per aumentare tale limite a 1024, aggiungere la riga seguente al file /etc/system:
set rlim_fd_cur=0x400
Disattivazione dell'avvio e arresto automatico
Per disattivare l'avvio e l'arresto automatico:
Su SUSE Linux, eliminare i seguenti collegamenti a ibmproxy:
Su Red Hat Linux, eliminare i seguenti collegamenti a ibmproxy:
A prescindere dal metodo di avvio, il comando ibmproxy può essere richiamato direttamente dal prompt dei comandi o dall'interno di uno script. Per una descrizione dettagliata del comando ibmproxy, fare riferimento alla sezione Comando ibmproxy. Vengono forniti di seguito esempi degli argomenti di uso più comune.
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
dove il file errors_icons.conf identifica le icone da utilizzare per i tipi di file indicati durante la visualizzazione dei contenuti delle directory.
/etc/init.d/ibmproxy start
/usr/sbin/ibmproxy
/usr/sbin/ibmproxy -nobg
Se Caching Proxy viene installato come servizio di Windows, viene avviato come qualsiasi altro servizio di Windows:
Se Caching Proxy è installato come servizio, questo può essere configurato per essere avviato automaticamente all'avvio di Windows. In tal caso, non è necessario accedere al sistema per consentire al proxy di soddisfare le richieste. Per avviare automaticamente il proxy:
Aggiornamento della variabile d'ambiente PATH
Se Caching Proxy è contrassegnato come Avviato nella finestra Servizi ma il proxy non funziona, è possibile che non sia stato eseguito il riavvio della macchina una volta installato il proxy. Se il servizio Caching Proxy è impostato in modo da interagire con il desktop, un errore nel riavvio può provocare anche la visualizzazione del seguente messaggio di errore: Errore catalogo messaggi: impossibile caricare il catalogo messaggi o catalogo messaggi non valido
Riavviare la macchina per consentire l'aggiornamento del valore della variabile d'ambiente PATH nel registro di configurazione di Windows. Se il registro di configurazione non viene aggiornato, la variabile PATH potrebbe indicare i percorsi corretti per Caching Proxy e GSK7, ma funzionare in modo errato.
Il problema può verificarsi se il percorso del servizio file system appare prima del percorso del servizio Caching Proxy nella variabile d'ambiente di Windows PATH. Il problema può essere risolto modificando la variabile PATH per collocare i servizi file system verso la fine delle impostazioni.
Questo problema non influisce sulle unità remote controllate da applicazioni non eseguite come servizi di Windows. Ad esempio, Caching Proxy può accedere alle unità condivise su altre macchine Windows visibili attraverso una rete locale (LAN).
Quando Caching Proxy viene installato come applicazione di Windows, la procedura di installazione crea una voce Caching Proxy come sottomenu del menu Start. Per avviare Caching Proxy come applicazione, fare clic su Start -> Programmi -> IBM WebSphere -> Edge Components -> Caching Proxy.
Questa procedura di avvio esegue il server proxy con le impostazioni dellaconfigurazione corrente. Per specificare altre impostazioni all'avvio, utilizzare la procedura di avvio con comando (vedere la sezione successiva).
Per avviare il server da qualsiasi prompt dei comandi Windows o DOS, utilizzare il comando ibmproxy. Se Windows non è stato arrestato e riavviato dopo l'installazione del server, immettere il percorso completo per questo comando, come segue (per impostazione predefinita):
c:\Programmi\IBM\edge\cp\bin\ibmproxy.exe
Il comando ibmproxy avvia il server con le impostazioni di configurazione correnti. Se la configurazione del server non è stata modificata dopo l'installazione, la configurazione corrente si basa sulle informazioni immesse durante l'installazione e sulle opzioni predefinite.
Il comando ibmproxy avvia il server come applicazione anche se Caching Proxy è stato installato per essere eseguito come servizio. Per forzare l'esecuzione del server come un'applicazione, è inoltre possibile specificare l'opzione di comando -noservice. Altre opzioni di comando modificano le impostazioni di configurazione durante il runtime.
È possibile eseguire simultaneamente più istanze del server proxy, ma ogni coppia di indirizzo IP di collegamento e porta di ascolto (Nome host/IP, PORTA) deve essere univoca. È inoltre necessario abilitare la direttiva BindSpecific nei file di configurazione. Inoltre, quando più istanze del proxy sono in esecuzione su un singolo sistema, è necessario definire le seguenti direttive per ogni istanza proxy:
Sui sistemi AIX, è possibile avviare una sola istanza con SRC. È necessario specificare file di configurazione univoci per tutte le istanze del server, dal momento che il file di configurazione identifica il numero di porta e tale numero deve essere diverso per ciascun server su una determinata macchina. Per avviare un'istanza aggiuntiva del server, quando ne è presente almeno una già in esecuzione, immettere il seguente comando:
ibmproxy -r altro_file_config
ibmproxy -noservice -r altro_file_config
dove altro_file_config è un file di configurazione univoco.
Quando si avviano istanze multiple del server, registrare l'ID del processo visualizzato per ciascuna istanza. Tali ID sono necessari per arrestare istanze specifiche del server.
Per arrestare il server:
Tabella 2. Metodi di avvio e di arresto per i sistemi Linux eUNIX
Metodo di avvio | Metodo di arresto |
Da /etc/inittab (su AIX) | Immettere stopsrc -s ibmproxy |
Da /sbin/init.d (On HP-UX) | Immettere /sbin/init.d/ibmproxy stop |
Da /etc/rc.d/init.d (su Linux) | Immettere /etc/rc.d/init.d/ibmproxy stop |
ibmproxy |
Per arrestare tutti i server su questa macchina: immettere killall ibmproxy
|
ibmproxy -nobg | Immettere ctrl-c |
ibmproxy -r -altro_file_di_configurazione(su AIX) | Immettere stopsrc -s ibmproxy -p id_processo |
ibmproxy -r -altro_file_di_configurazione(su Linux) |
|
ibmproxy -unload
Per arrestare il server al prompt di root, immettere:
Durante l'uso dei comandi di arresto, si possono sperimentare le seguenti limitazioni:
Su sistemi AIX, HP-UX e Linux, i comandi per arrestare il sistema Caching Proxy a volte arresta solo il processo Caching Proxy. Il comando AIX che provoca questo comportamento è stopsrc -s ibmproxy. Il comando per HP-UX e Linux che provoca questo comportamento è il comando ibmproxy -stop.
Il processo PACD, utilizzato dal server LDAP, potrebbe rimanere in esecuzione dopo l'arresto del server proxy. Il processo PACD può essere arrestato in sicurezza utilizzando il comando kill nel modo seguente:
kill -15 ID_processo_PACD
L'immissione del comando ibmproxy -stop su un sistema Solaris non ha lo stesso effetto che sugli altri sistemi operativi. A causa di una limitazione nel codice di Solaris, la fase Server Termination del plugin non viene eseguita quando si utilizza ibmproxy -stop sulle piattaforme Solaris.
Questa limitazione ha implicazioni per il software del server proxy e per i plugin implementati dal cliente.
Il processo PACD, utilizzato dal server LDAP, potrebbe rimanere in esecuzione dopo l'arresto del server proxy. Il processo PACD può essere arrestato in sicurezza utilizzando il comando kill nel modo seguente:
kill -15 ID_processo_PACD
È possibile arrestare il server Caching Proxy analogamente a quanto avviene per gli altri programmi Windows.
Se il proxy è installato come servizio:
Se il proxy non è installato come servizio, eseguire una delle operazioni qui riportate per arrestare Caching Proxy:
Dopo aver modificato la configurazione del server, mediante i moduli di Gestione e configurazione o la modifica del file ibmproxy.conf, è necessario riavviare il server per rendere effettive le modifiche. Nella maggior parte dei casi, è possibile riavviare il server senza doverlo prima arrestare. Tuttavia, alcune impostazioni non vengono aggiornate da un semplice riavvio. Per ulteriori informazioni, fare riferimento alla Tabella 6.
Per riavviare il server senza prima arrestarlo, fare clic sul pulsante Riavvia su qualsiasi modulo di Configurazione e amministrazione, oppure immettere quanto segue: ibmproxy -restart
Questa sezione illustra l'interazione tra il componente Caching Proxy con il sistema operativo, l'hardware del computer e la rete. Fornisce inoltre procedure per la configurazione di tale interazione. Questi elementi della configurazione del server proxy vengono normalmente gestiti dall'amministratore del sistema e devono essere attentamente coordinati con le risorse di rete, quali indirizzi IP e nomi host, nonché con le risorse di sistema, quale la memoria disponibile e i cicli della CPU.
Questa sezione contiene i seguenti argomenti:
Determinazione della proprietà del processo
Ottimizzazione del processo server proxy
Caching Proxy viene tipicamente eseguito come processo in background su un computer host configurato per agire come server di rete. Questo processo è associato con (collegato a) uno o tutti gli indirizzi IP (Internet Protocol) attivi sul computer host. Ascolta diversi protocolli Internet, quali FTP e HTTP, su porte specificate ed esegue azioni per queste richieste in base alla configurazione stabilita per il suo funzionamento. Per ulteriori informazioni, fare riferimento a Configurazione del funzionamento di Caching Proxy.
Per impostazione predefinita, Caching Proxy assume il nome del sistema del computer host. È possibile sovrascrivere questo comportamento predefinito specificando un nome host per il server proxy. Per poter collegare Caching Proxy a un determinato indirizzo IP, il nome host del server proxy deve essere modificato in un indirizzo IP uguale.
Il nome host del server proxy non interessa il modo in cui il traffico del client viene risolto. Il server proxy non confronta il proprio nome host con il valore dell'argomento nome host nell'intestazione della richiesta HTTP. Il nome host del server proxy viene a volte incorporato nelle pagine locali con contenuto generato in modo dinamico, quali i messaggi di errore. Viene inoltre trasmesso in risposta al client richiedente come valore dell'argomento "Via" nell'intestazione HTTP.
Il server proxy può essere configurato per sostituire il nome host del client che effettua la richiesta con il nome host del server prima di trasmettere la richiesta al server di destinazione. In questo modo, il server di destinazione viene forzato a mantenere il canale di comunicazione attraverso il server proxy, anziché stabilire una connessione diretta con il client.
Definire il processo del server proxy specificando l'ubicazione fisica dei file del server sul computer host, il nome con cui il server proxy fa riferimento a se stesso e le porte su cui è in ascolto come valori per le direttive ServerRoot, Hostname e Port. Se l'host è dotato di indirizzi IP multipli, il server proxy può essere collegato a un indirizzo specifico impostando il valore della direttiva BindSpecific su On e il valore della direttiva Hostname sullo specifico indirizzo IP.
Una porta di gestione fornisce un metodo per accedere ai moduli di configurazione e amministrazione ed eseguire la manutenzione del server. Per consentire l'accesso al server proxy mediante una porta di gestione, specificare un valore per la direttiva AdminPort. Le richieste ricevute sulla porta di gestione non vengono accodate a quelle ricevute sulla porta standard. È possibile scrivere regole di associazione per consentire l'accesso ai moduli di configurazione e amministrazione attraverso questa porta.
Quando la direttiva BindSpecific è attivata, Caching Proxy è associato alla porta specificata dalla direttiva Port insieme all'indirizzo IP derivato dal valore della direttiva Hostname. La porta specificata dalla direttiva AdminPort è associata a tutti gli indirizzi IP disponibili sul sistema.
Per ignorare il nome predefinito del server in esecuzione, quale IBM-PROXY o IBM_HTTP_SERVER, specificare un valore per la direttiva HeaderServerName . Questo valore popola il campo Risposte HTTP del server.
Per migliorare le prestazioni del proxy, è possibile impostare il valore della direttiva PureProxy su On. Questo disabilita completamente tutte le funzionalità di cache.
le seguenti direttive definiscono il processo del server proxy:
Per ulteriori informazioni, fare riferimento a Modifica manuale del file ibmproxy.conf.
I moduli di configurazione e amministrazione che seguono modificano i valori delle direttive associate:
Per ulteriori informazioni, fare riferimento a Utilizzo dei moduli di configurazione e amministrazione.
Quando un utente diverso dal superutente root avvia Caching Proxy, tale utente mantiene la proprietà di tutti i processi associati al server proxy. Tuttavia, se Caching Proxy viene avviato dal superutente root, una funzione impostata dell'ID utente sul server proxy legge le direttive UserId e GroupId nel file ibmproxy.conf e imposta la proprietà del processo all'utente e al gruppo specificati. Questo ha lo scopo di limitare l'accesso ai file e proteggere il computer. Se si modificano le direttive UserId o GroupId, è necessario aggiornare la proprietà e le autorizzazioni per le directory di log e gli altri file, quale una ACL (Access Control List), utilizzati dal server proxy.
Stabilire la proprietà del processo del specificando l'ID utente, l'ID gruppo e l'ubicazione del file in cui l'ID del processo viene registrato sotto forma di valori per le direttive UserID, GroupID e PidFile.
Per forzare l'esecuzione del processo del server proxy in primo piano, impostare il valore della direttiva NoBG su On.
Su sistemi Linux:
Sui sistemi Linux, verrà modificata la proprietà dei soli processi e thread responsabili dell'ascolto di connessioni. I processi e i thread responsabili di altre attività nel flusso di lavoro saranno ancora di proprietà dell'utente root. Tutti i processi e i thread ricevono numeri ID di processo (PID). Il comando ps elenca tutti gli ID di processo, a prescindere dalla loro associazione con un processo o un thread.
Impossibile inizializzare i gruppi per l'utente nobody, errore n.: 1
È possibile ignorare il messaggio di errore poiché non influisce sul normale funzionamento di Caching Proxy. È possibile risolvere il problema del messaggio di errore esportando le seguenti variabili di ambiente prima di avviare Caching Proxy:
esportare RPM_FORCE_NPTL=1 esportare LD_ASSUME_KERNEL=2.4.19:
Le direttive che seguono definiscono la proprietà del processo del server proxy:
Per ulteriori informazioni, fare riferimento a Modifica manuale del file ibmproxy.conf.
I moduli di configurazione e amministrazione che seguono modificano i valori delle direttive associate:
Per ulteriori informazioni, fare riferimento a Utilizzo dei moduli di configurazione e amministrazione.
Caching Proxy genera un nuovo thread per gestire ciascuna richiesta client. Se non ci sono thread disponibili, il server proxy mantiene in attesa le richieste fino a che non ottiene un maggior numero di thread disponibili. Man mano che il numero di thread attivi aumenta, il server proxy consuma più memoria. Specificare il numero massimo di thread attivi come valore della direttiva MaxActiveThreads.
Il backlog di ascolto è il numero di richieste in sospeso per le connessioni client, registrato dal server prima di rifiutare connessioni ai nuovi client. Basare questa impostazione sul numero di richieste che il server è in grado di elaborare in pochi secondi. Un server deve rispondere a una connessione client prima della sua scadenza. Specificare il numero massimo di connessioni che possono essere mantenute nel backlog come valore della direttiva ListenBacklog.
Il server proxy può mantenere connessioni client/server permanenti. Con una connessione permanente, il server accetta richieste multiple dal client e invia risposte attraverso la stessa connessione TCP/IP. L'uso delle connessioni permanenti riduce la latenza per i client e il carico per la CPU sul server proxy, con il costo minimo di un leggero aumento della memoria del server. La velocità di elaborazione generale aumenta quando il server non stabilisce una connessione TCP/IP distinta per ciascuna richiesta e risposta, e la connessione TCP/IP può essere utilizzata con la massima efficienza quando è permanente.
Il pooling di connessioni lato server applica i vantaggi delle connessioni permanenti lato server consentendo di riutilizzare le connessioni esistenti tra il server proxy e i server di origine. Ciascuna connessione riutilizzata risparmia tre pacchetti TCP (due pacchetti di sincronizzazione tridirezionali per impostare la connessione e uno per chiuderla). I vantaggi del lotto connessioni lato server comprendono:
Queste impostazioni mantengono aperte le connessioni ai server Web per tutto il tempo in cui sono in uso e consentono al proxy, anziché al server di origine, di gestire le connessioni. Di conseguenza, le connessioni vengono organizzate in lotti solo nella misura necessaria.
Quando il lotto connessioni lato server è abilitato, le connessioni HTTP ai server di origine vengono organizzate in lotti. Anche le connessioni SSL vengono organizzate in lotti nelle configurazioni in cui la direttiva SSLEnable per il proxy è impostata su On.
Configurare la modalità di gestione del lotto connessioni specificando il numero massimo di socket inattivi da mantenere per server in qualsiasi momento, il tempo di attesa del server prima di terminare una connessione permanente inattiva e l'intervallo con cui il thread di raccolta dati inutili verifica la presenza di connessioni scadute (il valore predefinito è di due minuti).
Definire il tempo in cui le varie connessioni rimangono aperte specificando i valori delle direttive InputTimeout, OutputTimeout, PersistTimeout, ReadTimeout e ScriptTimeout.
Le direttive che seguono gestiscono le connessioni con il processo del server proxy:
Per ulteriori informazioni, fare riferimento a Modifica manuale del file ibmproxy.conf.
I moduli di configurazione e amministrazione che seguono modificano i valori delle direttive associate:
Note:
Per ulteriori informazioni, fare riferimento a Utilizzo dei moduli di configurazione e amministrazione.
È possibile migliorare notevolmente le prestazioni di Caching Proxy impostando correttamente e ottimizzando il sistema. Di seguito vengono forniti alcuni suggerimenti per migliorare l'impostazione e l'ottimizzazione.
Le direttive che seguono influiscono in misura significativa sulle prestazioni del processo del server proxy:
I moduli di configurazione e amministrazione che seguono modificano i valori delle direttive associate:
Esaminare i servizi o daemon in esecuzione sul sistema e rimuovere quelli superflui per aumentare la memoria e i cicli della CPU a disposizione. Ad esempio, se sul sistema viene eseguito un server Web che fornisce solo poche pagine Web, considerare se è il caso di utilizzare solo caching Proxy come unico server Web. Disattivare altri server Web nel modo seguente:
Accertarsi che il sistema disponga di spazio di paginazione sufficiente a garantirne il corretto funzionamento. Il sistema richiede uno spazio di paginazione pari al doppio della memoria fisica. Se possibile, distribuire lo spazio di paginazione tra più unità fisiche. Ad esempio, un server Netfinity 5000 con 512 MB di memoria e cinque unità SCSI richiede 1 GB di spazio di paginazione totale, con circa 200 MB su ciascuna unità.
Caching Proxy crea ed elimina numerosi file durante il suo funzionamento. Se il server proxy registra gli accessi (mediante il log degli accessi, il log degli accessi del proxy o il log degli accessi alla cache), indirizzare i log a un file system dedicato in modo che, in caso di aumento improvviso, non utilizzino lo spazio destinato ad un'altra funzione, quale la cache.
Caching Proxy è sensibile alle modifiche apportate alle configurazioni TCP/IP. La riduzione dei valori TCP/IP su un sistema operativo potrebbe causare un funzionamento imprevisto del server proxy. Nello specifico, se i valori TCP/IP impostati sono troppo bassi, le connessioni potrebbero venire riavviate dai client che si connettono al server proxy o dai server di origine a cui si connette il proxy. Ciò accade soprattutto per i client che si connettono al server proxy attraverso una connessione a banda ridotta (56700 bps o meno). Se è necessario ridurre i parametri TCP/IP, agire con cautela.
L'intervallo di attesa TCP specifica il tempo durante il quale un socket resta in attesa di un pacchetto FIN dal mittente prima della chiusura forzata. Negli ambienti a carico elevato, il server proxy potrebbe sembrare bloccato se un gran numero di socket rimane in sospeso, nello stato TIME_WAIT, dopo la chiusura delle connessioni. La riduzione dell'intervallo di attesa TCP riduce il numero di socket in sospeso e, negli ambienti a carico elevato, può prevenire il blocco del server proxy. Si consiglia di impostare questo intervallo a 5 secondi.
Per impostare l'intervallo di attesa TCP a 5 secondi:
Emettere il seguente comando:
ndd /dev/tcp -set tcp_time_wait_interval 5000
Servirsi dell'utilità "sam" per impostare il parametro del kernel max_thread_proc a un valore di almeno 2048.
Immettere i seguenti comandi:
echo "1024 61000" > /proc/sys/net/ipv4/ip_local_port_range echo "5" > /proc/sys/net/ipv4/tcp_fin_timeout
Emettere il seguente comando:
ndd /dev/tcp -set tcp_time_wait_interval 5000
Modificare il file /etc/system perché appaia come segue:
set tcp:tcp_conn_hash_size=8129
Per impostare un tempo di attesa TCP, è necessario creare una voce del registro di configurazione. Per ulteriori informazioni, fare riferimento alla documentazione di Windows.
Diverse limitazioni nel kernel Linux sono basse e possono essere modificate. Alcune possono essere modificate attraverso il file system /proc, altre richiedono la ricompilazione del kernel.
Nota: il file system /proc è virtuale; ciò significa che non esiste fisicamente sul disco. Serve piuttosto da interfaccia per il kernel Linux. Poiché non esiste, i valori immessi vengono persi al riavvio. Di conseguenza, le modifiche che si desidera apportare al file system /proc devono essere inserite nel file /etc/rc.d/rc.local su RedHat o nel file /etc/rc.config su SUSE. In questo modo, le modifiche vengono sempre attivate al riavvio.
Di seguito vengono forniti alcuni consigli:
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
Se si decide di ricompilare il kernel, abilitare solo le opzioni assolutamente necessarie. Se uno specifico daemon non è necessario, non eseguirlo.
Sui sistemi AIX, è possibile migliorare le prestazioni di Caching Proxy utilizzando thread con ambito esteso all'intero sistema e consentendo l'uso di più heap da parte dei thread. Le prestazioni sono legate alla funzionalità multiprocessore del sistema operativo e alla pianificazione dei thread del sistema operativo sottostante. È possibile aumentare le prestazioni impostando le seguenti variabili di ottimizzazione dei thread su AIX nel modo qui riportato:
export AIXTHREAD_SCOPE=S export SPINLOOPTIME=500 export YIELDLOOPTIME=100 export MALLOCMULTIHEAP=1
È possibile impostare queste variabili d'ambiente prima di avviare /usr/sbin/ibmproxy oppure aggiungere a /etc/rc.ibmproxy se si utilizza il comando startsrc -s ibmproxy per avviare il server proxy. Il miglioramento delle prestazioni è più evidente su sistemi SMP ma in alcuni casi può essere chiaro anche su sistemi con un unico processore.
Questa sezione illustra le modalità di risposta del componente Caching Proxy alle richieste client e fornisce procedure per la configurazione di tale funzionamento. Questi elementi della configurazione del server proxy vengono normalmente gestiti da un amministratore Web e non influiscono sugli altri processi sul computer host o sui computer nella rete.
Questa sezione contiene i seguenti argomenti:
Gestione dell'elaborazione delle richieste
Gestione della consegna di contenuti locali
Gestione delle connessioni FTP
Personalizzazione dell'elaborazione server
Configurazione delle opzioni per le intestazioni
Informazioni sull'API (application programming interface)
Quando Caching Proxy riceve una richiesta client, esegue l'azione specificata nel campo metodo sull'oggetto specificato nel campo URL, se il metodo richiesto è stato abilitato. Il server proxy risolve l'URL in base a un insieme di regole di associazione definite dall'amministratore. Tali regole di associazione potrebbero fornire istruzioni a Caching Proxy perché agisca come server Web, recuperando l'oggetto dal file system locale, o come server proxy, recuperando l'oggetto da un server di origine.
In questa sezione viene descritto come abilitare i metodi, definire le regole di associazione e configurare un server proxy secondario.
Le richieste client al server comprendono un campo metodo che indica l'azione che il server deve eseguire sull'oggetto specificato.
Di seguito viene fornito un elenco di metodi supportati dal server proxy e una descrizione delle modalità di risposta a una richiesta client contenente il metodo, se quest'ultimo è attivato.
Per informazioni sul formato e sulle opzioni disponibili per il metodo Enable CONNECT, fare riferimento a Configurazione del tunneling SSL.
Il metodo POST è destinato alla gestione delle annotazioni di risorse esistenti. Gli esempi comprendono l'invio di un messaggio a una bacheca elettronica, a un gruppo di discussione, a una mailing list o analogo gruppo di risorse; l'immissione di un blocco di dati, ad esempio da un modulo a un programma di gestione dati; oppure l'estensione di un database mediante un'operazione di accodamento. Per Caching Proxy, il metodo POST viene utilizzato per elaborare i moduli di configurazione e amministrazione.
Questo metodo può essere gestito su connessioni permanenti.
L'attivazione del metodo PUT consente la scrittura di file su Caching Proxy mediante HTTP e FTP. Poiché PUT consente ai clienti di scrivere su Caching Proxy, è necessario utilizzare impostazioni di protezione del server per definire gli utenti autorizzati all'uso del metodo PUT e i file su cui tale metodo può essere applicato. Fare riferimento a Impostazioni di protezione del server.
Le direttive che seguono abilitano i metodi HTTP/FTP:
Per ulteriori informazioni, fare riferimento a Modifica manuale del file ibmproxy.conf.
I moduli di configurazione e amministrazione che seguono modificano i valori delle direttive associate:
Per ulteriori informazioni, fare riferimento a Utilizzo dei moduli di configurazione e amministrazione.
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
Oltre al supporto dei metodi HTTP standard, Caching Proxy supporta l'inoltro ddi altri metodi definiti nelle RFC o utilizzati da alcune applicazioni. Caching Proxy supporta inoltre i metodi definiti dai clienti e ne consente l'inoltro mediante il server proxy.
Web-based Distributed Authoring and Versioning (WebDAV) è una serie di estensioni del protocollo HTTP che consente di modificare e gestire in maniera collaborativa i file sui server Web remoti. Caching Proxy supporta i metodi WebDAV, i metodi utilizzati da Microsoft Exchange Server e i metodi definiti dall'utente (personalizzati).
Tali metodi sono codificati e gestiti dalle istruzioni Enable e Disable. Gli amministratori possono utilizzare la maschera di metodo corrispondente definita nell'istruzione PROTECT per autorizzare l'uso di questi metodi.
I metodi WebDAV supportati (RFC 2518) sono : PROPFIND , PROPPATCH , MKCOL, COPY, MOVE, LOCK, UNLOCK, SEARCH
I metodi MS Exchange supportati sono: BMOVE, BCOPY, BDELETE, BPROPFIND, BPROPPATCH, POLL, NOTIFY, SUBSCRIBE, UNSUBSCRIBE, ACL, SUBSCRIPTIONS, X_MS_ENUMATTS
Quando sono abilitati i metodi WebDAV o MS Exchange Server, Caching Proxy inoltra le richieste soltanto ai server di destinazione e non riscrive i collegamenti alle risorse nel corpo della richiesta.
Caching Proxy inoltra i metodi definiti dall'utente al server di back-end. Utilizzare la seguente sintassi per l'istruzione Enable nel file ibmproxy.conf per abilitare un metodo personalizzato:
Enable user-defined-method [WithBody | WithoutBody]
L'impostazione di un valore WithBody o WithoutBody indica al proxy se il metodo definito dall'utente ha bisogno di un corpo della richiesta.
Il seguente esempio abilita un metodo definito dall'utente My_METHOD e indica al proxy che tale metodo ha bisogno del corpo di una richiesta:
Enable MY_METHOD WithBody
Le seguenti direttive abilitano i metodi WebDAV, i metodi MS Exchange e i metodi definiti dall'utente:
Per ulteriori informazioni, fare riferimento a Modifica manuale del file ibmproxy.conf.
Le regole di associazione sono direttive di configurazione che fanno sì che le richieste client a Caching Proxy vengano elaborate in un certo modo, ad esempio inoltrate a un server di origine (meccanismo proxy), reindirizzate o respinte. L'impostazione corretta delle regole di associazione è importante per il corretto funzionamento di Caching Proxy. Le regole di associazione influiscono su quanto segue:
Le direttive per le regole di associazione utilizzano la forma che segue:
regola modello destinazione [indirizzo_IP | nome_host]:[porta]
Solo le richieste che corrispondono alla combinazione di maschera e IP/porta sono soggette alla regola. Una maschera può contenere caratteri jolly, ad esempio https://**/*.asp.
L'ordine con cui le direttive compaiono nel file di configurazione è significativo. Ad eccezione delle direttive Map, non appena viene rilevata una corrispondenza tra la richiesta e una maschera, la richiesta viene elaborata senza valutare le regole successive. La direttiva Map sostituisce l'URL nella richiesta. Questa nuova richiesta viene ancora confrontata con le restanti regole di associazione.
Le seguenti regole di associazione si applicano alle richieste client che corrispondono alla maschera specificata:
La regola di associazione seguente si applica alla risposta del server di origine:
Le regole di associazione che seguono sono valide per le applicazioni API:
Per configurare un surrogato standard:
Porta 80
Proxy /* http://server.di.contenuti.com/* :80
AdminPort 8080
Ciò consente l'invio tramite proxy di tutto il traffico HTTP sulla porta 80 al server di origine. Il traffico in entrata sulla porta di amministrazione non corrisponde alla regola proxy con caratteri jolly iniziale, per cui non viene inoltrato. Le restanti regole di associazione vengono utilizzate per elaborare la richiesta.
Le direttive che seguono definiscono le regole di associazione:
Per ulteriori informazioni, fare riferimento a Modifica manuale del file ibmproxy.conf.
I moduli di configurazione e amministrazione che seguono modificano i valori delle direttive associate:
Per ulteriori informazioni, fare riferimento a Utilizzo dei moduli di configurazione e amministrazione.
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
La direttiva JunctionRewrite consente alla routine di riscrittura delle giunzioni in Caching Proxy di riscrivere le risposte dai server di origine per garantire che gli URL relativi al server vengano mappati sul server di origine adeguato quando si utilizzano le giunzioni. È necessario abilitare anche il plug-in di riscrittura delle giunzioni. Le giunzioni vengono definite dalle regole di associazione del proxy.
Quando si utilizzano le regole di associazione del proxy per definire la giunzione, la direttiva Proxy può essere utilizzata con o senza l'opzione JunctionPrefix.
Di seguito vengono forniti esempi di giunzioni valide su cui è possibile agire mediante la routine di riscrittura delle giunzioni:
Di seguito viene fornito un esempio di una giunzione valida su cui non agisce la routine di riscrittura delle giunzioni:
Di seguito vengono forniti alcuni esempi di giunzioni non valide:
Queste regole di associazione hanno creato giunzioni per shopserver, authserver e b2bserver. Considerare che shopserver restituisce un documento HTML con i seguenti URL contenuti nei tag HTML adeguati:
La routine di riscrittura delle giunzioni sovrascrive i riferimenti relativi al server utilizzando le regole di associazione del proxy nel modo seguente:
Quando si utilizza l'opzione JunctionPrefix con la direttiva Proxy, anziché dedurre JunctionPrefix dal primo schema di URL nella regola Proxy, è possibile dichiarare il prefisso di giunzione nella regola Proxy utilizzando il formato seguente:
Proxy url_patern1 url_pattern2 JunctionPrefix:url_prefix
Quando si utilizza JunctionPrefix, non vi è alcun limite al formato del primo schema URL. Per supportare la riscrittura delle giunzioni quando non si utilizza l'opzione JunctionPrefix, l'URL proxy deve avere il formato seguente: Proxy /market/* http://b2bserver/*. Tuttavia, quando si utilizza JunctionPrefix, la regola Proxy seguente è valida per la riscrittura delle giunzioni:
Proxy /market/partners/*.html http://b2bserver.acme.com/*.html junctionprefix:/market/partners
La routine di riscrittura delle giunzioni influisce sui seguenti tag:
Tabella 3. Tag interessate dalla rountine junction rewriting
Tag | Attributi |
---|---|
!-- | 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 |
Le direttive che seguono vengono utilizzate per abilitare la routine e il plug-in di riscrittura delle giunzioni.
Per ulteriori informazioni, fare riferimento a Modifica manuale del file ibmproxy.conf.
Il seguente modulo di configurazione e amministrazione può essere utilizzato per abilitare il plug-in di riscrittura delle giunzioni:
Per ulteriori informazioni, fare riferimento a Utilizzo dei moduli di configurazione e amministrazione.
È possibile utilizzare i cookie per memorizzare le informazioni del server di back-end nel modo seguente: viene inviato un cookie al browser del client. Quando il browser invia richieste per risorse nella pagina HTML, allega un cookie per cui Caching Proxy inoltra le richieste al server di back-end corretto.
Per utilizzare i cookie come alternativa a JunctionRewrite, apportare le seguenti modifiche al file ibmproxy.conf:
Di seguito viene fornito un confronto del plug-in JunctionRewrite e dell'implementazione con cookie.
Proxy /no-juntion.jpg http://login-server/no-junction.jpg
Viene fornito del codice di esempio personalizzabile che riscrive e analizza i blocchi di tag JavaScript(TM) (SCRIPT) e applet (APPLET) nei file HTML. Da solo,il plugin JunctionRewrite non è in grado di elaborare i collegamenti alle risorse in JavaScript o nei valori di parametri di Java(TM).
Dopo aver installato Caching Proxy, è possibile compilare lo stesso codice e configurarlo per l'esecuzione con JunctionRewrite.
I seguenti file di esempio si trovano nella sottodirectory ...samples/cp/, all'interno della directory in cui è stato scaricato il fix pack.
Le regole di associazione Pass e Exec vengono utilizzate per fornire contenuti locali a un client che ne fa richiesta. Per impostazione predefinita, una regola Pass con una maschera jolly viene collocata come ultima regola di associazione. Questa regola indirizza tutte le richieste che non soddisfano le maschere precedenti perché recuperino i file da una directory di destinazione, detta generalmente directory root dei documenti.
Quando viene ricevuto un URL che non contiene un nome file, soddisfa la richiesta ricercando nella directory specificata, se presente, o nella directory root dei documenti, se non viene specificata una directory, un file corrispondente all'elenco di pagine di benvenuto specificato nel file di configurazione. Se viene definita più di una pagina di benvenuto,il server proxy ricerca le pagine nell'ordine con cui sono definite. La prima pagina di benvenuto individuata viene fornita al client.
La pagina iniziale del server è la pagina Web che il server fornisce per impostazione predefinita quando riceve una richiesta contenente solo l'URL del server, senza una directory o un nome file. Come spiegato in precedenza, la regola di associazione jolly predefinita richiede la memorizzazione della pagina iniziale del server nella directory root dei documenti e la corrispondenza del nome file della pagina iniziale con una pagina di benvenuto definita.
In questa sezione viene descritto come definire la directory root dei documenti e le pagine di benvenuto.
Le directory root dei documenti predefinite sono:
Le direttive che seguono definiscono la directory root dei documenti:
Per ulteriori informazioni, fare riferimento a Modifica manuale del file ibmproxy.conf.
Per modificare la directory root dei documenti nei moduli di configurazione e amministrazione, utilizzare la procedura seguente:
Dopo il riavvio, il server comincia a utilizzare la nuova directory root dei documenti.
Per ulteriori informazioni, fare riferimento a Utilizzo dei moduli di configurazione e amministrazione.
Il server ricerca la pagina iniziale nella directory root dei documenti, ma il file specifico restituito viene definito dall'elenco delle pagine di benvenuto.
Informazioni sulle pagine di benvenuto
Quando il server riceve una richiesta URL che non specifica un nome file, tenta di soddisfarla in base a un elenco di pagine di benvenuto impostato nel file di configurazione del server. Tale elenco definisce i file da utilizzare come pagine iniziali predefinite. Il server determina la pagina iniziale mediante una corrispondenza tra l'elenco di pagine di benvenuto e i file nella directory root dei documenti. La prima corrispondenza individuata è il file restituito come pagina iniziale. Se non viene individuata alcuna corrispondenza, il server visualizza un elenco dei contenuti della directory root dei documenti.
Per utilizzare un determinato file come pagina iniziale del server e restituirlo quando una richiesta non specifica né una directory, né un nome file, è necessario collocarlo nella directory root dei documenti e accertarsi che il suo nome corrisponda a uno dei nomi file presenti nell'elenco delle pagine di benvenuto.
Il file di configurazione predefinito definisce questi nomi file, in quest'ordine, per l'uso come pagine di benvenuto:
Il server restituisce il primo file che individua come corrispondente a un nome file nell'elenco. Fino a che non viene creato un file welcome.html o index.html, collocandolo nella directory root dei documenti, il server utilizza Frntpage.html come pagina iniziale.
Ad esempio, se si utilizza la configurazione predefinita e la directory root dei documenti non contiene un file denominato welcome.html, ma contiene file denominati index.html e FrntPage.html, il file index.html viene utilizzato come pagina iniziale.
Se non viene individuata una pagina iniziale, viene visualizzata la struttura della directory root dei documenti.
Le direttive che seguono definiscono le pagine di benvenuto:
Per ulteriori informazioni, fare riferimento a Modifica manuale del file ibmproxy.conf.
Il seguente modulo di configurazione e amministrazione definisce le pagine di benvenuto:
Per ulteriori informazioni, fare riferimento a Utilizzo dei moduli di configurazione e amministrazione.
Queste informazioni sono valide solo per le configurazioni di proxy diretto.
Caching Proxy funge da proxy per le richieste di URL FTP e le inoltra al server FTP adeguato, ma non può essere utilizzato per inoltrare via proxy le richieste da un client FTP. Può supportare solo le richieste FTP ricevute da un client HTTP (utilizzando lo schema di protocollo ftp://).
Solo i metodi GET, PUT e DELETE sono supportati per le richieste di file FTP. Solo il metodo GET è supportato per le richieste di elenchi di directory FTP. Per impostazione predefinita, le direttive PUT e DELETE sono disabilitate in Caching Proxy. Per ulteriori informazioni, fare riferimento a Abilitazione dei metodi HTTP/FTP.
In questa sezione viene descritto come proteggere i file FTP e gestire i login al server, i percorsi di directory e il concatenamento FTP.
Se è stato abilitato il metodo PUT per il caricamento dei file FTP o il metodo DELETE per la loro eliminazione, è necessario definire la protezione proxy FTP almeno per le richieste PUT e DELETE, per impedire l'aggiornamento non autorizzato dei file sul server FTP.
Per proteggere l'inoltro tramite proxy delle richieste FTP, nei moduli di configurazione e amministrazione, selezionare Configurazione server -> Protezione documenti. Per creare un'impostazione di protezione per le richieste di file FTP, includere ftp:// all'inizio della maschera di richiesta. Ad esempio, per proteggere i file in una directory denominata esami, utilizzare la maschera ftp://esami/*.
Per ulteriori informazioni sulla creazione di impostazioni di protezione, fare riferimento a Impostazioni di protezione server.
Se non vengono specificati un ID utente e una password nell'URL della richiesta, Caching Proxy tenta di accedere al server FTP richiesto in modo anonimo, utilizzando l'ID utente ANONYMOUS. Molti server FTP richiedono un indirizzo e-mail come password per FTP anonimo. Se il server FTP richiede una password per il login anonimo, Caching Proxy invia l'indirizzo e-mail specificato dalla direttiva WebmasterEmail nel file di configurazione.
Per impostare l'indirizzo e-mail del Webmaster nei moduli di configurazione e amministrazione, selezionare Configurazione server -> Gestione del sistema -> MIB SNMP. L'indirizzo e-mail può essere impostato anche utilizzando la direttiva WebmasterEmail; per i dettagli, vedere la sezione di riferimento: WebMasterEMail -- Imposta un indirizzo e-mail per ricevere i report di server selezionati.
Se il server FTP nell'URL della richiesta prevede una combinazione specifica di ID utente e password per consentire l'accesso, gli utenti possono immettere l'ID e la password nell'URL della richiesta, ad esempio:
ftp://IDutente:password@hostserverftp/
Se non si desidera specificare la password per l'ID utente FTP nell'URL della richiesta, gli utenti possono immettere solo l'ID utente nell'URL: ftp://IDutente@ hostserverftp. Caching Proxy tenta dapprima di accedere al server FTP con l'ID utente specificato, senza password. Se il login ha esito negativo senza una password, il browser richiede la password associata all'ID utente specificato.
Per i login non anonimi, è necessario specificare almeno l'ID utente nell'URL. Se l'ID utente non viene specificato, viene tentato il login anonimo e al client non viene richiesto l'ID utente.
È necessario specificare in Caching Proxy se si desidera interpretare i nomi percorso negli URL FTP come relativi alla directory di lavoro dell'utente o alla directory root. Ad esempio, se un utente che accede a un server FTP ha una directory di lavoro predefinita denominata /export/home/user1 e desidera recuperare un file denominato test1.exe da una sottodirectory denominata test, il proxy utilizza gli URL seguenti per recuperare il file dal server FTP, a seconda di come vengono interpretati gli URL FTP:
Se vengono impostati percorsi URL FTP relativi, gli utenti possono ancora specificare un nome percorso assoluto utilizzando la convenzione di accodare al carattere slash iniziale (/) la notazione %2F, che indica la directory root. Ad esempio, se user1, la cui directory di lavoro è /export/home/user1, desidera accedere a un file nella directory di lavoro di user2, /export/home/user2, la richiesta ftp://user1:user1pw@FTPhost/%2Fexport/home/user2/ file viene interpretata correttamente come un URL relativo alla directory root /, ossia, un nome percorso assoluto, anche se sono stati scelti i nomi percorso URL FTP relativi.
Per specificare in che modo debbano essere interpretati gli URL FTP, nei moduli di configurazione e amministrazione, selezionare Configurazione proxy -> Prestazioni proxy. Nella parte inferiore del modulo, in I percorsi URL FTP URL devono essere:, selezionare percorsi assoluti per specificare la directory root del server, oppure percorsi relativi per specificare la directory di lavoro dell'utente come inizio del percorso.
Questa impostazione può essere modificata anche nel file di configurazione del proxy; per ulteriori informazioni, vedere FTPUrlPath -- Specifica il modo in cui sono interpretati gli URL FTP.
Se si concatenano più server Web proxy tra loro, è possibile specificare che le richieste contenenti URL FTP vengano inviate a un server Web proxy concatenato, anziché direttamente al server FTP. Per specificare un server proxy concatenato per le richieste FTP, nei moduli di configurazione e amministrazione, selezionare Configurazione proxy -> Concatenamento proxy e domini non proxy. Lo schema di protocollo http:// viene utilizzato per specificare l'URL del proxy concatenato, anche quando il concatenamento richiede uno schema di protocollo ftp://.
Per configurare il concatenamento FTP mediante il file di configurazione proxy, fare riferimento alla sezione ftp_proxy -- Specifica un altro server proxy per le richieste FTP.
Questa sezione descrive l'utilizzo dell'inclusione di informazioni lato server per inserire informazioni nei programmi CGI e nei documenti HTML forniti a un client. Vengono inoltre illustrate la personalizzazione dei messaggi di errore del server e la associazione delle risorse.
L'inclusione di informazioni lato server consente di aggiungere informazioni ai programmi CGI e ai documenti HTML inviati dal server al client quando agisce come server di origine, ossia non per oggetti inviati tramite proxy o memorizzati nella cache. La data corrente, le dimensioni di un file, la data di ultima modifica sono esempi del tipo di informazioni che possono essere trasmesse al client. Questa sezione descrive il formato dei comandi per l'inclusione di informazioni lato server e illustra il funzionamento dei comandi di inclusione di informazioni lato server nei programmi CGI e nei documenti HTML. È inoltre possibile utilizzare l'inclusione di informazioni lato server per personalizzare le pagine di errore.
Prima di utilizzare l'inclusione di informazioni lato server sul server, prendere in considerazione le problematiche legate alle prestazioni, alla sicurezza e ai rischi:
Per abilitare l'inclusione di informazioni lato server, nei moduli di configurazione e amministrazione, selezionare Configurazione server -> Impostazioni di base. Utilizzare questo modulo per specificare quali tra i seguenti tipi di inclusione di informazioni lato server sono accettabili:
Utilizzare questo modulo anche per specificare se eseguire l'elaborazione dell'inclusione lato server per i documenti di testo o HTML oltre agli altri tipi di file.
Inoltre, accertarsi che l'estensione file utilizzata per l'inclusione sia riconosciuta. Nei moduli di configurazione e amministrazione, selezionare Configurazione server -> Tipi MIME e codifica quindi utilizzare il modulo Tipi MIME. Notare che le estensioni shtml e htmls sono riconosciute per impostazione predefinita.
Per configurare il server per l'inclusione di informazioni lato server mediante la modifica delle direttive nel file di configurazione del proxy, vedere le sezioni di riferimento dedicate alle seguenti direttive:
I comandi di inclusione devono essere inseriti nel documento HTML o nel programma CGI come commenti. I comandi hanno il formato seguente:
<!--#tag direttiva=valore ... --> o <!--#tag direttiva="value" ... -->
Le virgolette intorno ai valori sono facoltative, ma necessarie per incorporare spazi.
Questa sezione illustra le direttive accettate dal server per l'inclusione di informazioni lato server. Non confondere queste direttive con le direttive per il file di configurazione del proxy, descritte in Appendice B, Direttive del file di configurazione.)
config -- Elaborazione del file di controllo
Utilizzare questa direttiva per controllare determinati aspetti dell'elaborazione dei file. I tag validi sono cmntmsg, errmsg, sizefmt e timefmt.
Esempio:
<!--#config cmntmsg="[This is a comment]" --> <!-- #echo var=" " extra text -->
Risultato: <!--[This is a comment] extra text -->
Predefinito: [quanto segue era estraneo alla direttiva]
Esempio:
<!-- #config errmsg="[An error occurred]" -->
Predefinito: "[Si è verificato un errore durante l'elaborazione di questa direttiva]"
Esempio 1:
<!--#config sizefmt=bytes --> <!--#fsize file=foo.html -->
Risultato: 1024
Esempio 2:
<!--#config sizefmt=abbrev --> <!--#fsize file=foo.html -->
Risultato: 1K
Predefinito: "abbrev"
Esempio:
<!--#config timefmt="%D %T" --> <!--#flastmod file=foo.html -->
Risultato: "10/18/95 12:05:33"
Predefinito: "%a, %d %b %Y %T %Z"
I seguenti formati strftime()
sono validi con il tag timefmt:
Identificatore | Significato |
---|---|
%% | Sostituisci con % |
%a | Sostituisci con il giorno della settimana abbreviato |
%A | Sostituisci con il giorno della settimana in forma estesa |
%b | Sostituisci con il nome del mese abbreviato |
%B | Sostituisci con il nome del mese in forma estesa |
%c | Sostituisci con la data e l'ora |
%C | Sostituisci con il numero di secolo (anno diviso 100 e troncato) |
%d | Sostituisci con il giorno del mese (01-31) |
%D | Inserire la data come%m/%d/%y |
%e | Inserisci il mese dell'anno come numero decimale (01-12) (Solo in C POSIX, si tratta di un campo a due caratteri, con allineamento a destra e riempimento vuoto) |
%E[cCxyY] | Se il formato di data/ora alternativo non è disponibile, i descrittori %E vengono mappati sulle loro controparti abbreviate (ad esempio, %EC viene mappato su %C) |
%Ec | Sostituisci con la rappresentazione alternativa di data e ora |
%EC | Sostituisci con il nome dell'anno base (periodo) nella rappresentazione alternativa |
%Ex | Sostituisci con la rappresentazione alternativa della data |
%EX | Sostituisci con la rappresentazione alternativa dell'ora |
%Ey | Sostituisci con l'offset da %EC (solo anno) nella rappresentazione alternativa |
%EY | Sostituisci con la rappresentazione alternativa dell'anno completa |
%h | Sostituisci con il nome del mese abbreviato (lo stesso che %b) |
%H | Sostituisci con l'ora (formato 0-24) come numero decimale (00-23) |
%I | Sostituisci con l'ora (formato 0-12) come numero decimale (00-12) |
%j | Sostituisci con il giorno dell'anno (001-366) |
%m | Sostituisci con il mese (01-12) |
%M | Sostituisci con il minuto (00-59) |
%n | Sostituisci con una nuova riga |
%O[deHlmMSUwWy] | Se il formato di data/ora alternativo non è disponibile, i descrittori %E vengono mappati sulle loro controparti abbreviate (ad esempio, %Od viene mappato su %d) |
%Od | Sostituisci con il giorno del mese, utilizzando i simboli numerici alternativi, con il numero di zeri di riempimento iniziali adeguato se è previsto un simbolo alternativo allo zero, altrimenti con spazi |
%Oe | Sostituisci con il giorno del mese, utilizzando i simboli numerici alternativi, con spazi di riempimento iniziali |
%OH | Sostituisci con l'ora (formato 0-24), utilizzando i simboli numerici alternativi |
%OI | Sostituisci con l'ora (formato 0-12), utilizzando i simboli numerici alternativi |
%Om | Sostituisci con il mese, utilizzando i simboli numerici alternativi |
%OM | Sostituisci con i minuti, utilizzando i simboli numerici alternativi |
%OS | Sostituisci con i secondi, utilizzando i simboli numerici alternativi |
%OU | Sostituisci con il numero di settimana dell'anno (Domenica come primo giorno della settimana, regole corrispondenti a %U), utilizzando i simboli numerici alternativi |
%Ow | Sostituisci con il giorno della settimana (Domenica=0), utilizzando i simboli numerici alternativi |
%OW | Sostituisci con il numero di settimana dell'anno (Lunedì come primo giorno della settimana), utilizzando i simboli numerici alternativi |
%Oy | Sostituisci con l'anno (offset da %C) nella rappresentazione alternativa e utilizzando i simboli numerici alternativi |
%p | Sostituisci con l'equivalente locale di AM o PM |
%r | Sostituisci con la stringa equivalente a %I:%M:%S %p |
%R | Sostituisci con la notazione oraria 0-24 (%H:%M) |
%S | Sostituisci con i secondi (00-61) |
%t | Sostituisci con un carattere di tabulazione |
%T | Sostituisci con una stringa equivalente a %H:%M:%S |
%u | Sostituisci con il giorno della settimana come numero decimale (1-7), con 1 che rappresenta Lunedì |
%U | Sostituisci con il numero di settimana dell'anno (00-53), dove Domenica è il primo giorno della settimana |
%V | Sostituisci con il numero di settimana dell'anno (01-53), dove Lunedì è il primo giorno della settimana |
%w | Sostituisci con il giorno della settimana (0-6), dove Domenica è 0 |
%W | Sostituisci con il numero di settimana dell'anno (00-53), dove Lunedì è il primo giorno della settimana |
%x | Sostituisci con la rappresentazione adeguata della data |
%X | Sostituisci con la rappresentazione adeguata dell'ora |
%y | Sostituisci con il numero di due cifre dell'anno all'interno del secolo |
%Y | Sostituisci con il numero dell'anno completo di 4 cifre |
%Z | Sostituisci con il nome del fuso orario o con nessun carattere se il fuso orario non è noto |
La configurazione del sistema operativo determina i nomi completi e abbreviati dei mesi e gli anni.
echo--valori della variabile di visualizzazione
Utilizzare questa direttiva per visualizzare il valore delle variabili d'ambiente specificate con il tag var. Se non viene rilevata una variabile, viene visualizzato (Nessuna). Inoltre, echo può visualizzare un valore impostato dalle direttive set o global. Le seguenti variabili di ambiente possono essere visualizzate:
Esempio:
<!--#echo var=SSI_DIR -->
exec--specifica di programmi CGI
Utilizzare questa direttiva per includere l'output di un programma CGI. La direttiva exec scarta eventuali intestazioni HTTP prodotte dal programma CGI tranne le seguenti:
cgi--specifica dell'URL del programma CGI
Utilizzare questa direttiva per specificare l'URL di un programma CGI.
In questo esempio, program è il programma CGI da eseguire, path_info e query_string rappresentano uno o più parametri passati al programma come variabili d'ambiente:
<!--#exec cgi="/cgi-bin/program/path_info?query_string" -->
Questo esempio illustra l'uso delle variabili:
<!--#exec cgi="&path;&cgiprog;&pathinfo;&querystring;" -->
flastmod--visualizza la data e l'ora dell'ultima modifica del documento
Utilizzare questa direttiva per visualizzare la data e l'ora dell'ultima modifica apportata al documento. La formattazione di questa variabile viene definita dalla direttiva config timefmt. I tag file e virtual sono validi con questa direttiva e i relativi significati sono definiti nel modo seguente.
Formati direttive:
<!--#flastmod file="/percorso/file" --> <!--#flastmod virtual="/path/file" -->
<!--#flastmod file="/percorso/file" -->
<!--#flastmod virtual="/path/file" -->
Esempio:
<!--#flastmod file="foo.html" -->
Risultato: 12Maggio96
fsize--visualizza la dimensione del file
Utilizzare questa direttiva per visualizzare le dimensioni del file specificato. La formattazione di questa variabile viene definita dalla direttiva config sizefmt. I tag file e virtual sono validi per questa direttiva, e i relativi significati sono identici a quelli definiti in precedenza per la direttiva flastmod.
Esempio:
<!--#fsize file="/percorso/file" --> <!--#fsize virtual="/percorso/file" -->
Risultato: 1K
global--definisce le variabili globali
Utilizzare questa direttiva per definire variabili globali che possono essere successivamente sottoposte all'operazione echo da parte di questo file o di eventuali file inclusi.
Esempio:
<!--#global var=nomevariabile value="valore" -->
Ad esempio, per fare riferimento a un documento parent oltre il limite virtuale, è necessario impostare una variabile globale DOCUMENT_URI. Inoltre, è necessario fare riferimento alla variabile globale nel documento child. Questo esempio illustra il codice HTML da inserire nel documento parent:
<!--#global var="PARENT_URI" value=&DOCUMENT_URI; -->
Questo esempio illustra il codice HTML da inserire nel documento child:
<!--#flastmod virtual=&PARENT_URI; -->
include--include un documento nell'output
Utilizzare questa direttiva per includere il testo di un documento nell'output. I tag file e virtual sono validi con questa direttiva e i relativi significati sono identici a quelli definiti in precedenza per la direttiva flastmod.
set--imposta le variabili che devono essere echo
Utilizzare questa direttiva per impostare una variabile che può essere sottoposta a echo in un secondo momento, ma solo da parte di questo file.
Esempio:
<!--#set var="Variabile 2" value="AltroValore" -->
Durante la definizione di una direttiva, è possibile sottoporre a echo una stringa nel mezzo di value. Ad esempio:
<!--#include file="&nomefile;" -->
Variabili: una direttiva di impostazione lato server è generalmente seguita da una direttiva echo, in modo che ricerchi la variabile impostata, indichi dove si trova e proceda con la funzione. Può contenere riferimenti multipli a variabili. Le impostazioni lato server consentono inoltre di sottoporre a echo una variabile già impostata. Se non viene rilevata una variabile impostata, non viene visualizzato nulla.
Quando una impostazione lato server incontra un riferimento variabile all'interno di una direttiva di inclusione di informazioni lato server, tenta di risolverlo sul lato server. Nella seconda riga dell'esempio seguente, la variabile lato server &index; viene utilizzata con la stringa var per creare il nome della variabile var1. Alla variabile &var1; viene quindi assegnato un valore inserendo un carattere escape prima di & in ê in modo che non venga riconosciuto come una variabile. Viene invece utilizzato come una stringa per creare il valore frêd o fred con un accento circonflesso sulla e. La variabile ê è una variabile lato client.
<!--#set var="index" value="1" --> <!--#set var="var&index;" value="fr\êd" --> <!--#echo var="var1" -->
I caratteri che possono essere preceduti da escape (detti variabili escape) sono preceduti da un carattere backslash (\) e comprendono quanto segue:
Carattere | Significato |
---|---|
\a | Avviso (campanello) |
\b | Backspace |
\f | Alimentazione modulo (nuova pagina) |
\n | Nuova riga |
\r | Ritorno a capo |
\t | Tabulazione orizzontale |
\v | Tabulazione verticale |
\' | Virgoletta singola |
\" | Virgoletta doppia |
\? | Punto interrogativo |
\\ | Backslash |
\- | Trattino |
\. | Punto |
\& | Asterisco |
È possibile personalizzare i messaggi di errore restituiti da Caching Proxy e definire messaggi specifici per particolari condizioni di errore. Nei moduli di configurazione e amministrazione, selezionare Configurazione server -> Personalizzazione dei messaggi di errore. Utilizzare questo modulo per selezionare una condizione di errore e specificare un particolare file HTML da utilizzare per tale condizione.
Per personalizzare i messaggi di errore modificando le direttive nel file di configurazione del proxy, vedere la sezione di riferimento dedicata alla direttiva ErrorPage -- Specifica un messaggio personalizzato per una determinata condizione di errore.
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
WebSphere Application Server, versione 7.0 introduce il supporto streaming media sotto forma di Redirector RTSP. RTSP consente a Caching Proxy di agire come il primo punto di contatto con i media player e di reindirizzare le loro richieste a un adeguato server proxy o a un server di contenuti che fornisce il contenuto multimediale richiesto.
RTSP, il protocollo Real Time Streaming, è definito nella RFC 2326. Si tratta di un protocollo Internet standard per il controllo dei flussi di dati. Sebbene non includa tecnologie per la consegna dei flussi, è abbastanza flessibile da poter essere utilizzato per controllare i flussi di dati che non hanno a che fare con la riproduzione video o audio.
La funzione di reindirizzamento RTSP consente a Caching Proxy di reindirizzare le richieste per qualsiasi sessione di streaming multimediale controllata da RTSP. Sono inclusi i seguenti tipi di elementi multimediali:
Qualsiasi lettore configurabile per contattare un server proxy sulla sua porta RTSP, normalmente la 554, può utilizzare questo framework in Caching Proxy per far gestire le proprie richieste dal reindirizzamento RTSP.
Il reindirizzamento RTSP non memorizza nella cache, né agisce come proxy diretto per le presentazioni multimediali. Deve essere utilizzato insieme a un server per audio e/o video in streaming per fornire una o entrambe queste funzioni. Caching Proxy con il reindirizzamento RTSP deve avere accesso in rete a uno o più server proxy RTSP.
Questa funzione è soggetta alla seguente limitazione:
Attualmente, sono supportate solo le tecnologie RealNetworks. Queste comprendono il server proxy RealProxy, il server di origine RealServer e il lettore multimediale RealPlayer.
In precedenza, il reindirizzamento RTSP era soggetto a una limitazione per cui tutte le richieste per lo stesso server di origine, per qualsiasi URL, venivano reindirizzate allo stesso modo. Il reindirizzamento basato su nome file o altre parti dell'URL richiesto non era possibile. Questa limitazione è stata superata. Il reindirizzamento RTSP utilizza ora l'URL completo delle richieste ricevute, insieme al valore di soglia (rtsp_proxy_threshold) impostato nel file di configurazione di Caching Proxy per stabilire se reindirizzare la richiesta client al server di origine o a un server proxy. Le richieste allo stesso server di origine vengono ora gestite singolarmente.
Le direttive del file di configurazione che seguono vengono utilizzate per controllare il reindirizzamento RTSP. Le impostazioni per queste direttive non vengono aggiornate con il semplice riavvio del server. Il server dev'essere totalmente arrestato e quindi avviato per rendere effettive le modifiche a queste direttive.
Quando richiedono documenti, i client Web inviano intestazioni che forniscono ulteriori informazioni sul browser o la richiesta. Le intestazioni vengono generate automaticamente all'invio di una richiesta.
Caching Proxy mette a disposizione diverse opzioni per la personalizzazione delle informazioni nelle intestazioni per mantenerle nascoste al server di destinazione. Anche se la sostituzione dell'intestazione effettiva con una più generica presenta il vantaggio di aumentare l'anonimato del client, ha anche lo svantaggio di impedire la personalizzazione della pagina in base all'intestazione, prevista per alcune pagine Web.
Le intestazione utilizzano normalmente la forma che segue:
User-Agent: Mozilla 2.02/OS2 Client-IP: 45.37.192.3 Refer: http://www.bigcompany.com/WebTrafficExpress/main.html
Questa intestazione comprende i seguenti campi:
Per la maggior parte, è possibile bloccare le intestazioni mediante adeguate impostazioni della configurazione del proxy. Tuttavia, alcuni campi dell'intestazione sono necessari per il server di origine, per cui bloccandoli le pagine Web potrebbero venire visualizzate in modo errato; ad esempio, in alcuni casi il blocco del campo "host" dell'intestazione fa sì che gli utenti visualizzino la pagina Web sbagliata. Per ulteriori informazioni sui campi dell'intestazione, fare riferimento alla specifica HTTP Versione 1.1.
Per modificare le opzioni di intestazione mediante la modifica del file di configurazione proxy, vedere le sezioni di riferimento dedicate alle seguenti direttive:
Per ulteriori informazioni, fare riferimento a Modifica manuale del file ibmproxy.conf.
È possibile utilizzare due moduli di configurazione e amministrazione per specificare le opzioni di intestazione:
Selezionare questa casella per consentire l'inoltro dell'indirizzo IP del client richiedente al server di destinazione (dei contenuti). Se non si seleziona questa casella, il server di destinazione riceve l'indirizzo IP del server proxy. Lasciando questa casella deselezionata si aumenta l'anonimato del client durante la navigazione sul Web.
Digitare la stringa da inviare nell'intestazione al server di destinazione in sostituzione del tipo di browser e del sistema operativo in uso su un client. Ad esempio: specificando Caching Proxy 4.0 si sostituisce Mozilla 2.02/OS2 nell'intestazione seguente:
Content-Type:MIME User-Agent: Mozilla 2.02/OS2 Referer: http://www.ics.raleigh.ibm.com/WebTrafficExpress/main.html Pragma:no-cache
Immettere l'indirizzo di e-mail letto dal server di destinazione durante l'analisi dell'intestazione "From:". Si potrebbe voler specificare l'indirizzo di e-mail dell'amministratore del proxy, dal momento che l'amministratore è la persona che deve ricevere le segnalazioni di eventuali problemi.
Per ulteriori informazioni, fare riferimento a Utilizzo dei moduli di configurazione e amministrazione.
L'API (application programming interface) viene illustrata dettagliatamente nel manuale Guida alla programmazione di Edge Components. Le direttive API contenute nel file di configurazione abilitano le routine plug-in richiamate durante le fasi specifiche nel flusso di elaborazione delle richieste. Queste routine plug-in possono sostituire le routine incorporate o essere eseguite in aggiunta.
Di seguito sono riportate le direttive API:
Per ulteriori informazioni, fare riferimento a Modifica manuale del file ibmproxy.conf.
I moduli di configurazione e amministrazione che seguono modificano i valori delle direttive associate:
Per ulteriori informazioni, fare riferimento a Utilizzo dei moduli di configurazione e amministrazione.
Questa sezione illustra la cache del proxy e le relative modalità di configurazione. La cache può essere impostata per l'archiviazione dei file in memoria (cache in memoria) o su uno o più dispositivi di memorizzazione (cache su disco). È possibile configurare un agente di aggiornamento della cache per eseguire il caricamento preventivo nella cache dei file richiesti di frequente e applicare diversi filtri URL al processo di memorizzazione nella cache. Inoltre, questa sezione illustra la condivisione della cache mediante l'uso dell'accesso remoto alla cache o del plugin ICP (Internet caching protocol), la rimozione dei file obsoleti con la raccolta dati inutili della cache, e la memorizzazione nella cache dei file generati in modo dinamico.
Questa sezione contiene i seguenti argomenti:
La memorizzazione nella cache è una funzione in base alla quale il server proxy salva le copie locali dei file che i client richiedono; in questo modo, il server può fornirle velocemente prendendole dalla cache quando vengono richieste da quei client o da altri.
Caching Proxy è compatibile con HTTP 1.1 e segue generalmente il protocollo HTTP 1.1 per memorizzare e determinare lo stato di aggiornamento dei documenti.
In questo capitolo vengono illustrate alcune funzioni della cache del server proxy. Per quelle funzioni che possono essere configurate, nei seguenti capitoli vengono forniti ulteriori dettagli su come impostare i valori appropriati.
Il server proxy può memorizzare la cache su un'unità di memoria fisica o nella memoria del sistema. La scelta della memoria cache migliore per il sistema dipende dalle capacità dell'hardware di cui si dispone e se sia importante una risposta cache veloce o un numero maggiore di elementi memorizzati nella cache. Normalmente, il tempo di risposta di una memoria cache è superiore rispetto a una cache su disco, ma la dimensione di una memoria cache è limitata dalla quantità di RAM della macchina del server proxy. La dimensione di una cache su disco è limitata dalla dimensione dell'unità di memoria che, normalmente, è molto più grande della quantità di RAM.
Per le cache su disco, Caching Proxy utilizza una cache su disco non formattato, ciò vuol dire che il server proxy scrive direttamente sull'unità cache senza utilizzare i protocolli di lettura e scrittura del sistema operativo. È necessario preparare l'unità di memoria di una cache su disco utilizzando il comando htcformat. Maggiori dettagli su htcformat sono forniti nella sezione Configurazione della memorizzazione cache di base.
In una cache di memoria o su disco, Caching Proxy utilizza lo spazio di memoria del sistema per contenere un indice della cache che riduce il tempo di elaborazione necessario per trovare i file memorizzati nella cache.
La struttura della directory di cache di Caching Proxy e i metodi di ricerca sono diversi da quelli degli altri server proxy. Caching Proxy gestisce un indice nella memoria con le informazioni sui file contenuti nella cache. L'uso della RAM per la ricerca, anziché di un disco o di un altro supporto, determina una ricerca e un recupero dei file più veloce.
L'indice include gli URL, le ubicazioni cache e le informazioni sulla scadenza degli oggetti memorizzati nella cache. Per questo motivo, la quantità di memoria necessaria per contenere l'indice è proporzionale al numero di oggetti nella cache.
Quando si riceve una richiesta da un client, il proxy controlla l'indice della cache nella memoria di quell'URL.
Se il proxy viene configurato sulle richieste di cache, è in grado di memorizzare nella cache le richieste di file FTP e le richieste di file HTTP. Tuttavia, poiché i file FTP non contengono lo stesso tipo di informazioni di intestazione dei file HTTP, le date di scadenza dei file FTP memorizzati nella cache vengono calcolate in modo diverso dagli altri file memorizzati nella cache.
Se si effettua una richiesta al server FTP per richiamare un file, il proxy prima invia una richiesta LIST per il file al server FTP per ottenere le informazioni di directory FTP sul file. Se il server FTP risponde alla richiesta LIST con una risposta positiva di completamento e con le informazioni di directory del file, il proxy crea un'intestazione HTTP Last-Modified con la data analizzata delle informazioni sulla directory FTP. La funzione di memorizzazione nella cache del proxy utilizza questa intestazione Last-Modified, insieme al valore impostato nella direttiva CacheLastModifiedFactor nel file di configurazione, per stabilire l'intervallo di tempo in cui il file FTP rimane nella cache prima di scadere.
Per ulteriori informazioni su come utilizzare le direttive Last-Modified e CacheLastModifiedFactor per determinare quanto tempo un file rimane nella cache, fare riferimento a Gestione del contenuto della cache.
I file FTP richiamati per un ID utente specifico, anziché da un collegamento anonimo, vengono considerati file privati e non memorizzati nella cache.
Oltre alla memorizzazione nella cache dei contenuti Web, il server proxy esegue la memorizzazione nella cache del DNS (domain name server). Ad esempio, se un client richiede un URL da www.myWebsite.com, il proxy chiede al server DNS di risolvere il nome host www.myWebsite.com su un indirizzo IP. L'indirizzo IP viene quindi memorizzato nella cache per migliorare il tempo di risposta delle successive richieste a quel nome host. La memorizzazione nella cache DNS è automatica e non può essere configurata.
Alcuni file e documenti non vengono mai memorizzati nella cache. Tra questi sono inclusi:
È possibile limitare ulteriormente gli elementi memorizzati nella cache impostando dei filtri di cache. Ad esempio, si può desiderare che il server proxy non memorizzi nella cache i file supportati in locale dal proxy. Fare riferimento a Controllo degli elementi memorizzati nella cache per maggiori dettagli.
La gestione della cache include diversi fattori. Come amministratore server, è possibile specificare quanto segue:
Inoltre, è possibile regolare la configurazione cache per migliorare le prestazioni generali di Caching Proxy. Per maggiori dettagli sull'ottimizzazione delle prestazioni, fare riferimento a Ottimizzazione della cache del server proxy.
Se sono state utilizzate le impostazioni predefinite del programma di impostazione di Edge Components per installare Caching Proxy, la memorizzazione nella cache è abilitata e la cache è conservata nella memoria. È possibile regolare le seguenti impostazioni di cache di base per personalizzare la cache in base alle esigenze del sistema in uso.
Se invece non è stato utilizzato il programma di impostazione, configurare tali impostazioni in modo da abilitare la memorizzazione nella cache.
Le operazioni di base necessarie per configurare la cache sono le seguenti:
Dopo aver configurato le impostazioni cache di base, è possibile aggiungere o modificare le impostazioni per le seguenti funzioni.
In questo capitolo vengono fornite o indicate le istruzioni sulla modifica di queste informazioni.
Per abilitare la memorizzazione nella cache, abilitare la direttiva Caching su On oppure selezionare la casella Abilita memorizzazione nella cache del proxy nel modulo di configurazione Configurazione cache -> Impostazioni cache. Se non si specifica un'unità cache, la cache verrà memorizzata nella memoria. Per creare una cache su disco, seguire la procedura riportata in 2. Configurazione della memoria cache.
Le attività per la configurazione della memoria cache dipendono dall'uso di una cache di memoria o di una cache su disco.
Per utilizzare una cache di memoria, personalizzare l'impostazione Memoria cache in modo da includere una quantità di memoria sufficiente per contenere i contenuti di una cache. Fare riferimento a Impostazione della memoria cache per le dimensioni di memoria cache consigliate.
Per utilizzare una cache su disco, effettuare quanto segue:
La cache richiede un'unità formattata. Si consiglia di dedicare un'intera unità o partizione disco alla cache. La dimensione massima per la cache è 16392 KB.
Per formattare l'unità cache:
htcformat percorso_dispositivo [-blocksize dimensione_blocco] [-blocks numero di blocchi]
Gli argomenti -blocksize e -blocks sono facoltativi. La dimensione blocco predefinita è di 8192 byte. Se non viene specificato il numero di blocchi, la partizione disco verrà riempita con tutti i blocchi che è in grado di contenere.
Se si specifica il percorso unità, specificare il percorso dell'unità non formattata.
raw /dev/raw/raw1 dev/sdb1
Consultare il materiale di riferimento sul file system per maggiori informazioni riguardo l'accesso a unità non formattate.
Attenzione:
su sistemi Windows, il comando htcformat non contrassegna automaticamente il dispositivo cache come non scrivibile.
Se il sistema operativo tenta di scrivere sul dispositivo cache, i dati memorizzati nella cache potrebbero andare persi. Per evitare ciò, è possibile utilizzare il programma di utilità Windows Disk Manager per preparare il disco prima di usare il comando htcformat. Per preparare il disco, utilizzare il programma di utilità del disco per eliminare l'unità o la partizione che si desidera utilizzare, quindi ricrearla senza formattarla. In questo modo, il sistema considera il dispositivo non disponibile per la memoria di sistema.
Impostare il valore nella direttiva CacheMemory (o nel campo Memoria cache del modulo di configurazione Impostazioni cache), in base ai seguenti principi. La quantità di memoria impostata su questo valore viene utilizzata per supportare l'infrastruttura cache, incluso l'indice cache e, se la memorizzazione nella cache è configurata, per memorizzare i contenuti della cache.
Per una prestazione ottimale delle cache su disco, è consigliabile un valore di memoria cache minimo di 64 MB per il supporto dell'infrastruttura cache, incluso l'indice di cache. Con l'aumento della dimensione di cache, aumenta anche l'indice di cache e, di conseguenza, è necessaria più memoria per memorizzare l'indice. Un valore di memoria cache di 64 MB è sufficiente per supportare l'infrastruttura cache e memorizzare un indice di cache per una cache su disco con una dimensione fino a 6,4 GB. Per cache su disco di dimensioni superiori, la memoria cache deve essere l'1% della dimensione cache.
Per le cache di memoria, il valore della memoria cache equivale alla quantità di memoria riservata per il supporto dell'infrastruttura cache e per la cache stessa. È consigliabile un valore di memoria cache minimo di 64 MB.
Se per una memoria cache è assegnata troppa memoria fisica, si possono verificare operazioni indesiderate come errori di "memoria insufficiente" o guasti sul server proxy. Le limitazioni di valore per la memoria cache sono dovuti alle limitazioni di un'applicazione da 32 bit. Poiché Caching Proxy è un'applicazione a 32 bit, esso può utilizzare un massimo di 2 GB di memoria.
Caching Proxy assegna la memoria definita dalla direttiva CacheMemory e la utilizza come cache per memorizzare gli oggetti. Se si tratta di una cache di memoria o di una cache su disco non formattato, è necessario assegnare altra memoria per le strutture dati per la cache, per I/E di rete e buffer di connessione, buffer di sessione e memoria per il processo principale e per tutti i thread. Inoltre, è possibile che le richieste di alcuni client debbano assegnare un blocco lotto di memoria più ampio rispetto a quello predefinito. Quindi, se la direttiva CacheMemory è impostata approssimativamente su 2 GB, è possibile che Caching Proxy non abbia spazio sufficiente per funzionare, soprattutto sotto carichi di richieste eccessivi.
È consigliabile, quindi, che il valore della direttiva CacheMemory sia inferiore o uguale a 1600 MB. Un valore superiore a 1600 MB crea interferenza con la memoria di cui Caching Proxy ha bisogno per il normale funzionamento e causa degli effetti collaterali sfavorevoli. Questi effetti collaterali includono un maggiore uso della CPU (possibilmente fino al 100%), errori di memoria insufficiente e prestazioni più lente. Se si richiede una dimensione cache complessiva maggiore, utilizzare le unità cache o implementare una configurazione cache condivisa con RCA o ICP.
È possibile importare ed esportare i contenuti cache su e da un file di dump. Ciò risulta utile se la memoria cache va persa durante il riavvio o se si distribuisce la stessa cache su più proxy.
I filtri possono limitare ciò che è memorizzato nella cache confrontando il modulo della richiesta URL. Fare riferimento a Controllo degli elementi memorizzati nella cache per maggiori dettagli sui filtri delle impostazioni.
Facoltativamente, è possibile configurare il server proxy per memorizzare nella cache i risultati delle richieste di query. Per impostazione predefinita, gli URL che contengono un punto interrogativo (?) non sono memorizzati nella cache. Fare riferimento a Memorizzazione nella cache delle risposte di query per maggiori dettagli.
Un'altra possibilità è quella di memorizzare nella cache i risultati del servlet o dell'esecuzione JSP da IBM WebSphere Application Server. Fare riferimento a Memorizzazione nella cache di contenuto generato dinamicamente per maggiori dettagli.
Fare riferimento a Gestione del contenuto della cache per informazioni sulla configurazione quando i file nella cache scadono e sul modo in cui vengono rimossi i file obsoleti.
La cache può essere configurata per aggiornare automaticamente i file più comuni su una base giornaliera prima che vengano richiesti. Fare riferimento a Configurazione dell'agent della cache per l'aggiornamento e il precaricamento automatico per maggiori informazioni.
In determinate circostanze, utilizzando una cache condivisa si aumenta la probabilità di trovare un file richiesto nella cache. Fare riferimento a Utilizzo di una cache condivisa per maggiori informazioni.
La manutenzione di log accurati e concisi è importante per la gestione di Caching Proxy. La sezione Monitoraggio di Caching Proxy contiene informazioni sulla configurazione e l'utilizzo dei log del server proxy.
Caching Proxy offre diversi metodi di filtraggio che permettono di controllare quali file, documenti e altri oggetti vengono memorizzati nella cache. Tali metodi includono le seguenti funzioni:
Il server proxy può essere configurato per confrontare le richieste a un modello URL per stabilire se un file è memorizzato nella cache. Questa funzione viene configurata impostando le maschere per le richieste i cui file sono sempre memorizzati nella cache e separando le maschere per le richieste i cui file non devono mai essere memorizzati nella cache. È possibile utilizzare più maschere.
Un sistema simile viene utilizzato per consentire la memorizzazione nella cache delle risposte di query. Fare riferimento a Memorizzazione nella cache delle risposte di query per maggiori informazioni.
Per impostare i filtri di memorizzazione nella cache dell'URL modificando il file ibmproxy.conf, fare riferimento a CacheOnly -- Memorizza nella cache solo i file con gli URL che corrispondono a un modello e a NoCaching -- Specifica che i file con gli URL che corrispondono a un modello non vengono memorizzati nella cache.
Per impostare i filtri di memorizzazione nella cache dell'URL nei moduli di configurazione e amministrazione, utilizzare il campo Configurazione cache -> Funzionamento della cache: Filtro della cache mediante l'URL. Utilizzare questa sezione per specificare gli URL i cui file sono sempre memorizzati nella cache oppure specificare gli URL i cui file non sono mai memorizzati nella cache. Per specificare i due elenchi, uno relativo ai file da memorizzare sempre nella cache, un altro dei file che non devono mai essere memorizzati nella cache, creare un elenco e fare clic su Inoltra prima di creare l'altro elenco.
Le risposte restituite dalle query (richieste di URL che contengono un punto interrogativo), possono essere memorizzate utilizzando i filtri della memorizzazione nella cache. Questa funzione può essere utile in scenari di proxy inversi (sostituto) nel caso in cui molti client facciano al stessa richiesta di query.
La memorizzazione nella cache delle query può essere configurata modificando la direttiva CacheQueries nel file di configurazione ibmproxy.conf. La direttiva CacheQueries ha le seguenti opzioni:
Per ulteriori informazioni su queste opzioni, fare riferimento a CacheQueries -- Specifica le risposte della cache agli URL contenenti un punto interrogativo (?).
Per configurare la memorizzazione nella cache delle risposte alle query nei moduli di configurazione e amministrazione, utilizzare il campo Configurazione cache -> Funzionamento della cache: Filtro delle risposte alle query della cache mediante l'URL. Per specificare i due elenchi, creare un elenco e fare clic su Inoltra prima di creare l'altro elenco.
Oltre alla configurazione dell'impostazione della memorizzazione nella cache delle query, verificare che le seguenti impostazioni siano configurate correttamente per abilitare le risposte di query da memorizzare. Fare riferimento a Configurazione dell'aggiornamento della cache per ulteriori informazioni sull'impostazione di queste opzioni utilizzando i moduli di configurazione e amministrazione.
Poiché non è conveniente memorizzare nella cache i file forniti dal server proxy , i file che hanno origine nel dominio locale del server per impostazione predefinita non vengono memorizzati nella cache. Per memorizzare nella cache gli oggetti che hanno origine nel dominio locale del server, selezionare la casella Memorizza nella cache file di dominio locale nel modulo di configurazione e amministrazione Configurazione cache -> Funzionamento della cache. In alternativa, impostare la direttiva CacheLocalDomain nel file di configurazione proxy su on.
Gli elementi possono essere memorizzati nella cache sulla base di una sola parte specificata (importante) dell'URL in entrata, anziché dell'URL completo. Ciò è utile per il supporto Web modello transazione o per la memorizzazione dinamica nella cacha, poiché la stessa risposta viene spesso restituita per diverse richieste in entrata se parti significative degli URL delle richieste in entrata sono identiche.
Non è possibile utilizzare i moduli di configurazione e amministrazione per specificare una memorizzazione nella cache basata su URL parziali. Al contrario, utilizzare la direttiva SignificantUrlTerminator nel file di configurazione proxy per specificare un codice di interruzione per le richieste URL. Questa specifica fa in modo che Caching Proxy valuti solo i caratteri prima del codice di interruzione quando elabora la richiesta e determina se il file di richiesta è memorizzato nella cache. Quando viene definito più di un codice di interruzione, Caching Proxy confronta gli URL in entrata con i codici di interruzione nell'ordine in cui questi si trovano nel file ibmproxy.conf. Fare riferimento a SignificantURLTerminator -- Specifica un codice di terminazione per le richieste dell'URL per ulteriori informazioni.
Per impostare i filtri di cache direttamente modificando il file di configurazione del proxy, vedere le sezioni di riferimento delle seguenti direttive:
Fare riferimento a Panoramica sulla memorizzazione nella cache del server proxy per informazioni sui documenti che non possono essere memorizzati nella cache.
Poiché la memorizzazione nella cache include la creazione e il salvataggio di una copia del file fornito, è necessaria una manutenzione costante affinché la cache funzioni correttamente. I file memorizzati nella cache devono essere controllati per verificare l'aggiornamento e convalidati se non sono più coerenti con i file del server di origine. Questo processo di scadenza dei file viene descritto nella sezione Scadenza di file. Inoltre, i file inutilizzati o non validi devono essere rimossi dalla cache per fare spazio ai nuovi file. Questo processo di eliminazione dalla cache viene descritto nella sezione Raccolta di dati obsoleti.
L'aggiornamento della cache consiste nel mantenere nella memoria cache quegli oggetti coerenti con l'oggetto originale presente sul server di contenuto. Per ogni documento o altro oggetto memorizzato nella cache, Caching Proxy calcola un tempo in cui l'oggetto scade.
Per le pagine HTTP, l'intestazione del documento, generato dal server di contenuto, contiene le informazioni sulla scadenza.
Poiché il protocollo FTP non include le informazioni di scadenza equivalenti, Caching Proxy genera la propria intestazione Last-Modified: per i file FTP in base alle informazioni sulla directory FTP per ogni file e utilizza tali informazioni per calcolare i tempi di scadenza. Se il server proxy non è in grado di ottenere le informazioni sulla directory per il file dal server FTP, viene utilizzato il valore predefinito corrispondente all'URL FTP. Inoltre, poiché non esiste un formato data standard per i server FTP, Caching Proxy potrebbe non riconoscere la data e l'ora inviate da alcuni server FTP. In tal caso, viene utilizzato il valore predefinito dell'ora di scadenza del server proxy. Questa procedura consente al proxy di gestire la memorizzazione nella cache delle pagine HTTP e dei file FTP in un modo simile.
La scadenza può essere specificata da un server di contenuto in uno dei seguenti modi (in ordine di preferenza):
Una volta calcolata l'ora di scadenza nel modo appena descritto, Caching Proxy controlla l'eventuale presenza di un valore di Mantenimento minimo da applicare a questo URL. Se il valore è presente e l'ora specificata è superiore a quella calcolata, l'ora indicata dal valore Mantenimento minimo viene utilizzata come ora di scadenza dell'oggetto. Questa condizione è valida anche se Caching Proxy calcola un'ora di scadenza di 0 minuti per un documento. Quindi, per evitare dei contenuti obsoleti, utilizzare l'impostazione Mantenimento minimo con molta attenzione. Per impostare il valore di Mantenimento minimo, utilizzare la direttiva CacheMinHold oppure l'impostazione Configurazione cache -> Impostazioni scadenza cache: Scadenza URL. Fare riferimento a Configurazione dell'aggiornamento della cache per ulteriori informazioni.
Il valore dell'ora di scadenza finale viene confrontato con l'ora specificata nell'impostazione Margine ora. Se l'ora di scadenza è superiore al valore di Margine ora, il documento viene memorizzato nella cache; in caso contrario, non viene aggiunto nella cache. Per impostare il valore Margine ora, utilizzare la direttiva CacheTimeMargin o fare riferimento alle istruzioni riportate nella sezione Configurazione dell'aggiornamento della cache.
Se il documento si trova nella cache ma è scaduto, Caching Proxy invia una richiesta speciale, nota come richiesta if-modified-since al server di contenuto. A causa di questa richiesta, il server di contenuto invia il documento solo se è stato modificato dal momento in cui è stato ricevuto dal proxy. Se il documento non è stato modificato, il server di contenuto invia un messaggio informativo e non rinvia la pagina. In tal caso, il proxy fornisce il documento memorizzato nella cache. Per i file FTP, il server proxy simula il processo if-modified-since. Se stabilisce che il file non è stato modificato sul server FTP, fornisce il file dalla cache. In caso contrario, ottiene la versione più aggiornata dal server FTP.
Queste informazioni sono valide solo per le configurazioni di proxy diretto.
Poiché il protocollo FTP non definisce le date e le ore in modo così rigido come il protocollo HTTP, diversi fattori possono determinare delle leggere differenze tra l'intestazione Last-Modified, generata dal proxy per i file FTP, e la data effettiva del file. Tali fattori includono quanto segue:
Quando un file FTP di cache scade, il proxy simula il processo di riconvalida if-modified-since per tale file. Questo processo è possibile emettendo il comando FTP LIST del file richiesto, analizzando la data del file dalla risposta restituita dal server FTP e confrontando tale data con quella generata dal server proxy per l'intestazione Last-Modified quando il file è stato richiamato. Se la data del file non è stata modificata, il server proxy contrassegna come riconvalidato il file FTP memorizzato nella cache, imposta una nuova ora di scadenza per il file e fornisce quest'ultimo dalla cache anziché richiamarlo di nuovo dal server FTP. Se le due date non corrispondono, il proxy richiama di nuovo il file del server FTP e memorizza nella cache la nuova copia con la nuova data del file.
Non è possibile ottenere sempre le informazioni di directory per il file del server FTP. Se il proxy non è in grado di determinare la data del file FTP, non genera l'intestazione Last-Modified per il file. Al contrario, utilizza il valore specificato per la direttiva CacheDefaultExpiry che corrisponde all'URL, in modo da determinare il periodo di tempo in cui conservare il file nella cache. Quando questo intervallo scade, il proxy richiama di nuovo il file dal server FTP. Se alcuni file FTP della cache sembrano utilizzare spesso la direttiva CacheDefaultExpiry e vengono richiamati frequentemente (generando un volume elevato di traffico di rete), specificare un valore CacheDefaultExpiry più granulare per quei file. In questo modo, tali file vengono conservati più a lungo nella cache.
Per specificare le impostazioni di scadenza cache nei moduli di configurazione e amministrazione, utilizzare il modulo Configurazione cache -> Impostazioni di scadenza cache -> Limite di tempo per i file memorizzati nella cache. Per maggiori dettagli sull'impostazione delle date di scadenza dei file memorizzati nella cache, fare riferimento a Scadenza di file.
Per specificare l'ora di scadenza dei file memorizzati nella cache, nei moduli di configurazione e amministrazione, selezionare Configurazione cache -> Impostazioni scadenza cache. Sono utili i seguenti moduli.
Utilizzare questo modulo per impostare l'intervallo di tempo minimo in cui i file vengono conservati nella cache in base agli URL. È possibile specificare diversi funzionamenti della memorizzazione nella cache per diverse maschere di richiesta URL.
Per impostare la scadenza dei file basati sugli URL modificando il file di configurazione del proxy, fare riferimento alle sezioni in Appendice B, Dire ttive del file di configurazione per le seguenti direttive:
Utilizzare il modulo Impostazioni di scadenza cache per specificare le impostazioni di scadenza predefinita dei file utilizzati e non. È possibile impostare diversi valori per i file HTTP, FTP e Gopher e diversi valori per i file utilizzati e non.
Questo modulo contiene anche ulteriori opzioni di scadenza dei file:
Per configurare le impostazioni di scadenza predefinita modificando il file di configurazione del proxy, consultare le pagine di riferimento delle seguenti direttive:
Utilizzare il modulo fattore Ultima modifica per impostare il valore che il proxy utilizza per calcolare una data di scadenza per i file memorizzati nella cache senza data di scadenza nelle relative intestazioni. È possibile impostare diversi valori per i file che corrispondono alle diverse maschere di richiesta. La prima maschera corrispondente viene utilizzata per calcolare la data di scadenza.
Per impostare il fattore Ultima modifica cambiando direttamente il file di configurazione del proxy, fare riferimento a CacheLastModifiedFactor -- Specifica il valore per la determinazione delle date di scadenza.
Utilizzare il modulo di configurazione Limite di tempo dei file memorizzati nella cache per impostare il tempo massimo in cui un file rimane nella cache. I limiti di tempo vengono impostati in base alle maschere di richiesta ed è possibile specificare che i file vengono scartati o riconvalidati quando scade il limite di tempo. Queste impostazioni possono essere utilizzate per conservare i file le cui date di scadenza non sono valide o i file con scadenze estremamente lunghe.
Per impostare il limite massimo di scadenza per i file memorizzati nella cache modificando il file di configurazione proxy, vedere quanto segue:
Per diffondere gli URL memorizzati nella cache e ridurre l'uso delle risorse di sistema, Caching Proxy esegue il processo di pulitura noto come raccolta di dati obsoleti in cui vengono rimossi dalla cache i file vecchi o inutilizzati per fare spazio ai file più aggiornati.
Il processo di raccolta di dati obsoleti esamina i file nella directory di cache e cerca di eliminare quelli scaduti per ridurre la dimensione della cache e fare spazio ai nuovi file. La raccolta di dati obsoleti viene eseguita automaticamente, ma alcune impostazioni possono essere configurate in modo da adattare il processo alle esigenze dell'utente.
Per configurare la raccolta di dati obsoleti, nei moduli di configurazione e amministrazione selezionare Configurazione cache -> Impostazioni raccolta dati obsoleti. Utilizzare questo modulo per impostare un valore limite massimo di occupazione e un valore limite minimo di occupazione, che stabilisce quando la raccolta dati inutili viene avviata e arrestata. Quando la quantità di spazio nella cache raggiunge o supera la percentuale impostata per il valore di limite massimo di occupazione, viene avviata la raccolta dati inutili. La raccolta dati inutili continua fino a quando la percentuale dello spazio utilizzato nella cache è uguale o inferiore al valore di limite minimo di occupazione.
È possibile scegliere tra due algoritmi di raccolta dati inutili. L'algoritmo tempo di risposta ottimizza il tempo necessario per rispondere agli utenti rimuovendo dalla cache i file grandi. L'algoritmo larghezza di banda ottimizza l'uso della larghezza di banda della rete rimuovendo dalla cache i file più piccoli. Scegliere uno o entrambi.
Per configurare la raccolta dati inutili modificando il file di configurazione del proxy, vedere le sezioni di riferimento delle seguenti direttive:
La maggior parte dei server proxy di memorizzazione nella cache memorizza un file solo in seguito alla richiesta dell'utente. Caching Proxy dispone di un agent della cache che consente il precaricamento automatico nella cache. L'agente cache richiama automaticamente gli URL specificati, gli URL più noti o entrambi e li posiziona nella cache prima che vengano richiesti.
In alcuni casi, è necessario impostare il nome host del server proxy e identificare il log di accesso del server prima che la cache venga precaricata. Per configurare l'agent della cache, nei moduli di configurazione e amministrazione selezionare Configurazione cache quindi utilizzare i moduli Precaricamento cache e Aggiornamento cache. I file che rappresentano i risultati di query (ovvero, i file i cui URL includono il punto interrogativo (?)) vengono memorizzati solo se è abilitata la memorizzazione nella cache di query.
L'aggiornamento e il precaricamento automatico della cache offrono i seguenti vantaggi:
Gli svantaggi comprendono:
Per una maggiore efficienza, impostare l'agente cache in modo che sia in esecuzione quando le attività dell'utente sono ad un livello minimo e prima che il server sia occupato con le richieste dei client. A questo punto, i file nella cache sono pronti per fornire un servizio rapido non appena l'utente li richiede. Per impostazione predefinita, l'agente cache viene avviato ogni notte alle 3.00 ora locale.
Considerazioni speciali per le configurazioni di proxy inversi:
Per motivi di sicurezza, quando si utilizza una configurazione di proxy inverso, la regola Proxy http:* deve essere disabilitata. In altre parola, la regola va commentata nel file ibmproxy.conf. Tuttavia, se la regola è disabilitata, l'agente cache non potrà inviare correttamente le richieste e non potrà aggiornare il contenuto della cache di Caching Proxy. Nel log degli errori viene generato l'"Errore 403 vietato per effetto della regola" e l'aggiornamento della cache non viene completato.
Per evitare questo problema, utilizzare cacheAgentService, che è un servizio interno fornito da Caching Proxy. Per abilitare il servizio, inserire la seguente istruzione Service prima di qualsiasi altra regola di associazione nel file ibmproxy.conf:
Service /stringa-valida* INTERNAL:cacheAgentService
La variabile stringa-valida è una qualsiasi stringa valida che non sia in conflitto con le regole di associazione nel file ibmproxy.conf.
Sia Caching Proxy che l'agente cache analizzano l'URI in base a questa istruzione di servizio. Invece che inviare l'URI direttamente al Caching Proxy, l'agente cache aggiunge l'URI al modello /stringa-valida nell'istruzione di servizio.
Ad esempio, l'agente cache trasforma il seguente URI:
http://www.ibm.com/
in
/stringa-valida/http://www.ibm.com/
L'agente cache invia l'URI con il prefisso al Caching Proxy. Quando Caching Proxy riceve la richiesta, il prefisso /stringa-valida/ verrà rimosso. Se l'URI rimanente è un URI valido e corretto, allora Caching Proxy risponderà alla richiesta direttamente senza associare l'URI ad altre regole.
Inoltre, l'agente cache può inviare un URI relativo a Caching Proxy. Ad esempio, se si aggiunge LoadURL /abc/ utilizzando la precedente istruzione di servizio nel file ibmproxy.conf, l'agente cache la trasformerà in /stringa-valida/abc/ e la invierà a Caching Proxy. Caching Proxy riceve l'URL, rimuove il prefisso, associa /abc/ ad altre regole di associazione e gestisce la richiesta se viene trovata una corrispondenza.
Per informazioni sulla direttiva Service, fare riferimento a Service -- Personalizza la fase Servizio.
Sulle piattaforme Linux e UNIX, specificare il nome host del server proxy la cui cache è stata precaricata e aggiornata. Sulle piattaforme Windows, specificare il nome host solo se il server proxy aggiornato non si trova sulla macchina locale (notare che l'aggiornamento della cache di un server remoto in base ai file più utilizzati non è possibile perché l'agente cache locale non può accedere al log di accesso della cache del server remoto).
Per impostare il nome host del server proxy, nei moduli di configurazione e amministrazione selezionare Configurazione cache -> Aggiornamento cache: identificazione del server di destinazione della cache.
Per precaricare la cache con il contenuto memorizzato sugli URL specifici, nei moduli di configurazione e amministrazione utilizzare Configurazione cache -> Precaricamento cache. In questo modulo, è possibile specificare gli URL dell'agente cache da caricare. Il proxy richiama quelle pagine quando l'agente cache viene avviato, senza considerare se erano già presenti nella cache (questi URL vengono specificati nel file di configurazione proxy dalla direttiva LoadURL). È possibile utilizzare questo modulo anche per definire gli URL il cui contenuto non è stato mai memorizzato nella cache. Per questo tipo di precaricamento della cache non è necessario accedere a un log di accesso della cache.
Utilizzare il modulo Precaricamento cache per configurare le seguenti opzioni:
Per precaricare automaticamente le pagine più visitate, utilizzare il modulo Configurazione cache -> Aggiornamento cache. Questa funzione richiede un log di accesso alla cache per il server proxy. Il nome e il percorso dei log possono essere modificati; fare riferimento a Monitoraggio di Caching Proxy per ulteriori informazioni. Gli URL più noti vengono determinati automaticamente dal log di accesso cache. L'amministratore può specificare anche il numero delle pagine note da precaricare nella cache. (Questo numero viene specificato nel file di configurazione del proxy dalla direttiva LoadTopCached).
Utilizzare il modulo Aggiornamento cache per configurare le seguenti opzioni:
La modalità di Esplorazione è una parte facoltativa della funzione di aggiornamento automatico della cache. La maggior parte delle pagine dispone di collegamenti con altre pagine e con le informazioni relative e molto spesso gli utenti seguono il percorso che collega una pagina all'altra e un sito a un altro. L'esplorazione è un modo per memorizzare nella cache questi percorsi logici di informazione. Nella modalità di esplorazione, l'agente cache segue un livello specifico di collegamenti ipertestuali (HTML) sulle pagine che sta caricando e memorizza anche quelle pagine collegate. Le pagine collegate possono risiedere sullo stesso host della pagina di origine o su altri host. Un'illustrazione è riportata in Figura 1.
Per controllare il processo di esplorazione, l'amministratore indica all'agente cache un numero massimo di URL che può caricare (l'impostazione predefinita è 2000), un periodo di tempo massimo in cui essere in esecuzione (l'impostazione predefinita è due ore) e un numero massimo di thread che può utilizzare (l'impostazione predefinita è quattro). L'amministratore può configurare anche altri controlli. Per impostazione predefinita, la modalità di esplorazione viene abilitata per due livelli di gerarchia e non è consentita sugli host. Inoltre, tra due richieste viene inserito un intervallo. Per modificare tali impostazioni, fare riferimento a Direttive del file di configurazione proxy correlate.
L'agente cache carica e aggiorna la cache in questo ordine:
L'agente cache non controlla se è stato raggiunto il numero massimo di pagine fino a quando non comincia l'esplorazione tra i vari collegamenti. Se il valore del numero massimo di pagine (denominato MaxURLs nel file di configurazione proxy) è inferiore al numero di pagine richiamato nelle fasi 1 e 2, non viene richiamata nessuna pagina collegata.
I seguenti esempi mostrano come l'agente cache gestisce
le priorità di aggiornamento della cache e l'esplorazione
relative al numero
massimo di URL indicato (si presume che la modalità di
esplorazione sia configurata
per tutti gli esempi).
Impostazione del file di configurazione | Risultato |
---|---|
LoadURL http://www.getthis.com/main.html LoadURL http://www.getmetoo.com/welcome.htm LoadTopCached 30 MaxURLs 50 | Se il log di accesso della cache ha più di 30 URL univoci, l'agente cache richiama main.html, welcome.htm e i primi 30 URL richiesti in base al log di accesso della cache. Poiché non ha raggiunto il valore MaxURLs, richiama e carica fino a 18 URL collegati dalle pagine già memorizzate. |
LoadURL http://ww.joesmith.edu/favorites.html LoadURL http://www.janesmith.edu/dislikes.html LoadTopCached 30 MaxURLs 25 | Se il log di accesso della cache ha più di 30 URL univoci, l'agente cache richiama favorites.html, dislikes.html e i primi 30 URL richiesti dal log di accesso della cache. Nessun altro file viene richiamato in quanto è stato superato il valore in MaxURLs. |
LoadURL http://www.hello.com/hi.htm LoadURL http://www.ballyhoo.com/index.html LoadTopCached 20 MaxURLs 25 | Se il log di accesso della cache ha più di 20 URL univoci, l'agente cache richiama hi.htm, index.html, i primi 20 URL richiesti dal log di accesso della cache e fino a 3 URL collegati dalle pagine precedenti. Nessun altro file viene richiamato in quanto è stato raggiunto il valore in MaxURLs. |
L'agent della cache può essere configurato direttamente modificando le direttive corrette nel file di configurazione proxy. Per le direttive del file di configurazione proxy relative all'agent della cache, vedere le seguenti pagine di riferimento in Appendice B, Direttive del file di configurazione:
Se è abilitato l'aggiornamento automatico della cache, l'agente cache esegue automaticamente un'operazione di aggiornamento nell'ora indicata. Tuttavia, l'agente cache può essere attivato in qualsiasi momento dalla riga comandi.
Il file eseguibile è il seguente:
dove root_server è l'unità e la directory in cui è stato installato Caching Proxy (ad esempio, C:\Program Files\IBM\edge\cp).
Sulle piattaforme Linux e UNIX, è possibile eseguire automaticamente l'agente cache in vari momenti utilizzando il daemon cron. I lavori controllati da cron vengono specificati aggiungendo una riga al file di sistema crontab. Una voce di esempio del file di comando su Linux e UNIX è:
45 16 * * * /usr/sbin/cacheagt
Questo esempio di comando avvia l'agente cache ogni giorno alle 16:45 ora locale. Si possono usare più voci per eseguire più di una volta l'agente cache, se si desidera. Per maggiori informazioni, consultare la documentazione del sistema operativo sul daemon cron.
Quando si utilizza un daemon cron per eseguire l'agent della cache, ricodarsi di disattivare l'opzione di aggiornamento automatico utilizzando il modulo di configurazione Configurazione cache -> Aggiornamento cache oppure modificando il file di configurazione proxy. Altrimenti l'agente cache verrà eseguito più di una volta al giorno.
È una condizione comune per un punto di presenza (POP, point of presence) del Web quella di disporre di più traffico di quanto un unico server sia in grado di gestire. Una soluzione è quella di aggiungere più server. Tuttavia, se si utilizzano più server caching proxy, il contenuto di una cache spesso si sovrappone ai contenuti delle altre cache. Oltre a una ridondanza inutile nella memoria, non è possibile ottenere il numero massimo di salvataggi della larghezza di banda perché un file memorizzato nella cache viene ricaricato dal server di origine quando una richiesta per tale file arriva a un server proxy che non ha il file nella propria memoria. Sebbene sia possibile ridurre la doppia memorizzazione nella cache tramite una catena gerarchica di server proxy, questo scenario determinerà ulteriore traffico su un particolare server e ogni collegamento in più nella catena aggiunge latenza.
La condivisione della cache risolve questi problemi permettendo a ciascuna cache di condividere i contenuti con le altre cache. I salvataggi della larghezza di banda vengono determinati dai seguenti fattori:
Vengono forniti due metodi per utilizzare più cache come se fossero un'unica cache logica:
RCA e ICP possono essere utilizzati insieme.
Nella pianificazione di RCA, tenere presente quanto segue:
L'accesso alla cache remota non è corretto se una di queste condizioni non viene rispettata o se organizzazioni diverse gestiscono server diversi che sono membri della stessa matrice.
Per configurare l'accesso remoto alla cache, nei moduli di configurazione e amministrazione selezionare Configurazione cache -> Accesso remoto alla cache. I campi di questo modulo definiscono una matrice denominata che condivide una cache logica. Inserire le informazioni richieste per ciascun membro della matrice.
Per configurare l'accesso remoto alla cache modificando il file di configurazione del proxy, fare riferimento alle sezioni in Appendice B, Direttive del file di configurazione per le seguenti direttive:
Il plug-in ICP (Internet Caching Protocol) consente a un Caching Proxy di interrogare le cache conformi a ICP per ricercare pagine HTML e altre risorse memorizzabili nella cache. Quando il server proxy riceve una richiesta HTTP, ricerca altre risorse per la cache. Se la risorsa non si trova nella cache locale e il plug-in di ICP è abilitato, il server proxy racchiude le richieste URL in un pacchetto di query ICP e distribuisce questo pacchetto a tutte le cache peer ICP identificate. Se una cache peer conferma di disporre della risorsa, il server proxy richiama la risorsa dalla cache del peer. Se due o più peer rispondono in modo positivo, viene elaborata la prima risposta. Se nessun peer risponde con degli accessi, il server originale continua l'elaborazione della richiesta in base al flusso di lavoro. Ad esempio, il server proxy può richiamare un altro plug-in, continuare con la routine RAC (Remote Caching Access) se RCA è abilitato, oppure richiamare la risorsa richiesta.
Il plug-in di ICP viene attivato e configurato modificando il file di configurazione proxy, ibmproxy.conf. È necessario aggiungere una direttiva ServerInit, una direttiva PreExit o entrambe alla sezione delle direttive API del file di configurazione per poter utilizzare il plug-in di ICP. Il tipo di direttiva utilizzato dipende dal ruolo che Caching Proxy ha nel sistema ICP:
Per creare queste direttive, modificare manualmente il file ibmproxy.conf oppure, se il server proxy è già in esecuzione, collegarsi al modulo di configurazione e amministrazione Configurazione server -> Elaborazione richiesta -> Elaborazione richiesta API.
Le direttive prototipo (nel modulo dei commenti) sono state aggiunte alla sezione API del file ibmproxy.conf. L'ordine di queste direttive API è significativo. Se si aggiungono direttive API per abilitare nuove funzioni e moduli di plug-in, ordinare le direttive come illustrato nella sezione prototipi del file di configurazione. In alternativa, eliminare il commento o modificare se necessario le direttive API per includere il supporto per ogni funzione o plug-in desiderato.
Entrambe le direttive ServerInit e PreExit hanno due argomenti: (1) il percorso completo della libreria condivisa e (2) la chiamata di funzione. Questi argomenti sono delimitati da due punti (:). Il primo argomento è specifico del sistema e dipende dal punto in cui sono stati installati i componenti plug-in. Il secondo argomento è codificato nella libreria condivisa e deve essere digitato esattamente come illustrato.
Ogni direttiva deve comparire su un'unica riga nel file di configurazione proxy.
ServerInit percorso_della_libreria_condivisa:icpServer
Esempio di Linux e UNIX:
ServerInit /opt/ibm/edge/cp/internet/lib/plugins/icp/libicp_plugin.so:icpServer
Esempio di Windows:
ServerInit C:\Program Files\IBM\edge\cp\Bin\plugins\icp\icpplugin.dll:icpServer
PreExit percorso_della_libreria_condivisa:icpClient
Esempio di Linux e UNIX:
PreExit /opt/ibm/edge/cp/internet/lib/plugins/icp/libicp_plugin.so:icpClient
Esempio di Windows:
PreExit C:\Program Files\IBM\edge\cp\Bin\plugins\icp\icpplugin.dll:icpClient
Per configurare le impostazioni del plug-in, aggiungere o modificare le direttive ICP* fornite nel file di configurazione proxy. Per ulteriori informazioni, fare riferimento alle descrizioni delle seguenti direttive.
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
La funzione di memorizzazione nella cache dinamica consente a Caching Proxy di memorizzare un contenuto generato dinamicamente nel modulo delle risposte delle JSP (JavaServer Pages) e dei servlet generati da IBM WebSphere Application Server. Un modulo adattatore di Caching Proxy viene utilizzato sul server delle applicazioni per modificare le risposte in modo da poterle memorizzare nella cache sul server proxy e nella cache dinamica del server delle applicazioni. Con questa funzione, è possibile memorizzare nella cache il contenuto generato dinamicamente sull'unità terminale della rete, esonerando gli host dei contenuti dal ripetere le richieste al server delle applicazioni quando più di un client richiede lo stesso contenuto.
A volte è necessario abilitare la memorizzazione nella cache di query affinché la funzione di memorizzazione dinamica funzioni; ad esempio, se i servlet utilizzano gli URL nel formato di query. Il server proxy considera qualsiasi URL contenente un punto interrogativo (?) come una query.
La memorizzazione nella cache di contenuti generati dinamicamente offre i seguenti vantaggi:
Il server delle applicazioni esporta solo le pagine pubbliche composte per la memorizzazione nella cache del proxy. Le pagine private non vengono memorizzate dal proxy. Ad esempio, una pagina generata dinamicamente da un sito pubblico sulle previsioni del tempo, può essere esportata da IBM WebSphere Application Server e memorizzata nella cache da Caching Proxy. Tuttavia, una pagina generata dinamicamente, che elenca il contenuto del carrello d'acquisto di un utente, non può essere memorizzata nella cache dal server proxy. Inoltre, per poter generare in modo dinamico delle pagine, tutti i sottocomponenti di quella pagina devono poter essere memorizzati nella cache.
I file dinamici memorizzati nella cache non scadono come i file regolari; possono essere invalidati dal server delle applicazioni che li ha generati.
Le voci della cache dinamica vengono invalidate nelle seguenti circostanze:
L'invalidazione delle voci di cache dinamica viene sempre eseguita generando un messaggio di invalidazione per l'istanza specifica del plug-in di memorizzazione nella cache dinamica di Caching Proxy. Caching Proxy riceve i messaggi di invalidazione come post nel resource locator /WES_External_Adapter. Caching Proxy quindi cancella le voci non valide dalla cache.
La memorizzazione nella cache dinamica richiede le seguenti fasi di configurazione.
Seguire le istruzioni nella documentazione di IBM WebSphere Application Server per configurare il server delle applicazioni all'uso della cache dinamica locale (chiamata anche cache di frammenti dinamica). La cache di frammenti dinamica interagisce con la cache esterna sul Caching Proxy del server delle applicazioni.
IBM WebSphere Application Server comunica con Caching Proxy utilizzando un modulo software denominato External Cache Adapter, installato con il server delle applicazioni.
Per consentire al server proxy di memorizzare nella cache contenuti generati dinamicamente (risultati da servlet e JSP), è necessario effettuare due modifiche nel file di configurazione proxy, ibmproxy.conf. La prima modifica abilita il modulo plug-in per la memorizzazione dinamica; la seconda lo configura per riconoscere le origini dei contenuti dinamici memorizzabili nella cache.
Una direttiva API per l'operazione Servizio viene utilizzata per abilitare il plug-in di memorizzazione nella cache dinamica. Per creare questa direttiva, modificare manualmente il file ibmproxy.conf o, se il server proxy è già in esecuzione, utilizzare i moduli di configurazione e amministrazione per selezionare Configurazione server -> Elaborazione richiesta -> Elaborazione richiesta API. Il contenuto della direttiva viene illustrato negli esempi mostrati più avanti in questa sezione.
È presente una direttiva Servizio prototipo, per l'abilitazione della memorizzazione nella cache dinamica, come commento nella sezione API del file ibmproxy.conf. Ha l'intestazione JSP Plug-in. Le direttive API prototipo sono in un ordine stabilito. Se si aggiungono direttive API per abilitare nuove funzioni e moduli di plug-in, ordinare le direttive come illustrato nella sezione prototipi del file di configurazione. Facoltativamente, è possibile rimuovere i caratteri commento dalle direttive API prototipo e modificarli, se necessario, per includere un supporto per ciascuna funzione o plug-in desiderato.
Impostare la direttiva Servizio come illustrato nei seguenti esempi. (Ogni direttiva deve comparire su un'unica riga nel file di configurazione proxy; questi esempi a volte contengono delle interruzioni di riga per per facilitarne la lettura).
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:\Program Files\IBM\edge\cp\bin\plugins\ dynacache\dyna_plugin.dll:exec_dynacmd
Se il software di Caching Proxy è installato in una directory diversa da quella predefinita, sostituire il percorso di installazione con il percorso di questi esempi.
Ogni Caching Proxy deve essere configurato per riconoscere l'origine dei file generati dinamicamente. Aggiungere una direttiva ExternalCacheManager al file ibmproxy.conf per ciascun server delle applicazioni che memorizza il contenuto generato dinamicamente su questo server proxy. Questa direttiva specifica un WebSphere Application Server che memorizza i risultati sul proxy e imposta un valore di scadenza massimo per i contenuti di quel server. Per maggiori dettagli, fare riferimento a ExternalCacheManager -- Configura Caching Proxy per la memorizzazione nella cache dinamica da IBM WebSphere Application Server.
L'ID server, utilizzato nella direttiva ExternalCacheManager, deve corrispondere all'ID gruppo usato nella stanza gruppo di cache esterna del file dynacache.xml del server delle applicazioni.
Per il precedente esempio, aggiungere la seguente voce a ciascun file ibmproxy.conf del proxy.
ExternalCacheManager IBM-edge-cp-XYZ-1 20 secondi
Caching Proxy memorizza nella cache solo i contenuti di un IBM WebSphere Application Server il cui ID di gruppo corrisponde ad una voce ExternalCacheManager nel file ibmproxy.conf.
Se la memorizzazione nella cache è abilitata, la velocità delle unità della memoria cache è molto importante per le prestazioni di Caching Proxy. In questa sezione vengono forniti dei suggerimenti sulla scelta di un tipo di memoria cache e sulla configurazione delle unità di memoria cache per migliorare le prestazioni.
Caching Proxy può utilizzare due diversi tipi di supporto per la memoria cache:
Una cache di memoria consente un richiamo più veloce dei file, ma la dimensione di una memoria cache è limitata dalla quantità di memoria disponibile sulla macchina del server proxy. Una cache su disco, costituita da una o più partizioni disco non formattate, è più lenta di una cache di memoria ma, nella maggior parte dei casi, permette di disporre di dimensioni cache più grandi.
Le partizioni dell'unità utilizzata per la memorizzazione nella cache su disco, devono essere dedicate alla cache; vale a dire che non si possono utilizzare questi dischi fisici per contenere qualsiasi altro file system né per qualsiasi altro scopo diverso dalla memorizzazione nella cache del proxy. Inoltre, non è possibile utilizzare la compressione dati su un qualsiasi disco usato per la memorizzazione nella cache in quanto riduce le prestazioni.
Ogni unità di memoria cache (sia un disco che un file) è esposta a un sovraccarico di memoria sul server proxy. In generale, utilizzando un intero disco fisico su una sola unità cache, si ottengono le prestazioni migliori. L'uso di RAID o di altri meccanismi per associare più dischi fisici in un unico disco logico, può essere controproducente. Se si desidera utilizzare più dischi, specificarli come unità cache multiple mediante il modulo di configurazione Impostazioni cache o modificando la direttiva CacheDev nel file di configurazione proxy. Questo metodo consente al server proxy di controllare il parallelismo tra lettura e scrittura su più dischi e non si basa sulle prestazioni del sistema operativo o su un sottosistema del disco.
La raccolta di dati obsoleti nella cache del server proxy elimina dalla cache i file scaduti, liberando spazio per le nuove richieste all'interno dei file della cache. La raccolta di dati obsoleti viene attivata automaticamente quando la quantità di spazio utilizzato nella cache raggiunge il limite, specificato dall'amministratore, chiamato limite massimo di occupazione e continua fino a quando la quantità di spazio utilizzata non raggiunge un limite minimo di occupazione.
Poiché la routine di raccolta dati inutili utilizza il numero minimo di risorse CPU e non influisce sulla disponibilità del materiale scaduto all'interno della cache, non è necessario configurare l'esecuzione della raccolta dati inutili in orari stabiliti.
Per migliorare le prestazioni della raccolta dati inutili, impostare i limiti massimo e minimo di occupazione. È possibile, inoltre, configurare il tipo di algoritmo usato per la raccolta dati inutili. Fare riferimento a Raccolta di dati obsoleti per ulteriori informazioni su come modificare la raccolta di dati obsoleti.
Di seguito sono riportati dei suggerimenti per l'ottimizzazione delle prestazioni di cache su ogni piattaforma.
Creazione di un unico volume logico su un disco usando, preferibilmente, tutte le partizioni fisiche (PP) disponibili. Ad esempio, con un disco da 9 GB, creare un volume logico da 9 GB chiamato cpcache1. Formattarlo e specificarlo come unità cache del proxy utilizzando il suo volume logico non formattato, /dev/rcpcache1.
Sull'unità cache, creare una partizione singola (o slice) che utilizza l'intera dimensione del disco. Ad esempio, su un disco da 9 GB, creare una partizione da 9 GB chiamata c1t3d0s0. Formattarla e specificarla come unità cache del proxy utilizzando l'unità non formattata, /dev/rdsk/c1t3d0s0.
Creare una sola partizione utilizzando l'intera dimensione del disco. Ad esempio, su un disco da 9 GB, creare una partizione da 9 GB chiamata i:. Formattarla e specificarla come unità cache del proxy utilizzando l'unità non formattata, \\.\i:.
Le informazioni sulla configurazione della cache del server proxy e sulla formattazione e specifica delle unità cache sono incluse in Configurazione della memorizzazione nella cache del server proxy.
Questa parte fornisce informazioni sulla sicurezza di base, sull'utilizzo di SSL con Caching Proxy, sull'abilitazione dell'hardware di crittografia e sull'utilizzo del plug-in di IBM Tivoli(R) Access Manager (precedentemente noto come Tivoli Policy Director) e del modulo di autorizzazione PAC-LDAP.
Questa sezione contiene i seguenti argomenti:
Informazioni sulla sicurezza del server proxy
Impostazioni della protezione server
Abilitazione del supporto hardware crittografico
Utilizzo del plug-in di Tivoli Access Manager
Utilizzo del modulo di autorizzazione PAC-LDAP
Qualsiasi server accessibile da Internet può essere soggetto a intrusioni e il sistema su cui è in esecuzione può subire attacchi esterni. Persone non autorizzate potrebbero accedere al sistema, indovinare le password, aggiornare o eseguire i file, o anche leggere dati riservati. Parte dell'attrattiva del Web è la sua apertura. Tuttavia, si può fare un uso positivo del Web oppure abusarne.
Le seguenti sezioni descrivono come controllare gli utenti che hanno accesso ai file sul server di Caching Proxy.
Caching Proxy supporta le connessioni SSL (Secure Sockets Layer) in cui sono stabilite delle trasmissioni protette, incluse la codifica e la decodifica, tra il browser del client e il server di destinazione (un server di contenuto o un server sostitutivo).
Se Caching Proxy è configurato come sostitutivo, è in grado di stabilire delle connessioni protette con i client, con i server di contenuto o con entrambi. Per consentire le connessioni SSL, nei moduli di configurazione e amministrazione selezionare Configurazione proxy -> Impostazioni SSL. Su questo modulo, selezionare la casella di controllo Abilita SSL e specificare un database del file di chiavi e un file password database del file di chiavi.
Se Caching Proxy è configurato come un server proxy di inoltro, segue un protocollo pass-through chiamato Tunneling SSL per inviare le richieste crittografate tra il client e il server di contenuto. Le informazioni crittografate non vengono memorizzate nella cache perché il server proxy non decodifica le richieste ottimizzate. In un'installazione di un proxy diretto, il tunneling SSL è abilitato per impostazione predefinita. Per disabilitarlo, nei moduli di configurazione e amministrazione selezionare Configurazione proxy -> Impostazioni proxy quindi deselezionare la casella di spunta Tunneling SSL presente sul modulo.
Si possono prendere diverse precauzioni di base per proteggere il sistema:
Il filtro pacchetti consente di definire la provenienza e la destinazione dei dati. È possibile configurare il sistema in modo da rifiutare alcune combinazioni origine-destinazione.
Un firewall separa una rete interna da una rete accessibile pubblicamente, come ad esempio Internet. Il firewall è un insieme di computer o un unico computer che funziona da gateway in entrambe le direzioni, regolando e tracciando il traffico di passaggio. IBM Firewall è un esempio di software firewall.
Esempi:
Proxy /* http://server contenuto:443
o
Proxy /* https://server contenuto:443
In questo capitolo viene illustrato il modo in cui proteggere i dati e i file del server utilizzando le impostazioni di protezione. Le impostazioni di protezione vengono attivate in base alla richiesta che il server riceve, in modo specifico in base alla directory, al file o al tipo di file particolare indicato dalla richiesta. In un'impostazione di protezione, le direttive secondarie controllano il modo in cui l'accesso viene garantito o negato in base alle caratteristiche delle directory o dei file protetti.
Per definire un'impostazione di protezione e il modo in cui viene applicata, nei moduli di configurazione e amministrazione selezionare Configurazione server -> Protezione documenti. Utilizzare questo modulo per le seguenti operazioni:
Le regole di protezione vengono applicate nell'ordine in cui sono elencate nella tabella sul modulo di configurazione. Normalmente, queste vengono elencate a partire da quelle specifiche per arrivare a quelle generiche.
Utilizzare il menu a discesa e i pulsanti per specificare la posizione di una regola di protezione.
La protezione viene attivata in base alle maschere di richiesta che vengono confrontate con il contenuto delle richieste che i client inviano al server proxy.
Una richiesta è la parte di un URL completo che segue il nome host del server. Ad esempio, se il server è denominato fine.feathers.com e un utente browser immette l'URL http://fine.feathers.com/waterfowl/schedule.html , il server riceve la richiesta /waterfowl/schedule.html. Le maschere di richiesta indicano i nomi di directory o di file, o entrambi, soggetti a protezione. Ad esempio, alcune richieste che attivano la protezione in base alla maschera di richiesta appena descritta (/waterfowl/schedule.html), includono /waterfowl/* e /*schedule.html.
Immettere la maschera di richiesta nel campo Maschera richiesta URL.
Un'impostazione di protezione indica a Caching Proxy cosa fare con una richiesta che corrisponde ad un modello di richiesta. È possibile utilizzare un'impostazione di protezione denominata o definire una nuova impostazione nel modulo Protezione documenti.
Per utilizzare un'impostazione denominata, fare clic sul pulsante di opzione Protezione denominata e digitare il nome nel campo. Per definire una nuova impostazione, fare clic sul pulsante di opzione In linea e seguire le istruzioni (vedere il punto 6).
Diverse regole possono essere applicate a quelle richieste che derivano da indirizzi server diversi. Ad esempio, è possibile applicare una diversa impostazione di protezione alle richieste dei file di log se tali richieste provengono da indirizzi IP assegnati alla società.
Se si desidera includere l'indirizzo del richiedente nella regola, inserirlo nel campo Indirizzo IP server o nome host.
Se è stata utilizzata un'impostazione di protezione denominata, non sono necessari ulteriori input. Se è stata selezionata un'impostazione di protezione in linea o è stata specificata un'impostazione denominata che non esiste, il sistema apre altri moduli.
Se non è stata specificata un'impostazione di protezione denominata già esistente, si apre un altro modulo sul quale è possibile specificare gli utenti che possono accedere ai documenti o alle directory che corrispondono alla maschera di richiesta e quali azioni possono eseguire tali utenti.
Per impostare la protezione modificando direttamente il file di configurazione di Caching Proxy, è necessario prima comprendere i seguenti problemi:
Le direttive di instradamento della richiesta, come Map, Exec, Pass e Proxy, vengono utilizzate per controllare quali richieste accetta il server e come le reindirizza alle posizioni effettive del file. Le direttive di instradamento della richiesta utilizzano lo stesso tipo di maschere di richiesta delle direttive di protezione. Poiché vengono eseguite le direttive associate alla prima maschera corrispondente di ciascuna richiesta, le direttive di protezione devono essere elencate prima di essere instradate nel file di configurazione affinché la protezione funzioni correttamente. Per ulteriori informazioni, fare riferimento a Protect -- Attiva un passo di protezione per le richieste che corrispondono a un modello.
La direttiva Protect può essere usata per specificare un'impostazione di protezione in linea o può indicare un'impostazione denominata esistente. La sintassi dei due tipi di istruzione è leggermente diversa. Per ulteriori informazioni, fare riferimento a Protect -- Attiva un passo di protezione per le richieste che corrispondono a un modello.
Un'impostazione di protezione è costituita da una serie di istruzioni che utilizzano le direttive secondarie di protezione. La sintassi e le informazioni di riferimento sulla scrittura di impostazioni di protezione sono riportate in Appendice B, Direttive del file di configurazione; fare riferimento alle seguenti sezioni:
Il file di configurazione proxy predefinito include un'impostazione di protezione che richiede un ID amministratore e una password per poter accedere ai file nella directory /admin-bin/. Questa impostazione limita l'accesso ai moduli di configurazione e amministrazione.
SSL (Secure Sockets Layer) è un sistema che codifica automaticamente le informazioni prima di inviarle tramite Internet e le decodifica alla ricezione prima che vengano utilizzate. Protegge le informazioni riservate, come i numeri di carta di credito, quando vengono trasmesse via Internet.
Caching Proxy utilizza il sistema SSL per proteggere i server sostitutivi e per fornire un'amministrazione remota protetta come descritto nelle seguenti sessioni. L'SSL inoltre può essere utilizzato per proteggere le connessioni ai server di back-end (ad esempio, server delle applicazioni o dei contenuti) e per proteggere le comunicazioni tra il server proxy e i relativi client.
Per il proxy di inoltro, Caching Proxy supporta il tunneling SSL, che ignora l'SSL e inoltra i dati già codificati senza alterarli.
La protezione SSL viene avviata quando viene inviata una richiesta di connessione protetta da una macchina a un'altra ad esempio, quando un browser invia una richiesta a un server proxy sostitutivo. La sintassi della richiesta https:// invece di http:// indica al browser di inviare la richiesta sulla porta 443, ossia la porta su cui è in ascolto il server per le richieste di connessione protetta (al posto della porta 80, per le richieste di ruotine). Per stabilire una sessione protetta tra il browser e il server, le due macchine eseguono uno scambio definito sincronizzazione SSL per accettare una specifica di cifratura e selezionare una chiave utilizzata per codificare e decodificare le informazioni. Le chiavi vengono generate automaticamente e scadono insieme alla sessione. Di seguito viene riportato uno scenario tipico (si suppone SSL Versione 3):
Il client avvia una sessione SSL con Caching Proxy inviando un messaggio Client Hello che descrive le capacità di codifica del client.
Il server invia il certificato relativo al client e sceglie il pacchetto di crittografia da utilizzare per la codifica dei dati.
Il client invia le informazioni sulle chiavi di cifratura utilizzate per creare le chiavi di codifica simmetriche per i dati codificati. Questo materiale della chiave è noto come segreto premaster ed è crittografato con la chiave pubblica del server (ottenuta dal certificato del server stesso; fare riferimento a Gestione certificato e chiavi). Sia il server che il client possono ricavare le chiavi di codifica simmetrica per la lettura e la scrittura da pre-master secret.
Il server invia una conferma finale e un MAC (Message Authentication Code) per l'intero protocollo di sincronizzazione.
Il client invia un messaggio per convalidare il messaggio Server finish.
Se il client convalida il messaggio Server finish, viene avviato il flusso di dati codificati.
Utilizzando Caching Proxy come endpoint per le connessioni protette, è possibile ridurre il carico sul server di contenuto o delle applicazioni. Quando un Caching Proxy mantiene una connessione protetta, esegue la codifica, la decodifica e la creazione della chiave, ossia tutte operazioni che occupano molta CPU. Caching Proxy inoltre consente di configurare i timeout delle sessioni SSL per aumentare al massimo l'uso di ciascuna chiave.
Le seguenti limitazioni sono valide per l'SSL in un Caching Proxy di WebSphere Application Server:
Durante volumi di traffico HTTPS elevati, il server Caching Proxy potrebbe causare un utilizzo della CPU elevato. L'ottimizzazione delle modifiche su una variabile d'ambiente (GSK_V3_SIDCACHE_SIZE) e su un'istruzione proxy (SSLV3Timeout) consentono al server proxy di gestire il carico e ridurre l'utilizzo della CPU.
L'ID di sessione SSL identifica le sessioni SSL riutilizzabili, comprese le chiavi di crittografia o di decrittografia utilizzate dai browser e dai server, e viene utilizzato per evitare handshake SSL non necessari sulle nuove connessioni, che utilizzano molta della CPU del server. La libreria GSKit per il server Caching Proxy supporta l'ID di sessione SSL e include una cache per tale ID. Per impostazione predefinita, la cache dell'ID di sessione SSL contiene 512 voci. Quando viene raggiunto il limite massimo di voci, la voce della sessione più vecchia viene rimossa e una nuova voce verrà aggiunta nella cache.
Utilizzare la variabile d'ambiente GSK_V3_SIDCACHE_SIZE per modificare la dimensione predefinita della cache dell'ID di sessione SSL. Un valore valido per la variabile è compreso tra 1 e 4096. L'aumento della dimensione aumenta il tempo richiesto per individuare una sessione SSL memorizzata nella cache. Tuttavia, il tempo di ricerca è insignificante se confrontato al tempo richiesto per stabilire una connessione SSL. L'aumento della dimensione della cache consente al server proxy di gestire più sessioni SSL simultanee e di ridurre l'utilizzo della CPU quando il server proxy gestisce carichi HTTPS elevati.
Caching Proxy dispone anche di una istruzione regolabile SSLV3Timeout. Fare riferimento a SSLV3Timeout -- Specifica il tempo da attendere prima della scadenza di una sessione SSLV3. Il valore predefinito di questa istruzione è 1000 secondi. Questa direttiva definisce la durata di una sessione SSL nella cache della sessione. Se nessuna connessione SSL in entrata utilizza una sessione SSL esistente e la durata della sessione supera il valore, la sessione verrà rimossa dalla cache. Si consiglia di impostare il valore di SSLV3Timeout sulla lunghezza di una tipica sessione di client sicuro. Se il valore di timeout è troppo breve, potrebbe rallentare le prestazioni del proxy in quanto sono necessarie più sessioni handshake SSL per completare una singola sessione sicura. Tuttavia, se viene impostato un valore troppo elevato, è possibile che venga intattacata la sicurezza di una sessione.
Queste informazioni sono valide solo per le configurazioni di proxy diretto.
Quando Caching Proxy viene configurato come proxy di inoltro, utilizza il tunneling SSL per supportare le connessioni protette tra client e server di contenuto. Nel tunneling SSL, i dati codificati vengono inoltrati al server proxy senza alcuna alterazione. Poiché il server proxy non decodifica i dati, le funzioni che richiedono il server proxy per leggere le richieste o le intestazioni dei documenti non sono supportate nel tunneling SSL. Inoltre, le richieste ottimizzate non vengono memorizzate nella cache.
La Figura 2 mostra come viene stabilita una connessione utilizzando il tunneling SSL.
Il processo di tunneling SSL è il seguente:
In un'impostazione proxy di inoltro, è disponibile solo il tunneling SSL. Per abilitare il tunneling SSL, nei moduli di configurazione e amministrazione selezionare Configurazione proxy -> Impostazioni proxy. Selezionare la casella di controllo Tunneling SSL.
Il metodo CONNECT (disabilitato per impostazione predefinita) deve essere abilitato per le connessioni di tunneling SSL. Per abilitare il metodo nei moduli di configurazione, selezionare Configurazione server -> Elaborazione richiesta e utilizzare il modulo Metodi HTTP.
Sono disponibili tre opzioni (OutgoingPorts, OutgoingIPs, IncomingIPs) per la direttiva Enable CONNECT per una migliore sicurezza di tunneling SSL. È necessario specificare un valore per almeno OutgoingPorts, altrimenti il metodo CONNECT non sarà abilitato.
Enable CONNECT OutgoingPorts [all | [port1|port1-port2|port1-*],...]
Per consentire ai client di collegarsi solo alla porta 443 dei server remoti per il tunneling SSL, impostare le seguenti direttive. Di solito, la porta 443 è per le richieste HTTPS sul server remoto.
Enable CONNECT OutgoingPorts 443 SSLTunneling on
Per consentire ai client di collegarsi a qualsiasi porta dei server remoti per il tunneling SSL, impostare le seguenti direttive:
Enable CONNECT OutgoingPorts all SSLTunneling on
Per consentire ai client di collegarsi alle porte80, 8080-8088 e 9000 e alle porte superiori sui server remoti per il tunneling SSL, impostare le seguenti direttive:
Enable CONNECT OutgoingPorts 80,8080-8088,9000-* SSLTunneling on
Le porte e gli intervalli delle porte sono separati da una virgola senza spazi.
IMPORTANTE: per le configurazioni di proxy diretto, specificare almeno 443 o all con l'opzione OutgoingPorts per abilitare il normale tunneling SSL.
Enable CONNECT OutgoingIPs [[!]IP_pattern,...]
Ad esempio, per consentire ai client di collegarsi a qualsiasi porta sui server remoti che corrispondono al nome host/indirizzo IP *.ibm.com e non corrispondono a 192.168.*.* , impostare le seguenti direttive:
Enable CONNECT OutgoingPorts all OutgoingIPs *.ibm.com,!192.168.*.* SSLTunneling on
Enable CONNECT IncomingIPs [[!]IP_Pattern,...]
Ad esempio, per consentire ai client con indirizzo IP 192.168.*.* di stabilire una connessione su qualsiasi porta sui server remoti per il tunneling SSL, impostare le seguenti direttive:
Enable CONNECT OutgoingPorts all IncomingIPs 192.168.*.* SSLTunneling on
Note:
Per ulteriori informazioni sull'abilitazione del tunneling SSL e delle direttive CONNECT modificando il file di configurazione del proxy, fare riferimento alle sezioni in Appendice B, Direttive del file di configurazione per le seguenti direttive:
L'amministrazione remota di Caching Proxy si può ottenere utilizzando le funzioni di sicurezza fornite dall'SSL (Secure Sockets Layer) e l'autenticazione della password. Questo riduce in maniera significativa la possibilità di accesso al server proxy da parte di persone non autorizzate.
Per applicare l'SSL durante l'amministrazione remota del server, utilizzare una richiesta https:// invece di una richiesta http://, per aprire i moduli di configurazione e amministrazione. Ad esempio:
https://nome.server/FrontPage.html
Come precedentemente osservato, prima di configurare l'SSL è necessario impostare un database di chiavi o creare un certificato. I certificati vengono utilizzati per autenticare le identità server. Utilizzare il programma di utilità IBM Key Management (a volte chiamato iKeyman) per impostare i file di certificazione. Questo programma di utilità fa parte del software GSKit, incluso con il server delle applicazioni. GSKit, inoltre, comprende un'interfaccia grafica basata su Java per l'apertura dei file certificato.
Di seguito vengono riportate le fasi di base per impostare le chiavi SSL e i certificati.
Su tutti i sistemi operativi ad eccezione di Linux, se il certificato è scaduto, Caching Proxy non viene avviato correttamente e viene visualizzato un messaggio di errore che indica che il database di chiavi è scaduto. In Linux, il proxy sembra avviarsi ma il processo scompare rapidamente e non viene generato alcun messaggio di errore.
Per evitare questo problema su sistemi Red Hat Enterprise Linux 3.0, verificare che i pacchetti GCC si trovino ai seguenti livelli (o superiori):
La chiave pubblica deve essere associata a un certificato con firma digitale da un'autorità di certificazione (CA) designata come CA root sicura sul server. È possibile acquistare un certificato firmato inoltrando una richiesta per un certificato al provider CA. Caching Proxy supporta le seguenti CA esterne:
Per impostazione predefinita, le seguenti CA vengono designate come sicure:
Questa sezione offre un riferimento rapido per l'uso del programma di utilità IBM Key Manager (iKeyman). Utilizzare il gestore chiavi per creare il file database di chiavi SSL, la coppia di chiavi pubbliche-private e la richiesta di certificato. Dopo aver ricevuto il certificato firmato dalla CA, utilizzare il gestore chiavi per inserire il certificato nel database di chiavi in cui è stata creata la richiesta originale di certificato.
La documentazione più dettagliata dell'IBM Key Manager e GSKit viene fornita congiuntamente al software GSKit.
Impostazione del sistema per eseguire il gestore chiavi
Prima di avviare la GUI IKeyman, effettuare le seguenti operazioni:
Note:
ibmjcefw.jar ibmpkcs11.jar
ibmjceprovider.jar ibmpkcs.jar
local_policy.jar US_export_policy.jar
Aggiornare il file JAVA_HOME/jre/lib/security/java.security per aggiungere i provider IBM CMS successivamente al provider Sun. Ad esempio:
security.provider.1=sun.security.provider.Sun security.provider.2=com.ibm.spi.IBMCMSProvider security.provider.3=com.ibm.crypto.provider.IBMJCE
Un file di esempio java.security è disponibile in GSKit_Installation_path/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
Avvio del gestore chiavi
Avviare l'interfaccia utente grafica (GUI) del gestore chiavi, come segue:
Notare che se durante questa sessione viene creato un file database di chiavi, il file viene memorizzato nella directory da cui è stato avviato il gestore chiavi.
Un database di chiavi è un file che il server utilizza per memorizzare una o più coppie di chiavi e certificati. È possibile utilizzare un database di chiavi per tutte le coppie di chiavi e per tutti i certificati, oppure è possibile creare più database. Il programma di utilità di gestione chiavi viene utilizzato per creare nuovi database di chiavi e per specificare le relative password e file stash.
Per creare un database di chiavi e un file stash:
La password specificata quando viene creato un nuovo database di chiavi protegge la chiave privata, ossia l'unica che dispone dell'autorizzazione necessaria per firmare i documenti o decodificare i messaggi codificati con la chiave pubblica.
Per specificare la password, utilizzare le seguenti istruzioni:
Si consiglia di modificare la password del database di chiavi frequentemente. Tuttavia, se viene specificata una data di scadenza per la password, annotarla. Se la password scade prima che venga modificata, viene scritto un messaggio sul log degli errori e il server viene avviato ma le connessioni di rete non saranno protette.
Per modificare la password database di chiavi, seguire le fasi riportate sotto:
Per una connessione SSL tra un proxy e un server LDAP, collocare la password del database delle chiavi nel file pac_keyring.pwd. (Notare che il file pac_keyring.pwd non è un file stash generato da IKeyMan.)
Creazione di una nuova coppia di chiavi e della richiesta di certificato
Il database di chiavi memorizza le coppie di chiavi e le richieste di certificati. Per creare una coppia di chiavi pubbliche-private e una richiesta di certificato, seguire le fasi riportate sotto:
Una nuova richiesta di certificato è stata creata con esito positivo nel file nome_database_filechiavi.
Le richieste di certificato possono impiegare tra due e tre settimane per essere soddisfatte. Mentre si attende che la CA elabori la richiesta di certificato, è possibile agire da CA e utilizzare iKeyman per creare l'autocertificazione per abilitare le sessioni SSL tra i client e il server Caching Proxy.
Creazione di un certificato autofirmato
Utilizzare il programma di utilità di gestione chiavi per creare un certificato autofirmato per abilitare le sessioni SSL tra i client e il server proxy durante l'attesa di un certificato. Il certificato autofirmato è utile per effettuare le prove.
Per creare un certificato autofirmato, seguire la procedura riportata sotto:
Esportazione di chiavi
Utilizzare questa procedura per esportare le chiavi in un altro database di chiavi:
Importazione di chiavi
Per importare le chiavi da un altro database di chiavi:
Elenco autorità di certificazione
Per visualizzare un elenco di autorità di certificazione (CA) sicure in un database di chiavi:
Utilizzare questa procedura per ricevere un certificato inviato tramite posta elettronica da un'autorità di certificazione (CA) designata come CA sicura per impostazione predefinita (vedere l'elenco riportato in Autorità di certificazione). Se la CA che ha emesso il certificato non è una CA sicura nel database di chiavi, è necessario prima memorizzare il certificato della CA e definire questa CA come sicura. Successivamente, è possibile ricevere il certificato firmato dalla CA nel database. Non è possibile ricevere un certificato firmato da una CA che non è definita come sicura (vedere Memorizzazione del certificato di unaCA).
per ricevere un certificato firmato da CA in un database di chiavi:
Solo i certificati firmati dalle CA sicure vengono accettate per stabilire connessioni protette. Per aggiungere una CA all'elenco di autorità sicure, è necessario ottenere e memorizzare il relativo certificato come sicuro. Seguire questa procedura per memorizzare un certificato da una nuova CA, prima di riceverla nel database:
Visualizzazione della chiave predefinita in un database di chiavi
Visualizzare la voce chiave predefinita come segue:
Gli algoritmi di codifica e i caratteri hash per le versioni SSL 2 e 3, sono elencati nelle tabelle seguenti.
Creazione coppie di chiavi: dimensioni chiave privata RSA 512-1024
SSL versione 2
Versione USA | Versione esportazione |
RC4 US | RC4 Export |
RC2 US | RC2 Export |
DES 56-bit | non applicabile |
Triple DES US | non applicabile |
RC4 Export | non applicabile |
RC2 Export | non applicabile |
SSL versione 3
Versione USA | Versione esportazione |
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 | non applicabile |
DES CBC SHA | non applicabile |
NULL SHA | non applicabile |
NULL MD5 | non applicabile |
NULL NULL | non applicabile |
Queste specifiche SSL possono essere anche configurate modificando direttamente il file di configurazione proxy. Per maggiori dettagli, fare riferimento alle sezioni in Appendice B, Direttive del file di configurazione per le seguenti direttive:
Crittografia a 128 bit per Caching Proxy
Attualmente viene distribuita solo la versione di codifica a 128 bit di Caching Proxy. La versione a 56 bit non è più disponibile. Se si sta aggiornando una versione precedente, è possibile installare Caching Proxy direttamente sul sistema a 128 bit o a 56 bit correntemente installato. Se precedentemente si utilizzava un browser (esportazione) a 56 bit, è necessario effettuare l'aggiornamento a un browser a 128 bit per poter usufruire della codifica a 128 bit nel proxy.
Dopo un aggiornamento da una versione a 56 bit di Caching Proxy alla versione a 128 bit, se le dimensioni della chiave utilizzata per codificare i certificati sono impostate su 1024, non è necessaria alcuna modifica di configurazione. Tuttavia, se sono impostate su 512, per usufruire della codifica a 128 bit del proxy, è necessario creare nuovi certificati con dimensioni 1024. Creare le nuove chiavi utilizzando il programma di utilità IBM Key Manager (iKeyman).
Fare riferimento a Gestione certificati e chiavi per una descrizione dettagliata del programma di utilità IBM Key Manager.
Notare che questa versione del prodotto non supporta la codifica su SUSE Linux.
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
Seguire questa procedura per consentire che la routine di sincronizzazione SSL venga scaricata su una scheda di hardware crittografico:
Su AIX, per poter supportare IBM 4960 PCI Cryptographic Accelerator Card, fare riferimento a PKCS11DefaultCert, PKCS11DriverPath, PKCS11TokenPassword -- Supporta IBM 4960 PCI Cryptographic Accelerator Card (solo AIX).
Un plug-in di Caching Proxy viene fornito insieme a Tivoli Access Manager (in precedenza Tivoli Policy Director) che consente a Caching Proxy di utilizzare Access Manager per l'autenticazione e l'autorizzazione. Questo plug-in consente a un'azienda che utilizza Access Manager per il controllo degli accessi al Web di aggiungere la tecnologia Edge senza dover raddoppiare il lavoro, impostando degli schemi di autorizzazione separati per il server proxy.
Per maggiori informazioni su Tivoli Access Manager, visualizzare il sito Web del prodotto all'indirizzo http://www.ibm.com/software/tivoli/products/. Per informazioni sui requisiti software e hardware e sull'installazione del plug-in di Access Manager, fare riferimento alla documentazione fornita con Tivoli Access Manager.
Insieme al plug-in di Access Manager viene fornito uno script di configurazione per Caching Proxy.
Prima di eseguire lo script, effettuare quanto segue:
Lo script di configurazione si chiama wslconfig.sh ed è fornito nella directory /opt/pdweb-lite/bin/. Inserire l'ID amministratore di Access Manager e il nome dell'amministratore LDAP se richiesti.
Lo script di configurazione esegue automaticamente le seguenti operazioni:
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
Crea un'istruzione Protect ed una configurazione Protection che inoltra tutte le richieste al processo di autenticazione di Access Manager, come riportato di seguito:
Protection PROXY-PROT { ServerId WebSEAL-Lite Mask All@(*) AuthType Basic } Protect * PROXY-PROT
Dopo aver configurato il server proxy e il plug-in di Access Manager, utilizzare il comando wslstartwte invece di ibmproxy start per avviare il server proxy. Il comando wslstartwte carica automaticamente le variabili di ambiente richieste dal plug-in di Access Manager per effettuare l'inizializzazione. Se non si utilizza wslstartwte quando si avvia il server proxy, verranno visualizzati dei messaggi di errore relativi al plug-in di Access Manager. Il comando di arresto corrispondente, ibmproxy stop, è valido anche quando si utilizza il plug-in.
Il modulo di autorizzazione PAC-LDAP consente a Caching Proxy di accedere a un server LDAP (Lightweight Directory Access Protocol) durante l'esecuzione di routine di autorizzazione o autenticazione. Il modulo è costituito da due serie di componenti: una coppia di librerie condivise che aggiungono la funzionalità LDAP all'API di Caching Proxy e un daemon éAC (Policy Authentication Control). Una direttiva ServerInit nel file ibmproxy.conf indica alla libreria condivisa di inizializzare uno o più daemon PAC all'avvio del Caching Proxy. Per determinare il numero e le caratteristiche dei daemon PAC, le librerie condivise leggono un file paccp.conf. Durante l'inizializzazione, il daemon legge i file pac.conf per le direttive di configurazione e pacpolicy.conf per le informazioni sulle politiche. Quindi, una direttiva di autenticazione nel file ibmproxy.conf indica al server proxy di richiamare la libreria condivisa ogni qualvolta sia necessaria l'autenticazione, oppure la direttiva di autenticazione utilizzerà il flusso di lavoro del Caching Proxy durante l'elaborazione della richiesta HTTP standard.
Il processo di autenticazione determina se una serie di credenziali fornita, nome utente e password, è valida. Questo processo include la verifica della presenza di un utente nel registro e della password fornita, che deve corrispondere a quella memorizzata nel registro. Queste azioni vengono eseguite utilizzando il modulo PAC-LDAP durante la fase di autenticazione.
Quando il modulo di autorizzazione PAC-LDAP viene abilitato per l'autenticazione, diventa il repository predefinito da vengono richiamati gli ID utenti, le password e i gruppi. Quando una richiesta HTTP passa attraverso il flusso di lavoro del Caching Proxy, ciascuna direttiva Protect confronta l'URL della richiesta con il relativo modello di richiesta. In caso di corrispondenza, la direttiva Protect richiama uno schema di protezione che include l'ID server, il tipo di autenticazione da utilizzare, le regole relative alle maschere da applicare al client richiedente e le posizioni dei file password e gruppi. Se il file password non è definito, l'ID utente e la password vengono richiamati tramite il modulo di autorizzazione PAC-LDAP. Le politiche di tipo 0, 1, 2 e 3 definiscono gli schemi di autenticazione. Se l'autenticazione viene inoltrata, la richiesta viene supportata; altrimenti, il Caching Proxy restituisce un errore 401 al client.
Il processo di autorizzazione determina se un utente dispone del permesso necessario per accedere a una risorsa protetta. Quando viene utilizzato il modulo PAC-LDAP, comprende l'applicazione delle regole di autorizzazione che risiedono nel file pacpolicy.conf per la richiesta HTTP.
Quando il modulo di autorizzazione PAC-LDAP è abilitato per l'autorizzazione, le relative regole presenti nel file pacpolicy.conf vengono applicate alla richiesta HTTP. Quando una richiesta HTTP passa attraverso il flusso di lavoro del Caching Proxy, ciascuna direttiva Protect confronta l'URL della richiesta con il relativo modello di richiesta. In caso di corrispondenza, la direttiva Protect richiama uno schema di protezione. In questo caso, lo schema di protezione è la routine di autorizzazione utilizzata dal modulo di autorizzazione PAC-LDAP. La direttiva Authorization confronta l'URL richiesto con il relativo modello di richiesta e, in caso di corrispondenza, viene richiamato il modulo di autorizzazione PAC-LDAP. Le politiche di tipo 4 definite nel file pacpolicy.conf ridefiniscono ulteriormente l'autenticazione necessaria per le varie richieste URL.
LDAP consente l'accesso interattivo alle directory X.500 con un consumo minimo di risorse del sistema. IANA ha assegnato la porta TCP 389 e la porta UDP 389 all'LDAP. Per ulteriori informazioni, fare riferimento all'RFC 1777, che definisce il LDAP.
Tra gli esempi di client LDAP supportati vi sono il client IBM Tivoli LDAP e il client IBM SecureWay LDAP.
Tutti i componenti del modulo di autorizzazione PAC-LDAP vengono installati automaticamente quando viene installato il sistema Caching Proxy di WebSphere Application Server, versione 7.0. Su sistemi Linux e UNIX, vengono create una directory di librerie diCaching Proxy (./lib/), una directory di librerie del modulo di autorizzazione PAC-LDAP (./lib/plugins/pac/), una directory binaria (./bin/) e una directory di configurazione (./etc/) all'interno della directory /opt/ibm/edge/cp/. Vengono quindi creati i collegamenti simbolici dalle directory /usr/lib/, /usr/sbin/ e /etc alle directory specifiche di questi prodotti.
Struttura della directory
Directory Linux e UNIX | Directory Windows | Contenuto |
---|---|---|
/opt/ibm/edge/cp/ | \Program Files\IBM\edge\cp\ | Directory di base di Caching Proxy (root_cp) |
root_cp/sbin/ | \Program Files\IBM\edge\cp\Bin\ | Script e file binari di Caching Proxy |
/usr/sbin/ |
| Collegamenti simbolici a root_cp/sbin/ |
root_cp/etc/ | \Program Files\IBM\edge\cp\etc\ | File di configurazione di Caching Proxy |
/etc/ |
| Collegamenti simbolici a root_cp/etc/ |
root_cp/lib/ | \Program Files\IBM\edge\cp\lib\ plugins\ | Librerie di Caching Proxy |
root_cp/lib/ plugins/pac/ | \Program Files\IBM\edge\ cp\lib\plugins\pac\ | Librerie del modulo di autorizzazione PAC-LDAP |
/usr/lib/ |
| Collegamenti simbolici a cp_root/lib/ e cp_root/lib/ plugins/pac/ |
root_cp/root_server/pac/data/ | \Program Files\IBM\ edge\cp\server_root\pac\data\ | Memoria di dati del modulo di autorizzazione PAC-LDAP |
root_cp/root_server/ pac/creds/ | \Program Files\IBM\ edge\cp\server_root\pac\creds\ | Credenziali del modulo di autorizzazione PAC-LDAP |
File di plugin LDAP
Nome file Linux e UNIX | Nome file Windows | Descrizione |
---|---|---|
libpacwte.so | pacwte.dll | libreria condivisa |
libpacman.so | pacman.dll | libreria condivisa |
pacd_restart.sh | pacd_restart.bat | Script di riavvio daemon PAC |
paccp.conf, pac.conf, pacpolicy.conf | paccp.conf, pac.conf, pacpolicy.conf | File di configurazione e delle politiche |
Per abilitare le connessioni SSL protette tra il daemon PACD e il server LDAP, è necessario installare il package GSKit richiesto dal pacchetto client LDAP. GSKit 7 è richiesto e fornito per impostazione predefinita sulla macchina Caching Proxy ma potrebbe non avere la versione necessaria al client LDAP sulla macchina. È possibile utilizzare versioni differenti di GSKit sulla stessa macchina per processi differenti.
Inserire il file delle chiavi GSKit in $pacd_creds_dir/pac_keyring.kdb e la password in $pacd_creds_dir/pac_keyring.pwd.
Sui sistemi Linux, la variabile di ambiente LD_PRELOAD deve essere configurata come segue per abilitare le connessioni SSL tra il daemon PACD e il server LDAP. Impostare la variabile sul seguente valore:
LD_PRELOAD=/usr/lib/libstdc++-libc6.1-1.so.2
Il requisito GSKit a cui si è fatto riferimento precedentemente in questa sezione, è valido anche per i sistemi Linux.
Su sistemi Red Hat Enterprise Linux 4.0, il processo PACD non viene avviato quando Caching Proxy è configurato per utilizzare il plug-in LDAP ITDS 6.0 per l'autenticazione. Viene visualizzato il seguente messaggio di errore:
"errore durante il caricamento delle librerie condivise: /usr/lib/libldapiconv.so: R_PPC_REL24 relocation at 0x0fb58ad0 per il simbolo 'strpbrk' non compreso nell'intervallo"
Esiste una limitazione corrente che ITDS 6.0 non supporta i sistemi RHEL 4.0.
Il processo PACD non viene avviato su sistemi AIX a causa di collegamenti non risolti quando si utilizza il client LDAP ITDS. Quando si avvia il processo PACD, si verifica il seguente errore:
exec(): 0509-036 Impossibile caricare il programma /usr/sbin/pacd a causa dei seguenti errori: 0509-022 Impossibile caricare il modulo /usr/lib/libpacman.a. 0509-150 Impossibile caricare il modulo dipendente libldap.a. 0509-022 Impossibile caricare il modulo libldap.a.
Per risolvere questo problema per ITDS versione 5 del client LDAP, creare il seguente collegamento simbolico:
ln -s /usr/lib/libibmldap.a /usr/lib/libldap.a
Per risolvere questo problema per ITDS versione 6 del client LDAP, creare il seguente collegamento simbolico:
ln -s /opt/IBM/ldap/V6.0/lib/libibmldap.a /usr/lib/libldap.a
Tre direttive, ServerInit, Authorization o Authentication e ServerTerm devono essere aggiunge alla sezione delle direttive dell'API del file ibmproxy.conf per inizializzare il modulo di autorizzazione PAC-LDAP. Per creare tali direttive, modificare manualmente il file ibmproxy.conf oppure, se il server proxy è già in esecuzione, collegarsi ai moduli di configurazione e amministrazione con un browser Internet e aprire il modulo Elaborazione richiesta API (fare clic su Configurazione server -> Elaborazione richiesta-> Elaborazione richiesta API). (Ciascuna direttiva deve comparire su un'unica riga nel file di configurazione proxy, indipendentemente da se contengono o meno delle interruzioni di riga per per facilitarne la lettura).
Le direttive prototipo (nel modulo dei commenti) vengono fornite nella sezione API del file ibmproxy.conf. L'ordine di queste direttive API è significativo. Se si aggiungono direttive API per abilitare nuove funzioni e moduli di plug-in, ordinare le direttive come illustrato nella sezione prototipi del file di configurazione. In alternativa, eliminare il commento o modificare se necessario le direttive API per includere il supporto per ogni funzione o plug-in desiderato.
La direttiva ServerInit ha due argomenti: (1) il percorso completo della libreria condivisa, (2) la chiamata di funzione e (3) il percorso completo del file paccp.conf. Il primo e il secondo argomento sono delimitati da due punti (:). Il secondo e il terzo argomento sono delimitati da uno spazio. Il primo e il terzo argomento sono specifici del sistema e dipendono dal punto in cui sono stati installati i componenti plugin. Il secondo argomento è codificato nella libreria condivisa e deve essere digitato esattamente come illustrato. Durante la creazione di una direttiva ServerInit utilizzare il modulo Elaborazione richiesta API, è necessario inserire sia il secondo che il terzo argomento nel campo Nome funzione. Il terzo argomento viene visualizzato nella colonna Modello IP.
La direttiva Authorization ha tre argomenti: (1) un modello di richiesta, (2) il percorso completo della libreria condivisa e (3) il nome della funzione. Le richieste HTTP vengono confrontate con il modello di richiesta per stabilire se viene richiamata la funzione dell'applicazione. Il modello di richiesta può includere un protocollo, un dominio e un host; può essere proceduto da una barra (/); e può utilizzare un asterisco (*) come carattere jolly. Ad esempio, /front_page.html , http://www.ics.raleigh.ibm.com , /pub*, /* e * sono tutti validi. Il nome della funzione è il nome dato alla funzione dell'applicazione all'interno del programma. È codificato in modo permanente e deve essere digitato esattamente come mostrato. I primi due argomenti sono delimitati da uno spazio. Gli ultimi due sono delimitati da due punti (:).
La direttiva Authentication ha due argomenti: (1) il percorso completo della libreria condivisa e (2) il nome della funzione. Questi argomenti sono delimitati da due punti (:). Il primo argomento è specifico del sistema e dipende dall'installazione della libreria condivisa. Il modello URL per il primo argomento deve avviare la root del documento (/) quando si utilizza il Caching Proxy come proxy inverso. Il secondo argomento è codificato nella libreria condivisa e deve essere digitato esattamente come illustrato.
La direttiva ServerTerm ha due argomenti: (1) il percorso completo della libreria condivisa e (2) il nome della funzione. Questi argomenti sono delimitati da due punti (:). Il primo argomento è specifico del sistema e dipende dall'installazione della libreria condivisa. Il secondo argomento è codificato nella libreria condivisa e deve essere digitato esattamente come illustrato. Questa direttiva termina il daemon PAC quando il server proxy viene arrestato. Se il proprietario del daemon è differente dal quello del server proxy, il server potrebbe non essere in grado di arrestare il daemon e il daemon deve essere arrestato manualmente da un amministratore.
ServerInit percorso_libreria_condivisa:pacwte_auth_init percorso_file_politiche_conf
Esempio di Linux e UNIX:
ServerInit /usr/lib/libpacwte.so:pacwte_auth_init /etc/pac.conf
Esempio di Windows:
ServerInit C:\Progra ~1\IBM\edge\cp\lib\plugins\ pac\pacwte.dll:pacwte_auth_init C:\Progra ~1\IBM\edge\cp
Authorization request-template percorso_libreria_condivisa:pacwte_auth_policy
Esempio di Linux e UNIX:
Authorization http://* /usr/lib/libpacwte.so:pacwte_auth_policy
Esempio di Windows:
Authorization http://* C:\Program Files\IBM\edge\cp\lib\plugins\ pac\pacwte.dll:pacwte_auth_policy
Authentication BASIC percorso_libreria_condivisa:pacwte_auth_policy
Esempio di Linux e UNIX:
Authentication BASIC /usr/lib/plugins/pac/libpacwte.so:pacwte_auth_policy
Esempio di Windows:
Authentication BASIC C:\Program Files\IBM\edge\cp\lib\plugins\ pac\pacwte.dll:pacwte_auth_policy
ServerTerm path_of_shared_library:pacwte_shutdown
Esempio di Linux e UNIX:
ServerTerm /usr/lib/libpacwte.so:pacwte_shutdown
Esempio di Windows:
ServerTerm BASIC C:\Program Files\IBM\edge\cp\lib\plugins\ pac\bin\pacwte.dll:pacwte_shutdown
I file di configurazione e delle politiche del modulo di autorizzazione PAC-LDAP devono essere modificati manualmente con un editor di testo. Un nome direttiva è separato dal primo argomento da due punti (:). Più argomenti sono delimitati da virgole (,). Nel file di configurazione e delle politiche sono incluse le note per facilitare la modifica. Le direttive delle politiche delle chiavi sono mostrate di seguito.
Il paccp.conf viene letto dalle librerie condivise durante l'inizializzazione di Caching Proxy e contiene le definizioni (stanza [PAC_MAN_SERVER]) di ogni daemon PAC che verrà avviato. Ciascun daemon PAC deve disporre della propria stanza [PAC_MAN_SERVER].
[PAC_MAN_SERVER] hostname: # nome del daemon PAC port: # porta su cui è in ascolto pacd [PACWTE_PLUGIN] hostname_check:[true|false] # consente la ricerca DNS. Deve avere # la ricerca DNS attivata per ibmproxy per funzionare.
Il file pac.conf specifica il server LDAP con cui il daemon PAC tenta di eseguire la connessione.
[PAC_MAN_SERVER] hostname: # nome del daemon PAC port: # porta su cui è in ascolto pacd conn_type:ssl # impostare come commento se non viene utilizzato SSL authentication_sequence: [primary|secondary|none] authorization_sequence: [primary|secondary|none] [LDAP_SERVER] hostname: # nome host server LDAP port:389 # Porta su cui è in ascolto LDAP ssl_port:636 # Porta SSL utilizzata dal server LDAP admin_dn: # Utente con autorizzazione ad accedere al server LDAP # specificare admin_dn:NULL per abilitare il collegamento anonimo search_base: # Parte struttura ad albero LDAP per cercare le info # Se non è richiesto, specificare search_base:NULL search_key: # Campo ID da ricercare [CACHE] cred_cache_enabled [TRUE|FALSE] # attivare la cache delle credenziali cred_cache_min_size:100 # num. min. di credenziali da memorizzare nella cache in pacd cred_cache_max_size:64000 # num. max. di credenziali da memorizzare nella cache in pacd cred_cache_expiration:86400 # quando una credenziale scade policy_cache_enabled:[TRUE|FALSE] # attivare/disattivare la cache delle politiche policy_cache_min_size:100 # numero min. di voci correl. a politiche da memorizzare in cache policy_cache_max_size:64000 # numero max. di voci correl. a politiche da memorizzare in cache policy_cache_expiration:86400 # quando una voce correlata alle politiche scade
Tutte le politiche LDAP utilizzano il seguente modello nel file di configurazione e delle politiche. Ciascuna politica deve iniziare con la parola chiave POLICY in maiuscolo tra parentesi.
[POLICY] default_policy:[grant|deny] # descrive la politica predefinita per gli utenti # che non sono descritti nella sezione POLICY pac_client_hotname: # le istanze di Caching Proxy che possono # utilizzare un elenco delle politiche id: # l'ID per la voce LDAP o ip/nomehost # (caratteri jolly, ad esempio *.ibm.com, supportati) grant:[true|false] # true consente l'accesso, false # lo nega type:[0|1|2|3|4] # 0 voce LDAP che rappresenta il gruppo, # 1 voce LDAP che non rappresenta un gruppo, # 2 indirizzo IP # 3 nome host # 4 URL propagate:[true|false] # true indica che i diritti di accesso (concedi # o nega) verranno propagati a tutti # i discendenti o membri stop_entry:[entry|NULL] # La propagazione di questo diritto di accesso si ferma # a questa voce. Se l'ID è un gruppo, # stop_entry deve essere impostata su NULL. # stop_entry può essere applicata a un indirizzo IP # o a un nome host. Ciascuna stop_entry # deve essere contenuta sulla propria riga exception_entry:[entry|NULL] # L'assegnazione del diritto di accesso ignora # queste voci ma continua attraverso il relativo # sottoalbero, che potrebbe essere un elenco di voci # exception_entry può essere applicata a un gruppo, # un indirizzo IP o un nome host. Ciascuna # exception_entry deve essere contenuta nella propria riga. Exception_type: Eccezione:
Il carattere jolly (*) è supportato solo per l'ultima posizione di un indirizzo IP o per la prima posizione di un nome host nelle direttive id e stop_entry . I caratteri jolly non sono supportati nella exception_entry . I caratteri jolly non sono supportati per le voci LDAP in qualsiasi campo.
Sono supportate più politiche e il valore false ha la priorità in caso di politiche in conflitto. In altre parole, una singola negazione in una qualsiasi politica blocca l'accesso. L'ordine in cui le politiche vengono elencate nel file di configurazione e delle politiche è irrilevante e non stabilisce una priorità.
Per una serie di esempi di politiche, fare riferimento al file pacpolicy.conf nella directory dei file di configurazione.
Creare un file di testo normale denominato pac_ldap.cred in /cp_root/server_root/pac/creds . Questo file contiene la password corrispondente al nome utente nella direttiva admin_dn, che si trova nel file pac.conf.
Il daemon PAC codifica la password la prima volta che legge il file.
Per creare il file pac_ldap.cred sulle piattaforme Linux e UNIX, immettere i seguenti comandi:
cd cp_root/server_root/pac/creds echo "password" > pac_ldap.cred chown nobody pac_ldap.cred chgrp nobody pac_ldap.cred (su SUSE Linux, utilizzare chgrp nogroup pac_ldap.cred.)
Per creare il file su una piattaforma Windows, digitare la password in un file di testo e memorizzare il file nella directory server_root\pac\creds\.
Il daemon di autorizzazione LDAP viene eseguito come processo pacd. È possibile riavviare il daemon di autorizzazione LDAP senza interrompere il Caching Proxy, utilizzando gli script forniti. Eseguire lo script pacd come segue:
/usr/sbin/pacd_restart.sh id_utente_pacd
C:\Program Files\IBM\edge\cp\Bin\pacd_restart.bat root_install_CP
kill -15 ID_processo_pacd
Su HP-UX: il plugin PAC-LDAP e pacd potrebbero non caricare tutte le librerie condivise dipendenti al runtime. Prima di utilizzarle, verificare che le variabili di sistema siano impostate come segue
SHLIB_PATH=/usr/lib:/usr/IBMldap/lib PATH=/usr/IBMldap/bin:$PATH PATH=/usr/IBMldap/bin/usr/IBMldap/ è il percorso di installazione per il client LDAP su HP-UX. Se il clientLDAP è installato in una posizione differente, regolare PATH e SHLIB_PATH di conseguenza. Se non vengono impostate queste variabili, potrebbero verificarsi i seguenti errori:
"Errore Serverinit: il server non ha caricato le funzioni dal dal modulo DLL /opt/ibm/edge/cp/lib/plugins/pac/libpacwte.sl"
"/usr/lib/dld.sl: Impossibile trovare il percorso per la libreria condivisa: libibmldap.sl /usr/lib/dld.sl: Nessuna interruzione di file o Abort"
Su Linux: per SUSE Linux Enterprise Server 9, l'ldd pacd può riportare che libldap.so non è stato trovato. Per risolvere il problema, creare la seguente stringa simbolica:
ln -s /usr/lib/libldap.so.19 /usr/lib/libldap.so
Su AIX: all'avvio di pacd con IBM Tivoli Directory Server 5.2, il modulo PAC-LDAP potrebbe non essere in grado di caricare quanto risulta dal seguente errore:
exec(): 0509-036 Impossibile caricare il programma /usr/sbin/pacd a causa dei seguenti errori: 0509-022 Impossibile caricare il modulo /usr/lib/libpacman.a. 0509-150 Impossibile caricare il modulo dipendente libldap.a. 0509-022 Impossibile caricare il modulo libldap.a.
Per risolvere il problema, creare la seguente stringa simbolica:
ln -s /usr/lib/libibmldap.a /usr/lib/libldap.a
Impossibile estrarre un valore per: Uid, codice di ritorno:3
Questo errore viene visualizzato anche quando l'autenticazione LDAP funziona correttamente e può essere ignorata.
Questa sezione fornisce istruzioni per il monitoraggio di Caching Proxy mediante log e Controllo attività del server.
Questa sezione contiene i seguenti argomenti:
Configurazione della registrazione
Utilizzo del controllo attività del server
Per personalizzare la registrazione, è possibile utilizzare i moduli di configurazione e amministrazione o modificare le direttive nel file di configurazione del proxy. È possibile impostare le seguenti opzioni:
Caching Proxy può creare tre tipi di log di accesso, oltre al log eventi e degli errori:
Caching Proxy crea nuovi file di log ogni giorno a mezzanotte. Se il proxy non è in esecuzione a mezzanotte, al suo primo riavvio in quel giorno vengono creati nuovi log. È possibile specificare la directory e il prefisso del nome file di ciascun file di log; ogni file di log creato contiene un suffisso data in formato .Mmmddyyyy (ad esempio, .Apr142000).
Poiché i file di log possono utilizzare una grande quantità di spazio, memorizzare i file di log su un dispositivo di memorizzazione separato dal sistema operativo e dalla cache per evitare errori. Inoltre, configurare le routine di manutenzione dei log, come indicato in Gestione e archiviazione di log.
Per specificare la configurazione di base dei log del server proxy, nei moduli di configurazione e amministrazione selezionare Configurazione server -> Registrazione -> File di log. Specificare il percorso e il nome file di ciascun file di log che si desidera utilizzare. Il nome file corrente di ciascun log viene visualizzato nella casella di testo corrispondente; se non è stato specificato alcun percorso, viene visualizzato il percorso predefinito.
Le informazioni registrate nei log del proxy non vengono scritte automaticamente sul log di sistema, me è possibile configurare Caching Proxy in modo da poter scrivere sul log di sistema insieme o al posto dei log di cui dispone. Sul modulo File di log, selezionare la casella di controllo Informazioni di log su Syslog. Il log di sistema deve essere creato prima che questa opzione venga selezionata.
Per specificare che le informazioni di log del server proxy vengono scritte solo sul log di sistema, è necessario modificare il file di configurazione proxy; fare riferimento alla sezione LogToSyslog -- Specifica se inviare le informazioni di accesso al log di sistema (solo Linux e UNIX).
Direttive del file di configurazione correlate
Per impostare i log mediante il file di configurazione proxy, fare riferimento alle sezioni in Appendice B, Direttive del file di configurazione per le seguenti direttive:
I log di accesso registrano l'attività della macchina host, del proxy e della cache. Per ogni richiesta di accesso ricevuta dal proxy, una voce del log di accesso appropriato include le seguenti informazioni:
Gli errori di accesso vengono registrati nel log degli errori del server.
Esistono diversi motivi per limitare quanto è stato registrato:
La dimensione dei file di log di un server occupato può aumentare fino a completare lo spazio del disco del server. Per impostazione predefinita, tutte le richieste di accesso vengono registrate, ciò vuol dire che le voci di log vengono create non solo per una pagina HTML ma per ogni immagine di quella pagina. Includendo solo le richieste di accesso più importanti, è possibile ridurre in modo significativo il numero di voci nel log. Ad esempio, è possibile configurare i log di accesso in modo da includere le voci di log per le richieste di accesso della pagina HTML, ma non per le richieste delle immagini GIF.
Ad esempio, se si desidera sapere chi accede dal server da una sede esterna alla società, è possibile filtrare le richieste di accesso che hanno origine dagli indirizzi IP all'interno della società. Se si desidera sapere il numero di visitatori di un determinato sito Web, è possibile creare un log di accesso che mostra solo le richieste di accesso di quell'URL.
Le informazioni escluse da quei log di accesso non sono registrate in nessun report di accesso e non sono disponibili per essere utilizzate in futuro. Per questo motivo, se si è sicuri della quantità di informazioni di accesso che si devono tracciare, applicare i filtri di esclusione con prudenza fino ad acquisire una certa esperienza nel controllo del server.
Le voci dei log di accesso possono essere filtrate in base ai seguenti attributi:
Per specificare i filtri, nei moduli di configurazione e amministrazione, selezionare Configurazione server -> Registrazione -> Esclusioni log di accesso. Specificare solo le esclusioni desiderate. Non è necessario utilizzare tutte le categorie.
Fare clic su Inoltra.
Direttive del file di configurazione correlate
Per impostare i filtri del log di accesso mediante il file di configurazione proxy, fare riferimento alle sezioni in Appendice B, Direttive del file di configurazione per le seguenti direttive:
Tutti i log sono abilitati nella configurazione predefinita di Caching Proxy. Vengono memorizzati nella sottodirectory logs/ della directory di installazione. I percorsi predefiniti sono i seguenti:
Ogni nome di file di log è una combinazione del nome di base e di un suffisso data nel formato .Mmmddyyyy, ad esempio, proxy.Feb292000.
I log vengono memorizzati nel formato file comune per impostazione predefinita. È disponibile anche un formato di log combinato e può essere impostato aggiungendo la seguente riga al file di configurazione proxy (ibmproxy.conf).
LogFileFormat combinato
Il formato di log combinato è simile al formato comune ma ha dei campi aggiunti che mostrano le informazioni sulla provenienza, sull'agente utente e sui cookie. Il formato dell'ora locale è quello predefinito.
Per impostazione predefinita, tutte le richieste di accesso vengono registrate nel log di accesso corretto mentre nel log di sistema non viene registrata alcuna informazione di accesso. Le informazioni sul log degli errori vengono scritte solo nel log degli errori, mentre quelle sul log eventi vengono scritte solo sul log eventi.
Nella configurazione predefinita, i log non vengono archiviati o eliminati.
Per gestire i log, Caching Proxy utilizza un plug-in. Per ulteriori informazioni, fare riferimento a Appendice B, Direttive del file di configurazione per la direttiva del file di configurazione Midnight -- Specifica il plugin dell'API utilizzato per archiviare i log.
È possibile specificare come archiviare e rimuovere giornalmente i log. Le opzioni di base sono:
Per impostazione predefinita, i log del giorno corrente e di quello precedente non vengono mai eliminati dall'agente di gestione. Tutti i log del giorno corrente e i log di accesso della cache del giorno precedente non vengono mai compressi dall'agente di gestione.
Per configurare la gestione dei log, nei moduli di configurazione e amministrazione selezionare Configurazione server -> Registrazione -> Archiviazione di log. In questo modulo, utilizzare la casella a discesa per specificare il metodo di gestione.
Direttive del file di configurazione correlate
Per configurare l'archiviazione dei log mediante il file di configurazione proxy, fare riferimento alle sezioni in Appendice B, Direttive del file di configurazione per le seguenti direttive:
Il seguente esempio mostra come personalizzare la registrazione in base alle proprie esigenze. Si supponga di avere appena acquistato e installato Caching Proxy. Se si desidera impostare il server in base alle informazioni sui log di accesso e degli errori con i seguenti requisiti:
Per configurare Caching Proxy in modo da conservare i log in base a questi criteri, nei moduli di configurazione e amministrazione selezionare Configurazione server -> Registrazione.
Queste direzioni producono le seguenti righe nel file di configurazione proxy:
LogArchive purge PurgeAge 30 PurgeSize 25 AccessLogExcludeURL *.gif NoLog 130.128.*.* AccessLogExcludeReturnCode 300
Tramite il Controllo attività del server di Caching Proxy è possibile visualizzare le statistiche sulle prestazioni del server e della rete, lo stato del server e della rete e le voci dei log di accesso. Il controllo può essere utilizzato in remoto e non è necessario che si trovi sulla stessa macchina su cui è in esecuzione il server proxy. Il Controllo attività del server è abilitato per impostazione predefinita e non richiede configurazione.
Esistono due modi per avviare il Controllo attività del server:
http://your.server.name/Usage/Initial
A differenza di altri moduli del client di configurazione, i moduli di questa categoria non impostano le configurazioni del server, ma visualizzano i dati relativi all'uso del server. Questi moduli forniscono delle informazioni molto importanti che possono essere visualizzate in un'unica finestra di console.
Le seguenti sezioni mostrano il tipo di informazioni fornite dal Controllo attività del server e suggerisce come utilizzarle per ottimizzare le prestazioni.
Sono disponibili diverse pagine di Controllo attività del server:
Ogni pagina ha un pulsante Aggiorna che può essere utilizzato per aggiornare le informazioni.
Statistiche delle attività
La Tabella 4 mostra un esempio della pagina Statistiche delle attività.
Tabella 4. Statistiche delle attività
Statistiche delle attività | |
---|---|
Connessioni | 1 Attiva, 431 massimo |
Tempo di risposta | Non disponibile |
Velocità di trasmissione | 0 connessioni/secondo |
Richieste elaborate oggi | 0 |
Numero totale di richieste elaborate | 114 |
Errori di richiesta | 3 |
Le statistiche delle attività del server possono essere utilizzate per controllare il traffico del server in termini di numero di richieste di accesso, tempo di risposta, velocità di trasmissione, richieste elaborate oggi, numero totale di richieste elaborate ed errori. Le seguenti modifiche, apportate alla configurazione, influiscono sulle statistiche sulla pagina Attività.
Statistiche di rete
La Tabella 5 mostra una esempio della pagina Statistiche di rete.
Tabella 5. Statistiche di rete
Statistiche di rete | |
---|---|
Dati in uscita: | 1K byte/secondi |
Dati in entrata: | 1K byte/secondi |
Larghezza di banda ridotta: | 3 K byte (0K byte/secondi) |
Larghezza di banda ridotta oggi: | 0 K byte (0 byte/secondi) |
Il modulo Statistiche di rete fornisce le informazioni sulla rete su cui è in esecuzione il proxy, includendo la velocità di dati per i byte inviati e ricevuti.
Statistiche di accesso
La pagina delle Statistiche di accesso visualizza le 20 voci più recenti nei log di accesso. Questa pagina visualizza le voci recenti nel log di accesso proxy (tipo in nero) e nel log di accesso cache (tipo in blu). È possibile personalizzare ciò che è visualizzato personalizzando ciò che è registrato. Per ulteriori informazioni sulle statistiche dei log di accesso, fare riferimento a Filtri di log di accesso.
Statistiche di accesso proxy
Il modulo Statistiche di accesso proxy fornisce informazioni sull'attività del proxy, come ad esempio gli URL che sono stati richiesti e se sono stati forniti dalla cache. Oltre agli URL, sono presenti i codici di ritorno forniti ai client e la dimensione file in byte. Le seguenti impostazioni possono migliorare le statistiche di accesso proxy:
Statistiche cache
Se la memorizzazione nella cache è abilitata, la pagina Statistiche cache mostra le informazioni di accesso cache più recenti. Fornisce le informazioni sulla cache e sull'indice, incluso quanto segue:
Molte opzioni di configurazione della cache modificano i risultati delle statistiche di cache (consultare Configurazione della memorizzazione nella cache del server proxy).
Riepilogo aggiornamento cache
Se l'agente cache è configurato per precaricare i file nella cache, la pagina Riepilogo aggiornamento cache mostra le informazioni sull'esecuzione più recente dell'agente cache. L'agente cache deve essere stato eseguito almeno una volta affinché queste informazioni vengano visualizzate. Per modificare la modalità di funzionamento dell'agente di aggiornamento cache, considerare quanto segue:
In questa sezione sono forniti i riferimenti ai comandi del server proxy.
Scopo
Utilizzare il comando cgiparse per analizzare la variabile di ambiente QUERY_STRING degli script CGI. Se la variabile di ambiente QUERY_STRING non è impostata, il comando legge i caratteri CONTENT_LENGTH dall'input standard. Tutti gli output restituiti vengono scritti sull'output standard.
Formato
cgiparse -Flag [Modifier]
Parametri
Gli indicatori, i relativi equivalenti di un carattere (-k -f -v -r -i -s -p -c -q -P) e le funzioni, includono:
eval 'cgiparse -init'
Questo imposta la variabile di ambiente QUERY_STRING, senza considerare se è stato utilizzato il metodo GET o POST.
cgiparse può essere richiamato più volte nello stesso script se si utilizza il metodo GET, ma deve essere richiamato una sola volta se si utilizza il metodo POST. Con il metodo POST, una volta letto l'input standard, il successivo cgiparse trova l'input standard vuoto e attende per un periodo indefinito.
Esempi
I seguenti esempi ignorano il fatto che, in realtà, QUERY_STRING è già impostata dal server. Nei seguenti esempi, $ è il prompt della shell Bourne.
$ 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! $
Risultati
Scopo
Utilizzare il comando cgiutils nei programmi nph (no-parse header) per produrre una risposta HTTP 1.0 completa.
Formato
cgiutils -Flag [Modifier]
Se Modificatore contiene degli spazi vuoti, includerli tra virgolette ("").
Parametri
cgiutils -ct text/html
Se si omette tipo/sottotipo, il tipo di contenuto MIME è impostato su text/plain predefinito. Questo esempio imposta il tipo di contenuto MIME su text/plain.
cgiutils -ct
cgiutils -ce x-compress
cgiutils -cl en_UK
cgiutils -expires 2 giorni 12 ore
Il comando cgiutils aggiunge l'ora specificata sulla GMT (Greenwich Mean Time) corrente per determinare l'ora di scadenza. L'ora di scadenza è inserita nell'intestazione Expires: nel formato HTTP.
Esempi
cgiutils -expires "1 anno 3 mesi 2 settimane 4 giorni 12 ore 30 minuti"
cgiutils -status 200 -reason "Virtual doc follows" -expires now
Potrebbero essere prodotte intestazioni simili alle seguenti:
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
Il comando cgiutils produce automaticamente l'intestazione Server: perché disponibile nell'ambiente CGI. Inoltre, il campo Data: viene generato automaticamente a meno che non sia specificato l'indicatore -nodate.
Ciò include una riga vuota dopo l'output per indicare la fine della sezione dell'intestazione MIME. Se si desidera seguire questa intestazione insieme ad altre, utilizzare l'indicatore -noel (NO-Empty-Line) come illustrato nel seguente esempio.
cgiutils -noel -expires "2 days" -nodate
HTTP/1.0 200 Virtual doc follows MIME-Version: 1.0 Server: IBM-ICS Scadenza: Mar, 07 gennaio 1996 03:43:46 GMT
Scopo
Utilizzare il comando htadm per controllare i file di password del server. Il server utilizza i file di password per controllare l'accesso ai file. È possibile aggiungere un nome utente ad un file di password, eliminare un utente da un file di password, verificare una password utente e creare un file di password vuoto. È inoltre possibile modificare la password di un utente eliminando prima la password dell'utente e creandone, poi, una nuova.
Formato
htadm -Flag [Modifier]
Parametri
Per il nome utente utilizzare solo caratteri alfanumerici; non usare caratteri speciali.
Il comando non funziona se nel file di password esiste già un utente con lo stesso nome.
Le password possono avere fino a 32 caratteri. Per la password utilizzare solo caratteri alfanumerici; non usare caratteri speciali.
Note:
Le password possono avere fino a 32 caratteri. Per la password utilizzare solo caratteri alfanumerici; non usare caratteri speciali.
Note:
Esempi
htadm -adduser /opt/ibm/edge/cp/server_root/protect/heroes.pwd clark superman "Clark Kent"
htadm -adduser "C:\Program Files\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:\Program Files\IBM\edge\cp\server_root\protect\ heroes.pwd" clark superman "Clark Kent"
Scopo
Utilizzare il comando htcformat per preparare un file o un'unità non formattata per contenere la cache proxy. Questo comando di formato deve essere utilizzato prima che l'unità venga indicata per l'uso con la cache proxy.
Il percorso unità deve specificare l'unità non formattata. Consultare la documentazione del file system per informazioni su come accedere alle unità non formattate. Degli esempi sono disponibili in Configurazione della memorizzazione nella cache del server proxy.
La dimensione minima per una cache di Caching Proxy è 16392 KB, che è 2049 blocchi.
Formato
htcformat unità [-blocksize <dimensione blocco>] [-blocks numero di blocchi] htcformat -file percorso file [-blocksize dimensione blocco] -blocks numero di blocchi
Parametri
Utilizzo
Il sistema di memorizzazione nella cache isola i file o i dispositivi cache in contenitori per l'indicizzazione e la raccolta dati inutili. La dimensione dei contenitori è impostata su un certo numero di blocchi; tale dimensione non può essere configurata. Affinché venga eseguita la raccolta dati inutili, sono necessari almeno due contenitori; la dimensione minima di cache è 16392 KB.
Il comando htcformat rifiuta una richiesta di formato che fornisce un dispositivo cache con meno di due contenitori.
Esempi
Nel seguente esempio viene formattata una partizione disco chiamata c0t0d0s0 su Solaris.
htcformat /dev/rdsk/c0t0d0s0
Nel seguente esempio viene formattata una partizione disco chiamata lv02 su AIX.
htcformat /dev/rlv02
Nel seguente esempio viene formattata una partizione disco chiamata d: su Windows.
htcformat \\.\d:
Nel seguente esempio viene formattato un file denominato filecache con una dimensione di circa 1 GB.
htcformat -file /opt/ibm/edge/cp/filecache -blocks 131072
Scopo
Utilizzare il comando ibmproxy per avviare il server.
È possibile impostare tutti questi indicatori (tranne -r) mediante le direttive nel file di configurazione del server.
Normalmente si crea un file denominato README contenente le istruzioni o le notifiche utili per chi utilizza questa directory per la prima volta. Per impostazione predefinita, il comando ibmproxy include qualsiasi file README nella versione ipertestuale di una directory. Le istruzioni del file README possono essere impostate anche con la direttiva di configurazione DirReadme.
Formato
ibmproxy [-Flag [-Flag [-Flag..]]]
Parametri
Poiché il daemon http deve leggere il file di configurazione che il server sta utilizzando per accedere a PidFile, è necessario specificare lo stesso file di configurazione al riavvio. Se è stato utilizzato l'indicatore -r e un file di configurazione specifico quando al riavvio del server, è necessario specificare questo indicatore e lo stesso file con -restart.
Le opzioni di gestione del segnale sono presenti anche sulle piattaforme Linux e UNIX. Sulle piattaforme Linux e UNIX, sono disponibili le seguenti opzioni.
Esempi
ibmproxy -p 8080 -r /usr/etc/ibmproxy.conf
startsrc -s ibmproxy
Se il file di configurazione predefinito non esiste, il comando ibmproxy esporta la struttura ad albero della directory /Public. Questa struttura ad albero può contenere dei collegamenti non permanenti ad altre strutture ad albero della directory.
In questa sezione sono descritte le direttive contenute nel file di configurazione ibmproxy.conf.
Utilizzare queste informazioni come riferimento se si intende configurare il server modificando il file ibmproxy.conf. Se si utilizzano i moduli di configurazione e amministrazione, non è necessario fare riferimento a questo capitolo.
Le direttive sono elencate in ordine alfabetico.
Alcune direttive non vengono aggiornate quando il server viene riavviato. Se le
direttive riportate di seguito vengono modificate mentre il server è in esecuzione, è
necessario arrestare e riavviare il server manualmente. Fare riferimento a Avvio e arresto di Caching Proxy.
Tabella 6. Direttive non aggiornate in seguito a un riavvio
Gruppo direttive | Direttive |
CGI | DisinheritEnv, InheritEnv |
Caching | Caching |
Registrazione | AccessLog, CacheAccessLog, ErrorLog, ProxyAccessLog, ServerRoot |
Accesso alla rete | BindSpecific, Hostname, ListenBacklog, Port |
Prestazioni | MaxActiveThreads |
RTSP | Tutte le direttive RTSP |
SSL | Tutte le direttive SSL |
Controllo processi Linux e UNIX | GroupId, UserId |
Varie | TransparentProxy |
Questa appendice contiene le seguenti informazioni per ciascuna direttiva:
nome_direttiva valore
I valori originali codificati nel file di configurazione predefinito. Modificare solo le parti del file di configurazione che si desidera differenziare dai valori predefiniti. Una direttiva che non presenta valori predefiniti inizialmente codificati compare nel file come preceduta da un indicatore di commento (#). Se si intende specificare un valore per la direttiva, eliminare l'indicatore di commento e aggiungere il valore alla riga nel file di configurazione.
L'elenco riportato di seguito contiene i valori validi nel file di configurazione:
Tutte le voci vengono convertite in secondi, quindi unite.
Durante la modifica del file di configurazione, tenere presente quanto segue:
Di seguito sono riportate le direttive di Caching Proxy.
Utilizzare questa direttiva per supportare i file per il client anche se il tipo MIME del file non corrisponde a un'intestazione ACCEPT: inviata dal client. Se questa direttiva è impostata su OFF, i file i cui tipi MIME differiscono dai tipi accettabili dal client non possono essere visualizzati. Perciò, viene visualizzata una pagina di errore.
AcceptAnything {on | off}
AcceptAnything off
AcceptAnything on
Utilizzare questa direttiva per specificare la directory e il file in cui si intende registrate le statistiche di accesso al log. Per impostazione predefinita, il server scrive una voce in questo log ogni volta che un client invia al server una richiesta relativa ai dati memorizzati sul server locale. Normalmente, queste voci contengono solo le richieste provenienti dal client di configurazione o gli accessi, quando la macchina di Caching Proxy viene utilizzata come server di origine. Questo log non contiene informazioni sull'accesso proxy o cache.
Utilizzare la direttiva NoLog per specificare i client le cui richieste non devono essere registrate. Per una descrizione della direttiva NoLog, fare riferimento a NoLog -- Elimina le voci di log per host o domini specifici che corrispondono a un modello.
Il server avvia un nuovo file di log ogni giorno a mezzanotte, se in esecuzione. In caso contrario, questo si verifica appena il server viene avviato. Quando il file viene creato, il server utilizza il nome del file specificato, a cui appone un suffisso data. Questo è nel formato Mmmddyyyy , dove Mmm si riferisce alle prime tre lettere del mese, dd al giorno e yyyy all'anno.
È opportuno eliminare i file di log meno recenti in quanto occupano una significativa quantità di spazio sul disco rigido.
AccessLog /percorso_directory/nome_file_log
AccessLog /logs/accesslog
Utilizzare questa direttiva per non registrare le richieste effettuate da uno specifico metodo per accedere a file o directory. Ad esempio, non si desidera registrare le richieste DELETE per file o directory.
È possibile disporre di più occorrenze di questa direttiva nel file di configurazione. Inoltre, è possibile inserire più metodi sulla stessa direttiva, purché vengano separati da uno o più spazi.
AccessLogExcludeMethod metodo [ ...]
AccessLogExcludeMethod GET AccessLogExcludeMethod PUT AccessLogExcludeMethod POST AccessLogExcludeMethod DELETE AccessLogExcludeMethod GET PUT
Nessuna. Nel log accessi, il server include i file e le directory richiesti da tutti i tipi di metodi.
Utilizzare questa direttiva per specificare che non si intende registrare nel log accessi proxy le richieste di accesso a directory o file di un tipo MIME specificato. (Esempi di tipi MIME sono text/html, image/gif e image/jpeg.) Ad esempio, non si intende registrare richieste di accesso a immagini GIF.
È possibile disporre di più occorrenze di questa direttiva nel file di configurazione. Inoltre, è possibile inserire più tipi MIME sulla stessa direttiva, purché vengano separati da uno o più spazi.
AccessLogExcludeMimeType tipo_MIME [...]
AccessLogExcludeMimeType image/gif AccessLogExcludeMimeType text/html AccessLogExcludeMimeType image/gif text/html
Nessuna. Il log accessi include richieste inviate al server relative a file e directory di tutti i tipi MIME.
Utilizzare questa direttiva per specificare che non si intende registrare le richieste di accesso che rientrano all'interno di uno specifico intervallo di numeri di codici di errore. Questi numeri di codici di errore sono codici di stato del server proxy. Non è possibile specificare singoli codici. Ad esempio, il valore 300, indica che si intende escludere le richieste di accesso con codici di ritorno di reindirizzamento (301, 302, 303 e 304).
È possibile disporre di più occorrenze di questa direttiva nel file di configurazione. Inoltre, è possibile inserire più codici di ritorno sulla stessa direttiva purché vengano separati da uno o più spazi.
AccessLogExcludeReturnCode intervallo
AccessLogExcludeReturnCode 300
Nessuna. Il log accessi include tutte le richieste inviate al server, indipendentemente dal codice.
Utilizzare questa direttiva se non si intende registrare le richieste di accesso a specifici file o directory che corrispondono a una maschera URL specificata. Ad esempio, non si intende registrare le richieste di accesso ai file GIF o a uno specifico file o directory sul server.
È possibile disporre di più occorrenze di questa direttiva nel file di configurazione. Inoltre, è possibile inserire più voci sulla stessa direttiva, purché vengano separate da uno o più spazi.
AccessLogExcludeURL file_o_tipo [...]
AccessLogExcludeURL *.gif AccessLogExcludeURL /Freebies/* AccessLogExcludeURL *.gif /Freebies/*
Nessuna. Il server registra le richieste di accesso a tutti i file e directory.
Utilizzare questa direttiva per specificare che non si intende registrare le richieste di accesso eseguite da specifici agenti utente (ad esempio, Internet Explorer 5.0).
È possibile disporre di più occorrenze di questa direttiva nel file di configurazione. Inoltre, è possibile inserire più voci sulla stessa direttiva, purché vengano separate da uno o più spazi.
AccessLogExcludeUserAgent agente_utente [...]
AccessLogExcludeUserAgent *Mozilla/2.0 AccessLogExcludeUserAgent *MSIE 5*
Per impostazione predefinita, il file ibmproxy.conf contiene le seguenti definizioni per la direttiva AccessLogExcludeUserAgent:
AccessLogExcludeUserAgent IBM_Network_Dispatcher_HTTP_Advisor AccessLogExcludeUserAgent IBM_Network_Dispatcher_WTE_Advisor
Gli agenti utente sopra elencati sono quelli definiti per determinati advisor Load Balancer che normalmente si trovano davanti al server Caching Proxy. Per migliorare le prestazioni e ridurre il numero di operazioni di scrittura nel log, questi agenti utente non vengono registrati. Per impostazione predefinita, il server registra le richieste di accesso eseguite da tutti gli altri agenti utente.
Utilizzare questa direttiva per specificare un'icona da utilizzare per allineare le intestazioni sugli elenchi directory restituiti quando il server funge da proxy per le richieste FTP. Le icone vengono visualizzate accanto ai file associati per aiutare gli utenti a distinguerli.
L'icona può essere vuota o meno, in base a quanto specificato sulle intestazioni degli elenchi directory. Per il corretto allineamento, l'icona deve utilizzare la stessa dimensione delle altre icone utilizzate sull'elenco directory.
AddBlankIcon URL icona testo_alternativo
Specifica l'ultima parte dell'URL dell'icona. Il server aggiunge questo valore alla directory /icons/ per creare la richiesta URL completa. Se la richiesta è destinata a un file locale, il server la converte mediante le direttive di associazione. Per poter richiamare l'icona, le direttive di associazione devono consentire il trasferimento della richiesta.
Se il server viene utilizzato come proxy, la richiesta deve essere un URL completo che punta al server.
AddBlankIcon logo.gif logo
Il valore predefinito non specifica testo alternativo poiché l'icona è vuota.
Utilizzare questa direttiva per specificare un'icona che rappresenta una directory su un elenco directory.
AddDirIcon URL_icona testo_alternativo
Specifica l'ultima parte dell'URL dell'icona. Il server aggiunge questo valore alla directory /icons/ per creare la richiesta URL completa. Se la richiesta è destinata a un file locale, il server la converte mediante le direttive di associazione. Per poter richiamare l'icona, le direttive di associazione devono consentire il trasferimento della richiesta.
Se il server viene utilizzato come proxy, la richiesta deve essere un URL completo che punta al server. È necessario mappare l'URL su un file locale e verificare che le direttive di associazione consentano di trasferire l'URL.
AddDirIcon direct.gif DIR
Utilizzare questa direttiva per collegare i file con uno specifico suffisso a un tipo di codifica MIME. Questa direttiva viene utilizzata di rado.
AddEncoding .estensione codifica
AddEncoding .qp quoted_printable
AddEncoding .Z x-compress
Utilizzare questa direttiva per specificare le icone per rappresentare i file con uno specifico tipo di codifica o di contenuto MIME. Il server utilizza le icone sugli elenchi directory, compresi elenchi directory FTP.
AddIcon URL_icona testo_alternativo modello_tipo_MIME
Specifica l'ultima parte dell'URL dell'icona. Il server aggiunge questo valore alla directory /icons/ per creare la richiesta URL completa. Se la richiesta è destinata a un file locale, il server la converte mediante le direttive di associazione. Per poter richiamare l'icona, le direttive di associazione devono consentire il trasferimento della richiesta.
Se il server viene utilizzato come proxy, la richiesta deve essere un URL completo che punta al server. È necessario mappare l'URL su un file locale e verificare che le direttive di associazione consentano di trasferire l'URL.
AddIcon video_file.m.pm.gif MOV video/*
Nel file di configurazione ibmproxy.conf sono impostati molti valori predefiniti per la direttiva AddIcon.
Utilizzare la direttiva AddLang per l'elaborazione di file con più formati lingua. La direttiva consente agli utenti di associare l'estensione file alle lingue quando le richieste sono gestite in locale.
Il server proxy supporta già le direttive AddType e AddEncoding per l'elaborazione di file in più formati. Il server proxy non può gestire un utilizzo in più formati basato sull'intestazione Accept-Langauge nelle richieste. Tuttavia, la direttiva AddLang, che precedentemente era nascosta, fornisce un meccanismo per collegare una lingua a una estensione file.
AddLang .file-extension lingua quality
dove lingua è utilizzato in modo da corrispondere ai valori nell'intestazione Accept-Language e quality è un numero a virgola mobile utilizzato per calcolare la classificazione per i file associati.
Ad esempio, si assuma che le seguenti impostazioni AddLang siano configurate:
AddLang .en en 1.001 AddLang .de de 1.0 AddLang .en en-us 0.9
Quindi assumere che i file sample.html.en e sample.html.de esistano già sul disco locale. La seguente richiesta è ricevuta da Caching Proxy:
GET /sample.html HTTP/1.0 Accept-Language: de,en;q=0.5 .....
Quando la richiesta arriva, il server proxy calcola una classificazione per ogni file locale associato basato sui valori nell'intestazione Accept-Langauge e le definizioni nelle direttive AddLang. Il file con la classificazione più alta viene utilizzato per gestire la richiesta.
Nell'esempio precedente, al file sample.html.en viene assegnata la seguente classificazione:
0.5 x 1.001 = 5.005
Al file sample.html.de viene assegnata invece la seguente classificazione:
0.5 x 1.0 =0.5
Se non viene specificato un valore per q nell'intestazione Accept-Language, il valore predefinito sarà 1.0.
Utilizzare questa direttiva per specificare un'icona che rappresenti una directory parent su elenchi directory.
AddParentIcon URL icona testo_alternativo
Specifica l'ultima parte dell'URL dell'icona. Il server aggiunge questo valore alla directory /icons/ per creare la richiesta URL completa. Se la richiesta è destinata a un file locale, il server la converte mediante le direttive di associazione. Per poter richiamare l'icona, le direttive di associazione devono consentire il trasferimento della richiesta.
Se il server viene utilizzato come proxy, la richiesta deve essere un URL completo che punta al server. È necessario mappare l'URL su un file locale e verificare che le direttive di associazione consentano di trasferire l'URL.
AddParentIcon parent.gif UP
AddParentIcon dir-up.gif UP
Utilizzare questa direttiva per associare i file con uno specifico suffisso a un tipo e sottotipo MIME. È possibile disporre di più occorrenze di questa direttiva nel file di configurazione. Il server fornisce i valori predefiniti per i suffissi più utilizzati.
AddType .estensione tipo/tipo secondario codifica [qualità[ set_caratteri]]
Ogni altro valore di codifica viene considerato come binario e trasferito alle intestazioni MIME come intestazione MIME content-encoding. La specifica a 7bit e a 8bit non viene inviata alle intestazioni MIME.
AddType .ps application/postscript 8bit 1.0 AddType *.* application/binary binary 0.3
AddType .bin application/octet-stream binary 0.8
Molte impostazioni predefinite per la direttiva AddType sono contenute nel file di configurazione (ibmproxy.conf).
Utilizzare questa direttiva per specificare un'icona che rappresenti un tipo file sconosciuto su un elenco directory.
AddUnknownIcon URL icona testo_alternativo
Specifica l'ultima parte dell'URL dell'icona. Il server aggiunge questo valore a /icons/ per creare la richiesta URL completa. Se la richiesta è destinata a un file locale, il server la converte mediante le direttive di associazione. Per poter richiamare l'icona, le direttive di associazione devono consentire il trasferimento della richiesta.
Se il server viene utilizzato come proxy, la richiesta deve essere un URL completo che punta al server. È necessario mappare l'URL su un file locale e verificare che le direttive di associazione consentano di trasferire l'URL.
AddUnknownIcon saywhat.gif unknown
Utilizzare questa direttiva per specificare una porta che può essere utilizzata dagli amministratori per accedere ai moduli di configurazione o alle pagine relative allo stato del server. Le richieste inviate a questa porta non vengono accodate insieme a tutte le altre richieste in entrata sulla porta (o porte) standard definita con la direttiva Port. Tuttavia, le richieste su AdminPort sono sottoposte alle stesse normali regole di controllo degli accessi e di associazione delle richieste, ad esempio, Pass, Exec, Protect.
AdminPort numero_porta
AdminPort 2001
AdminPort 8008
Utilizzare questa direttiva per specificare se i file restituiti dal server di origine e contrassegnati come non memorizzabili nella cache devono essere memorizzati comunque. I file non memorizzabili nella cache, memorizzati in base a queste direttive, sono contrassegnati come must revalidate. Ogni volta che il file viene richiesto, il server proxy invia una richiesta If-Modified-Since al server di origine per riconvalidare la risposta prima che questa possa essere supportata dalla cache. Attualmente, gli unici file non memorizzabili nella cache interessati da questa direttiva sono le risposte provenienti dal server di origine contenenti un'intestazione cache-control: no-cache. Questa direttiva può essere specificata più volte.
AggressiveCaching modello_URL
AggressiveCaching http://www.hosta.com/* AggressiveCaching http://www.hostb.com/*
Per la compatibilità con le versioni precedenti, la sintassi di questa direttiva ( AggressiveCaching {on | off}) viene ora trattata come segue:
AggressiveCaching on viene trattata come AggressiveCaching * .
AggressiveCaching off viene ignorata.
Nessuno
Utilizzare questa direttiva per specificare gli URL per cui Caching Proxy aggiunge i caratteri di ritorno a capo e di avanzamento riga alla fine del corpo di una richiesta POST. Questa direttiva può essere specificata più volte.
appendCRLFtoPost modello_URL
appendCRLFtoPost http://www.hosta.com/
Nessuno
Utilizzare questa direttiva per specificare la matrice di cache remota che deve essere condivisa dai server.
ArrayName nome_array
Nessuno
Utilizzare questa direttiva per specificare una funzione applicativa personalizzata che il server deve richiamare durante la fase Autenticazione del processo di richiesta server. Questo codice viene eseguito in base allo schema di autenticazione. È supportata esclusivamente l'autenticazione BASIC.
Authentication tipo /percorso/file:nome_funzione
Authentication BASIC /ics/api/bin/icsextpgm.so:basic_authentication
Nessuno
Utilizzare questa direttiva per specificare una funzione applicativa personalizzata richiamata dal server durante la fase Autorizzazione del processo di richiesta server. Questo codice verifica se l'oggetto richiesto può essere supportato per il client.
Authorization modello_richiesta /percorso/file:nome_funzione
Authorization /index.html /api/bin/icsextpgm.so:auth_url
Nessuno
Utilizzare questa direttiva per attivare o disattivare l'aggiornamento cache. Se attivato, il contenuto della cache viene aggiornato automaticamente. In caso contrario, l'agente cache non viene richiamato, quindi tutte le relative impostazioni vengono ignorate. Se l'agente cache viene avviato da un altro metodo, ad esempio, utilizzando un lavoro cron su sistemi Linux e UNIX, impostare questa direttiva su off.
AutoCacheRefresh {on | off}
AutoCacheRefresh On
Utilizzare questa direttiva su un sistema multihome per specificare se il server è in ascolto su un solo indirizzo di rete. Se il valore viene impostato su On, il server viene associato all'indirizzo IP specificato nella direttiva Hostname, anziché a tutti gli indirizzi IP locali.
Se la direttiva non è specificata, il server viene associato al nome host predefinito.
Se la direttiva viene modificata, è necessario arrestare manualmente il server, quindi riavviarlo. La modifica non ha effetto se il server viene semplicemente riavviato. Fare riferimento a Avvio e arresto di Caching Proxy.
BindSpecific {on | off} [OutgoingSrcIp indir_ip | nome_host]
BindSpecific Off
Questa direttiva specifica la dimensione (in byte) dei blocchi nel supporto dell'unità di memorizzazione. Per impostazione predefinita, il valore è 8192. Dal momento che si tratta dell'unica dimensione supportata, non modificare questo valore. Per ulteriori informazioni, fare riferimento alla sezione Comando htcformat.
BlockSize dimensione
Per impostazione predefinita, non sono presenti impostazioni per BlockSize nel file di configurazione. (Il valore predefinito è 8192.)
Utilizzare questa direttiva per specificare il percorso e il nome del file in cui il server deve memorizzare un log accessi alla cache proxy. Questa direttiva è valida solo se il server è in esecuzione come proxy. Fare riferimento a CacheRefreshTime -- Specifica quando avviare l'agent della cache per ulteriori informazioni.
Per attivare la registrazione delle richieste nella cache proxy, la direttiva Caching deve essere impostata su ON ed è necessario stabilire dei valori per le direttive CacheMemory e CacheAccessLog. Facoltativamente, è possibile definire uno o più dispositivi cache utilizzando la direttiva CacheDev.
Il valore di CacheAccessLog può essere un percorso assoluto o relativo a ServerRoot. (Per ciascuno, è illustrato un esempio.)
CacheAccessLog percorso/file
CacheAccessLog /absolute/path/logfile CacheAccessLog /logs/logfile
Utilizzare questa direttiva per specificare l'algoritmo cache utilizzato dal server durante la raccolta di dati inutili.
CacheAlgorithm {bandwidth | responsetime | blend}
CacheAlgorithm bandwidth
Utilizzare questa direttiva per specificare se i nomi file di cache creati si basano sull'URL in entrata della richiesta.
Se questa direttiva è impostata su on, i nomi file di cache vengono creati in base all'URL in entrata. Se questa direttiva è impostata su off, l'URL in entrata passerà innanzitutto attraverso tutti i plugin di conversione nome adatti, regole MAP e regole PROXY, quindi il nome file di cache generato sarà basato sull'URL risultante.
CacheByIncomingUrl {on | off}
CacheByIncomingURL off
Utilizzare questa direttiva per specificare per quanto tempo il server deve conservare i file memorizzati nella cache. Durante l'esecuzione della raccolta di dati inutili, il server elimina i file memorizzati nella cache che hanno oltrepassato questo valore, indipendentemente dalla data di scadenza. Ogni volta che viene richiesto un file conservato nella cache per un periodo superiore a quello specificato, il server deve riconvalidarlo per verificare che sia valido, prima di poterlo utilizzare.
CacheClean specifica_durata
CacheClean 2 weeks
CacheClean 1 month
Utilizzare questa direttiva per impostare una scadenza predefinita per i file per cui il server non ha fornito un'intestazione Expires o Last-Modified. Specificare una maschera URL e la scadenza dei file che presentano URL corrispondenti alla maschera. È possibile includere più occorrenze di questa direttiva nel file di configurazione. Includere una direttiva separata per ciascuna maschera. La maschera URL deve contenere il protocollo. Per specificare la scadenza, può essere utilizzata qualsiasi combinazione di mesi, settimane, giorni e ore.
CacheDefaultExpiry modello_URL ora_scadenza
CacheDefaultExpiry ftp:* 1 day CacheDefaultExpiry gopher:* 2 days CacheDefaultExpiry http:* 0 days
Utilizzare questa direttiva per specificare un dispositivo di memorizzazione cache. È possibile specificare un file o una partizione su disco non formattata. Su piattaforme AIX, è possibile specificare un volume logico non formattato. (Se non si utilizza una cache in memoria, la memorizzazione nella cache su disco non formattato assicura le migliori prestazioni.)
Notare che è necessario predisporre i dispositivi cache prima di specificarli. Per predisporre un dispositivo cache, formattarlo per mezzo del comando htcformat. Per ulteriori informazioni, fare riferimento a Comando htcformat.
È possibile specificare più dispositivi cache. Ciascun dispositivo viene associato agli stessi valori CacheMemory e BlockSize. Tuttavia, ciascuno di essi va incontro a un sovraccarico di memoria di circa 8 MB nella macchina server proxy. Un numero minore di dispositivi di grandi dimensioni è sicuramente più efficiente di un numero maggiore di dispositivi di dimensioni più piccole. Per ottenere il massimo dell'efficienza, utilizzare un disco intero come unica grande partizione e nient'altro. Per ulteriori informazioni sulla memorizza cache, consultare Ottimizzazione delle prestazioni della cache su disco.
CacheDev {partizione_disco_nonformattata | file}
AIX: CacheDev /dev/rlv02
HP-UX: CacheDev /dev/rdsk/c1t15d0
Linux: CacheDev /opt/IBMWTE/filecache1
Solaris: CacheDev /dev/rdsk/clt3d0s0
Windows: CacheDev \\.\E:
Nessuno
Utilizzare questa direttiva per specificare se il server restituisce file memorizzati nella cache scaduti. Impostare questo valore su Off per fare in modo che il server possa restituire file scaduti. Utilizzare il valore predefinito On se un client richiede un file scaduto e si desidera che il proxy controlli che nel server di origine sia disponibile una versione più aggiornata del file stesso. Generalmente, gli amministratori non desiderano che il server restituisca file scaduti se non durante una dimostrazione, in cui il contenuto non è importante.
CacheExpiryCheck {on | off}
CacheExpiryCheck On
Utilizzare questa direttiva per specificare la dimensione massima dei file da memorizzare nella cache. I file la cui dimensione supera questo valore non verranno memorizzati. Il valore può essere specificato in byte (B), kilobyte (K), megabyte (M) o gigabyte (G). La specifica può contenere o meno spazi tra il numero e l'unità di misura (B, K, M, G).
CacheFileSizeLimit dimensione massima {B | K | M | G}
CacheFileSizeLimit 4000 K
Utilizzare questa direttiva per specificare il valore da adoperare per calcolare le date di scadenza di determinati URL o di tutti gli URL corrispondenti a una maschera.
Di frequente, i server HTTP forniscono la data/ora dell'ultima modifica ma non la data di scadenza. Allo stesso modo, i file FTP possono indicare la data/ora dell'ultima modifica ma non la data di scadenza. Caching Proxy calcola una data di scadenza per questi file in base alla data/ora dell'ultima modifica. Quest'ultima viene utilizzata per determinare il tempo trascorso dall'ultima modifica al file, che viene poi moltiplicato per il valore su una direttiva CacheLastModifiedFactor. Il risultato di questo calcolo indica la durata del file o l'intervallo di tempo prima che il file diventi obsoleto.
È anche possibile specificare off o -1 per disattivare la direttiva e non calcolare la data di scadenza. Il server proxy legge le direttive CacheLastModifiedFactor nell'ordine in cui compaiono nel file di configurazione e utilizza la prima direttiva applicabile al file memorizzato nella cache.
CacheLastModifiedFactor url fattore
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
Con il valore predefinito 0.14, i file modificati una settimana fa scadranno in un giorno.
Utilizzare questa direttiva per specificare se memorizzare nella cache gli URL degli host nello stesso dominio del proxy. Normalmente, i siti locali su una rete intranet non devono essere memorizzati nella cache, in quanto la larghezza di banda interna è sufficiente a caricare gli URL velocemente. Se i siti locali non vengono memorizzati nella cache sarà possibile risparmiare lo spazio per quegli URL che impiegano più tempo per essere richiamati.
CacheLocalDomain {on | off}
CacheLocalDomain on
Se il server di backend può restituire ai clienti le varianti lingua dello stesso URL, utilizzare questa direttiva per supportare la memorizzazione nella cache delle varie lingue del medesimo URL. La direttiva consente a Caching Proxy di verificare la preferenza lingua nelle richieste con la lingua della risposta memorizzata nella cache.
Quando si attiva CacheMatchLanguage, prima che Caching Proxy carichi il contenuto memorizzato nella cache, viene visualizzata la preferenza lingua nell'intestazione Accept-Language della richiesta, in cui compare la lingua del contenuto memorizzato nella cache. Caching Proxy confronta inoltre la distanza tra le preferenze. Se questa è inferiore al limite specificato, restituisce la copia memorizzata nella cache; in caso contrario, il proxy inoltra la richiesta al server di backend per ottenere una copia aggiornata nella lingua richiesta.
CacheMatchLanguage {on | off} lang-prefer-distance-limit special-id-for-all-lang
Di seguito è riportato un esempio di configurazione della direttiva, dell'oggetto cache e della richiesta.
CacheMatchLanguage On 0.2
Se l'oggetto cache è in cinese semplificato (zh_cn) e la richiesta è:
GET / HTTP/1.1 ... Accept-Language: en_US;q=1.0, zh_cn;q=0.7, ja;q=0.3 ....
Per questa richiesta, il cliente chiede una pagina in inglese (con codice e qualità en_US/1.0), quindi in cinese semplificato (con codice e qualità zh_cn/0.7), infine in giapponese (con codice e qualità ja/0.3). L'oggetto memorizzato nella cache è in cinese semplificato. La distanza tra le preferenze tra la migliore qualità prevista e la qualità della lingua corrispondente è 1.0 - 0.7 = 0.3. Poiché il limite è impostato su 0.2 dalla direttiva CacheMatchLanguage e 0.3 è superiore al limite, il proxy chiede al server una nuova copia di quell'URL invece di restituire l'oggetto memorizzato nella cache.
Quando il server restituisce una risposta, se non specifica una lingua o un id-speciale-per-tutte-le-lingue nell'intestazione Content-Language, nel momento in cui arriva un'altra richiesta, il proxy non esegue il confronto con la preferenza lingua e restituisce la copia memorizzata nella cache.
CacheMatchLanguage off
Utilizzare questa direttiva per definire l'intervallo di tempo massimo in cui i file possono rimanere nella cache. La durata di un file memorizzato nella cache definisce l'intervallo di tempo entro il quale il file può essere supportato dalla cache senza che l'origine venga controllata per verificare la presenza di eventuali aggiornamenti. In alcuni casi, la durata calcolata per un file memorizzato nella cache può essere superiore rispetto a quella desiderata per la conservazione del file. La durata del file, specificata dall'origine o calcolata da Caching Proxy, non può superare il limite specificato dalla direttiva CacheMaxExpiry.
Sono consentite più occorrenze di questa direttiva nel file di configurazione. Includere una direttiva separata per ciascuna maschera.
CacheMaxExpiry URL durata
CacheMaxExpiry ftp:* 1 month CacheMaxExpiry http://www.santaclaus.np/* 2 days 12 hours
CacheMaxExpiry 1 month
Utilizzare questa direttiva per specificare la quantità di memoria da associare alla cache. Per ottenere prestazioni ottimali delle cache su disco, è consigliabile un valore di memoria cache minimo di 64 MB per il supporto dell'infrastruttura cache, incluso l'indice di cache. Con l'aumento della dimensione di cache, aumenta anche l'indice di cache e, di conseguenza, è necessaria più memoria per memorizzare l'indice. Un valore di memoria cache di 64 MB è sufficiente per supportare l'infrastruttura cache e memorizzare un indice di cache di una cache su disco con una dimensione di circa 6,4 GB. Per cache su disco di dimensioni superiori, la memoria cache deve essere l'1% della dimensione cache.
Se si utilizza la cache in memoria, impostare questa direttiva per includere sia la cache che la quantità di memoria necessaria per l'indice cache.
Il valore massimo consigliato per questa direttiva è 1600 MB. Questo limite è determinato dal fatto che Caching Proxy, come applicazione a 32 bit, può utilizzare al massimo 2 GB di memoria. Se la quantità di memoria necessaria per la cache sommata a quella utilizzata per l'elaborazione di routine si avvicina o supera i 2 GB, Caching Proxy non funzionerà correttamente.
La quantità può essere specificata in una delle seguenti unità: byte (B), kilobyte (K), megabyte (M) e gigabyte (G).
CacheMemory quantità {B | K | M | G}
CacheMemory 64 M
Utilizzare questa direttiva per specificare gli URL dei file la cui scadenza deve essere ignorata. Alcuni siti impostano la scadenza dei file prima del termine della loro validità e, così facendo, il server deve richiedere il file più di frequente. La direttiva CacheMinHold consente di conservare nella cache il file scaduto per l'intervallo di tempo specificato prima che venga nuovamente richiesto. Questa direttiva può essere specificata più volte.
CacheMinHold http://www.cachebusters.com/* 1 hour
Nessuno
Utilizzare questa direttiva per specificare se il server proxy richiama i file da server remoti. Il valore predefinito (Off) consente al server di richiamare i file da server remoti. Il valore On fa sì che il server venga eseguito in modalità cache autonoma. In questo modo, il server può restituire esclusivamente i file già memorizzati nella cache. Normalmente, quando il server viene eseguito in questa modalità, è anche possibile impostare la direttiva CacheExpiryCheck su Off.
L'esecuzione del server in modalità cache autonoma può essere utile quando si utilizza il server a scopo dimostrativo. Se tutti i file da utilizzare per la dimostrazione sono memorizzati nella cache, non è necessaria una connessione di rete.
CacheNoConnect {on | off}
CacheNoConnect Off
Utilizzare questa direttiva per specificare di memorizzare nella cache solo i file con URL corrispondenti a una maschera specificata. È possibile utilizzare più occorrenze di questa direttiva nel file di configurazione. Includere una direttiva separata per ciascuna maschera. La maschera URL deve contenere il protocollo. Se per questa direttiva non è impostato alcun valore, è possibile memorizzare nella cache qualsiasi URL che non corrisponde a una direttiva NoCaching. Se le direttive CacheOnly e NoCaching non sono incluse nel file di configurazione, è possibile memorizzare nella cache qualsiasi URL.
CacheOnly modello_url
CacheOnly http://realstuff/*
Nessuno
Utilizzare questa direttiva per specificare gli URL per cui le risposte alle richieste di query sono state memorizzate nella cache. Se viene utilizzato il valore PUBLIC modello_url, le risposte a richieste GET che contengono un carattere punto interrogativo nell'URL vengono memorizzate nella cache se il server di origine contiene l'intestazione cache-control: public e la risposta è comunque memorizzabile nella cache. Se viene specificato il valore ALWAYS modello_url, le risposte a richieste GET che contengono un carattere punto interrogativo nell'URL vengono memorizzate nella cache se le risposte sono comunque memorizzabili.
Questa direttiva può essere specificata più volte.
CacheQueries {ALWAYS | PUBLIC} modello_url
CacheQueries ALWAYS http://www.hosta.com/* CacheQueries PUBLIC http://www.hostb.com/*
Nessuno
Utilizzare questa direttiva per specificare quando verificare il server di origine per determinare se i file memorizzati nella cache sono stati modificati.
Sebbene la direttiva CacheClean sembra simile a questa, c'è una differenza. CacheRefreshInterval specifica solo che il proxy riconvalida un file prima di utilizzarlo mentre la direttiva CacheClean consente di eliminare il file dalla cache dopo un determinato periodo di tempo.
CacheRefreshInterval modello_URL periodo_tempo
CacheRefreshInterval periodo_tempo
CacheRefreshInterval *.gif 8 hours CacheRefreshInterval 1 week
CacheRefreshInterval 2 weeks
Utilizzare questa direttiva per specificare quando avviare l'agente cache. È possibile avviare l'agente cache in uno specifico momento.
CacheRefreshTime HH:MM
CacheRefreshTime 03:00
La direttiva CacheTimeMargin specifica la durata minima di un file necessaria per memorizzarlo nella cache.
Caching Proxy calcola una data di scadenza per ciascun file. Se si ritiene improbabile di ricevere un'altra richiesta per il file prima che questo raggiunga la data di scadenza, Caching Proxy considera la durata del file insufficiente per poterlo memorizzare. Per impostazione predefinita, Caching Proxy non memorizza nella cache i file la cui durata è inferiore ai 10 minuti. Se la cache non è prossima alla propria capacità massima, lasciare questa direttiva al valore iniziale. Se la cache ha quasi raggiunto la capacità totale, aumentare il valore della durata minima.
CacheTimeMargin durata_minima
CacheTimeMargin 10 minutes
Utilizzare questa direttiva per impostare l'intervallo di tempo massimo entro il quale il server deve conservare nella cache i file non utilizzati che presentano URL che corrispondono a una maschera specificata. Il server elimina i file non utilizzati, che presentano URL corrispondenti alla maschera, dopo averli conservati nella cache per un determinato periodo di tempo, indipendentemente dalla data di scadenza. È possibile includere più occorrenze di questa direttiva nel file di configurazione. Includere una direttiva separata per ciascuna maschera. La maschera URL deve contenere il protocollo. Per specificare la scadenza, può essere utilizzata qualsiasi combinazione di mesi, settimane, giorni e ore.
CacheUnused modello_url intervallo_tempo
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
Utilizzare questa direttiva per abilitare la memorizzazione dei file nella cache. Se la memorizzazione nella cache è attivata, il server proxy memorizza i file che richiama da altri server in una cache locale. Il server proxy quindi risponde alle successive richieste per gli stessi file senza doverli richiamare da altri server.
Caching {on | off}
Caching On
Utilizzare questa direttiva per specificare la durata oltre la quale i log vengono compressi. I log vengono compressi quando la relativa durata supera il valore impostato per CompressAge. Se CompressAge è impostato su 0, i log non vengono mai compressi. I log del giorno precedente e seguente non vengono mai compressi.
CompressAge numero_giorni
CompressAge 1
Utilizzare questa direttiva per creare un comando che identifichi il programma di utilità di compressione utilizzato per comprimere i log e che trasferisca i parametri a quel programma di utilità. Includere il percorso ai log archiviati.
Il programma di utilità di compressione deve essere installato in una directory elencata nel percorso di quella macchina.
CompressCommand comando
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%%
Nessuno
Utilizzare questa direttiva per specificare quando eliminare un log in seguito a compressione. Un log viene eliminato quando la relativa durata ha superato il numero di giorni impostato per il valore di CompressDeleteAge. Se CompressDeleteAge è impostato su 0 o se il valore è inferiore a quello impostato per la direttiva CompressAge, il log non viene eliminato.
CompressDeleteAge numero_giorni
CompressDeleteAge 7
Utilizzare questa direttiva per specificare il tipo di contenuto della risposta HTTP che si desidera comprimere.
La compressione di una risposta HTTP consente di ridurre il carico di rete e migliora le prestazioni del server proxy. Quando è abilitata la funzione di filtro di compressione, se il browser supporta la compressione HTTP e se la risposta HTTP non è correntemente compressa, Caching Proxy comprime la risposta HTTP e restituisce il contenuto compresso al browser.
È possibile abilitare la funzione di filtro di compressione aggiungendo le seguenti due direttive al file ibmproxy.conf:
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]
La libreria mod_z citata nella direttiva CompressionFilterEnable è la versione dinamica di zlib1.1.4.
la variabile type-n è un qualsiasi valore valido per l'intestazione Content-Type, ad esempio text/html o image/bmp.
Nessuno
Utilizzare questa direttiva per abilitare il filtro di compressione per comprimere le risposte HTTP dal server di backend o dalla cache del server proxy.
Per esempi su come utilizzare questa direttiva, fare riferimento a CompressionFilterAddContentType -- Specifica il tipo di contenuto della risposta HTTP che si desidera comprimere.
Nessuno
Utilizzare questa direttiva per specificare il nome e il percorso di un file di configurazione aggiuntivo. Le direttive presenti nel file di configurazione specificato vengono elaborate dopo il file di configurazione corrente.
Nessuno
Utilizzare questa direttiva per definire il numero di thread di connessione da utilizzare per la gestione delle connessioni.
ConnThreads numero
ConnThreads 5
Utilizzare questa direttiva per specificare la parte di un file necessario che deve essere trasferita per consentire a Caching Proxy di completare la creazione del file di cache, anche se la connessione client è stata chiusa. I valori validi per questa variabile sono numeri interi compresi nell'intervallo 0 - 100.
Ad esempio, se si specifica ContinueCaching 75, Caching Proxy continua a trasferire il file dal server di contenuti e genera il file di cache se almeno il 75% del file è stato trasferito prima che si accorga che la connessione client è terminata.
ContinueCaching percentuale
ContinueCaching 75
Utilizzare questa direttiva per fornire al proxy le informazioni necessarie per filtrare il contenuto degli URL, comprese le informazioni sul servizio di restrizione. È possibile utilizzare questa direttiva più volte.
DefinePicsRule "nome_filtro" {
DefinePicsRule "RSAC Example" {
Utilizzare questa direttiva per associare un'impostazione di protezione predefinita alle richieste che corrispondono a un modello.
DefProt modello_richiesta nome_impostazione [FOR indirizzo_IP_server | nome_host]
La protezione non è attualmente attivata per le richieste che corrispondono alla maschera, a meno che la richiesta non corrisponda anche a una maschera su una successiva direttiva Protect. Fare riferimento a Protect -- Attiva un passo di protezione per le richieste che corrispondono a un modello per una spiegazione di come utilizzare la direttiva Protect con DefProt.
È possibile specificare un indirizzo IP (ad esempio, FOR 240.146.167.72) o un nome host (ad esempio, FOR hostA.bcd.com).
Questo parametro è opzionale. Senza questo parametro, il server utilizza la direttiva per tutte le richieste a prescindere dall'indirizzo IP su cui è stata ricevuta la richiesta o dal nome host nell'URL.
Note:
Per un indirizzo IP del server non è possibile specificare un carattere jolly.
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
Nessuno
Utilizzare questa direttiva per specificare se l'agente cache attende tra l'invio delle richieste al server di destinazione. Se si specifica un intervallo di tempo tra una richiesta e l'altra è possibile ridurre il carico sulla macchina proxy e sul collegamento di rete, oltre che sui server di destinazione. In caso contrario, l'agente cache sarà in esecuzione alla massima velocità. Per connessioni Internet a bassa velocità, è preferibile non specificare alcun intervallo per poter utilizzare al massimo la rete.
DelayPeriod {on | off}
DelayPeriod On
Utilizzare questa direttiva per specificare se l'agente cache segue i collegamenti ipertestuali tra gli host. Se un URL memorizzato nella cache contiene collegamenti ad altri server, il server può ignorare il collegamento o seguirlo. Se la direttiva DelveInto è impostata su never, non verrà applicata.
DelveAcrossHosts {on | off}
DelveAcrossHosts Off
Utilizzare questa direttiva per specificare il numero di livelli di collegamento da seguire mentre si ricercano le pagine da caricare nella cache. Se la direttiva DelveInto è impostata su never, non verrà applicata.
DelveDepth numero_livelli
DelveDepth 2
Utilizzare questa direttiva per specificare se l'agente cache carica le pagine collegate dagli URL memorizzati nella cache.
DelveInto {always | never | admin | topn}
DelveInto always
Utilizzare questa direttiva per applicare un'immagine di sfondo per gli elenchi directory creati dal server proxy. Gli elenchi directory vengono generati quando il server proxy viene utilizzato per ricercare siti FTP.
Specificare un percorso assoluto all'immagine di sfondo. Se l'immagine risiede su un altro server, l'immagine di sfondo deve essere specificata come URL completo. Se non viene specificata alcuna immagine di sfondo, viene utilizzato un semplice sfondo bianco.
DirBackgroundImage /percorso/file
DirBackgroundImage /images/corplogo.png DirBackgroundimage http://www.somehost.com/graphics/embossed.gif
Nessuno
Utilizzare questa direttiva per specificare se gli elenchi directory includono un conteggio byte esatto per file con dimensioni inferiori a un 1 KB. Un valore Off indica che l'elenco directory visualizza la dimensione di 1 KB per tutti i file con dimensione minore o uguale a 1 KB.
DirShowBytes {on | off}
DirShowBytes Off
Utilizzare questa direttiva per specificare se gli elenchi directory devono distinguere tra caratteri maiuscoli e minuscoli durante l'ordinamento dei nomi file.
Un valore On indica che i caratteri maiuscoli precedono i caratteri minuscoli nell'elenco dei file.
DirShowCase {on | off}
DirShowCase On
Utilizzare questa direttiva per specificare se gli elenchi directory includono la data dell'ultima modifica per ciascun file.
DirShowDate {on | off}
DirShowDate On
Utilizzare questa direttiva per specificare se gli elenchi directory includono le descrizioni dei file HTML. Le descrizioni vengono acquisite dalle tag <title> HTML dei file.
Le descrizioni degli elenchi directory FTP illustrano i tipi MIME dei file, se è possibile determinarli.
DirShowDescription {on | off}
DirShowDescription On
Utilizzare questa direttiva per specificare se gli elenchi directory contengono dei file nascosti nella directory. Il server considera i file il cui nome inizia con un punto (.) come file nascosti.
DirShowHidden {on | off}
DirShowHidden On
Utilizzare questa direttiva per specificare se il server contiene icone negli elenchi directory. Le icone possono essere utilizzate per fornire una rappresentazione grafica del tipo di contenuto dei file nell'elenco. Le stesse icone vengono definite dalle direttive AddBlankIcon, AddDirIcon, AddIcon, AddParentIcon e AddUnknownIcon.
DirShowIcons {on | off}
DirShowIcons On
Utilizzare questa direttiva per impostare il numero massimo di caratteri da visualizzare nel campo relativo alla descrizione sugli elenchi directory.
DirShowMaxDescrLength numero_di_caratteri
DirShowMaxDescrLength 25
Utilizzare questa direttiva per impostare il numero massimo di caratteri utilizzati per i nomi file sugli elenchi directory.
DirShowMaxDescrLength numero_di_caratteri
DirShowMaxLength 25
Utilizzare questa direttiva per impostare il numero minimo di caratteri sempre riservati ai nomi file sugli elenchi directory. I nomi file nella directory possono oltrepassare questo numero. Tuttavia, non possono superare il numero specificato sulla direttiva DirShowMaxLength.
DirShowMinLength numero_di_caratteri
DirShowMinLength 15
Utilizzare questa direttiva per specificare se gli elenchi directory includono la dimensione di ciascun file.
DirShowSize {on | off}
DirShowSize On
Utilizzare questa direttiva per specificare i metodi HTTP che il server non accetta. Per ciascun metodo che il server deve rifiutare, inserire una direttiva Disable separata.
Nel file di configurazione predefinito, i metodi GET, HEAD, OPTIONS, POST e TRACE sono abilitati mentre tutti gli altri metodi HTTP supportati sono disabilitati. Per disabilitare un metodo attualmente abilitato, eliminarlo dalla direttiva Enable e aggiungerlo alla direttiva Disable.
Disable metodo
Disable PUT Disable DELETE Disable CONNECT
Utilizzare questa direttiva per specificare le variabili di ambiente che non devono essere ereditate dai programmi CGI (diverse dalle variabili di ambiente CGI specifiche per l'elaborazione CGI).
Per impostazione predefinita, le variabili di ambiente vengono ereditate dai programmi CGI. Utilizzare questa direttiva per escludere singole variabili di ambiente, in modo che non vengano ereditate.
DisInheritEnv variabile_ambiente
DisInheritEnv PATH DisInheritEnv LANG
In questo esempio, tutte le variabili di ambiente, tranne PATH e LANG, vengono ereditate dai programmi CGI.
Nessuno
Utilizzare questa direttiva per specificare se il server ricerca i nomi host dei client richiedenti.
DNS-Lookup {on | off}
Il valore utilizzato influisce su alcuni fattori relativi al funzionamento del server:
DNS-Lookup Off
Utilizzare questa direttiva per specificare i metodi HTTP accettati dal server.
È possibile abilitare tutti i metodi HTTP necessari. Per ciascun metodo che il server deve accettare, inserire una direttiva Enable separata.
Enable metodo
Se non esiste alcuna direttiva per uno specifico URL, è possibile utilizzare la direttiva Enable per eseguire la programmazione personalizzata dei metodi HTTP. Il programma specificato su questa direttiva ignora l'elaborazione standard per quel metodo.
Enable metodo /percorso/DLLfile:nome_funzione
Per informazioni sul formato e sulle opzioni disponibili per il metodo Enable CONNECT, fare riferimento a Configurazione del tunneling SSL.
Enable GET Enable HEAD Enable POST Enable TRACE Enable OPTIONS
Utilizzare questa direttiva per abilitare l'opzione socket TCP NODELAY.
La direttiva EnableTcpNodelay migliora le prestazioni quando pacchetti IP di piccole dimensioni, come sincronizzazioni SSL o brevi risposte HTTP, vengono trasmessi tra Caching Proxy e il client. Per impostazione predefinita, l'opzione TCP NODELAY è abilitata per tutti i socket.
EnableTcpNodelay {All | HTTP | HTTPS | None}
EnableTcpNodelay All
Utilizzare questa direttiva per specificare una funzione applicativa personalizzata che deve essere chiamata dal server durante la fase Errore. Questo codice viene eseguito per fornire una routine di errore personalizzata in caso di errore.
Error Modello_richiesta /percorso/file:nome_funzione
Error /index.html /ics/api/bin/icsext05.so:error_rtns
Nessuno
Utilizzare questa direttiva per specificare il percorso e il nome file dove il server deve registrare gli errori interni.
Se in esecuzione, il server avvia un nuovo file di log ogni giorno a mezzanotte. In caso contrario, questo si verifica appena il server viene avviato. Quando il file viene creato, il server utilizza il nome del file specificato, a cui appone un suffisso data. Il suffisso data è nel formato Mmmddyyyy , dove Mmm rappresenta le prime tre lettere del mese, dd il giorno del mese e yyyy l'anno.
ErrorLog /percorso/directory_log/nome_file
Utilizzare questa direttiva per specificare il nome di un file da inviare al client richiedente quando il server riscontra una particolare condizione di errore. Il file di configurazione ibmproxy.conf fornisce le direttive ErrorPage che associano le parole chiave relative all'errore ai file dei messaggi di errore.
Per personalizzare i messaggi di errore, è possibile modificare le direttive ErrorPage per associare le parole chiave relative all'errore a file differenti o modificare i file dei messaggi di errore forniti. Ad esempio, è possibile modificare un messaggio in modo che contenga informazioni aggiuntive sulla causa del problema e suggerisca le possibili soluzioni per correggerlo. Per le reti interne, è possibile fornire un contatto a cui gli utenti possono rivolgersi.
Le direttive ErrorPage possono essere posizionate ovunque nel file di configurazione. Quando si verifica un errore, il file viene elaborato in base alle regole di associazione definite nel file di configurazione. Perciò, il file da inviare deve risiedere in una posizione raggiungibile attraverso le regole di associazione, come definito dalle direttive Fail, Map, NameTrans, Pass, Redirect e Service. Come minimo, è necessaria la direttiva Pass che consente al server di trasferire il file del messaggio di errore.
ErrorPage parola chiave /percorso/nomefile.html
ErrorPage scriptstart /HTML/errorpages/scriptstart.htmls
In questo esempio, quando si riscontra una condizione scriptstart, il server invia al client un file scriptstart.htmls presente nella directory /HTML/errorpages/.
Il testo HTML riportato di seguito è un esempio del possibile contenuto del file:
<HTML> <HEAD> <TITLE>Messaggio per la condizione SCRIPTSTART</TITLE> </HEAD> <BODY> Impossibile avviare il programma CGI. <P> <A HREF="mailto:admin@websvr.com">Riferire il problema</A> all'amministratore. </BODY> </HTML>
Se la direttiva che corrisponde al suddetto percorso nel file di configurazione del server è PASS /* /wwwhome/*, il percorso completo a questo file di messaggio è /wwwhome/HTML/errorpages/scriptstart.htmls.
Ciascuna condizione di errore è identificata da una parola chiave. Per stabilire quali messaggi di errore personalizzare, esaminare i file di messaggi di errore inclusi in Caching Proxy, disponibili in /HTML/errorpages. La pagina di errore contiene il numero errore, il messaggio predefinito, una spiegazione della causa e un'azione di ripristino adatta.
Quindi, effettuare una delle seguenti operazioni per modificare un messaggio di errore:
Tutte le parole chiave relative all'errore e i file di messaggi di errore predefiniti sono elencati nel file ibmproxy.conf nella sezione della direttiva ErrorPage. I file di messaggi di errore contengono il numero del messaggio di errore, la parola chiave, il messaggio predefinito, la spiegazione e la risposta dell'utente (azione).
Molte impostazioni predefinite sono contenute nel file ibmproxy.conf
Se non si modifica una direttiva ErrorPage per una condizione di errore, viene inviata la pagina di errore predefinita del server per quella condizione.
Utilizzare questa direttiva per specificare il nome file e il percorso al file di log eventi. Il log eventi cattura i messaggi informativi sulla cache.
Se in esecuzione, il server avvia un nuovo file di log ogni giorno a mezzanotte. In caso contrario, questo si verifica appena il server viene avviato. Quando il file viene creato, il server utilizza il nome del file specificato, a cui appone un suffisso data. Il suffisso data è nel formato Mmmddyyyy , dove Mmm rappresenta le prime tre lettere del mese, dd il giorno del mese e yyyy l'anno.
EventLog /percorso/directory_log/nome_file
Utilizzare questa direttiva per specificare una maschera per le richieste da accettare e a cui rispondere eseguendo un programma CGI. Se una richiesta corrisponde a una maschera su una direttiva Exec, non viene confrontata con le maschere richiesta sulle direttive successive.
Exec modello_richiesta percorso_programma [indirizzo_IP_server | nome_host]
È necessario utilizzare un asterisco (*) come carattere jolly sia in maschera_richiesta che in percorso_programma. La parte della richiesta che corrisponde al carattere jolly maschera_richiesta deve iniziare con il nome del file che contiene il programma CGI.
La richiesta può anche contenere ulteriori dati trasferiti al programma CGI nella variabile di ambiente PATH_INFO. I dati aggiuntivi seguono il primo carattere barra (/) successivo al nome file del programma CGI sulla richiesta. I dati vengono trasferiti in base alle specifiche CGI.
La direttiva Exec è ricorsiva e si applica a tutte le sottodirectory. Non è necessario utilizzare una direttiva Exec separata per ciascuna directory in cgi-bin e admin-bin.
È possibile specificare un indirizzo IP (ad esempio, 240.146.167.72 ) o un nome host (ad esempio, hostA.bcd.com).
Questo parametro è opzionale. Senza questo parametro, il server utilizza la direttiva per tutte le richieste a prescindere dall'indirizzo IP su cui è stata ricevuta la richiesta o dal nome host nell'URL.
I caratteri jolly non possono essere utilizzati per specificare indirizzi IP server.
Nell'esempio riportato di seguito, se il server riceve una richiesta /idd/depts/plan/c92 , esegue il programma CGI in /depts/bin/plan.exe con c92 trasferito al programma come input.
L'esempio di seguito utilizza il parametro indirizzo IP opzionale. Se il server riceve richieste che iniziano con /cgi-bin/, supporta la richiesta da una differente directory, in base all'indirizzo IP della connessione di rete su cui è arrivata la richiesta. Per le richieste che arrivano su 130.146.167.72, il server utilizza la directory /CGI-BIN/customerA. Per le richieste che arrivano su una qualsiasi connessione con indirizzo 0.83.100.45, il server utilizza la directory /CGI-BIN/customerB.
Exec /cgi-bin/* /CGI-BIN/customerA/* 130.129.167.72 Exec /cgi-bin/* /CGI-BIN/customerB/* 0.83.100.45
Nell'esempio riportato di seguito viene utilizzato il parametro nome host opzionale. Se il server riceve richieste che iniziano con /cgi-bin, supporta la richiesta da una differente directory, in base al nome host nell'URL. Per le richieste che arrivano per hostA.bcd.com, il server utilizza la directory /CGI-BIN/customerA. Per le richieste che arrivano per hostB.bcd.com, il server utilizza la directory /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 root_server/cgi-bin/* Exec root_server/admin-bin/* Exec root_server/DOCS/admin-bin/*
Utilizzare questa direttiva per esportare i contenuti cache in un file di dump. Si tratta di un'operazione utile quando la cache in memoria va perduta durante il riavvio o quando la medesima cache viene distribuita a più proxy.
ExportCacheImageTo nome_file_esportazione
Nessuno
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
Utilizzare questa direttiva per configurare Caching Proxy in modo che riconosca un prodotto IBM WebSphere Application Server (configurato con un modulo adattatore di Caching Proxy) da cui possa memorizzare dinamicamente nella cache le risorse create. Caching Proxy salva le copie dei risultati JSP anch'essi memorizzati nella cache dinamica del server delle applicazioni. Caching Proxy memorizza nella cache solo i contenuti di un IBM WebSphere Application Server il cui ID di gruppo corrisponde ad una voce ExternalCacheManager.
Notare che, per abilitare questa funzione, è necessario aggiungere anche una direttiva Service al file di configurazione di Caching Proxy. Inoltre, è necessario eseguire altre procedure di configurazione sul server delle applicazioni. Fare riferimento a Memorizzazione nella cache di contenuto generato dinamicamente per le informazioni complete.
ExternalCacheManager ID_gestore_cache_esterna scadenza_massima
La voce riportata di seguito definisce un gestore cache esterno (IBM WebSphere Application Server) che si trova all'interno del dominio www.xyz.com e le cui risorse scadono in 20 secondi o meno.
ExternalCacheManager IBM-CP-XYZ-1 20 seconds
Nessuno
Utilizzare questa direttiva per specificare una maschera per le richieste che il server non deve elaborare. Se una richiesta corrisponde a una maschera su una direttiva Fail, non viene confrontata con le maschere richiesta sulle direttive successive.
Fail modello_richiesta [indirizzo_IP_server | nome_host]
Nella maschera, è possibile utilizzare un asterisco come carattere jolly. Il carattere tilde (~), subito dopo una barra (/), deve essere confrontato in modo esplicito; infatti per questa operazione non è possibile utilizzare un carattere jolly.
È possibile specificare un indirizzo IP (ad esempio, 240.146.167.72 ) o un nome host (ad esempio, hostA.bcd.com).
Questo parametro è opzionale. Senza questo parametro, il server utilizza la direttiva per tutte le richieste a prescindere dall'indirizzo IP su cui è stata ricevuta la richiesta o dal nome host nell'URL.
Per un indirizzo IP del server non è possibile specificare un carattere jolly.
Nell'esempio riportato di seguito, il server rifiuta le richieste che iniziano con /usr/local/private/.
Fail /usr/local/private/*
Nell'esempio riportato di seguito viene utilizzato il parametro dell'indirizzo IP opzionale. Il server rifiuta le richieste che iniziano con /customerB/ se la richiesta arriva su una connessione di rete con l'indirizzo IP 240.146.167.72. Il server rifiuta le richieste che iniziano con /customerA/ se la richiesta arriva su una connessione di rete con l'indirizzo IP 0.83.100.45.
Fail /customerB/* 240.146.167.72 Fail /customerA/* 0.83.100.45
Nell'esempio riportato di seguito viene utilizzato il parametro del nome host opzionale. Il server rifiuta le richieste con /customerB/ se la richiesta arriva per hostA.bcd.com. Il server rifiuta le richieste che iniziano con /customerA/ se la richiesta arriva per hostB.bcd.com.
Fail /customerB/* hostA.bcd.com Fail /customerA/* hostB.bcd.com
Nessuno
Utilizzare questa direttiva per abilitare la crittografia approvata FIPS per il protocollo SSLV3 e TLS nelle connessioni SSL. Quando questa direttiva è abilitata, l'elenco delle specifiche di crittografia supportate per SSLV3 (direttiva V3CipherSpecs) viene ignorato. Inoltre, le specifiche di crittografia TLS consentite verranno impostate su 352F0AFF09FE mentre le specifiche di crittografia SSLV3 su FFFE.
FIPSEnable {on | off}
FIPSEnable off
Utilizzare questa direttiva per indicare al proxy di utilizzare il file di configurazione SOCKS per determinare il tipo di connessione da creare.
flexibleSocks {on | off}
flexibleSocks on
Utilizzare questa direttiva per abilitare i server FTP a generare un messaggio descrittivo o iniziale per una directory. Facoltativamente, è possibile visualizzare questo messaggio come parte degli elenchi FTP. La direttiva FTPDirInfo consente di controllare dove viene visualizzato il messaggio.
FTPDirInfo {top | bottom | off}
FTPDirInfo top
Se il server proxy fa parte di una catena di proxy, utilizzare questa direttiva per specificare il nome di un altro proxy che il server può contattare per le richieste FTP. È necessario specificare un URL completo, contenente il carattere barra finale (/). Per informazioni sull'utilizzo di un modello o di un nome dominio facoltativo, fare riferimento a no_proxy -- Specifica i modelli per la connessione diretta ai domini.
Queste informazioni sono valide solo per le configurazioni di proxy diretto.
ftp_proxy URL_completo [nome_dominio_o_modello]
ftp_proxy http:// outer.proxy.server/
Nessuno
Utilizzare questa direttiva per specificare se le informazioni del percorso negli URL FTP vengono interpretate come relative alla directory di lavoro dell'utente collegato o alla directory root.
FTPUrlPath {relative | absolute}
Se la direttiva FTPUrlPath viene impostata su absolute, la directory di lavoro FTP dell'utente collegato deve essere inclusa nel percorso URL FTP. Se viene specificata la direttiva FTPUrlPath Relative, la directory di lavoro FTP dell'utente collegato deve essere omessa dal percorso URL FTP. Ad esempio, per accedere al file test1.html, contenuto nella directory di lavoro /export/home/user1 di un utente collegato, sono necessari i seguenti percorsi URL, a seconda dell'impostazione della direttiva FTPUrlPath:
Nessuno
Utilizzare questa direttiva per specificare se utilizzare la raccolta di dati inutili. Se la memorizzazione nella cache è abilitata, il server utilizza il processo di raccolta di dati inutili per eliminare i file che non devono più essere conservati nella cache. I file vengono eliminati in base alla relativa data di scadenza e ad altri valori della direttiva proxy. Generalmente, se la memorizzazione nella cache è abilitata, viene utilizzata la raccolta di dati inutili. Se la raccolta di dati inutili non viene adoperata, la cache proxy viene utilizzata in modo inefficiente.
Gc {on | off}
Gc On
Utilizzare questa direttiva per specificare un'applicazione personalizzata che il server deve utilizzare per la raccolta di dati inutili.
GCAdvisor /percorso/file:nome_funzione
GCAdvisor /api/bin/customadvise.so:gcadv
Utilizzare questa direttiva per specificare la percentuale della capacità cache totale che deve essere raggiunta per attivare la raccolta di dati inutili. Questa percentuale viene chiamata livello massimo di occupazione. Il livello massimo di occupazione viene specificato come percentuale della capacità cache totale. La raccolta di dati obsoleti continua fino a che viene raggiunto il livello minimo di occupazione; fare riferimento a GcLowWater -- Specifica quando termina la raccolta di dati obsoleti per informazioni su come impostare questo valore. La percentuale del livello massimo di occupazione è compresa tra 50 e 95.
GcHighWater percentuale
GcHighWater 90
Utilizzare questa direttiva per specificare la percentuale della capacità cache totale che attiva la fine della raccolta di dati inutili. Questa percentuale è nota come livello minimo di occupazione. Questo viene specificato come percentuale della capacità cache totale e deve essere impostato su un valore inferiore rispetto a quello del livello massimo di occupazione; per informazioni sull'impostazione di questo valore, vedere GcHighWater -- Specifica quando inizia la raccolta di dati obsoleti per informazioni su come impostare questo valore.
GcLowWater percentuale
GcLowWater 60
Se il server proxy fa parte di una catena di proxy, utilizzare questa direttiva per specificare il nome di un altro proxy che il server può contattare per le richieste Gopher. È necessario specificare un URL completo, contenente il carattere barra finale (/). Per informazioni sull'utilizzo di un modello o di un nome dominio facoltativo, fare riferimento a no_proxy -- Specifica i modelli per la connessione diretta ai domini.
Queste informazioni sono valide solo per le configurazioni di proxy diretto.
gopher_proxy URL_completo [nome_dominio_o_modello]
gopher_proxy http://outer.proxy.server/
Nessuno
Utilizzare questa direttiva per specificare il numero o il nome gruppo assunto dal server prima di accedere ai file.
Se la direttiva viene modificata, è necessario arrestare manualmente il server, quindi riavviarlo, per convalidare le modifiche. La modifica non ha effetto se il server viene solo riavviato. Fare riferimento a Avvio e arresto di Caching Proxy.
GroupId { nome_gruppo | numero_gruppo}
AIX: GroupId nobody
HP-UX: GroupId other
Linux:
Red Hat: GroupId nobody
SUSE: GroupId nogroup
Solaris: GroupId nobody
Utilizzare questa direttiva per specificare il nome del server proxy restituito nell'intestazione HTTP
HeaderServerName nome
Nessuno
Utilizzare questa direttiva per specificare il nome dominio o un indirizzo IP restituito ai client dalle richieste file. Se si specifica un nome dominio, il server deve essere in grado di risolvere il nome in un indirizzo IP. Se si specifica un indirizzo IP, il DNS (Domain Name Server) non è necessario né accessibile.
Hostname {nome | indirizzo IP}
Per impostazione predefinita, questa direttiva non viene specificata nel file di configurazione iniziale. Se questa direttiva non viene specificata nel file di configurazione, il valore assegnato sarà il nome host definito nel DNS (Domain Name Server).
Se il server proxy fa parte di una catena di proxy, utilizzare questa direttiva per specificare il nome di un altro proxy che il server può contattare per le richieste HTTP. È necessario specificare un URL completo, contenente il carattere barra finale (/). Per informazioni sull'utilizzo di un modello o di un nome dominio facoltativo, fare riferimento a no_proxy -- Specifica i modelli per la connessione diretta ai domini.
http_proxy URL_completo [nome_dominio_o_modello]
http://outer.proxy.server/
Nessuno
Utilizzare questa direttiva per specificare se Caching Proxy richiama la home page precaria dell'URL e tenta di ricercarvi le etichette. Nel caso queste vengano trovate, verranno applicate alla richiesta protetta. Ad esempio, se si richiede https://www.ibm.com/, Caching Proxy richiama http://www.ibm.com/ e ricerca le etichette, utilizzando tutte quelle che trova per filtrare https://www.ibm.com/.
Se HTTPSCheckRoot è impostato su off, Caching Proy non richiama la home page precaria né ricerca le etichette.
HTTPSCheckRoot {on | off}
HTTPSCheckRoot on
Utilizzare questa sottodirettiva per specificare un indirizzo IP utilizzato per inviare e ricevere query ICP. La sottodirettiva deve essere contenuta nelle direttive <MODULEBEGIN> ICP e <MODULEEND>.
ICP_Address indirizzo_IP
Per impostazione predefinita, questa direttiva non viene specificata nel file di configurazione iniziale. Se questa direttiva non viene specificata nel file di configurazione, il valore assegnato prevede di accettare e inviare query ICP su qualsiasi interfaccia.
Utilizzare questa sottodirettiva per specificare il numero di thread generati, in ascolto per ricevere le query ICP. La sottodirettiva deve essere contenuta nelle direttive <MODULEBEGIN> ICP e <MODULEEND>.
ICP_MaxThreads numero_di_thread
ICP_MaxThreads 5
Se il server proxy fa parte di un cluster ICP, utilizzare questa sottodirettiva per specificare i peer ICP. La sottodirettiva deve essere contenuta nelle direttive <MODULEBEGIN> ICP e <MODULEEND>.
Quando si aggiunge un nuovo peer al cluster ICP, le informazioni peer ICP devono essere aggiunte al file di configurazione di tutti i peer esistenti. Utilizzare una riga per ciascun peer. Notare che è possibile includere l'host corrente nell'elenco peer. Nel momento in cui ICP viene inizializzato, ignora la voce dell'host corrente. In questo modo, è possibile disporre di un solo file di configurazione che può essere copiato su altre macchine peer senza doverlo modificare per rimuovere l'host corrente.
ICP_Peer nomehost porta_http porta_icp
La riga riportata di seguito aggiunge l'host abc.xcompany.com, con porta proxy 80 e porta ICP 3128, come peer.
ICP_Peer abc.xcompany.com 80 3128
Nessuno
Utilizzare questa sottodirettiva per specificare il numero di porta su cui il server ICP è in ascolto per ricevere le query ICP. La sottodirettiva deve essere contenuta nelle direttive <MODULEBEGIN> ICP e <MODULEEND>.
ICP_Port numero_porta
ICP_Port 3128
Utilizzare questa sottodirettiva per specificare il tempo massimo in cui Caching Proxy attende per ricevere le risposte alle query ICP. Il tempo è specificato in millisecondi. La sottodirettiva deve essere contenuta nelle direttive <MODULEBEGIN> ICP e <MODULEEND>.
ICP_Timeout timeout_in_millisecondi
ICP_Timeout 2000
Utilizzare questa direttiva per specificare gli URL non caricati dall'agente cache. Questa direttiva è utile quando l'agente cache carica le pagine collegate dagli URL memorizzati nella cache. Per specificare URL o maschere URL differenti, è possibile utilizzare più occorrenze della direttiva IgnoreURL. Il valore di questa direttiva può contenere asterischi (*) come caratteri jolly, per applicare una maschera.
IgnoreURL URL
IgnoreURL http://www.yahoo.com/ IgnoreURL http://*.ibm.com/*
IgnoreURL */cgi-bin/*
Utilizzare questa direttiva per specificare se si intende eseguire l'elaborazione di inclusione lato server per i file supportati dal file system, programmi CGI o entrambi. L'elaborazione di inclusione lato server viene eseguita su file con un tipo di contenuto ext/x-ssi-html. Facoltativamente, è possibile specificare di eseguire l'elaborazione di inclusione lato server anche per i file con un tipo di contenuto text/html. Per ulteriori informazioni sui tipi di contenuto, fare riferimento a AddType -- Specifica del tipo di dati di file con determinati suffissi.
Per inserire dinamicamente le informazioni nel file che deve essere restituito, è possibile utilizzare l'elaborazione di inclusione lato server. Questo tipo di informazioni possono contenere la data, la dimensione di un file, la data in cui il file è stato modificato l'ultima volta, variabili di ambiente di inclusione CGI o lato server o file di testo. L'elaborazione di inclusione lato server viene eseguita esclusivamente sui file creati localmente. Caching Proxy non esegue l'elaborazione di inclusione lato server su oggetti proxy o cache.
L'elaborazione di inclusione lato server fa sì che il server ricerchi comandi speciali nei file, ogni volta che questi vengono supportati. Ciò può influire sulle prestazioni del server e rallentare il tempo di risposta ai client.
imbeds {on | off | files | cgi | noexec} {SSIOnly | html}
Il server controlla il tipo di contenuto di ciascun file che richiama e l'output di ciascun programma CGI che elabora.
Normalmente, l'elaborazione di inclusione lato server viene eseguita solo sui file con un tipo di contenuto text/x-ssi/html. Tuttavia, è possibile specificare che i file con un tipo di contenuto text/html vengano elaborati per inclusioni lato server.
Ciascun suffisso deve disporre di una direttiva AddType definita con il tipo di contenuto corretto. Se si utilizzano suffissi diversi da .htm or .html, verificare di aver definito una direttiva AddType con un tipo di contenuto text/x-ssi/html.
imbeds on SSIOnly
Utilizzare questa direttiva per importare i contenuti cache da un file di dump. Si tratta di un'operazione utile quando la cache in memoria va perduta durante il riavvio o quando la medesima cache viene distribuita a più proxy.
ImportCacheImageFrom nome_file_importazione
Nessuno
Utilizzare questa direttiva per specificare le variabili di ambiente che devono essere ereditate dai programmi CGI (diverse dalle variabili di ambiente CGI specifiche per l'elaborazione CGI).
Se non si inserisce la direttiva InheritEnv, i programmi CGI erediteranno tutte le variabili di ambiente. Se si inserisce una direttiva InheritEnv, verranno ereditate solo le variabili di ambiente specificate sulle direttive InheritEnv insieme alle variabili di ambiente specifiche di CGI. La direttiva consente di inizializzare facoltativamente il valore delle variabili ereditate.
InheritEnv variabile_ambiente
InheritEnv PATH InheritEnv LANG=ENUS
In questo esempio, i programmi CGI ereditano solo le variabili di ambiente PATH e LANG e la variabile di ambiente LANG viene inizializzata con il valore ENUS.
Nessuna. Per impostazione predefinita, le variabili di ambiente vengono ereditate dai programmi CGI.
Utilizzare questa direttiva per impostare il tempo consentito a un client per inviare una richiesta dopo aver stabilito un collegamento con il server. Per prima cosa, il client si collega al server, quindi invia una richiesta. Se il client non invia alcuna richiesta entro l'intervallo di tempo specificato con questa direttiva, il server chiude il collegamento. Il valore tempo può essere specificato come una qualsiasi combinazione di ore, minuti (o min) e secondi (o sec).
InputTimeout tempo
InputTimeout 3 mins 30 secs
InputTimeout 2 minutes
Questa direttiva ignora l'azione predefinita del plugin JunctionRewrite e consente al proxy di correggere determinati collegamenti URL nella pagina html. Utilizzata insieme alla direttiva JunctionRewrite.
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
La direttiva JunctionReplaceUrlPrefix indica al plugin JunctionRewrite di sostituire l'URL modello_url_1 con modello_url_2, anziché inserire un prefisso all'inizio dell'URL.
JunctionReplaceUrlPrefix modello_url_1 modello_url_2
JunctionReplaceUrlPrefix /server1.internaldomain.com/* /server1/*
In questo esempio, l'URL è /server1.internaldomain.com/notes.nsf mentre il prefisso è /server1. Anziché inserire il prefisso per riscrivere l'URL in/server1/server1.internaldomain.com/notes.nsf, il plugin JunctionRewrite cambia l'URL in /server1/notes.nsf.
Nessuno
Questa direttiva consente alla routine di riscrittura delle giunzioni in Caching Proxy di riscrivere le risposte provenienti dai server di origine per garantire che gli URL relativi al server vengano mappati sul server di origine adeguato, quando si utilizzano le giunzioni.
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
Se si imposta JunctionRewrite on senza l'opzione UseCookie, anche il plugin di riscrittura delle giunzioni deve essere abilitato. Le giunzioni vengono definite dalle regole di associazione del proxy.
Fare riferimento a UseCookie come alternativa a JunctionRewrite e Plug-in transmogrifier di esempio per estendere la funzionalità JunctionRewrite per ulteriori informazioni su JunctionRewrite.
JunctionRewrite {on | on UseCookie | off}
JunctionRewrite off
La direttiva consente al proxy di riscrivere l'opzione di percorso nell'intestazione Set-Cookie quando il nome cookie viene confrontato. Se la risposta richiede una giunzione e il prefisso di questa è definito, il prefisso verrà inserito prima di ciascun percorso. Può essere utilizzata con il plugin JunctionRewrite o con al direttiva RewriteSetCookieDomain.
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
JunctionRewriteSetCookiePath nome-cookie1 nome-cookie2...
Nessuno
Questa direttiva non tiene conto dell'azione predefinita del plugin JunctionRewrite, ignorando la riscrittura dell'URL in caso di corrispondenza del modello URL. Funziona insieme al plugin JunctionRewrite, offrendo un modo per correggere alcuni collegamenti URL nella pagina html. Normalmente, la direttiva viene utilizzata per ignorare gli URL che già includono un prefisso.
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
JunctionSkipUrlPrefix modello_url
JunctionSkipUrlPrefix /server1/*
In questo esempio, l'URL è /server1/notes.nsf e il prefisso giunzione è /server1/. Anziché riscrivere l'URL in /server1/server1/notes.nsf, il plugin JunctionRewrite ignora la riscrittura dell'URL che rimane invariato, ossia /server1/notes.nsf.
Nessuno
Utilizzare questa direttiva per evitare di sovraccaricare i server di backend con richieste mentre l'oggetto cache è in fase di riconvalida.
Quando un oggetto cache deve essere riconvalidato con il contenuto sul server di backend, le richieste per la medesima risorsa verranno delegate al server di backend. A volte, il server di backend si interrompe a causa di un numero considerevole di richieste identiche. Abilitando questa direttiva, è possibile evitare questa situazione. Quando la direttiva è abilitata, viene restituita una copia scaduta o obsoleta della risorsa, se questa è in fase di aggiornamento sul proxy.
KeepExpired {on | off}
KeepExpired off
Utilizzare questa direttiva per specificare il percorso file al database di chiavi utilizzato dal server per le richieste SSL. I file di chiavi vengono generati per mezzo del programma di utilità gestore chiavi iKeyman.
KeyRing nomefile
Windows: KeyRing c:\Program Files\IBM\edge\cp\\key.kdb
Linux e UNIX: KeyRing /etc/key.kdb
Nessuno
Utilizzare questa direttiva per specificare il percorso al file password del database di chiavi. Il file password viene generato per mezzo del programma di utilità gestore chiavi iKeyman, quando si crea un file database di chiavi.
KeyRingStash percorso_file
Windows: KeyRingStash c:\Program Files\IBM\edge\cp\key.sth
Linux e UNIX: KeyRingStash /etc/key.sth
Nessuno
Utilizzare questa direttiva per controllare la dimensione corpo massima nelle richieste PUT o POST. Le direttive LimitRequest vengono utilizzate per proteggere il proxy da eventuali attacchi.
Il valore può essere specificato in kilobyte (K), megabyte (M) o gigabyte (G).
LimitRequestBody dimensione_corpo_max {K | M | G}
LimitRequestBody 10 M
Utilizzare questa direttiva per specificare il numero massimo di intestazioni che possono essere inviate nelle richieste client. Le direttive LimitRequest vengono utilizzate per proteggere il proxy da eventuali attacchi.
LimitRequestFields numero_intestazioni
LimitRequestFields 32
Utilizzare questa direttiva per specificare la lunghezza massima della riga della richiesta e di ciascuna intestazione in una richiesta. Le direttive LimitRequest vengono utilizzate per proteggere il proxy da eventuali attacchi.
Il valore può essere specificato in byte (B) o kilobyte (K).
LimitRequestFieldSize lunghezza_intestazione_max {B | K}
LimitRequestFieldSize 4096 B
Utilizzare questa direttiva per specificare il numero di connessioni client backlog di ascolto che il server può supportare prima di inviare ai client messaggi che indicano che la connessione è stata rifiutata. Questo numero dipende dal numero di richieste che il server può elaborare in pochi secondi. Non impostare questo numero su un valore superiore al numero che il server può tollerare prima che si verifichi il timeout dei client e la connessione si interrompa.
ListenBacklog numero_di_richieste
ListenBacklog 128
Utilizzare questa direttiva per specificare se le immagini in linea vengono richiamate dall'agente cache. Se LoadInlineImages è impostata su on, le immagini incorporate in una pagina che deve essere memorizzata nella cache verranno anch'esse memorizzate. Se impostata su off, le immagini incorporate non verranno memorizzate nella cache.
LoadInlineImages {on | off}
LoadInlineImages on
Utilizzare questa direttiva per indicare all'agente cache di accedere al log accessi cache della sera precedente e di caricare gli URL più richiesti.
Quando si imposta un valore per la direttiva LoadTopCached, è necessario impostare la direttiva Caching su On e un valore per la direttiva CacheAccessLog.
LoadTopCached numero_di_pagine
LoadTopCached 100
Utilizzare questa direttiva per specificare gli URL che l'agente cache deve caricare nella cache. Nel file di configurazione, è possibile includere più direttive LoadURL ma non è possibile utilizzare caratteri jolly.
LoadURL url
LoadURL http://www.ibm.com/
Nessuno
Utilizzare questa direttiva per specificare una funzione applicativa personalizzata che deve essere richiamata dal server durante la fase Log. Questo codice consente di eseguire registrazioni e altre elaborazioni dopo la chiusura della connessione.
Log modello_richiesta /percorso/file:nome_funzione
Log /index.html /api/bin/icsextpgm.so:log_url
Nessuno
Utilizzare questa direttiva per specificare il funzionamento della routine di archiviazione. Questa direttiva influisce su tutti i log con impostazioni globali. Specifica se i log vengono compressi o eliminati oppure se non sono sottoposti ad alcuna operazione.
Se si specifica Compress, utilizzare le direttive CompressAge e CompressDeleteAge per specificare quando i log sono compressi o eliminati. Utilizzare la direttiva CompressCommand per specificare il comando e i relativi parametri da utilizzare.
Se si specifica Purge, utilizzare le direttive PurgeAge e PurgeSize per specificare il momento in cui i log vengono eliminati.
LogArchive {Compress | Purge | none}
LogArchive Purge
Utilizzare questa direttiva per specificare il formato dei file di log accessi.
LogFileFormat {common | combined}
Per impostazione predefinita, i log vengono visualizzati nel formato di log comune NCSA. Specificare combined per visualizzare i log nel formato combinato NCSA. Questo formato aggiunge i campi per URL di riferimento, Agente utente e Cookie (se presenti nella richiesta).
LogFileFormat common
Solo sistemi Windows. Quando il proxy viene eseguito dalla riga comandi, utilizzare questa direttiva per inviare l'output al log accessi. Per ottimizzare le prestazioni, per impostazione predefinita, questa direttiva è impostata su off (disabilitata).
LogToGUI {on | off}
LogToGUI off
Solo sistemi Linux e UNIX. Utilizzare questa direttiva per specificare se il server registra le richieste di accesso e gli errori nel log di sistema oltre che nei file di log relativi agli accessi e agli errori.
LogToSyslog {on | off}
Il file di log di sistema deve essere presente sul server per poter specificare di scrivervi le informazioni del log errori. Si può scegliere se registrare le informazioni di accesso, di errore o entrambe.
Per inviare solo le informazioni di errore sul log di sistema, aggiungere la seguente riga al file /etc/syslog.conf:
user.err syslog_output_file_for_error_information
Per inviare solo le informazioni di accesso sul log di sistema, aggiungere la seguente riga al file /etc/syslog.conf:
user.info syslog_info_file_for_access_information
Per inviare le informazioni di errore e di accesso al log di sistema, aggiungere la seguente riga al file/etc/syslog.conf:
Specificare file_output_syslog e file_info_syslog nei seguenti formati:
Dopo aver creato il file di log di sistema, è possibile riavviarlo con il seguente comando:
kill -HUP 'cat /etc/syslog.pid'
LogToSyslog Off
Utilizzare questa direttiva per specificare una maschera per le richieste da modificare con una nuova stringa richiesta. Una volta che il server ha modificato la richiesta, acquisisce la nuova stringa e la confronta con le maschere richiesta sulle direttive successive.
La direttiva Map utilizza la stringa path richiesta in entrata per associare la regola. Vedere anche MapQuery -- Modifica le richieste corrispondenti a una nuova stringa di richiesta utilizzando la stringa del percorso della richiesta e la stringa della query in modo da corrispondere alla regola.
Map modello_richiesta nuova_richiesta [indirizzo_IP_server | nome_host]
Nella maschera, è possibile utilizzare un asterisco (*) come carattere jolly. Il carattere tilde (~), subito dopo una barra (/), deve essere confrontato in modo esplicito; infatti per questa operazione non è possibile utilizzare un carattere jolly.
È possibile specificare un indirizzo IP (ad esempio, 240.146.167.72 ) o un nome host (ad esempio, hostA.raleigh.ibm.com).
Questo parametro è opzionale. Senza questo parametro, il server utilizza la direttiva per tutte le richieste a prescindere dall'indirizzo IP su cui è stata ricevuta la richiesta o dal nome host nell'URL.
Per un indirizzo IP del server non è possibile specificare un carattere jolly.
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
Nessuno
Utilizzare questa direttiva per specificare una maschera per le richieste da modificare con una nuova stringa richiesta. Una volta che il server ha modificato la richiesta, acquisisce la nuova stringa e la confronta con le maschere richiesta sulle direttive successive.
La funzionalità di questa direttiva è molto simile a quella della regola Map (Map -- Modifica le richieste corrispondenti a una nuova stringa di richiesta utilizzando la stringa del percorso della richiesta in modo da corrispondere alla regola). Tuttavia, per gestire un URL con una stringa query, MapQuery utilizza sia la stringa path che la stringa query per associare la regola. Se l'URL in entrata viene associato su una regola MapQuery, l'URL tradotto verrà utilizzato per associare il resto delle regole.
MapQuery può anche tradurre un URL con una stringa query su un altro URL con una stringa path o query differente. Tuttavia, poiché tutte le altre direttive di associazione utilizzando solo la stringa path della richiesta, la stringa query modificata verrà aggiunta soltanto all'URL tradotto quando viene associata la stringa path della richiesta (non verrà ovvero utilizzata per associare modelli).
MapQuery modello_richiesta nuova_richiesta [indirizzo_IP_server | nome_host]
Nella maschera, è possibile utilizzare un asterisco (*) come carattere jolly. Il carattere tilde (~), subito dopo una barra (/), deve essere confrontato in modo esplicito; infatti per questa operazione non è possibile utilizzare un carattere jolly.
È possibile specificare un indirizzo IP (ad esempio, 240.146.167.72 ) o un nome host (ad esempio, hostA.raleigh.ibm.com).
Questo parametro è opzionale. Senza questo parametro, il server utilizza la direttiva per tutte le richieste a prescindere dall'indirizzo IP su cui è stata ricevuta la richiesta o dal nome host nell'URL.
Per un indirizzo IP del server non è possibile specificare un carattere jolly.
Si assuma che l'URL in entrata sia il seguente:
/getsomthing?type=1
e che la regola MapQuery sia
MapQuery /getsomething?type=* /gettype/*
L'URL tradotto sarà /gettype/1 e verrà utilizzato nella successiva associazione della regola.
Proxy /gettype/* http://server/gettype/*
L'URL tradotto sarà http://server/gettype/1.
Nessuno
Utilizzare questa direttiva per impostare il numero massimo di thread attivi contemporaneamente. Quando viene raggiunto il numero massimo, il server trattiene le nuove richieste fino al completamento di un'altra richiesta, che libera i thread. Generalmente, più la macchina è potente, più il numero impostato per questa direttiva sarà elevato. Se una macchina inizia a impiegare troppo tempo su attività generali, quali lo swapping della memoria, ridurre questo valore.
MaxActiveThreads numero_di_thread
MaxActiveThreads 100
Utilizzare questa direttiva per impostare la dimensione del buffer per i dati dinamici generati dal server. I dati dinamici provengono da programmi CGI, inclusioni lato server e programmi API.
Il valore può essere specificato in byte (B), kilobyte (K), megabyte (M) o gigabyte (G). La presenza di uno spazio tra il numero e il valore (B, K, M, G) è irrilevante.
MaxContentLengthBuffer dimensione
MaxContentLengthBuffer 100 K
Utilizzare questa direttiva per specificare la dimensione massima di ciascun file di log. Ciascun file di log non può superare la dimensione definita da questa direttiva. Quando un file di log raggiunge la dimensione massima definita, il file di log corrente viene chiuso e ne viene creato uno nuovo con lo stesso nome, a cui viene aggiunto il valore intero incrementale successivo.
Note:
Il valore consigliato per l'impostazione della direttiva MaxLogFileSize è almeno 10 M, ma inferiore a 200 M. La dimensione reale del file di log è leggermente maggiore della dimensione che viene impostata. L'impostazione di un valore troppo basso influenza le prestazioni del proxy in quanto il server proxy chiude e apre il file di log con una frequenza maggiore. Su alcune piattaforme, l'impostazione di un valore troppo alto fa sì che il proxy utilizzi più memoria per il buffering I/O. Quando la dimensione del file di log diventa troppo elevata, il proxy potrebbe non disporre della memoria necessaria anche se i buffer I/O sono controllati dal sistema operativo.
La dimensione massima può essere specificata in una delle seguenti unità: byte (B), kilobyte (K), megabyte (M) e gigabyte (G).
MaxLogFileSize dimensione massima {B | K | M | G}
MaxLogfileSize 128 M
Se la direttiva è commentata, tuttavia, non esiste alcuna limitazione per la dimensione del file di log.
Utilizzare questa direttiva per specificare il numero massimo di richieste che il server riceve su una connessione permanente. Quando si determina questo numero, considerare la quantità delle immagini presenti nelle pagine. Ciascuna immagine deve disporre di una richiesta separata.
MaxPersistRequest numero
MaxPersistRequest 5
Utilizzare questa direttiva per specificare il livello massimo della coda dell'agente cache che contiene le richieste di richiamo pagine in attesa. Se si dispone di un sistema di grandi dimensioni con una notevole quantità di memoria, è possibile definire una coda di richieste di richiamo pagine più grande senza utilizzare tutta la memoria disponibile.
La coda di URL da memorizzare nella cache viene determinata all'avvio di ogni esecuzione dell'agente cache. Se si indica all'agente cache di seguire i collegamenti ipertestuali ad altri URL, questi non verranno conteggiati nel livello della coda cache. Quando si raggiunge il valore specificato nella direttiva MaxURLs, l'agente cache si arresta, anche in presenza di altri URL nella coda.
MaxQueueDepth livello_massimo
MaxQueueDepth 250
Utilizzare questa direttiva per specificare il tempo massimo che l'agente cache ha a disposizione per richiamare gli URL durante una specifica esecuzione. Un valore pari a 0 indica che l'agente cache sarà in esecuzione fino al completamento.
MaxRuntime {0 | tempo_massimo}
MaxRuntime 2 hours 10 minutes
MaxRuntime 2 hours
Utilizzare questa direttiva per impostare il numero massimo di socket inattivi aperti da mantenere per qualsiasi server di origine. Utilizzare questa direttiva solo se la direttiva ServerConnPool è impostata su on.
MaxSocketPerServer num
MaxSocketPerServer 10
MaxSocketPerServer 5
Utilizzare questa direttiva per specificare il numero massimo di URL richiamati dall'agente cache durante una specifica esecuzione. Un valore pari a 0 indica che non ci sono limiti. Quando si utilizza la modalità automatica dell'agente cache, le direttive LoadURL e LoadTopCached hanno la precedenza su MaxURLs.
MaxURLs numero_massimo
MaxURLs 2000
Utilizzare questa direttiva per specificare i membri delle matrici condivisi dai server mediante la funzione RCA (Remote Cache Access).
Member nome { sottodirettiva sottodirettiva . . }
Sono incluse le seguenti sottodirettive:
Member bittersweet.chocolate.ibm.com { RCAAddr 127.0.0.1 RCAPort 6294 CacheSize 25G Timeout 500 milliseconds BindSpecific On ReuseAddr Off }
Nessuno
Utilizzare questa direttiva per specificare il plugin dell'applicazione in esecuzione a mezzanotte per archiviare i log. Questa direttiva viene inizializzata durante l'installazione. Se questa direttiva non è inclusa nel file di configurazione, l'archiviazione non viene eseguita.
Midnight /percorso/file:nome_funzione
Utilizzare questa direttiva per specificare una funzione applicativa personalizzate richiamata dal server durante la fase Conversione nome. Questo codice fornisce il meccanismo per convertire il percorso virtuale nella richiesta nel percorso fisico sul server, mappando gli URL su specifici oggetti.
NameTrans modello_richiesta /percorso/file:nome_funzione [indirizzo_IP_server | nome_host]
Per un indirizzo IP del server non è possibile specificare un carattere jolly.
NameTrans /index.html /api/bin/icsextpgm.so:trans_url
Nessuno
Su piattaforme Linux e UNIX, utilizzare questa direttiva per impedire che il processo server di Caching Proxy venga eseguito automaticamente in background. Per impostazione predefinita, la direttiva, impostata su off, ha il seguente formato:
NoBG [on | off]
NoBG on
NoBG off
Utilizzare questa direttiva per specificare che il server non memorizza nella cache i file con URL che corrispondono alla maschera specificata. È possibile includere più occorrenze di questa direttiva nel file di configurazione. Includere una direttiva separata per ciascuna maschera. La maschera URL deve contenere il protocollo.
Se la direttiva CacheOnly o NoCaching non è impostata, qualsiasi URL può essere memorizzato nella cache.
NoCaching modello_URL
NoCaching http://joke/*
Nessuno
Utilizzare questa direttiva per specificare che le richieste di accesso effettuate da host o domini specifici che corrispondono a una maschera prescelta non verranno registrate. Ad esempio, non si desidera registrare le richieste di accesso di host locali.
È possibile includere più occorrenze di questa direttiva nel file di configurazione. Inoltre, è possibile inserire più maschere sulla stessa direttiva, purché vengano separate da uno o più spazi. È possibile utilizzare nomi host o indirizzi IP sulle maschere.
NoLog {nome_host | indirizzo_IP} [...]
NoLog 128.0.* *.edu localhost.*
Nessuno
Se si utilizza la direttiva http_proxy, ftp_proxy o gopher_proxy per le catene di proxy, è possibile utilizzare questa direttiva per specificare i domini a cui il server si collega direttamente anziché passare per un proxy.
Specificare un valore come una stringa di nomi dominio o maschere nomi dominio. Separare ciascuna voce nella stringa con una virgola (,). Non utilizzare spazi nella stringa.
Le maschere in questa direttiva vengono inserite in modo differente rispetto ad altre direttive. Inoltre, non è possibile utilizzare caratteri jolly (*). È possibile specificare una maschera includendo solo l'ultima parte di un nome dominio. Il server si collega direttamente a qualsiasi dominio che termina con una stringa corrispondente alle maschere specificate. Questa direttiva si applica solo a catene di proxy ed è equivalente a una riga @/= diretta nel file di configurazione SOCKS.
no_proxy nome_dominio_o_maschera[,...]
no_proxy www.someco.com,.raleigh.ibm.com,.some.host.org:8080
In questo esempio, il server non passa attraverso un proxy per le seguenti richieste:
Nessuno
Per impostazione predefinita, quando si riceve una richiesta Range dai browser, Caching Proxy richiede una risposta completa dal server di back-end. Caching Proxy rimuove l'intestazione Range dalla richiesta e inoltra quindi la richiesta al server di back-end. Una volta memorizzata la risposta nella cache del server proxy, le richieste successive per lestesse risorse verranno utilizzate dal server proxy indipendentemente dal fatto che le richieste siano richieste Range o no. Di solito, l'azione predefinita di Caching Proxy migliora le prestazioni e fornisce ai client tempi di risposta più brevi. Tuttavia, se la risposta non può essere memorizzata nella cache o se la dimensione della risposta è elevata, l'azione predefinita ridurrà le prestazioni.
Utilizzare la direttiva NoCacheOnRange, che specifica che le richieste Range non vengonomemorizzate nella cache, per risolvere il problema descritto quando si utilizza la configurazione predefinita.
Quando si abilita la direttiva in generale nel file ibmproxy.conf o se la si abilita come opzione per la regola PROXY, Caching Proxy inoltrerà l'intestazione della richiesta Range al server di back-end. Tuttavia, Caching Proxy non memorizza nella cache la risposta 206 (contenuto parziale) dal server di back-end.
L'abilitazione della direttiva NoCacheOnRange migliora le prestazioni del proxy nei seguenti casi:
NoCacheOnRange [on | off]
È possibile abilitare NoCacheOnRange in una regola di associazione proxy:
Proxy /not-cachable/* http://server.com/no-cachable-resources/* NoCacheOnRange
NoCacheOnRange off
Utilizzare questa direttiva per specificare le intestazioni URL client da bloccare. Le intestazioni HTTP inviate da un client, comprese le intestazioni obbligatorie, possono essere bloccate. Fare attenzione mentre si bloccano le intestazioni. Tra le intestazioni comuni sono incluse:
Consultare la specifica del protocollo HTTP, per i dettagli su queste e altre informazioni. È possibile utilizzare questa direttiva più volte.
NoProxyHeader intestazione
NoProxyHeader Referer:
Nessuno
Utilizzare questa direttiva per specificare il numero di thread utilizzati dall'agente cache per richiamare le pagine nella coda. Basare il numero di thread sulla velocità della rete interna e del collegamento a Internet. L'intervallo di valori consentito è compreso tra 1 e 100.
NumClients numero
NumClients 4
Utilizzare questa direttiva per specificare una funzione applicativa personalizzata richiamata dal server durante la fase Tipo di oggetto. Questo codice individua gli oggetti richiesti nel file system e ne specifica il tipo MIME.
ObjectType modello_richiesta /percorso/file:nome_funzione
ObjectType /index.html /api/bin/icsextpgm.so:obj_type
Nessuno
Questa direttiva velocizza il processo di associazione delle regole per le richieste in entrata quando aumenta il numero di regole.
Quando si abilita la direttiva OptimizeRuleMapping, invece che la associazione di richieste URI in entrata rispetto a ogni regola uno-a-uno, il proxy associa l'URI a una struttura del prefisso. La struttura del prefisso consente al proxy di rimuovere il confronto tra le stringhe ridondanti tra le regole di associazione. Come risultato, Caching Proxy ottiene prestazioni migliori quando il numero di regole nella configurazione è maggiore di 300.
OptimizeRuleMapping [on | off ]
OptimizeRuleMapping off
Utilizzare questa direttiva per impostare il tempo massimo consentito al server per inviare l'output a un client. Il limite di tempo è valido per le richieste di file locali e per le richieste per cui il server funge da proxy. Questo limite non è valido per le richieste che avviano un programma CGI locale.
Se il server non invia la risposta completa entro il limite di tempo specificato su questa direttiva, interrompe il collegamento. Il valore tempo può essere specificato come una qualsiasi combinazione di ore, minuti (o min) e secondi (o sec).
OutputTimeout tempo
OutputTimeout 30 minutes
Utilizzare questa direttiva per specificare la directory contenente i file di auto-configurazione proxy generati utilizzando il modulo file PAC di configurazione remoto.
PacFilePath percorso_directory
Utilizzare questa direttiva per specificare una maschera per le richieste che si intende accettare e a cui si desidera rispondere con un file dal server. Se una richiesta corrisponde a una maschera su una direttiva Pass, non viene confrontata con le maschere richiesta sulle direttive successive.
Pass modello_richiesta [percorso_file [indirizzo_IP_server | nome_host]]
Nella maschera, è possibile utilizzare un asterisco (*) come carattere jolly. Il carattere tilde (~), subito dopo una barra (/), deve essere confrontato in modo esplicito; infatti per questa operazione non è possibile utilizzare un carattere jolly.
Questo parametro è opzionale. Se non si specifica un percorso, la richiesta stessa viene utilizzata come percorso.
È possibile specificare un indirizzo IP (ad esempio, 240.146.167.72 ) o un nome host (ad esempio, hostA.raleigh.ibm.com).
Questo parametro è opzionale. Senza questo parametro, il server utilizza la direttiva per tutte le richieste a prescindere dall'indirizzo IP su cui è stata ricevuta la richiesta o dal nome host nell'URL.
Per un indirizzo IP del server non è possibile specificare un carattere jolly.
Sistemi Linux e UNIX: Pass /updates/parts/* /opt/ibm/edge/cp/server_root/pub/*
Sistemi Windows: Pass /updates/parts/* c:\Program Files\IBM\edge\cp\pub\*
Pass /gooddoc/*
Pass /parts/* /customerA/catalog/* 240.146.167.72 Pass /parts/* /customerB/catalog/* 0.83.100.45
Sistemi AIX
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/*
Sistemi Solaris, HP-UX e Linux
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/*
Sistemi AIX
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/*
Sistemi HP-UX, Linux e Solaris
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/*
Sistemi Windows
Pass /icons/* C:\Program Files\IBM\edge\cp\icons\* Pass /Admin/* C:\Program Files\IBM\edge\cp\Admin\* Pass /Docs/* C:\Program Files\IBM\edge\cp\Docs\* Pass /erropages/* C:\Program Files\IBM\edge\cp\pub\errorpages\* Pass /* C:\Program Files\IBM\edge\cp\pub\*
Utilizzare questa direttiva per specificare l'intervallo di tempo che il server attende tra le risposte del client prima di annullare una connessione permanente. Il tempo può essere specificato utilizzando un qualsiasi incremento valido ma normalmente viene espresso in secondi o minuti.
Il server utilizza una direttiva timeout differente, InputTimeout, per determinare il tempo di attesa per l'invio della prima richiesta da parte del client, dopo aver stabilito la connessione. Per ulteriori informazioni sul timeout di input, fare riferimento a InputTimeout -- Specifica il timeout di input.
Dopo l'invio della prima risposta, il server utilizza il valore impostato per la direttiva PersistTimeout per determinare il tempo di attesa tra una richiesta e l'altra, prima di annullare la connessione permanente.
PersistTimeout tempo
PersistTimeout 4 seconds
Utilizzare questa direttiva per specificare una funzione applicativa personalizzata che il server adopera per richiamare le etichette PICS di un determinato URL. La funzione consente di creare automaticamente un'etichetta PICS per il file richiesto o ricercarne una in un file o database alternativo.
PICSDBLookup /percorso/file:nome_funzione
PICSDBLookup /api/bin/icsext05.so:get_pics
Nessuno
Solo Linux e UNIX. Utilizzare questa direttiva per specificare la posizione del file che contiene l'ID processo di Caching Proxy. All'avvio del processo server, l'ID processo (PID) viene registrato in un file. Se più istanze del server sono in esecuzione su un unico sistema, ciascuna istanza deve disporre della propria direttiva PidFile.
PidFile percorso_a_info_file_pid
PidFile /usr/pidinfo
Su sistemi AIX, per supportare IBM 4960 PCI Cryptographic Accelerator Card, sono fornite delle direttive aggiuntive.
Utilizzare queste tre direttive per consentire al proxy di caricare il driver del dispositivo, aprire il dispositivo token e accedere ai certificati memorizzati sul dispositivo. Una volta caricato il driver del dispositivo, il server proxy utilizzerà automaticamente il dispositivo per aumentare la velocità di comunicazione SSL.
Vedere anche SSLCryptoCard -- Specifica la scheda di crittografia installata.
PKCS11DefaultCert etichetta_cert_predefinito
Specificare l'etichetta del certificato SSL predefinito memorizzato sul dispositivo token.
PKCS11DriverPath percorso_assoluto_driver_scheda
Specificare il percorso assoluto del driver del dispositivo per Cryptographic Accelerator Card.
PKCS11TokenPassword password
Specificare la password per aprire il dispositivo token.
PKCS11DefaultCert MyDefaultCertInTheToken PKCS11DriverPath /usr/lib/pkcs11/PKCS11_API.so PKCS11TokenPassword MyPasswordToOpenTheToken
Nessuno
Le direttive riportate di seguito sono state aggiunte al file ibmproxy.conf di Caching Proxy per abilitare nuove funzioni e plugin. La maggior parte di queste direttive non può essere modificata con i moduli di configurazione e amministrazione. Utilizzare un editor di testo standard, quale vi o emacs, per modificarle manualmente. Ulteriori informazioni su ciascuna di queste direttive sono disponibili nel presente capitolo, in ordine alfabetico.
Nel file ibmproxy.conf, inserire le direttive utilizzate per configurare i moduli plugin di Caching Proxy nel seguente formato:
<MODULEBEGIN> nome plugin subdirective1 subdirective2 <MODULEEND>
Ciascun programma plugin analizza il file ibmproxy.conf e legge solo il proprio blocco di direttive. Il parser di Caching Proxy trascura tutto ciò che è compreso tra <MODULEBEGIN> e <MODULEEND>.
I moduli plugin di Caching Proxy e alcune nuove funzioni richiedono di aggiungere le direttive API al file ibmproxy.conf. Dal momento che il server proxy interagisce con i moduli plugin nell'ordine in cui sono elencati, prestare attenzione quando si ordinano le direttive all'interno del file di configurazione proxy. Le direttive prototipo (sotto forma di commenti) sono state aggiunte alla sezione API del file ibmproxy.conf. L'ordine di queste direttive API è significativo. Quando di aggiungono direttive API per abilitare nuove funzioni e moduli plugin, l'ordine delle direttive viene illustrato nella sezione dei prototipi del file di configurazione. In alternativa, rimuovere il commento e modificare le direttive API, se necessario, per includere il supporto a ogni funzione o plugin prescelto. Aggiungere moduli plugin creati dall'utente dopo quelli forniti dal prodotto.
Utilizzare questa direttiva per specificare il numero di porta su cui il server è in ascolto per ricevere richieste. Il numero di porta standard per HTTP è 80. Le porte con numero inferiore a 1024 sono riservate ad altre applicazioni TCP/IP e non devono essere utilizzate. Le porte comuni utilizzate per i server Web proxy sono la numero 8080 e 8008.
Quando viene utilizzata una porta diversa dalla 80, i client devono includere un numero di porta specifico sulle richieste al server. Il numero di porta è preceduto da un carattere due punti (:) e collocato dopo il nome host dell'URL. Ad esempio, dal browser, l'URL http://www.turfco.com:8008/ richiede la pagina iniziale predefinita da un host denominato www.turfco.com, in ascolto sulla porta 8008.
Per non tenere conto di questa impostazione durante l'avvio del server, è possibile utilizzare l'opzione -p sul comando ibmproxy.
Port numero
Se la direttiva viene modificata, è necessario arrestare manualmente il server, quindi riavviarlo, per convalidare le modifiche. Il server non riconosce la modifica se viene solamente riavviato. Fare riferimento a Avvio e arresto di Caching Proxy.
Porta 80
Utilizzare questa direttiva per specificare una funzione applicativa personalizzata richiamata dal server durante la fase PostAuth. Questo codice viene eseguito indipendentemente dai codici di ritorno delle fasi precedenti o di altri handler PostAuth e consente di deallocare le risorse assegnate per elaborare la richiesta.
PostAuth /percorso/file:nome_funzione
AuthExit /ics/api/bin/icsext05.so:post_exit
Nessuno
Utilizzare questa direttiva per specificare una funzione applicativa personalizzata richiamata dal server durante la fase PostExit. Questo codice viene eseguito indipendentemente dai codici di ritorno delle fasi precedenti o di altri handler PostExit e consente di deallocare le risorse assegnate per elaborare la richiesta.
PostExit /percorso/file:nome_funzione
PostExit /ics/api/bin/icsext05.so:post_exit
Nessuno
Utilizzare questa direttiva per specificare una funzione applicativa personalizzata richiamata dal server durante la fase PreExit. Questo codice viene eseguito in seguito alla lettura di una richiesta client ma prima di qualsiasi altra elaborazione. Durante questa fase, è possibile richiamare il modulo GoServe.
PreExit /percorso/file:nome_funzione
PreExit /ics/api/bin/icsext05.so:pre_exit
Nessuno
Utilizzare questa direttiva per attivare le regole dell'impostazione di protezione per le richieste che corrispondono a una maschera.
Un'impostazione di protezione viene definita con sottodirettive di protezione. Il formato della direttiva Protect varia a seconda che si desideri puntare a un'etichetta o a un file contenente le sottodirettive di protezione oppure includere queste ultime in linea come parte della direttiva Protect.
Questo parametro può assumere i seguenti formati:
Protect modello_richiesta [file_impostazione | etichetta[ [FOR indirizzo_IP_server | nome_host]
Protect modello_richiesta [FOR indirizzo_IP_server | nome_host] sottodirettiva valore sottodirettiva valore . . . }
Vengono utilizzati i parametri riportati di seguito:
Questo parametro è opzionale. Se omesso, l'impostazione di protezione viene definita dalla direttiva DefProt più aggiornata contenente una maschera corrispondente.
Esempio:
Protect http://x.x.x.x PROT-ADMIN
In un browser Web:
Esempio:
Protect http://hostname.example.com PROT-ADMIN
In un browser Web:
È possibile specificare un indirizzo IP (ad esempio, FOR 240.146.167.72) o un nome host (ad esempio, FOR hostA.bcd.com).
I caratteri jolly non possono essere utilizzati per specificare indirizzi IP server.
Questo parametro è opzionale. Senza questo parametro, il server utilizza la direttiva per tutte le richieste a prescindere dall'indirizzo IP su cui è stata ricevuta la richiesta o dal nome host nell'URL.
Questi esempi utilizzano indirizzi IP. Se il server riceve richieste che iniziano con /secret/ o /topsecret/, attiva un'impostazione di protezione differente per la richiesta, in base all'indirizzo IP della connessione di rete su cui è arrivata la richiesta.
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 }
Per impostazione predefinita, la protezione per i moduli di configurazione e amministrazione viene fornita da una direttiva Protect con una maschera richiesta /admin-bin/* .
Utilizzare questa direttiva per definire un'impostazione di protezione nel file di configurazione. Assegnare un nome all'impostazione di protezione e definire il tipo di protezione utilizzando le sottodirettive di protezione.
Note:
Protection nome_etichetta { sottodirettiva valore sottodirettiva valore . . . }
Fare riferimento a Sottodirettive di Protection -- Specificano il modo in cui viene protetta una serie di risorse per le descrizioni delle sottodirettive di protezione.
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 }
Di seguito sono riportate le descrizioni delle sottodirettive di protezione che possono essere utilizzate in un'impostazione di protezione. Le sottodirettive sono in ordine alfabetico.
Le impostazioni di protezione possono trovarsi in file separati o essere incluse nel file di configurazione, come parte delle direttive DefProt, Protect o Protection.
Utilizzare questa sottodirettiva di protezione quando si limita l'accesso in base a nomi utente e password. Specificare il tipo di autenticazione da utilizzare quando il client invia una password al server. Con l'autenticazione di base (AuthType Basic), le password vengono inviate al server sotto forma di testo normale. Le password sono codificate ma non crittografate.
AuthType Basic
Utilizzare questa sottodirettiva Protection per specificare nomi utente, gruppi e maschere indirizzi autorizzati a eseguire richieste DELETE su una directory protetta.
DeleteMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
Utilizzare questa sottodirettiva Protection per specificare nomi utente, gruppi e maschere indirizzi autorizzati a eseguire richieste GET su una directory protetta.
GetMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
GetMask All@(*)
Utilizzare questa sottodirettiva Protection per specificare il percorso e il nome del file gruppo server utilizzato dall'impostazione di protezione. I gruppi definiti nel file gruppo server possono quindi essere utilizzati da:
GroupFile /docs/etc/WWW/restrict.group
Utilizzare questa sottodirettiva per specificare nomi utente, gruppi e maschere indirizzo autorizzati a eseguire richieste HTTP non contemplate da altre sottodirettive Mask.
Mask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
MASK WEBADM,webadm
Utilizzare questa sottodirettiva di protezione quando si limita l'accesso in base a nomi utente e password. Specificare il percorso e il nome del file di password che deve essere utilizzato da questa impostazione di protezione.
Dal momento che alcuni browser memorizzano nella cache gli ID utente e le password per domini di sicurezza (ServerID) in un host, seguire le istruzioni qui riportate mentre si specificano file di password e ServerID:
PasswdFile /docs/etc/WWW/restrict.password
PasswdFile "c:\test this\admin.pwd"
Per un server protetto, utilizzare questa sottodirettiva Protection per specificare utenti, gruppi e maschere indirizzo autorizzati a eseguire richieste POST su una directory protetta.
PostMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
Utilizzare questa sottodirettiva Protection per specificare utenti, gruppi e maschere indirizzi autorizzati a eseguire richieste PUT su una directory protetta.
PutMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
Utilizzare questa sottodirettiva di protezione quando si limita l'accesso in base a nomi utente e password. Specificare un nome da associare al file di password da utilizzare. Il nome non deve essere necessariamente quello di una macchina reale.
Il nome viene utilizzato come identificativo per il richiedente. Dal momento che impostazioni di protezione differenti possono utilizzare diversi file di password, se si associa un nome all'impostazione di protezione, il client potrà stabilire più facilmente quale password inviare. La maggior parte dei client visualizza questo nome quando viene richiesto un nome utente e una password.
Dal momento che alcuni browser memorizzano nella cache ID utente e password per dominio di sicurezza (ServerID) in un host, seguire le istruzioni qui riportate mentre si specificano file di password e ServerID:
ServerID restricted
Utilizzare questa direttiva per indicare i protocolli che Caching Proxy deve elaborare e per mappare una richiesta su un server. I protocolli validi sono http, ftp e gopher.
La direttiva del proxy invia la richiesta al server remoto. Ad esempio, la seguente direttiva consente di inoltrare tutte le richieste all'URL designato:
Proxy /* http://nome.server.proxy/*
Per un server proxy inverso protetto, utilizzare la seguente direttiva:
Proxy /* https://nome.server.proxy/*
Se si desidera ridurre le limitazioni sul server proxy, rimuovere il commento dalle seguenti direttive nel file di configurazione. Tuttavia, queste direttive possono introdurre un problema di sicurezza quando il proxy è configurato come proxy inverso.
Proxy http:* Proxy ftp:* Proxy gopher:*
Parametri facoltativi:
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
Questa opzione indica a Caching Proxy di mantenere una associazione uno-a-uno tra il socket del client e il socket in uscita. Questa opzione risulta utile per alcune applicazioni, come l'autenticazione basata sulla connessione, che richiedono che il proxy mantenga il socket del server attivo e che lo riutilizzi per le richieste in entrata dallo stesso socket del client.
Se la regola del proxy è associata, questa opzione indica al proxy di non memorizzare nella cache le risposte corrispondenti.
Se la regola del proxy è associata e nella richiesta è presente un'intestazione Range, questa opzione indica al proxy di non memorizzare nella cache la risposta corrispondente. Per ulteriori informazioni, fare riferimento a NoCacheOnRange -- Specifica nessuna memorizzazione nella cache per le richieste di intervallo.
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
Utilizzare questa opzione se il plug-in di riscrittura junction è abilitato. Questa opzione non consente al proxy di riscrivere le risposte corrispondenti se l'URL in entrata è associato. Per ulteriori informazioni, fare riferimento a Abilitazione della riscrittura delle giunzioni (facoltativa) e a Definizione della giunzione con l'opzione JunctionPrefix (metodo consigliato).
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
Utilizzare questa opzione se il plug-in di riscrittura junction è abilitato. Anziché dedurre junction dal primo schema di URL nella regola proxy, questa opzione dichiara esplicitamente il prefisso di giunzione nella regola. Per ulteriori informazioni, fare riferimento a Abilitazione della riscrittura delle giunzioni (facoltativa) e a Definizione della giunzione con l'opzione JunctionPrefix (metodo consigliato).
Proxy maschera_richiesta percorso_server_destinazione [[ip]:porta] [UseSession | NoCaching | NoCacheOnRange | NoJunction | JunctionPrefix:/prefisso_URL]
Di seguito è riportato un esempio dell'opzione UseSession per la direttiva Proxy:
Proxy /abc/* http://server1/default/abc/* :80 UseSession
Quando la richiesta client in entrata arriva dalla porta 80 e se l'URL sulla richiesta client corrisponde al modello /abc/*, l'URL viene mappato su http://server1/default/abc/* .
Nessuna.
Utilizzare questa direttiva per specificare il percorso e il nome del file dove il server deve registrare le statistiche di accesso per le richieste proxy. Per impostazione predefinita, il server scrive una voce in questo log ogni volta che funge da proxy per una richiesta client. Se non si desidera registrare le richieste di determinati client, è possibile utilizzare la direttiva NoLog.
Il server avvia un nuovo file di log ogni giorno a mezzanotte, se in esecuzione. In caso contrario, questo si verifica appena il server viene avviato. Quando il file viene creato, il server utilizza il nome del file specificato, a cui appone un suffisso data o un'estensione. Il suffisso data o estensione è nel formato Mmmddyyyy , dove Mmm si riferisce alle prime tre lettere del mese, dd al giorno e yyyy all'anno.
È opportuno eliminare i file di log meno recenti in quanto occupano una significativa quantità di spazio sul disco rigido.
ProxyAccessLog percorso/file
Utilizzare questa direttiva per specificare un'applicazione personalizzata che il server deve richiamare durante la fase Proxy Advisor. Questo codice supporta la richiesta.
ProxyAdvisor /percorso/file:nome_funzione
ProxyAdvisor /api/bin/customadvise.so:proxyadv
Nessuno
Utilizzare la direttiva ProxyForwardLabels per specificare il filtro PICS sul server proxy e sul client o su due proxy in una gerarchia.
Se ProxyForwardLabels è impostato su on, il server proxy genera le intestazioni HTTP PICS-Label: per tutte le etichette PICS individuate, comprese etichette del server di origine, banche di etichette, cache etichette di Caching Proxy e plugin per la fornitura di etichette.
Se ProxyForwardLabels è impostata su Off, le intestazioni HTTP PICS-Label: non vengono generate.
ProxyForwardLabels {on | off}
ProxyForwardLabels Off
Utilizzare questa direttiva per generare un'intestazione From:. Normalmente, questa viene utilizzata per fornire un indirizzo e-mail dell'amministratore proxy.
ProxyFrom indirizzo_e-mail
L'impostazione ProxyFrom webmaster@proxy.ibm.com modifica l'intestazione
nel modo seguente:
Intestazione originale | Intestazione modificata |
---|---|
Indirizzo: http://www.ibm.com/ | Indirizzo: http://www.ibm.com/ |
Ultima modifica: martedì 5 Nov 1997 10:05:39 GMT | Ultima modifica: martedì 5 Nov 1997 10:05:39 GMT |
Pragma: no-cache | From: webmaster@proxy.ibm.com |
| Pragma: no-cache |
Nessuno
Utilizzare questa direttiva per specificare la reazione del server quando gli utenti selezionano con il mouse il pulsante Ricarica del browser. Se la direttiva ProxyIgnoreNoCache è impostata su on, durante i periodi di carico elevato, il server non richiede la pagina dal server di destinazione ma fornisce la copia del file memorizzata nella cache, se disponibile. In pratica, il server ignora l'intestazione Pragma: no-cache inviata dal browser.
ProxyIgnoreNoCache {on | off}
ProxyIgnoreNoCache off
Utilizzare questa direttiva per specificare se mantenere una connessione permanente con il client. Una connessione permanente riduce il tempo di attesa degli utenti e il carico CPU sul server proxy ma richiede un numero superiore di risorse. Una connessione permanente richiede più thread, quindi più memoria sul server proxy.
Le connessioni permanenti non devono essere utilizzate su un'impostazione server proxy a struttura, se uno dei proxy non è conforme a HTTP 1.1.
ProxyPersistence {on | off}
ProxyPersistence on
Utilizzare questa direttiva per specificare se il proxy inoltra l'indirizzo IP del client al server di destinazione.
ProxySendClientAddress {IP_client: | OFF}
La direttiva ProxySendClientAddress IP-client: modifica
l'intestazione nel modo seguente:
Intestazione originale | Intestazione modificata |
---|---|
Indirizzo: http://www.ibm.com/ | Indirizzo: http://www.ibm.com |
Ultima modifica: martedì 5 Nov 1997 10:05:39 GMT | Ultima modifica: martedì 5 Nov 1997 10:05:39 GMT |
Pragma: no-cache | Client-IP: 0.67.199.5 |
| Pragma: no-cache |
Nessuno
Utilizzare questa direttiva per specificare una stringa Agente utente che sostituisca la stringa inviata dal client. In questo modo, è possibile mantenere l'anonimato mentre si visitano i siti Web. Tuttavia, alcuni siti presentano delle pagine personalizzate basate sulla stringa Agente utente. L'uso della direttiva ProxyUserAgent impedisce di visualizzare alcune pagine personalizzate.
ProxyUserAgent nome_prodotto/versione
La direttiva ProxyUserAgent Caching Proxy/7.0 modifica l'intestazione nel modo seguente:
Intestazione originale | Intestazione modificata |
---|---|
Indirizzo: http://www.ibm.com/ | Indirizzo: http://www.ibm.com |
Ultima modifica: martedì 5 Nov 1997 10:05:39 GMT | Ultima modifica: martedì 5 Nov 1997 10:05:39 GMT |
Agente utente: Mozilla/ 2.02 OS2 | User Agent: Caching Proxy/7.0 |
Pragma: no-cache | Pragma: no-cache |
Nessuno
Utilizzare questa direttiva per controllare il formato dell'intestazione HTTP. Per questa direttiva, sono possibili quattro valori. Se ProxyVia è impostata su Full, Caching Proxy aggiunge un'intestazione Via nella richiesta o nella risposta; se un'intestazione Via si trova già nel flusso, Caching Proxy aggiunge le informazioni host alla fine. Se impostata su Set, Caching Proxy imposta l'intestazione Via sulle informazioni host; se un'intestazione Via già si trova nel flusso, Caching Proxy la elimina. Se impostata su Pass, Caching Proxy inoltra le informazioni dell'intestazione così come sono. Se impostata su Block, Caching Proxy non inoltra intestazioni Via.
ProxyVia {Full | Set | Pass | Block}
ProxyVia Pass
ProxyVia Full
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
La direttiva di associazione ProxyWAS funziona come la direttiva Proxy con la sola differenza che indica a Caching Proxy di dirigere le richieste corrispondenti a WebSphere Application Server. Per gli esempi sull'utilizzo di questa direttiva, fare riferimento a Proxy -- Specifica i protocolli proxy o il proxy inverso.
ProxyWAS modello_richiesta percorso_server_destinazione [[ip]:porta] [UseSession | NoCaching | NoCacheOnRange | NoJunction | JunctionPrefix:/prefisso_URL]
Nessuno
Utilizzare questa direttiva per specificare se il server funge da server proxy o da proxy e server di contenuti. Si consiglia di utilizzare Caching Proxy solo come proxy.
PureProxy {on | off}
PureProxy on
Utilizzare questa direttiva per specificare la durata di un log, espressa in giorni, prima che il log venga eliminato. Se PurgeAge è impostata su 0, il log non viene eliminato.
PurgeAge numero
PurgeAge 7
Utilizzare questa direttiva per specificare la dimensione, in megabyte, che i file di log possono raggiungere prima che l'archivio log venga svuotato. Se la direttiva PurgeSize è impostata su 0, non esiste alcun limite relativo alla dimensione, quindi i file non verranno eliminati.
L'impostazione di PurgeSize si riferisce a tutti i log di un determinato tipo. Ad esempio, se si stanno registrando errori (ossia, se una voce ErrorLog è stata creata nel file di configurazione) e PurgeSize è pari a 10 MB, Caching Proxy calcola le dimensioni di tutti i log errori, le somma ed elimina i log finché la dimensione totale non rientra al di sotto dei 10 MB.
PurgeSize numero_di_MB
PurgeSize 0
Utilizzare questa direttiva per specificare il nome e il percorso del file di configurazione RCA (Remote Cache Access).
RCAConfigFile /etc/nome_file
RCAConfigFile /etc/user2rca.conf
RCAConfigFile /etc/rca.conf
Utilizzare questa direttiva per specificare il numero di thread attivi su una porta RCA.
RCAThreads numero_di_thread
RCAThreads 50
MaxActiveThreads x [(ArraySize -1) / (2 x ArraySize -1)]
Utilizzare questa direttiva per specificare il limite di tempo consentito senza attività di rete prima che una connessione venga annullata.
ReadTimeout tempo
ReadTimeout 5 minutes
Utilizzare questa direttiva per specificare una maschera per le richieste che si intende accettare e inviare a un altro server. Se una richiesta corrisponde a una maschera su una direttiva Redirect, la richiesta non viene confrontata con le maschere su altre direttive nel file di configurazione.
Redirect modello_richiesta URL [indirizzo_IP_server | nome_host]
Nella maschera, è possibile utilizzare un asterisco (*) come carattere jolly. Il carattere tilde (~), subito dopo una barra (/), deve essere confrontato in modo esplicito; infatti per questa operazione non è possibile utilizzare un carattere jolly.
L'URL deve contenere la specifica di un protocollo e il nome del server a cui viene inviata la richiesta. Può inoltre contenere un percorso o nome file. Se maschera_richiesta adopera un carattere jolly, anche il percorso o il nome file sull'URL può utilizzare un carattere jolly. La parte della richiesta originale che corrisponde al carattere jolly su maschera_richiesta viene inserita al posto del carattere jolly sull'URL.
È possibile specificare un indirizzo IP (ad esempio, 240.146.167.72 ) o un nome host (ad esempio, hostA.bcd.com).
Questo parametro è opzionale. Senza questo parametro, il server utilizza la direttiva per tutte le richieste a prescindere dall'indirizzo IP su cui è stata ricevuta la richiesta o dal nome host nell'URL.
Per un indirizzo IP del server non è possibile specificare un carattere jolly.
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
Nessuno
Utilizzare questa direttiva per consentire a Caching Proxy di memorizzare nella cache più di una variante di una risorsa (URI) in base all'intestazione Cookie.
Per ulteriori informazioni, fare riferimento a SupportVaryHeader -- Memorizza nella cache più di una variante di una risorsa basata sull'intestazione HTTP Vary.
RegisterCacheIdTransformer Cookie nome-cookie
Il nome-cookie è il nome nell'intestazione Cookie nella richiesta del client.
RegisterCacheIdTransformer Cookie Usergroup
Per un esempio di utilizzo di questa direttiva insieme a SupportVaryHeader, fare riferimento a SupportVaryHeader -- Memorizza nella cache più di una variante di una risorsa basata sull'intestazione HTTP Vary.
Nessuno
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
La direttiva di associazione ReversePass esamina il flusso di risposte del server per individuare le richieste riscritte come risultato del reindirizzamento automatico. Normalmente, quando un server restituisce un codice HTTP nella classe 3xx (ad esempio, 301, Spostato in modo permanente, o 303, Visualizza altro), il server invia un messaggio con una risposta che indica al client richiedente di indirizzare le future richieste all'URL e all'indirizzo IP corretti. Nel caso di impostazione di un proxy inverso, un messaggio di reindirizzamento dal server di origine può far sì che i browser client ignorino il server proxy per le richieste successive. Per evitare che i client contattino direttamente il server di origine, utilizzare la direttiva ReversePass per intercettare le richieste eseguite in modo specifico al server di origine.
A differenza di altre direttive di associazione, che elaborano il flusso di richieste, ReversePass confronta la relativa maschera con il flusso di risposte. Il flusso di risposte è la risposta che il server proxy ottiene dal server di origine e invia al client.
ReversePass URL_riscritto URL_proxy [host:porta]
L'opzione host:porta consente al proxy di applicare una regola ReversePass differente, in base al nome host e alla porta del server di backend.
ReversePass http://backend.company.com:9080/* http://edge.company.com/*La porta 9080 è la porta predefinita per il servizio dell'applicazione su Edge. Questo tipo di richiesta può essere generato se il server delle applicazioni di origine restituisce un codice 3xx al client.
ReversePass http://edge.company.com:9080/* http://edge.company.com/*
Nessuno
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
Utilizzare questa direttiva per specificare il modello del dominio da riscrivere. La direttiva trasforma il dominio da modello1_dominio a modello2_dominio.
RewriteSetCookieDomain modello1_dominio modello2_dominio
RewriteSetCookieDomain .internal.com .external.com
Nessuno
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
La direttiva abilita o disabilita il reindirizzamento RTSP. Le opzioni sono on o off.
RTSPEnable {on | off}
RTSPEnable on
Nessuno
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
Questa direttiva viene utilizzata per specificare i server proxy RTSP che ricevono le richieste reindirizzate. Per differenti tipi di flussi è possibile specificare server diversi. Il formato di questa direttiva è il seguente:
rtsp_proxy_server indirizzo dns server[:porta] classificazione predefinita [elenco di tipi mime]
rtsp_proxy_server rproxy.mycompany.com:554 1 rtsp_proxy_server fw1.mycompany.com:554 2 rtsp_proxy_server fw1.mycompany.com:555 3 rtsp_proxy_server fw2.mycompany.com:557 4
Nessuno
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
Questa direttiva specifica il numero di richieste ricevute prima che una richiesta RTSP venga reindirizzata a un server proxy anziché a un server di origine. I proxy RealNetworks memorizzano nella cache i flussi sulla prima richiesta e, inizialmente, si riscontra un raddoppio della larghezza di banda per la ricezione del flusso. Specificando una soglia superiore a uno, le richieste eseguite una sola volta non verranno memorizzate nella cache. Il formato di questa direttiva è il seguente:
rtsp_proxy_threshold numero_di_ricorrenze
rtsp_proxy_threshold 5
Nessuno
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
Questa direttiva specifica il numero di URL univoci conservati in memoria per il reindirizzamento. Il proxy fa riferimento a questo elenco per determinare se è già stato riscontrato uno specifico URL. Un elenco di dimensioni superiori aumenta la capacità del server proxy di inviare una richiesta successiva allo stesso server proxy che ha ricevuto la richiesta precedente, ma ciascuna voce in elenco utilizza circa 16 byte di memoria.
rtsp_url_list_size dimensione_elenco
rtsp_url_list_size 8192
Nessuno
Per impostazione predefinita, quando Caching Proxy mappa le richieste rispetto alle regole definite nel file ibmproxy.conf, il processo di associazione è sensibile al maiuscolo/minuscolo. Tuttavia, alcuni URL delle applicazioni non sono sensibili al maiuscolo/minuscolo. Per poter gestire queste richieste correttamente, viene fornita la direttiva RuleCaseSense. Quando questa direttiva è impostata su off, il proxy associerà le richieste senza tenere conto della differenza maiuscolo/minuscolo.
RuleCaseSense {on | off}
RuleCaseSense on
Utilizzare questa direttiva per impostare il tempo concesso per chiudere un programma CGI avviato dal server. Scaduto il tempo, il server chiude il programma. Su piattaforme Linux e UNIX, questo avviene con il segnale KILL.
Specificare un valore tempo utilizzando una qualsiasi combinazione di ore, minuti (o min) e secondi (o sec).
ScriptTimeout timeout
ScriptTimeout 5 minutes
Utilizzare questa direttiva per specificare che le richieste inviate da Caching Proxy a un server downstream devono utilizzare il protocollo HTTP versione 1.0. (Un server downstream è un altro server proxy in una catena di proxy o un server di origine che elabora la richiesta.)
Se viene utilizzata questa direttiva, Caching Proxy identifica HTTP 1.0 come protocollo nella riga richieste. Al server downstream vengono inviate esclusivamente la funzionalità specifica di HTTP 1.0 e determinate funzioni di HTTP 1.1, come le intestazioni Cache-Control, supportate dalla maggior parte dei server HTTP 1.0. Utilizzare questa direttiva se si dispone di un server downstream che non gestisce correttamente le richieste HTTP 1.1.
Se la direttiva SendHTTP10Outbound non viene specificata, Caching Proxy identifica HTTP 1.1 come protocollo nella riga richieste.Nella richiesta, è possibile utilizzare anche la funzionalità HTTP 1.1, come le connessioni permanenti.
SendHTTP10Outbound modello_url
Questa direttiva può essere specificata più di una volta, ad esempio:
SendHTTP10Outbound http://www.hosta.com/* SendHTTP10Outbound http://www.hostb.com/*
Per motivi di compatibilità con le versioni precedenti, la suddetta sintassi di SendHTTP10Outbound viene gestita come segue:
Nessuno
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
Se funge da proxy inverso, Caching Proxy riceve le richieste HTTP da un client e le invia al server di origine. Per impostazione predefinita, Caching Proxy scrive il nome host del server di origine nell'intestazione HOST della richiesta che invia al server di origine. Al contrario, se la direttiva SendRevProxyName è impostata su yes, Caching Proxy scrive il proprio nome host nell'intestazione HOST. Questa direttiva può essere utilizzata per attivare una configurazione speciale per i server di back-end, in cui la richiesta inviata al server di origine sembra sempre provenire dal server proxy, anche nel caso in cui la richiesta viene reindirizzata da un server di back-end all'altro.
Questa direttiva si distingue dalla direttiva di associazione ReversePass nel modo seguente: la direttiva ReversePass intercetta le richieste con una determinata sintassi e ne sostituisce il contenuto con quello specificato. La direttiva SendRevProxyName può essere impostata solo per sostituire il nome host di Caching Proxy al nome host del server di origine. Questa direttiva non è utile nella configurazione del servizio applicazione su Edge.
SendRevProxyName {yes | no}
Questa direttiva imposta l'intervallo in cui il thread di raccolta di dati inutili controlla le connessioni server in timeout (impostata con la direttiva ServerConnTimeout). Utilizzare questa direttiva solo se la direttiva ServerConnPool è impostata su on.
ServerConnGCRun intervallo_tempo
ServerConnGCRun 2 minutes
ServerConnGCRun 2 minutes
Questa direttiva consente al proxy di raggruppare le proprie connessioni in uscita ai server di origine. Se impostata su on è possibile migliorare le prestazioni e sfruttare al massimo i server di origine che autorizzano alle connessioni permanenti. Con la direttiva ServerConnTimeout, è inoltre possibile specificare per quanto tempo una connessione può rimanere inutilizzata.
ServerConnPool {on | off}
ServerConnPool off
Utilizzare questa direttiva per limitare il tempo concesso senza attività di rete prima che la connessione venga annullata. Utilizzare questa direttiva solo se la direttiva ServerConnPool è impostata su on.
ServerConnTimeout spec-tempo
ServerConnTimeout 30 seconds
ServerConnTimeout 10 seconds
Utilizzare questa direttiva per specificare una funzione applicativa personalizzata richiamata dal server durante le routine di inizializzazione. Questo codice viene eseguito prima della lettura di qualsiasi richiesta client e ogni volta che il server viene riavviato.
Se si utilizzano i moduli GoServe nelle fasi PreExit o Service, è necessario chiamare qui il modulo gosclone.
ServerInit /percorso/file:nome_funzione [stringa_inizializzazione]
ServerInit /ics/api/bin/icsext05.so:svr_init
Nessuno
Utilizzare questa direttiva per specificare la directory dove è installato il programma server (l'attuale directory di lavoro del server). Le direttive di registrazione utilizzano questa directory di lavoro come root predefinita quando si utilizzano nomi percorso relativi.
Su sistemi Windows, la directory viene identificata durante l'installazione.
ServerRoot percorso_directory
Utilizzare questa direttiva per specificare una funzione applicativa personalizzata richiamata dal server durante la fase Chiusura del server. Questo codice viene eseguito quando si verifica una chiusura regolare e ogni volta che il server viene riavviato. In questo modo, è possibile rendere disponibili le risorse assegnate da una funzione applicativa PreExit.
ServerTerm /percorso/file:nome_funzione
ServerTerm /ics/api/bin/icsext05.so:shut_down
Nessuno
Utilizzare questa direttiva per specificare una funzione applicativa personalizzate richiamata dal server durante la fase Servizio. Questo codice supporta le richieste client. Ad esempio, consente di inviare il file o di eseguire il programma CGI.
Non sono disponibili impostazioni predefinite per questa direttiva. Se la richiesta corrisponde a una regola relativa al servizio (ossia, se viene eseguita una funzione applicativa specificata su una direttiva Service) ma la funzione restituisce HTTP_NOACTION, il server genera un errore e la richiesta non riesce.
Service modello_richiesta/percorso/file:nome_funzione [indirizzo_IP_server | nome_host]
Per un indirizzo IP del server non è possibile specificare un carattere jolly.
Service /index.html /ics/api/bin/icsext05.so:serve_req Service /cgi-bin/hexcalc* /ics/api/calculator:HEXcalc*
Nessuno
Utilizzare questa direttiva per specificare un codice di interruzione per le richieste URL. Se si utilizza un codice di interruzione in una richiesta, Caching Proxy valuta solo i caratteri che precedono questo codice quando elabora la richiesta e stabilisce se il risultato è già memorizzato nella cache. Quando viene definito più di un codice di interruzione, Caching Proxy confronta gli URL in entrata con i codici di interruzione nell'ordine in cui questi si trovano nel file ibmproxy.conf.
SignificantURLTerminator stringa_terminazione
SignificantURLTerminator &.
In questo esempio, le due richieste che seguono sono considerate identiche.
http://www.exampleURL.com/tx.asp?id=0200&.;x=004;y=001 http://www.exampleURL.com/tx.asp?id=0200&.;x=127;y=034
Nessuno
Utilizzare questa direttiva per impostare il server SMTP utilizzato dalla routine sendmail interna in Caching Proxy per Windows. Le seguenti due direttive devono essere impostate per questa routine: WebMasterEMail -- Imposta un indirizzo e-mail per ricevere i report di server selezionati e WebMasterSocksServer (solo Windows) -- Imposta un server socks pre la routine sendmail.
SMTPServer indirizzo IP o nome host del server SMTP
SMTPServer mybox.com
Nessuno
Utilizzare questa direttiva per abilitare o disabilitare il supporto SNMP.
SNMP {on | off}
SNMP off
Utilizzare questa direttiva per definire la password tra l'agente secondario DPI (Distributed Protocol Interface) del server Web e l'agente SNMP. Il nome della comunità SNMP autorizza un utente a visualizzare le variabili relative alle prestazioni monitorate da SNMP per una comunità di server prescelta. L'amministratore di sistema definisce le variabili da cui i server possono essere visualizzati quando viene specificata una password. Se si modifica il nome della comunità SNMP, assicurarsi di aver modificato anche il nome della comunità specificato nel file /etc/snmpd.conf.
SNMPCommunity nome
SNMPCommunity public
Utilizzare questa direttiva per memorizzare nella cache il contenuto su una richiesta protetta quando si utilizza un proxy inverso. Questa direttiva configura la memorizzazione nella cache di tutte le connessioni al server proxy, sia le connessioni client che quelle con un server di contenuti di back-end.
SSLCaching {on | off}
SSLCaching off
Utilizzare questa direttiva per specificare le etichette chiave che consentono al proxy di determinare quale certificato inviare al client, quando Caching Proxy funge da unico proxy inverso per più domini che offrono i propri certificati SSL, e di indicare al server proxy se richiamare o meno un certificato PKI lato client per l'autenticazione client.
Utilizzando la direttiva SSLCertificate, Caching Proxy può distinguere un certificato emesso da una CA (certification authority) da un certificato autofirmato. Tuttavia, accettando il certificato emesso dalla CA (opzione ClientAuthRequired), l'utilizzo di questa direttiva consente agli utenti non autorizzati di ottenere l'accesso al server proxy. Quando si utilizza l'opzione ClientAuthRequired sulla direttiva SSLCertificate, è possibile utilizzare l'opzione dell'espressione logica per determinare gli utenti che possono accedere al canale SSL.
Quando un'espressione logica viene aggiunta alla direttiva SSLCertificate, Caching Proxy estrae i valori dal certificato client e calcola l'espressione logica. Se l'espressione è soddisfatta con i valori nel certificato client, allora Caching Proxy concede al client di utilizzare la connessione SSL altrimenti la connessione viene terminata e chiusa.
SSLCertificate IP/nomehost server etichettacertificato [NoClientAuth | ClientAuthRequired espressione-logica]
L'opzione dell'espressione logica è valida solo se utilizzata con l'opzione ClientAuthRequired. Quando un'espressione logica viene aggiunta alla direttiva SSLCertificate, Caching Proxy estrae i valori dal certificato client e calcola l'espressione logica. Se l'espressione è soddisfatta con i valori nel certificato client, allora Caching Proxy concede al client di utilizzare la connessione SSL altrimenti la connessione viene terminata e chiusa.
SSLCertificate www.abc.com ABCCert SSLCertificate 204.146.167.72 intABCCert SSLCertificate www.xyz.com XYZCert ClientAuthRequired SSLCertificate www.xyz.com XYZCert ClientAuthRequired CN="valid.user.common.name.pattern" && (L="accepted.location.pattern" || C!="not.valid.country.pattern")
Nessuno
Queste informazioni sono valide solo per le configurazioni di proxy inverso.
Utilizzare questa direttiva per indicare al server proxy la presenza di una scheda crittografica installata e per specificarla.
Su AIX, per poter supportare IBM 4960 PCI Cryptographic Accelerator Card, fare riferimento a PKCS11DefaultCert, PKCS11DriverPath, PKCS11TokenPassword -- Supporta IBM 4960 PCI Cryptographic Accelerator Card (solo AIX).
SSLCryptoCard {rainbowcs | nciphernfast} {on | off}
SSLCryptoCard rainbowcs on
Nessuno
Utilizzare questa direttiva per specificare che Caching Proxy è in ascolto sulla porta 443 per ricevere richieste protette.
SSLEnable {on | off}
SSLEnable off
Utilizzare questa direttiva per specificare la porta destinata alle richieste HTTP trasformate in richieste HTTPS da Caching Proxy mediante l'implementazione di SSL. Specificare una porta diversa dalla porta principale HTTP 80 o SSL 443.
SSLForwardPort numero porta
SSLForwardPort 8888
Nessuno
Utilizzare questa direttiva per disabilitare i thread listener per le richieste HTTP standard (normalmente le porte 80 e 8080) quando SSL (normalmente la porta 443) è abilitato.
SSLOnly {on | off}
SSLOnly off
Utilizzare questa direttiva per specificare la porta di ascolto HTTPS diversa dalla porta HTTPS 443 predefinita di ibmproxy.
SSLPort valore porta
Dove valore porta è un numero intero maggiore di 0. Inoltre, valore porta deve essere consentito dal sistema operativo e non deve essere utilizzato da altre applicazioni.
SSLPort 8443
443
Queste informazioni sono valide solo per le configurazioni di proxy diretto.
Impostando questa direttiva su on, è possibile eseguire l'operazione di tunnel SSL su qualsiasi porta sul server di destinazione. Se si imposta su off, l'operazione di tunnel SSL è consentita esclusivamente su determinate porte specificate nelle regole Proxy. Se non sono disponibili regole Proxy per operazioni di tunnel SSL, e la direttiva SSLTunneling è impostata su off, allora tale operazione non è consentita. Se la direttiva SSLTunneling è impostata su on, è necessario abilitare anche il metodo CONNECT, mediante la direttiva Enable.
Questa direttiva va abilitata se si utilizza Caching Proxy come proxy diretto. Quando Caching Proxy viene utilizzato come proxy inverso, la disabilitazione di questa direttiva (impostazione predefinita) consente di proteggere i punti deboli del tunnel SSL da attacchi.
Per ulteriori informazioni, fare riferimento a Tunneling SSL.
SSLTunneling {on | off}
SSLTunneling off
Utilizzare questa direttiva per specificare la versione di SSL da utilizzare: V2, V3 o tutte le versioni. Impostare questa direttiva su V2 se si utilizzano server che non sono in grado di supportare la versione 3 di SSL.
SSLVersion {SSLV2 | SSLV3 | all}
SSLVersion SSLV3
Utilizzare questa direttiva per specificare, in secondi, il tempo in cui una sessione SSL della versione 2 rimane in attesa senza eseguire attività prima della scadenza della sessione.
SSLV2Timeout secondi
dove secondi rappresenta un valore compreso tra 0 e 100.
SSLV2Timeout 100
Utilizzare questa direttiva per specificare, in secondi, il tempo in cui una sessione SSL della versione 3 rimane in attesa senza eseguire attività prima della scadenza.
SSLV3Timeout secondi
dove secondi rappresenta un valore compreso tra 1 e 86400 secondi (ossia, un giorno).
SSLV3Timeout 100
Utilizzare questa direttiva per specificare se si desidera che il server distingua tra caratteri maiuscoli e minuscoli quando i suffissi file vengono confrontati con modelli di suffissi sulle direttive AddClient, AddCharSet, AddType, AddEncoding e AddLanguage. Per impostazione predefinita, il server non distingue tra caratteri maiuscoli e minuscoli.
SuffixCaseSense {on | Off}
SuffixCaseSense Off
Utilizzare questa direttiva per fare in modo che Caching Proxy memorizzi nella cache più di una variante di una risorsa (URI), in base all'intestazione HTTP Vary.
Quando la direttiva SupportVaryHeader è abilitata, il proxy crea un ID cache basato sull'URI e sui valori dell'intestazione selezionata nella richiesta client.
I nomi delle intestazioni selezionate vengono specificati nell'intestazione Vary inviata in una precedente risposta del server. Se il server modifica la serie di nomi intestazione selezionati per una risorsa, tutti gli oggetti precedenti memorizzati nella cache per la risorsa verranno eliminati dalla cache del proxy.
Questa direttiva può essere utilizzata con la direttiva RegisterCacheIdTransformer (RegisterCacheIdTransformer -- Memorizza nella cache più di una variante di una risorsa basata sull'intestazione Cookie).
Quando si utilizzano entrambe le direttive, il proxy crea un trasformatore ID cache interno basato sull'intestazione Vary dell'intestazione richiesta del server e del client. In questo modo, il proxy può generare identificativi cache univoci per diverse coppie richiesta/risposta, anche se gli URI richiesti sono gli stessi.
Gli oggetti dello stesso URI memorizzati nella cache hanno una propria durata predefinita, a seconda delle intestazioni Expire e Cache-Control nelle impostazioni relative a richieste/risposte o in altre impostazioni di configurazione. Se viene utilizzato il plugin Dynacache, tutte le presentazioni multiple associate allo stesso URI non sono più valide nella cache del proxy.
SupportVaryHeader {on | off}
In questo esempio, le seguenti direttive sono abilitate e configurate in ibmproxy.conf, come di seguito:
SupportVaryHeader on RegisterCacheIdTransformer Cookie UserGroup
Il client Guest accede al server proxy con
URI [<code>] http://www.dot.com/group.jpg [</code>]
e la seguente richiesta/risposta:
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 .......
Quindi, il client Admin accede al server proxy con lo stesso URI
http://www.dot.com/group.jpg
e la seguente richiesta/risposta:
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 .......
Come risultato, se le risposte sono memorizzabili, il server proxy genere due differenti ID cache:
1. CacheID(URI, "Guest", "en_US") 2. CacheID(URI, "Admin", "fr_FR")
Il server proxy memorizza nella cache due diverse varianti della risposta inviata dal server. In seguito, quando un client richiede la risorsa (.../group.jpg), con una combinazione di valori di preferenza lingua e gruppo utente, il server proxy richiama e supporta la variante appropriata della risorsa dalla cache.
SupportVaryHeader off
Utilizzare questa direttiva per abilitare il protocollo TLS versione 1 nelle connessioni SSL. Dopo aver attivato questa direttiva, la connessione SSL controlla innanzitutto il protocollo TLS, quindi il protocollo SSLv3, infine il protocollo SSLv2.
TLSV1Enable {on | off}
TLSV1Enable on
Nessuno
Utilizzare questa direttiva per specificare una funzione applicativa personalizzata che il server richiama durante la fase Manipolazione dei dati. Questo codice fornisce tre funzioni applicative:
È possibile avere più direttive Transmogrifier attive per ciascuna istanza del server.
Transmogrifier /percorso/file:nome_funzione:nome_funzione:nome_funzione
Transmogrifier /ics/bin/icsext05.so:open_data:write_data:close_data
Nessuno
Utilizzare questa direttiva per inviare un messaggio al client per informarlo che i dati:
transmogrifiedwaning {yes|no}
Si
Queste informazioni sono valide solo per le configurazioni di proxy diretto.
Solo su sistemi Linux, utilizzare questa direttiva per specificare se il server può essere eseguito come server proxy trasparente.
Quando la direttiva TransparentProxy è impostata su on, la direttiva BindSpecific viene ignorata e assume il valore off. Dal momento che la maggior parte del traffico HTTP utilizza la porta 80, si consiglia di configurarla tra le altre.
TransparentProxy {on | off} Porta 80
TransparentProxy off
Se viene utilizzato il firewall IPCHAIN, l'abilitazione della direttiva non è sufficiente per configurare correttamente il proxy trasparente. Se viene utilizzato il firewall IPTABLES, allora è necessario aggiungere la regola del firewall IPTABLES manualmente.
Se si utilizza il firewall IPTABLES, quando è abilitata la direttiva TransparentProxy e prima di avviare il server proxy, emettere il seguente comando per aggiungere la regola del firewall a IPTABLES:
iptables -t nat -A PREROUTING -i interfaccia-rete -p tcp --dport 80 -j REDIRECT --to-port porta-ascolto-ibmproxy
Se si assume che il firewall e il server proxy si trovino sulla stessa macchina, questa regola indica al firewall IPTABLES di indirizzare tutto il traffico TCP per la porta 80 alla porta di ascolto del proxy locale. La regola può essere aggiunta anche nella configurazione IPTABLES. Ciò consente il caricamento automatico della regola al riavvio del sistema.
Dopo aver avviato il proxy trasparente, se si desidera arrestare il server Caching Proxy, è necessario emettere anche il seguente comando come root:
ibmproxy -unload
Sui sistemi Linux, questo comando elimina le regole firewall di reindirizzamento. Se non si emette questo comando in seguito all'arresto del server, la macchina accetterà richieste di cui non è destinataria.
Utilizzare questa direttiva per specificare il server proxy aggiornato dall'agente cache. La direttiva è obbligatoria se l'agente cache deve aggiornare un server proxy diverso da quello locale su cui l'agente cache è in esecuzione. Facoltativamente, è possibile specificare la porta.
Sebbene l'agente cache possa aggiornare la cache su un altro server, non può richiamare il log accessi cache da quella macchina. Perciò, se la direttiva UpdateProxy specifica un host diverso dall'host locale, la direttiva LoadTopCached viene ignorata.
UpdateProxy nome_host_completo_server_proxy
UpdateProxy proxy15.ibm.com:1080
Nessuno
Utilizzare questa direttiva per specificare il numero o il nome utente assunto dal server prima di accedere ai file.
Se la direttiva viene modificata, è necessario arrestare manualmente il server, quindi riavviarlo, per convalidare le modifiche. Il server non riconosce la modifica se viene solamente riavviato. Fare riferimento a Avvio e arresto di Caching Proxy.
UserId {nome_ID | numero}
AIX, Linux, Solaris: UserId nobody
HP-UX: UserId www
Questa direttiva elenca la specifica di codifica disponibile per SSL versione 2.
V2CipherSpecs specifica
I valori accettabili prevedono qualsiasi combinazione di quanto segue. Il valore None può essere utilizzato due volte.
None (SSL è disabilitato per impostazione predefinita.)
Questa direttiva elenca le specifiche di codifica disponibili per SSL versione 3.
Se la direttiva FIPSenable è impostata su "on", la direttiva V3CipherSpecs verrà ignorata. Per ulteriori informazioni, fare riferimento a FIPSEnable -- Abilita le crittografie approvate FIPS (Federal Information Processing Standard) per SSLV3 e TLS.
V3CipherSpecs specifica
Tra i valori possibili sono inclusi:
None (SSL è disabilitato per impostazione predefinita.)
Utilizzare questa direttiva per impostare un indirizzo e-mail su cui ricevere report di Caching Proxy selezionati, ad esempio, una notifica 30 giorni prima della scadenza di un certificato SSL. Su sistemi Linux e UNIX, deve essere in esecuzione un processo sendmail. Per sistemi Windows, il processo sendmail è integrato in Caching Proxy, pertanto non è necessario alcun server di posta esterno; tuttavia, è necessario impostare due altre direttive: WebMasterSocksServer (solo Windows) -- Imposta un server socks per la routine sendmail e SMTPServer (solo Windows) -- Imposta un server SMTP per la routine sendmail.
WebMasterEMail indirizzoemailwebmaster
WebMasterEmail webmaster@computer.com
WebMasterEmail webmaster
Utilizzare questa direttiva per impostare il server SMTP utilizzato dalla routine sendmail interna in Caching Proxy per Windows. Le seguenti due direttive devono essere impostate per questa routine: WebMasterEMail -- Imposta un indirizzoe-mail per ricevere i report di server selezionati e SMTPServer (solo Windows) -- Imposta un server SMTP per la routine sendmail.
WebMasterSocksServer indirizzo IP o nome host del server socks
WebMasterSocksServer socks.mybox.com
Nessuno
Utilizzare questa direttiva per specificare il nome di un file di benvenuto che il server ricerca per rispondere alle richieste che non contengono uno specifico nome file. È possibile creare un elenco di file di benvenuto inserendo più occorrenze di questa direttiva nel file di configurazione.
Per le richieste che non contengono un nome file o un nome directory, il server ricerca sempre, nella directory root dei file, un file corrispondente a un nome specificato su una direttiva Welcome. In caso di corrispondenza, il file viene restituito al richiedente.
Se il server riscontra più di una corrispondenza tra i file di una directory e i nomi file sulle direttive Welcome, l'ordine delle direttive Welcome determina quale file verrà restituito. Il server utilizza la direttiva Welcome più vicina all'inizio del file di configurazione.
Welcome nome_file [indirizzo_IP_server | nome_host]
È possibile specificare un indirizzo IP (ad esempio, 240.146.167.72 ), o un nome host (ad esempio, hostA.bcd.com).
Questo parametro è opzionale. Senza questo parametro, il server utilizza la direttiva per tutte le richieste a prescindere dall'indirizzo IP su cui è stata ricevuta la richiesta o dal nome host negli URL.
Per un indirizzo IP del server non è possibile specificare un carattere jolly.
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
Queste impostazioni predefinite si trovano nell'ordine utilizzato dalla configurazione predefinita:
Welcome Welcome.html Welcome welcome.html Welcome index.html Welcome Frntpage.html