Preparación para el examen de LPI: servicios web

Tema 208 de la Administración de Nivel Intermedio (LPIC-2)

En este tutorial, el cuarto de una serie de siete tutoriales que incluye la administración de redes de nivel intermedio sobre Linux, David Mertz sigue preparándolo para rendir el Examen 208® de Intermediate Level Administration (Administración de Nivel Intermedio) de Linux Professional Institute (LPIC-2). Aquí, David Mertz analiza cómo configurar y ejecutar el servidor HTTP Apache y el servidor proxy Squid.

David Mertz, Developer, Gnosis Software, Inc.

David MertzDavid Mertz cree que los lenguajes artificiales son perfectamente naturales pero los lenguajes naturales parecen un poco artificiales. Es posible contactar a David en mertz@gnosis.cx; podrá investigar todos los aspectos de su vida en su página Web personal. Vea su libro, Text Processing in Python (Procesamiento de Texto en Python). Las sugerencias y recomendaciones sobre las columnas pasadas o futuras son bienvenidas.



29-07-2011

Antes de comenzar

Sepa lo que estos tutoriales pueden enseñarle y cómo aprovecharlos al máximo.

Acerca de esta serie

Linux Professional Institute (LPI) certifica a los administradores del sistema Linux en dos niveles: nivel junior(también denominado "certificación nivel 1") y nivel intermedio(también denominado "certificación nivel 2"). Para alcanzar la certificación nivel 1, usted deberá aprobar los exámenes 101 y 102; para alcanzar la certificación nivel 2, deberá aprobar los exámenes 201 y 202.

developerWorks ofrece tutoriales para ayudarlo a prepararse para cada uno de los cuatro exámenes. Cada examen cubre varios temas y, a su vez, cada tema cuenta con un tutorial de autoestudio sobre developerWorks. Para el examen 202 de LPI, los siete temas y los correspondientes tutoriales de developerWorks son los siguientes:

Tabla 1. Examen 202 de LPI: Tutoriales y temas
Tema del examen 202 de LPItutorial de developerWorksResumen del tutorial
Tema 205Preparación para el examen 202 de LPI (tema 205):
Configuración de redes
Aprenda a configurar la red TCP/IP básica, de la capa de hardware (por lo general Ethernet, modem, ISDN, u 802.11) mediante el ruteo de las direcciones de red.
Tema 206Preparación para el examen 202 de LPI (tema 206):
Correo y noticias
Aprenda a utilizar Linux como servidor de correo y servidor de noticias. Aprenda cómo funcionan el transporte de correo, el filtrado de correo local, el software de mantenimiento de la lista de correspondencia y el software del servidor para el protocolo NNTP.
Tema 207Preparación para el examen 202 de LPI (tema 207):
DNS
Aprenda a utilizar Linux como servidor de DNS, usando principalmente BIND. Aprenda a realizar una configuración básica de BIND, a gestionar las zonas DNS y a asegurar el servidor DNS.
Tema 208Preparación para el examen 202 de LPI (tema 208):
servicios web
(Este tutorial) Aprenda a instalar y configurar el servidor Web Apache, y sepa cómo implementar el servidor proxy Squid. Vea un detalle de los objetivos más abajo.
Tema 210Preparación para el examen 202 de LPI (tema 210):
Gestión del cliente de red
Próximamente
Tema 212Preparación para el examen 202 de LPI (tema 212):
Seguridad del sistema
Próximamente
Tema 214Preparación para el examen 202 de LPI (tema 214):
Solución de problemas de red
Próximamente

Para empezar a prepararse para la certificación nivel 1, vea los tutoriales de developerWorks para el examen 101 de LPI. Para prepararse para la certificación nivel 2, vea los tutoriales de developerWorks para el examen 201 de LPI. Lea más sobre el conjunto completo de tutoriales de developerWorks para LPI.

Linux Professional Institute no avala ningún material o técnica de terceros en particular para la preparación del examen. Para más detalles, póngase en contacto con info@lpi.org.

