Página de mantenimiento con nginx

11 de agosto, 2011 - por | | Sistemas, Tips

En varios de nuestros proyectos utilizamos nginx como servidor HTTP. A veces solo, y otras como proxy de Apache sirviendo únicamente contenidos estáticos (mira este otro post para ver las ventajas de hacer ésto).

En cualquier sitio web te ves obligado en algún momento a poner el sitio offline: por tareas de mantenimiento de sistemas, por nuevas versiones del código, por cambios en la infraestructura, etc. Puesto que debes informar siempre al usuario de lo que pasa en tu sitio, debes tener preparada para todas esas ocasiones una página que indique que el servicio no está disponible.

En nginx eso se consigue colocando en el fichero de configuración lo siguiente:


server {
        error_page 503 @maintenance;
        location @maintenance {
                rewrite ^(.*)$ /503.html break;
        }
}

El nombre del fichero puede ser cualquiera que tú elijas. Lo que hace nginx es que siempre que existe ese fichero (en el $document_root), redirige cualquier petición que le llega a esa página. Y lo hace, además, devolviendo un código de estado 503. Puedes comprobar ésto en el Header de la página con cualquier herramienta popular tipo Firebug (documentación en inglés).

Instalar SSH2 para PHP 5.3 en CentOS

10 de agosto, 2011 - por | 1 comentario | Desarrollo, Sistemas

En el proceso de instalación de SSH2 para PHP 5.3 sobre CentOS hay un primer paso que sigue funcionando igual de bien que anteriormente:


yum install gcc php53-devel libssh2 libssh2-devel

Sin embargo, PHP 5.3 sobre CentOS aún no ha incorporado el paquete correspondiente para:


php53-pear

necesario para manejar la instalación de la extensión SSH2 mediante PECL. Es un bug ya apuntado en el Bugzilla de Redhat, pero que aún está pendiente de resolución.

Hay dos métodos principales para resolver este problema. Uno que consiste en utilizar el repositorio IUS, que ofrece paquetes php53 y extensiones más actualizados, junto con un php53-pear. Si te decides por este método, este post de Eric London te explica los pasos principales (en inglés).

El segundo método consiste en conservar el paquete tradicional php-pear y forzar su actualización mediante los siguientes comandos:


pear upgrade --force Console_Getopt
pear upgrade --force pear
pear upgrade-all

Una vez que tienes instalados los paquetes mencionados, ya puedes instalar la extensión SSH2:


pecl install -f ssh2

Una vez que esté instalada, verás que al final del proceso de instalación te indica como siempre la línea que debes añadir al fichero php.ini:


extension=ssh2.so

Reinicias tu servidor HTTP y compruebas que la extensión está cargada y funcionando:


php -m | grep ssh2

Actualizar WordPress por SSH

10 de agosto, 2011 - por | | Sistemas, Tips

Tenemos que ir más allá de nuestros límites corporales para conseguir muchas cosas.

WordPress incluye desde hace tiempo la posibilidad de actualizar directamente desde el admin tanto el core, como los plugins y los temas. Es decir, los 3 componentes principales. Para nosotros, que manejamos múltiples WordPress, es la forma más cómoda de mantenerlos actualizados.

La lástima es que la interfaz del admin sólo menciona la posibilidad de hacerlo por FTP, cuando en realidad también existe la alternativa de hacerlo por SSH. Lo único que hace falta es que tengas instalada y funcionando en tu servidor la extensión SSH2 para PHP; una vez la tienes corriendo, verás cómo WordPress te enseña en la misma pantalla de actualización la posibilidad de hacerlo por SSH.

Si te mueves en Linux, en la mayoría de las distribuciones recientes instalar la extensión SSH2 para PHP es muy fácil: no te exige compilar nada, como hace unos años. Por ejemplo, para Debian/Ubuntu este post de Kevin van Zonneveld te lo resuelve todo (en inglés).

Ahora bien, si te mueves en CentOS, y te has animado a probar PHP 5.3 sobre esa plataforma, la cosa desgraciadamente se complica un poco. Si estás interesado en ésto, te lo explicamos en este otro post.

