Nginx: alternativa a Apache

nginx.pngNginx (engine x) es un servidor HTTP, reverse proxy y servidor proxy IMAP/POP3. Desarollado para una de las web más visitadas de rusia, lleva en producción sobre dos años y medio.
Desarrollado bajo licencia BSD, aún está en beta, pero tiene buena fama de estabilidad, un buen conjunto de características, configuración sencilla y poco consumo de recursos.
Entre las características HTTP nos encontramos: manejo de ficheros estáticos, índices y autoíndices, reverse proxying acelerado sin caché y con balanceo de carga y tolerancia a fallos, FastCGI, arquitectura modular y soporte SSL.
En Apache-ES han medido el rendimiento y en el caso que se trataba, servicio de imágenes y contenido estático, gana Nginx debido a unas modificaciones que trae de base.
Nginx
Vía / Apache-ES

| |

Laboratorio: área clientes mediante Apache y PHP

Viendo diferentes empresas con página corporativa, he visto que suele ser común el área para los clientes. En este mundo es normal que el tema de los pagos suela dar complicaciones, por eso yo creo que es preferible subir lo que se va desarrollando para el cliente en un servidor propio que en el servidor del cliente, ya que hasta que no pague en su totalidad, no dispone de ello.

Si te encuentras en esta situación, quizás te sea útil este truco para habilitar una área privada protegida para los clientes, la cual redireccionará al contenido del cliente, ya sea el propio trabajo en sí o una aplicación en particular.

Para el caso del ejemplo, yo lo he hecho para unas páginas web estáticas, y luego que cada cual, si le interesa, que lo adapte a su gusto.

El funcionamiento es el siguiente: el usuario accede a una ruta con acceso restringido a usuarios válidos mediante Apache. También mediante Apache se le redirigirá a una página propia, en este caso las páginas HTML que están guardadas en un directorio específico para clientes (fuera del webroot) y en un directorio específico para ese cliente en concreto.

Supongamos que tenemos el directorio webroot siguiente home/www y el área web de clientes está en el directorio home/www/clientes y el espacio físico específico de clientes está en home/www/_clientes. Lo primero que debemos hacer es añadir el siguiente .htaccess en el directorio clientes.

AuthType Basic
AuthName "Acceso a clientes"
AuthUserFile [path]\passwords.conf
Require valid-user
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/clientes(.*)$
RewriteRule ^(.*)$ /_clientes/index.php?url=$1  [L,QSA]

Lo que hace esta configuración es añadir autenticación al directorio clientes y redireccionar al script index.php del directorio _clientes, pasándole como parámetro la url a la que se accede.

El script index.php para este ejemplo, lo que he hecho ha sido incrustar el fichero que se quiere directamente, teniendo en cuenta el Content-Type y que si no se añade ninguna url después de clientes se tome por defecto el fichero index.html.

<?php
// Devuelve el content-type
function content_type($url) {
$ext = substr($url, strrpos($url, '.')+1);
if ($ext == 'swf') {
header("Content-type: application/octet-stream");
} else if ($ext == 'png') {
header("Content-type: image/png");
} else if ($ext == 'jpg') {
header("Content-type: image/jpeg");
} else if ($ext == 'gif') {
header("Content-type: image/gif");
} else if ($ext == 'js') {
header("Content-type: text/javascript");
} else if ($ext == 'css') {
header("Content-type: text/css");
} else if ($ext == 'html') {
header("Content-type: text/html");
} else {
header("Content-type: text/plain");
}
}
// Obtengo el usuario y la ruta a la que quiere acceder
$user = $_SERVER['REMOTE_USER'];
$url = substr($_SERVER['REQUEST_URI'], strlen("/clientes"));
$url = $url == '/'? '/index.html' : $url;
// Añado el content-type
content_type($url);
// Inserto el fichero
if (file_exists('./'.$user.$url)) {
include './'.$user.$url;
}
?>

Por supuesto a este truco le faltan cosas, como seguridad en el directorio _clientes, a parte de que hay que tener cuidado con los paths relativos o absolutos, y alguna cosilla más, pero creo que como idea desde la que partir no está mal.

Trabajar con variables de entorno en Apache

Aunque se llamen variables de entorno, realmente son variables tratadas por Apache, y no las mismas que trata el S.O. Mediante estas variables se puede enviar información a las CGIs u otros programas externos, así esta información podrá ser utilizada en operaciones de acceso a la aplicación.
En el artículo que os presentamos explican detalladamente una introducción a la manipulación de estas variables de entorno, ya sea modificándolas o enviándolas.
Por ejemplo, podemos ver cómo modificar las variables para situaciones específicas: usar la versión antigua de HTTP/1.0 para todas las peticiones o tratar con cuidado las redirecciones cuando sabemos que el cliente no las sabe tratar del todo bien.
Apache Variable Fun in htaccess

Reescribe condiciones de Apache dependientes de la hora

Cuando queremos redirigir mediante Apache se puede realizar teniendo en cuenta la hora y los minutos actuales. Tieniendo en cuenta que las horas son en formato 24 y que empieza por 01 para la 1 am y 24 para las 12 pm, podemos redirigir nuestra página según sea la hora y el minuto.

RewriteCond %{TIME_HOUR} ^(.*)
RewriteCond %{TIME_MIN} ^(.*)
RewriteRule (.*) http://${HTTP_HOST}%{REQUEST_URI}?H=%1&M=%2 [R,L]

