From cc40af334e619bb549038238507407866f774f8f Mon Sep 17 00:00:00 2001 From: hongbotian Date: Mon, 30 Nov 2015 01:35:09 -0500 Subject: upload apache JIRA: BOTTLENECK-10 Change-Id: I67eae31de6dc824097dfa56ab454ba36fdd23a2c Signed-off-by: hongbotian --- rubbos/app/apache2/manual/sections.html.es | 492 +++++++++++++++++++++++++++++ 1 file changed, 492 insertions(+) create mode 100644 rubbos/app/apache2/manual/sections.html.es (limited to 'rubbos/app/apache2/manual/sections.html.es') diff --git a/rubbos/app/apache2/manual/sections.html.es b/rubbos/app/apache2/manual/sections.html.es new file mode 100644 index 00000000..0b7fecb6 --- /dev/null +++ b/rubbos/app/apache2/manual/sections.html.es @@ -0,0 +1,492 @@ + + + +Secciones de configuración - Servidor HTTP Apache + + + + + +
<-
+

Secciones de configuración

+
+

Idiomas disponibles:  en  | + es  | + ja  | + ko  | + tr 

+
+

Las directivas presentes en los ficheros de configuración pueden ser +de aplicación para todo el servidor, o puede que su +aplicación se limite solamente a determinados directorios, +ficheros, hosts, o URLs. Este documento explica cómo usar las +secciones de configuración y los ficheros .htaccess +para modificar el ámbito de aplicación de las directivas de +configuración.

+ +
top
+
+

Tipos de secciones de +configuración

+ + + +

Exiten dos tipos básicos de secciones de +configuración. Por un lado, la mayoría de las secciones de +configuración se evalúan para cada petición que se +recibe y se aplican las directivas que se incluyen en las distintas +secciones solamente a las peticiones que se adecúan a +determinadas características. Por otro lado, las secciones de tipo +<IfDefine> e +<IfModule>, se +evalúan solamente al inicio o reinicio del servidor. Si al +iniciar el servidor las condiciones son las adecuadas, las directivas +que incluyen estas secciones se aplicarán a todas las peticiones +que se reciban. Es caso contrario, esas directivas que incluyen se +ignoran completamente.

+ +

Las secciones <IfDefine> incluyen directivas que se +aplicarán solamente si se pasa un determinado parámetro por +línea de comandos al ejecutar httpd. Por +ejemplo, con la siguiente configuración, todas las peticiones +serán redireccionadas a otro sitio web solamente si el servidor +se inició usando httpd -DClosedForNow:

+ +

+<IfDefine ClosedForNow>
+Redirect / http://otherserver.example.com/
+</IfDefine> +

+ +

La sección <IfModule> es muy parecida. La diferencia +respecto a <IfDefine> está en que incluye directivas +que se aplicarán solamente si un determinado módulo en +particular está disponible en el servidor. El módulo debe +estar compilado estáticamente en el servidor, o si está +compilado de forma dinámica ha de ponerse antes una línea +LoadModule en el fichero de +configuración. Esta directiva debe usarla solamente si necesita +que su fichero de configuración funcione estén o no +instalados determinados módulos. No debe usarla para incluir +directivas que quiera que se apliquen siempre, porque puede suprimir +mensajes de error que pueden ser de mucha utilidad para detectar la +falta de algún módulo.

+ +

En el siguiente ejemplo, la directiva MimeMagicFiles se aplicará +solamente si el módulo mod_mime_magic está +disponible.

+ +

+<IfModule mod_mime_magic.c>
+MimeMagicFile conf/magic
+</IfModule> +

+ +

Tanto <IfDefine> +como <IfModule> +pueder usarse con condiones negativas anteponiendo al test el +carácter "!". Estas secciones también pueden anidarse para +establecer restricciones más complejas.

+ +
top
+
+

Sistemas de ficheros y espacio +web

+ +

