NetLoony: GUI para Apache

NetLoony es una GUI para Apache open source que nos facilitará la administración de nuestro servidor web.
netloony.png
Inicialmente era un producto de pago, pero ahora es open source, lo cual es un importante paso. Desarrollado en Java nos permite entre otras cosas disponer de un monitor de rendimiento, control remoto, soporte para SSL, buscador de ficheros htaccess, editor de texto, scaner de puertos, backup y muchas cosas más.
NetLoony
Vía / Apache-es

| |

Server2Go: servidor WAMP portable

server2go.pngServer2Go es un servidor web completo y portable, el cual podremos tener instalado en CDROMs o unidades USB.

Dentro de las características que ofrece nos encontramos con:

  • Gratuito
  • Servidor WAMPP (Windows, Apache, MySQL, PHP y Perl)
  • No necesita instalación
  • PHP 5 con muchas extensiones instaladas.
  • SQLite
  • MySQL 5
  • Perl 5.8

La licencia es donationware, lo que quiere decir que si se dona una cantidad de dinero (10€) se podrá acceder a características ampliadas.

Server2Go

Vía / OpenSourceCommunity.org

| | |

MAMP: Apache, MySQL y PHP para Mac

mamp.pngMAMP es un instalador de Apache, MySQL y PHP para Mac OS X sencillo y que con unos pocos clicks ya tenemos instaladas las aplicaciones más habituales para desarrollo web.
mamp.jpg
La versión está realizado bajo licencia GNU General Public License, aunque existe una versión PRO, con licencia, que dispone de funcionalidades extra.
MAMP

Fichero htaccess imprescindible de ejemplo

Los ficheros htaccess son imprescindibles a la hora de crear una aplicación web en condiciones. Con ellos podemos realizar muchas acciones que mejoran la funcionalidad y nos ahorrar tiempo de programación.

Para aquellos que no estamos muy acostumbrados al fichero htaccess, nos viene bien una chuleta que nos muestre las acciones más usuales que se pueden realizar en Apache.

Por ello, la gente de AskApache se han creado un fichero de ejemplo con casi todas las cosas que se pueden realizar en un htaccess, prometiendo futuras ampliaciones. Entre las funcionalidades que encontramos está:

  • Opciones genéricas
  • Variables de entorno
  • Mime Types
  • Forzar la descarga del archivo
  • Documentos de error
  • Acciones sobre scripts
  • Cabeceras, caché y optimizaciones
  • Rewrites y redirecciones
  • Autenticación y seguridad
  • SSL
  • Site en construcción

Ultimate htaccess File sample

Laboratorio: Proteger ruta virtual mediante Apache

En otras ocasiones hemos comentado como proteger directorios mediante Apache, incluyendo en el .htaccess los comandos necesarios para ello. El problema viene cuando en vez de proteger una ruta física, queremos proteger un URL virtual, entendiendo URL virtual, aquella que no existe físicamente y que mediante Apache redireccionamos a un script en concreto, por ejemplo:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteBase /
RewriteRule ^clientes index.php?redirect=clientes [QSA,L]

En este caso, si accedemos a http://servidor/cliente, realmente no estaremos accediendo a una ruta física, pero puede ser que queramos que esta url no sea accesible para todo el mundo.

Para proteger una URL virtual debemos usar el comando Location, el cual debemos incluirlo en el httpd.conf o en un dominio virtual, y para protegerlo deberemos usar:

<Location /client>
AuthType Basic
AuthName "Acceso Protegido"
AuthUserFile [ruta .htpasswd]
AuthGroupFile /dev/null
order allow,deny
allow from all
deny from none
require valid-user
</Location>
|

Optimizaciones para Apache y PHP

La gente de IBM nos vuelve a ofrecer un artículo en el que nos explican como optimizar nuestro Apache y PHP para obtener mejores resultados en nuestras aplicaciones web.
El artículo está dividido en dos partes: una para configurar Apache y la otra para PHP, existe un documento anterior en el que explican la arquitectura LAMP y como configurar Linux.
Inicialmente para Apache nos explica cómo configurar el MPM (Multi-Processing Modules), el cual ayuda a manejar las conexiones entrantes y las salientes, podremos indicar el número máximo de clientes y el número de peticiones por hijo que tratará, entre otras cosas.
Algo también muy importante es configurar eficientemente las opciones o controles que se indican en los ficheros de configuración, y que controlan las reglas que debe seguir el servidor web con cada petición.
Por último, habrá que tener en cuenta en la configuración el número de conexiones que permanecerán activas para una llamada HTTP, así como el envío de la respuesta de forma comprimida (de esto ya hemos hablado en otras ocasiones, hay que decidir entre CPU usada en el servidor o respuestas más rápidas).
Sobre PHP nos indican la necesidad de usar opcode cache, representación binaria del script PHP que puede ser ejecutada. Para ello existen varios cachés disponibles, aunque recomiendan el uso de eAccelerator.
El resto de las recomendaciones se refieren a la configuración del tiempo máximo de ejecución, el tiempo máximo de espera de la entrada, la memoria máxima utilizada y al tamaño del buffer.
Optimizing Apache and PHP
Vía / Good PHP Tutorials

| |

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