Acerca de este tutorial

Bienvenido a "Web services" (servicios web), el cuarto tutorial de los siete referidos a la administración de redes de nivel intermedio sobre Linux. En este tutorial, aprenderá a configurar y ejecutar el servidor HTTP Apache y el Servidor Web Proxy-Caché Squid.

Tal como ocurre con los demás tutoriales de las series developerWorks 201 y 202, el propósito de este tutorial es servir como guía de estudio y punto de partida para la preparación del examen y no como documentación completa sobre el tema. Se recomienda a los lectores consultar la lista de objetivos detallados de LPI y complementar la información suministrada aquí con otro material cuando resulte necesario.

Este tutorial está organizado de acuerdo con los objetivos de LPI para este tema. En términos generales, en el examen deberá esperar más preguntas sobre los objetivos de mayor ponderación.

Tabla 2. servicios web: Objetivos del examen cubiertos por este tutorial
Objetivo del examen de LPIPonderación del objetivoResumen del objetivo
2.208.1
Implementación de un servidor Web
Ponderación 2Instale y configure un servidor Web. Este objetivo incluye el monitoreo de la carga y rendimiento del servidor, la restricción de acceso del usuario cliente, la configuración del soporte a los lenguajes de scripting como módulos y la configuración de la autenticación del usuario cliente. También incluye la capacidad para configurar opciones de servidor para restringir el uso de los recursos.
2.208.2
Mantenimiento de un servidor Web
Ponderación 2Configure un servidor Web para utilizar hosts virtuales, Secure Sockets Layer (SSL), y personalizar el acceso a los archivos.
2.208.3
Implementación de un servidor proxy
Ponderación 2Instale y configure un servidor proxy, incluyendo las políticas de acceso, la autenticación y el uso de recursos.

Requisitos previos

Para aprovechar al máximo este tutorial, ya debería tener un conocimiento básico de Linux y un sistema Linux en funcionamiento en el cual pueda practicar los comandos mencionados en este tutorial.


Acerca de Apache y Squid

Servidor Web Apache

Apache es el servidor Web dominante en Internet en su conjunto; su predominio es aún mayor entre los servidores Linux. Existen algunos otros servidores Web de propósitos especiales (algunos ofrecen un mejor rendimiento para tareas específicas), pero el servidor Apache es siempre la opción predeterminada.

Apache viene preinstalado en la mayoría de las distribuciones Linux y, a menudo, ya está funcionando después de ser lanzado durante la inicialización, aun cuando usted no haya configurado específicamente un servidor Web. Si Apache no está instalado, utilice el sistema de instalación normal de su distribución para instalarlo, o descargue el último servidor HTTP del Apache HTTP Server Project (Proyecto de Servidor HTTP Apache). Los módulos aportan muchas otras capacidades, muchas de las cuales se distribuyen con Apache en sí y otras pueden obtenerse de terceros.

Aunque el último Apache se encuentra en el nivel 2.x desde 2001, el Apache 1.3.x sigue siendo de uso generalizado y la serie 1.3.x sigue manteniéndose para la corrección de errores y las actualizaciones de seguridad. Existen algunas diferencias de configuración menores entre 1.3 y 2.x; hay algunos módulos disponibles para 1.3 que no están disponibles para 2.x. Las últimas versiones a la fecha de este tutorial son 1.3.34 (estable), 2.0.55 (estable) y 2.1.9 (beta).

Como norma, un nuevo servidor debería utilizar la última versión disponible de la serie 2.x. A menos que usted tenga una necesidad especifica para utilizar un módulo no habitual más antiguo, 2.x proporciona buena estabilidad, más capacidades y un mejor rendimiento general (para algunas tareas, como soporte PHP, el 1.3 sigue teniendo un mejor rendimiento). Con miras al futuro, las nuevas funcionalidades tendrán sin duda un mejor soporte en 2.x que en 1.3.x.

Servidor proxy Squid