Las secciones de configuración usadas con más frecuencia +son las que cambian la configuración de áreas del sistema de +ficheros o del espacio web. En primer lugar, es importante comprender +la diferencia que existe entre estos dos conceptos. El sistema de +ficheros es la visión de sus discos desde el punto de vista del +sistema operativo. Por ejemplo, en una instalación estándar, +Apache estará en /usr/local/apache2 en un sistema +Unix o en "c:/Program Files/Apache Group/Apache2" en un +sistema Windows. (Tenga en cuenta que con Apache debe usar siempre +barras /, incluso en Windows.) Por el contrario, el espacio web lo +que presenta el servidor web y que visualiza el cliente. De manera que +la ruta /dir/ en el espacio web se corresponde con la +ruta /usr/local/apache2/htdocs/dir/ en el sistema de +ficheros de una instalación estándar en Unix. El espacio +web no tiene que tener correspondencia directa con el sistema de +ficheros, porque las páginas web pueden generarse de forma +dinámica a partir de bases de datos o partiendo de otras +ubicaciones.

+ +

Secciones relacionadas con el sistema +de ficheros

+ +

Las secciones <Directory> y <Files>, junto con sus contrapartes que usan +expresiones regulares, aplican sus directivas a áreas del sistema de +ficheros. Las directivas incluidas en una sección <Directory> se aplican al +directorio del sistema de ficheros especificado y a sus +subdirectorios. El mismo resultado puede obtenerse usando ficheros .htaccess. Por ejemplo, en la +siguiente configuración, se activarán los índices de +directorio para el directorio /var/web/dir1 y sus +subdirectorios.

+ +

+<Directory /var/web/dir1>
+Options +Indexes
+</Directory> +

+ +

Las directivas incluidas en una sección <Files> se aplicarán a +cualquier fichero cuyo nombre se especifique, sin tener en cuenta en +que directorio se encuentra. Por ejemplo, las siguientes directivas de +configuración, cuando se colocan en la sección principal del +fichero de configuración, deniegan el acceso a cualquier fichero +llamado private.html sin tener en cuenta de donde se +encuentre.

+ +

+<Files private.html>
+Order allow,deny
+Deny from all
+</Files> +

+ +

Para referirse a archivos que se encuentren en un determinado lugar +del sistema de ficheros, se pueden combinar las secciones <Files> y <Directory>. Por ejemplo, la +siguiente configuración denegará el acceso a +/var/web/dir1/private.html, +/var/web/dir1/subdir2/private.html, +/var/web/dir1/subdir3/private.html, y cualquier otra +aparición de private.html que se encuentre en +/var/web/dir1/ o cualquiera de sus subdirectorios.

+ +

+<Directory /var/web/dir1>
+<Files private.html>
+Order allow,deny
+Deny from all
+</Files>
+</Directory> +

+ + +

Secciones relacionadas con el espacio +web

+ +

La sección <Location> y su contraparte que usa + expresiones regulares, cambian + la configuración para el contenido del espacio web. Por ejemplo, + la siguiente configuración evita que se acceda a cualquier URL + que empiece por /private. En concreto, se aplicará a + peticiones que vayan dirigidas a + http://yoursite.example.com/private, + http://yoursite.example.com/private123, y a + http://yoursite.example.com/private/dir/file.html + así como + también a cualquier otra petición que comience por + /private.

+ +

+<Location /private>
+Order Allow,Deny
+Deny from all
+</Location> +

+ +

La sección <Location> puede no tener nada que ver con el +sistema de ficheros. Por ejemplo, el siguiente ejemplo muestra como +asociar una determinada URL a un handler interno de Apache del +módulo mod_status. No tiene por qué +existir ningún fichero server-status en el sistema +de ficheros.

+ +

+<Location /server-status>
+SetHandler server-status
+</Location> +

+ + +

Caracteres comodín y expresiones +regulares

+ +

Las secciones <Directory>, <Files>, y <Location> pueden usar caracteres comodín +del tipo fnmatch de la librería estándar de C. +El carácter "*" equivale a cualquier secuencia de caracteres, "?" +equivale a cualquier carácter individual, y "[seq]" +equivale a cualquier carácter en seq. Ningún +carácter comodín equivale a"/", que debe siempre +especificarse explícitamente.