Si se da el caso de que el servidor está ciertas horas de retraso respecto a tí, por ejemplo 3, se podría hacer de la siguiente manera:

Options +FollowSymLinks
RewriteEngine On
RewriteBase /demo/apache/
# 5am > < 8am
RewriteCond %{TIME_HOUR} >02
RewriteCond %{TIME_HOUR} <05
RewriteRule ^index.html$ /demo/apache/manyana/index.html
# 8am > < 4pm
RewriteCond %{TIME_HOUR} >05
RewriteCond %{TIME_HOUR} <13
RewriteRule ^index.html$ /demo/apache/mediodia/index.html
# 4pm > < 10pm
RewriteCond %{TIME_HOUR} >13
RewriteCond %{TIME_HOUR} <19
RewriteRule ^index.html$ /demo/apache/tarde/index.html
# 10pm > < 5am
RewriteCond %{TIME_HOUR} >19
RewriteCond %{TIME_HOUR} <02
RewriteRule ^index.html$ /demo/apache/noche/index.html

Using TIME_HOUR and TIME_MIN RewriteCond in htaccess

| | | |

Cómo decir a Google que vuelva por nuestra página más tarde

Cuando tenemos nuestra página en mantenimiento y el motor de Google (Googlebot) u otro motor de búsqueda, se pasa por nuestra página para indexarla, no es correcto que obtenga una página no encontrada (404) o un error del servidor (500).
Según dicen en Google Webmaster Central lo correcto es mandar un código de red no disponible (503), pero el autor de este post recomienda también enviar un Retry-After para que vuelva a pasarse más tarde. También recomienda que a los motores de búsqueda se les envie a una página 503 y a los visitantes (menos a él) a una página 404 (página no encontrada).
Instruct Search Engines to come back to site after you finish working on it

Configuración de un subdominio

Un buen artículo que explica cómo configurar un subdominio. Empieza indicando cómo se redirige a un subdominio: las configuración de un subdominio está ligada a la del dominio, la petición llega primero al subdominio y luego esta redirigirá al servidor web correspondiente del subdominio.

La primera opción es cuando el subdominio apunta al mismo servidor web, para ello es necesario configurar el servidor DNS, indicando el alias mediante los CNAMES. Si se encuentra en distinta IP que el dominio es necesario indicarlo mediante A. Y si deseamos gestionar el correo por otro servidor de correo deberemos indicarlo mediante MX. [Gracias Sergio por la corrección]

www IN CNAME dominio.com.
subdominio1 IN CNAME dominio.com.
subdominio2 IN CNAME dominio.com.
subdominio1 IN A 123.45.67.89.
subdominio2 IN A 123.45.67.90.
subdominio1 IN MX 10 subdominio1.dominio.com.
subdominio2 IN MX 10 subdominio2.dominio.com.

Y ya por último la configuración de Apache:

Listen 80
NameVirtualHost *
<VirtualHost *>
ServerName www.dominio.com
DocumentRoot /home/httpd/htdocs/
</VirtualHost>
<VirtualHost *>
ServerName subdominio.dominio.com
DocumentRoot /home/httpd/htdocs/subdominio/
</VirtualHost>

Subdomain Configuration

| | |

Versión 1.7.0 de WAMP5

wamp.pngHa sido lanzada la versión 1.7.0 de la aplicación WAMP (Windows Apache MySQL PHP), que añade además phpmyadmin.

Las novedades que nos ofrece son las siguientes:

  • Módulo de idiomas para el administrador de WAMP5
  • Compatibilidad con Windows Vista
  • Añadidos inicialmente 14 idiomas y adaptación de las funcionalidades y add-ons por el módulo de lenguaje
  • Apache 2.2.4
  • PHP 5.2.1
  • PHP 4.4.5 (addon PHP4)
  • phpmyadmin 2.9.2

WAMP5

Ejemplos de htaccess para Apache

Impresionante lista de trucos y ejemplos de código para incluir en nuestro .htaccess o httpd.conf, que nos puede a llegar a ser muy útil.

Ultimate htaccess Article

Cómo instalar Apache en Windows Vista

Aunque no soy usuario de Vista, si que he visto que algunas personas se quejan de tener problemas para instalar Apache en Windows Vista.

Vamos a decir cómo se haría paso a paso (aunque algunos pasos sean demasiado obvios):

  • Ir a Start
  • All Programs
  • Accessories, después hacer click con el botón derecho en Command Prompt y selecciona Run as administrator. Esto abrirá una ventana de comandos con derechos de administrador.
  • Dirígete al directorio donde tengas guardado el archivo de instalación apache*.msi y ejecuta “msiexec /i apache*.msi”, donde apache*.msi es el nombre del archivo completo.
  • Pulsa enter y el resto irá a la perfección.

Installing Apache on Vista

Vía / Planet PHP

Mod_security: ‘enjaula’ tu Apache

Algo que nos debería preocupar bastante es la seguridad de nuestro servidor web. “Enjaular” se refiere a meter a Apache en un entorno propio para que cuando suframos un ataque solo a ese entorno y no a nuestro sistema entero.
Para ello, se puede hacer mediante mod_security y la gente de Apache-ES nos explica muy bien cómo instalarlo para Linux y cómo hacerlo para que funcione bajo Windows ya que en Windows mod_security no funciona correctamente.
Apache mod-security (PDF)
Vía / Apache-ES