WordPress como CMS: identificar subpáginas

9 de agosto, 2011 - por | | Desarrollo

Si te has animado a utilizar WordPress como CMS, un poquito más allá de su foco original de funcionar como un blog, la gestión de las páginas pronto se va a convertir en uno de tus temas habituales de desarrollo.

Cuando empiezas a montar la estructura de información del sitio, y separas los contenidos por áreas, te encontrarás probablemente con la clásica estructura de árbol, en la que hay unas páginas principales de las que cuelgan otras secundarias. Identificar en qué pagina y subpágina se encuentra el usuario te va a venir bien para muchas cosas, empezando por un menú básico que ayude a navegar con más facilidad.

WordPress cuenta con su propia función para determinar en qué página te encuentras:


is_page($page);

pero no con una para determinar la subpágina. En nuestros proyectos solemos utilizar la siguiente:


/**
 * Returns boolean value for checking if the current page is child
 * of a parent page
 *
 * @param int
 * @return bool
 */
function is_subpage($iID = null)
{
        global $post, $wpdb;
        if ( is_page() AND isset( $post->post_parent ) != 0) {
                $aParent = $wpdb->get_row( $wpdb->prepare(
                    "SELECT ID FROM $wpdb->posts \
                    WHERE ID = %d AND post_type = 'page' LIMIT 1",
                    $post->post_parent
                ) );
                if ( is_int( $iID ) > 0 ) {
                        if ( $aParent->ID == $iID ) {
                                return true;
                        } else {
                                return false;
                        }
                } else {
                        if ( $aParent->ID ) {
                                return true;
                        } else {
                                return false;
                        }
        } else {
                return false;
        }
}

La llamamos desde el fichero:


/wp-includes/functions.php

Utilizar InnoDB en Django

8 de agosto, 2011 - por | | Desarrollo, Tips

Si estás empezando a trabajar con Django y vas a utilizar MySQL, te conviene pararte un momento a mirar si estás utilizando el tipo de almacenamiento que realmente quieres.

Al generar los esquemas, Django no especifica ningún tipo de almacenamiento; sencillamente los genera con el que está establecido en tu servidor de MySQL. Así que si aún no has generado ningún esquema, revisa tu configuración de MySQL. Todas las versiones previas a la 5.5 hacían de MyISAM el almacenamiento por defecto.

La configuración del tipo de almacenamiento la puedes hacer directamente en MySQL, o especificarla en los settings de tu conexión a la base de datos en Django utilizando la opción “init_command”. Por ejemplo, del siguiente modo para establecer InnoDB como el tipo almacenamiento por defecto.


'OPTIONS': {
   'init_command': 'SET storage_engine=INNODB',
}

Si ya cuentas con algunas tablas, y te encuentras con que están con un tipo de almacenamiento distinto al que tu pensabas, te va a tocar modificar las tablas en la forma habitual:


ALTER TABLE tablename ENGINE=INNODB;

Problemas al guardar la IP en la sesión con conexiones 3G

7 de agosto, 2011 - por | | Curiosidades, Desarrollo

Hace poco me ha surgido un problema para el que en un primer momento no encontraba una explicación satisfactoria. Sobre una aplicación escrita en PHP y que trabaja casi todo el tiempo haciendo uso de sesión, me empecé a encontrar con cierres de sesión inesperados.

Las primeras cosas que pensé fueron problemas de disco (suelen acarrear problemas aleatorios de memoria); errores en un refactor reciente de código que consistía en abstraer muchas llamadas a sesión; y problemas de memoria. Fui descartándolos todos, y me puse a pensar en un problema interno de la aplicación en la forma de gestionar la sesión.

Por ahí no encontré un problema, pero sí la razón de esas pérdidas de sesión. Estaba almacenando la IP del cliente como un valor más de la sesión; creo recordar que lo diseñé así para obtener más seguridad. El problema es que la conexión 3G con la que navegaba, cambiaba la IP constantemente. La aplicación cuando comprobaba que la IP de la sesión no correspondía con la del cliente, la cerraba.