+ +

Si necesita un sistema de equivalencias más flexible, cada +sección tiene una contraparte que acepta expresiones regulares compatibles con +Perl: <DirectoryMatch>, <FilesMatch>, y <LocationMatch>. Consulte la sección +sobre la fusión de secciones de configuración para ver la +forma en que las secciones expresiones regulares cambian el modo en +que se aplican las directivas.

+ +

Abajo se muestra un ejemplo en el que una sección de +configuración que usa caracteres comodín en lugar de una +expresión regular modifica la configuración de todos los +directorios de usuario:

+ +

+<Directory /home/*/public_html>
+Options Indexes
+</Directory> +

+ +

Usando expresiones regulares, podemos denegar el acceso a muchos +tipos ficheros de imágenes de una sola vez:

+ +

+<FilesMatch \.(?i:gif|jpe?g|png)$>
+Order allow,deny
+Deny from all
+</FilesMatch> +

+ + + +

Qué usar en cada momento

+ +

Decidir cuando hay que usar secciones que se apliquen sobre el +sistema de ficheros y cuando usar secciones que se apliquen sobre el +espacio web es bastante fácil. Cuando se trata de directivas que +se aplican a objetos que residen en el sistema de ficheros, siempre se +deben usar <Directory> o <Files>. Cuando se trata de directivas que se +aplican a objetos que no residen en el sistema de ficheros (por +ejemplo una página web generada a partir de una base de datos), +se usa <Location>.

+ +

Es importante no usar nunca <Location> cuando se trata de restringir el +acceso a objetos en el sistema de ficheros. Esto se debe a que varias +URLs diferentes pueden corresponderse con una misma ubicación en +el sistema de ficheros, haciendo que la restricción pueda ser +evitada. Por ejemplo, considere la siguiente configuración:

+ +

+<Location /dir/>
+Order allow,deny
+Deny from all
+</Location> +

+ +

La restricción funciona si se produce una petición a +http://yoursite.example.com/dir/. Pero, ¿qué +ocurriría si se trata de un sistema de ficheros que no distingue +mayúsculas de minúsculas? Entonces, la restricción que +ha establecido podría evitarse fácilmente haciendo una +peticion a http://yoursite.example.com/DIR/. Una +sección <Directory> por el contrario, se aplicará +a cualquier contenido servido desde esa ubicación, +independientemente de cómo se llame. (Una excepción son los +enlaces del sistema de ficheros. El mismo directorio puede ser +colocado en más de una ubicación del sistema de ficheros +usando enlaces simbólicos. La sección <Directory> seguirá los +enlaces simbólicos sin resetear la ruta de fichero (resetting the +pathname). Por tanto, para conseguir el mayor nivel de seguridad, los +enlaces simbólicos deben desactivarse con la directiva Options correspondiente.)

+ +

En el caso de que piense que nada de esto le afecta porque usa un +sistema de ficheros que distingue mayúsculas de minúsculas, +recuerde que hay muchas otras maneras de hacer corresponder +múltiples direcciones del espacio web con una misma +ubicación del sistema de ficheros. Por tanto, use las secciones +de configuración que se aplican al sistema de ficheros siempre +que sea posible. Hay, sin embargo, una excepción a esta +regla. Poner restricciones de configuración en una sección +<Location /> es completamente seguro porque estas +secciones se aplicarán a todas las peticiones independientemente +de la URL específica que se solicite.

+ +
top
+
+

Hosts virtuales

+ +

El contenedor <VirtualHost> agrupa directivas que se +aplicarán a hosts específicos. Esto es útil cuando se +sirven varios hosts con una misma máquina y con una +configuración diferente cada uno. Para más información, +consulte la documentación sobre hosts +virtuales.

top
+
+

Proxy

+ +

Las secciones <Proxy> y <ProxyMatch> aplican las directivas de +configuración que engloban solo a los sitios accedidos a +través del servidor proxy del módulo +mod_proxy que tengan equivalencia con la URL +especificada. Por ejemplo, la siguiente configuración +evitará que se use el servidor proxy para acceder al sitio web +cnn.com.

+ +

+<Proxy http://cnn.com/*>
+Order allow,deny
+Deny from all
+</Proxy> +

+
top
+
+

¿Qué directivas se pueden +usar?

+ +

Para ver que directivas son las que se pueden usar en cada +sección de configuración, consulte el Context de la directiva. +Todas las directivas que está permitido usar en las secciones +<Directory> se +pueden usar también en las secciones <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, <LocationMatch>, <Proxy>, y <ProxyMatch>. Sin embargo, hay algunas +excepciones:

+ + +
top
+
+

¿Cómo se fusionan las distintas +secciones?

+ +

Las secciones de configuración se aplican en un determinado +orden. Como este orden puede tener efectos significativos en como se +interpretan las directivas de configuración, es importante +entender cómo funciona este proceso.

+ +

El orden de fusión es el siguiente:

+ +
    +
  1. <Directory> (excepto expresiones + regulares) y .htaccess simultáneamente (si el + uso de .htaccess está permitido, prevaleciendo + sobre <Directory>)
  2. + +
  3. <DirectoryMatch> + (y <Directory ~>)
  4. + +
  5. <Files> y + <FilesMatch> + simultáneamente
  6. + +
  7. <Location> + y <LocationMatch> + simultáneamente
  8. +
+ +

Aparte de <Directory>, cada grupo se procesa en el + orden en que aparezca en los ficheros de configuración. + <Directory> + (grupo 1 arriba) se procesa empezando por los componentes de la + ruta al directorio más cortos. Por ejemplo, + <Directory + /var/web/dir> se procesará antes de + <Directory /var/web/dir/subdir>. Si hay que + aplicar varias secciones <Directory> a un mismo directorio, se + aplican en el orden en que aparezcan en el fichero de + configuración. Las configuraciones incluidas mediante la + directiva Include se + tratarán como si estuvieran dentro del fichero de + configuración principal en lugar de la sección + Include.

+ +

Las secciones incluidas dentro de secciones <VirtualHost> se aplican + después de las correspondientes secciones fuera + de la definición del host virtual. Esto permite que la + configuración especificada para los hosts virtuales pueda + prevalecer sobre la configuración del servidor principal.

+ +

Las secciones que aparecen después prevalecen sobre las + que aparecen antes.

+ +

Nota técnica.

Previamente a la fase de + traducción de nombres (en la que se analizan los + Aliases y DocumentRoots para calcular + las correspondencias entre URLs y nombres de ficheros) se + ejecuta una secuencia + <Location>/<LocationMatch>. Los + resultados de esta secuencia se desechan después de + ejecutar la traducción.
+ +

Algunos ejemplos

+ +

Abajo se muestra un ejemplo para que se vea claramente cuál es +el orden de fusión. Asumiendo que todas las secciones se aplican +a la petición, las de este ejemplo se aplicarían en el orden +A > B > C > D > E.

+ +

+<Location />
+E
+</Location>
+
+<Files f.html>
+D
+</Files>
+
+<VirtualHost *>
+<Directory /a/b>
+B
+</Directory>
+</VirtualHost>
+
+<DirectoryMatch "^.*b$">
+C
+</DirectoryMatch>
+
+<Directory /a/b>
+A
+</Directory>
+
+

+ +

A continuación se muestra un ejemplo más concreto. +Independientemente de las restricciones de acceso que se hayan +establecido en las secciones <Directory>, la sección <Location> será evaluada +al final y se permitirá acceso sin restricciones al servidor. En +otras palabras, el orden de fusión es importante, de modo que +ponga atención.

+ +

+<Location />
Order deny,allow
Allow from all
+</Location>

+# Esta sección <Directory> no tendrá efecto
+<Directory />
+Order allow,deny
+Allow from all
+Deny from badguy.example.com
+</Directory> +

+ + + +
+
+

Idiomas disponibles:  en  | + es  | + ja  | + ko  | + tr 

+
+ \ No newline at end of file -- cgit 1.2.3-korg