Squid es un servidor proxy-caché para clientes Web que soporta los protocolos HTTP, FTP, TLS, SSL y HTTPS. Ejecutando un caché en una red local, o al menos más cerca de su red que los recursos consultados, se puede mejorar la velocidad y reducir el ancho de banda de la red. Cuando las máquinas atendidas por el mismo servidor Squid solicitan el mismo recurso varias veces, el recurso es prestado desde una copia local del servidor en lugar de que el pedido salga por múltiples routers de red que pueden potencialmente desacelerar o sobrecargar a los servidores de destino.

Usted puede configurar a Squid como proxy explícito que debe configurarse en cada cliente Web (navegador) o configurarlo para que intercepte todos los pedidos Web que salen de una LAN y almacenar en caché todo ese tráfico. Puede configurar a Squid con diversas opciones respecto de la duración y las condiciones en que habrán de mantenerse las páginas almacenadas en caché.

Otros recursos

Tal como ocurre con la mayoría de las herramientas Linux, siempre es útil examinar las páginas man para conocer las utilidades que se analizan. Las versiones y switches podrían cambiar entre las distintas versiones de utilidad o kernel o con diferentes distribuciones de Linux. Si desea información más detallada, el Proyecto de Documentación de Linux contiene una serie de documentos útiles, en especial los instructivos. Se han publicado una serie de libros sobre redes Linux; en mi opinión, TCP/IP Network Administration (Administración de redes TCP/IP) de O’Reilly,, escrito por Craig Hunt, es especialmente útil. (Vea Recursos más adelante en este tutorial si desea los vínculos.)

También se han escrito buenos libros sobre cómo trabajar con Apache. Algunos se refieren a la administración general mientras que otros cubren módulos determinados o configuraciones especiales de Apache. Consulte en la librería de su preferencia la gama de títulos disponibles.


Implementación de un servidor Web

Una multitud daemons

El inicio de Apache es similar al inicio de cualquier otro daemon. Por lo general, usted prefiere colocar su inicio en los scripts de inicialización del sistema pero, en principio, puede iniciar el Apache en cualquier momento. En la mayoría de los sistemas, al Apache se lo llama httpd, aunque también puede llamárselo apache2. Es probable que el servidor esté instalado en /usr/sbin/, pero otras ubicaciones son posibles dependiendo de la distribución y de cómo haya instalado usted el servidor.

En la mayoría de las ocasiones, usted iniciará el Apache sin opciones pero vale la pena tener en cuenta las opciones -d serverroot y -f config. La primera opción le permite especificar una ubicación en los discos locales desde la cual se brindará contenido; la segunda le permitirá especificar un archivo de configuración no predeterminado. Un archivo de configuración puede anular la opción -f utilizando la directiva ServerRoot (la mayoría lo hace). De forma predeterminada, los archivos de configuración son apache2.conf o httpd.conf, dependiendo de las opciones de compilación. Estos archivos podrían estar en /etc/apache2/, /etc/apache/, /etc/httpd/conf/, /etc/httpd/apache/conf, o en algunas otras ubicaciones dependiendo de la versión, la distribución de Linux y la forma en que usted instaló o compiló Apache. La verificación de man apache2 o man httpd debería darle detalles específicos del sistema.

El daemon de Apache es poco común si se lo compara con otros servidores en el sentido de que, por lo general, crea varias copias ejecutables de sí mismo. La copia principal sencillamente engendra las otras, mientras que estas copias secundarias atienden los pedidos entrantes reales. El objetivo de tener múltiples copias ejecutables es actuar como "pool" (grupo) para los pedidos que pueden llegar en paquetes; las copias adicionales del daemon se inician cuando resulta necesario, de acuerdo con varios parámetros de configuración. Por lo general, la copia principal se ejecuta como raíz pero las otras copias se ejecutan como usuario más restringido por razones de seguridad. Por ejemplo:

