Esta edición se aplica a:
y a todos los releases y modificaciones posteriores hasta que se indique lo contrario en nuevas ediciones.
Realice el pedido de las publicaciones a través del representante de IBM o de la sucursal de IBM que presta servicio en su localidad.
Este prefacio describe el objetivo y los usuarios de destino de esta publicación, cómo esta organizada, las características de accesibilidad, las convenciones y terminología y los documentos relacionados.
El manual Guía de administración de Caching Proxy se ha escrito para aquellos administradores de red y de sistemas expertos que estén familiarizados con sus sistemas operativos y con el suministro de servicios de Internet. No es necesario tener conocimientos previos de Caching Proxy.
Esta publicación no está diseñada para dar soporte a releases anteriores de Caching Proxy.
Esta documentación utiliza los siguientes convenios tipográficos y de teclas.
Convenio | Significado |
---|---|
Negrita | Cuando se hace referencia a interfaces gráficas de usuario (las GUI), se indican en negrita menús, elementos de los menús, etiquetas, botones, iconos y carpetas. También puede utilizarse para enfatizar nombres de mandatos que, de lo contrario, podrían confundirse con el texto de alrededor. |
Monoespaciado | Indica texto que es necesario entrar en un indicador de mandatos. Además, el monoespaciado indica texto que aparece en la pantalla, ejemplos de código y extractos de archivos. |
Cursiva | Indica valores de variable que debe proporcionar el usuario (por ejemplo, el usuario facilitará el nombre de un archivo para NombreArchivo). La cursiva también indica énfasis y los títulos de manuales. |
Control-x | Donde x es el nombre de una tecla, indica una secuencia de Control-carácter. Por ejemplo, Control-c significa pulsar y mantener pulsada la tecla Control mientras se pulsa la tecla c. |
Intro | Se refiere a la tecla etiquetada con la palabra Intro o con la flecha hacia la izquierda. |
% | Representa el indicador de shell de mandatos de Linux y UNIX para un mandato que no requiere privilegios root. |
# | Representa el indicador de shell de mandatos de Linux y UNIX de un mandato que requiere privilegios root. |
C:\ | Representa el indicador de mandatos de Windows. |
Entrada de mandatos | Cuando se le indique que "entre" o "emita" un mandato, escriba el mandato y luego pulse Intro. Por ejemplo, la instrucción "Entre el mandato ls" significa que debe escribir ls en un indicador de mandatos y, después, pulsar Intro. |
[ ] | Encierran elementos opcionales en las descripciones de sintaxis. |
{ } | Encierran listas de las que debe elegirse un elemento en las descripciones de sintaxis. |
| | Separa elementos en una lista de opciones encerradas entre los signos { } (llaves) en las descripciones de sintaxis. |
... | Los puntos suspensivos que aparecen en las descripciones de sintaxis indican que es posible repetir el elemento anterior una o más veces. Los puntos suspensivos que aparecen en los ejemplos indican que se ha omitido información en el ejemplo para una mayor brevedad. |
Las características de accesibilidad ayudan al usuario que tiene discapacidades físicas, como por ejemplo una movilidad restringida o una visión limitada, a utilizar satisfactoriamente los productos de software. Éstas son las principales características de accesibilidad en WebSphere Application Server, Versión 6.1:
Sus comentarios son importantes para ayudarnos a proporcionar la información más precisa y de la mayor calidad posible. Si desea hacer algún comentario sobre esta publicación o cualquier otra documentación acerca de Edge Components de WebSphere Application Server:
Esta parte proporciona una visión general del componente Caching Proxy, las instrucciones para utilizar los formularios de Configuración y Administración y el Asistente de configuración, las instrucciones para editar manualmente el archivo ibmproxy.conf y los procedimientos para iniciar y detener el servidor proxy.
Esta parte contiene los siguientes temas:
Utilización de los formularios de Configuración y Administración
Utilización del Asistente de configuración
Edición manual del archivo ibmproxy.conf
Inicio y detención de Caching Proxy
Actuando como proxy de retorno o como proxy de reenvío, Caching Proxy intercepta las peticiones de datos de un cliente, recupera la información solicitada de las máquinas que alojan contenidos y devuelve esos contenidos al cliente. Habitualmente, las peticiones se refieren a documentos que se almacenan en máquinas de servidor web (también llamadas servidores de origen o sistemas principales que alojan contenidos) y se entregan mediante el HTTP (Protocolo de transferencia de hipertexto). No obstante, es posible configurar Caching Proxy de forma que maneje otros protocolos, tales como FTP (Protocolo de transferencia de archivos) y Gopher.
Antes de entregarlos al peticionario, el Caching Proxy almacena en una antememoria local los contenidos que pueden colocarse en antememoria. Entre los ejemplos de contenidos que pueden colocarse en antememoria se incluyen las páginas Web estáticas y los archivos JPS (JavaServer Pages) con fragmentos que se generan dinámicamente pero que cambian con poca frecuencia. La antememoria permite a Caching Proxy satisfacer las peticiones subsiguientes que se refieren a los mismos contenidos entregándolos directamente desde la antememoria local, lo cual es mucho más rápido que recuperarlos otra vez del sistema principal que aloja contenidos.
IMPORTANTE: Caching Proxy está disponible en todas las instalaciones de Edge Components, con las excepciones siguientes:
Las configuraciones básicas de proxy son el proxy de retorno y el proxy de reenvío.
Por omisión, Caching Proxy se configura como un servidor de proxy de retorno. En una configuración de proxy de retorno, un servidor proxy se encuentra entre uno o más servidores de contenido e Internet. Acepta peticiones de clientes Internet para el contenido almacenado en el sitio inicial del servidor proxy. El servidor proxy aparece ante el cliente como el servidor de origen (contenido); el cliente no sabe que la petición se ha enviado a otro servidor.
Como alternativa, puede configurar Caching Proxy como servidor proxy de reenvío. Sin embargo, los navegadores de cliente deben configurarse individualmente para utilizar el proxy. En una configuración de proxy de reenvío, un servidor proxy se encuentra entre el cliente e Internet. Caching Proxy reenvía la petición de un cliente a los sistemas principales de contenido situados en Internet, guarda en antememoria los datos recuperados y los entrega al cliente.
Los siguientes cambios en el archivo de configuración ibmproxy.conf deben realizarse para habilitar la configuración del proxy de reenvío:
Proxy http:* Proxy ftp:* Proxy gopher:*
SSLTunneling OnPara obtener más información en el túnel SSL, consulte Configuración de túneles SSL.
Enable CONNECT OutgoingPorts Allo bien
Enable CONNECT OutgoingPorts 443
para obtener información sobre el formato y las opciones disponibles para el método Enable CONNECT, consulte Configuración de túneles SSL.
Realizar estos cambios permite que el proxy de reenvío haga lo siguiente:
Una variante del Caching Proxy de reenvío es un Caching Proxy transparente. En este rol, Caching Proxy realiza la misma función que un Caching Proxy de reenvío básico, pero lo hace sin que el cliente sea consciente de su presencia. La configuración de Caching Proxy transparente sólo está soportada en sistemas Linux.
Como sucede con el Caching Proxy de reenvío normal, el Caching Proxy transparente se instala en una máquina junto a Internet o la pasarela, pero los programas de navegador de cliente no están configurados para dirigir peticiones a un Caching Proxy de reenvío. Los clientes no son conscientes de que existe un proxy en la configuración. Sin embargo, un direccionador está configurado para interceptar peticiones de cliente y dirigirlas al Caching Proxy transparente.
Para obtener información sobre la directiva de esta configuración, consulte TransparentProxy -- Habilitar el proxy transparente en Linux.
La publicación Caching Proxy Administration Guide Versión 6.1 incluye características recién documentadas y actualizaciones correctoras.
Las nuevas características más importantes son:
Para obtener información sobre la configuración de un proxy de reenvío, consulte Proxy de reenvío.
Para obtener información sobre la directiva de proxy transparente (de reenvío), consulte TransparentProxy -- Habilitar el proxy transparente en Linux.
Para obtener información sobre estos métodos, consulte Habilitar métodos WebDAV, métodos MS Exchange y métodos definidos por el usuario.
Para obtener información sobre estas directivas, consulte CompressionFilterAddContentType -- Especificar el tipo de contenido de la respuesta HTTP que desea comprimir y CompressionFilterEnable -- Habilitar el filtro de compresión para comprimir las respuestas HTTP.
Para obtener información sobre esta directiva, consulte NoCacheOnRange -- Especificar sin colocación en antememoria para peticiones de rango.
Para obtener información sobre esta directiva, consulte OptimizeRuleMapping -- Optimizar el proceso de correlación de regla para las peticiones entrantes cuando aumenta el número de reglas.
MapQuery es similar a la directiva Map y utiliza la vía de acceso y la serie de consulta para cumplir la regla.
Para obtener información sobre esta directiva, consulte MapQuery -- Cambiar las peticiones coincidentes a una nueva serie de petición, utilizando la serie de vía de acceso de petición y consulta para cumplir la regla.
Para obtener información sobre esta directiva, consulte RuleCaseSense -- Correlaciona peticiones de los URL de aplicación que no son sensibles a mayúsculas y minúsculas.
Para obtener información sobre estas directivas, consulte PKCS11DefaultCert, PKCS11DriverPath, PKCS11TokenPassword -- Da soporte a la tarjeta IBM 4960 PCI Cryptographic Accelerator Card (sólo AIX).
Para obtener información sobre la opción de expresión lógica en esta directiva, consulte SSLCertificate -- Especificar etiquetas de clave para certificados.
Caching Proxy proporciona directivas que requieren la coincidencia de patrones adicional en tiempo de ejecución. Para mejorar el rendimiento de Caching Proxy, puede utilizar estas directivas como opciones de la regla Proxy o ProxyWAS. Para obtener más información sobre estas opciones adicionales para la regla Proxy o ProxyWAS, consulte Proxy: especificar los protocolos de proxy o el proxy de retorno.
Caching Proxy se facilita con formularios HTML que pueden servirse a los clientes que lo soliciten y utilizarse para configurar servidor proxy. Estos formularios ejecutan programas CGI que editan el archivo de configuración de servidor proxy local, ibmproxy.conf. Para utilizar estos formularios, el servidor proxy debe estar ejecutándose y estar configurado para pasar los formularios desde el directorio local donde residen.
Por omisión, el Caching Proxy se instala con las directivas Pass incluidas en el archivo ibmproxy.conf que permiten el acceso a los formularios de Configuración y Administración. Cuando un cliente solicita la página de inicio por omisión de este servidor proxy, se sirve Frntpage.html. Esta página contiene un enlace de hipertexto con la página de inicio de los formularios de Configuración y Administración, wte.html.
Los formularios de Configuración y Administración están protegidos y requieren la autenticación de cliente antes de que se sirvan. Para obtener las instrucciones sobre cómo establecer el ID y la contraseña del administrador, consulte Establecimiento de la contraseña de administrador.
Un navegador Web utilizado para acceder a los formularios de Configuración y Administración debe dar soporte a los siguientes elementos:
Los navegadores recomendados son Mozilla y Firefox (para los sistemas Linux, UNIX y Windows) e Internet Explorer (para los sistemas Windows). Para obtener versiones específicas de los navegadores Mozilla, Firefox e Internet Explorer, consulte el siguiente sitio Web y siga los enlaces a la página Web del software soportado: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Para acceder a los formularios de Configuración y Administración:
http://su.nombre.servidor[:puerto][/directorio][/página.html]donde
Los cambios de configuración solicitados se han completado satisfactoriamenteSi no se acepta la entrada, aparecerá un mensaje de error en el marco superior que indicará que no se han aceptado los valores.
Después de instalar los paquetes de Caching Proxy, debe crear una identificación y contraseña del administrador para acceder a los formularios de Configuración y Administración. La configuración de servidor proxy por omisión autentica a los usuarios que soliciten los formularios de Configuración y Administración mediante el archivo de contraseñas webadmin.passwd situado en el directorio /opt/ibm/edge/cp/server_root/protect/ de los sistemas Linux y UNIX o \Archivos de programa\IBM\edge\cp\etc\ directory en los sistemas Windows. La instalación de paquetes no sobrescribe ningún archivo webadmin.passwd existente.
Utilice los siguientes mandatos para añadir una entrada de administrador al archivo webadmin.passwd:
# htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwdCuando se le solicite, proporcione al programa htadm un nombre de usuario, una contraseña y un nombre real para el administrador.
cd "\Archivos de programa\IBM\edge\cp\server_root\protect\" htadm -adduser webadmin.passwd"Cuando se le solicite, proporcione al programa htadm un nombre de usuario, una contraseña y un nombre real para el administrador.
Para obtener una descripción detallada del mandato htadm, consulte Mandato htadm.
El Asistente de configuración de Caching Proxy le permite configurar con rapidez un Caching Proxy instalado. Este programa sólo establece las directivas esenciales que son necesarias para modificar el comportamiento de Caching Proxy para actuar como sustituto. El servidor proxy puede requerir configuración adicional.
Para utilizar el Asistente de configuración de Caching Proxy:
En los sistemas Windows: pulse Inicio -> Programas -> IBM WebSphere -> Edge Components -> Caching Proxy -> Asistente de configuración.
En los sistemas Linux y UNIX: especifique el mandato /opt/ibm/edge/cp/cpwizard/cpwizard.sh
Port puerto Proxy /* http://servidor de contenido :puerto
Ejemplos:
Proxy /* http://servidor contenido :443
o bien
Proxy /* https://servidor contenido :443
Limitaciones en los sistemas Linux: los accesos directos del teclado no funcionan con el Asistente de configuración de Caching Proxy.
Caching Proxy puede configurarse manualmente, bien mediante la edición del archivo de configuración ibmproxy, bien mediante los formularios de Configuración y Administración.
El archivo de configuración está formado por las sentencias llamadas directivas. Para modificar la configuración, edite el archivo de configuración modificando las directivas y guarde los cambios. Puede utilizar prácticamente cualquier editor de texto como, por ejemplo, emacs y vi para editar el archivo de configuración.
Los cambios del archivo de configuración entran en vigor al reiniciar el servidor, a menos que haya cambiado una de las directivas identificadas en la Tabla 6. Si ha modificado alguna de las directivas de esa lista, debe detener el servidor y volver a iniciarlo. Para obtener las instrucciones, consulte Inicio y detención de Caching Proxy.
El Apéndice B. Directivas del archivo de configuración describe todas las directivas del archivo de configuración y proporciona información detallada sobre la sintaxis.
Caching Proxy está diseñado para ejecutarse de forma continuada como un proceso en segundo plano con un mínimo de intervención por parte del operador. Generalmente, el servidor proxy se inicia durante el ciclo de arranque de la máquina y únicamente se detiene cuando el mantenimiento lo requiere. El servidor proxy puede iniciarse manualmente si es necesario. Asimismo, se puede pasar una instrucción de reinicio al servidor proxy, que detiene y reinicia el servidor proxy sin interrumpir conexiones de cliente activas.
En los sistemas Linux y UNIX, se coloca un script de inicialización ibmproxy y los enlaces simbólicos asociados en los directorios /etc/ adecuados cuando se instala Caching Proxy. A continuación, esos scripts se integran en las rutinas de arranque y cierre del sistema operativo. Puede modificar los valores de configuración del reinicio automático mediante la edición del script ibmproxy y la modificación de las opciones del mandato ibmproxy.
Es posible que el script de inicialización de Caching Proxy no pueda establecer satisfactoriamente el número máximo deseado de descriptores de archivo debido al límite en todo el sistema Solaris de los descriptores de archivo. Si el número máximo de todo el sistema es inferior al valor del script de inicialización de Caching Proxy, se utiliza el límite de todo el sistema. Puede modificar el límite de los descriptores de archivo para evitar problemas de rendimiento del proxy, que pueden ser el resultado de un valor demasiado bajo (inferior a 1024). Emita el mandato ulimit para visualizar el número de descriptores que estén disponibles en ese momento. Si el valor es inferior a 1024, aumente el límite de descriptor de archivo. Para incrementar el límite de descriptor de archivo a 1024, añada la siguiente línea al archivo /etc/system:
set rlim_fd_cur=0x400
Inhabilitación del arranque y cierre automático
Para inhabilitar el arranque y cierre automático:
En SUSE Linux, elimine los siguientes enlaces con ibmproxy:
Independientemente del método de arranque, el mandato ibmproxy se invoca finalmente, bien directamente desde el indicador de mandatos, bien desde dentro de un script. Para obtener una descripción detallada del mandato ibmproxy, consulte Mandato ibmproxy. Sólo se ofrecen ejemplos de los argumentos utilizados con mayor frecuencia.
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
donde el archivo errors_icons.conf identifica qué iconos se deben utilizar para los tipos de archivo designados al examinar los directorios.
/etc/init.d/ibmproxy start
/usr/sbin/ibmproxy
/usr/sbin/ibmproxy -nobg
Si Caching Proxy se instala como un servicio Windows, se inicia como cualquier otro servicio Windows:
Si Caching Proxy se instala como servicio, puede configurarse para que se arranque automáticamente al iniciar Windows. En ese caso, no es necesario que inicie la sesión antes de que el proxy pueda servir las peticiones. Para que el proxy se inicie automáticamente:
Renovación de la variable de entorno PATH
Si Caching Proxy está marcado como Iniciado en la ventana Servicios, pero el proxy no funciona, es posible que la máquina no se haya reiniciado después de instalar el proxy. Si el servicio de Caching Proxy está establecido para interactuar con el escritorio, un error durante el reinicio también puede provocar que aparezca el siguiente mensaje de error en un recuadro emergente: Error del catálogo de mensajes: No se puede cargar el catálogo de mensajes o no es válido
Se debe reiniciar la máquina para que el valor de la variable de entorno PATH se renueve en el registro de Windows. Si el registro no se renueva, es posible que la variable PATH muestre las vías de acceso de Caching Proxy y GSK7 correctas pero no funcione correctamente.
El problema puede surgir si aparece la vía de acceso para el servicio de sistema de archivos antes de la vía de acceso del servicio de Caching Proxy en la variable de entorno PATH de Windows. La alteración de la variable PATH con el fin de situar los servicios de sistema de archivos próximos al final de la operación de establecimiento puede solucionar este problema.
Este problema no afecta a las unidades remotas controladas por las aplicaciones que no se ejecutan en servicios Windows. Por ejemplo, Caching Proxy puede acceder a las unidades compartidas en otras máquinas Windows que estén visibles mediante una red de área local (LAN).
Al instalar Caching Proxy como una aplicación Windows, el procedimiento de instalación crea una entrada Caching Proxy como submenú del menú Inicio. Para iniciar Caching Proxy como una aplicación, pulse Inicio -> Programas -> IBM WebSphere -> Edge Components -> Caching Proxy.
Este proceso de arranque ejecuta el servidor proxy con los valores actuales de configuración. Si desea especificar otros valores durante el tiempo de arranque, utilice el procedimiento de arranque de mandatos (consulte el apartado siguiente).
Para iniciar el servidor desde cualquier indicador de mandatos DOS o Windows, utilice el mandato ibmproxy. Si no ha cerrado y reiniciado Windows desde que instaló el servidor, especifique el nombre de vía de acceso completo de este mandato del siguiente modo (por omisión):
c:\Archivos de programa\IBM\edge\cp\bin\ibmproxy.exe
El mandato ibmproxy inicia el servidor con los valores actuales de configuración. Si no ha modificado la configuración del servidor desde la instalación, la configuración actual se basa en la información que haya especificado durante la instalación y en las opciones por omisión.
El mandato ibmproxy inicia el servidor como una aplicación, incluso si ha instalado Caching Proxy para que se ejecute como un servicio. Para forzar al servidor a que se ejecute como una aplicación, también puede especificar la opción de mandato -noservice. Las demás opciones de mandato modifican los valores de configuración durante el tiempo de ejecución.
Se pueden ejecutar varias instancias del servidor proxy simultáneamente, pero cada instancia debe escuchar en un puerto independiente. En los sistemas AIX, sólo se puede iniciar una instancia con SRC. Se deben especificar archivos de configuración exclusivos para todas las instancias del servidor ya que el archivo de configuración identifica un número de puerto, que debe ser distinto para cada servidor en una máquina determinada. Para iniciar un instancia adicional del servidor (cuando uno como mínimo ya está en ejecución), especifique el siguiente mandato:
ibmproxy -r otro_archivo_configuración
ibmproxy -noservice -r otro_archivo_configuración
donde otro_archivo_configuración es un archivo de configuración exclusivo.
Al iniciar varias instancias del servidor, registre el ID de proceso que se visualiza para cada instancia. Estos ID son necesarios para detener instancias específicas del servidor.
Para detener el servidor:
Método de inicio | Método de parada |
Desde /etc/inittab (en AIX) | Especifique stopsrc -s ibmproxy |
Desde /sbin/init.d (en HP-UX) | Especifique /sbin/init.d/ibmproxy stop |
Desde /etc/rc.d/init.d (en Linux) | Especifique /etc/rc.d/init.d/ibmproxy stop |
ibmproxy |
Para detener todos los servidores de esta máquina: especifique killall ibmproxy |
ibmproxy -nobg | Especifique ctrl-c |
ibmproxy -r -otro_archivo_configuración (en AIX) | Especifique stopsrc -s ibmproxy -p id_proceso |
ibmproxy -r -otro_archivo_configuración (en Linux) |
|
ibmproxy -unload
Para detener el servidor en un indicador de raíz, especifique:
Puede experimentar las siguientes limitaciones al utilizar los mandatos de cierre:
En los sistemas AIX, HP-UX y Linux, los mandatos para detener el sistema de Caching Proxy en ocasiones sólo cierran el proceso de Caching Proxy. El mandato de AIX que ocasiona este comportamiento es el mandato stopsrc -s ibmproxy. El mandato de HP-UX y Linux que ocasiona este comportamiento es el mandato ibmproxy -stop.
Es posible que el proceso PACD, que se utiliza por el servidor LDAP, continúe en ejecución después de cerrar el servidor proxy. El proceso PACD se puede cerrar de modo seguro mediante el mandato kill tal como se muestra a continuación:
kill -15 PACD_process_ID
La emisión del mandato ibmproxy -stop en un sistema Solaris no tiene el mismo efecto que el mandato en los demás sistemas operativos. Debido a una limitación del código Solaris, no se ejecuta el paso de plug-in de terminación del servidor cuando se utiliza ibmproxy -stop en las plataformas Solaris.
Esta limitación tiene implicaciones para el software del servidor proxy y los plug-ins implementados por el cliente.
Es posible que el proceso PACD, que el servidor LDAP utiliza, continúe en ejecución después de que el servidor proxy se cierre. El proceso PACD se puede cerrar de modo seguro mediante el mandato kill tal como se muestra a continuación:
kill -15 PACD_process_ID
Puede detener el servidor Caching Proxy del mismo modo en que detiene los demás programas Windows.
Si el proxy se instala como un servicio:
Si el proxy no está instalado como un servicio, lleve a cabo cualquiera de las acciones siguientes para detener Caching Proxy:
Después de modificar la configuración del servidor mediante los formularios de Configuración y Administración o la edición del archivo ibmproxy.conf, debe reiniciar el servidor antes de que los cambios entren en vigor. En la mayoría de los casos, puede reiniciar el servidor sin detenerlo previamente. Pero algunos valores no se renuevan mediante un simple reinicio. Para obtener más información, consulte la Tabla 6.
Para reiniciar el servidor sin detenerlo primero, pulse el botón Reiniciar en cualquier formulario de Configuración y Administración o escriba lo siguiente: ibmproxy -restart
En este apartado se describe cómo el componente Caching Proxy interactúa con el sistema operativo, el hardware del sistema y la red. Asimismo, proporciona los procedimientos para configurar esta interacción. El administrador del sistema es quien gestiona generalmente estos elementos de la configuración del servidor proxy, que deben coordinarse con los recursos de red como, por ejemplo, las direcciones IP y los nombres de sistema principal, además de con los recursos del sistema, como la memoria disponible y los ciclos de la CPU.
Esta parte contiene los siguientes temas:
Establecimiento de la propiedad de procesos
Ajuste del proceso del servidor proxy
Caching Proxy generalmente se ejecuta como un proceso en segundo plano en un sistema principal que esté configurado para actuar como un servidor de red. Este proceso está asociado con (enlazado con) una o todas las direcciones IP (Protocolo Internet) activas del sistema principal. Puede escuchar varios protocolos de Internet como, por ejemplo, FTP y HTTP en puertos específicos y realizar acciones a partir de estas peticiones de acuerdo con su configuración de comportamiento. Para obtener más información, consulte Configuración del comportamiento de Caching Proxy.
Por omisión, Caching Proxy adopta el nombre del sistema principal. Puede sobrescribir este comportamiento por omisión especificando deliberadamente un nombre de sistema principal para el servidor proxy. Para enlazar Caching Proxy con una dirección IP específica, el nombre de sistema principal del servidor proxy debe modificarse para que sea idéntica a esa dirección IP.
El nombre de sistema principal del servidor proxy no tiene un efecto sobre cómo se resuelve el tráfico de clientes. El servidor proxy no compara su propio nombre de sistema principal con el valor del argumento de nombre de sistema principal de la cabecera de la petición HTTP. El nombre de sistema principal del servidor proxy se incorpora ocasionalmente en las páginas de contenido local generadas dinámicamente como, por ejemplo, los mensajes de error. También se devuelve al cliente solicitado como el valor del argumento Via de la cabecera HTTP.
El servidor proxy puede configurarse para que sustituya el nombre de sistema principal del cliente que lo solicite por el nombre de sistema principal del servidor proxy antes de pasar la petición al servidor de destino. Esta acción fuerza al servidor de destino a mantener el canal de comunicación a través del servidor proxy, en lugar de establecer una conexión directa con el cliente.
Defina el proceso del servidor proxy especificando la ubicación física de los archivos del servidor proxy en el sistema principal, el nombre con el que el servidor proxy se refiere a sí mismo y los puertos en los que escucha como valores de las directivas ServerRoot, Hostname y Port. Si el sistema principal tiene varias direcciones IP, se puede enlazar el servidor proxy con una dirección específica estableciendo el valor de la directiva BindSpecific en On y el valor de la directiva Hostname igual al valor de la dirección IP.
Un puerto de administración proporciona un método de acceso a los formularios de Configuración y Administración y mantenimiento del servidor. Para proporcionar el acceso al servidor proxy mediante el puerto de administración, especifique un valor de la directiva AdminPort. Las peticiones recibidas en el puerto de administración no se colocan en cola con las peticiones recibidas en el puerto estándar. Se pueden escribir normas de correlación para permitir el acceso a los formularios de Configuración y Administración a través de este puerto.
Cuando se habilita la directiva BindSpecific, Caching Proxy se enlaza con el puerto especificado por la directiva Port junto con la dirección IP derivada del valor de la directiva Hostname. El puerto especificado por la directiva AdminPort se enlaza con todas direcciones IP disponibles en el sistema.
Para sobrescribir el nombre por omisión del servidor que se esté ejecutando, como, por ejemplo, IBM-PROXY o IBM_HTTP_SERVER, especifique un valor para la directiva HeaderServerName. Este valor se especifica en el campo del servidor de respuestas HTTP.
Para mejorar el rendimiento del proxy, el valor de la directiva PureProxy puede establecerse en on. Esto inhabilita completamente todas los funciones de colocación en antememoria.
Las siguientes directivas definen el proceso del servidor proxy:
Para obtener más información, consulte el Edición manual del archivo ibmproxy.conf.
Los siguientes formularios de Configuración y Administración editan los valores de las directivas asociadas:
Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.
Cuando un usuario distinto del superusuario root inicia Caching Proxy, aquél mantiene la propiedad de todos los procesos asociados con el servidor proxy. No obstante, si el superusuario root inicia Caching Proxy, una función de ID de usuario establecida en el servidor proxy lee las directiva UserId y GroupId del archivo ibmproxy.conf y modifica la propiedad de los procesos del usuario y grupo especificados. Esta acción se lleva a cabo para limitar el acceso a archivos y proteger el sistema. Si modifica las directivas UserId o GroupId, debe actualizar la propiedad y los permisos de los directorios de anotaciones cronológicas y otros otros archivos como, por ejemplo, una lista de control de acceso (ACL), que utiliza el servidor proxy.
Establezca la propiedad del proceso del servidor proxy especificando la identificación de usuario, identificación de grupo y ubicación del archivo donde el ID de proceso está registrado como valores de las directivas UserID, GroupID y PidFile.
Para forzar que proceso del servidor proxy se ejecute como un proceso en primer plano, establezca el valor de la directiva NoBG en on.
En sistemas Linux:
En los sistemas Linux, sólo a los procesos y hebras responsables de la escucha de conexiones se les modificará la propiedad. Los procesos y hebras responsables de las demás actividades del flujo de trabajo seguirán siendo propiedad del usuario root. Todos los procesos y hebras reciben los números de ID de proceso (PID). El mandato ps enumera todos los ID de proceso, independientemente de si están o no asociados con un proceso o hebra.
Cannot init groups for user nobody, errno: 1Puede ignorar este mensaje de error, porque no afecta a la operación normal de Caching Proxy. Además existe una solución para evitar el mensaje de error, exportando las variables de entorno siguientes antes de iniciar Caching Proxy:
export RPM_FORCE_NPTL=1 export LD_ASSUME_KERNEL=2.4.19:
Las siguientes directivas establecen la propiedad de procesos del servidor proxy:
Para obtener más información, consulte el Edición manual del archivo ibmproxy.conf.
Los siguientes formularios de Configuración y Administración editan los valores de las directivas asociadas:
Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.
Caching Proxy genera una nueva hebra para manejar cada una de las peticiones de cliente. Si no existen hebras disponibles, el servidor proxy mantiene las peticiones hasta que están disponibles más hebras. A medida que aumenta el número de hebras activas, el servidor proxy consume más memoria. Especifique el número máximo de hebras activas como valor de la directiva MaxActiveThreads.
El registro de reserva de escucha es el número de peticiones pendientes para las conexiones de cliente que el servidor anota cronológicamente antes de rechazar las conexiones con nuevos clientes. Debe basar este valor en el número de peticiones que el servidor puede procesar en pocos segundos. Un servidor debe responder a una conexión de cliente antes de que caduque. Especifique el número máximo de conexiones que se pueden mantener en el registro de reserva como el valor de la directiva ListenBacklog.
El servidor proxy puede mantener las conexiones persistentes de cliente/servidor. Con una conexión persistente, el servidor acepta varias peticiones del cliente y envía las respuestas a través de la misma conexión TCP/IP. El uso de conexiones persistentes reduce la latencia de los clientes y la carga de CPU del servidor proxy, con un coste mínimo de un pequeño aumento de la memoria del servidor. No sólo aumenta el rendimiento global cuando el servidor no establece una conexión TCP/IP independiente para cada petición y respuesta, sino que la conexión TCP/IP puede utilizarse con mayor eficacia cuando la conexión es persistente.
La agrupación de conexiones de la parte servidor aplica las ventajas de las conexiones persistentes en la parte servidor, lo que permite la reutilización de las conexiones existentes entre un servidor proxy y los servidores de origen. Todas las conexiones reutilizadas guardan tres paquetes TCP: dos paquetes de protocolo de enlace en tres direcciones para configurar la conexión y uno para cerrarla. Las ventajas de una agrupación de conexiones de la parte servidor incluyen:
Cuando la agrupación de conexiones de la parte servidor está habilitada, se agrupan las conexiones HTTP con los servidores de origen. Las conexiones SSL también se agrupan en las configuraciones donde la directiva SSLEnable del proxy está establecida en on.
Configure cómo mantener la agrupación de conexiones especificando el número máximo de sockets desocupados que se deben conservar por servidor en cualquier momento, el periodo durante el cual el servidor espera antes de finalizar una conexión persistente desocupada y el intervalo durante el cual la recogida de basura busca conexiones caducadas (el valor por omisión es dos minutos).
Defina el periodo de tiempo durante el cual las distintas conexiones permaneces abiertas como valores de las directivas InputTimeout, OutputTimeout, PersistTimeout, ReadTimeout y ScriptTimeout.
Las siguientes directivas gestionan las conexiones con el proceso del servidor proxy:
Para obtener más información, consulte el Edición manual del archivo ibmproxy.conf.
Los siguientes formularios de Configuración y Administración editan los valores de las directivas asociadas:
Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.
Puede mejorar notablemente el rendimiento de Caching Proxy configurando y ajustando el sistema correctamente. A continuación aparecen sugerencias para mejorar la configuración y el ajuste.
Las siguientes directivas afectan al rendimiento del proceso del servidor proxy significativamente.
Los campos de formularios de Configuración y Administración editan los valores de las directivas asociadas:
Examine los servicios o daemons que se estén ejecutando en el sistema y elimine aquellos que no sean necesarios para aumentar la memoria disponible y los ciclos de la CPU. Por ejemplo, si el sistema está ejecutando un servidor Web que únicamente sirve unas pocas páginas Web, se le recomienda que use Caching Proxy como el único servidor Web. Inhabilite los demás servidores Web del siguiente modo:
Asegúrese de que el sistema tiene el suficiente espacio de paginación para que opere correctamente. El sistema necesita el doble de espacio de paginación que la memoria física. Si es posible, amplíe el espacio de paginación a varias unidades físicas. Por ejemplo, un servidor Netfinity 5000 con 512 MB de memoria y cinco unidades SCSI necesita 1 GB de espacio de paginación total con 200 MB en todas las unidades aproximadamente.
Caching Proxy crea y destruye varios archivos durante su funcionamiento. Si el servidor proxy registra los accesos (mediante las anotaciones cronológicas de acceso, anotaciones cronológicas de acceso proxy o anotaciones cronológicas de acceso de antememoria), dirija estas anotaciones cronológicas a sus propios sistemas de archivos de modo que, si las anotaciones cronológicas crecen de forma inesperada, no utilicen el espacio diseñado para otra función (por ejemplo, la antememoria).
Caching Proxy es sensible a las modificaciones de las configuraciones TCP/IP. La reducción de los valores TCP/IP de cualquier sistema operativo puede provocar que el servidor proxy actúe de forma inesperada. Para ser más específicos, si los valores TCP/IP se establecen demasiado bajos, los clientes que se conectan al servidor proxy o los servidores de origen a los que se conecta el proxy pueden restablecer las conexiones. Esto es particularmente cierto en el caso de los clientes que se conectan al servidor proxy mediante una conexión de bajo ancho de banda (56700 bps o inferior). Proceda con cuidado si se deben reducir los parámetros TCP/IP.
El intervalo de tiempo de espera de TCP especifica la duración de tiempo que un socket espera un paquete FIN del remitente antes de cerrarse a la fuerza. En los entornos de carga alta, es posible que el servidor proxy parezca atascarse si un gran número de sockets permanecen suspendidos en el estado TIME_WAIT después de que se cierren las conexiones. La reducción del intervalo de tiempo de espera de TCP hará que descienda el número de sockets suspendidos y, en los entornos de carga alta, es posible que evite que el servidor proxy aparente atascarse. Se recomienda que este intervalo se establezca en 5 segundos.
Para establecer el intervalo de tiempo de espera de TCP en 5 segundos
Emita el mandato siguiente:
ndd /dev/tcp -set tcp_time_wait_interval 5000
Utilice el programa de utilidad "sam" para establecer el parámetro de kernel max_thread_proc en 2048 como mínimo.
Emita los siguientes mandatos:
echo "1024 61000" > /proc/sys/net/ipv4/ip_local_port_range echo "5" > /proc/sys/net/ipv4/tcp_fin_timeout
Emita el mandato siguiente:
ndd /dev/tcp -set tcp_time_wait_interval 5000
Edite el archivo /etc/system para que se lea del siguiente modo:
set tcp:tcp_conn_hash_size=8129
debe crearse una entrada de registro para establecer un intervalo de tiempo de espera TCP. Consulte la documentación de Windows para obtener más información.
Varios límites del kernel de Linux son bajos y pueden modificarse. Algunos pueden modificarse mediante el sistema de archivos /proc mientras que los demás requieren la recompilación del kernel.
Nota: el sistema de archivos /proc es virtual, es decir, no existe físicamente en el disco. Por el contrario, actúa como interfaz en el kernel de Linux. Como no existe, los valores de entrada se pierden durante el reinicio. Por lo tanto, incluya los cambios que desea realizar en el sistema de archivos /proc en el archivo /etc/rc.d/rc.local de RedHat o en el archivo /etc/rc.config file de SUSE. Los cambios siempre se activan durante el reinicio.
A continuación se incluyen algunas recomendaciones:
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
Si decide volver a crear el kernel, habilite sólo aquellas opciones que necesite definitivamente. Si no necesita un daemon específico, no lo ejecute.
En los sistemas AIX, el rendimiento de Caching Proxy puede mejorarse utilizando las hebras de ámbito de sistema y permitiendo que las hebras utilicen varios almacenamientos dinámicos. El rendimiento está relacionado con la capacidad de multiproceso del sistema operativo y la planificación de hebras del sistema operativo subyacente. Se puede obtener la mejora del rendimiento estableciendo las siguientes variables de ajuste de hebra del modo siguiente:
export AIXTHREAD_SCOPE=S export SPINLOOPTIME=500 export YIELDLOOPTIME=100 export MALLOCMULTIHEAP=1
Puede establecer estas variables de entorno antes de iniciar /usr/sbin/ibmproxy , o bien puede añadirlas a /etc/rc.ibmproxy si utiliza startsrc -s ibmproxy para iniciar el servidor proxy. Después de ajustar estas variables de ajuste de hebras, la mejora del rendimiento será más evidente en los sistemas SMP. No obstante, en algunos casos, la mejora también puede ser evidente en sistemas de un solo procesador.
Este apartado describe cómo el componente Caching Proxy responde a las peticiones de cliente y proporciona los procedimientos para configurar este comportamiento. Un administrador Web es quien gestiona generalmente estos elementos de la configuración de servidor proxy, que no afectan a los demás procesos del sistema principal u otros sistemas de la red.
Esta parte contiene los siguientes temas:
Gestionar el proceso de peticiones
Gestión del envío del contenido local
Personalización del proceso del servidor
Configuración de las opciones de cabecera
Acerca de la interfaz de programas de aplicación
Cuando Caching Proxy recibe la petición de un cliente, realiza la acción especificada en el campo de método del objeto especificado del campo URL, si se ha habilitado el método solicitado. El servidor proxy resuelve el URL de acuerdo con un conjunto de normas de correlación definidas por el administrador. Es posible que estas normas de correlación indiquen a Caching Proxy que actúe como un servidor Web y recupere el objeto del sistema de archivos local o que actúe como un servidor proxy y recupere el objeto de un servidor de origen.
En este tema se describe cómo habilitar los métodos, definir las normas de correlación y configurar un servidor proxy sustituto.
Las peticiones de cliente dirigidas al servidor incluyen un campo de método que indica la acción que el servidor va a realizar en el objeto especificado.
A continuación aparece una lista de métodos a los que el servidor proxy da soporte y una descripción de cómo responde a una petición que contenga el método cuando éste está habilitado.
Para obtener información sobre el formato y las opciones disponibles para el método Enable CONNECT, consulte Configuración de túneles SSL.
El método POST se designa para manejar la anotación de recursos existentes. Entre los ejemplos se incluye el envío de un mensaje a un tablón de anuncios, un grupo de noticias o lista de correo, o recursos de grupo similares; el paso de un bloque de datos, por ejemplo, de un formulario a un programa de manejo de datos, o la ampliación de una base de datos a través de una operación añadir. En Caching Proxy, el método POST se utiliza para procesar los formularios de Configuración y Administración.
Este método se puede manejar a través de conexiones persistentes.
La habilitación del método PUT permite que los archivos se escriban en Caching Proxy mediante HTTP y FTP. Como PUT permite a los clientes escribir en Caching Proxy, es necesario que utilice las configuraciones de protección de servidor para definir quién puede utilizar PUT y los archivos en los que se puede utilizar PUT. (Consulte el Configuraciones de protección del servidor.)
Las siguientes directivas habilitan los métodos HTTP/FTP:
Para obtener más información, consulte el Edición manual del archivo ibmproxy.conf.
Los siguientes formularios de Configuración y Administración editan los valores de las directivas asociadas:
Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.
Sólo se aplica a configuraciones de proxy de retorno.
Además del soporte de métodos HTTP estándar, Caching Proxy da soporte al reenvío de otros métodos definidos en los RFC o utilizados por algunas aplicaciones. Caching Proxy también da soporte a métodos definidos por el cliente y permite reenviarlos mediante el servidor proxy.
WebDAV (Web-based Distributed Authoring and Versioning) es un conjunto de extensiones del protocolo HTTP que permite editar y gestionar archivos de forma cooperativa en servidores Web remotos. Caching Proxy da soporte a los métodos WebDAV, métodos utilizados por Microsoft Exchange Server y métodos definidos por el usuario (personalizados).
Estos métodos están codificados y se gestionan con las directivas Enable y Disable. Los administradores también pueden utilizar la máscara de método definida en la directiva PROTECT para autorizar el uso de estos métodos.
Métodos WebDAV soportados (RFC 2518): PROPFIND , PROPPATCH , MKCOL, COPY, MOVE, LOCK, UNLOCK, SEARCH
Métodos de MS Exchange soportados: BMOVE, BCOPY, BDELETE, BPROPFIND, BPROPPATCH, POLL, NOTIFY, SUBSCRIBE, UNSUBSCRIBE, ACL, SUBSCRIPTIONS, X_MS_ENUMATTS
Cuando los métodos WebDAV o de MS Exchange Server están habilitados, Caching Proxy sólo reenvía las peticiones a los servidores de destino y no reescribe ningún enlace de recurso en el cuerpo de las peticiones.
Caching Proxy también puede reenviar métodos definidos por el usuario al servidor de fondo. Utilice la sintaxis siguientes para la directiva Enable en el archivo ibmproxy.conf a fin de habilitar un método personalizado:
Enable método-definido-por-usuario [WithBody | WithoutBody]
Establecer el valor WithBody o WithoutBody indica al proxy si el método definido por el usuario necesita un cuerpo de petición.
El siguiente ejemplo habilita un método definido por el usuario My_METHOD e indica al proxy que el método necesita un cuerpo de petición:
Enable MY_METHOD WithBody
Las siguientes directivas habilitan los métodos WebDAV, métodos de MS Exchange y métodos definidos por el usuario:
Para obtener más información, consulte el Edición manual del archivo ibmproxy.conf.
Las normas de correlación son directivas de configuración que hacen que las peticiones de cliente dirigidas a Caching Proxy se procesen de algún modo, por ejemplo, se pasan a un servidor de origen (proxy), se redirigen o se rechazan. Es importante establecer las normas de correlación correctamente para el correcto funcionamiento del Caching Proxy. Las normas de correlación tienen un efecto sobre lo siguiente:
Las directivas de normas de correlación utilizan el siguiente formulario:
norma plantilla destino [dirección_IP | nombre_sistppal]:[puerto]
Sólo las peticiones que coinciden con la combinación determinada de plantilla y puerto IP están sujetas a esta norma. Una plantilla puede contener comodines, por ejemplo, https://**/*.asp.
El orden en el que aparecen las normas en el archivo de configuración es significativo. Excepto las directivas Map, tan pronto como la petición coincide con una plantilla, aquella se procesa y no se evalúan las normas posteriores. La directiva Map sustituye el URL de la petición. Esta nueva petición continúa para ser comparada con las restantes normas de correlación.
Las siguientes normas de correlación se aplican a las peticiones de cliente que coinciden con la plantilla determina:
La siguiente norma de correlación se aplica a la respuesta de servidor de origen:
Las siguientes normas de correlación se aplican a las aplicaciones API:
Para configurar un sustituto estándar:
Puerto 80
Proxy /* http://nuestro.servidor.contenido.com/* :80
AdminPort 8080
Esto permite que todo el tráfico HTTP del puerto 80 pase por el proxy al servidor de origen. El tráfico que entre en el puerto de administración no coincide con la norma de proxy comodín inicial y, por lo tanto, no se ve afectado. Las restantes normas de correlación se utilizan para procesar la petición.
Las siguientes directivas definen las normas de correlación:
Para obtener más información, consulte el Edición manual del archivo ibmproxy.conf.
El siguiente formulario de Configuración y Administración edita los valores de las directivas asociadas:
Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.
Sólo se aplica a configuraciones de proxy de retorno.
La directiva JunctionRewrite habilita la rutina de reescritura de unión en Caching Proxy para reescribir las respuestas de los servidores de origen para garantizar que los URL relativos al servidor se correlaciones correctamente con el servidor de origen correcto cuando se utilizan uniones. El plug-in de reescritura de unión también debe habilitarse. Las uniones se definen mediante normas de correlación del proxy.
Al utilizar las normas de correlación del proxy para definir la unión, puede utilizar la directiva Proxy con la opción JunctionPrefix o sin ella.
A continuación se ofrecen ejemplos de uniones válidas sobre las que puede actuar la rutina de reescritura de unión:
A continuación se ofrece un ejemplo de una unión válida sobre la que no actuará la rutina de reescritura de unión:
A continuación aparecen ejemplos de uniones no válidas:
Estas normas de correlación han creado uniones para servidortienda, servidorautoriz y servidorb2b. Considere que servidortienda devuelve un documento HTML con los siguientes URL contenidos en los distintivos HTML apropiados:
La rutina de reescritura de unión reescribirá las referencias relativas al servidor mediante las normas de correlación del proxy del modo siguiente:
Al utilizar la opción JunctionPrefix con la directiva Proxy, en lugar de inferir JunctionPrefix del primer patrón de URL de la norma Proxy, puede declarar el prefijo de unión de la norma Proxy mediante el formato siguiente:
Proxy url_patern1 url_pattern2 JunctionPrefix:url_prefix
Al utilizar JunctionPrefix, no hay límites en cuanto al formato del primer patrón de URL. Para dar soporte a la reescritura de unión cuando no se utilice la opción JunctionPrefix, el URL de proxy debe tener el siguiente formato: Proxy /market/* http://servidorautoriz/*. Sin embargo, al utilizar JunctionPrefix, la siguiente norma Proxy es válida para la reescritura de unión:
Proxy /market/partners/*.html http://servidorautoriz.acme.com/*.html junctionprefix:/market/partners
La rutina de reescritura de unión afecta a los siguientes distintivos:
Distintivo | Atributos |
---|---|
!-- | 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 |
Las siguientes directivas se utilizan para habilitar el plug-in y la rutina de reescritura de unión.
Para obtener más información, consulte el Edición manual del archivo ibmproxy.conf.
Los siguientes formularios deConfiguración y Administración se pueden utilizar para habilitar el plug-ins de reescritura de unión:
Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.
Puede utilizar cookies para almacenar información del servidor de programa de fondo del siguiente modo: se envía una cookie al navegador de cliente. Cuando el navegador envía peticiones a los recursos de la página HTML, éste adjunta una cookie de modo que Caching Proxy envía las peticiones al servidor de programa de fondo correcto.
Para utilizar cookies como una alternativa para JunctionRewrite, efectúe las siguientes modificaciones en el archivo ibmproxy.conf:
A continuación aparece una comparación entre el plug-in JunctionRewrite y la implementación de cookies.
Proxy /no-juntion.jpg http://login-server/no-junction.jpg
Se proporciona código de ejemplo personalizable que reescribe y analiza los bloques de distintivos JavaScript(TM) (SCRIPT) y applet (APPLET) de los archivos HTML. El plug-in JunctionRewrite por sí solo puede procesar los enlaces de recursos en JavaScript o en los valores de parámetros de Java(TM).
Después de instalar Caching Proxy, puede compilar el mismo código y configurarlo para que se ejecute con JunctionRewrite.
Loa siguientes archivos de ejemplo están situados en el subdirectorio ...samples/cp/, bajo el directorio en que ha descargado el fixpack.
Las normas de correlación Pass y Exec se utilizan para enviar el contenido local a un cliente que lo solicite. Por omisión, una norma Pass con una plantilla comodín se coloca como la última norma de correlación. Esta norma dirige todas las peticiones que no coinciden con las plantillas anteriores para recuperar los archivos de un directorio de destino, al que generalmente se denomina directorio raíz de documentos.
Cuando se recibe un URL que no contenga un nombre de archivo, Caching Proxy satisface la petición buscando el directorio especificado, si se proporciona uno, o el directorio raíz de documentos, si no se especifica ningún directorio, del archivo que coincide con la lista de páginas de bienvenida especificada en el archivo de configuración. Si se define más de una página Web, el servidor proxy busca las páginas en el orden en que se definen. Se sirve la primera página de bienvenida que se encuentre.
La página de inicio del servidor es la página Web que el servidor envía por omisión al recibir una petición que contenga sólo el URL del servidor sin un nombre de archivo ni directorio. Como se explica previamente, la norma de correlación de comodín por omisión requiere que la página de inicio del servidor esté almacenada en el directorio raíz de documentos y que el nombre de archivo de la página de inicio coincida con una página de bienvenida definida.
Este tema describe cómo definir el directorio raíz de documentos y las páginas de bienvenida.
Los directorios raíz de documentos por omisión son:
La siguiente directiva define el directorio raíz de documentos:
Para obtener más información, consulte el Edición manual del archivo ibmproxy.conf.
Para modificar el directorio raíz de documentos de los formularios de Configuración y Administración, utilice el siguiente procedimiento:
Después del reinicio, el servidor empieza a utilizar el directorio raíz de documentos.
Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.
El servidor busca la página de inicio en el directorio raíz de documentos, pero el archivo específico que devuelve se define mediante la lista de páginas de bienvenida.
Acerca de las páginas de bienvenida
Cuando el servidor recibe una petición URL que no especifica un nombre de archivo, intenta satisfacer la petición de acuerdo con una lista de páginas de bienvenida establecidas en el archivo de configuración del servidor. Esta lista define los archivos que se van a utilizar como páginas principales por omisión. El servidor determina su página de inicio haciendo coincidir la lista de páginas de bienvenida con los archivos del directorio raíz de documentos. La primera coincidencia que encuentra es el archivo que se devuelve como página de inicio. Si no se encuentra ninguna coincidencia, el servidor muestra un listado de los directorios raíz de documentos.
Para que un determinado archivo se utilice como la página de inicio del servidor y se devuelva cuando una petición no especifique un directorio ni un nombre de archivo, debe incluir el archivo en el directorio raíz de documentos y asegurarse que su nombre coincida con uno de los nombres de archivo enumerados en la lista de páginas de bienvenida.
El archivo de configuración por omisión define, en el orden siguiente, estos nombres de archivo para que se utilicen como páginas de bienvenida:
El servidor devuelve el primer archivo que encuentra que coincide con un nombre de archivo de la lista. Hasta que cree un archivo welcome.html o index.html e incluya ese archivo en el directorio raíz de documentos, el servidor utiliza Frntpage.html como la página de inicio.
Por ejemplo, si está utilizando la configuración por omisión y el directorio raíz de documentos no contiene un archivo denominado welcome.html, pero contiene los archivos denominados index.html y FrntPage.html, se utiliza el archivo index.html como página de inicio.
Si no se encuentra ninguna página de inicio, el contenido del directorio raíz de documentos se visualiza como un directorio.
La siguiente directiva define las páginas de bienvenida:
Para obtener más información, consulte el Edición manual del archivo ibmproxy.conf.
El siguiente formulario de Configuración y Administración define las páginas de bienvenida:
Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.
Sólo se aplica a configuraciones de proxy de reenvío.
Caching Proxy pasa por el proxy todas las peticiones para los URL de FTP al servidor FTP adecuado, pero no puede utilizarse para pasar por el proxy las peticiones de un cliente FTP. Puede dar soporte sólo a aquellas peticiones FTP recibidas de un cliente HTTP (mediante el esquema de protocolo ftp://).
Sólo se da soporte a los métodos GET, PUT y DELETE para las peticiones de los archivos FTP. Sólo se da soporte al método GET para las peticiones de listados de directorio FTP. Por omisión, se inhabilitan PUT y DELETE en Caching Proxy. Para obtener más información, consulte Habilitación de métodos HTTP/FTP.
Este tema describe cómo proteger los archivos FTP y gestionar el inicio de sesión del servidor, las vías de acceso de directorio y el encadenamiento de FTP.
Si ha habilitado el método PUT para la carga de archivos FTP o el método DELETE para la supresión de archivos FTP, es necesario que defina la protección del proxy FTP para las peticiones PUT y DELETE como mínimo, para evitar la actualización de archivos no autorizados en el servidor FTP.
Para proteger el paso por el proxy de las peticiones FTP, en los formularios de Configuración y Administración, seleccione Configuración de servidor -> Protección de documentos. Para crear una configuración de protección para las peticiones de archivos FTP, incluya ftp:// al inicio de la plantilla de petición. Por ejemplo, para proteger los archivos de un directorio llamado exams, utilice la plantilla ftp://exams/*.
Para obtener más información sobre cómo crear configuraciones de protección, consulte el Configuraciones de protección del servidor.
Si ningún ID de usuario ni contraseña se especifica en el URL de petición, Caching Proxy intenta iniciar la sesión en el servidor FTP solicitado de forma anónima (mediante el ID de usuario ANONYMOUS). Numerosos servidores FTP requieren una dirección de correo electrónico como contraseña para el FTP anónimo. Si el servidor FTP pide una contraseña para el inicio de sesión anónimo, Caching Proxy envía la dirección de correo electrónico especificada por la directiva WebmasterEmail del archivo de configuración.
Para establecer la dirección de correo electrónico del Webmaster que aparece en los formularios de Configuración y Administración, seleccione Configuración de servidor -> Gestión del sistema -> SNMP MIB. La dirección de correo electrónico también puede establecerse mediante la directiva WebmasterEmail; para obtener detalles, consulte el apartado de referencia: WebMasterEMail: establecer una dirección de correo electrónico para recibir informes de servidor seleccionados.
Si el servidor FTP del URL de petición requiere un ID de usuario y contraseñas específicos para iniciar la sesión, los usuarios pueden especificar el ID de usuario y contraseña en el URL de petición, por ejemplo:
ftp://idusuario:contraseña@sistppalservidorftp/
Si no desea especificar la contraseña para el ID de usuario FTP en el URL de petición, los usuarios pueden especificar sólo el ID de usuario en el URL: ftp://idusuario@sistppalservidorftp. Caching Proxy primero intenta iniciar la sesión en el servidor FTP con el ID de usuario especificado y sin contraseña. Si el inicio de sesión no se realiza satisfactoriamente sin una contraseña, el navegador solicita la contraseña asociada al ID de usuario especificado.
Para los inicios de sesión que no sean anónimos, se debe especificar el ID de usuario como mínimo en el URL. Si no se especifica el ID de usuario, se intenta el inicio de sesión anónimo y al cliente no se le solicita el ID de usuario.
Debe especificar a Caching Proxy si desea que los nombres de vía de acceso de los URL de FTP se interpreten como relativos al directorio de trabajo del usuario o relativos al directorio raíz. Por ejemplo, si un usuario que ha iniciado sesión en un servidor FTP tiene un directorio de trabajo por omisión llamado /export/home/usuario1 y desea recuperar un archivo llamado prueba1.exe de un subdirectorio llamado prueba, el proxy utiliza los siguientes URL para recuperar el archivo del servidor FTP, dependiendo de cómo se interpreten los URL de FTP:
Si se establecen las vías de acceso de URL de FTP relativas, los usuarios pueden especificar todavía un nombre de vía de acceso absoluta mediante la convención consistente en utilizar un carácter de escape %2F con el carácter de barra inclinada (/) para indicar el directorio raíz. Por ejemplo, si usuario1, cuyo directorio de trabajo es /export/home/uduario1, desea acceder a un archivo del directorio de trabajo de usuario2, /export/home/usuario2, la petición ftp://usuario1:usuario1pw@FTPhost/%2Fexport/home/usuario2/ archivo se interpreta correctamente como un URL relativo al directorio raíz / (es decir, un nombre de vía de acceso absoluta), incluso si se ha optado por los nombres de vías de acceso relativas de los URL de FTP.
Para especificar cómo se deben interpretar los URL de FTP, en los formularios de Configuración y Administración, seleccione Configuración de proxy -> Rendimiento del proxy. En la parte inferior del formulario, bajo Las vías de acceso de URL de FTP deben ser:, seleccione vías de acceso absolutas para especificar el directorio raíz del servidor o vías de acceso relativas para especificar el directorio de trabajo del usuario como el principio de la vía de acceso.
Este valor también puede modificarse en el archivo de configuración de proxy; para obtener más información, consulte FTPUrlPath: especificar cómo se interpretan los URL de FTP.
Si está encadenando varios servidores proxy Web, puede especificar que las peticiones que contengan los URL de FTP se envíen a un servidor proxy Web encadenado en lugar de al servidor FTP directamente. Para especificar un servidor proxy encadenado para las peticiones FTP, en los formularios de Configuración y Administración, seleccione Configuración de proxy -> Encadenamiento de proxy y dominios que no son proxy. El esquema de protocolo http:// se utiliza para especificar el URL del proxy encadenado, incluso al encadenar peticiones para un protocolo de esquema ftp://.
Para configurar el encadenamiento FTP mediante el archivo de configuración de proxy, consulte el apartado de referencia en ftp_proxy: especificar otro servidor proxy para las peticiones FTP.
Este tema describe cómo utilizar las inclusiones de servidor para insertar información en los programas CGI programas y documentos HTML que se envíen al cliente. Asimismo se describe la personalización de las correlaciones de recursos y mensajes de error del servidor.
Las inclusiones de servidor le permiten añadir información a los programas CGI y documentos HTML que el servidor envía al cliente al actuar como servidor de origen (es decir, no a objetos en antememoria o que han pasado por el proxy). La fecha actual, el tamaño de un archivo y la fecha del último cambio de un archivo son ejemplos del tipo de información que se puede enviar al cliente. Este aprtado describe el formato de mandato de las inclusiones de servidor y explica cómo lograr que los mandatos include de servidor funcionen en los programas CGI y documentos HTML. Asimismo puede utilizar las inclusiones de servidor para personalizar las páginas de error.
Antes de utilizar las inclusiones de servidor en el servidor, tenga en cuenta los problemas de rendimiento, seguridad y riesgo:
Para habilitar las inclusiones de servidor, seleccione Configuración de servidor -> Configuración básica en los formularios de Configuración y Administración. Utilice este formulario para especificar cuál de los siguientes tipos de inclusiones de servidor son aceptables:
Utilice este formulario para especificar si desea realizar el proceso de inclusión de la parte servidor de los documentos de texto y HTML además de otros tipos de archivo.
Asimismo, asegúrese de que se reconozca la extensión de archivo que utilice para la inclusión. En los formularios de Configuración y Administración, seleccione Configuración de servidor -> Tipos MIME y codificación y utilice el formulario Tipos MIME. Tenga en cuenta que las extensiones shtml y htmls se reconocen por omisión.
Para configurar el servidor para las inclusiones de servidor editando las directivas del archivo de configuración de proxy, consulte los apartados de referencia de las siguientes directivas:
Los mandatos include deben incluirse en el documento HTML o programa CGI como comentarios. Los mandatos tienen el siguiente formato:
<!--#directive tag=value ... --> o bien <!--#directive tag="value" ... -->
Las comillas que encierran los valores son opcionales, pero son necesarias para anidar espacios.
Este apartado explica las directivas que el servidor acepta para las inclusiones de servidor. No se deben confundir estas directivas con las directivas del archivo de configuración de proxy, que aparecen documentadas en el Apéndice B. Directivas del archivo de configuración.
config: controlar proceso de archivos
Utilice esta directiva para controlar ciertos aspectos del proceso de archivos. Los distintivos válidos son cmntmsg, errmsg, sizefmt y timefmt.
Ejemplo:
<!--#config cmntmsg="[Esto es un comentario]" --> <!-- #echo var=" " texto adicional -->
Resultado: <!--[Esto es un comentario] texto extra -->
Valor por omisión: [Lo siguiente era adicional en la directiva]
Ejemplo:
<!-- #config errmsg="[Se ha producido un error]" -->
Valor por omisión: "[Se ha producido un error al procesar esta directiva]
Ejemplo 1:
<!--#config sizefmt=bytes --> <!--#fsize file=foo.html -->
Resultado: 1024
Ejemplo 2:
<!--#config sizefmt=abbrev --> <!--#fsize file=foo.html -->
Resultado: 1K
Valor por omisión: "abbrev"
Ejemplo:
<!--#config timefmt="%D %T" --> <!--#flastmod file=foo.html -->
Resultado: "10/18/95 12:05:33"
Default: "%a, %d %b %Y %T %Z"
Los siguientes formatos strftime() son válidos con el distintivo timefmt:
Especificador | Significado |
---|---|
%% | Sustituir por % |
%a | Sustituir por el nombre abreviado del día de la semana |
%A | Sustituir por el nombre completo del día de la semana |
%b | Sustituir por el nombre abreviado del mes |
%B | Sustituir por el nombre completo del mes |
%c | Sustituir por la fecha y hora |
%C | Sustituir por el número de siglo (año dividido por 100 y truncado) |
%d | Sustituir por el día del mes (01-31) |
%D | Insertar la fecha como %m/%d/%y |
%e | Insertar el mes del año como un número decimal (01-12) (Bajo C POSIX sólo, es un campo de 2 caracteres, justificado por la derecha, rellenado con espacios en blanco) |
%E[cCxyY] | Si el formato fecha/hora alternativo no está disponible, los descriptores %E se correlacionan con sus equivalentes no ampliados (por ejemplo, %EC se correlaciona con %C) |
%Ec | Sustituir por la representación alternativa de la fecha y hora |
%EC | Sustituir por el nombre del año base (periodo) de la representación alternativa |
%Ex | Sustituir por la representación alternativa de la fecha |
%EX | Sustituir por la representación alternativa de la hora |
%Ey | Sustituir por el desplazamiento de %EC (año sólo) en la representación alternativa |
%EY | Sustituir por la representación alternativa completa del año |
%h | Sustituir por el nombre abreviado del mes (igual a %b) |
%H | Sustituir por la hora (reloj de 23 horas) como un número decimal (00-23) |
%I | Sustituir por la hora (reloj de 12 horas) como un número decimal (00-12) |
%j | Sustituir por el día del año (001-366) |
%m | Sustituir por el mes (01-12) |
%M | Sustituir por los minutos (00-59) |
%n | Sustituir por una nueva línea |
%O[deHlmMSUwWy] | Si el formato fecha/hora alternativo no está disponible, los descriptores %E se correlacionan con sus equivalentes no ampliados (por ejemplo, %Od se correlaciona con %d) |
%Od | Sustituir por el día del mes, utilizando los símbolos numéricos alternativos, rellenados según convenga con ceros delante si existe algún símbolo alternativo para el cero, de lo contrario deben utilizarse espacios delante |
%Oe | Sustituir por el día del mes, utilizando los símbolos numéricos alternativos, rellenados según convenga con espacios anteriores |
%OH | Sustituir por la hora (reloj de 24), utilizando los símbolos numéricos alternativos |
%OI | Sustituir por la hora (reloj de 12), utilizando los símbolos numéricos alternativos |
%Om | Sustituir por el mes, utilizando los símbolos numéricos alternativos |
%OM | Sustituir por los minutos, utilizando los símbolos numéricos alternativos |
%OS | Sustituir por los segundos, utilizando los símbolos numéricos alternativos |
%OU | Sustituir por el número de semana del año (el domingo como el primer día de la semana, normas correspondientes a %U) utilizando los símbolos numéricos alternativos |
%Ow | Sustituir por el día de la semana (Domingo=0), utilizando los símbolos numéricos alternativos |
%OW | Sustituir por el número de semana del año (el lunes como el primer día de la semana) utilizando los símbolos numéricos alternativos |
%Oy | Sustituir por el año (desplazamiento de %C) de la representación alternativa, utilizando los símbolos numéricos alternativos |
%p | Sustituir por el equivalente local de AM o PM |
%r | Sustituir por la serie equivalente a %I:%M:%S %p |
%R | Sustituir por la notación de 24 horas (%H:%M) |
%S | Sustituir por los segundos (00-61) |
%t | Sustituir por una pestaña |
%T | Sustituir por una serie equivalente a %H:%M:%S |
%u | Sustituir por el día de la semana como un número decimal (1-7), con 1 igual a lunes |
%U | Sustituir por el número de la semana del año (00-53), donde el domingo es el primer día de la semana |
%V | Sustituir por el número de la semana del año (01-53), donde el lunes es el primer día de la semana |
%w | Sustituir por el día de la semana (0-6), donde el domingo es 0 |
%W | Sustituir por el número de la semana del año (00-53), donde el lunes es el primer día de la semana |
%x | Sustituir por la representación adecuada de la fecha |
%X | Sustituir por la representación adecuada de la hora |
%y | Sustituir por el número del año de dos dígitos dentro del siglo |
%Y | Sustituir con el número del año de cuatro dígitos |
%Z | Sustituir por el nombre del huso horario o dejar sin caracteres si se desconoce el huso horario |
La configuración del sistema determina los años y nombres de mes completos y abreviados.
echo: visualizar valores de variable
Utilice esta directiva para visualizar el valor de las variables de entorno especificadas con el distintivo var. Si no se encuentra una variable, se visualizará (None). Asimismo, echo puede mostrar un valor establecido por las directivas set o global. Las siguientes variables de entorno pueden mostrarse:
Ejemplo:
<!--#echo var=SSI_DIR -->
exec: especificar programas CGI
Utilice esta directiva para incluir la salida de un programa CGI. La directiva exec descarta cualquier cabecera HTTP a las que da salida la CGI excepto las siguientes:
cgi: especificar URL de programa CGI
Utilice esta directiva para especificar el URL de un programa CGI.
En este ejemplo, programa es el programa CGI que se desea ejecutar y info_vía_acceso y serie_consulta representan uno o más parámetros pasados al programa como variable de entorno:
<!--#exec cgi="/cgi-bin/programa/info_vía_acceso?serie_consulta" -->
Este ejemplo muestra la utilización de variables:
<!--#exec cgi="&path;&cgiprog;&pathinfo;&querystring;" -->
flastmod: visualizar fecha y hora de la última modificación del documento
Utilice esta directiva para visualizar la fecha y hora más recientes en las que se modificó el documento. El formato de esta variable se define mediante la directiva config timefmt. Los distintivos file y virtual son válidos con esta directiva y sus significados se definen del siguiente modo.
Formatos de directiva:
<!--#flastmod file="/path/file" --> <!--#flastmod virtual="/path/file" -->
<!--#flastmod file="/path/file" -->
<!--#flastmod virtual="/path/file" -->
Ejemplo:
<!--#flastmod file="foo.html" -->
Result: 12May96
fsize: visualizar tamaño de archivo
Utilice esta directiva para visualizar el tamaño del archivo especificado. La directiva config sizefmt define el formato de esta variable. Los distintivos file y virtual son válidos con esta directiva y sus significados son los mismos que se han definido anteriormente para la directiva flastmod.
Ejemplo:
<!--#fsize file="/path/file" --> <!--#fsize virtual="/path/file" -->
Result: 1K
global: definir variables globales
Utilice esta directiva para definir las variables globales que se pueden repetirse posteriormente mediante este archivo o cualquier archivo incluido.
Ejemplo:
<!--#global var=VariableName value="SomeValue" -->
Por ejemplo, para hacer referencia a un documento padre */a través de los límites virtuales, es necesario que establezca una variable global DOCUMENT_URI. Además es necesario que haga referencia a la variable global del documento hijo. Este ejemplo muestra el código HTML que se necesita para insertar el documento padre:
<!--#global var="PARENT_URI" value=&DOCUMENT_URI; -->
Este ejemplo muestra el código HTML que es necesario insertar en el documento hijo:
<!--#flastmod virtual=&PARENT_URI; -->
include: incluir un documento en la salida
Utilice esta directiva para incluir el texto de un documento de la salida. Los distintivos file y virtual son válidos con esta directiva y sus significados son los mismos que se han definido anteriormente para la directiva flastmod.
set: establecer variables que se van a repetir
Utilice esta directiva para establecer una variable que se pueda repetir posteriormente, pero sólo mediante este archivo.
Ejemplo:
<!--#set var="Variable 2" value="AnotherValue" -->
Al definir una directiva, puede repetir una serie en medio de value. Por ejemplo:
<!--#include file="&filename;" -->
Variables: una directiva set en la parte servidor va seguida generalmente de una directiva echo, de tal modo que busca la variable establecida, informa acerca de dónde se encuentra la variable y continúa con la función. Puede contener varias referencias a variables. Las directivas set de la parte servidor también le permiten repetir una variable ya establecida. Si no se encuentra ninguna variable set, no se visualiza nada.
Cuando una directiva set de la parte servidor encuentra una referencia de variable dentro de una directiva de inclusión de servidor, intenta resolverla en la parte servidor. En la segunda línea del siguiente ejemplo, la variable &index; de la parte servidor se utiliza con la serie var para construir el nombre de variable var1. A continuación, se asigna a la variable &var1; un valor indicando un carácter de escape delante del & de ê de modo que no se reconozca como una variable. En su lugar, se utiliza como una serie para crear el valor frêd, o fred con un acento circunflejo encima de la e. La variable ê es una variable de parte del servidor.
<!--#set var="index" value="1" --> <!--#set var="var&index;" value="fr\êd" --> <!--#echo var="var1" -->
Los caracteres que se pueden definir de este modo (llamados variables con escape) aparecen precedidos de una barra inclinada invertida \) e incluyen los siguientes:
Carácter | Significado |
---|---|
\a | Alerta (timbre) |
\b | Retroceso |
\f | Salto de página (nueva página) |
\n | Línea nueva |
\r | Retorno de carro |
\t | Tabulador horizontal |
\v | Tabulador vertical |
\' | Comillas simples |
\" | Comillas |
\? | Signo de interrogación |
\\ | Barra inclinada invertida |
\- | Guión |
\. | Punto |
\& | Ampersand |
Puede personalizar los mensajes de error que Caching Proxy devuelve y puede definir mensajes específicos para determinadas condiciones de error. En los formularios de Configuración y Administración, seleccione Configuración de servidor -> Personalización de mensajes de error. Utilice este formulario para seleccionar una condición de error y especificar un determinado archivo HTML para utilizarlo en esa condición.
Para personalizar los mensajes de error mediante la edición de directivas en el archivo de configuración de proxy, consulte el apartado de referencia de la directiva ErrorPage: especificar un mensaje personalizado para una determinada condición de error.
Sólo se aplica a configuraciones de proxy de retorno.
WebSphere Application Server, Versión 6.1 introduce el soporte multimedia de modalidad continua en la forma del redirector RTSP. RTSP habilita Caching Proxy para que actúe como el primer punto de contacto con los reproductores multimedia y redirija las peticiones a un servidor proxy adecuado o a un servidor de contenido que proporcione el contenido de soporte solicitado.
RTSP (Real Time Streaming Protocol) aparece definido en RFC 2326. Es un protocolo estándar de Internet para controlar la corriente de datos. Aunque no incluye la tecnología para enviar corrientes, es lo bastante flexible para que pueda utilizarse para controlar las corrientes de datos que no están relacionados con la reproducción de vídeo o audio.
La característica de redirección RTSP permite que Caching Proxy redireccione las peticiones para cualquier sesión multimedia de modalidad continua controlada por RTSP. Éstas incluyen los siguientes tipos de soporte:
Cualquier reproductor que se pueda configurar para contactar con un servidor proxy en el puerto RTSP (generalmente 554) puede utilizar esta infraestructura de Caching Proxy para que el redirector RTSP maneje las peticiones.
El redirector RTSP no coloca en antememoria o pasa directamente por el proxy las representaciones multimedia. El redirector RTSP debe utilizarse junto con un servidor multimedia de modalidad continua de terceros para que proporcione una de las funciones o ambas. Caching Proxy con el redirector RTSP debe tener acceso de red a uno o más de los servidores proxy RTSP.
Esta característica está sujeta a la siguiente limitación:
Actualmente, sólo se da soporte a las tecnologías RealNetworks. Éstas incluyen el servidor proxy RealProxy, el servidor de origen RealServer y el reproductor multimedia RealPlayer.
Anteriormente, el redirector RTSP estaba sujeto a la limitación de que todas las peticiones al mismo servidor de origen de cualquier URL debían redirigirse al mismo sitio. La redirección basada en los nombres de archivo u otras partes del URL solicitado no era posible. Esta limitación ya no se aplica. Actualmente el redirector RTSP utiliza el URL completo de las peticiones recibidas junto con el valor de umbral (rtsp_proxy_threshold) establecido en el archivo de configuración de Caching Proxy para determinar si se debe redirigir la petición de cliente al servidor de origen o a un servidor proxy. Actualmente las peticiones al mismo servidor de origen se manejan individualmente.
Las siguientes directivas de configuración de archivos se utilizan para controlar la redirección RTSP. Los valores de estas directivas no se renuevan mediante un reinicio de servidor. El servidor debe detenerse completamente y reiniciarse antes de que los cambios de estas directivas entren en vigor.
Al solicitar documentos, los clientes Web envían cabeceras que proporcionan información adicional sobre el navegador o la petición. Las cabeceras se generan automáticamente cuando se envía una petición.
Caching Proxy permite que varias opciones para personalizar la información de cabecera la mantengan oculta del servidor de destino. Aunque la sustitución de la cabecera genérica por la cabecera real tiene la ventaja de aumentar el anonimato del cliente, tiene la desventaja de inhabilitar la personalización de páginas basada en cabeceras que se escribe en algunas páginas Web.
Las cabeceras adoptan generalmente este formato:
User-Agent: Mozilla 2.02/OS2 Client-IP: 45.37.192.3 Referer: http://www.bigcompany.com/WebTrafficExpress/main.html
Esta cabecera incluye los siguientes campos:
Los valores adecuados de configuración del proxy pueden bloquear la mayoría de las cabeceras. Sin embargo, algunos campos de cabecera son necesarios para los servidores de origen, de modo que si se bloquean, es posible que las páginas Web no se visualicen correctamente (por ejemplo, en algunos casos el bloqueo del campo de cabecera "host" puede ocasionar que los usuarios vean la página Web errónea). Para obtener información sobre los campos de cabecera, consulte la especificación HTTP Version 1.1.
Para modificar las opciones de cabecera editando el archivo de configuración de proxy, consulte los apartados de referencia de las siguientes directivas:
Para obtener más información consulte el Edición manual del archivo ibmproxy.conf.
Puede utilizar dos formularios de Configuración y Administración para especificar las opciones de cabecera:
Compruebe este recuadro si desea que la dirección IP del cliente se envíe al servidor de destino (contenido). Si no comprueba este recuadro, el servidor de destino recibe la dirección IP del servidor proxy. Si deja este recuadro deseleccionado, se incrementa el anonimato de los clientes mientras se navega por Internet.
Escriba la serie que desea enviar en la cabecera del servidor de destino para sustituir el tipo de navegador y el sistema operativo que está utilizando el cliente. Por ejemplo: especifique que Caching Proxy 4.0 sustituye a Mozilla 2.02/OS2 en la siguiente cabecera:
Content-Type:MIME User-Agent: Mozilla 2.02/OS2 Referer: http://www.ics.raleigh.ibm.com/WebTrafficExpress/main.html Pragma:no-cache
Escriba la dirección de correo electrónico que el servidor lee al analizar la cabecera "De:". Es posible que desee especificar la dirección de correo electrónico del administrador de proxy ya que el administrador es la persona que debe recibir los informes de cualquier problema.
Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.
La interfaz de programas de aplicación (API) se describe detalladamente en la publicación Guía de programación de Edge Components. Las directivas API del archivo de configuración habilitan las rutinas de plug-in a las que se llama durante los pasos específicos dentro del flujo de trabajo del proceso de peticiones. Estas rutinas de plug-in pueden sustituirse o ejecutarse además de las rutinas incorporadas.
A continuación se enumeran las directivas API:
Para obtener más información, consulte el Edición manual del archivo ibmproxy.conf.
El siguiente formulario de Configuración y Administración edita los valores de las directivas asociadas:
Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.
Este apartado describe la antememoria del proxy y su configuración. La antememoria puede configurarse para almacenar archivos en la memoria (antememoria de memoria) o en uno o más dispositivos de almacenamiento (antememoria de disco). Un agente de renovación de antememoria puede configurarse para cargar previamente en la antememoria los archivos solicitados frecuentemente, y se pueden aplicar varios filtros de URL a la colocación en antememoria. En este apartado también se describe el compartimiento de antememoria mediante el uso del acceso de antememoria remota o el plug-in de Protocolo de antememoria de Internet(ICP); la eliminación de los archivos obsoletos con la recogida de basura de antememoria, y la colocación en antememoria de los archivos generados dinámicamente.
Esta parte contiene los siguientes temas:
La colocación en antememoria es una característica que permite que el servidor proxy guarde copias locales de los archivos que solicitan los clientes de modo que éste puede servirlos con mayor rapidez desde la antememoria cuando el mismo u otro cliente los solicita de nuevo.
Caching Proxy es compatible con HTTP 1.1 y generalmente cumple con el protocolo HTTP para colocar en antememoria los documentos y determinar la antigüedad.
Este capítulo describe algunas características de la antememoria del servidor proxy. Para esas características que pueden configurarse, la información detallada de cómo establecer los valores adecuados se incluye en capítulos posteriores.
El servidor proxy puede almacenar la antememoria en un dispositivo de almacenamiento físico o en la memoria del sistema. El tipo de almacenamiento de antememoria más adecuado para el usuario depende de las posibilidades del hardware y de si es más importante disponer de una respuesta de antememoria rápida o de un número mayor de elementos almacenados en la antememoria. El tiempo de respuesta de una antememoria de memoria generalmente es más rápido que de una antememoria de disco, pero el tamaño de una antememoria de memoria está limitado por la cantidad de RAM en la máquina del servidor proxy. El tamaño de una antememoria de disco está limitada por el tamaño de un dispositivo de almacenamiento, que generalmente es mucho mayor que la cantidad de RAM.
Para las antememorias de disco, Caching Proxy utiliza el disco sin procesar, que significa que el servidor proxy escribe directamente en el dispositivo de antememoria sin utilizar los protocolos de escritura y lectura del sistema operativo. El dispositivo de almacenamiento de una antememoria de disco debe prepararse mediante la utilización del mandato htcformat. La información detallada sobre htcformat se incluye en el apartado Configuración de la colocación en antememoria básica.
Tanto en una antememoria de memoria como de disco, Caching Proxy también utiliza el espacio de memoria del sistema para mantener un índice de la antememoria, que reduce el tiempo de proceso para buscar los archivos en antememoria.
La estructura de directorios de antememoria de Caching Proxy y sus métodos de búsqueda son distintos de los demás servidores proxy. Caching Proxy mantiene un índice en la memoria con información sobre los archivos en la antememoria. La utilización de RAM para realizar búsquedas en lugar de un disco u otro soporte da como resultado una búsqueda y recuperación de archivos más rápidas.
El índice incluye los URL, ubicaciones de antememoria e información de caducidad de los objetos en antememoria. Por esta razón, la cantidad de memoria necesaria para mantener el índice es proporcional al número de objetos en la antememoria.
Cuando se recibe una petición de un cliente, el proxy comprueba el índice de antememoria en la memoria de ese URL.
Cuando se configura el proxy para colocar en antememoria las peticiones, puede colocar en antememoria las peticiones de archivos FTP además de las peticiones de archivos HTTP. No obstante, como los archivos FTP no contienen el mismo tipo de información de cabecera que los archivos HTTP, las fechas de caducidad de los archivos FTP en antememoria se calculan de modo distinto al resto de los archivos en antememoria.
Cuando se realiza una petición al servidor FTP para que recupere un archivo, el proxy primero envía al servidor FTP una petición LIST para que el archivo obtenga la información de directorio FTP sobre el archivo. Si el servidor FTP responde a la petición LIST con una respuesta afirmativa de conclusión y con la información de directorio del archivo, el proxy crea una cabecera HTTP Last-Modified con la fecha analizada a partir de la información de directorio FTP. La función de colocación en antememoria del proxy seguidamente utiliza esta cabecera Last-Modified, junto con el valor establecido en la directiva CacheLastModifiedFactor del archivo de configuración, para determinar el periodo de tiempo que el archivo FTP permanece en la antememoria antes de caducar.
Para obtener más información sobre cómo se utilizan la cabecera Last-Modified y la directiva CacheLastModifiedFactor para determinar el periodo de tiempo que un archivo permanece en la antememoria, consulte el Mantenimiento del contenido de la antememoria.
Los archivos FTP que se recuperan para un ID de usuario específico y no mediante un inicio de sesión anónimo se consideran archivos privados y no se colocan en antememoria.
Además de la colocación en antememoria del contenido Web, el servidor proxy realiza la colocación en antememoria del servidor de nombres de dominio (DNS). Por ejemplo, cuando un cliente solicita un URL de www.misitioWeb.com,el proxy solicita al servidor DNS que resuelva el nombre del sistema principal de www.misitioWeb.com como una dirección IP. A continuación, la dirección IP se coloca en antememoria para mejorar el tiempo de respuesta para las peticiones posteriores a ese nombre de sistema principal. La colocación en antememoria DNS es automática y no puede volver a configurarse.
Algunos archivos y documentos no se colocan nunca en antememoria. Éstos incluyen los elementos siguientes:
Es posible restringir adicionalmente los elementos colocados en antememoria mediante el establecimiento de filtros de colocación en antememoria. Por ejemplo, es posible que no desee que el servidor proxy coloque en antememoria los archivos que se sirven localmente desde el proxy. Consulte el Control de los elementos colocados en antememoria para obtener información detallada.
La gestión de una antememoria implica varios factores. Como administrador del servidor, puede especificar la siguiente información:
Asimismo, se pueden realizar ajustes de la configuración de antememoria para mejorar el rendimiento global de Caching Proxy. Para obtener información detallada sobre el ajuste del rendimiento, consulte el Ajuste de la antememoria del servidor proxy.
Si ha utilizado los valores por omisión del Programa de instalación del producto Edge Components para instalar Caching Proxy, la colocación en antememoria está habilitada y la antememoria se almacena en la memoria. Es posible que desee ajustar los siguientes valores de antememoria básica para personalizar la antememoria en función de las necesidades del sistema.
Si no ha utilizado programa de instalación, configure estos valores para habilitar la colocación en antememoria.
Los pasos básicos necesarios para configurar la antememoria son los siguientes:
Después de configurar los valores de antememoria básica, es posible que desee añadir o modificar los valores de las siguientes características.
Las instrucciones sobre cómo modificar cada uno de estos valores se facilitan en este capítulo o bien se hace referencias a ellos.
Para habilitar la colocación en antememoria, establezca la directiva Caching en on o seleccione el recuadro Habilitar colocación en antememoria de proxy en el formulario de configuración Configuración de antememoria -> Valores de antememoria. Si no especifica un dispositivo de antememoria, la antememoria se almacenará en la memoria. Para crear una antememoria de disco, siga los pasos de 2. Configure el almacenamiento en antememoria.
Las tareas para configurar el almacenamiento de antememoria dependen de si se utiliza una antememoria de memoria o una antememoria de disco.
Para utilizar la antememoria de memoria, personalice el valor Memoria de antememoria para que incluya la suficiente memoria para mantener el contenido de una antememoria. Consulte Establecimiento de la memoria de antememoria para obtener los tamaños de memoria de antememoria recomendados.
Para utilizar una antememoria de disco, debe realizar las siguientes acciones:
La antememoria requiere un dispositivo especialmente formateado. Se recomienda destinar un dispositivo o partición de disco completos a la antememoria. El tamaño mínimo de una antememoria es 16392 KB.
Para formatear el dispositivo de antememoria:
htcformat vía_de_acceso_dispositivo_original [-blocksize tamaño_bloque] [-blocks número_de_bloques]Los argumentos -blocksize y -blocks son opcionales. El tamaño de bloque por omisión es de 8192 bytes. Si el número de bloques no se especifica, la partición de disco se rellenará con tantos bloques como pueda contener.
Al especificar la vía de acceso del dispositivo, asegúrese de especificar la vía de acceso del dispositivo sin procesar.
raw /dev/raw/raw1 dev/sdb1
Consulte el material de referencia para sistema de archivos para obtener información adicional sobre el acceso a los dispositivos sin procesar.
Si el sistema operativo intenta escribir en el dispositivo de antememoria, los datos en antememoria pueden perderse. Para evitar esto, puede utilizar el programa de utilidad Windows Disk Manager para preparar el disco antes de utilizar el mandato htcformat. Para preparar el disco, utilice el programa de utilidad de disco para suprimir el dispositivo y la partición que desee utilizar y, a continuación, vuelva a crearlos sin formato. Esta acción hace que el sistema considere el dispositivo no disponible para el almacenamiento del sistema.
Establezca el valor de la directiva CacheMemory (o del campo Memoria de antememoria del formulario de configuración Valores de configuración), de acuerdo con el siguiente principio. La cantidad de memoria establecida en este valor se utiliza para el soporte de infraestructura de antememoria, incluido el índice de antememoria, y, si se configura la colocación en antememoria de la memoria, para almacenar el contenido de la antememoria.
Para un rendimiento óptimo de las antememorias de disco, se recomienda un valor mínimo de memoria de antememoria de 64 MB para el soporte de infraestructura de antememoria, incluido el índice de antememoria. A medida que aumenta el tamaño de antememoria, aumenta el índice de antememoria y se necesita más memoria de antememoria para almacenar el índice. Un valor de memoria de antememoria de 64 MB es lo bastante grande para proporcionar el soporte de infraestructura y almacenar un índice de antememoria para una antememoria de disco de hasta 6.4 GB aproximadamente. Para antememorias de disco de mayor tamaño, la memoria de antememoria debería ser el 1% del tamaño de antememoria.
Para las antememorias de memoria, el valor de memoria de antememoria es la cantidad de memoria reservada para el soporte de infraestructura y la misma antememoria. Se recomienda un valor mínimo de memoria de antememoria de 64 MB.
Si se asigna demasiada memoria física a la antememoria de memoria, es posible que se produzcan operaciones no deseadas como, por ejemplo, errores de "insuficiencia de memoria" o anomalías del servidor proxy. Las limitaciones de valor para la memoria de antememoria son debidas a las limitaciones de una aplicación de 32 bits. Como Caching Proxy es una aplicación de 32 bits, puede utilizar un máximo de 2 GB de memoria.
Caching Proxy asigna la memoria definida por la directiva CacheMemory y la utiliza como la antememoria para almacenar objetos. Debe asignarse la memoria adicional, tanto si es una antememoria de memoria como una antememoria de disco sin procesar, para las estructuras de datos de la antememoria, los almacenamientos intermedios de conexiones y E/S de red, almacenamientos intermedios de sesiones y la memoria del proceso principal y todas las hebras. Asimismo, es posible que las peticiones de algunos clientes necesiten asignar un bloque de agrupaciones de memoria mayor que el valor por omisión. Por lo tanto, si la directiva CacheMemory se establece próxima a la marca de 2 GB, es posible que Caching Proxy no tenga la suficiente memoria para operar, especialmente bajo altas cargas de peticiones.
Se recomienda que el valor de la directiva CacheMemory sea inferior o igual a 1600 MB. El establecimiento del valor en más de 1600 MB interfiere con la memoria que necesita Caching Proxy para un funcionamiento normal y tiene efectos colaterales adversos. Estos efectos colaterales generalmente incluyen una mayor utilización de la CPU (posiblemente de hasta el 100 %), errores de falta de memoria y un rendimiento más lento, aunque no se limita a ellos. Si es necesario un mayor tamaño de antememoria global, utilice los dispositivo de antememoria o implemente una configuración de antememoria compartida con RCA o ICP.
Puede importar o exportar el contenido de antememoria a un archivo de vuelco y desde él. Esto es útil cuando la memoria de antememoria se pierde durante el reinicio o al desplegar la misma antememoria para varios proxies.
Los filtros pueden restringir los elementos que se colocan en antememoria haciéndolos coincidir con el formato de la petición URL. Consulte el Control de los elementos colocados en antememoria para obtener detalles sobre cómo establecer los filtros.
Opcionalmente, puede configurar el servidor proxy para colocar en antememoria los resultados de las peticiones de consultas. Por omisión, los URL que contienen un signo de interrogación (?) no se colocan en antememoria. Consulte el Colocación en antememoria de respuestas de consultas para obtener información detallada.
Otra opción consiste en colocar en antememoria los resultados de la ejecución de JPS o servlets desde IBM WebSphere Application Server. Consulte el Colocación en antememoria de contenidos generados dinámicamente para obtener información detallada.
Consulte el Mantenimiento del contenido de la antememoria para obtener información sobre la configuración cuando los archivos de la antememoria caducan y sobre cómo se eliminan los archivos obsoletos.
La antememoria puede configurarse para renovar automáticamente los archivos más solicitados a diario antes de que se soliciten. Consulte el Configuración del agente de carga para la renovación y precarga automática para obtener más información.
En ciertas circunstancias, la utilización de una antememoria aumenta la posibilidad de que un archivo solicitado se encuentre en la antememoria. Consulte el Utilización de una antememoria compartida para obtener información.
El mantenimiento de anotaciones cronológicas concisas y exactas es importante para gestionar Caching Proxy. Supervisión de Caching Proxy contiene información sobre cómo configurar y utilizar las anotaciones cronológicas del servidor proxy.
Caching Proxy ofrece varios métodos de filtrado para controlar qué archivos, documentos y demás objetos se colocan en antememoria. Éstos incluyen las características siguientes:
El servidor proxy puede configurarse para comparar peticiones con una plantilla de URL para determinar si un archivo se ha colocado en antememoria. Esta característica se configura mediante el establecimiento de plantillas para las peticiones cuyos archivos siempre están colocados en antememoria y de plantillas independientes para las peticiones cuyos archivos nunca deben colocarse en antememoria. Se pueden utilizar varias plantillas.
Un sistema similar se utiliza para habilitar la colocación en antememoria de respuestas de consultas. Consulte Colocación en antememoria de respuestas de consultas para obtener información.
Para establecer los filtros de colocación en antememoria de URL mediante la edición del archivo ibmproxy.conf, consulte CacheOnly: colocar en antememoria sólo los archivos con los URL que coinciden con una plantilla yNoCaching: especificar que no se coloquen en antememoria los archivos con los URL que coinciden con una plantilla.
Para establecer los filtros de colocación en antememoria de URL en los formularios de Configuración y Administración, utilice el campo Configuración de antememoria -> Comportamiento de antememoria: Filtrado de antememoria por URL. Utilice este apartado para especificar los URL cuyos archivos siempre se colocan en antememoria o para especificar los URL cuyos archivos nunca se colocan en antememoria. Para especificar dos listas, una de archivos que siempre se vayan a almacenar en antememoria y otra de los archivos que nunca se vayan a colocar en antememoria, cree una lista y, a continuación, pulse Someter antes de crear la otra lista.
Las respuestas devueltas de consultas (peticiones URL que contienen un signo de interrogación) se pueden almacenar en antememoria mediante filtros de colocación en antememoria. Esta característica puede ser útil en los escenarios de proxy de retorno (sustituto) si numerosos clientes realizan la misma petición de consulta.
La colocación en antememoria de consultas puede configurarse mediante la edición de la directiva CacheQueries en el archivo de configuración ibmproxy.conf. La directiva CacheQueries presenta las siguientes opciones:
Encontrará información adicional sobre estas opciones en CacheQueries: especificar las respuestas de antememoria a los URL que contienen un signo de interrogación (?).
Para configurar la colocación en antememoria de respuestas de consultas en los formularios de Configuración y Administración, utilice el campo Configuración de antememoria -> Comportamiento de antememoria: Colocar en antememoria filtrado de respuestas de consulta por URL. Para especificar dos listas, cree una lista y, a continuación, pulse Someter antes de crear la otra lista.
Asimismo, para configurar el valor de colocación en antememoria de consultas, asegúrese de que los siguientes valores se configuran correctamente para permitir que las respuestas de consultas se coloquen en antememoria. Consulte Configuración de la antigüedad de antememoria para obtener información sobre cómo establecer estas opciones mediante los formularios de Configuración y Administración.
Como generalmente no resulta eficaz colocar en antememoria los archivos que se sirven desde el servidor proxy, los archivos que se originan en el dominio local del servidor no se colocan en antememoria por omisión. Para colocar en antememoria los objetos que se originan en el dominio local del servidor, seleccione el recuadro Almacenar en antememoria archivos de dominio locales del formulario de Configuración y Administración Configuración de antememoria -> Comportamiento de antememoria. Alternativamente, establezca la directiva CacheLocalDomain del archivo de configuración de proxy en on.
Los elementos sólo pueden colocarse en antememoria basándose sólo en una parte (significativa) especificada del URL de entrada, en lugar del URL completo. Esto resulta útil en los servicios Web del modelo de transacciones o en la colocación en antememoria dinámica, ya que la misma respuesta se devuelve a menudo para diversas peticiones de entrada cuando partes significativas de los URL de peticiones de entrada son idénticos.
No se pueden utilizar los formularios de Configuración y Administración para especificar la colocación en antememoria basada en URL parciales. En su lugar, utilice la directiva SignificantUrlTerminator en el archivo de configuración de proxy para especificar un código de terminación para las peticiones URL. Esta especificación hace que Caching Proxy evalúe sólo los caracteres previos al código de terminación al procesar la petición y determina si el archivo solicitado se ha colocado en antememoria. Cuando se define más de un código de terminador, Caching Proxy compara los URL de entrada con los códigos de terminador en el orden en el que están definidos en el archivo ibmproxy.conf. Consulte SignificantURLTerminator; especificar un código de terminación para las peticiones URL para obtener más información.
Para establecer los filtros editando directamente el archivo de configuración de proxy, consulte los apartados de referencia de las siguientes directivas:
Consulte el Visión general de la colocación en antememoria del servidor proxy para obtener información sobre los documentos que se pueden colocar en antememoria.
Como la colocación en antememoria requiere crear y guardar una copia del archivo servido, es necesario cierto mantenimiento de rutina para que la antememoria funcione correctamente. Debe comprobarse la antigüedad de los archivos en antememoria y deben invalidarse cuando ya no son coherentes con los archivos del servidor de origen. Este proceso de caducidad de archivos se explica en Caducidad de los archivos. Asimismo, los archivos invalidados o no utilizados deben eliminarse de la antememoria para dejar espacio para los nuevos archivos. Este proceso de depuración de la antememoria se describe en Recogida de basura.
El mantenimiento de los objetos en antememoria que son coherentes con el objeto original del servidor de contenido se conoce como mantenimiento de la antigüedad en la antememoria. Para todos los documentos u otros objetos que coloca en antememoria, Caching Proxy calcula una hora en la que caduca el objeto.
Para las páginas HTTP, la cabecera del documento, generada por el servidor de contenido, contiene la información de caducidad.
Como el protocolo FTP no incluye información de caducidad equivalente, Caching Proxy genera su propia cabecera Last-Modified: para los archivos FTP, basándose en la información de directorios FTP para todos los archivos y utiliza esta información para calcular los tiempos de caducidad. Si el servidor proxy no puede obtener la información de directorio para el archivo a partir del servidor FTP, se utiliza el valor por omisión que coincide con el URL de FTP. Asimismo, como no existe un formato de fecha estándar para los servidores FTP, es posible que Caching Proxy no pueda entender la fecha y hora enviadas por algunos servidores FTP. En ese caso, se utiliza el valor de tiempo de caducidad por omisión del servidor proxy. Este procedimiento permite que el proxy gestione la colocación en antememoria de las páginas HTTP y los archivos FTP de una forma parecida.
Un servidor de contenido puede especificar la caducidad de uno de los siguientes modos (en orden de preferencia):
Después de calcular el tiempo de caducidad como se acaba de describir, Caching Proxy comprueba si existe un valor de Espera mínima que se aplica a este URL. Si existe este valor y el periodo que especifica es mayor que el tiempo de caducidad calculado, el tiempo especificado por el valor de Espera mínima se utiliza como tiempo de caducidad del objeto. Esto es cierto incluso si Caching Proxy calcula un tiempo de caducidad de 0 minutos para un documento. Por lo tanto, para evitar servir contenido que no es actual, tenga cuidado con la utilización del valor de Espera mínima. (Para establecer el valor de Espera mínima, utilice la directiva CacheMinHold o el valor Configuración de antememoria -> Valores de caducidad de antememoria: Caducidad del URL. Consulte Configuración de la antigüedad de antememoria para obtener información adicional.
El valor de tiempo de caducidad final se contrasta con el tiempo especificado en el valor Margen de tiempo. Si el tiempo de caducidad es mayor que el valor Margen de tiempo, el documento se coloca en antememoria; de lo contrario no se añade a la antememoria. Para establecer el valor de Margen de tiempo, utilice la directiva CacheTimeMargin o consulte las instrucciones en Configuración de la antigüedad de antememoria.
Si se encuentra el documento en la antememoria pero ha caducado, Caching Proxy emite una petición especial conocida como if-modified-since al servidor de contenido. Esta petición provoca que el servidor de contenido envíe el documento sólo si se ha modificado desde que el proxy lo recibió por última vez. Si el documento no se ha modificado, el servidor de contenido envía un mensaje que lo indica y no vuelve a enviar la página. Es ese caso, el proxy sirve el documento en antememoria. Para los archivos FTP, el servidor proxy simula este proceso if-modified-since. Si se determina que el archivo no se ha modificado en el servidor FTP, éste sirve el archivo desde la antememoria. De lo contrario, obtiene la versión más reciente del servidor FTP.
Sólo se aplica a configuraciones de proxy de reenvío.
Como el protocolo FTP no define las fechas y horas de forma tan estricta como lo hace el protocolo HTTP, existen varios factores que pueden provocar que la cabecera Last-Modified generada por el proxy para los archivos sea ligeramente distinta de la fecha de archivo real. Estos factores son los siguientes:
Cuando un archivo FTP caduca en la antememoria, el proxy simula el proceso de revalidación if-modified-since de HTTP para el archivo FTP. Lleva a cabo esta acción volviendo a emitir el mandato FTP LIST para el archivo solicitado, analizando la fecha de archivo de la respuesta devuelta por el servidor FTP y comparando esta fecha con la fecha que el servidor proxy ha generado para la cabecera Last-Modified cuando el archivo se ha recuperado inicialmente. Si la fecha de archivo no se ha modificado, el servidor proxy marca el archivo FTP en antememoria como revalidado, establece una nueva fecha de caducidad del archivo y sirve el archivo de la antememoria en lugar de recuperarlo del servidor FTP de nuevo. Si las dos fechas de archivo no coinciden, el proxy recupera el archivo del servidor FTP de nuevo y coloca la nueva copia con la nueva fecha de archivo.
No siempre es posible obtener la información de directorio del archivo a partir del servidor FTP. Si el proxy no puede determinar la fecha de archivo del archivo FTP, no genera una cabecera Last-Modified del archivo. En su lugar, utiliza el valor especificado para la directiva CacheDefaultExpiry que coincide con el URL para determinar el periodo de tiempo que se debe mantener en archivo en la antememoria. Cuando este periodo de tiempo caduca, el proxy siempre recupera el archivo del servidor FTP de nuevo. Si archivos FTP específicos de la antememoria parecen utilizar la directiva CacheDefaultExpiry con mucha frecuencia y se recuperan con asiduidad (generando un alto volumen de tráfico de red), es recomendable especificar un valor CacheDefaultExpiry más granular para esos archivos específicos. Con esta acción, se consigue mantenerlos en la antememoria durante un periodo de tiempo más largo.
Para especificar los valores de caducidad de la antememoria de los formularios de Configuración y Administración, utilice el formulario Configuración de antememoria -> Valores de caducidad de antememoria -> Límite de tiempo para archivos de antememoria. Para obtener más detalles sobre cómo establecer las fechas de caducidad del archivo en antememoria, consulte Caducidad de los archivos.
Para especificar los tiempos de caducidad de los archivos en antememoria, seleccione Configuración de antememoria -> Valores de caducidad de antememoria en los formularios de Configuración y Administración. Los siguientes formularios son de gran utilidad.
Utilice este formulario para establecer el periodo mínimo de tiempo que los archivos se mantienen en antememoria, basándose en sus URL. Puede especificar diferentes comportamientos de colocación en antememoria para las distintas plantillas de petición URL.
Para establecer la caducidad de archivos basada en URL editando el archivo de configuración de proxy, consulte los apartados de referencia del Apéndice B. Directivas del archivo de configuración para obtener información sobre las siguientes directivas:
Utilice el formulario Valores de caducidad de antememoria para especificar los valores de caducidad por omisión de los archivos usados y sin usar. Puede establecer valores distintos para los archivos HTTP, FTP y Gopher y también para los archivos usados y no usados.
Este formulario contiene opciones adicionales de caducidad de archivos:
Para establecer los valores de caducidad por omisión editando el archivo de configuración de proxy, consulte las páginas de referencia de las siguientes directivas:
Utilice el formulario Factor de última modificación para establecer el valor que el proxy utiliza para calcular una fecha de caducidad de los archivos en antememoria sin fecha de caducidad en las cabeceras. Puede establecer diferentes valores para los archivos que coincidan con distintas plantillas de petición. La primera plantilla que coincida se utiliza para calcular la fecha de caducidad.
Para establecer el factor de última modificación editando directamente el archivo de configuración de proxy, consulte CacheLastModifiedFactor: especificar el valor para determinar las fechas de caducidad.
Utilice el formulario de configuración Límite de tiempo para archivos de antememoria para establecer el tiempo máximo que un archivo puede permanecer en la antememoria. Los límites de tiempo se establecen basándose en las plantillas de petición, y se puede especificar que las plantillas se descarten o se vuelvan a validar cuando caduque el límite de tiempo. Estos valores pueden utilizarse para mantener los archivos cuyas fechas de caducidad no son válidas o los archivos con tiempos de caducidad muy largos.
Para establecer el límite máximo de tiempo de caducidad de los archivos en antememoria editando el archivo de configuración de proxy, consulte las siguientes directivas:
Como parte del esfuerzo para mantener en antememoria los URL populares y minimizar el uso de los recursos del sistema, Caching Proxy realiza el proceso de limpieza conocido como recogida de basura, mediante el cual se eliminan los archivos antiguos o usados de la antememoria para dejar espacio para los archivos más recientes.
El proceso de recogida de basura examina los archivos del directorio de antememoria e intenta eliminar los archivos caducados para reducir el tamaño de la antememoria y dejar espacio para los archivos nuevos. La recogida de basura se realiza automáticamente, pero algunos valores pueden configurarse para adaptar el proceso a sus necesidades.
Para configurar la recogida de basura, seleccione Configuración de antememoria -> Valores de recogida de basura en los formularios de Configuración y Administración. Utilice este formulario para establecer la marca alta y la marca baja, que determinan cuándo se inicia y se detiene la recogida de basura. Cuando la cantidad de espacio utilizado en la antememoria alcanza o excede el porcentaje establecido para la marca alta, se inicia la recogida de basura. La recogida de basura continúa hasta que el porcentaje de espacio utilizado en la antememoria es igual al valor establecido para la marca baja o menor que él.
Puede escoger entre dos algoritmos de recogida de basura. El algoritmo responsetime optimiza el tiempo necesario para responder a los usuarios mediante la eliminación preferencial de los archivos de gran tamaño de la antememoria. El algoritmo bandwidth optimiza el uso de la banda ancha de red mediante la eliminación preferencial de archivos de menor tamaño de la antememoria. Escoja uno de los dos o utilice una combinación de los dos.
Para configurar la recogida de basura editando el archivo de configuración de proxy, consulte los apartados de referencia de las siguientes directivas:
La mayoría de los servidores proxy de antememoria colocan en antememoria un archivo únicamente después de que lo solicite un usuario. Caching Proxy tiene un agente que proporciona la precarga automática de antememoria. Puede especificar que el agente de antememoria recupere automáticamente los URL especificados, los URL más populares o ambos y los coloca en la antememoria antes de que se soliciten.
En algunos casos, es necesario establecer el nombre de sistema principal del servidor proxy e identificar anotaciones cronológicas de acceso de antememoria antes de cargar previamente la antememoria. Para configurar el agente de antememoria, seleccione Configuración de antememoria en los formularios de Configuración y Administración y utilice los formularios Precarga de antememoria y Renovación de antememoria. Tenga en cuenta que los archivos que representan los resultados de las consultas, es decir, los archivos cuyos URL incluyen el signo de interrogación (?) se colocan en antememoria sólo si la colocación en antememoria está habilitada.
La renovación y precarga automática proporciona las siguientes ventajas:
Las desventajas son las siguientes:
Para obtener una eficacia óptima, establezca el agente de antememoria para que se ejecute cuando la actividad del servidor sea baja y antes de que el servidor esté ocupado con las peticiones de cliente. A continuación, los archivos están listos en la antememoria para proporcionar un servicio rápido la primera vez que un usuario los solicita. Por omisión, el agente de antememoria se inicia cada noche a las 3 de la mañana hora local.
Consideraciones especiales de las configuraciones de proxy de retorno:
Por razones de seguridad, cuando utilice una configuración de proxy de retorno, la regla Proxy http:* debe estar inhabilitada por omisión. (Es decir, esta regla aparece como comentario en el archivo ibmproxy.conf.) Sin embargo, si la regla está inhabilitada, se impide que el agente de antememoria envíe peticiones satisfactoriamente y renueve el contenido de antememoria de Caching Proxy. Un error "403 Prohibido por norma" en los resultados de anotaciones cronológicas de error y no se completará la renovación de antememoria.
Para evitar este problema, utilice cacheAgentService, que es un servicio interno proporcionado por Caching Proxy. Para habilitar el servicio, ponga la siguiente directiva Service antes de cualquier otra regla de correlación en el archivo ibmproxy.conf:
Service /any-valid-string* INTERNAL:cacheAgentService
La variable any-valid-string es cualquier serie que sea válida y no esté en conflicto con otras reglas de correlación en el archivo ibmproxy.conf.
Tanto Caching Proxy como el agente de antememoria analizan el URI basado en esta directiva de servicio. En vez de enviar el URI directamente a Caching Proxy, el programa de utilidad de agente de antememoria añade el URI como prefijo con el patrón /any-valid-string en la directiva Service.
Por ejemplo, el agente de antememoria transforma el siguiente URI:
http://www.ibm.com/
en
/any-valid-string/http://www.ibm.com/
El agente de antememoria envía el URI con el prefijo a Caching Proxy. Cuando Caching Proxy recibe la petición, elimina el prefijo /any-valid-string/. Si el URI restante es una unidad totalmente calificada, Caching Proxy sirve la petición directamente sin correlacionar el URI con otras reglas.
Además, el agente de antememoria puede enviar un URI relativo a Caching Proxy. Por ejemplo, si añade LoadURL /abc/ utilizando la directiva Service referenciada previamente en el archivo ibmproxy.conf, el agente de antememoria lo transforma en /any-valid-string/abc/ y lo envía a Caching Proxy. Caching Proxy recibe el URL, elimina el prefijo, correlaciona /abc/ con otras reglas de correlación y maneja la petición si hay una coincidencia.
Para obtener información sobre la directiva Service, consulte Service: personalizar el paso de servicio.
En las plataformas Linux y UNIX, especifique el nombre de sistema principal del servidor proxy cuya antememoria se está precargando y renovando. En las plataformas Windows, especifique el nombre de sistema principal sólo si el servidor proxy que se está renovando no está en la máquina local. Tenga en cuenta que no es posible renovar la antememoria de un servidor remoto basándose en los archivos a los que se ha accedido con mayor frecuencia, ya que el agente de antememoria local no tiene acceso a las anotaciones cronológicas de acceso de antememoria de un servidor remoto.
Para establecer el nombre de sistema principal del servidor proxy, seleccione Configuración de antememoria -> Renovación de antememoria: Identificar servidor de destino de antememoria en los formularios de Configuración y Administración.
Para precargar la antememoria con el contenido almacenado en los URL específicos, utilice Configuración de antememoria -> Precarga de antememoria en los formularios de Configuración y Administración. En este formulario, puede especificar los URL para el agente de antememoria que se desea cargar. El proxy recupera esas páginas cuando el agente de antememoria se inicia, independientemente de si se encontraban en la antememoria previamente. Estos URL se especifican en el archivo de configuración de proxy mediante la directiva LoadURL. Este formulario también puede utilizarse para definir los URL cuyo contenido nunca se coloca en antememoria. El acceso a las anotaciones cronológicas de acceso de antememoria no es necesario para este tipo de precarga en antememoria.
Utilice el formulario Precarga de antememoria para configurar las siguientes opciones:
Para precargar automáticamente las páginas a las que se accede frecuentemente, utilice el formulario Configuración de antememoria -> Renovación de antememoria. Esta función requiere anotaciones cronológicas de acceso a antememoria para el servidor proxy. La ubicación y el nombre de las anotaciones cronológicas pueden modificarse; para obtener información consulte la Supervisión de Caching Proxy. Los URL más solicitados se determinan automáticamente desde las anotaciones cronológicas de acceso de antememoria. El administrador también puede especificar el número de páginas más solicitadas que se van a precargar en la antememoria. Este número se especifica en el archivo de configuración de proxy mediante la directiva LoadTopCached.
Utilice el formulario Renovación de antememoria para configurar las siguientes opciones:
La profundización es una parte opcional de la característica de renovación de antememoria automática. La mayoría de las páginas Web tienen enlaces con otras páginas con información relacionada, y los usuarios a menudo siguen la ruta que enlaza una página una página con otra y un sitio con otro. La profundización es un modo de colocar en antememoria estas rutas de información lógica. En la profundización, el agente de antememoria sigue un nivel especificado de enlaces (HTML) de hipertexto en las páginas que está cargando y además coloca en antememoria todas esas páginas enlazadas. Las páginas enlazadas pueden residir en el mismo sistema principal como la página de origen o en otros sistemas principales. Se muestra una ilustración en la Figura 1.
Para controlar el proceso de profundización, el administrador especifica al agente de antememoria el número máximo de los URL que puede cargar (el valor por omisión es 2000), el periodo máximo de tiempo que puede ejecutarse (el valor por omisión es de dos horas) y un número máximo de hebras que puede utilizar (el valor por omisión es cuatro). El administrador también puede configurar controles adicionales. Por omisión, la profundización se habilita para dos niveles de la jerarquía y no es posible entre sistemas principales. Adicionalmente, se inserta un retraso entre las peticiones. Para modificar estos valores, consulte Directivas relacionadas del archivo de configuración de proxy.
El agente de antememoria carga y, a continuación, refresca la antememoria en el siguiente orden:
Tenga en cuenta que el agente de antememoria no comprueba si el número máximo de páginas se ha alcanzado hasta que empieza la profundización entre enlaces. Si el valor del número máximo de páginas (llamado MaxURLs en el archivo de configuración de proxy) es menor que el número de páginas recuperadas en los pasos 1 y 2, no se recupera ninguna página enlazada.
Los siguientes ejemplos muestran cómo el agente de antememoria maneja las prioridades de renovación de antememoria y la profundización, relativas al número máximo de URL que se han especificado (asuma que se ha configurado la profundización para todos estos ejemplos).
valores del archivo de configuración | Resultado |
---|---|
LoadURL http://www.getthis.com/main.html LoadURL http://www.getmetoo.com/welcome.htm LoadTopCached 30 MaxURLs 50 |
Si las anotaciones cronológicas de acceso de antememoria tienen más de 30 URL únicos, el agente de antememoria recupera main.html, welcome.htm y los 30 primeros URL solicitados basándose en las anotaciones cronológicas de acceso de antememoria. Como no ha alcanzado el valor MaxURLs, recupera y carga hasta 18 URL enlazados de páginas colocadas en antememoria. |
LoadURL http://ww.joesmith.edu/favorites.html LoadURL http://www.janesmith.edu/dislikes.html LoadTopCached 30 MaxURLs 25 |
Si las anotaciones cronológicas de acceso de antememoria tienen más de 30 URL únicos, el agente de antememoria recupera favorites.html, dislikes.html y los 30 primeros URL solicitados de las anotaciones cronológicas de acceso de antememoria. No se recupera ningún otro archivo ya que se ha excedido el valor de MaxURLs. |
LoadURL http://www.hello.com/hi.htm LoadURL http://www.ballyhoo.com/index.html LoadTopCached 20 MaxURLs 25 |
Si las anotaciones cronológicas de acceso de antememoria tienen más de 20 URL únicos, el agente de antememoria recupera hi.htm, index.html, los 20 primeros URL solicitados de las anotaciones cronológicas de acceso de antememoria y hasta 3 URL enlazados de las páginas anteriores. No se recupera ningún otro archivo ya que se alcanzado el valor de MaxURLs. |
El agente de antememoria también puede configurarse editando directamente las directivas del archivo de configuración de proxy. Para obtener información sobre las directivas del archivo de configuración de proxy relacionadas con el agente de antememoria, consulte las siguientes páginas de referencia que aparecen en el Apéndice B. Directivas del archivo de configuración:
Si se habilita la renovación de antememoria automática, el agente de antememoria ejecuta automáticamente una operación de renovación a la hora especificada. No obstante, también puede ejecutar el agente de antememoria desde una línea de mandatos cuando lo desee.
El archivo ejecutable es el siguiente:
Donde server_root es la unidad y el directorio donde se ha instalado Caching Proxy (por ejemplo, C:\Archivos de programa\IBM\edge\cp).
En las plataformas Linux y UNIX, puede ejecutar automáticamente el agente de antememoria en varios momentos distintos mediante el daemon cron. Los trabajos controlados por cron se especifican añadiendo una línea al archivo crontab del sistema. Una entrada de ejemplo del archivo de mandatos en Linux y UNIX es:
45 16 * * * /usr/sbin/cacheagt
Este ejemplo de mandato inicia el agente de antememoria cada día a las 4:45 de la tarde, hora local. Puede utilizar varias entradas para ejecutar el agente de antememoria más de una vez, si así lo desea. Para obtener más información, consulte la documentación del sistema operativo sobre el daemon cron.
Al utilizar un daemon cron para ejecutar el agente de antememoria, no olvide desactivar la opción de renovación automática, ya sea utilizando la configuración Configuración de antememoria -> Renovación de antememoria o editando el archivo de configuración de proxy. De lo contrario, el agente de antememoria se ejecuta más de una vez al día.
Es común que un punto de presencia en la Web tenga más tráfico que lo que puede manejar un único servidor. Una solución consiste simplemente en añadir más servidores. No obstante, cuando se utilizan varios servidores proxy de colocación en antememoria, el contenido de una antememoria con frecuencia se solapa con el contenido de las demás antememorias. Además de la innecesaria redundancia en el almacenamiento, el ahorro máximo de banda ancha no se logra ya que un archivo en antememoria vuelve a buscarse en el servidor de origen cuando una petición solicitándolo llega a un servidor proxy que no tiene ese archivo en su propia antememoria. Aunque la colocación duplicada en antememoria puede minimizarse mediante una cadena jerárquica de servidores proxy, este escenario no evita generar tráfico adicional a través de un determinado servidor a la vez que cada enlace adicional de la cadena añade latencia.
El compartimiento de antememoria soluciona estos problemas permitiendo que todas las antememorias compartan su contenido con las demás antememorias. El ahorro de banda ancha se produce debido a los siguientes hechos:
Se proporcionan dos métodos para utilizar varias antememorias como si fuesen una antememoria lógica:
RCA y ICP pueden utilizarse juntos.
Al planificar RCA, considere las siguientes recomendaciones:
El acceso a antememoria remota no es adecuado si se viola alguna de estas condiciones o si distintas organizaciones gestionan distintos servidores que sean miembros de la matriz.
Para configurar el acceso a antememoria remota, seleccione Configuración de antememoria -> Acceso a antememoria remota en los formularios de Configuración y Administración. Los campos de este formularios definen una matriz determinada que comparte una antememoria lógica. Especifique la información necesaria para todos los miembros de la matriz.
Para configurar el acceso a antememoria remota editando el archivo de configuración de proxy, consulte los apartados de referencia del Apéndice B. Directivas del archivo de configuración para obtener información sobre las siguientes directivas:
El plug-in de Protocolo de antememoria de Internet permite que Caching Proxy consulte las antememorias compatibles con ICP que buscan páginas HTML y otros recursos que puedan colocarse en antememoria. Cuando el servidor proxy recibe una petición HTTP, busca su propia antememoria para el recurso. Si no se encuentra el recurso en la antememoria local y el plug-in ICP está habilitado, el servidor proxy encapsula la petición URL en un paquete de consulta ICP y, a continuación, envía este paquete a todas las antememorias de igual de ICP identificadas. Si una antememoria de igual responde que tiene el recurso, el servidor proxy recupera el recurso de esa antememoria de igual. Si dos o más iguales responden afirmativamente, se procesa la primera respuesta. Si ningún igual responde con coincidencias, el servidor original continúa procesando la petición en función de su flujo de trabajo. Por ejemplo, el servidor proxy puede invocar otro plug-in, continuar con la rutina de Acceso a antememoria remota, si RCA está habilitada, o recuperar el recurso solicitado.
El plug-in ICP se activa y se configura editando el archivo de configuración de proxy ibmproxy.conf. Una directiva ServerInit, una directiva PreExit o ambas deben añadirse al apartado de directivas de la API del archivo de configuración para utilizar el plug-in ICP. Qué directivas se utilicen depende del rol que Caching Proxy tenga en el sistema ICP:
Para crear estas directivas, edite el archivo ibmproxy.conf manualmente o, si el servidor proxy ya está en ejecución, conéctese al formulario de Configuración y Administración Configuración de servidor Server -> Proceso de peticiones -> Petición de proceso de API.
Tenga en cuenta que las directivas de prototipo (en forma de comentarios) se han añadido al apartado API del archivo ibmproxy.conf. Estas directivas API aparecen en un orden determinado. Al añadir las directivas API para habilitar nuevas características y módulos de plug-in, ordene las directivas como se muestran en la parte de prototipo del archivo de configuración. Alternativamente, elimine los comentarios de las directivas API y edítelas, si es necesario, para incluir el soporte de todas las funciones o plug-ins deseados.
Las directivas ServerInit y PreExit tienen dos argumentos: (1) la vía de acceso plenamente cualificada de la biblioteca compartida y (2) la llamada de función. Estos argumentos se delimitan por dos puntos (:). El primer argumento es específico del sistema y depende de dónde están instalados los componentes de plug-in. El segundo argumento se codifica en la biblioteca compartida y debe escribirse exactamente como se muestra.
Todas las directivas deben aparecer en una única línea en el archivo de configuración de proxy.
ServerInit vía_acceso_biblioteca_compartida:icpServer
Ejemplo de Linux y UNIX:
ServerInit /opt/ibm/edge/cp/internet/lib/plugins/icp/libicp_plugin.so:icpServer
Ejemplo de Windows:
ServerInit C:\Archivos de programa\IBM\edge\cp\Bin\plugins\icp\icpplugin.dll: icpServer
PreExit vía_acceso_biblioteca_compartida:icpClient
Ejemplo de Linux y UNIX:
PreExit /opt/ibm/edge/cp/internet/lib/plugins/icp/libicp_plugin.so:icpClient
Ejemplo de Windows:
PreExit C:\Archivos de programa\IBM\edge\cp\Bin\plugins\icp\icpplugin.dll:icpClient
Para configurar los valores del plug-in, añada o modifique las directivas ICP* que se facilitan en el archivo de configuración de proxy. Para obtener información adicional, consulte las descripciones de las directivas siguientes.
Sólo se aplica a configuraciones de proxy de retorno.
La función de colocación en antememoria dinámica permite que Caching Proxy se coloque en antememoria el contenido generado dinámicamente en forma de respuestas de JavaServer Pages (JSP) y servlets generados IBM WebSphere Application Server. Se utiliza un módulo del adaptador de Caching Proxy en el servidor de aplicaciones para modificar las respuestas de modo que se puedan colocar en antememoria en el servidor proxy además de en la antememoria dinámica del servidor de aplicaciones. Con esta característica, el contenido generado dinámicamente puede colocarse en antememoria en los límites de la red de modo que el sistema principal que aloja contenidos quede exento de realizar peticiones repetidas al servidor de aplicaciones cuando más de un cliente solicite el mismo contenido.
En ocasiones es necesario habilitar la colocación en antememoria de consultas para que funcione la característica de colocación en antememoria dinámica, por ejemplo, si los servlets utilizan los URL en forma de consulta. El servidor proxy considera cualquier URL que contenga un signo de interrogación (?) como una consulta.
La colocación en antememoria del contenido generado dinámicamente ofrece las siguientes ventajas:
El servidor de aplicaciones sólo exporta páginas públicas compuestas completamente para la antememoria de proxy. El proxy no coloca en antememoria las páginas privadas. Por ejemplo, una página generada dinámicamente desde un sitio público que facilita el pronóstico del tiempo actual puede exportarse mediante IBM WebSphere Application Server y colocarse en antememoria mediante Caching Proxy. No obstante, una página generada dinámicamente que enumera el contenido del carro de la compra de un usuario no puede colocarse en antememoria mediante el servidor proxy. Asimismo, para colocar en antememoria una página generada dinámicamente, todos los subcomponentes de esa página también deben poder colocarse en antememoria.
Los archivos dinámicos en antememoria no caducan del mismo modo que lo hacen los archivos normales; pueden invalidarse mediante el servidor que los ha generado.
Las entradas de la antememoria dinámica se invalidan en las siguientes circunstancias:
La invalidación de las entradas de antememoria dinámica se realiza mediante la generación de un mensaje de invalidación para la instancia específica del plug-in de colocación en antememoria dinámica de Caching Proxy. Caching Proxy recibe los mensajes de invalidación como apéndices del localizador de recursos /WES_External_Adapter. A continuación, Caching Proxy borra las entradas no válidas de la antememoria.
La colocación en antememoria dinámica requiere los siguientes pasos de configuración.
Siga las instrucciones de la documentación de IBM WebSphere Application Server para configurar el servidor de aplicaciones a fin de que utilice la antememoria dinámica local (también denominada la antememoria de fragmentos dinámica). La antememoria de fragmentos dinámica interacciona con la antememoria externa de Application Server Caching Proxy.
IBM WebSphere Application Server se comunica con Caching Proxy utilizando un módulo de software denominado adaptador de antememoria externa, que se instala con Application Server.
Para habilitar el servidor proxy para que coloque en antememoria el contenido generado dinámicamente (resultados de servlets y JSP), debe realizar dos cambios en el archivo de configuración de proxy ibmproxy.conf. El primer cambio habilita el módulo de plug-in de colocación en antememoria dinámica mientras que el segundo lo configura para que reconozca los orígenes del contenido dinámico que se puede colocar en antememoria.
Se utiliza una directiva API para el paso Service con el fin de habilitar el plug-in de colocación en antememoria dinámica. Para crear esta directiva, edite el archivo ibmproxy.conf manualmente o, si el servidor proxy ya está en ejecución, utilice los formularios de Configuración y Administración para seleccionar Configuración de servidor -> Proceso de peticiones -> Petición de proceso de API. El contenido de la directiva se muestra en ejemplo que aparecen posteriormente en este apartado.
Existe una directiva Service prototipo para habilitar la colocación en antememoria dinámica como un comentario en el apartado API del archivo ibmproxy.conf. Tiene la cabecera JSP Plug-in. Tenga en cuenta que las directivas API prototipo aparecen en un orden determinado. Al añadir las directivas API para habilitar nuevas características y módulos de plug-in, ordene las directivas como se muestran en la parte de prototipo del archivo de configuración. Opcionalmente, puede eliminar los caracteres de comentario de las directivas API prototipo y editarlas si es necesario para incluir soporte para todas las funciones o plug-ins deseados.
Establezca la directiva Service como se muestra en los siguientes ejemplos. Tenga en cuenta que todas las directivas deben aparecer en una única línea en el archivo de configuración de proxy; estos ejemplos en ocasiones contienen divisiones de línea para que sean legibles.
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:\Archivos de programa\IBM\edge\cp\bin\plugins\ dynacache\dyna_plugin.dll:exec_dynacmd
Si el software de Caching Proxy se instala en un directorio que no sea el directorio por omisión, sustituya la vía de acceso por la vía de acceso de estos ejemplos.
Todos los Caching Proxy también deben configurarse para que reconozcan el origen de los archivos generados dinámicamente. Añada una directiva ExternalCacheManager al archivo ibmproxy.conf para todos los servidores de aplicaciones que colocan en antememoria el contenido generado dinámicamente en este servidor proxy. Esta directiva especifica un servidor de WebSphere Application Server que coloca en antememoria los resultados del proxy y establece un tiempo de caducidad máximo para el contenido de ese servidor. Encontrará más información detallada en ExternalCacheManager: configurar Caching Proxy para la colocación en antememoria dinámica desde IBM WebSphere Application Server.
El ID de servidor utilizado en la directiva ExternalCacheManager debe coincidir con el ID de grupo del apartado de grupo de antememoria externa del archivo dynacache.xml del servidor de aplicaciones.
Para el ejemplo anterior, añada la siguiente entrada a todos los archivos ibmproxy.conf de proxy.
ExternalCacheManager IBM-edge-cp-XYZ-1 20 seconds
Caching Proxy coloca en antememoria sólo el contenido de un servidor de IBM WebSphere Application Server cuyo ID de grupo coincida con una entrada ExternalCacheManager del archivo ibmproxy.conf.
Cuando se habilita la colocación en antememoria, la velocidad de los dispositivos de almacenamiento de antememoria es crítica para el rendimiento de Caching Proxy. Este apartado proporciona sugerencias sobre cómo elegir un tipo de almacenamiento de antememoria y configurar los dispositivos de almacenamiento de antememoria para un mejor rendimiento.
Caching Proxy puede utilizar dos tipos distintos de soporte de almacenamiento de antememoria:
Una antememoria de memoria proporciona la recuperación de archivos más rápida, aunque el tamaño de una antememoria de memoria está limitada por la cantidad de memoria disponible en la máquina del servidor proxy. Una antememoria de disco, compuesta de una o más particiones de disco sin procesar, es más lenta que una antememoria de memoria pero permite tamaños de antememoria mayores en la mayoría de los casos.
Es necesario que las particiones de dispositivo utilizadas para la colocación en antememoria de discos estén dedicadas a la antememoria; es decir, no utilice estos discos físicos para contener ningún otro sistema de archivos y no los utilice tampoco para ningún otro propósito que no sea el de almacenar la antememoria de proxy. Adicionalmente, no utilice la compresión de datos en ningún disco utilizado para la antememoria de proxy porque reduce el rendimiento.
Todos los dispositivos de almacenamiento de antememoria, ya sea un disco ya un archivo, incurren en una actividad adicional de la memoria del servidor proxy. En general, la utilización de un disco físico entero como un único dispositivo de antememoria proporciona el mejor rendimiento. La utilización de RAID u otros mecanismos para combinar varios discos físicos en un único disco lógico puede ser contraproducente. Si desea utilizar varios discos, especifíquelos como varios dispositivos de antememoria mediante el formularios de configuración Valores de antememoria o mediante la edición de la directiva CacheDev del archivo de configuración de proxy. Este método permite que el servidor proxy controle el paralelismo de escritura y lectura en varios discos y no confía en el rendimiento del sistema operativo o un subsistema de disco.
La recogida de basura de antememoria del servidor proxy elimina los archivos caducados de la antememoria, liberando espacio para la colocación en antememoria de archivos para peticiones nuevas. La recogida de basura se desencadena automáticamente cuando la cantidad de espacio usado en la antememoria alcanza un límite especificado por el administrador que se denomina marca alta y continúa hasta que la cantidad de espacio utilizado alcanza una marca baja.
Como la rutina de recogida de basura utiliza unos recursos de CPU mínimos y no afecta a la disponibilidad de material en antememoria caducado, no es necesaria la configuración de la recogida de basura para que se ejecute en momentos específicos.
Para mejorar el rendimiento de la recogida de basura, puede establecer la marca alta y la marca baja. Puede configurar el tipo de algoritmo utilizado para la recogida de basura. Consulte Recogida de basura para obtener más información sobre cómo modificar la recogida de basura.
A continuación aparecen una serie de sugerencias adicionales para optimizar el rendimiento de antememoria en todas las plataformas.
Cree un único volumen lógico de disco, preferiblemente utilizando todas las particiones físicas (PP) disponibles. Por ejemplo, dado un disco de 9 GB, cree un volumen lógico de 9 GB denominado cpcache1. Formatéelo y especifíquelo como un dispositivo de antememoria de proxy utilizando el volumen lógico sin procesar, /dev/rcpcache1.
En el dispositivo de antememoria, cree una única partición (o porción) que utilice todo el tamaño del disco. Por ejemplo, en un disco de 9 GB, cree una partición de 9 GB denominada c1t3d0s0. Formatéela y especifíquela como un dispositivo de antememoria de proxy utilizando el dispositivo sin procesar, /dev/rdsk/c1t3d0s0.
Cree una única partición utilizando todo el tamaño del disco. Por ejemplo, en un disco de 9 GB, cree una partición de 9 GB denominada i:. Formatéela y especifíquela como un dispositivo de antememoria de proxy utilizando el dispositivo sin procesar, \\.\i:.
Encontrará información sobre cómo configurar la antememoria del servidor proxy en la Configuración de la antememoria y el servidor proxy.
En esta parte se proporciona información sobre la seguridad básica, cómo utilizar SSL con Caching Proxy, cómo habilitar el hardware criptográfico y cómo utilizar el plug-in de IBM Tivoli Access Manager (anteriormente Tivoli Policy Director) y el módulo de autorización PAC-LDAP.
Esta parte contiene los siguientes temas:
Acerca de la seguridad del servidor proxy
Configuraciones de protección del servidor
Habilitación del soporte de hardware criptográfico
Utilización del plug-in de Tivoli Access Manager
Utilización del módulo de autorización PAC-LDAP
Cualquier servidor accesible desde Internet corre el riesgo de atraer la atención de modo indeseado sobre el sistema en el se ejecuta. Es posible que las personas no autorizadas intenten averiguar las contraseñas, los archivos de actualización y los archivos o leer los datos confidenciales. Parte de la atracción de Internet es su accesibilidad. No obstante, la Web está abierta tanto a una utilización positiva como al abuso.
Los siguientes apartados describen cómo controlar quién tiene acceso a los archivos de su servidor de Caching Proxy.
Caching Proxy da soporte a las conexiones SSL (Secure Sockets Layer), en las que las transmisiones seguras que impliquen el cifrado y descifrado se establecen entre el navegador de cliente y el servidor de destino (bien un servidor de contenido, bien un servidor sustituto).
Cuando Caching Proxy se configura como sustituto, puede establecer conexiones seguras con los clientes, con los servidores de contenido o ambos. Para habilitar las conexiones SSL, en los formularios de Configuración y Administración, seleccione Configuración de proxy -> Valores SSL. En este formulario, seleccione el recuadro de selección Habilitar SSL y especifique una base de datos de conjunto de claves y un archivo de contraseñas de la base de datos de conjunto de claves.
Cuando Caching Proxy se configura como un servidor proxy de reenvío, sigue un protocolo de paso a través denominado Túneles SSL para pasar peticiones cifradas entre el cliente y el servidor de contenido. La información cifrada no se coloca en antememoria porque el servidor proxy no descifra las peticiones de túnel. En una instalación de proxy de reenvío, se habilitan los túneles SSL. Para inhabilitarlos, en los formularios de Configuración y Administración, seleccione Configuración de proxy -> Valores de proxy y deseleccione el cuadro de selección Túneles SSL de este formulario.
Puede tomar varias precauciones básicas para proteger el sistema.
Los filtros de paquetes le permiten definir desde donde pueden venir los datos y a dónde pueden ir. Puede configurar el sistema para rechazar ciertas combinaciones de origen y destino.
Un cortafuegos separa una red interna de una red accesible públicamente como, por ejemplo, Internet. El cortafuegos puede ser un grupo de sistemas o un único sistema que actúe como una pasarela en ambas direcciones, regulando y haciendo un seguimiento del tráfico que pase por él. IBM Firewall es un ejemplo de software de cortafuegos.
Ejemplos:
Proxy /* http://content server :443
o
Proxy /* https://content server :443
En este capítulo se describe cómo proteger los datos y archivos del servidor mediante las configuraciones de protección. Las configuraciones de protección se desencadenan basándose en la petición que recibe el servidor, específicamente en el directorio, archivo o tipo de archivo específicos a los que se dirige la petición. En una configuración de protección, las subdirectivas controlan cómo se otorga o deniega el acceso basándose en las características de los directorios o archivos que se van a proteger.
Para definir una configuración de protección y cómo se aplica seleccione Configuración de servidor -> Protección de documentos en los formularios de Configuración y Administración. Utilice este formulario para los pasos siguientes:
Las normas de protección se aplican en el orden en el que se enumeran en la tabla del formulario de configuración. En general, las normas se enumeran de lo específico a lo genérico.
Utilice el menú desplegable y los botones para especificar la colocación de una norma de protección.
La protección se activa basándose en las plantillas de petición, que se comparan con el contenido de las peticiones que los clientes envían al servidor proxy.
Una petición es la parte de un URL completo que sigue al nombre del sistema principal del servidor. Por ejemplo, si su servidor se denomina fine.feathers.com y un navegador especifica el URL http://fine.feathers.com/waterfowl/schedule.html, el servidor recibe la petición /waterfowl/schedule.html. Las plantillas de petición especifican los nombres de archivo o de directorio, o ambos, que están sujetos a la protección. Por ejemplo, algunas peticiones que activan la protección basándose en la plantilla de petición recién descrita (/waterfowl/schedule.html) incluyen /waterfowl/* y /*schedule.html.
Escriba la plantilla de petición en el campo Plantilla de petición de URL.
Una configuración de protección indica a Caching Proxy qué hacer con una petición que coincida con una plantilla de petición. Puede utilizar una configuración de protección con nombre o definir una nueva configuración en el formulario Protección de documentos.
Para utilizar una configuración determinada, pulse el botón de selección Protección con nombre y escriba el nombre en el campo facilitado. Para definir una nueva configuración, pulse el botón de selección En línea y siga la instrucciones que se facilitan (consulte el paso 6).
Se pueden aplicar distintas normas a las peticiones de diferentes direcciones de servidor. Por ejemplo, es posible que desee aplicar una configuración de protección distinta a las peticiones de archivos de anotaciones cronológicas cuando estás peticiones se reciben desde direcciones IP asignadas a su empresa.
Si desea incluir la dirección del solicitante en la norma, escríbala en el campo Dirección IP de servidor o nombre de sistema principal.
Si ha utilizado una configuración de protección con nombre, no es necesaria más entrada. Si ha seleccionado una configuración de protección en línea o especificado una configuración determinada que no exista, el sistema abre formularios adicionales.
Si no ha especificado una configuración de protección con nombre existente, se abre un formulario adicional, en el que puede especificar qué usuarios pueden acceder a los documentos o directorios que coincidan con la plantilla de petición y qué acciones se les permiten a esos usuarios.
Para establecer la protección mediante la edición directa del archivo de configuración de Caching Proxy, primero debe estar familiarizado con los siguientes temas:
Las directivas de direccionamiento de peticiones como Map, Exec, Pass y Proxy se utilizan para controlar qué peticiones acepta el servidor y cómo redirecciona las peticiones a ubicaciones de archivo reales, El direccionamiento de peticiones utiliza el mismo tipo de plantillas de petición que las directivas de protección. Dado que se ejecutan las indicaciones asociadas con la primera plantilla coincidente de cada petición, deben enumerarse las directivas de protección antes que las directivas de direccionamiento en el archivo de configuración para que la protección se realice correctamente. Para obtener más información, consulte Protect: activar una configuración de protección de las peticiones que coinciden con una plantilla.
La directiva Protect puede utilizarse para especificar una configuración de protección en línea o puede hacer referencia a una configuración con nombre existente. La sintaxis de los dos tipos de sentencias es ligeramente distinta. Para obtener información, consulte Protect: activar una configuración de protección de las peticiones que coinciden con una plantilla.
Una configuración de protección es una serie de sentencias que utilizan las subdirectivas de protección. Encontrará la sintaxis y la información de referencia sobre cómo escribir las configuraciones de protección en el Apéndice B. Directivas del archivo de configuración; consulte los siguientes apartados de referencia:
El archivo de configuración de proxy por omisión incluye una configuración de protección que requiere un ID y una contraseña de administrador para acceder a los archivos del directorio /admin-bin/. Este valor limita el acceso a los formularios de Configuración y Administración.
SSL (Secure Sockets Layer) es un sistema que cifra automáticamente la información antes de enviarla a través de Internet y la descifra en el otro extremo antes de utilizarla. Con estas operaciones se protege la información confidencial como, por ejemplo, los dígitos de las tarjetas de crédito, mientras se transmite a través de Internet.
Caching Proxy utiliza SSL para proteger los servidores sustitutos y proporcionar una administración remota segura como se describe en los apartados siguientes. SSL también puede utilizarse para proteger las conexiones con los servidores de programa de fondo (por ejemplo, los servidores de contenido y de aplicaciones) además de las comunicaciones entre el servidor proxy y sus clientes.
Para el proxy de reenvío, Caching Proxy da soporte a los túneles SSL, que ignora SSL y reenvía los datos ya cifrados sin modificarlos.
La protección se inicia cuando se envía una petición de conexión segura desde una máquina a otra, por ejemplo, cuando un navegador envía una petición a un servidor proxy sustituto. La sintaxis de petición https:// en lugar de http:// indica al navegador que envíe la petición al puerto 443, que es donde el servidor escucha las peticiones de conexiones seguras, y no al puerto 80 para las peticiones rutinarias. Para establecer una sesión segura entre el navegador y el servidor, las dos máquinas realizan un intercambio denominado protocolo de enlace SSL para acordar una especificación de cifrado y seleccionar una clave que se utilice para cifrar y descifrar la información. Las claves se generan automáticamente y caducan cuando lo hace la sesión. Un escenario típico para SSL Versión 3 es el que se describe a continuación:
El cliente inicia una sesión SSL con Caching Proxy mediante el envío de un mensaje de saludo del cliente que describe las posibilidades de cifrado del cliente.
El servidor envía su certificado al cliente y elige el conjunto de cifrado que se va a utilizar para el cifrado de datos.
El cliente envía la información de claves de cifrado que se utilizan para crear las claves de cifrado simétricas de los datos cifrados. Este material de claves se conoce como secreto premaestro y se cifra con la clave pública del servidor, que se obtiene del certificado del servidor; consulte Gestión de claves y certificados. Tanto el servidor como el cliente pueden derivar las claves de cifrado simétricas de lectura y escritura a partir del secreto premaestro.
El servidor envía una confirmación final y un código de autenticación de mensajes (MAC) para todo el protocolo de establecimiento de comunicación).
El cliente envía un mensaje para validar el mensaje de finalización del servidor.
Si el cliente valida el mensaje de finalización del servidor, comienza el flujo de datos cifrado.
La utilización de Caching Proxy como punto final para las conexiones seguras puede reducir la carga de los servidores de contenido o de aplicación. Cuando Caching Proxy mantiene una conexión segura, realiza el cifrado, el descifrado y la creación de claves, que son todas operaciones de uso intensivo de la CPU. Asimismo, Caching Proxy le permite configurar los tiempos de espera de sesiones SSL para maximizar la utilización de todas las claves.
Limitaciones de SSL
Las siguientes limitaciones se aplican a SSL en Caching Proxy de WebSphere Application Server:
Durante volúmenes de tráfico altos de HTTPS, el servidor Caching Proxy puede causar un uso elevado de la CPU. Cambios en el ajuste de una variable de entorno (GSK_V3_SIDCACHE_SIZE) y de una directiva de proxy (SSLV3Timeout) pueden ayudar al servidor proxy a gestionar la carga y reducir el uso de CPU.
El ID de sesión de SSL identifica las sesiones SSL reutilizables, incluidas las claves de cifrado o descifrado utilizadas por ambos navegadores y servidores, y se utiliza para evitar protocolos de enlace SSL innecesarios en las conexiones nuevas, que consumen buena parte del tiempo de CPU del servidor. La biblioteca de GSKit para el servidor Caching Proxy da soporte al ID de sesión SSL e incluye una antememoria de ID de sesión SSL. Por omisión, la antememoria del ID de sesión SSL contiene 512 entradas. Cuando se alcanza el límite de la entrada, la entrada de sesión más antigua se eliminará y la nueva entrada se añadirá a la antememoria.
Utilice la variable de entorno GSK_V3_SIDCACHE_SIZE para cambiar el tamaño por omisión de la antememoria de ID de sesión SSL. Un valor válido de la variable está entre 1 y 4096. Si aumenta el tamaño, aumentará el tiempo de búsqueda necesario para localizar una sesión SSL en antememoria. No obstante, el aumento del tiempo de búsqueda es insignificante comparado con la actividad general que es necesaria para establecer una conexión SSL. Si aumenta el tamaño de la antememoria, ayudará al servidor proxy a gestionar más sesiones SSL simultáneas y reducir el uso de la CPU cuando el servidor proxy esté por debajo de cargas elevadas de HTTPS.
Caching Proxy también tiene una directiva ajustable, SSLV3Timeout. (Consulte el SSLV3Timeout: especificar el tiempo de espera antes de que caduque una versión de SSLV3.) El valor por omisión de la directiva es de 1000 segundos. Esta directiva define la duración de una sesión SSL en la antememoria de sesión. Si ninguna conexión SSL entrante utiliza una sesión SSL existente y la duración de la sesión sobrepasa este valor, la sesión será eliminada de la antememoria de sesión. Es recomendable que ajuste el valor de SSLV3Timeout a la duración típica de una sesión segura de cliente. Si el tiempo de espera es demasiado corto, puede reducir el rendimiento del proxy porque se necesitan varias sesiones de protocolo de enlace SSL para completar una sola sesión segura. Sin embargo, si el valor es demasiado grande, también puede perjudicar la seguridad de una sesión segura.
Sólo se aplica a configuraciones de proxy de reenvío.
Cuando Caching Proxy se configura como un proxy de reenvío, utiliza los túneles SSL para dar soporte a las conexiones seguras entre los clientes y los servidores de contenido. En los túneles SSL, los datos cifrados se pasan a través del servidor proxy sin experimentar modificaciones. Como el servidor proxy no descifra los datos, no se da soporte en los túneles SSL a las funciones que requieren que el servidor proxy lea las peticiones o las cabeceras de documento. Asimismo, las peticiones de túnel no se colocan en antememoria.
Figura 2 muestra cómo un conexión se establece mediante los túneles SSL.
El procedo de túneles SSL es el siguiente:
En un valor de proxy de reenvío, únicamente están disponibles los túneles SSL. Para habilitar los túneles SSL, seleccione Configuración de Proxy -> Valores de proxy en los formularios de Configuración y Administración.. Seleccione el recuadro de selección Túneles SSL.
El método CONNECT (que se habilita por omisión) también debe habilitarse para las conexiones de túneles SSL. Para habilitarlo en los formularios de configuración, seleccione Configuración de servidor -> Proceso de peticiones y utilice el formulario Métodos HTTP.
Se proporcionan tres opciones (OutgoingPorts, OutgoingIPs, IncomingIPs) para la directiva Enable CONNECT para la seguridad ampliada de túneles SSL. Es necesario que especifique un valor para OutgoingPorts como mínimo; en caso contrario, el método CONNECT no se habilitará.
Enable CONNECT OutgoingPorts [all | [port1|port1-port2|port1-*],...]Para permitir que los clientes se conecten sólo al puerto 443 de los servidores remotos para túneles SSL, establezca las directivas siguientes. (Normalmente, el puerto 443 es para peticiones HTTPS en el servidor remoto.)
Enable CONNECT OutgoingPorts 443 SSLTunneling onPara permitir que los clientes se conecten a cualquier puerto de los servidores remotos para túneles SSL, establezca las directivas siguientes:
Enable CONNECT OutgoingPorts all SSLTunneling onPara permitir que los clientes se conecten a los puertos 80, 8080-8088 y 9000 y superiores de los servidores remotos para túneles SSL, establezca las directivas siguientes:
Enable CONNECT OutgoingPorts 80,8080-8088,9000-* SSLTunneling on
Los puertos y los rangos de puertos se separan con una coma sin dejar ningún espacio en la lista.
IMPORTANTE: para las configuraciones de proxy de reenvío, especifique como mínimo 443 o all con la opción OutgoingPorts para habilitar los túneles SSL normales.
Enable CONNECT OutgoingIPs [[!]IP_pattern,...]Por ejemplo, para permitir que los clientes se conecten a cualquier puerto de los servidores remotos que coincida con la dirección IP/nombre de sistema principal *.ibm.com y que no coincida con 192.168.*.* , establezca las directivas siguientes:
Enable CONNECT OutgoingPorts all OutgoingIPs *.ibm.com,!192.168.*.* SSLTunneling on
Enable CONNECT IncomingIPs [[!]IP_Pattern,...]Por ejemplo, para permitir que los clientes procedentes de la dirección IP 192.168.*.* establezcan una conexión con cualquier puerto de los servidores remotos para túneles SSL, establezca las directivas siguientes:
Enable CONNECT OutgoingPorts all IncomingIPs 192.168.*.* SSLTunneling on
Para obtener más información para habilitar los túneles SSL y las directivas CONNECT editando el archivo de configuración de proxy, consulte los apartados de referencia del Apéndice B. Directivas del archivo de configuración correspondientes a las siguientes directivas:
La administración remota de Caching Proxy puede llevarse a cabo mediante las características de seguridad proporcionadas por SSL (Secure Sockets Layer) y la autenticación de contraseña. Con ello, se reduce significativamente la probabilidad de acceso al servidor proxy por las personas no autorizadas.
Para aplicar SSL durante la administración remota del servidor, utilice una petición https:// en lugar de una petición http:// para abrir los formularios de Configuración y Administración. Por ejemplo:
https://su.nombre.servidor/suPáginaPresentación.html
Como se ha indicado anteriormente, antes de configurar SSL, debe configurar una base de datos de claves y obtener o crear un certificado. Los certificados se utilizan para autenticar las identidades de servidor. Utilice el programa de utilidad IBM Key Management, en ocasiones denominado iKeyman, para configurar los archivos de certificación. Este programa de utilidad forma parte del software GSKit, que se incluye con Application Server. GSKit además incluye una interfaz gráfica basada en Java para abrir los archivos de certificados.
A continuación aparecen los pasos básicos para configurar los certificados y las claves SSL.
En todos los sistemas operativos excepto en Linux, si el certificado ha caducado, Caching Proxy no se iniciará de forma adecuada y aparecerá un mensaje de error indicando que la base de datos de claves ha caducado. En Linux, el proxy parece iniciarse, pero el proceso desaparece rápidamente y no se genera ningún mensaje de error.
Para prevenir este problema en los sistemas Red Hat Enterprise Linux 3.0, asegúrese de que los paquetes GCC estén en los niveles siguientes o superiores:
La clave pública debe asociarse con un certificado firmado digitalmente procedente de una autoridad certificadora (CA) designada como CA raíz de confianza del servidor. Puede comprar un certificado firmado sometiendo una petición de certificado a un proveedor de autoridades certificadoras (CA). Caching Proxy da soporte a las siguientes CA externas:
Por omisión, se designan como CA de confianza a las siguientes CA:
Este apartado proporciona una referencia rápida para utilizar el programa de utilidad IBM Key Manager (iKeyman). Utilice el gestor de claves para crear el archivo de base de datos de claves SSL, el par de claves pública y privada y la petición de certificado. Después de recibir el certificado firmado por la CA, utilice el gestor de claves para colocar el certificado en la base de datos de claves donde ha creado la petición de certificado original.
Con el software GSKit se incluye más documentación detallada sobre IBM Key Manager y GSKit.
Configure el sistema para que ejecute el gestor de claves
Antes de iniciar la GUI de IKeyman, realice las acciones siguientes:
ibmjcefw.jar ibmpkcs11.jar
ibmjceprovider.jar ibmpkcs.jar
local_policy.jar US_export_policy.jar
Actualice el archivo JAVA_HOME/jre/lib/security/java.security para añadir los proveedores IBM CMS y IBM JCE después del proveedor Sun. Por ejemplo:
security.provider.1=sun.security.provider.Sun security.provider.2=com.ibm.spi.IBMCMSProvider security.provider.3=com.ibm.crypto.provider.IBMJCE
Encontrará un ejemplo de archivo java.security en vía_acceso_instalación_GSKit/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
Inicio del gestor de claves
Inicie la interfaz gráfica de usuario del gestor de claves del siguiente modo:
Tenga en cuenta que si crea un nuevo archivo de base de datos de claves durante esta sesión, éste se almacena en el directorio a partir del cual se inició el gestor de claves.
Una base de datos de claves es un archivo que el servidor utiliza para almacenar un o más pares de claves y certificados. Se puede utilizar una base de datos de claves para todos los pares de claves y certificados o crear varias bases de datos. El programa de utilidad de gestión de claves se utiliza para crear nuevas bases de datos de claves y especificar sus contraseñas y archivos stash.
Para crear una base de datos de claves y un archivo stash:
La contraseña que especifique cuando cree una base de datos de claves nueva protege la clave privada. La clave privada es la única clave que puede firmar documentos o descifrar mensajes cifrados con la clase pública.
Utilice las siguientes directrices al especificar la contraseña:
Es aconsejable modificar la contraseña de base de datos de claves con frecuencia. No obstante, si especifica una fecha de caducidad para la contraseña, registre cuándo debe modificarse. Si la contraseña caduca antes de modificarla, se escribe un mensaje en las anotaciones cronológicas de error y se inicia el servidor, pero no puede realizar conexiones de red seguras.
Siga estos pasos para modificar la contraseña de base de datos de claves:
Para realizar una conexión SSL entre un proxy y un servidor LDAP, introduzca la contraseña de base de datos de claves en el archivo pac_keyring.pwd. Tenga en cuenta que el archivo pac_keyring.pwd no es el archivo stash generado por IKeyMan.
Creación de un nuevo par de claves y una petición de certificados
La base de datos de claves almacena pares de claves y peticiones de certificado. Para crear un par de claves pública y privada y una petición de certificado, siga los pasos siguientes:
Se ha creado una nueva petición de certificado satisfactoriamente en el archivo nombre_basedatos_archivo_claves.
Creación de un certificado autofirmado
Utilice el programa de utilidad de gestión de claves para crear un certificado de servidor autofirmado para habilitar las sesiones SSL entre los clientes y el servidor proxy mientras se espera que se envíe un certificado. Asimismo, puede utilizar certificados autofirmados sólo para pruebas.
Siga este procedimiento para crear un certificado autofirmado:
Claves de exportación
Utilice este procedimiento para exportar claves a otra base de datos de claves:
Importing keys (Claves de importación)
Para importar claves de otra base de datos de claves:
Listado de autoridades certificadoras
Para visualizar una lista de las autoridades certificadoras (CA) de confianza en la base de datos de claves:
Utilice este procedimiento para recibir un certificado que se le envíe electrónicamente desde una autoridad certificadora (CA) que esté designada como una CA de confianza por omisión (consulte la lista en Autoridades certificadoras). Si la CA que emite el certificado firmado por CA o no es una CA de confianza en la base de datos de claves, primero debe almacenar el certificado de la CA y designar la CA como una CA de confianza. Seguidamente ya puede recibir el certificado firmado por CA en la base de datos. No puede recibir un certificado firmado por CA de una CA que no sea de confianza (consulte Almacenamiento de un certificado de CA).
Para recibir un certificado firmado por CA en una base de datos de claves:
Sólo los certificados firmados por las CA de confianza se aceptan para establecer conexiones seguras. Para añadir una CA a la lista de autoridades de confianza, debe obtener y almacenar el certificado como de confianza. Siga este procedimiento para almacenar un certificado de una CA nueva, antes de recibirlo en la base de datos:
Visualización de la clave por omisión en una base de datos de claves
Visualice la entrada de clave por omisión del siguiente modo:
Los algoritmos de cifrado y hashes utilizados para SSL versiones 2 y 3 aparecen enumerados en las tablas siguientes.
Generación de pares de claves: tamaños de clave pública de RSA 512-1024
SSL Versión 2
Versión para EE.UU. | Versión para exportar |
RC4 US | RC4 Export |
RC2 US | RC2 Export |
DES 56-bit | no aplicable |
Triple DES US | no aplicable |
RC4 Export | no aplicable |
RC2 Export | no aplicable |
SSL Versión 3
Versión para EE.UU. | Versión para exportar |
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 bits | no aplicable |
DES CBC SHA | no aplicable |
NULL SHA | no aplicable |
NULL MD5 | no aplicable |
NULL NULL | no aplicable |
Estas especificaciones SSL también pueden configurarse editando directamente el archivo de configuración de proxy. Para obtener detalles, consulte los apartados de referencia del Apéndice B. Directivas del archivo de configuración para obtener información sobre las siguientes directivas:
Cifrado de 128 bits para Caching Proxy
Sólo está disponible una versión de cifrado de 128 bits de Caching Proxy. Ya no se puede acceder a la versión de 56 bits. Si está actualizando una versión anterior, puede instalar Caching Proxy directamente en la versión de 128 o 56 bits instalada actualmente. Si previamente utilizaba un navegador de 56 bits (de exportación), debe actualizarlo a un navegador de 128 bits para aprovechar el cifrado de 128 bits del proxy.
Después de actualizar Caching Proxy de la versión de 56 bits a la versión de 128 bits, si el tamaño de clave utilizado para cifrar los certificados se establece en 1024, no es necesario modificar la configuración. No obstante, si el tamaño de clave se establece en 512, para aprovechar el cifrado de 128 bits del proxy, debe crear nuevos certificados con un tamaño de clave de 1024. Cree claves nuevas mediante el programa de utilidad IBM Key Manager (iKeyman).
Consulte Gestión de claves y certificados para obtener información detallada del programa de utilidad IBM Key Manager.
Tenga en cuenta que esta versión del producto no da soporte al cifrado en SUSE Linux.
Sólo se aplica a configuraciones de proxy de retorno.
Siga este procedimiento para permitir que la rutina de protocolo de enlace SSL se descargue en una tarjeta de hardware criptográfico:
En AIX, para dar soporte a la tarjeta IBM 4960 PCI Cryptographic Accelerator Card, consulte PKCS11DefaultCert, PKCS11DriverPath, PKCS11TokenPassword -- Da soporte a la tarjeta IBM 4960 PCI Cryptographic Accelerator Card (sólo AIX).
Se proporciona un plug-in de Caching Proxy con Tivoli Access Manager (anteriormente Tivoli Policy Director) que permite que Caching Proxy utilice Access Manager para las funciones de autenticación y autorización. Este plug-in permite que una empresa que utilice Access Manager para el control de accesos a Internet con el fin de añadir la tecnología Edge sin tener que duplicar el trabajo mediante el establecimiento de esquemas de autorización separados para el servidor proxy.
Para obtener información adicional sobre Tivoli Access Manager, visualice el sitio Web del producto en http://www.ibm.com/software/tivoli/products/. Para obtener información sobre los requisitos de software y hardware y sobre la instalación del plug-in de Access Manager, consulte la documentación facilitada con Tivoli Access Manager.
Se facilita un script de configuración para Caching Proxy con el plug-in de Access Manager.
Antes de ejecutar el script, realice las siguientes acciones:
El script de configuración se denomina wslconfig.sh y se facilita en el directorio /opt/pdweb-lite/bin/. Especifique el ID de administrador de Access Manager y el nombre de administrador LDAP cuando se le soliciten.
El script de configuración automáticamente realiza los pasos siguientes:
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 una sentencia Protect y una configuración de protección que reenvía todas las peticiones al proceso de autenticación de Access Manager del siguiente modo:
Protection PROXY-PROT { ServerId WebSEAL-Lite Mask All@(*) AuthType Basic } Protect * PROXY-PROT
Después de configurar el servidor proxy y el plug-in de Access Manager, utilice el mandato wslstartwte en lugar de ibmproxy start para iniciar el servidor proxy. El mandato wslstartwte carga automáticamente las variables de entorno que el plug-in de Access Manager necesita para inicializarse. Si no utiliza wslstartwte al iniciar el servidor proxy, aparecerán mensajes de error sobre el plug-in de Access Manager. El mandato stop correspondiente, ibmproxy stop, aún es válido cuando se utiliza el plug-in.
El módulo de autorización PAC-LDAP permite que Caching Proxy acceda al servidor LDAP (Lightweight Directory Access Protocol) al realizar rutinas de autorización o autenticación. El módulo consta de dos conjuntos de componentes: un par de bibliotecas compartidas que añaden las funciones LDAP a la API de Caching Proxy y un daemon PAC (Policy Authentication Control). Una directiva ServerInit del archivo ibmproxy.conf indica a la biblioteca compartida que inicialice uno o más daemons PAC cuando se inicie Caching Proxy. Las bibliotecas compartidas leen un archivo paccp.conf para determinar el número y características de los daemons PAC. Durante la inicialización, el daemon lee el archivo pac.conf para las directivas de configuración y el archivo pacpolicy.conf para la información de políticas. A continuación, una directiva Authentication del archivo ibmproxy.conf indica al servidor proxy que llame a la biblioteca compartida siempre que la autenticación sea necesaria, o bien una directiva Authorization usurpa el flujo de trabajo de Caching Proxy durante el proceso de peticiones HTTP.
El proceso de autenticación determina si un conjunto proporcionado de credenciales - nombre de usuario y contraseña - es válido. Este proceso incluye la verificación de que un usuario esté en el registro y que la contraseña facilitada coincida con la contraseña almacenada en ese registro. A continuación, se indican las acciones realizadas mediante el módulo PAC-LDAP durante el paso de autenticación.
Cuando se habilita el módulo de autorización PAC-LDAP para las funciones de autenticación, se convierte en el depósito por omisión del que se obtienen los ID de usuario, las contraseñas y los grupos. Cuando una petición HTTP pasa a través del flujo de trabajo de Caching Proxy, todas las directivas Protect comparan el URL solicitado con la correspondiente plantilla de petición. Si se produce una coincidencia, la directiva Protect invoca un esquema de protección, que incluye el ID de servidor, el tipo de autenticación que se va a utilizar, las normas de enmascaramiento que se deben aplicar al cliente solicitante y las ubicación de los archivos de grupos y contraseñas. Si no se define el archivo de contraseñas, el ID de usuario y contraseña se recuperan a través del módulo de autorización PAC-LDAP. Las políticas del tipo 0, 1, 2 y 3 definen los esquemas de autenticación. Si se pasa la autenticación, se sirve la autenticación; de lo contrario, Caching Proxy devuelve un error 401 al cliente.
El proceso de autorización determina si un usuario tiene el permiso necesario para acceder al recurso protegido. Cuando se utiliza el módulo PAC-LDAP, es necesaria la aplicación de las normas de autorización que residan en el archivo pacpolicy.conf para la petición HTTP.
Cuando se habilita el módulo de autorización PAC-LDAP para las funciones de autorización, las normas de autorización del archivo pacpolicy.conf se aplican a la petición HTTP. Cuando una petición HTTP pasa a través del flujo de trabajo de Caching Proxy, todas las directivas Protect comparan el URL solicitado con la correspondiente plantilla de petición. Si se produce una coincidencia, la directiva Protect invoca un esquema de protección. En este caso, el esquema de protección es la rutina de autorización tomada por el módulo de autorización PAC-LDAP. La directiva Authorization compara el URL solicitado con la correspondiente plantilla de petición y, si se produce una coincidencia, se invoca al módulo de autorización PAC-LDAP. Las políticas de tipo 4 definidas en el archivo pacpolicy.conf que ajustan de forma adicional la autenticación necesaria para varias peticiones URL.
LDAP proporciona acceso interactivo a los directorios X.500 con un consumo mínimo de los recursos del sistema. IANA ha asignado el puerto TCP 389 y el puerto UDP 389 a LDAP. Para obtener más información, consulte RFC 1777, que define LDAP.
Son ejemplos de clientes LDAP soportados: el cliente LDAP de IBM Tivoli y el cliente LDAP de IBM SecureWay.
Todos los componentes del módulo de autorización PAC-LDAP se instalan automáticamente cuando se instala el sistema Caching Proxy de WebSphere Application Server, Versión 6.1. En los sistemas Linux y UNIX, se crean en el directorio /opt/ibm/edge/cp/ un directorio de biblioteca de Caching Proxy (./lib/), un directorio de biblioteca del módulo de autorización PAC-LDAP (./lib/plugins/pac/), un directorio de binarios (./bin/) y un directorio de configuración (./etc/). A continuación, se crean enlaces simbólicos desde los directorios /usr/lib/, /usr/sbin/ y /etc con estos directorios específicos de productos.
Estructura de directorio
Directorio Linux y UNIX | Directorio Windows | Contenido |
---|---|---|
/opt/ibm/edge/cp/ | \Archivos de programa\IBM\edge\cp\ | Directorio base de Caching Proxy ( raíz_cp) |
raíz_cp/sbin/ | \Archivos de programa\IBM\edge\cp\Bin\ | Binarios y scripts de Caching Proxy |
/usr/sbin/ | Enlaces simbólicos con raíz_cp/sbin/ | |
raíz_cp/etc/ | \Archivos de programa\IBM\edge\cp\etc\ | Archivo de configuración de Caching Proxy |
/etc/ | Enlaces simbólicos con raíz_cp/etc/ | |
raíz_cp/lib/ | \Archivos de programa\IBM\edge\cp\lib\ plugins\ | Bibliotecas de Caching Proxy |
raíz_cp/lib/ plugins/pac/ | \Archivos de programa\IBM\edge\ cp\lib\plugins\pac\ | Bibliotecas de módulo de autorización PAC-LDAP |
/usr/lib/ | Enlaces simbólicos con raíz_cp/lib/ y raíz_cp/lib/ plugins/pac/ | |
raíz_cp/server_root/pac/data/ | \Archivos de programa\IBM\ edge\cp\server_root\pac\data\ | Almacenamiento de datos de módulo de autorización PAC-LDAP |
raíz_cp/server_root/ pac/creds/ | \Archivos de programa\IBM\ edge\cp\server_root\pac\creds\ | Credenciales del módulo de autorización PAC-LDAP |
Archivos del plug-in LDAP
Nombre de archivo Linux y UNIX | Nombre de archivo Windows | Descripción |
---|---|---|
libpacwte.so | pacwte.dll | Biblioteca compartida |
libpacman.so | pacman.dll | Biblioteca compartida |
pacd_restart.sh | pacd_restart.bat | Script de reinicio de daemons PAC |
paccp.conf, pac.conf, pacpolicy.conf | paccp.conf, pac.conf, pacpolicy.conf | archivos de configuración y de políticas |
Para habilitar las conexiones SSL (Secure Sockets Layer) entre el daemon PACD y el servidor LDAP, debe instalar el paquete GSKit que el paquete de cliente LDAP necesita. GSKit 7 es necesario en la máquina de Caching Proxy, donde se facilita por omisión, pero es posible que no sea la versión que requiere el cliente LDAP en la máquina. Se pueden utilizar versiones distintas de GSKit en la misma máquina para procesos distintos.
Coloque el archivo de claves de GSKit en $pacd_creds_dir/pac_keyring.kdb y la contraseña en $pacd_creds_dir/pac_keyring.pwd.
En los sistemas Linux, la variable de entorno LD_PRELOAD debe configurarse del siguiente modo para habilitar las conexiones SSL entre el PACD y el servidor LDAP. Establezca la variable en el siguiente valor:
LD_PRELOAD=/usr/lib/libstdc++-libc6.1-1.so.2
El requisito de GSKit al que se hace referencia anteriormente también se aplica a los sistemas Linux.
En los sistemas Red Hat Enterprise Linux 4.0, el proceso PACD no se inicia cuando se configura Caching Proxy para utilizar el plug-in LDAP de ITDS 6.0 para realizar la autenticación. Se produce el siguiente mensaje de error:
"error while loading shared libraries: /usr/lib/libldapiconv.so: R_PPC_REL24 relocation at 0x0fb58ad0 for symbol 'strpbrk' out of range"
Existe actualmente la restricción de que ITDS 6.0 no da soporte a los sistemas RHEL 4.0.
El proceso PACD no se inicia en los sistemas AIX debido a unos enlaces no resueltos al utilizar el cliente LDAP de ITDS. Cuando se inicia el proceso PACD, podría producirse el siguiente error:
exec(): 0509-036 Cannot load program /usr/sbin/pacd because of the following errors: 0509-022 Cannot load module /usr/lib/libpacman.a. 0509-150 Dependent module libldap.a could not be loaded. 0509-022 Cannot load module libldap.a.
Para eludir este problema para ITDS versión 5 del cliente LDAP, cree el símbolo siguiente:
ln -s /usr/lib/libibmldap.a /usr/lib/libldap.a
Para eludir este problema para ITDS versión 6 del cliente LDAP, cree el símbolo siguiente:
ln -s /opt/IBM/ldap/V6.0/lib/libibmldap.a /usr/lib/libldap.a
Las tres directivas ServerInit, Authorization o Authentication, y ServerTerm deben añadirse al apartado de directivas API del archivo ibmproxy.conf para inicializar el módulo de autorización PAC-LDAP. Para crear estas directivas, edite el archivo ibmproxy.conf manualmente o, si el servidor proxy ya está en ejecución, conéctese a los formularios de Configuración y Administración con un navegador de Internet y abra el formulario Petición de proceso de API (Pulse Servidor de configuración -> Proceso de peticiones.-> Petición de proceso de API). Todas las directivas deben aparecer en una única línea en el archivo de configuración de proxy, independientemente de si los ejemplos proporcionados en este apartado contienen divisiones de línea para que sean legibles.
Tenga en cuenta que las directivas de prototipo (en forma de comentarios) se facilitan en el apartado API del archivo ibmproxy.conf. Estas directivas API aparecen en un orden determinado. Al añadir las directivas API para habilitar nuevas características y módulos de plug-in, ordene las directivas como se muestran en la parte de prototipo del archivo de configuración. Alternativamente, elimine los comentarios de las directivas API y edítelas, si es necesario, para incluir el soporte de todas las funciones o plug-ins deseados.
La directiva ServerInit tiene tres argumentos: (1) la vía de acceso plenamente cualificada de la biblioteca compartida, (2) la llamada de función y (3) la vía de acceso plenamente cualificado del archivo paccp.conf. El primer y segundo argumentos se delimitan por dos puntos (:). El segundo y tercer argumentos se delimitan por un espacio. El primer y tercer argumentos son específicos del sistema y dependen de dónde se han instalado los componentes de plug-in. El segundo argumento se codifica en la biblioteca compartida y debe escribirse exactamente como se muestra. Al crear una directiva ServerInit mediante el formulario Petición de proceso de API, tanto el segundo como el tercer argumento deben especificarse en el campo Nombre de función. El tercer argumento se muestra en la columna Plantilla de IP.
La directiva Authorization tiene tres argumentos: (1) una plantilla de petición, (2) la vía de acceso plenamente cualificada de la biblioteca compartida y (3) el nombre de función. Las peticiones HTTP se comparan con la plantilla de petición para determinar si se llama a la función de aplicación. La plantilla de petición puede incluir un protocolo, un dominio y un sistema principal; puede estar precedida por una barra inclinada (/), y puede utilizar un asterisco (*) como carácter comodín. Por ejemplo, las posibilidades /front_page.html , http://www.ics.raleigh.ibm.com, /pub*, /* y * son todas válidas. El nombre de función es el nombre asignado a la función de aplicación del programa. Está codificado y debe escribirse exactamente como se muestra. Los primeros dos argumentos se delimitan por un espacio. Los dos últimos argumentos se delimitan mediante dos puntos (:).
La directiva Authentication tiene dos argumentos: (1) la vía de acceso plenamente cualificada de la biblioteca compartida y (2) el nombre de función. Estos argumentos se delimitan por dos puntos(:). El primer argumento es específico del sistema y depende de dónde está instalada la biblioteca compartida. La plantilla de URL del primer argumento debe empezar en el directorio raíz de documentos (/) al utilizar Caching Proxy como proxy de retorno. El segundo argumento se codifica en la biblioteca compartida y debe escribirse exactamente como se muestra.
La directiva ServerTerm tiene dos argumentos: (1) la vía de acceso plenamente cualificada de la biblioteca compartida y (2) el nombre de función. Estos argumentos se delimitan por dos puntos(:). El primer argumento es específico del sistema y depende de dónde está instalada la biblioteca compartida. El segundo argumento se codifica en la biblioteca compartida y debe escribirse exactamente como se muestra. Esta directiva finaliza el daemon PAC cuando se cierra el servidor proxy. Si el propietario del daemon es distinto del propietario del servidor proxy, es posible que el servidor proxy no pueda detener el daemon, en cuyo caso un administrador debe detener manualmente el daemon.
ServerInit vía_acceso_biblioteca_compartida :pacwte_auth_init archivo_políticas_conf_vía_acceso
Ejemplo de Linux y UNIX:
ServerInit /usr/lib/libpacwte.so:pacwte_auth_init /etc/pac.conf
Ejemplo de 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 vía_de_biblioteca_compartida:pacwte_auth_policy
Ejemplo de Linux y UNIX:
Authorization http://* /usr/lib/libpacwte.so:pacwte_auth_policy
Ejemplo de Windows:
Authorization http://* C:\Archivos de programa\IBM\edge\cp\lib\plugins\ pac\pacwte.dll:pacwte_auth_policy
Authentication BASIC vía_acceso_biblioteca_compartida:pacwte_auth_policy
Ejemplo de Linux y UNIX:
Authentication BASIC /usr/lib/plugins/pac/libpacwte.so:pacwte_auth_policy
Ejemplo de Windows:
Authentication BASIC C:\Archivos de programa\IBM\edge\cp\lib\plugins\ pac\pacwte.dll:pacwte_auth_policy
ServerTerm vía_acceso_biblioteca_compartida:pacwte_shutdown
Ejemplo de Linux y UNIX:
ServerTerm /usr/lib/libpacwte.so:pacwte_shutdown
Ejemplo de Windows:
ServerTerm BASIC C:\Archivos de programa\IBM\edge\cp\lib\plugins\ pac\bin\pacwte.dll:pacwte_shutdown
Los archivos de configuración y de políticas del módulo de autorización PAC-LDAP deben editarse manualmente con un editor de texto. Un nombre de directiva se separa del primer argumento mediante dos puntos (:). Si existen varios argumentos se delimitan por comas (,). Los comentarios incluidos los archivos de configuración y de políticas ayudan a editarlos. A continuación se muestras las directivas de políticas más relevantes.
Las bibliotecas compartidas leen el archivo paccp.conf durante la inicialización de Caching Proxy y dicho archivo contiene las definiciones (apartado [PAC_MAN_SERVER]) de cada uno de los daemons PAC que se iniciarán. Todos los daemons PAC deben tener su propio apartado [PAC_MAN_SERVER].
[PAC_MAN_SERVER] hostname: # name of PAC daemon port: # port pacd is listening on [PACWTE_PLUGIN] hostname_check:[true|false] # enables DNS lookup. Must have # DNS lookup turned on for ibmproxy to work.
El archivo pac.conf especifica el servidor LDAP con el que el daemon PAC intenta conectarse.
[PAC_MAN_SERVER]
hostname: # name of PAC daemon
port: # port pacd is listening on
conn_type:ssl # comment out if you do not use SSL
authentication_sequence: [primary|secondary|none]
authorization_sequence: [primary|secondary|none]
[LDAP_SERVER]
hostname: # LDAP Server hostname
port:389 # Port LDAP is listening on
ssl_port:636 # SSL port used by the LDAP server
admin_dn: # User with permission to access the LDAP server
# specify admin_dn:NULL to enable anonymous binding
search_base: # Portion of LDAP tree to search for policy info
# If not required, specify search_base:NULL
search_key: # ID field to search
[CACHE]
cred_cache_enabled [TRUE|FALSE] # turn credentials cache on
cred_cache_min_size:100 # minimum number of credentials to cache in pacd
cred_cache_max_size:64000 # maximum number of credentials to cache in pacd
cred_cache_expiration:86400 # when a credential expires
policy_cache_enabled:[TRUE|FALSE] # turns policy cache on/off
policy_cache_min_size:100 # min. number of policy related items to cache
policy_cache_max_size:64000 # max. number of policy related items to cache
policy_cache_expiration:86400 # when a policy related item expires
Todas las políticas LDAP utilizan la siguiente plantilla en los archivos de configuración y de políticas. Todas las políticas deben empezar por la palabra clave en mayúscula POLICY entre paréntesis.
[POLICY] default_policy:[grant|deny] # describes the default policy for users # that are not described in the POLICY section pac_client_hotname: # the instances of Caching Proxy that are allowed # to use a policy list id: # the id for the LDAP entry or ip/hostname # (wildcard supported, such as *.ibm.com) grant:[true|false] # true means to grant access, false means # to deny access type:[0|1|2|3|4] # 0 LDAP entry that is a group, # 1 LDAP entry that is not a group, # 2 IP address # 3 hostname # 4 URL propagate:[true|false] # true means that the access rights (grant # or deny) will be propagated to all # descendants or members stop_entry:[entry|NULL] # Propagation of the access right stops # at this entry. If the id is a group, # stop_entry must be set to NULL. # stop_entry may be applied to an IP # address or hostname. Each stop_entry # must be on its own line exception_entry:[entry|NULL] # Assignment of the access right skips # these entries, but continues through their # subtrees. This may be a list of entries. # exception_entry may be applied to a group, # IP address, or hostname. Each # exception_entry must be on its own line. Exception_type: Exception:
Sólo se da soporte al carácter comodín (*) cuando ocupa la última posición de una dirección IP o la primera posición de un nombre de sistema principal de las directivas id y stop_entry . Los caracteres comodín no reciben soporte en exception_entry . Tampoco se da soporte a los caracteres comodín en las entradas LDAP de cualquier campo.
Se da soporte a varias políticas y, si las políticas entran en conflicto, el valor false siempre tiene preferencia. Es decir, se bloquea el acceso sólo con que se produzca una única denegación en cualquier política. El orden en que se enumeran las políticas en los archivos de configuración y de políticas es irrelevante y no establece ninguna prioridad.
Para obtener un conjunto de ejemplos de políticas, consulte el archivo the pacpolicy.conf del directorio de archivos de configuración.
Cree un archivo de texto plano denominado pac_ldap.cred en /raíz_cp/server_root/pac/creds . Este archivo contiene la contraseña correspondiente al nombre de usuario de la directiva admin_dn, que se encuentra en el archivo pac.conf.
El daemon PAC cifra la contraseña la primera vez que lee el archivo.
Para crear el archivo pac_ldap.cred en las plataformas Linux y UNIX, emita los siguientes mandatos:
cd raíz_cp/server_root/pac/creds echo "password" > pac_ldap.cred chown nobody pac_ldap.cred chgrp nobody pac_ldap.cred (en SUSE Linux, utilice chgrp nogroup pac_ldap.cred.)
Para crear el archivo en una plataforma Windows, escriba la contraseña en un archivo de texto y almacene el archivo en el directorio server_root\pac\creds\.
El daemon de autorización LDAP se ejecuta como el proceso pacd. Puede reiniciar el daemon de autorización LDAP sin interrumpir Caching Proxy mediante la utilización de los scripts que se facilitan. Ejecute el script pacd del modo siguiente:
/usr/sbin/pacd_restart.sh id_usuario_pacd
C:\Archivos de programa\IBM\edge\cp\Bin\pacd_restart.bat raíz_instalación_CP
kill -15 ID_proceso_pacd
En HP-UX: es posible que el plug-in PAC-LDAP y pacd no carguen todas las bibliotecas compartidas dependientes durante el tiempo de ejecución. Antes de utilizarlos, asegúrese de que las variables de sistema estén establecidas del siguiente modo
SHLIB_PATH=/usr/lib:/usr/IBMldap/lib PATH=/usr/IBMldap/bin:$PATH PATH=/usr/IBMldap/bin/usr/IBMldap/
es la vía de acceso de instalación por omisión del cliente LDAP en HP-UX. Se recomienda que ajuste PATH y SHLIB_PATH según corresponda si el cliente LDAP se instala en una ubicación distinta. Sin establecer estas variables, pueden ocurrir los siguientes errores:
"Serverinit Error: server did not load functions from DLL module /opt/ibm/edge/cp/lib/plugins/pac/libpacwte.sl"
"/usr/lib/dld.sl: Can't find path for shared library: libibmldap.sl /usr/lib/dld.sl: No such file or directory Abort"
En Linux: en SUSE Linux Enterprise Server 9, ldd pacd podría informar que no se encuentra libldap.so. Para evitar este problema, cree el siguiente enlace simbólico:
ln -s /usr/lib/libldap.so.19 /usr/lib/libldap.so
En AIX: al iniciar pacd con IBM Tivoli Directory Server 5.2, es posible que el módulo PAC-LDAP no pueda cargarse y se genere el siguiente error:
exec(): 0509-036 Cannot load program /usr/sbin/pacd because of the following errors: 0509-022 Cannot load module /usr/lib/libpacman.a. 0509-150 Dependent module libldap.a could not be loaded. 0509-022 Cannot load module libldap.a.
Para evitar este problema, cree el siguiente enlace simbólico:
ln -s /usr/lib/libibmldap.a /usr/lib/libldap.a
Could not extract a value for: Uid, return code:3Este error se mostrará incluso cuando la autenticación LDAP funcione correctamente y puede hacerse caso omiso de él.
Esta parte proporciona las instrucciones para supervisar Caching Proxy utilizando las anotaciones cronológicas y el Supervisor de actividad de servidor
Esta parte contiene los siguientes temas:
Configuración de las anotaciones cronológicas
Utilización del Supervisor de actividad del servidor
Para personalizar las anotaciones cronológicas, puede utilizar los formularios de Configuración y Administración o editar las directivas del archivo de configuración de proxy. Puede establecer las siguientes opciones:
Caching Proxy puede crear tres tipos de anotaciones cronológicas de acceso, además de las anotaciones cronológicas de sucesos y las anotaciones cronológicas de error:
Caching Proxy crea nuevos archivos de anotaciones cronológicas todos los días a las doce de la noche. Si el proxy no se está ejecutando a esa hora, se crean nuevas anotaciones cronológicas la primera vez que se inicia ese día. Puede especificar el directorio y el prefijo de nombre de archivo de todos los archivos de anotaciones cronológicas. Todos estos archivos creados también contienen un sufijo de fecha con el formato .Mmmddaaaa (por ejemplo, .Apr142000).
Como las anotaciones cronológicas pueden utilizar una gran cantidad de espacio, se le recomienda que almacene los archivos de anotaciones cronológicas en un dispositivo de almacenamiento que sea independiente del sistema operativo y de la antememoria para prevenir errores. Asimismo, configure las rutinas de mantenimiento como se especifica en Mantenimiento y archivado de las anotaciones cronológicas.
Para especificar la configuración básica de las anotaciones cronológicas de servidor proxy, seleccione Configuración de servidor -> Anotación cronológica -> Archivos de anotaciones cronológicas en los formularios de Configuración y Administración. Especifique la vía de acceso y el nombre de archivo de todos los archivos de anotaciones cronológicas que desee utilizar. El nombre de archivo actual de cada uno de los archivos de anotaciones cronológicas se muestra en el recuadro de texto correspondiente. Si no ha especificado una vía de acceso, se visualiza la vía de acceso por omisión.
La información que se anota cronológicamente en las anotaciones cronológicas del proxy no se escribe automáticamente en las anotaciones cronológicas del sistema, pero puede configurar Caching Proxy para que escriba en las anotaciones cronológicas del sistema además de sus propias anotaciones cronológicas o en lugar de ellas. En el formulario Archivos de anotaciones cronológicas, seleccione el recuadro de selección Registrar información en Syslog. Tenga en cuenta que las anotaciones cronológicas del sistema deben crearse antes de que se seleccione esta opción.
Para especificar que la información de las anotaciones cronológicas del servidor proxy se escriban únicamente en las anotaciones cronológicas del sistema, debe editar el archivo de configuración de proxy. Consulte el apartado de referencia LogToSyslog: especificar si se va a enviar la información de acceso a las anotaciones cronológicas del sistema (Linux y UNIX sólo).
Directivas de archivos de configuración relacionadas
Para configurar las anotaciones cronológicas mediante el archivo de configuración de proxy, consulte los apartados de referencia del Apéndice B. Directivas del archivo de configuración para obtener información sobre las siguientes directivas:
Las anotaciones cronológicas registran la actividad de la máquina del sistema principal, el proxy y la antememoria. Para todas las peticiones de acceso que recibe el proxy, existe una entrada de las anotaciones cronológicas adecuadas que incluye la siguiente información:
Los errores de acceso se anotan cronológicamente en las anotaciones cronológicas de error del servidor.
Existen varias razones para limitar qué elementos se anotan cronológicamente:
Los archivos de anotaciones cronológicas de un servidor ocupado pueden hacerse lo suficientemente grande para ocupar todo el espacio de disco del servidor. Por omisión, todas las peticiones de acceso se anotan cronológicamente, lo que significa que las entradas de anotaciones cronológicas se realizan no sólo para una página HTML sino también para todas las imágenes que contiene la página. La inclusión sólo de las peticiones de acceso relevantes puede reducir significativamente el número de entradas en las anotaciones cronológicas. Por ejemplo, es posible que desee configurar las anotaciones cronológicas de acceso para que incluyan las entradas de anotaciones cronológicas de las peticiones de acceso a las páginas HTML pero no de las peticiones de imágenes GIF.
Por ejemplo, si está interesado en quién está accediendo al servidor desde fuera de la empresa, puede especifica run filtro que excluya las peticiones de acceso que se originan a partir de las direcciones IP de la empresa. Si está interesado en averiguar el volumen de usuarios que visitan un determinado sitio Web, puede crear anotaciones cronológicas de acceso que sólo muestren las peticiones de acceso a ese URL.
La información que se excluye de las anotaciones cronológicas de acceso no se registra en ningún informe de acceso y no está disponible para su uso futuro. Por lo tanto, si no está seguro de la cantidad de información sobre la que es necesario hacer un seguimiento, aplique los filtros de exclusión con moderación hasta que tenga la suficiente experiencia en la supervisión del servidor.
Las entradas de anotaciones cronológicas de acceso pueden filtrarse basándose en cualquiera de los atributos siguientes:
Para especificar los filtros, seleccione Configuración de servidor -> Exclusiones de anotaciones cronológicas de acceso en los formularios de Configuración y Administración. Especifique sólo las exclusiones que desee. No es necesario que utilice todas las categorías.
Pulse Someter.
Directivas de archivos de configuración relacionadas
Para establecer los filtros de anotaciones cronológicas de acceso mediante el archivo de configuración de proxy, consulte los apartados de referencia del Apéndice B. Directivas del archivo de configuración para obtener información sobre las siguientes directivas:
Todas las anotaciones cronológicas se habilitan en la configuración por omisión de Caching Proxy. Se almacenan en el subdirectorio logs/ del directorio de instalación. Las vías de acceso por omisión son las siguientes:
Todos los nombres de archivo de anotaciones cronológicas son una combinación del nombre base y un sufijo de fecha con el formato .Mmmddaaaa, por ejemplo, proxy.Feb292000.
Las anotaciones cronológicas se almacenan en el formato de archivo común por omisión. También está disponible un formato de anotaciones cronológicas combinado, que puede establecerse añadiendo la siguiente línea al archivo de configuración de proxy (ibmproxy.conf).
LogFileFormat combined
El formato de anotaciones cronológicas combinado es parecido al formato común pero tiene campos añadidos que muestran al referente, el agente de usuario y la información de cookie. El formato de tiempo local es el formato de tiempo por omisión.
Por omisión, todas las peticiones de acceso se registran en las anotaciones cronológicas de acceso adecuadas y no se registra ninguna información de acceso en las anotaciones cronológicas del sistema. La información de anotaciones cronológicas de error sólo se escribe en las anotaciones cronológicas de error y la información de anotaciones cronológicas de sucesos sólo en las anotaciones cronológicas de sucesos.
En la configuración por omisión, las anotaciones cronológicas no se archivan ni se suprimen.
Caching Proxy utiliza un plug-in para gestionar las anotaciones cronológicas. Para obtener más información, consulte la página de referencia en el Apéndice B. Directivas del archivo de configuración para obtener información sobre la directiva del archivo de configuración Midnight: especificar el plug-in de API utilizado para archivar las anotaciones cronológicas.
Ahora puede especificar cómo archivar y eliminar las anotaciones cronológicas diariamente. Las opciones básicas son:
Por omisión, las anotaciones cronológicas del día actual y de los días anteriores no se suprimen nunca mediante un agente de mantenimiento. Todas las anotaciones cronológicas del día actual y las anotaciones cronológicas de acceso a la antememoria de los días anteriores nunca se comprimen mediante el agente de mantenimiento.
Para configurar el mantenimiento de las anotaciones cronológicas, seleccione Configuración de servidor -> Anotación cronológica -> Archivado de anotaciones cronológicas en los formularios de Configuración y Administración. En este formulario, utilice el recuadro desplegable para especificar el método de mantenimiento.
Directivas relacionadas del archivo de configuración
Para configurar el archivado de anotaciones cronológicas mediante el archivo de configuración de proxy, consulte las páginas de referencia del Apéndice B. Directivas del archivo de configuración para obtener información sobre las siguientes directivas:
El siguiente ejemplo muestra cómo puede personalizar el registro cronológico para satisfacer sus necesidades. Suponga que acaba de adquirir e instalar Caching Proxy. Y desea configurar el servidor para anotar cronológicamente la información de error y acceso con los siguientes requisitos:
Para configurar Caching Proxy de modo que mantenga las anotaciones cronológicas de acuerdo con estos criterios, en los formularios de Configuración y Administración, seleccione Configuración de servidor -> Anotación cronológica.
Si se siguen estas instrucciones, se generan las siguientes líneas en el archivo de configuración de proxy:
LogArchive purge PurgeAge 30 PurgeSize 25 AccessLogExcludeURL *.gif NoLog 130.128.*.* AccessLogExcludeReturnCode 300
El Supervisor de actividad de servidor de Caching Proxy muestra las estadísticas del rendimiento de red y de servidor, el estado de la red y el servidor, y las entradas de anotaciones cronológicas de acceso. El supervisor puede utilizarse de forma remota y no es necesario que esté en la misma máquina en la que se está ejecutando el servidor proxy. El Supervisor de actividad del servidor se habilita por omisión y no requiere ninguna configuración.
Existen dos formas de abrir el Supervisor de actividad del servidor:
http://su.nombre.servidor/Usage/Initial
A diferencia de otros formularios del cliente de configuración, los formularios de esta categoría no establecen las configuraciones del servidor, pero visualizan los datos sobre el uso del servidor. Estos formularios proporcionan mucha más información de la que puede visualizarse en una única ventana de la consola.
Los apartados siguientes muestran el tipo de información que proporciona Supervisor de actividad de servidor y sugieren cómo utilizar la información para ajustar el rendimiento.
Existen varias páginas de Supervisor de actividad de servidor a las que se puede acceder:
Todas las páginas tienen un botón Renovar, que se pueden utilizar para actualizar la información.
Estadísticas de actividad
La Tabla 4 muestra un ejemplo de la página de Estadísticas de actividad.
Estadísticas de actividad | |
---|---|
Conexiones | 1 Activa, 431 como máximo |
Tiempo de respuesta | No está disponible |
Productividad | 0 conexiones/segundo |
Peticiones procesadas hoy | 0 |
Total de peticiones procesadas | 114 |
Errores de petición | 3 |
Estas estadísticas de actividad del servidor pueden utilizarse para supervisar el tráfico del servidor en términos del número de peticiones de acceso, tiempo de respuesta, productividad, peticiones procesadas hoy, total de peticiones procesadas y errores. Los siguientes cambios de configuración tienen un efecto sobre las estadísticas de la página Actividad.
Estadísticas de red
Tabla 5 muestra un ejemplo de la página de Estadísticas de red.
Estadísticas de red | |
---|---|
Datos de salida: | 1K bytes/segundo |
Datos de entrada: | 1K bytes/segundo |
Ancho de banda guardado: | 3 K bytes (0 K bytes/segundo) |
Ancho de banda guardado hoy: | 0 K bytes (0 bytes/segundo) |
El formulario Estadísticas de red proporciona información sobre la red en la que se está ejecutando el proxy, incluidas las velocidades de los datos enviados y recibidos.
Estadísticas de acceso
La página Estadísticas de acceso muestra las 20 entradas más recientes de las anotaciones cronológicas de acceso. Esta página muestra las entradas más recientes de las anotaciones cronológicas de acceso al proxy (en caracteres negros) y de las anotaciones cronológicas de acceso a la antememoria (en caracteres azules). Puede personalizar los datos que se muestran personalizando los datos que se anotan cronológicamente. Para obtener más información sobre las estadísticas de las anotaciones cronológicas de acceso, consulte Filtros de las anotaciones cronológicas de acceso.
Estadísticas de acceso a proxy
El formulario Estadísticas de acceso a proxy proporciona información sobre la actividad del proxy como, por ejemplo, cuáles son los URL que se han solicitado y si se han servido desde la antememoria. Después de los URL aparecen los códigos de retorno proporcionados a los clientes y el tamaño de archivo en bytes. Los siguientes valores pueden mejorar las estadísticas de acceso a proxy:
Estadísticas de antememoria
Si se habilita la colocación en antememoria, la página Estadísticas de antememoria muestra la información reciente de acceso a la antememoria. Proporciona información sobre la antememoria y el índice, incluidos los siguientes aspectos:
Muchas de las opciones de configuración de la antememoria modifican los resultados de las estadísticas de antememoria (consulte la Configuración de la antememoria y el servidor proxy).
Resumen de renovación de la antememoria
Si el agente de antememoria se configura para cargar previamente los archivos en la antememoria, la página Resumen de renovación de la antememoria muestra la información sobre la ejecución mas reciente del agente de antememoria. El agente de antememoria debe haberse ejecutado como mínimo una vez para mostrar cualquier información. Para modificar el modo en que funciona el agente de renovación de antememoria, tenga en cuenta los siguientes puntos:
Este tema proporciona una referencia de los mandatos del servidor proxy.
Utilice el mandato cgiparse para analizar la variable de entorno QUERY_STRING para los scripts CGI. Si no se establece la variable de entorno QUERY_STRING, el mandato lee los caracteres de CONTENT_LENGTH de la entrada estándar. Toda la salida devuelta se escribe en la salida estándar.
cgiparse -Distintivo [Modificador]
Los distintivos, junto con sus equivalentes de un único carácter (-k -f -v -r -i -s -p -c -q -P) y funciones, son:
eval 'cgiparse -init'
Con ello se establece la variable de entorno QUERY_STRING, independientemente de si se ha utilizado el método GET o POST.
Cuando se utiliza el método GET, cgiparse puede llamarse en el mismo script varias veces, pero, si se utiliza el método POST, sólo debe llamarse una vez. Con el método POST, después de la lectura de la entrada estándar, el siguiente mandato cgiparse encuentra vacía la entrada estándar y espera indefinidamente.
Los siguientes ejemplos ignoran el hecho de que, en realidad, el servidor ya ha establecido QUERY_STRING. En los siguientes ejemplos, $ es el indicador del 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! $
Utilice el mandato cgiutils en programas de cabecera que no sean resultado de análisis para producir una respuesta HTTP 1.0 completa.
cgiutils -Distintivo [Modificador]
Si Modificador contiene espacios en blanco, inclúyalo entre comillas ("").
cgiutils -ct text/html
Si omite tipo/subtipo, el tipo de contenido MIME se establece en el valor por omisión text/plain. Este ejemplo establece el tipo de contenido MIME en text/plain.
cgiutils -ct
cgiutils -ce x-compress
cgiutils -cl en_UK
cgiutils -expires 2 days 12 hours
El mandato cgiutils añade el tiempo que especifique a la Hora Media de Greeenwich actual para determinar la fecha de caducidad. La fecha de caducidad se incluye en la cabecera Expires: en el formato HTTP.
cgiutils -expires "1 year 3 months 2 weeks 4 days 12 hours 30 mins"
cgiutils -status 200 -reason "Aparece un doc virtual" -expires now
Es posible que se generen cabeceras parecidas a éstas:
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
El mandato cgiutils produce automáticamente la cabecera Server:, ya que está disponible en el entorno CGI. El campo Date: también se genera automáticamente a menos que se especifique el distintivo -nodate.
Este ejemplo incluye una línea después de la salida para marcar el final del apartado de la cabecera MIME. Si desea continuar este ejemplo con más cabeceras, utilice el distintivo -noel archivo-configuración(NO-Empty-Line) tal como se muestra en el siguiente ejemplo.
cgiutils -noel -expires "2 days" -nodate
HTTP/1.0 200 Virtual doc follows MIME-Version: 1.0 Server: IBM-ICS Expires: Tue, 07 Jan 1996 03:43:46 GMT
Utilice el mandato htadm para controlar los archivos de contraseñas del servidor. El servidor utiliza archivos de contraseñas para controlar el acceso a los archivos. Puede añadir un nombre de usuario al archivo de contraseñas, suprimir un usuario de un archivo de contraseñas, verificar una contraseña de usuario y crear un archivo de contraseñas vacío. Asimismo, puede modificar la contraseña de un usuario, suprimiendo primero la contraseña del usuario y creando, a continuación, una nueva.
htadm -Distintivo [Modificador]
Utilice únicamente caracteres alfanuméricos para el nombre de usuario; no utilice caracteres especiales.
El mandato no se ejecuta correctamente si ya existe un usuario con el mismo nombre en el archivo de contraseñas.
Las contraseñas pueden tener una longitud de hasta 32 caracteres. Utilice únicamente caracteres alfanuméricos para la contraseña; no utilice caracteres especiales.
Las contraseñas pueden tener una longitud de hasta 32 caracteres. Utilice únicamente caracteres alfanuméricos para la contraseña; no utilice caracteres especiales.
htadm -adduser /opt/ibm/edge/cp/server_root/protect/heroes.pwd clark superman "Clark Kent"
htadm -adduser "C:\Archivos de programa\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:\Archivos de programa\IBM\edge\cp\server_root\protect\ heroes.pwd" clark superman "Clark Kent"
Utilice el mandato htcformat para preparar un dispositivo o archivo sin procesar para albergar la antememoria de proxy. Este mandato de formato debe utilizarse antes de que se especifique el dispositivo para utilizarlo con la antememoria de proxy.
La vía de acceso del dispositivo debe especificar el dispositivo original. Consulte la documentación del sistema de archivos para obtener información detallada sobre cómo acceder a los dispositivos originales. Podrá acceder a los ejemplos en la Configuración de la antememoria y el servidor proxy.
El tamaño mínimo de una antememoria de Caching Proxy es de 16392 KB, que equivale a 2049 bloques.
htcformat dispositivo [-blocksize <tamaño de bloque>] [-blocks número de bloques] htcformat -file vía_acceso_archivo [-blocksize tamaño de bloque] -blocks número de bloques
Adicionalmente, el sistema de colocación en antememoria divide los archivos y dispositivos de antememoria en contenedores para la indexación y la recogida de basura. El tamaño de los contenedores se establece en un determinado número de bloques y no se puede configurar. Para que la recogida de basura se ejecute, son necesarios dos contenedores cómo mínimo, siendo el tamaño mínimo de antememoria de 16392 KB.
El mandato htcformat rechaza una petición de formulario que genere un dispositivo de antememoria con menos de dos contenedores.
El ejemplo siguiente formatea una partición de disco llamada c0t0d0s0 en Solaris.
htcformat /dev/rdsk/c0t0d0s0
El ejemplo siguiente formatea una partición de disco llamada lv02 en AIX.
htcformat /dev/rlv02
El ejemplo siguiente formatea una partición de disco llamada d en Windows.
htcformat \\.\d:
El siguiente ejemplo formatea un archivo denominado filecache para que tenga un tamaño de 1 GB.
htcformat -file /opt/ibm/edge/cp/filecache -blocks 131072
Utilice el mandato ibmproxy para iniciar el servidor.
Puede establecer todos estos distintivos (excepto -r) mediante las directivas del archivo de configuración del servidor.
Es una práctica habitual crear un archivo denominado README que contenga las instrucciones y avisos que debe leer cualquier persona que acceda por primera vez al directorio. Por omisión, el mandato ibmproxy incorpora cualquier archivo README en la versión de hipertexto de un directorio. Las instrucciones del archivo README también pueden establecerse con la directiva de configuración DirReadme.
ibmproxy [-Distintivo [-Distintivo [-Distintivo..]]]
Como el daemon http debe leer el archivo de configuración que el servidor está utilizando actualmente para acceder al PidFile, debe especificar el mismo archivo de configuración durante el reinicio. Si ha utilizado el distintivo -r y un archivo de configuración específico al iniciar el servidor, debe especificar este distintivo y el mismo archivo con -restart.
Las opciones del manejo de señales también existen en las plataformas Linux y UNIX. En las plataformas Linux y UNIX, están disponibles las siguientes opciones.
ibmproxy -p 8080 -r /usr/etc/ibmproxy.conf
startsrc -s ibmproxy
Si el archivo de configuración por omisión no existe, el mandato ibmproxy exporta el árbol de directorios /Public. Este árbol contiene enlaces con otros árboles de directorios.
Este tema describe las directivas que se incluyen en el archivo de configuración ibmproxy.conf.
Utilice esta información como referencia si configura el servidor mediante la edición del archivo ibmproxy.conf. Si utiliza los formularios de Configuración y Administración, es necesario que consulte este capítulo.
Las directivas se enumeran por orden alfabético.
Algunas directivas no se renuevan cuando el servidor se reinicia. Si las siguientes directivas se modifican mientras se está ejecutando el servidor, debe detener y reiniciar el servidor manualmente. (Consulte el Inicio y detención de Caching Proxy.)
Grupo de directivas | Directivas |
CGI | DisinheritEnv, InheritEnv |
Colocación en antememoria | Caching |
Registro cronológico | AccessLog, CacheAccessLog, ErrorLog, ProxyAccessLog, ServerRoot |
Acceso a red | BindSpecific, Hostname, ListenBacklog, Port |
Rendimiento | MaxActiveThreads |
RTSP | Todas las directivas RTSP |
SSL | Todas las directivas SSL |
Control de procesos Linux y UNIX | GroupId, UserId |
Varios | TransparentProxy |
Este apéndice proporciona la siguiente información sobre todas las directivas:
NombreDirectiva valor
Estos son los valores originales codificados en el archivo de configuración por omisión. Modifique sólo las partes del archivo de configuración que desee que sean distintas de los valores por omisión. Una directiva que no tiene un valor por omisión codificado inicialmente aparece en el archivo precedida por un marcador de comentario (#). Si desea especificar un valor para la directiva, elimine el marcador de comentario y añada el valor a la línea del archivo de configuración.
La siguiente lista incluye los valores que se aceptan en el archivo de configuración:
Todas las entradas se convierten a segundos y éstos se suman.
Al editar el archivo de configuración, recuerde los siguiente requisitos:
A continuación aparecen las directivas de Caching Proxy.
Utilice esta directiva para servir los archivos al cliente incluso si el tipo MIME del archivo no coincide con una cabecera ACCEPT: enviada por el cliente. Si esta directiva se establece en OFF, no se visualizan los archivos cuyos tipos MIME son distintos de los tipos que el cliente puede aceptar. En su lugar se visualiza una página de error.
AcceptAnything {on | off}
AcceptAnything off
AcceptAnything on
Utilice esta directiva para especificar el directorio y el archivo donde desea que el servidor anote cronológicamente las estadísticas de acceso. Por ejemplo, el servidor escribe una entrada en estas anotaciones cronológicas cada vez que un cliente envía al servidor una petición de datos almacenados en el servidor local. Generalmente, estas entradas sólo incluyen las peticiones del cliente de configuración o accesos cuando la máquina de Caching Proxy se utiliza como un servidor de origen. Estas anotaciones cronológicas no contienen la información de acceso a la antememoria o al proxy.
Utilice la directiva NoLog para especificar los clientes cuyas peticiones no desea anotar cronológicamente. Para obtener una descripción de la directiva NoLog, consulte NoLog: suprimir las entradas de anotaciones cronológicas de los sistemas principales o dominios específicos que coinciden con una plantilla.
El servidor inicia un nuevo archivo de anotaciones cronológicas cada día a las doce de la noche si se está ejecutando. De lo contrario, el servidor inicia un nuevo archivo de anotaciones cronológicas la primera vez que se inicia en un día cualquiera. Al crear el archivo, el servidor utiliza el nombre de archivo que especifique y añadirá un sufijo de fecha. El sufijo de fecha aparece en el formato Mmmddaaaa, donde Mmm son las tres primeras letras del mes, dd es el día del mes y aaaa es el año.
Se recomienda eliminar los archivos de anotaciones cronológicas antiguos ya que pueden utilizar una cantidad significativa de espacio de la unidad de disco duro.
AccessLog /vía_acceso_directorio/nombre_archivo_anotaciones_cronológicas
AccessLog /logs/accesslog
Utilice esta directiva para evitar el registro cronológico de peticiones realizadas por un determinado método para acceder a los archivos o directorios. Por ejemplo, es posible que no desee anotar cronológicamente las peticiones DELETE de los archivos y directorios.
Pueden darse varias apariciones de esta directiva en el archivo de configuración. Asimismo, puede colocar varios métodos en la misma directiva si los separa por uno o más espacios.
AccessLogExcludeMethod método [ ...]
AccessLogExcludeMethod GET AccessLogExcludeMethod PUT AccessLogExcludeMethod POST AccessLogExcludeMethod DELETE AccessLogExcludeMethod GET PUT
Ninguno. El servidor incluye en las anotaciones cronológicas de acceso los archivos y directorios solicitados por todos los tipos de métodos.
Utilice esta directiva para especificar que no desea registrar en el proxy las peticiones de anotaciones cronológicas de acceso para acceder a los directorios o archivos de un tipo MIME especificado. (Ejemplos de tipos MIME son text/html, image/gif e image/jpeg.) Por ejemplo, es posible que no desee anotar cronológicamente las peticiones de acceso de las imágenes GIF.
Pueden darse varias apariciones de esta directiva en el archivo de configuración. Asimismo, puede colocar varios tipos MIME en la misma directiva si los separa por uno o más espacios.
AccessLogExcludeMimeType tipo_MIME [...]
AccessLogExcludeMimeType image/gif AccessLogExcludeMimeType text/html AccessLogExcludeMimeType image/gif text/html
Ninguno. Las anotaciones cronológicas de acceso incluyen las peticiones al servidor de archivos y directorios de todos los tipos MIME.
Utilice esta directiva para especificar que no desea anotar cronológicamente las peticiones de acceso que se incluyen dentro de un rango especificado de números de código de error. Estos números de código de error son códigos de estado del servidor proxy. No puede especificar los códigos individuales. La especificación de 300 indica que desea excluir las peticiones de acceso con códigos de retorno de redirección (301, 302, 303 y 304).
Pueden darse varias apariciones de esta directiva en el archivo de configuración. Asimismo, puede colocar varios códigos de retorno en la misma directiva si los separa por uno o más espacios.
AccessLogExcludeReturnCode rango
AccessLogExcludeReturnCode 300
Ninguno. Las anotaciones cronológicas de acceso incluyen todas las peticiones al servidor, independientemente del código.
Utilice esta directiva para especificar que no desea anotar cronológicamente las peticiones de acceso a los archivos o directorios específicos que coincidan con una plantilla de URL especificada. Por ejemplo, es posible que no desee anotar cronológicamente las peticiones de acceso de los archivos GIF o las peticiones de acceso a un determinado archivo o directorio del servidor.
Pueden darse varias apariciones de esta directiva en el archivo de configuración. Asimismo, puede colocar varias entradas de la misma directiva si las separa por uno o más espacios.
AccessLogExcludeURL archivo_o_tipo [...]
AccessLogExcludeURL *.gif AccessLogExcludeURL /Freebies/* AccessLogExcludeURL *.gif /Freebies/*
Ninguno. El servidor anota cronológicamente las peticiones de acceso a todos los archivos y directorios.
Utilice esta directiva para especificar que no desea anotar cronológicamente las peticiones de acceso realizadas por agentes de usuario específicos (por ejemplo, Internet Explorer 5.0).
Pueden darse varias apariciones de esta directiva en el archivo de configuración. Asimismo, puede colocar varias entradas de la misma directiva si las separa por uno o más espacios.
AccessLogExcludeUserAgent agente_usuario [...]
AccessLogExcludeUserAgent *Mozilla/2.0 AccessLogExcludeUserAgent *MSIE 5*
Por omisión, el archivo ibmproxy.conf contiene las siguientes definiciones de la directiva AccessLogExcludeUserAgent:
AccessLogExcludeUserAgent IBM_Network_Dispatcher_HTTP_Advisor AccessLogExcludeUserAgent IBM_Network_Dispatcher_WTE_Advisor
Los agentes de usuario enumerados anteriormente son aquellos definidos para ciertos asesores de Load Balancer que generalmente trabajan delante del servidor de Caching Proxy. Para mejorar el rendimiento minimizando el número de escrituras en las anotaciones cronológicas, estos agentes de usuario no se anotan cronológicamente. Por omisión, el servidor anota cronológicamente las peticiones de acceso realizadas por todos los agentes de usuario.
Utilice esta directiva para especificar un icono que alinee las cabeceras o listados de directorios que se devuelven cuando el servidor actúa como proxy para las peticiones FTP. Los iconos aparecen junto a los archivos asociados para ayudar a los usuarios a diferenciar los archivos.
El icono puede ser un icono en blanco u otro icono que se especifique para que aparezca en las cabeceras de los listados de directorios. Para una alineación adecuada, el icono que se utilice debe tener el mismo tamaño que los demás iconos que se están utilizando en los listados de directorios.
AddBlankIcon URL_icono texto_alternativo
Especifica la última parte del URL del icono. El servidor añade este valor al directorio /icons/ para crear la petición URL completa. Si la petición es para un archivo local, el servidor traduce la petición mediante las directivas de correlación. Para recuperar el icono, las directivas de correlación deben permitir que se pase la petición.
Si está utilizando el servidor como proxy, la petición completa debe ser un URL plenamente cualificado que señale al servidor.
AddBlankIcon logo.gif logo
El valor por omisión no especifica el texto alternativo porque el icono está en blanco.
Utilice esta directiva para especificar un icono que represente un directorio en un listado de directorios.
AddDirIcon URL_icono texto_alternativo
Especifica la última parte del URL del icono. El servidor añade este valor al directorio /icons/ para crear la petición URL completa. Si la petición es para un archivo local, el servidor traduce la petición mediante las directivas de correlación. Para recuperar el icono, las directivas de correlación deben permitir que se pase la petición.
Si está utilizando el servidor como proxy, la petición completa debe ser un URL plenamente cualificado que señale al servidor. Debe correlacionar el URL con un archivo local y asegurarse de que las directivas de correlación permitan que se pase el URL.
AddDirIcon direct.gif DIR
Utilice esta directiva para enlazar archivos con un determinado sufijo a un tipo de codificación MIME. Esta directiva se utiliza raras veces.
AddEncoding .extensión codificación
AddEncoding .qp quoted_printable
AddEncoding .Z x-compress
Utilice esta directiva para especificar los iconos que representen a los archivos con un tipo específico de codificación o de contenido MIME. El servidor utiliza los iconos en los listados de directorios, incluidos los listados de directorios FTP.
AddIcon URL_icono texto_alternativo plantilla_tipo_MIME
Especifica la última parte del URL del icono. El servidor añade este valor al directorio /icons/ para crear la petición URL completa. Si la petición es para un archivo local, el servidor traduce la petición mediante las directivas de correlación. Para recuperar el icono, las directivas de correlación deben permitir que se pase la petición.
Si está utilizando el servidor como proxy, la petición completa debe ser un URL plenamente cualificado que señale al servidor. Debe correlacionar el URL con un archivo local y asegurarse de que las directivas de correlación permitan que se pase el URL.
AddIcon video_file.m.pm.gif MOV video/*
Numerosos valores por omisión se establecen para la directiva AddIcon en el archivo de configuración ibmproxy.conf.
Utilice esta directiva para especificar un icono que represente un directorio padre en los listados de directorios.
AddParentIcon URL_icono texto_alternativo
Especifica la última parte del URL del icono. El servidor añade este valor al directorio /icons/ para crear la petición URL completa. Si la petición es para un archivo local, el servidor traduce la petición mediante las directivas de correlación. Para recuperar el icono, las directivas de correlación deben permitir que se pase la petición.
Si está utilizando el servidor como proxy, la petición completa debe ser un URL plenamente cualificado que señale al servidor. Debe correlacionar el URL con un archivo local y asegurarse de que las directivas de correlación permitan que se pase el URL.
AddParentIcon parent.gif UP
AddParentIcon dir-up.gif UP
Utilice esta directiva para enlazar archivos con un determinado sufijo a un tipo y subtipo MIME. Pueden darse varias apariciones de esta directiva en el archivo de configuración. El servidor proporciona los valores por omisión para los sufijos utilizados con mayor frecuencia.
AddType .extensión tipo/subtipo codificación[calidad[ conjunto_de_caracteres]]
Cualquier otro valor de codificación recibe el mismo tratamiento que binary y se pasa en las cabeceras MIME como una cabecera MIME de codificación de contenido. Las especificaciones 7bit y 8bit no se envían en las cabeceras MIME.
AddType .ps application/postscript 8bit 1.0 AddType *.* application/binary binary 0.3
AddType .bin application/octet-stream binary 0.8
Los numerosos valores por omisión de la directiva AddType se encuentran en el archivo de configuración (ibmproxy.conf).
Utilice esta directiva para especificar un icono que represente los archivos con un tipo de archivo desconocido en un listado de directorios.
AddUnknownIcon URL_icono texto_alternativo
Especifica la última parte del URL del icono. El servidor añade este valor a /icons/ para crear la petición URL completa. Si la petición es para un archivo local, el servidor traduce la petición mediante las directivas de correlación. Para recuperar el icono, las directivas de correlación deben permitir que se pase la petición.
Si está utilizando el servidor como proxy, la petición completa debe ser un URL plenamente cualificado que señale al servidor. Debe correlacionar el URL con un archivo local y asegurarse de que las directivas de correlación permitan que se pase el URL.
AddUnknownIcon saywhat.gif unknown
Utilice esta directiva para especificar un puerto que puedan utilizar los administradores para acceder a las páginas de estado del servidor o los formularios de configuración. Las peticiones dirigidas a este puerto no se colocan en la cola con las demás peticiones de entrada en el puerto o puertos estándar que se definen con la directiva Port. No obstante, las peticiones de AdminPort observan las mismas normas de correlaciones de peticiones y de control de accesos normales que, por ejemplo, Exec y Protect.
AdminPort número_puerto
AdminPort 2001
AdminPort 8008
Utilice esta directiva para especificar si los archivos devueltos por el servidor de origen y marcados como que no se colocan en antememoria se van a colocar en antememoria de todos modos. Los archivos que no se pueden colocar en antememoria que se colocan en antememoria de acuerdo con esta directiva se marcan como deben revalidarse. Siempre que se solicita el archivo, el servidor proxy envía una petición If-Modified-Since al servidor de origen para volver a validar la respuesta antes de que se sirva la respuesta desde la antememoria. En la actualidad, los únicos archivos que no se colocan en antememoria afectados por esta directiva son respuestas del servidor de origen que contienen una cabecera cache-control: no-cache. Esta directiva puede especificarse varias veces.
AggressiveCaching patrón_url
AggressiveCaching http://www.hosta.com/* AggressiveCaching http://www.hostb.com/*
Para que sea compatible con versiones anteriores, la sintaxis anterior de esta directiva ( AggressiveCaching {on | off}) se trata del siguiente modo:
Ninguno
Para las peticiones que contienen un nombre de directorio pero carecen de un nombre de archivo, la directiva AlwaysWelcome controla si el servidor busca en el directorio un archivo de bienvenida que se devuelva. Por omisión, AlwaysWelcome se establece en un valor de on. Esto significa que el servidor siempre busca en el directorio solicitado un archivo que coincida con un nombre especificado en una directiva Welcome. Si se encuentra una coincidencia, el archivo se devuelve al solicitante. Si el servidor encuentra más de una coincidencia entre los archivos de un directorio y los nombres de archivo de las directivas Welcome, el orden de las directivas Welcome determina qué archivo se devuelve. El servidor utiliza la directiva Welcome más cercana a la parte superior del archivo de configuración.
AlwaysWelcome on | off
AlwaysWelcome on
Utilice esta directiva para especificar los URL para los que Caching Proxy añade los caracteres de retorno de carro y de salto de línea al final del cuerpo de una petición POST. Esta directiva se puede especificar varias veces.
appendCRLFtoPost patrón_url
appendCRLFtoPost http://www.hosta.com/
Ninguno
Utilice esta directiva para especificar la matriz de antememoria remota que van a compartir los servidores.
ArrayName nombre_matriz
Ninguno
Utilice esta directiva para especificar una función de aplicación personalizada a la que desee que llame el servidor durante el paso de autenticación del proceso de peticiones del servidor. Este código se ejecuta de acuerdo con el esquema de autenticación. Sólo se da soporte a la autenticación BASIC.
Authentication tipo /vía_acceso/archivo:nombre_función
Authentication BASIC /ics/api/bin/icsextpgm.so:basic_authentication
Ninguno
Utilice esta directiva para especificar una función de aplicación personalizada a la que llama el servidor durante el paso de autorización del proceso de peticiones del servidor. Este código verifica que el objeto solicitado puede servirse al cliente.
Authorization plantilla_petición /vía_acceso/archivo:nombre_función
Authorization /index.html /api/bin/icsextpgm.so:auth_url
Ninguno
Utilice esta directiva para activar y desactivar la renovación de antememoria. Si la renovación está activada, el contenido de antememoria se renueva automáticamente. Si la renovación está desactivada, no se invoca el agente de antememoria y todos sus valores se ignoran. Si está iniciando el agente de antememoria mediante otro método, por ejemplo, utilizando un trabajo cron en los sistemas Linux y UNIX, establezca esta directiva en off.
AutoCacheRefresh {on | off}
AutoCacheRefresh On
Utilice esta directiva en un sistema multiconexión para especificar si el servidor escucha en una única dirección de red. Si establece el valor en On, el servidor se enlaza con la dirección IP especificada en la directiva Hostname, en lugar de enlazarse con todas las direcciones IP locales.
Si no se especifica esta directiva, el servidor se enlaza con Hostname por omisión.
Si modifica esta directiva, debe detener y reiniciar el servidor manualmente. El servidor no realiza el cambio si sólo lo reinicia. (Consulte el Inicio y detención de Caching Proxy.)
BindSpecific {on | off} [OutgoingSrcIp dir_ip | ]
BindSpecific Off
Esta directiva especifica el tamaño, en bytes, de los bloques del soporte del dispositivo de colocación en antememoria. Por omisión, es valor es 8192. Como es el único valor soportado, no cambie este valor. Para obtener más información, consulte el apartado de referencia de Mandato htcformat.
BlockSize tamaño
Por omisión, no existe un valor para BlockSize en el archivo de configuración. (El valor por omisión es 8192.)
Utilice esta directiva para especificar la vía de acceso y el nombre de archivo donde desea que el servidor almacene las anotaciones cronológicas de acceso a la antememoria de proxy. Esta directiva es válida sólo si el servidor se ejecuta como un proxy. Consulte CacheRefreshTime: especificar cuándo se desea iniciar el agente de antememoria para obtener más información.
Para habilitar el registro cronológico de las peticiones dirigidas a la antememoria de proxy, la directiva Caching debe establecerse en ON, a la vez que deben establecerse valores para las directivas CacheMemory y cacheAccessLog. Opcionalmente, se pueden definir uno o más dispositivos de antememoria mediante la directiva CacheDev.
El valor de CacheAccessLog puede ser una vía de acceso absoluta o una vía de acceso relativa a ServerRoot. (Se muestra un ejemplo de cada una de ellas.)
CacheAccessLog vía_acceso/archivo
CacheAccessLog /absolute/path/logfile CacheAccessLog /logs/logfile
Utilice esta directiva para especificar el algoritmo de antememoria que el servidor utiliza durante la recogida de basura.
CacheAlgorithm {bandwidth | responsetime | blend}
CacheAlgorithm bandwidth
Utilice esta directiva para especificar si los nombres de archivo de antememoria generados están basados en el URL de entrada de la petición.
Si se establece esta directiva en on, los nombres de archivo de antememoria se generan basándose en el URL de entrada. Si esta directiva se establece en off, el URL de entrada se pasa primero a través de todos los plug-ins aplicables de traducción de nombres, normas MAP y PROXY, y el nombre de archivo de antememoria generado se basa en el URL resultante.
CacheByIncomingUrl {on | off}
CacheByIncomingURL off
Utilice esta directiva para especificar cuánto tiempo desea que el servidor mantenga los archivos en antememoria. Cuando se ejecuta la recogida de basura, el servidor suprime los archivos en antememoria que han excedido este tiempo, independientemente de la fecha de caducidad de los archivos. Siempre que se solicite un archivo que ha estado en la antememoria durante más tiempo que el especificado, el servidor volverá a validar el archivo para asegurarse de que es válido antes de servirlo.
CacheClean especificación_de_tiempo
CacheClean 2 weeks
CacheClean 1 month
Utilice esta directiva para establecer un tiempo de caducidad por omisión para los archivos para los que el servidor no ha proporcionado una cabecera Expires ni Last-Modified. Especifique una plantilla de URL y el tiempo de caducidad para los archivos que tengan los URL que coincidan con la plantilla. Se pueden incluir varias apariciones de esta directiva en el archivo de configuración. Incluya una directiva separada para cada plantilla. La plantilla de URL debe incluir el protocolo. Especifique el valor de tiempo mediante cualquier combinación de meses, semanas, días y horas.
CacheDefaultExpiry plantilla_URL tiempo_caducidad
CacheDefaultExpiry ftp:* 1 day CacheDefaultExpiry gopher:* 2 days CacheDefaultExpiry http:* 0 days
Utilice esta directiva para especificar un dispositivo de almacenamiento de antememoria. Se puede modificar tanto un archivo como una partición de disco sin procesar. En las plataformas AIX, se puede modificar un volumen lógico sin procesar. Si no se utiliza una antememoria de memoria, la colocación en antememoria de disco sin procesar genera el mejor rendimiento.
Tenga en cuenta que los dispositivos de antememoria deben prepararse antes de especificarse. Para preparar un dispositivo de antememoria, formatéelo mediante el mandato htcformat. Para obtener más información, consulte Mandato htcformat.
Se pueden especificar varios dispositivos de antememoria. Todos los dispositivos se asocian con mismos valores CacheMemory y BlockSize. No obstante, todos ellos incurren en una actividad adicional de la memoria de aproximadamente 8 MB en la máquina del servidor proxy. Menos dispositivos de gran tamaño son más eficaces que un mayor número dispositivos más pequeños. Para lograr una mayor eficacia, utilice un disco entero como una partición grande sin que haya nada más en el disco. Para obtener más información sobre el almacenamiento en antememoria, consulte Optimización del rendimiento de antememoria de disco.
CacheDev {partición_disco_sin_procesar | archivo}
AIX: CacheDev /dev/rlv02
HP-UX: CacheDev /dev/rdsk/c1t15d0
Linux: CacheDev /opt/IBMWTE/filecache1
Solaris: CacheDev /dev/rdsk/clt3d0s0
Windows: CacheDev \\.\E:
Ninguno
Utilice esta directiva para especificar si el servidor devuelve los archivos en antememoria que han caducado. Establezca el valor en Off, si desea que el servidor devuelva los archivos caducados. Utilice el valor por omisión de On si desea que el proxy compruebe mediante el servidor de origen si existe una versión más reciente cuando un cliente solicite un archivo caducado. Generalmente, los administradores no desean que el servidor devuelva archivos caducados, salvo, quizás, en aquellas ocasiones en que están haciendo pruebas del servidor y no les preocupa especialmente el contenido que se devuelve.
CacheExpiryCheck {on | off}
CacheExpiryCheck On
Utilice esta directiva para especificar el tamaño máximo de archivos que se desea colocar en antememoria. Los archivos que sobrepasan este tamaño no se colocan en antememoria. El valor puede especificarse en bytes (B), kilobytes (K), megabytes (M) o gigabytes (G). No importa si la especificación incluye un espacio entre el número y la unidad de medida (B, K, M, G).
CacheFileSizeLimit máximo {B | K | M | G}
CacheFileSizeLimit 4000 K
Utilice esta directiva para especificar el valor que se desea utilizar para calcular las fechas de caducidad de URL específicos o de todos aquellos URL que coincidan con una plantilla.
Los servidores HTTP con frecuencia proporcionan la última vez que se ha modificado un archivo pero no la fecha de caducidad. De forma parecida, los archivos FTP pueden proporcionar una indicación de hora modificada por última vez pero carecer de una fecha de caducidad. Caching Proxy calcula una fecha de caducidad de estos archivos basada en la hora en que se han modificado por última vez. Utiliza la hora de última modificación para determinar el periodo de tiempo desde que se ha modificado el archivo y lo multiplica por el valor que aparece en la directiva CacheLastModifiedFactor. El resultado de este cálculo se corresponde con la duración del archivo o con el intervalo de tiempo antes de que caduque.
Puede especificar off o -1 para desactivar la directiva sin calcular la fecha de caducidad. El servidor proxy lee las directivas CacheLastModifiedFactor en el orden en el que aparecen en el archivo de configuración. Utiliza la primera directiva que puede aplicar al archivo en antememoria.
CacheLastModifiedFactor url factor
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
El valor por omisión de 0.14 hace que los archivos modificados siete días antes caduquen en un día.
Utilice esta directiva para especificar si se desea colocar en antememoria los URL de sistemas principales pertenecientes al mismo dominio que el proxy. Generalmente no es necesario colocar en antememoria los sitios locales de una intranet porque el ancho de banda interno es suficiente para cargar los URL con rapidez. Si no colocan en antememoria los sitios locales, se ahorra espacio de antememoria para los URL cuya recuperación requiere más tiempo.
CacheLocalDomain {on | off}
CacheLocalDomain on
Si el servidor de programa de fondo tiene la posibilidad de devolver a los clientes las variantes del idioma para el mismo URL, utilice esta directiva para dar soporte a la colocación en antememoria de diferentes idiomas para el mismo URL. La directiva permite a Caching Proxy verificar la preferencia del idioma en las peticiones con el idioma de la respuesta en antememoria.
Cuando se habilita CacheMatchLanguage, Caching Proxy compara la preferencia del idioma de la cabecera Accept-Language de la petición con el idioma del contenido en antememoria antes de que Caching Proxy cargue el contenido en antememoria. Caching Proxy también compara la distancia de preferencia. Si la distancia de preferencia es inferior a un límite especificado, Caching Proxy devuelve la copia en antememoria; de lo contrario, el proxy envía la petición al servidor de programa de fondo para obtener una copia nueva en el idioma solicitado.
CacheMatchLanguage {on | off} límite_distancia_preferencia_idioma id_especial_para_todos_idiomas
A continuación aparece un ejemplo de configuración de la directiva, el objeto de antememoria y la petición.
CacheMatchLanguage On 0.2
Si el objeto de antememoria es chino simplificado (zh_cn) y la petición es:
GET / HTTP/1.1 ... Accept-Language: en_US;q=1.0, zh_cn;q=0.7, ja;q=0.3 ....
Para esta petición, el cliente solicita una página en inglés (con el código y calidad en_US/1.0), a continuación, en chino simplificado (con el código y calidad zh_cn/0.7) y, por último, en japonés (con el código y calidad ja/0.3). El objeto en antememoria está en chino simplificado. La distancia de preferencia en entre la mejor calidad esperada y la calidad del idioma coincidente es 1.0 - 0.7 = 0.3. Como el límite está establecido en 0.2 por la directiva CacheMatchLanguage, y 0.3 es mayor que el límite, el proxy pide al servidor una nueva copia de ese URL en lugar de devolver el objeto en antememoria.
Si el servidor no especifica un idioma ni special-id-for-all-lang en la cabecera Content-Language al devolver una respuesta, el proxy no coincide con la preferencia del idioma y devuelve la copia en antememoria cuando entra la siguiente petición.
CacheMatchLanguage off
Utilice esta directiva para definir el periodo máximo de tiempo que los archivos pueden permanecer en la antememoria. La duración de un archivo en antememoria define el intervalo de tiempo que puede servirse desde la antememoria sin que se compruebe el origen en busca de actualizaciones. En algunos casos, la duración calculada para un archivo en antememoria puede ser superior a la deseada para que se mantenga ese archivo. La duración del archivo, ya sea especificada por el origen o calculada por Caching Proxy, no puede exceder el límite especificado por la directiva CacheMaxExpiry.
Se permiten varias apariciones de esta directiva en el archivo de configuración. Incluya una directiva independiente para cada plantilla.
CacheMaxExpiry URL duración
CacheMaxExpiry ftp:* 1 month CacheMaxExpiry http://www.santaclaus.np/* 2 days 12 hours
CacheMaxExpiry 1 month
Utilice esta directiva para especificar la cantidad de memoria que se desea asociar con la antememoria. Para un rendimiento óptimo de las antememorias de disco, se recomienda un valor mínimo de memoria de antememoria de 64 MB para el soporte de infraestructura de antememoria, incluido el índice de antememoria. A medida que aumenta el tamaño de antememoria, aumenta el índice de antememoria y se necesita más memoria de antememoria para almacenar el índice. Un valor de memoria de antememoria de 64 MB es lo bastante grande para proporcionar el soporte de infraestructura y almacenar un índice de antememoria para una antememoria de disco de hasta 6.4 GB aproximadamente. Para antememorias de disco de mayor tamaño, la memoria de antememoria debería ser el 1% del tamaño de antememoria.
Si se utiliza la colocación en antememoria de la memoria, establezca esta directiva para que incluya la antememoria y la cantidad de memoria necesaria para el índice de antememoria.
El valor máximo recomendado para esta directiva es 1600 MB. Este límite viene determinado por el hecho de que Caching Proxy, como aplicación de 32 bits, puede utilizar un valor máximo de 2 GB de memoria. Si la cantidad de memoria necesaria para la antememoria más la cantidad de memoria utilizada para el proceso de rutina se aproxima a 2 GB o los excede, Caching Proxy no funciona con normalidad.
La cantidad puede especificarse en cualquiera de las siguientes unidades: bytes (B), kilobytes (K), megabytes (M) y gigabytes (G).
CacheMemory cantidad {B | K | M | G}
CacheMemory 64 M
Utilice esta directiva para especificar los URL de los archivos cuya fecha de caducidad va a sobrescribirse. Algunos sitios establecen los archivos para que caduquen antes de que finalice su duración, lo que requiere que el servidor solicite el archivo con más frecuencia. La directiva CacheMinHold hace que se retenga el archivo caducado en la antememoria durante el periodo de tiempo especificado antes de que se solicite de nuevo. Esta directiva puede especificarse varias veces.
CacheMinHold http://www.cachebusters.com/* 1 hour
Ninguno
Utiliza esta directiva para especificar si el servidor proxy debe recuperar los archivos de los servidores remotos. El valor por omisión (Off) habilita el servidor para que recupere los archivos de los servidores remotos. El valor On establece el servidor para que se ejecute en la modalidad de antememoria autónoma. Esto significa que el servidor sólo puede devolver los archivos ya almacenados en la antememoria. Generalmente, al ejecutar el servidor en esta modalidad, también establece la directiva CacheExpiryCheck en Off.
La ejecución del servidor en la modalidad de antememoria autónoma puede ser de utilidad si está utilizando el servidor para demostraciones. Si tiene conocimiento de que todos los archivos que desea utilizar para una demostración se almacenan en la antememoria, no es necesaria una conexión de red.
CacheNoConnect {on | off}
CacheNoConnect Off
Utilice esta directiva para especificar que sólo los archivos con los URL que coincidan con una plantilla específica se coloquen en la antememoria. Puede utilizar varias apariciones de esta directiva en el archivo de configuración. Incluya una directiva independiente para cada plantilla. La plantilla de URL debe incluir el protocolo. Si no se establece ningún valor para esta directiva, todos los URL que no coincidan con una directiva NoCaching pueden colocarse en antememoria. Si no se incluyen las directivas CacheOnly ni NoCaching en el archivo de configuración, se puede colocar en antememoria cualquier URL.
CacheOnly patrón_url
CacheOnly http://realstuff/*
Ninguno
Utilice esta directiva para especificar los URL para los que se colocan en antememoria las respuestas a las peticiones de consulta. Si se utiliza el valor PUBLIC patrón_url, las respuestas a las peticiones GET que contienen un signo de interrogación en el URL se colocan en antememoria si el servidor de origen incluye la cabecera cache-control: public y, además, la respuesta puede colocarse en antememoria. Si se especifica el valor ALWAYS patrón_url, las respuestas a las peticiones GET que contienen un signo de interrogación en el URL se colocan en antememoria si éstas puede colocarse en antememoria.
Esta directiva puede especificarse varias veces.
CacheQueries {ALWAYS | PUBLIC} patrón_url
CacheQueries ALWAYS http://www.hosta.com/* CacheQueries PUBLIC http://www.hostb.com/*
Ninguno
Utilice esta directiva para especificar cuándo se debe realizar la comprobación con el servidor de origen para determinar si ha cambiado un archivo en antememoria.
A pesar de que la directiva CacheClean parece idéntica a esta directiva, existe una diferencia. CacheRefreshInterval sólo especifica que el proxy vuelve a validar un archivo antes de utilizarlo, mientras que la directiva CacheClean hace que el archivo se elimine de la antememoria después de un periodo de tiempo especificado.
CacheRefreshInterval patrón_URL periodo_tiempo
CacheRefreshInterval periodo_tiempo
CacheRefreshInterval *.gif 8 hours CacheRefreshInterval 1 week
CacheRefreshInterval 2 weeks
Utilice esta directiva para especificar cuándo se desea iniciar el agente de antememoria. Puede iniciar el agente de antememoria en un momento específico.
CacheRefreshTime HH:MM
CacheRefreshTime 03:00
La directiva CacheTimeMargin especifica la duración mínima de un archivo que es necesaria para que se pueda colocar en antememoria.
Caching Proxy calcula un tiempo de caducidad para todos los archivos. Si es improbable que se reciba otra petición para el archivo antes de que éste caduque, Caching Proxy considera que la duración del archivo es demasiado corta para que éste se coloque en antememoria. Por omisión, Caching Proxy no coloca en antememoria los archivos cuya duración es inferior a 10 minutos. Si la antememoria no está próxima a su capacidad máxima, deje esta directiva en el valor inicial. Si la antememoria está próxima a su capacidad total, se recomienda que aumente el valor de la duración mínima.
CacheTimeMargin duración_mínima
CacheTimeMargin 10 minutes
Utilice esta directiva para establecer el intervalo de tiempo máximo para que el servidor mantenga los archivos en antememoria no utilizados que tengan los URL que coincidan con una plantilla especificada. El servidor suprime los archivos no utilizados que tengan los URL que coincidan con la plantilla después de su colocación en antememoria durante el tiempo especificado, independientemente de la fecha de caducidad. Puede incluir varias apariciones de esta directiva en el archivo de configuración. Incluya una directiva independiente para cada plantilla. La plantilla de URL debe incluir el protocolo. Especifique el valor de tiempo mediante cualquier combinación de meses, semanas, días y horas.
CacheUnused plantilla_URL periodo_tiempo
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
Utilice esta directiva para habilitar la colocación en antememoria de los archivos. Con la colocación en antememoria activada, el servidor proxy almacena los archivos que recupera de otros servidores en una antememoria local. A continuación, El servidor proxy responde a las peticiones posteriores de los mismos archivos sin necesidad de recuperarlos de otros servidores.
Caching {on | off}
Caching On
Utilice esta directiva para especificar la antigüedad después de la cual se comprimen las anotaciones cronológicas. Cuando las anotaciones cronológicas son más antiguas que el valor establecido para CompressAge, se comprimen. Si CompressAge se establece en 0, no se comprimen las anotaciones cronológicas nunca. Las anotaciones cronológicas del día actual y días anteriores nunca se comprimen.
CompressAge número_de_días
CompressAge 1
Utilice esta directiva para crear un mandato que identifique el programa de utilidad de compresión utilizado para compactar las anotaciones cronológicas y que pasa los parámetros a ese programa de utilidad. Incluya la vía de acceso de las anotaciones cronológicas archivadas.
El programa de utilidad de compresión debe estar instalado en un directorio incluido en la vía de acceso para esa máquina.
CompressCommand mandato
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%%
Ninguno
Utilice esta directiva para especificar cuándo se desean suprimir las anotaciones cronológicas después de su compresión. Cuando las anotaciones cronológicas son más antiguas que el número de días establecido para el valor de CompressDeleteAge, se suprimen. Si CompressDeleteAge se establece en 0 o si el valor es inferior al valor establecido para la directiva CompressAge, no se suprimen las anotaciones cronológicas.
CompressDeleteAge número_de_días
CompressDeleteAge 7
Utilice esta directiva para especificar el tipo de contenido de la respuesta HTTP que desea comprimir.
La compresión de la respuesta HTTP ayuda a reducir la carga de red y mejora el rendimiento del servidor proxy. Cuando la función de filtro de compresión está habilitada, si el navegador da soporte a la compresión HTTP y si la respuesta HTTP no está comprimida actualmente, Caching Proxy comprime la respuesta HTTP y devuelve el contenido comprimido al navegador.
Puede habilitar la función de filtro de compresión añadiendo las dos directivas siguientes en el archivo 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 biblioteca mod_z a la que se hace referencia en la directiva CompressionFilterEnable es la versión dinámica de zlib1.1.4.
La variable type-n es cualquier valor válido de la cabecera Content-Type; por ejemplo: text/html o image/bmp.
Ninguno
Utilice esta directiva para habilitar el filtro de compresión a fin de comprimir las respuestas HTTP del servidor de fondo o de la antememoria del servidor proxy.
Para ver ejemplos de cómo utilizar esta directiva, consulte CompressionFilterAddContentType -- Especificar el tipo de contenido de la respuesta HTTP que desea comprimir.
Ninguno
Utilice esta directiva para especificar el nombre y la ubicación de un archivo de configuración adicional. Las directivas que aparecen en el archivo de configuración especificado se procesan después del archivo de configuración actual.
Ninguno
Utilice esta directiva para definir el número de hebras de conexión que se van a utilizar para la gestión de conexiones.
ConnThreads número
ConnThreads 5
Utilice esta directiva para especificar qué cantidad de un archivo solicitado debe transferirse para que Caching Proxy complete la creación del archivo de antememoria, incluso si la conexión de cliente ha finalizado. Los valores válidos para esta variable son enteros que están en el rango de 0 - 100.
Por ejemplo, si se especifica ContinueCaching 75, Caching Proxy continúa la transferencia del archivo desde el servidor de contenido y genera el archivo de antememoria si el 75% o más del archivo ya se ha transferido antes de que Caching Proxy detecte que la conexión de cliente ha terminado.
ContinueCaching porcentaje
ContinueCaching 75
Utilice esta directiva para proporcionar al proxy la información necesaria para filtrar los URL en busca del contenido que incluya la información de servicios de tarifas. Puede especificar esta directiva varias veces.
DefinePicsRule "nombre_filtro" {
DefinePicsRule "Exemplo RSAC" {
Utilice esta directiva para asociar una configuración de protección por omisión con las peticiones que coincidan con una plantilla.
DefProt plantilla_petición nombre_configuración [FOR dirección_IP_servidor | ]
La protección, de hecho, no se activa para las peticiones que coinciden con la plantilla, a menos que la petición también coincida con una plantilla de una directiva Protect posterior. Consulte Protect: activar una configuración de protección de las peticiones que coinciden con una plantilla para obtener una explicación de cómo la directiva Protect se utiliza con DefProt.
Puede especificar una dirección IP (por ejemplo, FOR 240.146.167.72 ) o un nombre de sistema principal (por ejemplo, FOR sistppalA.bcd.com ).
Este parámetro es opcional. Sin este parámetro, el servidor utiliza la directiva para todas las peticiones, independientemente de la dirección IP en la que entran las peticiones o el nombre de sistema principal del URL.
No puede especificarse un carácter comodín para la dirección IP de un servidor.
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/* ClienteA-PROT 0.67.106.79 DefProt /secret/* ClienteB-PROT 0.83.100.45
DefProt /secret/* ClienteA-PROT sistppalA.bcd.com DefProt /secret/* ClienteB-PROT sistppalB.bcd.com
Ninguno
Utilice esta directiva para especificar si el agente de antememoria debe esperar entre los envíos de peticiones a los servidores de destino. La especificación de un retraso entre las peticiones reduce la carga en la máquina proxy y el enlace de red, además de en los servidores de destino. Si no se especifican retrasos, deje que el agente de antememoria se ejecute a la máxima velocidad. Para las conexiones de Internet lentas, se recomienda que no se especifique ningún periodo de retraso para lograr la máxima utilización de la red.
DelayPeriod {on | off}
DelayPeriod On
Utilice esta directiva para especificar si el agente de antememoria debe seguir los enlaces de hipertexto en los distintos sistemas principales. Si un URL en antememoria contiene enlaces con otros servidores, el servidor puede ignorar el enlace o seguirlo. Si la directiva DelveInto está establecida en never, no se aplica esta directiva.
DelveAcrossHosts {on | off}
DelveAcrossHosts Off
Utilice esta directiva para especificar el número de niveles de enlace que se deben seguir al buscar las páginas que se vayan a cargar en la antememoria. Si la directiva DelveInto está establecida en never, no se aplica esta directiva.
DelveDepth número_de_niveles
DelveDepth 2
Utilice esta directiva para especificar si el agente de antememoria debe cargar las páginas enlazadas desde los URL en antememoria.
DelveInto {always | never | admin | topn}
DelveInto always
Utilice esta directiva para aplicar una imagen de fondo a los listados de directorio generados por el servidor proxy. Los listados de directorios se generan cuando el servidor proxy se utiliza para examinar los sitios FTP.
Especifique una vía de acceso absoluta para la imagen de fondo. Si la imagen se ubica en otro servidor, la imagen de fondo debe especificarse como un URL completo. Si no se especifica ninguna imagen de fondo, se utiliza un fondo en blanco.
DirBackgroundImage /vía_acceso/archivo
DirBackgroundImage /images/corplogo.png DirBackgroundimage http://www.somehost.com/graphics/embossed.gif
Ninguno
Utilice esta directiva para especificar si los listados de directorios incluyen el recuento exacto de bytes para los archivos más pequeños que 1 KB. Un valor de Off indica que el listado de directorios muestra un tamaño de 1 KB para todos los archivos de 1 KB o menores.
DirShowBytes {on | off}
DirShowBytes Off
Utilice esta directiva para especificar si los listados de directorios distinguen entre las mayúsculas y minúsculas al ordenar los nombres de archivo.
Un valor de On indica que las mayúsculas aparecen antes que las minúsculas en la lista de archivos.
DirShowCase {on | off}
DirShowCase On
Utilice esta directiva para especificar si los listados de directorios incluyen la fecha en que cada archivo fue modificado por última vez.
DirShowDate {on | off}
DirShowDate On
Utilice esta directiva para especificar si los listados de directorios incluyen las descripciones de los archivos HTML. Las descripciones se toman de los distintivos <title> HTML de los archivos.
Las descripciones de los listados de directorios FTP muestran los tipos MIME de los archivos si pueden determinarse.
DirShowDescription {on | off}
DirShowDescription On
Utilice esta directiva para especificar si los listados de directorios incluyen cualquier archivo oculto del directorio. El servidor considera cualquier archivo que tenga un nombre que empiece por un punto (.) como un archivo oculto.
DirShowHidden {on | off}
DirShowHidden On
Utilice esta directiva para especificar si el servidor incluye iconos en los listados de directorios. Los iconos pueden utilizarse para proporcionar una representación gráfica del tipo de contenido de los archivos del listado. Los iconos mismos se definen mediante las directivas AddBlankIcon, AddDirIcon, AddIcon, AddParentIcon y AddUnknownIcon.
DirShowIcons {on | off}
DirShowIcons On
Utilice esta directiva para establecer el número máximo de caracteres que debe mostrarse en el campo de descripción de los listados de directorios.
DirShowMaxDescrLength número_de_caracteres
DirShowMaxDescrLength 25
Utilice esta directiva para establecer el número máximo de caracteres que debe utilizarse para los nombres de archivo de los listados de directorios.
DirShowMaxDescrLength número_de_caracteres
DirShowMaxLength 25
Utilice esta directiva para establecer el número mínimo de caracteres que siempre está reservado para los nombres de archivo en los listados de directorios. Los nombres de archivo del directorio pueden exceder este número. No obstante, los nombres de archivo no pueden ser de mayor longitud que el número especificado en la directiva DirShowMaxLength.
DirShowMinLength número_de_caracteres
DirShowMinLength 15
Utilice esta directiva para especificar si los listados de directorios incluyen el tamaño de todos los archivos.
DirShowSize {on | off}
DirShowSize On
Utilice esta directiva para especificar qué métodos HTTP no acepta el servidor. Para cada método que el servidor vaya a rechazar, especifique una directiva Disable independiente.
En el archivo de configuración por omisión, los métodos GET, HEAD, OPTIONS, POST y TRACE están habilitados y todos los demás métodos HTTP soportados están inhabilitados. Para inhabilitar un método que esté habilitado en ese momento, suprímalo de la directiva Enable y añádalo en la directiva Disable.
Disable método
Disable PUT Disable DELETE Disable CONNECT
Utilice esta directiva para especificar qué variables de entorno no desea que los programas CGI hereden, además de las variables de entorno CGI que son específicas del proceso CGI.
Por omisión, los programas CGI heredan todas las variables de entorno. Utilice esta directiva para evitar que las variables de entorno individuales se hereden.
DisInheritEnv variable_entorno
DisInheritEnv PATH DisInheritEnv LANG
En este ejemplo, los programas CGI heredan todas las variables de entorno, excepto PATH y LANG.
Ninguno
Utilice esta directiva para especificar si el servidor debe buscar los nombres de sistema principal de los clientes solicitantes.
DNS-Lookup {on | off}
El valor que utilice afecta a los siguientes aspectos del funcionamiento del servidor:
DNS-Lookup Off
Utilice esta directiva para especificar qué métodos HTTP acepta el servidor.
Puede habilitar tantos métodos HTTP como sea necesario. Para cada método que el servidor vaya a aceptar, especifique una directiva Enable independiente.
Enable método
Si no existe ninguna directiva Service para un determinado URL, puede utilizar la directiva Enable para realizar la programación personalizada de cualquier método HTTP. El programa que especifique en esta directiva sobrescribe el proceso estándar de ese método.
Enable método /vía_acceso/archivoDLL:nombre_función
para obtener información sobre el formato y las opciones disponibles para el método Enable CONNECT, consulte Configuración de túneles SSL.
Enable GET Enable HEAD Enable POST Enable TRACE Enable OPTIONS
Utilice esta directiva para habilitar la opción de sockets TCP NODELAY.
La directiva EnableTcpNodelay mejora el rendimiento cuando pequeños paquetes IP como, por ejemplo, un protocolo de enlace SSL o una respuesta HTTP corta se transmiten entre Caching Proxy y el cliente. Por omisión, la opción TCP NODELAY se habilita para todos los sockets.
EnableTcpNodelay {All | HTTP | HTTPS | None}
EnableTcpNodelay All
Utilice esta directiva para especificar una función de aplicación personalizada a la que desea que el servidor llame durante el paso de error. Este código se ejecuta para proporcionar rutinas de error personalizadas cuando se encuentra un error.
Error plantilla_petición /vía_acceso/archivo:nombre_función
Error /index.html /ics/api/bin/icsext05.so:error_rtns
Ninguno
Utilice esta directiva para especificar la vía de acceso y el nombre de archivo donde desea que el servidor anote cronológicamente los errores internos.
Si el servidor se está ejecutando, inicia un nuevo archivo de anotaciones cronológicas todos los días a las doce de la noche. De lo contrario, el servidor inicia un nuevo archivo de anotaciones cronológicas la primera vez que se inicia en un día cualquiera. Al crear el archivo, el servidor utiliza el nombre de archivo que especifica e añadirá un sufijo de fecha. El sufijo de fecha aparece en el formato Mmmddaaaa, donde Mmm representa las tres primeras letras del mes, dd representa el día del mes y aaaa representa el año.
ErrorLog /vía_acceso/directorio_anotaciones_cronológicas/nombre_archivo
Utilice esta directiva para especificar el nombre del archivo que se envía al cliente que lo solicite cuando el servidor se encuentra con una determinada condición de error. El archivo de configuración ibmproxy.conf proporciona las directivas ErrorPage que asocian las palabras clave de error con los archivos de mensaje error.
Para personalizar los mensajes de error, puede modificar las directivas ErrorPage para asociar las palabras clave de error con los distintos archivos o puede modificar los archivos de mensaje de error proporcionados. Por ejemplo, puede modificar un mensaje para que incluya más información sobre la causa del problema y sugiera posibles soluciones para arreglarlo. Para las redes internas, es recomendable que proporcione una persona de contacto para puedan llamar los usuarios.
Las directivas ErrorPage pueden colocarse en cualquier lugar del archivo de configuración. Cuando se produce el error, se procesa el archivo de acuerdo con las normas de correlación definidas en el archivo de configuración. Por lo tanto, el archivo que desee enviar debe estar en una ubicación que pueda accederse mediante las normas de correlación como las definen las directivas Fail, Map, NameTrans, Pass, Redirect y Service. Como mínimo, es necesaria una directiva Pass que permita al servidor pasar el archivo de mensaje de error.
ErrorPage palabra_clave /vía_acceso/nombre_archivo.html
ErrorPage scriptstart /HTML/errorpages/scriptstart.htmls
En este ejemplo, cuando se encuentra una condición scriptstart, el servidor envía al cliente el archivo scriptstart.htmls que se encuentra en el directorio /HTML/errorpages/.
El siguiente texto HTML es un ejemplo de lo que el archivo puede contener:
<HTML> <HEAD> <TITLE>Mensaje para la condición SCRIPTSTART</TITLE> </HEAD> <BODY> No se ha podido iniciar el programa CGI. <P> <A HREF="mailto:admin@websvr.com">Notificar al administrador</A> este problema. </BODY> </HTML>
Si la directiva que coincide con la anterior vía de acceso del archivo de configuración del servidor es PASS /* /wwwhome/*, entonces la vía de acceso completa es /wwwhome/HTML/errorpages/scriptstart.htmls.
Todas las condiciones de error se identifican mediante una palabra clave. Para decidir qué mensajes de error desea personalizar, primero revise los archivos de mensaje de error proporcionados con Caching Proxy, que puede encontrar en /HTML/errorpages. La página de errores incluye el número de error, el mensaje por omisión, una explicación de la causa y una acción de recuperación apropiada.
A continuación, realice una de las acciones siguientes para cambiar un mensaje de error:
Todas las palabras clave de error y los archivos de mensaje de error se enumeran en el archivo ibmproxy.conf del apartado de la directiva ErrorPage. Los archivos de mensaje de error incluyen el número de mensaje de error, la palabra clave, el mensaje por omisión, la explicación y la respuesta del usuario (acción).
Muchos de los valores por omisión se incluyen en el archivo ibmproxy.conf
Si no modifica una directiva ErrorPage para una condición de error, se envía la página de error por omisión del servidor para esa condición.
Utilice esta directiva para especificar el nombre de archivo y la vía de acceso de las anotaciones cronológicas de sucesos. Las anotaciones cronológicas de sucesos capturan los mensajes informativos sobre la propia antememoria.
Si el servidor se está ejecutando, inicia un nuevo archivo de anotaciones cronológicas todos los días a las doce de la noche. De lo contrario, el servidor inicia un nuevo archivo de anotaciones cronológicas la primera vez que se inicia en un día cualquiera. Al crear el archivo, el servidor utiliza el nombre de archivo que especifica e añadirá un sufijo de fecha. El sufijo de fecha aparece en el formato Mmmddaaaa, donde Mmm representa las tres primeras letras del mes, dd representa el día del mes y aaaa representa el año.
EventLog /vía_acceso/directorio_anotaciones_cronológicas/nombre_archivo
Utilice esta directiva para especificar una plantilla que las peticiones acepten y a la que respondan mediante la ejecución de un programa CGI. Después de que una petición coincide con una plantilla de una directiva Exec, la petición no se compara con las plantillas de petición de cualquier directiva posterior.
Exec plantilla_petición vía_acceso_programa [dirección_IP_servidor | ]
Debe utilizar un asterisco (*) como comodín en plantilla_petición y vía_acceso_programa. La parte de la petición que coincide con el comodín plantilla_petición debe empezar con el nombre del archivo que contiene el programa CGI.
La petición también puede contener datos adicionales que se pasan al programa CGI de la variable de entorno PATH_INFO. Los datos adicionales siguen al primer carácter de barra inclinada (/) que aparece detrás del nombre de archivo del programa CGI de la respuesta. Los datos se pasan de acuerdo con las especificaciones CGI.
La directiva Exec es recursiva y se aplica a todos los subdirectorios. No es necesaria una directiva Exec independiente para todos los directorios que aparecen bajo cgi-bin admin-bin.
Puede especificar una dirección IP (por ejemplo, 240.146.167.72 ) o un nombre de sistema principal (por ejemplo, sistppalA.bcd.com ).
Este parámetro es opcional. Sin este parámetro, el servidor utiliza la directiva para todas las peticiones, independientemente de la dirección IP en la que entran las peticiones o el nombre de sistema principal del URL.
Los caracteres comodín no pueden utilizarse para especificar las direcciones IP de servidor.
En el siguiente ejemplo, si el servidor recibe una petición de /idd/depts/plan/c92, éste ejecuta el programa CGI de /depts/bin/plan.exe pasando c92 al programa como entrada.
El siguiente ejemplo utiliza el parámetro de dirección IP opcional. Si el servidor recibe peticiones que empiezan por /cgi-bin/, sirve la petición desde un directorio distinto basándose en la dirección IP de la conexión de red en la que entra la petición. Para las peticiones que entran en 130.146.167.72, el servidor utiliza el directorio /CGI-BIN/clienteA. Para las peticiones que entran en cualquier conexión con una dirección de 0.83.100.45, el servidor utiliza el directorio /CGI-BIN/clienteB.
Exec /cgi-bin/* /CGI-BIN/clienteA/* 130.129.167.72 Exec /cgi-bin/* /CGI-BIN/clienteB/* 0.83.100.45
El siguiente ejemplo utiliza el parámetro de nombre de sistema principal opcional. Si el servidor recibe peticiones que empiezan por /cgi-bin, sirve la petición desde un directorio distinto basándose en el nombre de sistema principal del URL. Para las peticiones que entran para sistppalA.bcd.com, el servidor utiliza el directorio /CGI-BIN/clienteA. Para las peticiones que entran para sistppalB.bcd.com, el servidor utiliza el directorio /CGI-BIN/clienteB.
Exec /cgi-bin/* /CGI-BIN/clienteA/* sistppalA.bcd.com Exec /cgi-bin/* /CGI-BIN/clienteB/* sistppalB.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 raíz_servidor/cgi-bin/* Exec raíz_servidor/admin-bin/* Exec raíz_servidor/DOCS/admin-bin/*
Utilice esta directiva para exportar el contenido de antememoria a un archivo de vuelco. Esto es útil cuando la antememoria de memoria se pierde durante el reinicio o al desplegar la misma antememoria para varios proxies.
ExportCacheImageTo nombre_archivo_exportación
Ninguno
Sólo se aplica a configuraciones de proxy de retorno.
Utilice esta directiva para configurar que Caching Proxy reconozca IBM WebSphere Application Server, que se configura con un módulo de adaptador de Caching Proxy y desde el cual puede colocar en antememoria los recursos creados dinámicamente. Caching Proxy guarda copias de los resultados de JSP que también se almacenan en la antememoria dinámica del servidor de aplicaciones. Caching Proxy coloca en antememoria sólo el contenido de un servidor IBM WebSphere Application Server cuyo ID de grupo coincida con una entrada ExternalCacheManager.
Tenga en cuenta que también es necesario añadir una directiva Service al archivo de configuración de Caching Proxy para habilitar esta característica. También son necesarios pasos de configuración adicionales en el servidor de aplicaciones. Consulte el Colocación en antememoria de contenidos generados dinámicamente para obtener toda la información.
ExternalCacheManager ID_Gestor_Antememoria_Externa Tiempo_Caducidad_Máximo
La siguiente entrada define un gestor de antememoria externo (IBM WebSphere Application Server) que se encuentra en el dominio www.xyz.com y cuyos recursos caducan en 20 segundos o antes.
ExternalCacheManager IBM-CP-XYZ-1 20 seconds
Ninguno
Utilice esta directiva para especificar una plantilla para las peticiones que el servidor no va a procesar. Después de que una petición coincide con una plantilla de una directiva Fail, la petición no se compara con las plantillas de petición de ninguna directiva posterior.
Fail plantilla_petición [dirección_IP_servidor | ]
Puede utilizar un asterisco como comodín en la plantilla. El carácter de tilde (~) que aparece justo después de una barra inclinada (/) debe coincidir explícitamente; no se puede utilizar un carácter comodín para que coincida con él.
Puede especificar una dirección IP (por ejemplo, 240.146.167.72 ) o un nombre de sistema principal (por ejemplo, sistppalA.bcd.com ).
Este parámetro es opcional. Sin este parámetro, el servidor utiliza la directiva para todas las peticiones, independientemente de la dirección IP en la que entran las peticiones o el nombre de sistema principal del URL.
No puede especificarse un carácter comodín para la dirección IP de un servidor.
En el siguiente ejemplo, el servidor rechaza cualquier petición que empiece por /usr/local/private/.
Fail /usr/local/private/*
Los siguientes ejemplos utilizan el parámetro de dirección IP opcional. El servidor rechaza cualquier petición que empiece por /clienteB/ si la petición entra en una conexión de red con la dirección IP 240.146.167.72. El servidor rechaza cualquier petición que empiece por /clienteA/ si la petición entra en una conexión de red con la dirección IP 0.83.100.45.
Fail /clienteB/* 240.146.167.72 Fail /clienteA/* 0.83.100.45
Los siguientes ejemplos utilizan el parámetro de nombre de sistema principal opcional. El servidor rechaza cualquier petición que empiece por /clienteB/ si la petición entra para sistppalA.bcd.com. El servidor rechaza cualquier petición que empiece por /clienteA/ si la petición entra para sistppalB.bcd.com.
Fail /clienteB/* sistppalA.bcd.com Fail /clienteA/* sistppalB.bcd.com
Ninguno
Utilice esta directiva para habilitar cifrados aprobados por FIPS para los protocolos SSLV3 y TLS en conexiones SSL. Si esta directiva está habilitada, se ignora la lista de especificaciones de cifrado soportadas para SSLV3 (DIRECTIVA V3CipherSpecs). Además, las especificaciones de cifrado TLS permitidas se establecerán en 352F0AFF09FE, y las especificaciones de cifrado de SSLV3 se establecerán en FFFE.
FIPSEnable {on | off}
FIPSEnable off
Utilice esta directiva para indicar al proxy que utilice el archivo de configuración SOCKS para determinar el tipo de conexión que desea realizar.
flexibleSocks {on | off}
flexibleSocks on
Utilice esta directiva para permitir que los servidores FTP generen un mensaje descriptivo o de bienvenida para un directorio. Este mensaje puede visualizarse opcionalmente como parte de los listados FTP. La directiva FTPDirInfo le permite controlar donde se visualizará el mensaje.
FTPDirInfo {top | bottom | off}
FTPDirInfo top
Si el servidor proxy forma parte de una cadena de proxies, utilice esta directiva para especificar el nombre de otro proxy con el que entre en contacto este servidor para obtener las peticiones FTP. Debe especificar un URL completo, incluido el carácter de barra inclinada final (/). Para obtener más información sobre cómo utilizar una plantilla o nombre de dominio opcional, consulte no_proxy: especificar las plantillas para conectarse directamente con los dominios.
Sólo se aplica a configuraciones de proxy de reenvío.
ftp_proxy URL_completo [nombre_dominio_o_plantilla]
ftp_proxy http:// servidor.proxy.externo/
Ninguno
Utilice esta directiva para especificar si la información de vía de acceso de los URL de FTP ha de interpretarse como relativa al directorio de trabajo del usuario que ha iniciado la sesión o al directorio raíz.
FTPUrlPath {relative | absolute}
Si la directiva FTPUrlPath se establece en absolute, el directorio de trabajo FTP del usuario que ha iniciado la sesión debe incluirse en la vía de acceso de los URL de FTP. Si se especifica FTPUrlPath Relative, el directorio de trabajo de FTP del usuario que ha iniciado la sesión debe omitirse de la vías de acceso de los URL de FTP. Por ejemplo, para acceder al archivo test1.html, que se encuentra en el directorio de trabajo /export/home/user1 de un usuario que ha iniciado la sesión, son necesarias las siguientes vías de acceso de URL en función del valor de la directiva FTPUrlPath:
Ninguno
Utilice esta directiva para especificar si se desea utilizar la recogida de basura. Si se habilita la colocación en antememoria, el servidor utiliza el proceso de recogida de basura para suprimir los archivos que ya no deben permanecer en antememoria. Los archivos se suprimen en función de la fecha de caducidad y otros valores de las directivas de proxy. Generalmente, si se habilita la colocación en antememoria, se utiliza la recogida de basura. Si no se utiliza la recogida de basura, la antememoria de proxy se utiliza sin eficacia.
Gc {on | off}
Gc On
Utilice esta directiva para especificar una aplicación personalizada que desea que el servidor utilice para la recogida de basura.
GCAdvisor /vía_acceso/archivo:nombre_función
GCAdvisor /api/bin/customadvise.so:gcadv
Utilice esta directiva para especificar el porcentaje de la capacidad de antememoria total que debe rellenarse para desencadenar la recogida de basura. Este porcentaje se llama marca alta. La marca alta se especifica como un porcentaje de la capacidad de antememoria total. La recogida de basura continúa hasta que se ha alcanzado la marca baja; consulte GcLowWater: especificar cuándo termina la recogida de basura para obtener información sobre cómo se establece ésta. El porcentaje para la marca alta puede establecerse entre 50 y 95.
GcHighWater porcentaje
GcHighWater 90
Utilice esta directiva para especificar el porcentaje de la capacidad de antememoria total que desencadena la finalización de la recogida de basura. Este porcentaje se conoce como marca baja. La marca baja se especifica como un porcentaje de la capacidad de antememoria total. Debe establecerse en un valor inferior que el valor establecido para la marca alta; consulte GcHighWater: especificar cuándo empieza la recogida de basura para obtener información sobre cómo establecer la marca alta.
GcLowWater porcentaje
GcLowWater 60
Si el servidor proxy forma parte de una cadena de proxies, utilice esta directiva para especificar el nombre de otro proxy con el que entre en contacto este servidor para obtener las peticiones Gopher. Debe especificar un URL completo, incluida la barra inclinada final (/). Para obtener más información sobre cómo utilizar una plantilla o nombre de dominio opcional, consulte no_proxy: especificar las plantillas para conectarse directamente con los dominios.
Sólo se aplica a configuraciones de proxy de reenvío.
gopher_proxy URL_completo[nombre_dominio_o_plantilla]
gopher_proxy http://servidor.proxy.externo/
Ninguno
Utilice esta directiva para especificar el nombre o número de grupo al que cambia el servidor antes de acceder a los archivos.
Si modifica esta directiva, debe detener y reiniciar el servidor manualmente para que el cambio entre en vigor. El cambio no entra en vigor si únicamente reinicia el servidor. (Consulte el Inicio y detención de Caching Proxy.)
GroupId { nombre_grupo | número_grupo}
AIX: GroupId nobody
HP-UX: GroupId other
Linux:
Solaris: GroupId nobody
Utilice esta directiva para especificar el nombre del servidor proxy devuelto en la cabecera HTTP.
HeaderServerName nombre
Ninguno
Utilice esta directiva para especificar el nombre de dominio o una dirección IP que se devuelve a los clientes desde las peticiones de archivo. Si especifica un nombre de archivo, un servidor de nombres de dominio debe poder resolver el nombre en una dirección IP. Si especifica una dirección IP, el servidor de nombres de dominio no es necesario ni se puede acceder a él.
Hostname {nombre | dirección IP}
Por omisión, esta directiva no se especifica en el archivo de configuración inicial. Si no especifica esta directiva en el archivo de configuración, el valor toma el nombre de sistema principal definido en el servidor de nombres de dominio como valor por omisión.
Si el servidor proxy forma parte de una cadena de proxies, utilice esta directiva para especificar el nombre de otro proxy con el que entre en contacto este servidor para obtener las peticiones HTTP. Debe especificar un URL completo, incluida la barra inclinada final (/). Para obtener más información sobre cómo utilizar una plantilla o nombre de dominio opcional, consulte no_proxy: especificar las plantillas para conectarse directamente con los dominios.
http_proxy URL_completo[nombre_dominio_o_plantilla]
http://servidor.proxy.externo/
Ninguno
Utilice esta directiva para especificar si Caching Proxy recupera la página de inicio desprotegida del URL e intenta buscar etiquetas en ella. Si se encuentra alguna etiqueta, éstas se aplican a la petición segura. Por ejemplo, se solicita https://www.ibm.com/, Caching Proxy recupera http://www.ibm.com/, busca etiquetas en ella y utiliza todas las que encuentra para filtrar https://www.ibm.com/.
Si HTTPSCheckRoot se establece en off, Caching Proxy no recupera la página de inicio desprotegida y busca etiquetas en ella.
HTTPSCheckRoot {on | off}
HTTPSCheckRoot on
Utilice esta subdirectiva para especificar una dirección IP que se utilice para enviar y recibir las consultas ICP. Debe incluirse dentro de las directivas <MODULEBEGIN> ICP y <MODULEEND>.
ICP_Address dirección_IP
Por omisión, esta directiva no se especifica en el archivo de configuración inicial. Si no especifica esta directiva en el archivo de configuración, el valor toma la aceptación y el envío de consultas ICP en cualquier interfaz como valor por omisión.
Utilice esta subdirectiva para especificar el número de hebras generadas para escuchar las consultas ICP. Debe incluirse dentro de las directivas <MODULEBEGIN> ICP y <MODULEEND>.
ICP_MaxThreads número_de_hebras
ICP_MaxThreads 5
Si el servidor proxy forma parte de un clúster ICP, utilice esta subdirectiva para especificar los iguales ICP. Debe incluirse dentro de las directivas <MODULEBEGIN> ICP y <MODULEEND>.
Cuando se añade un nuevo igual al clúster ICP, la información de igual ICP debe añadirse al archivo de configuración de todos los iguales existentes. Utilice una línea para cada igual. Tenga en cuenta que el sistema principal actual también puede incluirse en la lista de iguales. Cuando se inicializa ICP, éste ignora la entrada del sistema principal actual. Esta acción hace posible que exista un único archivo de configuración que se pueda copiar en las demás máquinas de igual sin necesidad de editarlo para eliminar el sistema principal actual.
ICP_Peer nombre_sistppal puerto_http puerto_icp
La siguiente línea añade el sistema principal abc.xcompany.com, cuyo puerto proxy es 80 y el puerto ICP 3128 como igual.
ICP_Peer abc.xcompany.com 80 3128
Ninguno
Utilice esta subdirectiva para especificar el número de puerto en el que el servidor ICP escucha las consultas ICP. Debe incluirse dentro de las directivas <MODULEBEGIN> ICP y <MODULEEND>.
ICP_Port número_puerto
ICP_Port 3128
Utilice esta subdirectiva para especificar el periodo de tiempo máximo durante el que Caching Proxy espera las respuestas a las consultas ICP. Este periodo de tiempo se especifica en milisegundos. Debe incluirse dentro de las directivas <MODULEBEGIN> ICP y <MODULEEND>.
ICP_Timeout tiempo_de_espera_en_milisegundos
ICP_Timeout 2000
Utilice esta directiva para especificar los URL que el agente de antememoria no va a cargar. Esta directiva es de gran utilidad cuando el agente de antememoria está cargando páginas enlazadas desde los URL en antememoria. Puede utilizar varias apariciones de la directiva IgnoreURL para especificar distintos URL o máscaras de URL. El valor de esta directiva puede contener asteriscos (*) como comodines para aplicar una máscara.
IgnoreURL URL
IgnoreURL http://www.yahoo.com/ IgnoreURL http://*.ibm.com/*
IgnoreURL */cgi-bin/*
Utilice esta directiva para especificar si desea que el proceso de inclusión de la parte servidor se realice para los archivos servidos desde el sistema de archivos, los programas CGI o ambos. El proceso de inclusión de la parte servidor se realiza en los archivos con un tipo de contenido de ext/x-ssi-html. Opcionalmente, puede especificar que el proceso de inclusión de la parte servidor se realice para los archivos con un tipo de contenido de text/html. Para obtener más información sobre los tipos de contenido, consulte AddType: especificar el tipo de datos de los archivos con sufijos determinados.
Puede utilizar el proceso de inclusión de la parte servidor para insertar dinámicamente información en el archivo que se devuelva. Esta información puede incluir la fecha, el tamaño de un archivo, la última fecha de modificación de un archivo, las variables de entorno CGI o de inclusión de la parte servidor, o archivos de texto. El proceso de inclusión de la parte servidor sólo se realiza en los archivos que se originan localmente. Caching Proxy no realiza el proceso de inclusión de la parte servidor en los objetos en antememoria o que han pasado por el proxy.
El proceso de inclusión de la parte servidor hace que el servidor examine los archivos en busca de mandatos especiales cada vez que se sirven. Esto puede afectar al rendimiento del servidor y ralentizar el tiempo de respuesta a los clientes.
imbeds {on | off | files | cgi | noexec} {SSIOnly | html}
El servidor comprueba el tipo de contenido de todos los archivos que recupera y la salida de todos los programas CGI que procesa.
El proceso de inclusión de la parte servidor generalmente sólo se realiza para los archivos con un tipo de contenido de text/x-ssi-html. No obstante, puede especificar que los archivos con un tipo de contenido de text/html se procesen para las inclusiones de la parte servidor.
Todos los sufijos deben tener una directiva AddType definida con el tipo de contenido correcto. Si utiliza sufijos distintos a .htm o .html, asegúrese de que la directiva AddType se define mediante un tipo de contenido de text/x-ssi/html.
imbeds on SSIOnly
Utilice esta directiva para importar el contenido de antememoria de un archivo de vuelco. Esto es útil cuando la antememoria de memoria se pierde durante el reinicio o al desplegar la misma antememoria para varios proxies.
ImportCacheImageFrom nombre_archivo_importación
Ninguno
Utilice esta directiva para especificar qué variables de entorno desea que los programas CGI hereden, además de las variables de entorno CGI que son específicas del proceso CGI.
Si no incluye una directiva InheritEnv, los programas CGI heredan todas las variables de entorno. Si incluye cualquier directiva InheritEnv, sólo aquellas variables de entorno especificadas en las directivas InheritEnv se heredan junto con las variables de entorno específicas de CGI. La directiva permite inicializar opcionalmente el valor de las variables que se heredan.
InheritEnv variable_entorno
InheritEnv PATH InheritEnv LANG=ENUS
En este ejemplo, las variables de entorno PATH y LANG sólo las heredan los programas CGI y la variable de entorno LANG se inicializa con el valor de ENUS.
Ninguno. Por omisión, los programas CGI heredan todas las variables de entorno.
Utilice esta directiva para establecer el tiempo permitido para que un cliente envíe una petición después de realizar una conexión con el servidor. Un cliente primero se conecta al servidor y, a continuación, envía una petición. Si el cliente no envía una petición durante el especificado mediante esta directiva, el servidor cierra la conexión. Especifique el valor de tiempo mediante cualquier combinación de horas, minutos (o mins) y segundos (o segs).
InputTimeout tiempo
InputTimeout 3 mins 30 secs
InputTimeout 2 minutes
Esta directiva sobrescribirá la acción por omisión del plug-in JunctionRewrite, lo que permitirá que el proxy corrija ciertos enlaces URL URL de la página html. Se utiliza junto con la directiva JunctionRewrite.
Sólo se aplica a configuraciones de proxy de retorno.
La directiva JunctionReplaceUrlPrefix indicará al plug-in JunctionRewrite que cambie el URL de patrón_url_1 a patrón_url_2, en lugar de insertar un prefijo al principio del URL.
JunctionReplaceUrlPrefix patrón_url_1 patrón_url_2
JunctionReplaceUrlPrefix /server1.internaldomain.com/* /server1/*
En este ejemplo, asuma que el URL es /server1.internaldomain.com/notes.nsf y que el prefijo es /server1. En lugar de insertar el prefijo para reescribir el URL como /server1/server1.internaldomain.com/notes.nsf, el plug-in JunctionRewrite plug-in cambiará el URL a /server1/notes.nsf.
Ninguno
Esta directiva habilita la rutina de reescritura de unión en Caching Proxy para reescribir las respuestas de los servidores de origen para garantizar que los URL relativos al servidor se correlacionen correctamente con el servidor de origen correcto cuando se utilizan uniones.
Sólo se aplica a configuraciones de proxy de retorno.
El plug-in de reescritura de unión también debe habilitarse si establece JunctionRewrite on sin la opción UseCookie. Las uniones se definen mediante normas de correlación del proxy.
Consulte UseCookie como alternativa a JunctionRewrite y Ejemplo de plug-in de transformación rápida para ampliar la funcionalidad de JunctionRewrite para obtener información adicional sobre JunctionRewrite.
JunctionRewrite {on | on UseCookie | off}
JunctionRewrite off
La directiva permitirá al proxy reescribir la opción de vía de acceso en la cabecera Set-Cookie cuando se produzca una coincidencia con el nombre de cookie. Si la respuesta necesita uniones y no se ha definido un prefijo de uniones, el prefijo insertará delante de todas las vías de acceso. Puede utilizarse con el plug-in JunctionRewrite o puede utilizarse con la directiva RewriteSetCookieDomain.
Sólo se aplica a configuraciones de proxy de retorno.
JunctionRewriteSetCookiePath nombre-cookie1 nombre-cookie2...
Ninguno
Esta directiva sobrescribirá la acción por omisión del plug-in JunctionRewrite, lo que evitará la reescritura de URL si ya hay coincidencia con patrón de URL. Funciona con el plug-in JunctionRewrite plug-in y proporciona un modo de corregir algunos de los enlaces URL de la página URL. Generalmente, la directiva se utiliza para evitar los URL que ya incluyen un prefijo.
Sólo se aplica a configuraciones de proxy de retorno.
JunctionSkipUrlPrefix patrón_url
JunctionSkipUrlPrefix /server1/*
En este ejemplo, asuma que el URL es /server1/notes.nsf y que el prefijo de unión es /server1/. En lugar de reescribir el URL como /server1/server1/notes.nsf, el plug-in JunctionRewrite plug-in omitirá la reescritura del URL, que permanecerá sin modificar como /server1/notes.nsf.
Ninguno
Utilice esta directiva para impedir que los servidores de programa de fondo se vean saturados con peticiones mientras se vuelve a validar un objeto de antememoria.
Cuando se vuelve a validar un objeto de antememoria con el contenido del servidor de programa de fondo, las peticiones de ese mismo recurso se enviarán al servidor de programa de fondo a través del proxy. En ocasiones, la avalancha de peticiones iguales provocará la caída del servidor del programa de fondo. Habilitar esta directiva puede ayudar a evitar que se produzca esta situación. Si la directiva está habilitada, se devolverán las copias caducadas u obsoletas del recurso si el recurso se está actualizando en el proxy.
KeepExpired {on | off}
KeepExpired off
Utilice esta directiva para especificar la vía de acceso del archivo a la base de datos de conjunto de claves que el servidor utiliza para las peticiones SSL. Los archivos de conjunto de claves se generan mediante el programa de utilidad del gestor de claves iKeyman.
KeyRing nombre_archivo
Windows: KeyRing c:\Archivos de programa\IBM\edge\cp\\key.kdb
Linux y UNIX: KeyRing /etc/key.kdb
Ninguno
Utilice esta directiva para especificar la vía de acceso del archivo al archivo de contraseñas de la base de datos de conjunto de claves. El archivo de contraseñas se genera mediante el programa de utilidad del gestor de claves iKeyman cuando se crea un archivo de base de datos de conjunto de claves.
KeyRingStash vía_acceso_archivo
Windows: KeyRingStash c:\Archivos de programa\IBM\edge\cp\key.sth
Linux y UNIX: KeyRingStash /etc/key.sth
Ninguno
Utilice esta directiva para controlar el tamaño máximo del cuerpo de las peticiones PUT o POST. Las directivas LimitRequest se utilizan para proteger al proxy de posibles ataques.
El valor puede especificarse en kilobytes (K), megabytes (M) o gigabytes (G).
LimitRequestBody tamaño_cuerpo_máximo {K | M | G}
LimitRequestBody 10 M
Utilice esta directiva para especificar el número máximo de cabeceras que se pueden enviar en las peticiones de cliente. Las directivas LimitRequest se utilizan para proteger al proxy de posibles ataques.
LimitRequestFields número_cabeceras
LimitRequestFields 32
Utilice esta directiva para especificar la longitud máxima de la línea de petición y de todas las cabeceras de una petición. Las directivas LimitRequest se utilizan para proteger al proxy de posibles ataques.
El valor puede especificarse en bytes (B) o kilobytes (K).
LimitRequestFieldSize longitud_máx_cabeceras {B | K}
LimitRequestFieldSize 4096 B
Utilice esta directiva para especificar el número de conexiones de cliente del registro de reserva de escucha que el servidor transporta antes de enviar mensajes de conexiones rechazadas a los clientes. Este número depende del número de peticiones que el servidor puede procesar en pocos segundos. No lo establezca en un valor superior al número que el servidor puede procesar antes de que finalice el tiempo de espera de los clientes y éstos terminen anormalmente la conexión.
ListenBacklog número_de_peticiones
ListenBacklog 128
Utilice esta directiva para especificar si el agente de antememoria debe recuperar las imágenes en línea. Si LoadInlineImages se establece en on, también se colocarán en antememoria las imágenes que estén anidadas en una página que se esté colocando en antememoria. Si se establece en off, las imágenes anidadas no se colocan en antememoria.
LoadInlineImages {on | off}
LoadInlineImages on
Utilice esta directiva para indicar al agente de antememoria que acceda a las anotaciones cronológicas de acceso a la antememoria de la noche anterior y cargue los URL más solicitados.
La directiva Caching debe establecerse en On y debe establecerse un valor para la directiva CacheAccessLog cuando se establece un valor para la directiva LoadTopCached.
LoadTopCached número_de_páginas
LoadTopCached 100
Utilice esta directiva para especificar los URL que se desea cargar en la antememoria mediante el agente de antememoria. Pueden incluirse varias directivas LoadURL en el archivo de configuración, pero no se pueden utilizar los caracteres comodín.
LoadURL url
LoadURL http://www.ibm.com/
Ninguno
Utilice esta directiva para especificar una función de aplicación personalizada a la que el servidor llama durante el paso de anotación cronológica. Este código proporciona el registro cronológico y demás procesos que se realizan después de cerrar la conexión.
Log plantilla_petición /vía_acceso/archivo:nombre_función
Log /index.html /api/bin/icsextpgm.so:log_url
Ninguno
Utilice esta directiva para especificar el comportamiento de la rutina de archivado. Esta directiva afecta a todas las anotaciones cronológicas con valores globales. Especifica que las anotaciones cronológicas deben comprimirse o depurarse, o que no se realice nada con ellas.
Si especifica Compress, utilice las directivas CompressAge y CompressDeleteAge para especifica cuando se comprimen o se suprimen las anotaciones cronológicas. Utilice la directiva CompressCommand para especificar qué mandato y sus parámetros deben utilizarse.
Si especifica Purge, utilice las directivas PurgeAge y PurgeSize para especificar cuando se desea depurar las anotaciones cronológicas.
LogArchive {Compress | Purge | none}
LogArchive Purge
Utilice esta directiva para especificar el formato de archivo de los archivos de anotaciones cronológicas de acceso.
LogFileFormat {common | combined}
Por omisión, las anotaciones cronológicas se muestran en el formato de archivo de anotaciones cronológicas común de NCSA. Especifique combined para mostrar las anotaciones cronológicas en el formato de archivo de anotaciones cronológicas combinado de NCSA. El formato combinado añade campos para el URL de referencia, el agente de usuario y el cookie (si aparecen en la petición).
LogFileFormat common
Sistema Windows sólo. Al ejecutar el proxy mediante la línea de mandatos, utilice esta directiva para que se envíe la salida a las anotaciones cronológicas de acceso. Para optimizar el rendimiento del servidor, esta directiva se establece en off (inhabilitado) por omisión.
LogToGUI {on | off}
LogToGUI off
Sistemas Linux y UNIX sólo. Utilice esta directiva para especificar si el servidor va a anotar cronológicamente las peticiones y errores de acceso en las anotaciones cronológicas del sistema además de en los archivos de anotaciones cronológicas de error y de acceso.
LogToSyslog {on | off}
El archivo de anotaciones cronológicas de error debe estar presente en el servidor antes de especificar que la información de anotaciones cronológicas de error se escriba en él. Puede escoger si desea anotar cronológicamente la información de acceso, la información de error o ambas.
Para enviar sólo la información de error a las anotaciones cronológicas del sistema, añada la siguiente línea al archivo /etc/syslog.conf:
user.err archivo_salida_syslog_para_información_errores
Para enviar sólo la información de acceso a las anotaciones cronológicas del sistema, añada la siguiente línea al archivo /etc/syslog.conf:
user.info archivo_info_syslog_para_información_acceso
Para enviar la información de error y la información de acceso a las anotaciones cronológicas del sistema, añada ambas líneas al archivo /etc/syslog.conf:
Especifique archivo_salida_syslog y archivo_info_syslog en los siguientes formatos:
Después de crear el archivo de anotaciones cronológicas del sistema, puede reiniciarlo con el siguiente mandato:
kill -HUP 'cat /etc/syslog.pid'
LogToSyslog Off
Utilice esta directiva para especificar una plantilla para las peticiones que desea cambiar a una nueva serie de petición. Después de que el servidor modifica la petición, éste toma la nueva serie de petición y la compara con las plantillas de petición de las directivas posteriores.
La directiva Map utiliza la serie de la vía de acceso de petición entrante para cumplir la regla. Consulte también MapQuery -- Cambiar las peticiones coincidentes a una nueva serie de petición, utilizando la serie de vía de acceso de petición y consulta para cumplir la regla.
Map plantilla_petición petición_nueva [dirección_IP_servidor | ]
Puede utilizar un asterisco (*) como comodín en la plantilla. El carácter de tilde (~) que aparece justo después de una barra inclinada (/) debe coincidir explícitamente; no se puede utilizar un carácter comodín para que coincida con él.
Puede especificar una dirección IP (por ejemplo, 240.146.167.72 ) o un nombre de sistema principal (por ejemplo, sistppalA.raleigh.ibm.com).
Este parámetro es opcional. Sin este parámetro, el servidor utiliza la directiva para todas las peticiones, independientemente de la dirección IP en la que entran las peticiones o el nombre de sistema principal del URL.
No puede especificarse un carácter comodín para la dirección IP de un servidor.
Map /stuff/* /good/stuff/*
Map /stuff/* /clienteA/good/stuff/* 240.146.167.72 Map /stuff/* /clienteB/good/stuff/* 0.83.104.45
Map /stuff/* /clienteA/good/stuff/* sistppalA.bcd.com Map /stuff/* /clienteB/good/stuff/* sistppalB.bcd.com
Ninguno
Utilice esta directiva para especificar una plantilla para las peticiones que desea cambiar a una nueva serie de petición. Después de que el servidor modifica la petición, éste toma la nueva serie de petición y la compara con las plantillas de petición de las directivas posteriores.
La funcionalidad de la directiva es casi idéntica a la de la regla Map (Map -- Cambiar las peticiones coincidentes a una nueva serie de petición, utilizando la serie de vía de acceso de petición para cumplir la regla). Sin embargo, para manejar un URL con una serie de consulta, MapQuery utiliza la vía de acceso y la serie de consulta para cumplir la regla. Si el URL cumple una regla MapQuery, se utilizará el URL traducido para cumplir el resto de las reglas.
MapQuery también puede traducir un URL con una serie de consulta a otro URL con una vía de acceso o una serie de consulta distinta. Sin embargo, debido a que todas las demás directivas de correlación sólo utilizan la vía de acceso de petición, la serie de consulta modificada sólo se añadirá (no se utilizará para patrones de coincidencia) al URL traducido cuando coincida la vía de acceso de petición.
MapQuery plantilla_petición petición_nueva [dirección_IP_servidor | ]
Puede utilizar un asterisco (*) como comodín en la plantilla. El carácter de tilde (~) que aparece justo después de una barra inclinada (/) debe coincidir explícitamente; no se puede utilizar un carácter comodín para que coincida con él.
Puede especificar una dirección IP (por ejemplo, 240.146.167.72 ) o un nombre de sistema principal (por ejemplo, sistppalA.raleigh.ibm.com).
Este parámetro es opcional. Sin este parámetro, el servidor utiliza la directiva para todas las peticiones, independientemente de la dirección IP en la que entran las peticiones o el nombre de sistema principal del URL.
No puede especificarse un carácter comodín para la dirección IP de un servidor.
Suponiendo que el URL entrante es el siguiente,
/getsomthing?type=1
y que la regla MapQuery es la siguiente,
MapQuery /getsomething?type=* /gettype/*
El URL traducido será /gettype/1 y se utilizará en la siguiente correlación de regla.
Proxy /gettype/* http://server/gettype/*
El URL traducido será http://server/gettype/1.
Ninguno
Utilice esta directiva para establecer el número máximo de hebras que estarán activas simultáneamente. Si se alcanza este máximo, el servidor retiene las nuevas peticiones hasta que termina otra petición y las hebras están disponibles. Generalmente, cuanto más potencia tiene una máquina, mayor es el valor que se establece para esta directiva. Si una máquina empieza a pasar demasiado tiempo realizando tareas de actividad adicional como, por ejemplo, el intercambio de memorias intente reducir este valor.
MaxActiveThreads número_de_hebras
MaxActiveThreads 100
Utilice esta directiva para establecer el tamaño del almacenamiento intermedio de los datos dinámicos generados por el servidor. Son datos dinámicos la salida de los programas CGI, las inclusiones de la parte servidor y los programas de API.
El valor puede especificarse en bytes (B), kilobytes (K), megabytes (M) o gigabytes (G). No importa si hay un espacio entre el número y el valor (B, K, M, G).
MaxContentLengthBuffer tamaño
MaxContentLengthBuffer 100 K
Utilice esta directiva para especificar el tamaño máximo de todos los archivos de anotaciones cronológicas. Todos los archivos de anotaciones cronológicas no pueden sobrepasar el tamaño definido por esta directiva. Una vez que un archivo de anotaciones cronológicas alcanza el tamaño máximo definido, se cierra el archivo de anotaciones cronológicas actual y se crea uno nuevo con el mismo nombre añadido por el siguiente valor entero incremental.
El valor recomendado para establecer la directiva MaxLogFileSize es como mínimo de 10 M, pero de menos de 200 M. El tamaño real del archivo de anotaciones cronológicas es ligeramente superior al tamaño que ha establecido. Establecer un valor demasiado bajo afecta al rendimiento del proxy, porque el servidor proxy cierra y abre el archivo de anotaciones cronológicas más a menudo. En algunas plataformas, establecer un valor demasiado alto hace que el proxy utilice memoria para almacenamiento intermedio de E/S. Cuando el tamaño del archivo de anotaciones cronológicas se vuelve más grande, puede hacer que el proxy agote la memoria o aparente una pérdida de memoria, aunque el sistema operativo controle los almacenamientos intermedios de E/S.
El tamaño máximo puede especificarse en cualquiera de las siguientes unidades: bytes (B), kilobytes (K), megabytes (M) y gigabytes (G).
MaxLogFileSize máximo {B | K | M | G}
MaxLogfileSize 128 M
Utilice esta directiva para especificar el número máximo de solicitantes que el servidor recibe en una conexión persistente. Al determinar este número, tenga en cuenta el número de imágenes utilizado en las páginas. Cada imagen requiere una petición independiente.
MaxPersistRequest número
MaxPersistRequest 5
Utilice esta directiva para especificar la profundidad máxima de la cola de peticiones de recuperación de página pendientes del agente de antememoria. Si tiene un sistema de tamaño considerable con una gran cantidad de memoria, puede definir un cola de peticiones de recuperación de páginas mayor sin consumir toda la memoria disponible.
La cola de los URL que se va a colocar en antememoria se determina al principio de todas las ejecuciones del agente de antememoria. Si indica al agente de antememoria que siga los enlaces de hipertexto a otros URL, estos URL no se cuentan en la profundidad de la cola de antememoria. Después de que se alcance el valor especificado en la directiva MaxURLs, el agente de antememoria se detiene, incluso si quedan más URL en la cola.
MaxQueueDepth longitud_máxima
MaxQueueDepth 250
Utilice esta directiva para especificar el periodo máximo de tiempo para que el agente de antememoria recupere los URL durante una ejecución determinada. Un valor de 0 significa que el agente de antememoria se ejecuta hasta que se complete.
MaxRuntime {0 | tiempo_máximo}
MaxRuntime 2 hours 10 minutes
MaxRuntime 2 hours
Utilice esta directiva para establecer el número máximo de sockets desocupados abiertos que mantener para cualquier servidor de origen. Utilice esta directiva sólo si la directiva ServerConnPool está establecida en on.
MaxSocketPerServer núm
MaxSocketPerServer 10
MaxSocketPerServer 5
Utilice esta directiva para especificar el número máximo de los URL que el agente de antememoria recupera durante una ejecución determinada. Un valor de 0 significa que no hay ningún límite. Cuando se utiliza la modalidad automática del agente de antememoria, las directivas LoadURL y LoadTopCached tienen prioridad ante MaxURLs.
MaxURLs número_máximo
MaxURLs 2000
Utilice esta directiva para especificar los miembros de las matrices que comparten los servidores mediante el acceso a antememoria remota.
Member nombre { subdirectiva subdirectiva . . }
Se incluyen las siguientes subdirectivas:
Member bittersweet.chocolate.ibm.com { RCAAddr 127.0.0.1 RCAPort 6294 CacheSize 25G Timeout 500 milliseconds BindSpecific On ReuseAddr Off }
Ninguno
Utilice esta directiva para especificar el plug-in de aplicación que se ejecuta a medianoche para archivar las anotaciones cronológicas. Esta directiva se inicializa durante la instalación. Si no incluye esta directiva en el archivo de configuración, no se realizan las funciones de archivado.
Midnight /vía_acceso/archivo:nombre_función
Utilice esta directiva para especificar una función de aplicación personalizada a la que el servidor llama durante el paso de traducción de nombre. Este código proporciona el mecanismo para traducir la vía de acceso virtual de la petición a la vía de acceso física del servidor, lo que permite correlacionar los URL a objetos específicos.
NameTrans plantilla_petición /vía_acceso/archivo:nombre_función [dirección_IP_servidor | ]
No puede especificarse un carácter comodín para la dirección IP de un servidor.
NameTrans /index.html /api/bin/icsextpgm.so:trans_url
Ninguno
En las plataformas Linux y UNIX, utilice esta directiva para evitar que el proceso de servidor de Caching Proxy se ejecute automáticamente de fondo. La directiva, que se establece en off por omisión, tiene el siguiente formato:
NoBG [on | off]
NoBG on
NoBG off
Utilice esta directiva para especificar que el servidor no coloque en antememoria los archivos con los URL que coincidan con la plantilla especificada. Puede incluir varias apariciones de esta directiva en el archivo de configuración. Incluya una directiva separada para cada plantilla. La plantilla de URL debe incluir el protocolo.
Si no están establecidas las directivas CacheOnly ni NoCaching, cualquier URL es un candidato para la colocación en antememoria.
NoCaching patrón_URL
NoCaching http://joke/*
Ninguno
Utilice esta directiva para especificar que no coloque en antememoria las peticiones de acceso realizadas desde sistemas principales o dominios específicos que coincidan con una plantilla especificada. Por ejemplo, es posible que no desee anotar cronológicamente las peticiones de acceso de los sistemas principales locales.
Puede incluir varias apariciones de esta directiva en el archivo de configuración. Asimismo, puede colocar varias plantillas en la misma directiva si las separa por uno o más espacios. Puede utilizar los nombres de sistema principal o direcciones de número IP en las plantillas.
NoLog { | dirección_IP} [...]
NoLog 128.0.* *.edu localhost.*
Ninguno
Si está utilizando la directiva http_proxy, ftp_proxy o gopher_proxy para el encadenamiento de proxy, puede utilizar esta directiva para especificar los dominios con los que se conecta el servidor directamente en lugar de ir a través de un proxy.
Especifique el valor como un serie de nombres de dominio o plantillas de nombre de dominio. Separe cada entrada de la serie con una coma (,). No utilice ningún espacio en la serie.
Las plantillas de esta directiva se especifican de modo distinto a las demás directivas. Y lo más importante, no puede utilizar el carácter comodín (*). Puede especificar una plantilla incluyendo sólo la última parte de un nombre de dominio. El servidor se conecta directamente con cualquier dominio que termine con una serie que coincida con las plantillas que se especifiquen. Esta directiva sólo se aplica al encadenamiento de proxy y es equivalente a una línea @/= directa del archivo de configuración SOCKS.
no_proxy nombre_dominio_o_plantilla[,...]
no_proxy www.someco.com,.raleigh.ibm.com,.some.host.org:8080
En este ejemplo, el servidor no va a través de un proxy para las siguientes peticiones:
Ninguno
Por omisión, cuando se recibe de los navegadores una petición de rango, Caching Proxy requiere una respuesta completa del servidor de fondo. Caching Proxy elimina la cabecera Rango de la petición y, a continuación, reenvía la petición al servidor de fondo. Una vez que la respuesta se coloca en la antememoria en el servidor proxy, las peticiones posteriores de los mismos recursos se sirven desde el servidor proxy independientemente de si las peticiones son peticiones de rango o no. Habitualmente, la acción por omisión de Caching Proxy mejorará el rendimiento y dará a los clientes tiempos de respuesta más cortos. Sin embargo, si la respuesta no puede colocarse en la antememoria, o si es muy grande, la acción por omisión disminuirá el rendimiento.
Utilice la directiva NoCacheOnRange, que especifica que no hay colocación en antememoria para las peticiones de rango, a fin de solucionar el problema que se describe al utilizar la configuración por omisión.
Cuando habilite globalmente la directiva en el archivo ibmproxy.conf, o si la habilita como una opción para la regla de correlación PROXY, Caching Proxy reenvía la cabecera Petición de rango al servidor de fondo. Sin embargo, Caching Proxy no coloca en antememoria la respuesta 206 (contenido parcial) del servidor de fondo.
Habilitar la directiva NoCacheOnRange puede mejorar el rendimiento del proxy en los casos siguientes:
NoCacheOnRange [on | off]
También puede habilitar NoCacheOnRange en una regla de correlación de proxy:
Proxy /not-cachable/* http://server.com/no-cachable-resources/* NoCacheOnRange
NoCacheOnRange off
Utilice esta directiva para especificar las cabeceras URL que se desea bloquear. Cualquier cabecera HTTP enviada por un cliente puede bloquearse, incluidas las cabeceras necesarias. Se requiere extrema precaución al bloquear las cabeceras. Las cabeceras comunes son:
Consulte la especificación de protocolo HTTP para obtener información detallada de estas y otras cabeceras. Puede especificar esta directiva varias veces.
NoProxyHeader cabecera
NoProxyHeader Referer:
Ninguno
Utilice esta directiva para especificar el número de hebras que el agente de antememoria utiliza para recuperar las páginas de la cola. Base el número de hebras en la velocidad de red interna y la conexión a Internet. El rango permitido es de 1 a 100.
NumClients número
NumClients 4
Utilice esta directiva para especificar una función de aplicación personalizada a la que el servidor llama durante el paso de tipo de objeto. Este código localiza el objeto solicitado en el sistema de archivos y especifica el tipo MIME que le corresponde.
ObjectType plantilla_petición /vía_acceso/archivo:nombre_función
ObjectType /index.html /api/bin/icsextpgm.so:obj_type
Ninguno
Esta directiva acelera el proceso de correlación de reglas para peticiones entrantes cuando aumenta el número de reglas.
Cuando se habilita la directiva OptimizeRuleMapping, en vez de correlacionar las peticiones de URI entrantes con cada regla de una en una, el proxy correlaciona el URI con un árbol de prefijos. El árbol de prefijos ayuda al proxy a eliminar la comparación redundante de series entre las reglas de correlación. Como resultado, Caching Proxy consigue un rendimiento mejor cuando el número de reglas de la configuración es mayor que 300.
OptimizeRuleMapping [on | off ]
OptimizeRuleMapping off
Utilice esta directiva para establecer el intervalo de tiempo máximo permitido al servidor para que envíe la salida a un cliente. El límite de tiempo se aplica a las peticiones de los archivos locales y las peticiones para las cuales el servidor actúa como un proxy. El límite de tiempo no se aplica a las peticiones que inician un programa CGI local.
Si el servidor no envía la respuesta completa dentro del límite de tiempo especificado en esta directiva, el servidor elimina la conexión. Especifique el valor de tiempo mediante cualquier combinación de horas, minutos (o mins) y segundos (o segs).
OutputTimeout tiempo
OutputTimeout 30 minutes
Utilice esta directiva para especificar el directorio que contiene los archivos de autoconfiguración de proxy generados mediante el formulario de configuración remota de archivos PAC.
PacFilePath vía_acceso_directorio
Utilice esta directiva para especificar una plantilla para las peticiones que desea aceptar y a las que desea responder con un archivo del servidor. Después de que una petición coincide con una plantilla de una directiva Pass, la petición no se compara con las plantillas de petición de cualquier directiva posterior.
Pass plantilla_petición [vía_acceso_archivo [dirección_IP_servidor | ]]
Puede utilizar un asterisco (*) como comodín en la plantilla. El carácter de tilde (~) que aparece justo después de una barra inclinada (/) debe coincidir explícitamente; no se puede utilizar un carácter comodín para que coincida con él.
Este parámetro es opcional. Si no especifica la vía de acceso, la petición misma se utiliza como la vía de acceso.
Puede especificar una dirección IP (por ejemplo, 240.146.167.72 ) o un nombre de sistema principal (por ejemplo, sistppalA.raleigh.ibm.com).
Este parámetro es opcional. Sin este parámetro, el servidor utiliza la directiva para todas las peticiones, independientemente de la dirección IP en la que entran las peticiones o el nombre de sistema principal del URL.
No puede especificarse un carácter comodín para la dirección IP de un servidor.
Pass /gooddoc/*
Pass /parts/* /clienteA/catalog/* 240.146.167.72 Pass /parts/* /clienteB/catalog/* 0.83.100.45
Pass /Admin/* /usr/lpp/internet/server_root/Admin/* Pass /Docs/* /usr/lpp/internet/server_root/Docs/* Pass /errorpages/* /usr/lpp/internet/server_root/pub/errorpages/* Pass /* /usr/lpp/internet/server_root/pub/*
Pass /Admin/* /opt/ibm/edge/cp/server_root/Admin/* Pass /Docs/* /opt/ibm/edge/cp/server_root/Docs/* Pass /errorpages/* /opt/ibm/edge/cp/server_root/pub/errorpages/* Pass /* /opt/ibm/edge/cp/server_root/pub/*
Pass /Admin/* /usr/lpp/internet/server_root/Admin/* Pass /Docs/* /usr/lpp/internet/server_root/Docs/* Pass /errorpages/* /usr/lpp/internet/server_root/pub/errporpages/* Pass /* /usr/lpp/internet/server_root/pub/*
Pass /Admin/* /opt/ibm/edge/cp/server_root/Admin/* Pass /Docs/* /opt/ibm/edge/cp/server_root/Docs/* Pass /errorpages/* /opt/ibm/edge/cp/server_root/pub/errorpages/* Pass /* /opt/ibm/edge/cp/server_root/pub/*
Pass /icons/* C:\Archivos de programa\IBM\edge\cp\icons\* Pass /Admin/* C:\Archivos de programa\IBM\edge\cp\Admin\* Pass /Docs/* C:\Archivos de programa\IBM\edge\cp\Docs\* Pass /erropages/* C:\Archivos de programa\IBM\edge\cp\pub\errorpages\* Pass /* C:\Archivos de programa\IBM\edge\cp\pub\*
Utilice esta directiva para especificar el periodo de tiempo que el servidor espera entre las peticiones del cliente antes de cancelar una conexión persistente. El tiempo puede especificarse en cualquier incremento de tiempo válido, pero generalmente se especifica en segundos o minutos.
El servidor utiliza una directiva de tiempo de espera distinta, InputTimeout, para determinar cuánto tiempo debe esperar el cliente para enviar la primera petición después del establecimiento de la conexión. Para obtener más información sobre el tiempo de espera de la entrada, consulte InputTimeout: especificar el tiempo de espera de la entrada.
Después de que el servidor envíe la primera respuesta, éste utiliza el valor establecido de la directiva PersistTimeout para determinar cuánto tiempo se debe esperar a las peticiones posteriores antes de cancelar la conexión persistente.
PersistTimeout tiempo
PersistTimeout 4 seconds
Utilice esta directiva para especificar una función de aplicación personalizada a la que el servidor llama para recuperar las etiquetas PICS para un URL especificado. La función puede crear dinámicamente una etiqueta PICS para el archivo solicitado o bien buscar una etiqueta PICS en un archivo o base de datos alternativos.
PICSDBLookup /vía_acceso/archivo:nombre_función
PICSDBLookup /api/bin/icsext05.so:get_pics
Ninguno
Linux y UNIX sólo. Utilice esta directiva para especificar la ubicación del archivo que contiene el ID de proceso de Caching Proxy. Cuando se inicia el proceso de servidor, registra el ID de proceso ID (PID) en un archivo. Si varias instancias del servidor se ejecutan en un único sistema, todas las instancias deben tener su propia directiva PidFile.
PidFile vía_acceso_a_info_archivo_pid
PidFile /usr/pidinfo
En los sistemas AIX, se proporcionan directivas adicionales para dar soporte a la tarjeta IBM 4960 PCI Cryptographic Accelerator Card.
Utilice estas tres directivas para que el proxy pueda: cargar el controlador de dispositivo, abrir el dispositivo de señal y acceder a los certificados almacenados en el dispositivo. Cuando se carga el controlador de dispositivo, el servidor proxy utilizará automáticamente el dispositivo para aumentar la velocidad de comunicación de SSL.
Consulte también SSLCryptoCard: especificar la tarjeta criptográfica instalada.
PKCS11DefaultCert etiqueta_cert_por_omisión
Especifique la etiqueta del certificado SSL por omisión en el dispositivo de señal.
PKCS11DriverPath vía_absoluta_al_controlador_de_tarjeta
Especifique la vía de acceso absoluta al controlador de dispositivo de la tarjeta Cryptographic Accelerator Card.
PKCS11TokenPassword contraseña
Especifique la contraseña para abrir el dispositivo de señal.
PKCS11DefaultCert MyDefaultCertInTheToken PKCS11DriverPath /usr/lib/pkcs11/PKCS11_API.so PKCS11TokenPassword MyPasswordToOpenTheToken
Ninguno
Las directivas enumeradas a continuación se han añadido al archivo ibmproxy.conf de Caching Proxy para habilitar nuevas características y plug-ins. Los formularios de Configuración y Administración no están disponibles para la edición de la mayoría de estas directivas. Se debe utilizar un editor de texto estándar como vi o emacs para editarlas manualmente. Encontrará información adicional sobre estas nuevas directivas por orden alfabético en este capítulo.
En el archivo ibmproxy.conf, las directivas utilizadas para configurar los módulos de plug-in de Caching Proxy deben especificarse con el siguiente formato:
<MODULEBEGIN> nombre plug-in subdirectiva1 subdirectiva2 <MODULEEND>
Todos los programas de plug-in analizan el archivo ibmproxy.conf y leen únicamente su propio bloque de subdirectivas. El analizador de Caching Proxy ignora todo lo que aparece entre <MODULEBEGIN> y <MODULEEND>.
Los módulos de plug-in de Caching Proxy y algunas características nuevas requieren que las directivas API se añadan al archivo ibmproxy.conf. Como el servidor proxy interactúa con los módulos de plug-in en el orden en el que aparecen enumerados, tenga cuidado al ordenar las directivas en el archivo de configuración de proxy. Las directivas de prototipo (en forma de comentarios) se han añadido al apartado API del archivo ibmproxy.conf. Estas directivas API aparecen en un orden determinado. Al añadir las directivas API para habilitar nuevas características y módulos de plug-in, ordene las directivas como se muestran en la parte de prototipo del archivo de configuración. Alternativamente, elimine los comentarios de las directivas API y edítelas, si es necesario, para incluir el soporte de todas las funciones o plug-ins deseados. Añada los módulos de plug-in generados por el usuario después de los que se proporcionan con el producto.
Utilice esta directiva para especificar el número del puerto donde el servidor escucha las peticiones. El número de puerto estándar para HTTP es 80. Los demás números de puertos inferiores a 1024 se reservan para otras aplicaciones TCP/IP y no deben utilizarse. Los puertos comunes utilizados para los servidores Web de proxy son 8080 y 8008.
Cuando se utiliza un puerto distinto de 80, se le solicita a los clientes que incluyan un número de puerto específico en las peticiones al servidor. El número de puerto está precedido por dos puntos (:) y aparece colocado detrás del nombre de sistema principal del URL. Por ejemplo, desde el navegador, el URL http://www.turfco.com:8008/ solicita la página de bienvenida por omisión de un sistema principal denominado www.turfco.com que escucha en el puerto 8008.
Puede utilizar la opción -p del mandato ibmproxy para sobrescribir este valor al iniciar el servidor.
Port número
Si modifica esta directiva, debe detener y reiniciar el servidor manualmente para que el cambio entre en vigor. El servidor no reconoce el cambio si sólo lo reinicia. (Consulte el Inicio y detención de Caching Proxy.)
Port 80
Utilice esta directiva para especificar una función de aplicación personalizada a la que el servidor llama durante el paso de PostAuth. Este código se ejecuta independientemente de los códigos de retorno de pasos anteriores u otros manejadores PostAuth. Le permite limpiar cualquier recurso asignado para procesar la petición.
PostAuth /vía_acceso/archivo:nombre_función
AuthExit /ics/api/bin/icsext05.so:post_exit
Ninguno
Utilice esta directiva para especificar una función de aplicación personalizada a la que el servidor llama durante el paso de PostExit. Este código se ejecuta independientemente de los códigos de retorno de pasos anteriores u otros manejadores PostExit. Le permite limpiar cualquier recurso asignado para procesar la petición.
PostExit /vía_acceso/archivo:nombre_función
PostExit /ics/api/bin/icsext05.so:post_exit
Ninguno
Utilice esta directiva para especificar una función de aplicación personalizada a la que el servidor llama durante el paso de PreExit. Este código se ejecuta después de la lectura de una petición de cliente pero antes de que ocurra cualquier otro proceso. Puede llamar al módulo GoServe durante este paso.
PreExit /vía_acceso/archivo:nombre_función
PreExit /ics/api/bin/icsext05.so:pre_exit
Ninguno
Utilice esta directiva para activar las normas de configuración de protección de las peticiones que coinciden con una plantilla.
Una configuración de protección se define mediante subdirectivas de protección. El formato de la directiva Protect depende de si desea señalar a una etiqueta o archivo que contenga las subdirectivas de protección o bien incluir las subdirectivas de protección en línea como parte de la directiva Protect.
Este parámetro puede adoptar las siguientes formas:
Protect plantilla_petición [archivo_configuración | etiqueta[ [FOR dirección_IP_servidor | ]
Protect plantilla_petición [FOR dirección_IP_servidor | h] subdirectiva valor subdirectiva valor . . . }
Se utilizan los siguientes parámetros:
Este parámetro es opcional. Si se omite, la configuración de protección se define mediante la directiva DefProt más reciente que contiene una plantilla que coincida.
Ejemplo:
Protect http://x.x.x.x PROT-ADMIN
En un navegador Web:
Ejemplo:
Protect http://nombresistppal.ejemplo.com PROT-ADMIN
En un navegador Web:
Puede especificar una dirección IP (por ejemplo, FOR 240.146.167.72 ) o un nombre de sistema principal (por ejemplo, FOR sistppalA.bcd.com ).
Los caracteres comodín no pueden utilizarse para especificar las direcciones IP de servidor.
Este parámetro es opcional. Sin este parámetro, el servidor utiliza la directiva para todas las peticiones, independientemente de la dirección IP en la que entran las peticiones o el nombre de sistema principal del URL.
Estos ejemplos utilizan direcciones IP. Si el servidor recibe peticiones que empiecen por /secret/ o /topsecret/, activa una configuración de protección distinta de la petición basándose en la dirección IP de la conexión de red que esa petición utiliza para entrar.
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/* ClienteA-PROT FOR 0.67.106.79 Protect /secret/* ClienteB-PROT FOR 0.83.100.45 Protect /topsecret/* 0.67.106.79 { AuthType Basic ServerID restricted PasswdFile /docs/WWW/cliente-A.pwd GroupFile /docs/WWW/cliente-A.grp GetMask A-brass PutMask A-brass } Protect /topsecret/* 0.83.100.45 { AuthType Basic ServerID restricted PasswdFile /docs/WWW/cliente-B.pwd GroupFile /docs/WWW/cliente-B.grp GetMask B-brass PutMask B-brass }
Protect http://host1/* proxy-prot
Protect /secret/* ClienteA-PROT FOR sistppalA.bcd.com Protect /secret/* ClienteB-PROT FOR sistppalB.bcd.com Protect /topsecret/* sistppalA.bcd.com { AuthType Basic ServerID restricted PasswdFile /docs/WWW/cliente-A.pwd GroupFile /docs/WWW/cliente-A.grp GetMask A-brass PutMask A-brass } Protect /topsecret/* sistppalB.bcd.com { AuthType Basic ServerID restricted PasswdFile /docs/WWW/cliente-B.pwd GroupFile /docs/WWW/cliente-B.grp GetMask B-brass PutMask B-brass }
Por omisión, se proporciona protección para los formularios de Configuración y Administración mediante una directiva Protect con una plantilla de petición de /admin-bin/* .
Utilice esta directiva para definir una configuración de protección dentro del archivo de configuración. Debe darle un nombre a la configuración de protección y definir el tipo de protección mediante las subdirectivas de protección.
Protection nombre_etiqueta { subdirectiva valor subdirectiva valor . . . }
Consulte Subdirectivas de protección: especificar cómo proteger un conjunto de recursos para obtener descripciones de las subdirectivas de protección.
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 }
A continuación se proporcionan las descripciones de las subdirectivas de protección que pueden utilizarse en una configuración de protección. Las subdirectivas aparecen por orden alfabético.
Las configuraciones de protección pueden estar en archivos independientes o incluidas en el archivo de configuración como parte de las directivas DefProt, Protect o Protection.
Utilice esta subdirectiva de protección al limitar el acceso en función de los nombres de usuario y las contraseñas. Especifique el tipo de autenticación que se va a utilizar cuando el cliente envíe una contraseña al servidor. Con la autenticación básica AuthType Basic), las contraseñas se envían al servidor como texto plano. Se codifican pero no se cifran.
AuthType Basic
Utilice esta subdirectiva de protección para especificar las plantillas de nombres de usuario, grupos y direcciones autorizadas para realizar peticiones DELETE a un directorio protegido.
DeleteMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
Utilice esta subdirectiva de protección para especificar las plantillas de nombres de usuario, grupos y direcciones autorizadas para realizar peticiones GET a un directorio protegido.
GetMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
GetMask All@(*)
Utilice esta subdirectiva de protección para especificar la vía de acceso y el nombre de archivo del archivo de grupo de servidor que la configuración de protección utiliza. Los grupos definidos dentro del archivo de grupo de servidor los pueden utilizar posteriormente:
GroupFile /docs/etc/WWW/restrict.group
Utilice esta subdirectiva para especificar las plantillas de nombres de usuario, grupos y direcciones autorizadas para realizar peticiones HTTP que no estén cubiertas por otras subdirectivas de máscara.
Mask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
MASK WEBADM,webadm
Utilice esta subdirectiva de protección al limitar el acceso en función de los nombres de usuario y las contraseñas. Especifique la vía de acceso y nombre del archivo de contraseñas que va a utilizar esta configuración de protección.
Como algunos navegadores colocan en antememoria los ID de usuario y contraseñas según el reino de seguridad (ServerID) de un sistema principal, siga estas directrices al especificar los archivo de contraseñas y ServerID:
PasswdFile /docs/etc/WWW/restrict.password
PasswdFile "c:\test this\admin.pwd"
Para tener un servidor protegido, utilice esta subdirectiva de protección para especificar las plantillas de usuarios, grupos y direcciones autorizadas para realizar peticiones POST a un directorio protegido.
PostMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
Utilice esta subdirectiva de protección para especificar las plantillas de usuarios, grupos y direcciones autorizadas para realizar peticiones PUT a un directorio protegido.
PutMask authors,(niceguy,goodie)@45.96.3.1,128.0.*.*
Utilice esta subdirectiva de protección al limitar el acceso en función de los nombres de usuario y las contraseñas. Especifique un nombre que desee asociar con el archivo de contraseñas que se esté utilizando. No es necesario que el nombre sea el nombre real de la máquina.
El nombre se utiliza como un identificador del solicitante. Como distintas configuraciones de protección pueden utilizar archivos de contraseñas diferentes, la asociación de un nombre con la configuración de protección puede ayudar al cliente a decidir qué contraseña debe enviar. La mayoría de los clientes muestran este nombre al solicitar un nombre de usuario o contraseña.
Como algunos navegadores colocan en antememoria los ID de usuario y contraseñas según el reino de seguridad (ServerID) de un sistema principal, siga estas directrices al especificar los archivo de contraseñas y ServerID:
ServerID restricted
Utilice esta directiva para indicar qué protocolos va a procesar Caching Proxy y correlacionar una petición con un servidor. Los protocolos válidos son http, ftp y gopher.
La directiva de proxy pasa la petición a un servidor remoto. Por ejemplo, la siguiente directiva provoca que todas las peticiones se reenvíen al URL designado:
Proxy /* http://nombre.servidor.proxy/*
Para disponer de un servidor proxy de retorno, utilice la siguiente directiva:
Proxy /* https://nombre.servidor.proxy/*
Si desea que el servidor proxy sea menos restrictivo, elimine los comentarios de las siguientes directivas del archivo de configuración. No obstante, estas directivas pueden ocasionar un problema de seguridad cuando el proxy se configura como un proxy de retorno.
Proxy http:* Proxy ftp:* Proxy gopher:*
Parámetros opcionales:
Sólo se aplica a configuraciones de proxy de retorno.
Esta opción indica a Caching Proxy que mantenga una correlación de uno a uno entre el socket del cliente y el socket saliente. Esta opción es útil para algunas aplicaciones como, por ejemplo, la autenticación basada en conexiones, que necesitan al proxy para mantener activo el socket del servidor y reutilizar el socket para las peticiones que vengan del mismo socket del cliente.
Si se cumple la regla del proxy, esta opción indica al proxy que no coloque en antememoria las respuestas correspondientes.
Si se cumple la regla del proxy y hay una cabecera Rango en la petición, esta opción indica al proxy que no coloque en antememoria la respuesta correspondiente. Para obtener más información, consulte NoCacheOnRange -- Especificar sin colocación en antememoria para peticiones de rango.
Sólo se aplica a configuraciones de proxy de retorno.
Utilice esta opción si el plug-in de reescritura de enlace está habilitado. Esta opción no permite que el proxy reescriba las respuestas correspondientes si el URL entrante coincide. Para obtener más información, consulte Habilitación de la reescritura de unión (opcional) y Definición de la unión con la opción JunctionPrefix (método recomendado).
Sólo se aplica a configuraciones de proxy de retorno.
Utilice esta opción si el plug-in de reescritura de enlace está habilitado. En vez de inferir el prefijo de enlace a partir del primer patrón de URL en la regla de proxy, la opción declara explícitamente el prefijo de reescritura de enlace. Para obtener más información, consulte Habilitación de la reescritura de unión (opcional) y Definición de la unión con la opción JunctionPrefix (método recomendado).
Proxy plantilla_petición vía_servidor_destino [[ip]:puerto] [UseSession | NoCaching | NoCacheOnRange | NoJunction | JunctionPrefix:/prefijo_url]
A continuación aparece un ejemplo de la opción UseSession de la directiva Proxy:
Proxy /abc/* http://servidor1/por_omisión/abc/* :80 UseSession
Cuando la petición de entrada de cliente viene del puerto 80, y si el URL de la petición de cliente coincide con el patrón /abc/*, el URL se correlaciona con http://servidor1/por_omisión/abc/* .
Ninguno.
Utilice esta directiva para especificar la vía de acceso y el nombre del archivo donde desea que el servidor anote cronológicamente las estadísticas de acceso de las peticiones de proxy. Por ejemplo, el servidor escribe una entrada en estas anotaciones cronológicas siempre que actúa como un proxy para una petición de cliente. Puede utilizar la directiva NoLog si no desea anotar cronológicamente las peticiones de ciertos clientes.
El servidor inicia un nuevo archivo de anotaciones cronológicas cada día a las doce de la noche si se está ejecutando. De lo contrario, el servidor inicia un nuevo archivo de anotaciones cronológicas la primera vez que lo inicia en un día cualquiera. Al crear el archivo, el servidor utiliza el nombre de archivo que especifica e añadirá una extensión o sufijo de fecha. La extensión o sufijo de fecha aparece en el formato Mmmddaaaa, donde Mmm son las tres primeras letras del mes, dd es el día del mes y aaaa es el año.
Se recomienda eliminar los archivos de anotaciones cronológicas antiguos ya que pueden consumir un cantidad significativa de espacio de la unidad de disco duro.
ProxyAccessLog vía_acceso/archivo
Utilice esta directiva para especificar una aplicación personalizada a la que desea que el servidor llame durante el paso de Proxy Advisor. Este código dará servicio a la petición.
ProxyAdvisor /vía_acceso/archivo:nombre_función
ProxyAdvisor /api/bin/customadvise.so:proxyadv
Ninguno
Utilice la directiva ProxyForwardLabels para especificar el filtrado PICS en el servidor proxy y en el servidor, o en dos proxies de una jerarquía de proxy.
Si ProxyForwardLabels se establece en on, el servidor proxy genera cabeceras HTTP PICS-Label: de todas la etiquetas PICS encontradas, que incluyen las etiquetas del servidor de origen, las oficinas de etiquetas, la antememoria de etiquetas de Caching Proxy y los plug-ins de proveedor de etiquetas.
Si ProxyForwardLabels se establece en Off, las cabeceras HTTP PICS-Label: no se generan.
ProxyForwardLabels {on | off}
ProxyForwardLabels Off
Utilice esta directiva para generar una cabecera From:. Generalmente se utiliza para proporcionar una dirección de correo electrónico del administrador de proxy.
ProxyFrom dirección_correo_electrónico
El valor ProxyFrom webmaster@proxy.ibm.com ocasiona la siguiente modificación de la cabecera:
Cabecera original | Cabecera modificada |
---|---|
Location: http://www.ibm.com/ | Location: http://www.ibm.com/ |
Last Modified: Tue 5 Nov 1997 10:05:39 GMT | Last Modified: Tue 5 Nov 1997 10:05:39 GMT |
Pragma: no-cache | From: webmaster@proxy.ibm.com |
Pragma: no-cache |
Ninguno
Utilice esta directiva para especificar cómo reacciona el servidor cuando los usuarios pulsan Recargar en el navegador. Si la directiva ProxyIgnoreNoCache se establece en on, durante los periodos de carga elevada el servidor no solicita la página del servidor de destino y proporciona la copia en antememoria del archivo si está disponible. Esencialmente, el servidor hace caso omiso de la cabecera Pragma: no-cache enviada desde el navegador.
ProxyIgnoreNoCache {on | off}
ProxyIgnoreNoCache off
Utilice esta directiva para especificar si se desea mantener una conexión persistente con el cliente. Una conexión persistente reduce el tiempo de espera para los usuarios así como la carga de la CPU del servidor proxy, pero requiere más recursos. Se requieren más hebras y, por lo tanto, más memoria del servidor proxy para una conexión persistente.
Las conexiones persistentes no deben utilizarse en una configuración de servidores proxy de varios niveles si alguno de los proxies no es compatible con HTTP 1.1.
ProxyPersistence {on | off}
ProxyPersistence on
Utilice esta directiva para especificar si el proxy reenvía la dirección IP del cliente al servidor de destino.
ProxySendClientAddress {IP_cliente: | OFF}
La directiva ProxySendClientAddress Client-IP: ocasiona la siguiente modificación de la cabecera:
Cabecera original | Cabecera modificada |
---|---|
Location: http://www.ibm.com/ | Location: http://www.ibm.com |
Last Modified: Tue 5 Nov 1997 10:05:39 GMT | Last Modified: Tue 5 Nov 1997 10:05:39 GMT |
Pragma: no-cache | Client-IP: 0.67.199.5 |
Pragma: no-cache |
Ninguno
Utilice esta directiva para especificar la serie User Agent que sustituye a la serie que envía el cliente. Esta acción permite un mayor anonimato al visitar los sitios Web. No obstante, algunos sitios tienen páginas personalizadas basadas en la serie User Agent. La utilización de la directiva ProxyUserAgent evita que estas páginas de personalización se visualicen.
ProxyUserAgent nombre_producto/versión
La directiva ProxyUserAgent Caching Proxy/6.1 ocasiona la siguiente modificación de la cabecera:
Cabecera original | Cabecera modificada |
---|---|
Location: http://www.ibm.com/ | Location: http://www.ibm.com |
Last Modified: Tue 5 Nov 1997 10:05:39 GMT | Last Modified: Tue 5 Nov 1997 10:05:39 GMT |
User Agent: Mozilla/ 2.02 OS2 | User Agent: Caching Proxy/6.1 |
Pragma: no-cache | Pragma: no-cache |
Ninguno
Utilice esta directiva para controlar el formato de la cabecera HTTP. Existen cuatro valores posibles de esta directiva. Si ProxyVia se establece en Full, Caching Proxy añade una cabecera Via a la petición o respuesta; si una cabecera Via ya está en la corriente, Caching Proxy añade la información de sistema principal al final. Si se establece en Set, Caching Proxy establece la cabecera Via en la información de sistema principal; si una cabecera Via ya está en la corriente, Caching Proxy la elimina. Si se establece en Pass, Caching Proxy reenvía cualquier información como está. Si se establece en Block, Caching Proxy no reenvía ninguna cabecera Via.
ProxyVia {Full | Set | Pass | Block}
ProxyVia Pass
ProxyVia Full
Sólo se aplica a configuraciones de proxy de retorno.
La directiva de correlación ProxyWAS funciona de modo idéntico a la directiva Proxy, pero también indica a Caching Proxy que las peticiones coincidentes se dirijan a WebSphere Application Server. Por ejemplo, para obtener información sobre cómo utilizar esta directiva, consulte Proxy: especificar los protocolos de proxy o el proxy de retorno.
ProxyWAS plantilla_petición vía_acceso_servidor_destino [[ip]:puerto] [UseSession | NoCaching | NoCacheOnRange | NoJunction | JunctionPrefix:/prefijo_url]
Ninguno
Utilice esta directiva para especificar si el servidor debe actuar como un servidor proxy o como un proxy y servidor de contenido. Se recomienda que utilice Caching Proxy como proxy sólo.
PureProxy {on | off}
PureProxy on
Utilice esta directiva para especificar la antigüedad de las anotaciones cronológicas en días antes de que se depuren. Si PurgeAge se establece en 0, las anotaciones cronológicas no se suprimen nunca.
PurgeAge número
PurgeAge 7
Utilice esta directiva para especificar el tamaño en megabytes que pueden alcanzar los archivos de anotaciones cronológicas antes de que se depure el archivador de anotaciones cronológicas. Si la directiva PurgeSize se establece en 0, no existe límite de tamaño y no se suprimen archivos.
El valor de PurgeSize hace referencia a todas las anotaciones cronológicas de un tipo de anotaciones cronológicas. Por ejemplo, si está anotando cronológicamente los errores -es decir, si una entrada ErrorLog se ha realizado en el archivo de configuración- y PurgeSize está definido como 10 MB, Caching Proxy calcula los tamaños de todas las anotaciones cronológicas de error, las suma y, a continuación, elimina anotaciones cronológicas hasta que el tamaño total es inferior a 10 MB.
PurgeSize número_de_MB
PurgeSize 0
Utilice esta directiva para especificar el nombre y la ubicación del archivo de configuración de acceso a antememoria remota.
RCAConfigFile /etc/nombre_archivo
RCAConfigFile /etc/user2rca.conf
RCAConfigFile /etc/rca.conf
Utilice esta directiva para especificar el número de hebras que funcionan en un puerto RCA.
RCAThreads número_de_hebras
RCAThreads 50
MaxActiveThreads x [(ArraySize -1) / (2 x ArraySize -1)]
Utilice esta directiva para especificar el límite de tiempo permitido sin actividad de red antes de que se cancele una conexión.
ReadTimeout tiempo
ReadTimeout 5 minutes
Utilice esta directiva para especificar una plantilla para las peticiones que desea aceptar y enviar a otro servidor. Después de que una petición coincida con una plantilla de una directiva Redirect, la petición no se compara con las plantillas de ninguna otra directiva del archivo de configuración.
Redirect plantilla_petición URL [dirección_IP_servidor | ]
Puede utilizar un asterisco (*) como comodín en la plantilla. El carácter de tilde (~) que aparece justo después de una barra inclinada (/) debe coincidir explícitamente; no se puede utilizar un carácter comodín para que coincida con él.
URL debe contener una especificación de protocolo y el nombre del servidor al se envía la petición. También debe contener una vía de acceso o un nombre de archivo. Si plantilla_petición utiliza un comodín, la vía de acceso o el nombre de archivo de URL también puede contener un comodín. La parte de la petición original que coincide con el comodín de plantilla_petición se inserta en lugar del comodín de URL.
Puede especificar una dirección IP (por ejemplo, 240.146.167.72 ) o un nombre de sistema principal (por ejemplo, sistppalA.bcd.com ).
Este parámetro es opcional. Sin este parámetro, el servidor utiliza la directiva para todas las peticiones, independientemente de la dirección IP en la que entran las peticiones o el nombre de sistema principal del URL.
No puede especificarse un carácter comodín para la dirección IP de un servidor.
Redirect /chief/stuff/* http://www.otra.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/* sistppalA.bcd.com Redirect /stuff/* http://www.dawg.com/pound/* sistppalB.bcd.com
Ninguno
Utilice esta directiva para permitir a Caching Proxy almacenar en antememoria más de una variante de un recurso (URI) basándose en la cabecera Cookie.
Para obtener más información, consulte SupportVaryHeader: almacenar en antememoria más de una variante de un recurso basándose en la cabecera Vary de HTTP.
RegisterCacheIdTransformer Cookie nombre-cookie
nombre-cookie es el nombre de la cabecera Cookie en la petición del cliente.
RegisterCacheIdTransformer Cookie Usergroup
Para obtener un ejemplo de utilización de esta directiva junto con SupportVaryHeader, consulte SupportVaryHeader: almacenar en antememoria más de una variante de un recurso basándose en la cabecera Vary de HTTP.
Ninguno
Sólo se aplica a configuraciones de proxy de retorno.
La directiva de correlación ReversePass examina la corriente de respuestas de servidor para detectar las peticiones que se reescriben como resultado de la redirección automática. Generalmente, cuando un servidor devuelve un código HTTP de la clase 3xx (por ejemplo, 301, trasladado permanentemente, o 303, ver otro), el servidor envía un mensaje con la respuesta que indica al cliente solicitante que dirija las peticiones futuras a la dirección IP y el URL correctos. En el caso de una configuración de proxy de retorno, un mensaje de redirección desde el servidor de origen puede ocasionar que los navegadores de cliente omitan el servidor de proxy en peticiones posteriores. Para evitar que los clientes contacten con el servidor de origen directamente, utilice la directiva ReversePass para interceptar las peticiones que se realizan específicamente al servidor de origen.
A diferencia de las demás directivas de correlación, que procesan la corriente de peticiones, ReversePass hace coincidir su plantilla con la corriente de respuestas. La corriente de respuestas es la respuesta que el servidor proxy obtiene del servidor de origen y envía al cliente.
ReversePass URL_reescrito URL_proxy [sistppal:puerto]
La opción sistppal:puerto permite que el proxy aplique una norma ReversePass distinta basada en el nombre de sistema principal y el puerto del servidor de programa de fondo.
ReversePass http://backend.company.com:9080/* http://edge.company.com/*El puerto 9080 es el puerto por omisión de Application Service at the Edge. Este tipo de petición puede generarse si el servidor de aplicaciones de origen devuelve un código de 3xx al cliente.
ReversePass http://edge.company.com:9080/* http://edge.company.com/*
Ninguno
Sólo se aplica a configuraciones de proxy de retorno.
Utilice esta directiva para especificar el patrón de dominio que es necesario reescribir. La directiva modificará el dominio de patrón_dominio1 a patrón_dominio2.
RewriteSetCookieDomain patrón_dominio1 patrón_dominio2
RewriteSetCookieDomain .internal.com .external.com
Ninguno
Sólo se aplica a configuraciones de proxy de retorno.
Esta directiva habilita o inhabilita la redirección de RTSP. Las opciones son on u off.
RTSPEnable {on | off}
RTSPEnable on
Ninguno
Sólo se aplica a configuraciones de proxy de retorno.
Esta directiva se utiliza para especificar que los servidores proxy de RTSP reciban las peticiones redirigidas. Se pueden especificar distintos servidores para tipos de corrientes diferentes. El formato de esta directiva es:
rtsp_proxy_server dirección dns servidor[:puerto] rango por omisión [lista de tipos 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
Ninguno
Sólo se aplica a configuraciones de proxy de retorno.
Esta directiva especifica cuántas peticiones se reciben antes de que una petición RTSP se redirija a un servidor proxy en lugar de a un servidor de origen. Los proxies RealNetworks colocan en antememoria las corrientes de la primera petición e inicialmente la colocación en antememoria se produce al doble del ancho de banda de la recepción de una corriente. La especificación de un umbral mayor que uno evita que las peticiones realizadas una vez se coloquen en antememoria. El formato de esta directiva es:
rtsp_proxy_threshold número_de_coincidencias
rtsp_proxy_threshold 5
Ninguno
Sólo se aplica a configuraciones de proxy de retorno.
Esta directiva especifica el número de los URL exclusivos que se mantienen en la memoria para la redirección. El proxy consulta esta lista para determinar si se ha encontrado un determinado URL anteriormente. Los tamaños de lista más grandes mejoran la capacidad del servidor proxy para enviar una petición posterior al mismo servidor proxy que haya recibido la petición anterior, aunque todas las entradas de lista consumen aproximadamente 16 bytes de memoria.
rtsp_url_list_size tamaño_de_lista
rtsp_url_list_size 8192
Ninguno
Por omisión, cuando Caching Proxy correlaciona peticiones con reglas definidas en el archivo ibmproxy.conf, el proceso de coincidencia es sensible a mayúsculas y minúsculas. Sin embargo, algunos URL de aplicación no son sensibles a mayúsculas y minúsculas. Para manejar correctamente estas peticiones, se proporciona la directiva RuleCaseSense. Cuando la directiva se establece en off, el proxy emparejará peticiones independientemente de que tengan mayúsculas o minúsculas.
RuleCaseSense {on | off}
RuleCaseSense on
Utilice esta directiva para establecer el tiempo permitido para que finalice un programa CGI iniciado por el servidor. Cuando caduca el tiempo, el servidor finaliza el programa. En las plataforma Linux y UNIX, esto se realiza con la señal KILL.
Especifique el valor de tiempo mediante cualquier combinación de horas, minutos (o mins) y segundos (o segs).
ScriptTimeout tiempo_espera
ScriptTimeout 5 minutes
Utilice esta directiva para especificar qué peticiones enviadas desde Caching Proxy a un servidor en sentido descendente deben utilizar el protocolo HTTP versión 1.0. Un servidor en sentido descendente es otro servidor proxy de una cadena de proxies o un servidor de origen que procesa la petición.
Si se utiliza esta directiva, Caching Proxy identifica HTTP 1.0 como el protocolo de la línea de petición. Sólo las funciones específicas de HTTP 1.0 y ciertas funciones de HTTP 1.1 como, por ejemplo, las cabeceras de control de antememoria, a las que dan soporte la mayoría de los servidores HTTP 1.0, se envían al servidor en sentido descendente. Utilice esta directiva si tiene un servidor en sentido descendente que no maneja las peticiones HTTP 1.1 correctamente.
Si no se especifica la directiva SendHTTP10Outbound, Caching Proxy identifica HTTP 1.1 como el protocolo de la línea de petición. Las funciones de HTTP 1.1, como, por ejemplo, las conexiones persistentes, también pueden utilizarse en la petición.
SendHTTP10Outbound patrón_url
Esta directiva puede especificarse varias veces, por ejemplo:
SendHTTP10Outbound http://www.hosta.com/* SendHTTP10Outbound http://www.hostb.com/*
Para obtener la compatibilidad con versiones anteriores, la sintaxis anterior de SendHTTP10Outbound se maneja del siguiente modo:
Ninguno
Sólo se aplica a configuraciones de proxy de retorno.
Al funcionar como un proxy de retorno, Caching Proxy recibe peticiones HTTP de un cliente y envía las peticiones al servidor de origen. Por omisión, Caching Proxy escribe el nombre de sistema principal del servidor de origen en la cabecera HOST de la petición que se envía al servidor de origen. Si esta directiva SendRevProxyName se establece en yes, Caching Proxy escribe su propio nombre de sistema principal en la cabecera HOST en su lugar. Esta directiva puede utilizarse para habilitar la configuración especial de servidores de programa de fondo, ya que permite que la petición al servidor de origen siempre aparezca si procediese del servidor proxy, incluso cuando la petición se redirige de un servidor de programa de fondo a otro.
Esta directiva difiere de las directivas de correlación ReversePass del modo siguiente: la directiva ReversePass intercepta las peticiones con una sintaxis especificada y sustituye el contenido de petición distinto que especifique. La directiva SendRevProxyName sólo puede establecerse para sustituir el nombre de sistema principal de Caching Proxy por el nombre de sistema principal del servidor de origen. Esta directiva no es útil para configurar Application Service at the Edge.
SendRevProxyName {yes | no}
Esta directiva establece el intervalo durante el cual la hebra de recogida de basura busca las conexiones de servidor que han excedido el tiempo de espera, que se establece con la directiva ServerConnTimeout. Utilice esta directiva sólo si la directiva ServerConnPool está establecida en on.
ServerConnGCRun intervalo_tiempo
ServerConnGCRun 2 minutes
ServerConnGCRun 2 minutes
Esta directiva permite que el proxy agrupe las conexiones de salida con los servidores de origen. El establecimiento de esta directiva en on mejora el rendimiento y permite aprovechar mejor los servidores de origen que permiten las conexiones persistentes. También puede especificar cuánto tiempo desea mantener una conexión en desuso a través de la directiva ServerConnTimeout.
ServerConnPool {on | off}
ServerConnPool off
Utilice esta directiva para limitar el tiempo permitido sin actividad de red antes de cancelar la conexión. Utilice esta directiva sólo si la directiva ServerConnPool está establecida en on.
ServerConnTimeout especificación-tiempo
ServerConnTimeout 30 seconds
ServerConnTimeout 10 seconds
Utilice esta directiva para especificar una función de aplicación personalizada a la que el servidor llama durante las rutinas de inicialización. Este código se ejecuta antes de que se lea cualquier petición de cliente y siempre que el servidor se reinicie.
Si está utilizando los módulos GoServe en los pasos de PreExit o de servicio, es necesario que aquí llame al módulo gosclone.
ServerInit /vía_acceso/archivo:nombre_función [serie_inicialización]
ServerInit /ics/api/bin/icsext05.so:svr_init
Ninguno
Utilice esta directiva para especificar el directorio dónde se va a instalar el programa servidor, es decir, el directorio de trabajo actual del servidor. Las directivas de registro cronológico utilizan este directorio de trabajo actual como el directorio raíz por omisión cuando se utilizan los nombres de vías de acceso relativas.
En los sistemas Windows, el directorio se identifica durante la instalación.
ServerRoot vía_acceso_directorio
Utilice esta directiva para especificar una función de aplicación personalizada a la que el servidor llama durante el paso de terminación de servicio. Este código se ejecuta cuando se produce una conclusión ordenada y siempre que el servidor se reinicie. Le permite liberar los recursos asignados por una función de aplicación PreExit
ServerTerm /vía_acceso/archivo:nombre_función
ServerTerm /ics/api/bin/icsext05.so:shut_down
Ninguno
Utilice esta directiva para especificar una función de aplicación personalizada a la que el servidor llama durante el paso de servicio. Este código da servicios a la petición de cliente. Por ejemplo, envía el archivo o ejecuta el programa CGI.
No existe un valor por omisión para esta directiva. Si la petición coincide con una norma Service, es decir, si se ejecuta una función de aplicación especificada en una directiva Service, pero la función devuelve HTTP_NOACTION, el servidor genera un error y la petición no se realiza correctamente.
Service plantilla_petición/vía_acceso/archivo:nombre_función [dirección_IP_servidor | ]
No puede especificarse un carácter comodín para la dirección IP de un servidor.
Service /index.html /ics/api/bin/icsext05.so:serve_req Service /cgi-bin/hexcalc* /ics/api/calculator:HEXcalc*
Ninguno
Utilice esta directiva para especificar un código de terminación de las peticiones URL. La utilización del código de terminación en una petición provoca que Caching Proxy evalúe sólo los caracteres que aparecen antes del código de terminación durante el proceso de la petición y al evaluar si el resultado ya está colocado en antememoria. Cuando se define más de un código de terminador, Caching Proxy compara los URL de entrada con los códigos de terminador en el orden en el que están definidos en el archivo ibmproxy.conf.
SignificantURLTerminator serie_terminación
SignificantURLTerminator &.
En este ejemplo, las dos peticiones que siguen aparecen a continuación se tratan de igual modo.
http://www.exampleURL.com/tx.asp?id=0200&.;x=004;y=001 http://www.exampleURL.com/tx.asp?id=0200&.;x=127;y=034
Ninguno
Utilice esta directiva para establecer el servidor SMTP utilizado por la rutina sendmail de Caching Proxy para Windows. Las dos directivas siguientes también deben establecerse para esta rutina: WebMasterEMail: establecer una dirección de correo electrónico para recibir informes de servidor seleccionados y WebMasterSocksServer (Windows sólo): establecer un servidor socks para la rutina sendmail.
SMTPServer dirección IP o nombre de sistema principal del servidor SMTP
SMTPServer mybox.com
Ninguno
Utilice esta directiva para habilitar o inhabilitar el soporte SNMP.
SNMP {on | off}
SNMP off
Utilice esta directiva para definir la contraseña entre el subagente DPI (Distributed Protocol Interface) del servidor Web y el agente SNMP. El nombre de la comunidad SNMP autoriza a un usuario a visualizar las variables de rendimiento supervisadas por SNMP para una comunidad especificada de servidores. El administrador del sistema define qué variables de los servidores pueden visualizarse cuando se especifica una contraseña. Si modifica el nombre de la comunidad SNMP, asegúrese también de modificar el nombre de comunidad especificado en el archivo /etc/snmpd.conf.
SNMPCommunity nombre
SNMPCommunity public
Utilice esta directiva para colocar en antememoria el contenido de una petición segura cuando se utiliza un servidor proxy de retorno. Esta directiva configura la colocación en antememoria de todas las conexiones con el servidor proxy, tanto las conexiones de cliente como las conexiones con un servidor de contenido de programa de fondo.
SSLCaching {on | off}
SSLCaching off
Utilice esta directiva para especificar las etiquetas de clave que permiten al proxy determinar qué certificado se va a enviar al cliente cuando Caching Proxy esté actuando como un único proxy de retorno para varios dominios que ofrezcan sus propios certificados SSL y para indicar al servidor proxy que recupere o no un certificado PKI de la parte cliente para la autenticación de cliente.
Utilizando la directiva SSLCertificate, Caching Proxy puede distinguir entre un certificado emitido por una autoridad de certificación (CA) o un certificado autoasignado. Sin embargo, al aceptar un certificado emitido por cualquier CA (opción ClientAuthRequired), el uso de esta directiva puede permitir a los usuarios que no sean válidos obtener acceso al servidor proxy. Al utilizar la opción ClientAuthRequired en la directiva SSLCertificate, puede utilizar la opción de expresión lógica para determinar qué usuarios válidos pueden acceder al canal SSL.
Cuando se añade una expresión lógica adicional a la directiva SSLCertificate, Caching Proxy extrae valores del certificado de cliente y calcula la expresión lógica. Si los valores del certificado del cliente son satisfactorios para la expresión, Caching Proxy otorga al cliente el uso de la conexión SSL; en caso contrario, se cierra la conexión.
SSLCertificate Ipservidor/nombresistppal EtiquetaCertificado [NoClientAuth | ClientAuthRequired expresión-lógica]
La opción de expresión lógica sólo es válida cuando se utiliza con la opción ClientAuthRequired. Cuando se añade una expresión lógica adicional a la directiva SSLCertificate, Caching Proxy extrae valores del certificado de cliente y calcula la expresión lógica. Si los valores del certificado del cliente son satisfactorios para la expresión, Caching Proxy otorga al cliente el uso de la conexión SSL; en caso contrario, se cierra la conexión.
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")
Ninguno
Sólo se aplica a configuraciones de proxy de retorno.
Utilice esta directiva para indicar al servidor proxy que hay una tarjeta criptográfica instalada y para especificar la tarjeta.
En AIX, para dar soporte a la tarjeta IBM 4960 PCI Cryptographic Accelerator Card, consulte PKCS11DefaultCert, PKCS11DriverPath, PKCS11TokenPassword -- Da soporte a la tarjeta IBM 4960 PCI Cryptographic Accelerator Card (sólo AIX).
SSLCryptoCard {rainbowcs | nciphernfast} {on | off}
SSLCryptoCard rainbowcs on
Ninguno
Utilice esta directiva para especificar que Caching Proxy escucha las peticiones seguras en el puerto 443.
SSLEnable {on | off}
SSLEnable off
Utilice esta directiva para especificar el puerto al que dirigirse para las peticiones HTTP que Caching Proxy actualiza a peticiones HTTPS mediante la implementación SSL. Especifique un puerto distinto del puerto HTTP principal 80 o el puerto SSL principal 443.
SSLForwardPort número de puerto
SSLForwardPort 8888
Ninguno
Utilice esta directiva para inhabilitar las hebras de receptor de las peticiones HTTP estándar (generalmente puertos 80 y 8080) cuando se habilita SSL (generalmente el puerto 443).
SSLOnly {on | off}
SSLOnly off
Utilice esta directiva para especificar el puerto de escucha HTTPS distinto del puerto HTTPS por omisión 443 de ibmproxy.
SSLPort valor de puerto
donde valor de puerto es un valor entero mayor que 0. Asimismo, el sistema operativo debe permitir valor de puerto, que no puede utilizar ninguna otra aplicación.
SSLPort 8443
443
Sólo se aplica a configuraciones de proxy de reenvío.
Activar esta directiva (valor on) habilita los túneles SSL para cualquier puerto del servidor de destino. Desactivar esta directiva (valor off) sólo habilita los túneles SSL para los puertos indicados en las normas Proxy. Si no existe ninguna norma Proxy para los túneles SSL, y la directiva SSLTunneling se establece en off, no se permitirán los túneles SSL. Si la directiva SSLTunneling se establece en on, también debe habilitar el método CONNECT mediante la directiva Enable.
Debe habilitar esta directiva si utiliza Caching Proxy como proxy de reenvío. Sin embargo, al utilizar Caching Proxy como proxy de retorno, la inhabilitación de esta directiva (por omisión) protege contra los ataques a la vulnerabilidad de los túneles SSL.
Para obtener más información, consulte Túneles SSL.
SSLTunneling {on | off}
SSLTunneling off
Utilice esta directiva para especificar la versión de SSL que se va a utilizar: V2, V3 o todas las versiones. Establezca esta directiva en V2 si está utilizando servidores que no pueden dar soporte a SSL Versión 3.
SSLVersion {SSLV2 | SSLV3 | all}
SSLVersion SSLV3
Utilice esta directiva para especificar en segundos durante cuánto tiempo una sesión de SSL versión 2 espera sin actividad antes de que caduque la sesión.
SSLV2Timeout segundos
donde segundos representa un valor entre 0 y 100.
SSLV2Timeout 100
Utilice esta directiva para especificar en segundos durante cuánto tiempo una sesión de SSL versión 3 espera sin actividad antes de que caduque.
SSLV3Timeout segundos
donde segundos representa un valor entre 1 y 86400 segundos (que es 1 día en segundos).
SSLV3Timeout 100
Utilice esta directiva para especificar si desea que el servidor distinga entre mayúsculas y minúsculas cuando los sufijos de archivo se comparen con los patrones de sufijo de las directivas AddClient, AddCharSet, AddType, AddEncoding y AddLanguage. Por omisión, el servidor no realiza la distinción entre mayúsculas y minúsculas.
SuffixCaseSense {on | Off}
SuffixCaseSense Off
Utilice esta directiva para permitir a Caching Proxy almacenar en antememoria más de una variante de un recurso (URI) basándose en la cabecera Vary de HTTP.
Cuando esta habilitada la directiva SupportVaryHeader, el proxy forma un ID de antememoria ID basándose en el URI y los valores de cabecera seleccionados en la petición del cliente.
Los nombres de las cabeceras seleccionadas se especifican en la cabecera Vary enviada en una respuesta anterior desde el servidor. Si el servidor cambia el conjunto de nombres de cabecera de un recurso, todos los objetos de antememoria anteriores del recurso se eliminan de la antememoria del proxy.
Esta directiva se puede utilizar con la directiva RegisterCacheIdTransformer (RegisterCacheIdTransformer: almacenar en antememoria más de una variante de un recurso basándose en la cabecera Cookie).
Cuando se utilizan ambas directivas, el proxy crea un transformador interno de ID de antememoria basándose en la cabecera Vary del servidor y en la cabecera de la petición del cliente. De esta forma, el proxy puede generar identificadores de antememoria exclusivos para pares de petición y respuesta distintos, aunque los URI solicitados sean los mismos.
Los objetos de antememoria del mismo URI tienen su propia vida por omisión en la antememoria, en función de las cabeceras Expire y Cache-Control de las peticiones/respuestas, u otros valores de configuración. Si se utiliza el plug-in Dynacache, todas las presentaciones asociadas al mismo URI pasan a ser no válidas en la antememoria del proxy.
SupportVaryHeader {on | off}
En este ejemplo, se habilitan y configuran las directivas en ibmproxy.conf, tal y como se indica:
SupportVaryHeader on RegisterCacheIdTransformer Cookie UserGroup
El cliente Guest accede al servidor proxy con
URI [<code>] http://www.dot.com/group.jpg [</code>]
y la siguiente petición/respuesta:
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 .......
A continuación, el cliente Admin accede al servidor proxy con el mismo URI
http://www.dot.com/group.jpg
y la siguiente petición/respuesta:
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 .......
Como resultado, si las respuestas se pueden almacenar en antememoria, el servidor proxy genera dos ID de antememoria distintos:
1. CacheID(URI, "Guest", "en_US") 2. CacheID(URI, "Admin", "fr_FR")
El servidor proxy almacena dos variantes distintas de las respuestas del servidor en la antememoria. Posteriormente, cuando cualquier cliente solicita el recurso (.../group.jpg), con una combinación de valores de preferencia de idioma y de grupos de usuarios, el servidor proxy recupera la variante adecuada del recurso de la antememoria y la proporciona.
SupportVaryHeader off
Utilice esta directiva para habilitar el protocolo TLS versión 1 en las conexiones SSL. Después de activar esta directiva, la conexión SSL primero comprueba el protocolo TLS, seguidamente el protocolo SSLv3 y por último el protocolo SSLv2.
TLSV1Enable {on | off}
TLSV1Enable on
Ninguno
Utilice esta directiva para especificar una función de aplicación personalizada a la que el servidor llama durante el paso de manipulación de datos. Este código proporciona tres funciones de aplicación:
Puede tener varios Transmogrifiers para cada instancia del servidor.
Transmogrifier /vía_acceso/archivo: nombre_función:nombre_función:nombre_función
Transmogrifier /ics/bin/icsext05.so:open_data:write_data:close_data
Ninguno
Utilice esta directiva para enviar un mensaje al cliente informándole de los datos:
transmogrifiedwarning {yes|no}
Yes
Sólo se aplica a configuraciones de proxy de reenvío.
Sólo para sistemas Linux, utilice esta directiva para especificar si el servidor puede ejecutarse o no como servidor proxy transparente.
Cuando la directiva TransparentProxy se establece en on, la directiva BindSpecific se pasa por alto y toma el valor off por omisión. Como la mayoría del tráfico HTTP fluye a través del puerto 80, se recomienda que sea uno de los puertos configurados.
TransparentProxy {on | off} Port 80
TransparentProxy off
Si se utiliza el cortafuegos IPCHAIN, basta con habilitar esta directiva para configurar satisfactoriamente el proxy transparente. Si se utiliza el cortafuegos IPTABLES, tendrá que añadir manualmente la norma del cortafuegos IPTABLES.
Si utiliza el cortafuegos IPTABLES, cuando se habilite la directiva TransparentProxy y antes de iniciar el servidor proxy, ejecute el mandato siguiente para añadir la norma de cortafuegos a IPTABLES:
iptables -t nat -A PREROUTING -i interfaz-red-usuario -p tcp --dport 80 -j REDIRECT --to-port puerto-escucha-ibmproxy
Suponiendo que el cortafuegos y el servidor proxy estén en el mismo receptáculo, esta norma indica al cortafuegos IPTABLES que redirija todo el tráfico de TCP designado para el puerto 80 al puerto de escucha del proxy local. La norma también se puede añadir a la configuración de IPTABLES. Esto permite que la norma se cargue automáticamente cuando se reinicie el sistema.
Después de iniciar el proxy transparente, si desea detener el servidor Caching Proxy, también debe emitir el siguiente mandato como root:
ibmproxy -unload
En los sistemas Linux, este mandato elimina las normas de cortafuegos de redirección. Si no emite este mandato después de detener el servidor, la máquina aceptará las peticiones que no está dirigidas a él.
Utilice esta directiva para especificar qué servidor proxy actualizará el agente de antememoria. Esta directiva es necesaria cuando el agente de antememoria debe actualizar un servidor proxy distinto del servidor proxy local donde está en ejecución el agente de antememoria. Opcionalmente, puede especificar el puerto.
Aunque el agente de antememoria puede actualizar la antememoria en otro servidor, no puede recuperar las anotaciones cronológicas de acceso a la antememoria desde esa máquina. Por lo tanto, si la directiva UpdateProxy especifica un sistema principal que sea distinto del sistema principal local, la directiva LoadTopCached se ignora.
UpdateProxy nombre_de_sistppal_plenamente_cualificado_de_server_proxy
UpdateProxy proxy15.ibm.com:1080
Ninguno
Utilice esta directiva para especificar el nombre o número de usuario al que cambia el servidor antes de acceder a los archivos.
Si modifica esta directiva, debe detener y reiniciar el servidor manualmente para que el cambio entre en vigor. El servidor no reconoce el cambio si sólo lo reinicia. (Consulte el Inicio y detención de Caching Proxy.)
UserId {nombre_ID | número}
AIX, Linux, Solaris: UserId nobody
HP-UX: UserId www
Esta directiva enumera las especificaciones de cifrado disponibles para SSL Versión 2.
V2CipherSpecs especificación
Los valores aceptables son cualquiera de las combinaciones siguientes. Ninguno puede utilizarse dos veces.
Ninguno (SSL está inhabilitada por omisión).
Esta directiva enumera las especificaciones de cifrado disponibles para SSL Versión 3.
Si la directiva FIPSenable está establecida en "on", se ignorará la directiva V3CipherSpecs. Para obtener más información, consulte FIPSEnable: cifrados aprobados por FIPS (Enable Federal Information Processing Standard) para SSLV3 y TLS.
V3CipherSpecs especificación
Los valores aceptables son los siguientes:
Ninguno (SSL está inhabilitada por omisión).
Utilice esta directiva para establecer una dirección de correo electrónico donde recibir informes de Caching Proxy seleccionados como, por ejemplo, un aviso 30 días antes de la fecha de caducidad de un certificado SSL. En los sistemas Linux y UNIX debe estar en ejecución un proceso sendmail. Para los sistemas Windows, el proceso sendmail se crea dentro de Caching Proxy de modo que no es necesario ningún servidor de correo externo; no obstante, deben establecerse dos directivas adicionales: WebMasterSocksServer (Windows sólo): establecer un servidor socks para la rutina sendmail y SMTPServer (Windows sólo): establecer un servidor SMTP para la rutina sendmail.
WebMasterEMail direccióncorreoelectrónicoWebmaster
WebMasterEmail webmaster@computer.com
WebMasterEmail webmaster
Utilice esta directiva para establecer el servidor socks utilizado por la rutina sendmail de Caching Proxy para Windows. Las dos directivas siguientes también deben establecerse para esta rutina: WebMasterEMail: establecer una dirección de correo electrónico para recibir informes de servidor seleccionados y SMTPServer (Windows sólo): establecer un servidor SMTP para la rutina sendmail.
WebMasterSocksServer dirección IP o sistema principal de servidores socks
WebMasterSocksServer socks.mybox.com
Ninguno
Utilice esta directiva para especificar el nombre de un archivo de bienvenida que el servidor busca para responder a las peticiones que no contienen un nombre de archivo específico. Puede crear una lista de archivos de bienvenida introduciendo varias apariciones de esta directiva en el archivo de configuración.
Para las peticiones que no contienen un nombre de archivo o nombre de directorio, el servidor siempre busca en el directorio raíz un archivo que coincida con un nombre especificado en una directiva Welcome. Si se encuentra una coincidencia, el archivo se devuelve al solicitante.
Para las peticiones que contienen un nombre de directorio pero carecen de un nombre de archivo, la directiva AlwaysWelcome controla si el servidor busca en el directorio un archivo de bienvenida para devolverlo. Por omisión, AlwaysWelcome se establece en un valor de On. Esto significa que el servidor siempre busca en el directorio solicitado un archivo que coincida con un nombre especificado en una directiva Welcome. Si se encuentra una coincidencia, el archivo se devuelve al solicitante.
Si el servidor encuentra más de una coincidencia entre los archivos de un directorio y los nombres de archivo de las directivas Welcome, el orden de las directivas Welcome determina qué archivo se devuelve. El servidor utiliza la directiva Welcome más cercana a la parte superior del archivo de configuración.
Welcome nombre_archivo [dirección_IP_servidor | nombre_sistppal]
Puede especificar una dirección IP (por ejemplo, 240.146.167.72) o un nombre de sistema principal (por ejemplo, sistppalA.bcd.com ).
Este parámetro es opcional. Sin este parámetro, el servidor utiliza la directiva para todas las peticiones, independientemente de la dirección IP en la que entran las peticiones o el nombre de sistema principal de los URL.
No puede especificarse un carácter comodín para la dirección IP de un servidor.
Welcome letsgo.html Welcome Welcome.html
Welcome ClienteA.html 0.67.106.79 Welcome ClienteB.html 0.83.100.45
Welcome ClienteA.html sistppalA.bcd.com Welcome ClienteB.html sistppalB.bcd.com
Estos valores por omisión están en el orden utilizado por la configuración por omisión:
Welcome Welcome.html Welcome welcome.html Welcome index.html Welcome Frntpage.html