Listado 1. Las numerosas caras de copias ejecutables múltiples de Apache
# ps axu
| grep apache2 root 6620 Ss Nov12 0:00 /usr/sbin/apache2 -k start -DSSL www-data
6621 S Nov12 0:00 /usr/sbin/apache2 -k start -DSSL www-data 6622 Sl Nov12 0:00
/usr/sbin/apache2 -k start -DSSL www-data 6624 Sl Nov12 0:00 /usr/sbin/apache2
-k start -DSSL dqm 313 S+ 03:44 0:00 man apache2 root 637 S+ 03:59 0:00 grep
apache2

En muchos sistemas, el usuario restringido no será nadie. En el Listado 1, es www-data.

Inclusión de los archivos de configuración

Como se mencionó antes, la conducta de Apache se ve afectada por directivas de su archivo de configuración. Para los sistemas Apache2, es muy probable que el principal archivo de configuración resida en /etc/apache2/apache2.conf pero, a menudo, este archivo contiene múltiples instrucciones Include (incluir) para agregar información de configuración de otros archivos, posiblemente mediante patrones de comodines. En términos generales, es probable que una configuración de Apache contenga cientos de directivas y opciones (la mayoría de las cuales no se documentaron específicamente en este tutorial).

También es muy probable que se incluyan algunos archivos. Usted podría ver httpd.conf para las configuraciones del "usuario", para utilizar los archivos de configuración anteriores a Apache 1.3 que utilizan ese nombre. En general, los hosts virtuales se especifican en archivos de configuración independientes, compatibilizados en un comodín, como se muestra a continuación:

Listado 2. Especificación de hosts virtuales
# Include the virtual host
configurations (incluye las configuraciones de host virtuales): Incluye
/etc/apache2/sites-enabled/[^.#]*

Con Apache 2.x, los módulos también se especifican por lo general en archivos de configuración independientes (a menudo en el mismo archivo en 1.3.x). Por ejemplo, un sistema propio incluye:

Listado 3. Desde /etc/apache2/apache2.conf
# Include module configuration (incluye
la configuración del módulo): Incluye /etc/apache2/mods-enabled/*.load Incluye
/etc/apache2/mods-enabled/*.conf

En realidad, para utilizar un módulo en un servidor Apache ejecutable hacen falta dos pasos en el archivo de configuración, cargarlo y habilitarlo:

Listado 4. Carga de un módulo Apache opcional
# cat
/etc/apache2/mods-enabled/userdir.load LoadModule userdir_module
/usr/lib/apache2/modules/mod_userdir.so # cat
/etc/apache2/mods-enabled/userdir.conf <IfModule mod_userdir.c>
UserDir public_html UserDir disabled root <Directory
/home/*/public_html> AllowOverride FileInfo AuthConfig Limit Options
MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
</Directory> </IfModule>

Los comodines de las líneas Include (Incluir) insertarán todos los archivos .load y .conf en el directorio /etc/apache2/mods-enabled/.

Observe el patrón general: las directivas básicas son comandos de una línea con algunas opciones; las directivas más complejas anidan comandos que utilizan una etiqueta abrir/cerrar tipo XML. Para cada directiva, usted sólo deberá saber si es una línea o estilo abrir/cerrar – no puede elegir el estilo que desea a voluntad.

Archivos de registro

Una clase importante de directivas de configuración se refieren al registro de las operaciones de Apache. Usted podrá mantener diferentes tipos de información y niveles de detalle para las operaciones de Apache. Llevar un registro de errores siempre es una buena idea; podrá especificarlo con la siguiente directiva única:

Listado 5. Especificación de un registro de errores
# Global error log.
ErrorLog /var/log/apache2/error.log

Podrá personalizar otros registros de acceso al servidor, de referenciador y de cualquier otra información apropiada para su configuración individual. La operación de registro se configura con dos directivas. Primero, una directiva LogFormat utiliza un conjunto de variables especiales para especificar lo que va en el archivo de registro; segundo, una directiva CustomLog le dice a Apache que registre realmente los eventos en el formato especificado. Usted podrá especificar un número ilimitado de formatos independientemente de que se utilicen o no. Esto le permite activar y desactivar detalles del registro de acuerdo con las necesidades que pudieran surgir.

Las variables de un LogFormat son similares a las variables shell, pero con un % inicial. Algunas variables tienen letras únicas, mientas que otras tienen nombres largos rodeados de corchetes, tal como se muestra en el Listado 6.

Listado 6. Variables de LogFormat
LogFormat "%h %l %u %t \"%r\" %>s %b
\"%{Referer}i\" \"%{User-Agent}i\"" combined CustomLog
/var/log/apache2/referer_log combined

Consulte un libro o la documentación completa de Apache si desea una lista de todas las variables. Entre las más comunes se encuentran: %h para la dirección IP del cliente solicitante, %t para la fecha y hora del pedido, %>s para el código de estado de HTTP, y la variable mal escrita %{Referer} para el sitio referenciador que llegó a la página atendida .

El nombre utilizado en las directivas LogFormat y CustomLog es arbitrario. En el Listado 6, se utilizó el nombre combined pero también podría ser myfoobarlog. Sin embargo, hay algunos nombres que habitualmente se utilizan y que vienen con archivos de configuración de muestra, como combined, common, referer y agent. Por lo general, estos formatos específicos reciben el soporte directo de las herramientas analizadoras de registros.


Mantenimiento de un servidor Web

Hosts virtuales, multi-homing y opciones por directorio

Los directorios individuales servidos por un servidor Apache pueden tener sus propias opciones de configuración. Sin embargo, la configuración principal puede limitar las opciones que pueden configurarse localmente. Si desea una configuración por directorio, utilice la directiva AccessFileName y especifique el nombre de archivo de configuración local de .htaccess. Las limitaciones de configuración local se especifican dentro de una directiva <Directory>.Por ejemplo:

Listado 7. Ejemplo de directiva de directorio
#Let's have some Icons, shall we? Alias
/icons/ "/usr/share/apache2/icons/" <Directory
"/usr/share/apache2/icons"> Options Indexes MultiViews AllowOverride None
Order allow,deny Allow from all </Directory>

A menudo, trabajando en conjunto con las opciones por directorio, Apache puede atender a los hosts virtuales. Múltiples nombres de dominio pueden ser atendidos desde el mismo proceso Apache, cada uno de los cuales accede a un directorio apropiado. Usted puede definir los hosts virtuales con la directiva <VirtualHost>; coloque los archivos de configuración en un directorio incluido, como /etc/apache2/sites-enabled/ o en un archivo de configuración principal. Por ejemplo, usted podría especificar:

Listado 8. Configuración de hosts virtuales
<VirtualHost
"foo.example.com"> ServerAdmin webmaster@foo.example.com DocumentRoot
/var/www/foo ServerName foo.example.com <Directory /var/www/foo>
Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny
allow from all </Directory> ScriptAlias /cgi-bin/
/usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride
None Options ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow
from all </Directory> CustomLog /var/log/apache2/foo_access.log
combined </VirtualHost> <VirtualHost
"bar.example.org"> DocumentRoot /var/www/bar ServerName bar.example.org
</VirtualHost> <VirtualHost *> DocumentRoot /var/www
</VirtualHost>

La opción final * toma cualquier pedido HTTP que no esté dirigido a uno de los nombres especificados explícitamente (como los dirigidos por dirección IP o dirigidos como un dominio simbólico no especificado que también resuelve a la máquina servidor). Para que los dominios virtuales funcionen, DNS debe definir cada alias con un registro CNAME.

Los servidores multi-homed suenan de manera similar al hosting virtual pero el concepto es diferente. Utilizando multi-homing, usted podrá especificar las direcciones IP a las que está conectada una máquina para permitir los pedidos Web. Por ejemplo, usted podría brindar acceso HTTP sólo a la LAN local y no al mundo exterior. Si usted especifica una dirección para escuchar, también puede indicar un puerto no predeterminado. El valor predeterminado para BindAddress es *, que significa aceptar los pedidos de cada dirección IP bajo la cual se puede acceder al servidor. El siguiente podría ser un ejemplo mixto:

Listado 9. Configuración de multi-homing
BindAddress 192.168.2.2 Listen
192.168.2.2:8000 Listen 64.41.64.172:8080

En este caso, aceptaremos todos los pedidos del cliente provenientes de la LAN local (que utilizan la dirección 192.168.2.2) en el puerto predeterminado 80 y en el puerto especial 8000. Esta instalación de Apache también monitoreará los pedidos HTTP del cliente que provienen de la dirección WAN, pero sólo en el puerto 8080.

Limitación del acceso Web

Usted puede habilitar el acceso al servidor por directorio con los comandos Order, Allowfrom, y Deny from que están dentro de una directiva <Directory>. Es posible especificar las direcciones denegadas o permitidas mediante nombres de host parciales o direcciones IP. Order le permite establecer una prioridad entre la lista de aceptación y la lista de denegación.

En muchos casos, usted necesitará un control más ajustado que el que puede obtener con el simple hecho de permitir que determinados hosts accedan a su servidor Web. Para habilitar los requisitos de inicio de sesión del usuario, utilice la familia de comandos Auth*, que se encuentra también dentro de la directiva <Directory>. Por ejemplo, para configurar la Autenticación Básica, usted podría utilizar una directiva como la que aparece en el Listado 10.

Listado 10. Configuración de la Autenticación Básica
<Directory
"/var/www/baz"> AuthName "Baz" AuthType Basic AuthUserFile
/etc/apache2/http.passwords AuthGroupFile /etc/apache2/http.groups Require john
jill sally bob </Directory>

También puede especificar la Autenticación Básica dentro de un archivo .htaccess por directorio. La Autenticación “Digest” es más segura que la Básica, pero se encuentra mucho menos implementada en los servidores. Sin embargo, la debilidad de la Autenticación Básica (que transmite contraseñas en texto claro) de todos modos se resuelve mejor con una capa SSL.

El soporte al cifrado SSL del tráfico Web es suministrado por el módulo mod_ssl. Cuando se utiliza SSL, los datos transmitidos entre el servidor y el cliente se cifran con una contraseña que se negocia de forma dinámica y que es resistente a la interceptación. Todos los navegadores importantes soportan SSL. Si desea más información sobre cómo configurar Apache 2.x con mod_ssl, vea la descripción en el sitio Web de Apache (diríjase a Recursos para ver el vínculo).


Implementación de un servidor proxy

Instalación y ejecución de Squid

En la mayoría de las distribuciones, usted puede instalar Squid utilizando los procedimientos de instalación normal. Obtenga la versión fuente de Squid en el sitio Web de Squid Web Proxy Cache (diríjase a Recursos para ver el vínculo). Construyendo a partir de la fuente, utilice la secuencia básica ./configure; make; make install.

Una vez instalado, podrá ejecutarlo de manera sencilla como raíz, /usr/sbin/squid (o desde la ubicación que utilice su distribución, quizá /usr/local/sbin/). Por supuesto que para que resulte mucho más útil, usted probablemente querrá configurar el archivo de configuración de Squid en /etc/squid/squid.conf, /usr/local/squid/etc/squid.conf, o en el lugar en el que su sistema ubique con precisión a squid.conf. Tal como ocurre con casi todos los daemons, podrá utilizar un archivo de configuración diferente, en este caso con la opción -f.

Puertos, direcciones IP, http_access y ACL (Listas de control de acceso)

Las opciones de configuración más importantes para Squid son las opciones http_port que usted elige. Usted puede monitorear todos los puertos que desee, adjuntando opcionalmente cada uno a una dirección de IP o nombre de host determinados. El puerto predeterminado para Squid es 3128, que permite que cualquier dirección de IP se conecte al servidor Squid. Para almacenar en caché sólo para una LAN, especifique la dirección de IP local, de la siguiente manera:

Listado 11. Almacenamiento en caché de Squid sólo para una LAN
# default
(disabled) # http_port 3128 # LAN only http_port 192.168.2.2:3128

Usted también puede habilitar el almacenamiento en caché a través de otros servidores Squid utilizando icp_port y htcp_port. Los protocolos IPC y HTCP se utilizan para que los caché se comuniquen entre sí en lugar de hacerlo mediante los servidores y clientes Web. Para almacenar en caché los multicasts, utilice mcast_groups.

Para permitir que los clientes se conecten a su servidor Squid, tendrá que darles permiso para poder hacerlo. A diferencia de un servidor Web, el servidor Squid no es absolutamente generoso con sus recursos. En el caso simple, sólo podemos utilizar un par de patrones de subred/máscara de red o CIDR (Classless Internet Domain Routing) para controlar los permisos:

Listado 12. Permisos de acceso simples de Squid
http_access deny
10.0.1.0/255.255.255.0 http_access allow 10.0.0.0/8 icp_access allow
10.0.0.0/8

Usted puede utilizar la directiva acl para nombrar la listas de control de acceso (ACL). Puede nombrar las ACL tipo src que sencillamente especifican rangos de dirección como se ve en el Listado 12, pero también puede crear otros tipos de ACL. Por ejemplo:

Listado 13. Permisos de acceso ajustados
acl mynetwork src 192.168/16 acl asp
urlpath_regex \.asp$ acl bad_ports port 70 873 acl javascript rep_mime_type -i
^application/x-javascript$ # what HTTP access to allow classes http_access deny
asp # don't cache active server pages http_access deny bad_ports # don't cache
gopher or rsync http_access deny javascript # don't cache javascript content
http_access allow mynetwork # allow LAN everything not denied

El Listado 13 muestra sólo un pequeño subconjunto de los tipos de ACL disponibles. Vea una muestra de squid.conf si desea ejemplos de muchos otros. O consulte la documentación sobre control de acceso (Capítulo 6) de la Guía del Usuario de Squid (diríjase a Recursos para ver el vínculo).

En el Listado 13, decidimos no no almacenar en caché las direcciones URL que terminan en .asp (el contenido es probablemente dinámico), no almacenar en caché los puertos 70 y 873 y no almacenar en caché los objetos JavaScript devueltos. Fuera de lo que se deniega, las máquinas de la LAN (el rango /16 dado) tendrán todos sus pedidos almacenados en caché. Observe que cada ACL definida tiene un nombre único pero arbitrario (utilice nombres que tengan sentido; Squid no reserva los nombres).

Modalidades de almacenamiento en caché

La manera más simple de ejecutar Squid es en el modo proxy. Si sigue este procedimiento, los clientes deberán configurarse explícitamente para utilizar el caché. Los clientes del navegador Web tienen pantallas de configuración que les permiten especificar un puerto y dirección proxy en lugar de una conexión http directa. Este sistema simplifica al máximo la configuración de Squid pero obliga a los clientes a realizar algún trabajo de configuración si desean beneficiarse con el caché de Squid.

También podrá configurar a Squid para que sea ejecutado como un caché transparente. Para ello, deberá configurar el ruteo basado en políticas (fuera de Squid en sí, utilizando ipchains o ipfilter) o usar su servidor Squid como una puerta de enlace. Suponiendo que usted está en condiciones de dirigir los pedidos externos a través del servidor Squid, el servidor deberá configurarse de la siguiente manera. Es probable que necesite recompilar Squid con la opción --enable-ipf-transparent; sin embargo, en la mayoría de las instalaciones Linux, no debería ser necesario. Para configurar el servidor para el almacenamiento en caché transparente (una vez que tiene los paquetes redireccionados), agregue algo similar al Listado 14 a su squid.conf:

Listado 14. Configuración de Squid para el almacenamiento en caché transparente
httpd_accel_host virtual httpd_accel_port 80
httpd_accel_with_proxy on httpd_accel_uses_host_header on

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux
ArticleID=502378
ArticleTitle=Preparación para el examen de LPI: servicios web
publish-date=07292011