Y es que a veces encontraremos que nuestra aplicación tiene unos requisitos mínimos que el servidor no cumple. Pongamos por ejemplo que queremos instalar prestashop que tiene ciertos requisitos mínimos y que por algún motivo nuestro hosting no satisface.

Cómo configurar variables de PHP desde .htaccess

Hay varias formas de actuar sobre estas variables, pero tal y como reza el título de esta entrada hoy vamos a hacerlo con el archivo .htaccess, y para ello utilizaremos la orden php_value. Su sintaxis es muy sencilla:

php_value + variable_php + valor.

Un ejemplo podría ser que necesitamos que la variable memory_limit esté configurada en 64M y el servidor la tiene configurada en 32M, o quizás el max_input_vars está configurado en 500 y nuestros requisitos mínimos son 1.000. Para ello incluiríamos las siguientes líneas en el archivo .htaccess:

php_value memory_limit 64M
php_value max_input_vars 1000

O supongamos que queremos mostrar los errores de PHP de nuestra aplicación. Podemos hacerlo desde el archivo .htaccess:

php_value error_reporting 7
php_flag display_errors On

Dónde colocar las líneas dentro del archivo .htaccess

Personalmente me gusta colocar este tipo de sentencias al comienzo del archivo .htaccess, justo detrás de los comentarios:

# Comentarios habituales en archivos .htaccess

# variables php
php_value error_reporting 7
php_flag display_errors On

<IfModule mod_rewrite.c>
<IfModule mod_env.c>
SetEnv HTTP_MOD_REWRITE On
</IfModule>

RewriteEngine on
...

Créditos, referencias y artículos relacionados

• Aumentar el límite de memoria de un script en PHP
• Aumentar el limite de tiempo máximo de ejecución de un script en PHP
• Servidor Web en Raspberry PI y Ubuntu Mate
• Como configurar Virtual Hosts en Apache 2 y Ubuntu
• Habilitar módulos en Apache 2 sobre Ubuntu

Estoy seguro de que a muchos de vosotros os suena lo siguiente: te dispones a instalar un servidor web, abres la consola de Linux, instalas Apache, y cuando buscas el paquete de PHP te encuentras que tienes varias opciones: php7.2, php7.2-cgi, php7.2-fpm o libphp7.2-embed. Dudas sobre cual elegir pero no tienes tiempo o ganas de investigar, sabes que el paquete php7.2 funcionará con total seguridad, así que lo instalas y continuas con la siguiente tarea.

Si has vivido esta situación, no te sientas culpable, no tengas remordimientos de conciencia, no estás solo, somos muchos los que hemos actuado así, pero sigue leyendo y la próxima vez podrás elegir la mejor opción para tus necesidades.

Handlers en Apache

Según la web de Apache, un handler es «una representación interna de Apache de una acción que se va a ejecutar cuando hay una llamada a un fichero», y continua «Generalmente, los ficheros tienen handlers implícitos, basados en el tipo de fichero de que se trata». Esto, traducido al cristiano y llevado al ámbito de PHP significa que cuando Apache detecta un fichero PHP hará uso de los handlers para conectar con el intérprete y que éste realice las tares oportunas.

Handlers para PHP

Ya sabemos que es un handler, repasemos ahora las principales opciones existente para que Apache pueda interpretar los archivos PHP.

DSO ó mod_php

Probablemente habrás escuchado hablar de mod_php pero quizás no de DSO. Mod_php es como se conoce comúnmente al manejador DSO (Dynamic Shared Object).

Es la opción más habitual en entornos de desarrollo o locales, si buscamos en internet como instalar PHP sobre Apache en Linux la mayoría de resultados nos propondrán este sistema, y para muestra un botón: Servidor Web en Raspberry PI y Ubuntu Mate.

Con mod_php el intérprete de PHP es ejecutado directamente por Apache como un módulo, lo que evita tener que realizar llamadas a procesos externos. Esto es una ventaja en cuanto que la comunicación entre ambos es muy ágil y nos permite obtener un gran rendimiento.

Otra característica de este sistema es que el intérprete PHP es cargado al arrancar cada proceso de Apache, incluso cuando el contenido a servir no contiene código PHP alguno. Este hecho provoca que obtengamos un mejor rendimiento en detrimento del consumo de recursos del sistema, convirtiéndolo en una mala opción para sites con mucho tráfico.

También es importante destacar que PHP hereda los permisos del usuario de Apache. Esto implica que nobody será el propietario de cualquier archivo creado por PHP, pudiendo generar algunos conflictos de permisos. No obstante con una mínima configuración podemos evitar este problema, podéis ver como hacerlo en el artículo Archivos y permisos de usuario en Apache 2 y Linux.

Ventajas de DSO

• Fácil instalación y configuración.
• Buen rendimiento.

Inconvenientes de DSO

• Alto consumo de recursos.
• Los archivos creados por PHP pertenecen a Apache.

CGI

CGI son las siglas de Common Getway Interface. Como su propio nombre indica es una interface y su cometido es permitir a Apache interactuar con programas externos, en este caso con PHP. Es un sistema que prácticamente podemos denominar como legacy y está cada vez más en desuso debido a su pobre rendimiento y a la existencia de alternativas más modernas y eficientes.

Al utilizar esta interface, cada petición de PHP inicia un proceso independiente que es finalizado cuando concluye su labor. Este modus operandi consigue que CGI sea muy eficiente en el consumo de memoria pero pobre en rendimiento. En sitios web con alto tráfico el sistema de creación y destrucción de procesos implica un uso de procesador demasiado elevado, por lo que no es nada recomendable para este tipo de sites.

Y al igual que con DSO, Apache será el propietario de lo archivos que generemos o subamos al servidor haciendo uso de PHP, pero ya hemos visto que este problema tiene fácil solución.

Ventajas de CGI

• Fácil de instalar y configurar.
• Consumo de recursos moderado en sites con poco tráfico.

Inconvenientes de CGI

• Rendimiento pobre.
• Alto consumo de procesador en sites con tráfico elevado.
• Los archivos creados por PHP pertenecen a Apache.

FastCGI

Podemos decir que FastCGI es la evolución de CGI, y surge por la necesidad disponer de un sistema con las ventaja de Common Getway Interface pero minimizando sus inconvenientes.

Al contrario que CGI, FastCGI mantiene la sesión abierta de forma persistente y no la cierra una vez que ha concluido el proceso por el que la abrió. Con esto se consigue un rendimiento similar a DSO a costa de elevar el consumo de memoria pero manteniéndolo por debajo de éste.

Una gran ventaja de FastCGI es que podemos configurar nuestro servidor para que trabaje con múltiples versions de PHP, lo que es particularmente útil cuando en una misma máquina tenemos aplicaciones que requieren versiones distintas de PHP.

Otra característica muy interesante es que podemos separar el host dónde corre Apache del host qué interpreta PHP, ofreciéndonos una gran versatilidad en el diseño de nuestro sistema.

Por último y haciendo referencia al propietario de los archivos creados por PHP, FastCGI hace uso de suEXEC para permitir definir la propiedad de los archivos. Esto es particularmente útil en entornos compartidos dónde es posible configurar distintos propietarios para distintos sites

Ventajas de FastCGI

• Buen rendimiento.
• Consumo de recursos moderado.
• Posibilidad de ejecutar Apache y PHP en distintos hosts.
• Posibilidad de trabajar con distintas versiones de PHP.
• Posibilidad de definir el propietario de los archivos.

Inconvenientes de FastCGI

• Mayor complejidad de configuración.

FPM

FPM o FastCGI Process Manager ha sido el último en llegar, y no es más que una implementación de FastCGI con varias características orientadas a la mejora del comportamiento para sitios web con mucho tráfico.

Cómo la diferencia entre FastCGI y FPM comienzan a adentrarse en un terreno muy técnico, no entraremos en mucho detalle, ero si mencionaremos algunas de estas mejoras:

• Manejo avanzado para detener/arrancar procesos de forma fácil.
• Posibilidad de iniciar hilos de procesos con diferentes uid/gid/chroot/environment.
• Escuchar en diferentes puertos.
• Usar distintos php.ini
• Uso de safe_mode.

Si quieres ver la lista completa de estas ventajas puedes hacerlo en la página dedicada a FPM en php.net.

Ventajas de FPM

• Buen rendimiento.
• Consumo de recursos moderado.
• Todas las ventajas de FastCGI.
• Más opciones de configuración que FastCGI.

Inconvenientes de FPM

• Mayor dificultad de instalación y configuración.

Tabla comparativa

Para intentar ser prácticos, podemos resumir lo que hemos visto en una tabla comparativa, que si bien carece de muchos matices puede darnos una visión bastante clara con tan solo un vistazo.

mod_php, CGI, FastCGI ó FPM, cuál es mejor?

Y la respuesta que muchos esperaréis después de leer (o no) esta entrada es: cuál es mejor? Y la respuesta más habitual a este tipo de preguntas es: para qué?

Para entornos de desarrollo, entornos de prueba o para pequeñas intranets sin excesiva carga recomendaría DSO. Es fácil de configurar, rinde bien y no tendremos problemas de recursos. El único motivo por el que me decantaría por otra opción sería si necesitáramos tener más de una versión de php corriendo en la misma máquina. En tal caso la opción más apropiada sería FastCGI.

Si nos vamos al lado opuesto, sites con muchísimo tráfico, dónde confieso que no tengo ninguna experiencia, parece que la mejor opción es FPM, por: rendimiento, consumo de recursos y versatilidad.

Y entre el espacio que dejan las dos situaciones propuestas es quizás dónde mejor encajaría FastCGI, asumiendo que los motivos que influyen en la decisión última no permiten trazar líneas delimitadoras claras y recomendar hasta aquí esta opción y a partir de aquí la otra. En su lugar nos dejan una amplia gama de grises en función de las características del entorno.

Para acabar, personalmente intentaría no utilizaría CGI, pues no encuentro ninguna característica diferenciadora que compense el peor rendimiento y mayor consumo de recursos.

Créditos, referencias y artículos relacionados

• Imagen de portada por Arek Socha en pixabay.
• Servidor Web en Raspberry PI y Ubuntu Mate.
• Archivos y permisos de usuario en Apache 2 y Linux.
• Habilitar módulos en Apache 2 sobre Ubuntu.
• Handlers en Apache.
• RFC de Common Gateway Interface.

Así que puestos a escribir sobre habilitar módulos, y dado que es una tarea bastante habitual habitual cuando instalamos un nuevo servidor web, o incluso cuando instalamos algunos paquetes de software sobre un servidor web existente, decidí escribir esta entrada más generalista.

Y es que en la actualidad, en una instalación estándar de Apache 2 sobre Ubuntu 18 se instalan más de 100 módulos, de los cuales sólo hay activos algo más de una veintena.

Habilitar módulos

Lejos quedan los tiempos en los que para habilitar módulos de Apache teníamos que editar el archivo apache.conf, tarea que generalmente no consistía más que en descomentar alguna línea. Hoy basta con ejecutar el comando a2enmod y reiniciar el servidor:

sudo a2enmod modulo
sudo service apache2 restart

Pero descubramos que hay detrás de de este comando.

Los módulos disponibles por Apache 2 se encuentran dentro del directorio /etc/apache2/mods-available/. Lo que quiere decir que si el módulo que queremos habilitar no se encuentra ahí tendremos que copiarlo y asignarle los permisos adecuados.

Por otro lado, los módulos habilitados se encuentran en el directorio /etc/apache2/mods-enabled/. Pero en este caso en lugar de encontrar archivos, encontraremos enlaces simbólicos a los archivos situados en la carpeta /etc/apache2/mods-available/. Así que una alternativa al comando a2enmod es el comando ln:

sudo ln -s /etc/apache2/mods-available/modulo /etc/apache2/mods-enabled/modulo
sudo service apache2 restart

Deshabilitar módulos

Y para deshabilitar módulos la operación es muy similar, con la salvedad de que en lugar de utilizar el comando a2enmod utilizaremos el comando a2dismod:

sudo a2dismod modulo
sudo service apache2 restart

O simplemente eliminaremos el enlace simbólico:

sudo rm /etc/apache2/mods-enabled/modulo
sudo service apache2 restart

Comprobaciones y logs de errores

Podemos saber si un módulo se ha instalado correctamente revisando la salida de la función phpinfo() de php, en la sección apache2handler.

Y en caso de experimentar cualquier tipo de problema, el primer lugar dónde consultar qué está ocurriendo son los logs de error de Apache 2, en el archivo /var/log/apache2/error.log.

cat /var/log/apache2/error.log

Créditos, referencias y artículos relacionados

• Imagen de portada por Wichan Yodsawai.
• Servidor Web en Raspberry PI y Ubuntu Mate.
• Como configurar Virtual Hosts en Apache 2 y Ubuntu.
• Archivos y permisos de usuario en Apache 2 y Linux.

Esta es la tercera entrega de la serie Clonar una web en un servidor local, por lo que te recomiendo leer las entregas previas. No obstante, este artículo puede ser tratado como un artículo atómico asumiendo que perdemos ciertos matices.

Una de las ventajas del proceso de clonado de los archivos frente al de clonado de una base de datos es que si bien con la base de datos podíamos encontrarnos muchas limitaciones en función de los diferentes proveedores y planes de hostings, para clonar los archivos el único requisito que debemos cumplir con respecto a nuestro host remoto es tener acceso mediante ftp, algo que todos los hosting ofrecen.

Descarga de archivos

Para descargar los archivos nos serviremos del comando wget. Comenzaremos el proceso creando un script de consola y le asignándole los permisos necesarios:

mkdir ~/scripts
vim ~/scripts/cloneWebFiles.sh
chmod 0755 ~/scripts/clonWebFiles.sh

Con el siguiente contenido:

#!/bin/bash

wget -r -N -q --level=15 --user=user --password='password' --directory-prefix=~/webBackUp fttp://ftp.url.com

Dónde:

• -r, indica recursividad
• -N, indica que descargue solo archivos nuevos y/o modificados
• -q, oculta los mensajes de salida del comando
• –level=15, es el numero de niveles de recursividad
• –user=user, es el usuario ftp
• –password=’password’, es la contraseña del ftp
• –directory-prefix=~/webBackUp, es el directorio dónde copiaremos los archivos
• fttp://ftp.url.com, es el ftp con el path del que queremos descargar los archivos

Esto realizará una copia de los archivos de nuestra web en la carpeta ~/webBackUp/ftp.url.com. Esta operación suele tardar bastante tiempo, así que para agilizarla hemos optado por descargar únicamente los archivos nuevos y/o modificados recientemente, aun así con una web de tamaño medio tardará un buen rato.

Debemos destacar que no descargamos los archivos directamente a nuestro entorno de pruebas, sino que los descargamos a una carpeta intermedia. Esto lo hacemos por dos motivos:

1. Modificaremos algunos archivos antes de copiarlos en nuestro entorno de pruebas.
2. Podemos crear un segundo script que omita la descarga y que restaure nuestra copia mucho más rápido, muy útil en caso de querer descartar los cambios realizados y comenzar desde 0.

Modificación de datos relativos al entorno

Una vez hecha la descarga de los archivos deberemos modificar los que contienen datos relativos a nuestro host. En nuestro ejemplo, el archivo wp-config.php almacena la inforación de la conexión a la base de datos. En vuestro caso debereis localizar que archivos contienen este tipo de información antes de seguir avanzando.

La estrategia que seguiremos para ello sera la de realizar una copia inicial de forma manual de los archivos sensibles al entorno de pruebas. Una vez hecha actualizaremos los datos necesarios.

Por otro lado, automatizaremos una tarea que renombra estos archivos en la ubicación intermedia, de forma que cuando realicemos la copia al entorno de pruebas no se sobrescriban. Así que agregamos estas dos líneas a nuestro script:

rm ~/webBackUp/ftp.url.com/w-config.php.renamed
mv ~/webBackUp/ftp.url.com/w-config.php ~/webBackUp/ftp.url.com/w-config.php.renamed

Copia de archivos a la ubicación definitiva

Ya con los archivos descargados y una vez resuelta la problemática de la información sensible al entorno copiamos los archivos:

cp -r ~/webBackUp/ftp.url.com/* /var/www/targetVHost

Como vemos, este sistema solo copia los archivos nuevos y/o que han sufrido cambios, pero si hemos eliminado un archivo de nuestro host remoto no lo eliminará de nuestro host local. Para mi esta situación no supone un problema a día de hoy, así que simplemente no hago nada, pero siempre se puede preparar algún sistema que busque la diferencia de archivos entre la copia intermedia y el entorno de prueba y elimine los sobrantes de esta segunda ubicación.

El script

Y todo el rollazo que os he soltado se traduce básicamente en el siguiente script:

#!/bin/bash

wget -r -N -q --level=15 --user=user --password='password' --directory-prefix=~/webBackUp fttp://ftp.url.com
rm ~/webBackUp/ftp.url.com/w-config.php.renamed
mv ~/webBackUp/ftp.url.com/w-config.php ~/webBackUp/ftp.url.com/w-config.php.renamed
cp -r ~/webBackUp fttp://ftp.url.com/* /var/www/targetVHost

Programar la ejecución de la copia

Al igual que hicimos con la clonación de la base de datos programamos la ejecución del script con Cron:

crontab -e

E incluimos la siguiente línea en el archivo crontab:

0 2 * * 5 ~/scripts/clonWebFiles.sh

Aunque en principio ambos script podrían ejecutarse a la misma vez, hemos sido precavidos retrasando una hora la ejecución de la copia de los archivos, de forma que se ejecute cada viernes a las 02:00 de la madrugada.

Créditos y Referencias

• Articulo de la serie: Clonar una web en un servidor local.
• Entrega previa de la seie: Clonar una web: la base de datos.
• Imagen de portada: Martin Harry.

Esta entrada pertenece a la serie Clonar una web en un servidor local. Por ese motivo te recomiendo que leas dicho artículo para darle perspectiva a este. Sea como sea, este artículo puede ser leído sin la referencia anterior, pero perderemos ciertos matices que quizás resulten interesantes.

Backup de la base de datos remota

En función del hosting que tengamos contratado dispondremos de una serie de funcionalidades. Por norma general si has contratado un VPS o servidor dedicado tendrás la posibilidad de ejecutar scripts de consola, lo cual ofrece muchas posibilidades para la tarea que queremos realizar.

Si por el contrario dispones de un hosting compartido no sueles tener acceso a esta opción, así que para dar respuesta a la mayor cantidad de situaciones posibles realizaremos el backup con PHP, más concretamente haremos uso de la clase MySql Backup Lite que introducimos en la entrada Backup de base de datos MySQL con PHP. Y para programar la ejecución de esta tarea nos ayudaremos de nuestro servidor local, dónde programaremos la ejecución de un script que acceda a la url que realiza el respaldo.

Para no extendernos demasiado y no repetirnos, no copiaremos la clase en esta entrada, puedes encontrarla en los enlaces del párrafo anterior.

Así que crearemos un script en PHP en nuestro servidor remoto que llamaremos backUpDb.php en el directorio scripts que tras ser ejecutado generará una copia de la base de datos en el archivo backups/wordpressBackUp.sql.

include('MySqlBackup.php');

$arrayDbConf['host'] = 'dbHost';
$arrayDbConf['user'] = 'dbUser';
$arrayDbConf['pass'] = 'dbPassword';
$arrayDbConf['name'] = 'wordpressDbName';

try {

  $bck = new MySqlBackupLite($arrayDbConf);
  $bck->backUp();
  $bck->setFileDir('../backups/');
  $bck->setFileName('wordpressBackUp.sql');
  $bck->saveToFile();

}
catch(Exception $e) {

  die($e);

}

Si nuestro hosting tiene habilitada la conexión remota a la base de datos este paso podríamos ejecutarlo en el servidor local. Como no siempre tendremos esta opción, nos hemos decantado por la alternativa más universal.

Y puesto que en este ejemplo el backup es de una plataforma WordPress, y que por ese motivo los datos de conexión a la base de datos ya están especificados en un archivo de configuración escrito en PHP, sería más interesante hacer un include del archivo wp-config.php y obtenerlos desde ahí. De nuevo, en pro de mantener esta entrada lo más genérica posible hemos decidido hacerlo así.

Programar la ejecución del backup de la base de datos

Una vez más existen múltiples opciones para programar esta tarea, unas más elegantes que otras. En un VPS programar una tarea con Cron sería lo más lógico y eficiente, pero tal y como hemos comentado, tomaremos la opción que podemos aplicar independientemente del hosting que tengamos: utilizaremos Cron en nuestro servidor local para programar una tarea que ejecute el script de backup de base de datos que acabamos de crear en el host remoto.

Para ello creamos un script de consola y le asignamos los permisos necesarios:

mkdir ~/scripts
vim ~/scripts/cloneWebDb.sh
chmod 0755 ~/scripts/clonWebDb.sh

Con el siguiente contenido:

#!/bin/bash

curl -Is https://url.com/scripts/backUpDb.php

Y programamos la ejecución del script con Cron:

crontab -e

E incluimos la siguiente línea en el archivo crontab:

0 1 * * 5 ~/scripts/clonWebDb.sh

Asegurándonos de que el script se ejecuta cada Viernes a la 1 de la madrugada. Evidentemente puedes programar la periodicidad que más te convenga. Puedes visitar la entrada Programar tareas en Ubuntu con Cron para profundizar en la programación de tareas con Cron.

Descargar el backup de la base de datos

Lo siguiente es descargar el backup que acabamos de realizar. Lo haremos mediante el protocolo ftp, sirviéndonos del comando wget. Para ello agregamos una línea más a nuestro script clonWeb.sh, de forma que quede así:

#!/bin/bash

curl -Is https://url.com/scrpts/backUpDb.php
wget -q --user=user --password='password' --directory-prefix=~/webBackUp fttp://ftp.url.com/backups/wordpressBackUp.sql

Dónde:

• -q, oculta los mensajes de salida del comando
• –user=user, es el usuario ftp
• –password=’password’, es la contraseña del ftp
• –directory-prefix=~/webBackUp, es el directorio dónde copiaremos los archivos
• fttp://ftp.url.com/backups/wordpressBackUp.sql, es el ftp con el path del que queremos descargar los archivos

Con esto ya habremos descargado nuestra base de datos en el directorio ~/webBackUp/ftp.url.com/backups/wordpressBackUp.sql. El siguiente paso será restaurarla.

Restauración de la base de datos

Y para restaurar la base de datos en nuestro servidor local la estrategia que seguiremos será:

1. Eliminamos la base de datos.
2. Volvemos a crear base de datos vacía.
3. Restauramos la base de datos desde el backup.

Como puedes ver el proceso es bastante crítico pues elimina completamente la copia existente. Además hará que durante el tiempo que toma el proceso nuestro clon local no esté accesible. En mi caso el uso que le voy a dar es disponer de una réplica de una web en productivo en un servidor local para realizar pruebas. Para este uso el riesgo es perfectamente asumible, y en todo el tiempo que llevo utilizándola no he tenido ningún tipo de problema. Evidentemente, tú deberás evaluar si este riego y esta parada de servicio son asumibles para ti.

Así que crearemos un script SQL que elimine completamente la base de datos y vuelva a crearla. De nuevo lo haremos dentro de la carpeta ~/scripts y lo llamaremos dropAndCreateDb.sql. El contenido será el siguiente:

DROP DATABASE localDbName;
CREATE DATABASE localDbName;

Y agregamos dos líneas más a nuestro script de consola para ejecutar

#!/bin/bash

curl -Is https://urlToScript.com/backUpDb.php
wget -N -q --user=user --password='password' --directory-prefix=~/webBackUp ftp://ftp.miweb.com/path/backups/wordpressBackUp.sql
mysql -u localDbUserName -plocalDbPassword localDbName < ~/scripts/dropAndCreateDb.sql
mysql -u localDbUserName -plocalDbPassword localDbName < ~/webBackUp/ftp.url.com/backups/wordpressBackUp.sql

Actualización de los datos relativos al entorno

El último paso para dar por completado el proceso de clonación de nuestra base de datos será reemplazar todos los datos datos necesarios para que nuestro clon funcione perfectamente. Este paso es el que más puede variar de un entorno a otro, a continuación os dejo un ejemplo bastante básico para un blog realizado en wordpress:

update wp_options set option_value='http://192.168.1.10' where option_name='siteurl';
update wp_options set option_value='http://192.168.1.10' where option_name='home';
update wp_posts set guid=REPLACE(guid, 'blog.ahierro.es', '192.168.1.146:8085') where guid like '%blog.ahierro.es%';

Vosotros tendréis que localizar las tablas, campos y registro a modificar en vuestras plataformas. En el ejemplo expuesto las dos primeras líneas hacen referencia a datos de configuración y son imprescindible, pues de no actualizar estos campos nuestro wordpress local siempre redirigiría al remoto.

Créditos y Referencias

• Articulo de la serie: Clonar una web en un servidor local.
• Siguiente entrega de la serie: Clonar una web: los archivos.
• Clase MySql Backup Lite.
• Imagen de portada: Martin Harry.

Y cuando hablamos de «una copia exacta», queremos decir que tanto archivos como bases de datos estén perfectamente actualizados. Esto es muy útil para realizar pruebas de todo tipo: nuevos plugins, cambios de configuración, revisión de actualizaciones, etc.

Realizar esta tarea manualmente es tedioso, aburrido y consume mucho tiempo, eso sin contar que es probable que cuando nos propongamos realizar nuestras pruebas este entorno esté desactualizado, alterado por las últimas pruebas realizadas, o lo que es aún peor, no esté disponible. Así que una buena idea es automatizar esta tarea y programar su ejecución con la periodicidad que nos interese.

Algunos aspectos relativos al clonado

Resumen del proceso

Es buena idea tener una visión general del proceso antes de adentrarnos en él. Lo que vamos a hacer básicamente es un proceso ETL (Extract, Transform, Load) manual.

Como parte del proceso de extracción realizaremos una copia de seguridad de la base de datos y la descargaremos a una ubicación intermedia. Haremos lo mismo con los archivos del servidor.

Una vez tenemos todo lo necesario en nuestro servidor local, modificamos algunos datos como son archivos de configuración o los registros en la base de datos relativos al entorno.

Finalmente restauraremos la base de datos y sobrescribiremos los archivos de nuestro servidor local.

Local versus Remoto

A pesar de que cada una de las tareas que realizaremos no son complicadas por si mismas, alternaremos de host continuamente y eso puede generar alguna confusión, así que para seguir los pasos indicados sin error deberemos estar muy atentos al host en el que se realizan las distintas acciones. Identificaremos los hosts como «remoto», el servidor de producción que queremos clonar, y «local» el servidor de pruebas dónde queremos tener la copia.

Es importante que las versiones de LAMP (Linux, Apache, PHP y MySQL) sean lo más similar posible, de este modo es posible que nos ahorraremos algunos quebraderos de cabeza. Además, es recomendable dedicar un virtual host de Apache para este entorno en nuestro servidor local.

Ejemplo sobre WordPress

Y ya que estas líneas que lees están escritas sobre WordPress, utilizaremos esta plataforma como ejemplo para realizar el clonado. Esto quiere decir que por norma general, si queréis clonar otra plataforma, las mayores diferencias las encontraremos en los los registros de la base de datos y los archivos de configuración referentes al entorno.

Periodicidad

Como hemos dicho queremos automatizar el clonado de nuestra web para tener nuestra réplica preparada y actualizada en todo momento. Podemos establecer la periodicidad que más nos convenga, personalmente estoy cómodo con una semana por dos motivos:

1. En una semana no suelen producirse muchos cambios en el blog.
2. Algunas pruebas se extienden durante varios días, y una restauración diaria las sobrescribiría.

Además, siempre estamos a tiempo de lanzar una actualización manual en caso de ser necesario con la simple ejecución de un script. Si no tienes una web muy grande el proceso será relativamente rápido.

Requisitos hardware

En cuanto a los requisitos de hardware puedes estar tranquilo, pues no necesitas un gran servidor para implementar este sistema. Un ejemplo muy claro de ello es que para este blog lo tengo implementado con una humilde Raspberry Pi. Por si te interesa, aquí te dejo un enlace en el que puedes ver cómo de sencillo es montar un servidor web Apache sobre una Raspberry Pi.

Clonando nuestra web: el proceso

Llegados a este punto creo que al igual que yo ya tendréis ganas de poneros manos a la obra, así que no me enrollo más y vamos al lío.

Y puesto que esto se ha alargado un poco más de la cuenta, hemos dividido este artículo en varias entregas para que sea más fácil de seguir:

1. Clonar una web en un servidor local (es decir, esta entrada).
2. Clonar una web: la base de datos.
3. Clonar una web: los archivos.

Créditos y referencias

• Imagen de portada: Martin Harry.

Los ejemplos de este documento han sido probados tanto sobre Ubuntu Mate 16.0.4.2 y Apache 2.4.18 como sobre XUbuntu 18.04 con la versión 2.4.29 de Apache, aunque funcionarán sobre la mayoría de distribuciones Linux con la versión 2.4 de Apache.

Para el resto del artículo, asumiremos que la ip de la máquina dónde estamos configurando los host virtuales es 192.168.1.10.

¿Qué es un virtual host en Apache 2?

Virtual host es la herramienta que Apache pone a nuestra disposición para poder publicar más de una página web en un mismo servidor Apache, y que además,  nos permite mantener configuraciones diferentes para cada host virtual.

Al realizar una petición al servidor web, Apache puede identificar a que site (host virtual) queremos acceden en función de tres variables relacionadas con la solicitud realuzada al servidor:

1. La IP
2. El Host Name
3. El puerto

En este artículo distinguiremos los host virtuales por el puerto, pues es lo que utilizo habitualmente en mi entorno de desarrollo por una simple cuestión de comodidad.

Nociones de configuración

Toda la configuración de Apache 2 se encuentra bajo la carpeta /var/apache2. Los archivos de configuración para los virtual hosts se encuentran dentro de dos carpetas en particular:

1. /var/apache2/sites-available. En esta carpeta se encuentran todos los archivos de configuración de los hosts virtuales, cada host se corresponde con un archivo.
2. /var/apache2/sites-enabled. En esta carpeta se crearán enlaces simbólicos a los archivos de la carpeta sites-available para los host que queramos activar en cada momento.

Con la instalación de Apache, se creará por defecto, el archivo /etc/apache2/sites-available/000-default.conf y su correspondiente enlace simbólico en la carpeta sites-enabled que se encarga de configurar el host virtual por defecto al que accedemos tras instalar Apache.

Cómo crear un virtual host

Crear host virtuales es una tarea relativamente habitual, así que los señores desarrolladores de Apache nos lo han puesto bastante sencillo.

A continuación crearemos un host virtual para alojar un entorno de pruebas de este blog. Para entender mejor el proceso, a pesar de que es sencillo, lo dividiremos en cuatro pasos:

Paso 1: Creamos el directorio que alojará nuestra web

Lo primero será crear el directorio dónde alojaremos los archivos que posteriormente serviremos.

cd /var/www
sudo mkdir ahierro.es
cd ahierro.es
sudo mkdir public

La carpeta que serviremos será public, es buena idea guardarse un nivel de directorio para archivos relacionados con el proyecto que no deben ser accesibles desde una url en el navegador. Esto es bastante habitual en muchas aplicaciones y frameworks.

En este paso del proceso es importante dejar correctamente configurados los permisos de acceso a los archivos y carpetas de nuestro host virtual. Para ello os dejo un enlace al artículo Archivos y permisos de usuario en Apache 2 y Linux por si queréis echarle un vistazo.

Paso 2: Creamos el archivo de configuración del nuevo host virtual

Ahora crearemos el archivo de configuración en /etc/apache2/sites-available, lo más sencillo es hacerlo desde otro que ya exista. Es muy importante que lleve la extensión .conf o el comando a2ensite no funcionará más adelante:

cd /etc/apache2/sites-available
sudo cp 000-default.conf ahierro.es.conf

Lo editamos:

sudo vim ahierro.es.conf

Inicialmente tenemos algo así:

<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html

# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
</VirtualHost>

Y tras modificarlo debe quedar así:

<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com

ServerAdmin webmaster@localhost
DocumentRoot /var/www/ahierro.es/public

# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf

<Directory /var/www/ahierro.es/public>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>

</VirtualHost>

Como podemos ver en la línea 1 hemos cambiado :80 por :8085, con lo que estamos indicando que a este virtualhost accederemos mediante este puerto. Personalmente suelo comenzar con el puerto 8080, en este ejemplo he especificado el 8085 porque ya tengo otros cinco host virtuales.

En la línea 12 lo único que hemos hecho es actualizar la referencia al directorio raíz para asegurarnos que apunta al lugar adecuado.

Y por último hemos añadido una nueva sección a partir de la línea 30 con unas directrices básicas entre las que hemos habilitado el módulo mod_rewrite, necesario para la re-escritura de urls.

Paso 3: Abrimos el puerto adecuado en Apache

Por defecto Apache solo atiende solicitudes por el puerto 80. Para conseguir que también atienda las que llegan por el puerto 8085, que es el que hemos indicado en nuestro fichero de configuración del virtual host, debemos editar el archivo /etc/apache2/ports.conf.

sudo vim /etc/apache2/ports.conf

El contenido del fichero es algo así:

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen 80
Listen 8085

<IfModule ssl_module>
Listen 443
</IfModule>

<IfModule mod_gnutls>
Listen 443
</IfModule>

Vemos que la  línea 5 hace referencia al puerto 80, nosotros hemos añadido una línea más, la 6, indicándole que escuche también el puerto 8085.

Paso 4: Habilitamos el nuevo virtualhost

Si os habéis fijado hablamos de los directorios sites-available y sites-enabled, pero solo hemos trabajado con el primero. Para crear el enlace simbólico lo haremos con el comando a2ensite:

sudo a2ensite ahierro.es.conf

Y por si te lo estás preguntando, si, un ln o un cp servirían de igual manera. Y ahora que el enlace simbólico ya se encuentra en el directorio sites-enabled solo nos queda reiniciar apache:

sudo service apache2 restart

Paso 5: Comprobamos que todo funcione correctamente

Podemos comprobar que todo ha salido bien con dos sencillos pasos

1. Creamos un archivo index.html y lo guardamos en el directorio público del host virtual que acabamos de crear, en este caso /var/www/ahierro.es/public.
2. Accedemos a la ip del servidor seguida de dos puntos y el puerto: http://192.168.1.10:8085/index.html.

Si vemos el contenido del archivo index.html es que todo ha salido bien, en caso contrario deberemos buscar el problema en función del mensaje de error obtenido.

Conclusión

Una forma sencilla de organizar nuestros proyectos siempre que no sean demasiados.

Personalmente, en el virtual host por defecto (puerto 80),  creo un sencillo fichero con enlaces a todos los hosts virtuales y otros accesos directos que me interesa tener a mano como pueden ser phpmyadmin o phpinfo. Esto suele ahorrarme unos minutos preciados minutos cada día.

Y como siempre me gustaría saber tú opinión,  ¿utilizas los virtual host? ¿los identificas por puerto? ¿organizas tus proyectos de otra forma? Deja un comentario y aprendamos juntos.

Créditos, referencias y artículos relacionados

• Archivos y permisos de usuario en Apache 2 y Linux
• Ejecutar Linux en Windows 10 con WSL
• Servidor Web en Raspberry PI y Ubuntu Mate
• Clonar una web en un servidor local

Para este artículo asumiremos que disponemos de varios host virtuales y que vamos a asignar los permisos adecuados solo a uno de ellos. La carpeta raíz es /var/www/html y la pública /var/www/html/public.

En caso de que tengas un servidor Apache 2 recién instalado lo habitual es que las carpetas mencionadas en el párrafo anterior sean /var/www y /var/www/public respectivamente.

Por último antes de entrar en materia indicar que también asumiremos que el usuario con el que trabajamos es «usuario».

Asignamos los permisos

Comenzaremos asegurándonos de que /var/www/html pertenezca al grupo www-data:

sudo chgrp www-data /var/www/html

Nos aseguramos también que nuestro usuario pertenezca al mismo grupo:

sudo usermod -a -G www-data usuario

Asignamos los permisos adecuados:

sudo chmod -R 775 /var/www/html
sudo chmod -R g+s /var/www/html

Y por último nos aseguramos de ser los propietarios del directorio:

sudo chown -R usuario /var/www/html

En este punto ya tenemos los permisos de usuario correctamente configurados, pero como siempre es bueno comprobarlo.

Comprobamos que todo sea correcto

Para comprobar que todo haya salidos bien accedemos a /var/www y listamos los archivos con detalle:

ls -l

Deberíamos tener algo similar a lo siguiente:

total 2
drwxrwxr-x 4 usuario www-data 4096 dic 19 18:01 html
drwxrwxr-x 8 usuario www-data 4096 dic 19 18:07 vhost1

Los archivos y/o carpetas de este directorio pueden cambiar en función de lo que tengas en /var/www, pero al margen de eso podemos ver que tanto el usuario, el grupo y los perisos son correctos.

Si entramos dentro de /var/www/html y hacemos lo mismo el resultado debe ser similar.

Conclusión

Una tarea sencilla y rápida que nos ahorrará posibles complicaciones futuras. Y como siempre me gusta saber tu opinión, ¿qué haces distinto al establecer los permisos? ¿Te ha servido  este artículo para solucionar algún problema de permisos? ¿Cuál es tu experiencia en este tema?

Créditos, referencias y artículos relacionados

• Como configurar Virtual Hosts en Apache 2 y Ubuntu
• Servidor web en Raspberry Pi y Ubuntu Mate
• Debugar PHP con NetBeans y XCode

Esta entrada forma parte de la serie Raspberry Pi como herramienta de apoyo al desarrollo web, y está pensada para un servidor de uso personal. De cualquier manera, el contenido de esta guía es perfectamente aplicable a cualquier distribución de Linux basada en Ubuntu y a Raspbian.

Esta documento también puede utilizarse para la configuración de un servidor de una pequeña organización, en cuyo caso sería necesario tener en cuenta algunas consideraciones:

1. Una Rasperri Pi no es el hardware más adecuado. Debería instalarse sobre un hardware fiable y acordemente dimensionado a las necesidades del uso que se le dará.
2. Además del contenido de este artículo, deberían realizarse una serie de configuraciones extra enfocadas en la seguridad que no entran en el ámbito ni el alcance de este documento.
3. Este artículo esta pensado para la instalación y configuración de un servidor web en una red local, en caso de que el servidor sea accesible directamente desde internet, el punto anterior cobra mayor importancia, además de requerir algunos ajustes más.

Una vez que todos tenemos claro el ámbito y el alcance, vamos al lío.

Instalamos Apache 2

Este paso será muy sencillo, actualizamos los repositorios e instalamos Apache 2:

sudo apt-get update
sudo apt-get install apache2

Si todo ha ido bien ya podremos acceder al al servidor web desde cualquier pc conectado a la red local con tan solo introducir la ip en el navegador.

Para el resto de la entrada asumiremos que nuestra Raspberry está configurada con la IP estática 192.168.1.10.

Así que si introducimos en el navegador la dirección http://192.168.1.10  veremos la página por defecto de Apache 2:

Un aspecto muy importante en la configuración de Apache es asignar los permisos adecuados a la carpeta del servidor. Podemos pasar sin hacerlo pero más pronto que tarde nos encontraremos con problemas relacionados con permisos.

Comenzaremos asegurándonos de que /var/www/html pertenezca al grupo www-data y que tiene los permisos adecuados:

sudo chgrp www-data /var/www/html
sudo chmod 775 /var/www/html
sudo chmod g+s /var/www/html

Agregamos nuestro usuario al grupo www-data:

sudo usermod -a -G www-data usuario

Y por último nos aseguramos de ser los propietarios del directorio

sudo chown usuario /var/www/html

Con esto hemos concluido la instalación de Apache.

Instalamos PHP

Instalamos PHP:

sudo apt-get install php7.0

Es posible que en función de la distribución que utilicemos en lugar del paquete php7.0 encontremos otra versión. Podemos comprobarlo fácilmente con la siguiente orden:

sudo apt-cache search php

Y si por cualquier motivo necesitamos una versión específica de php, deberemos incluir el repositorio ondrej/php como hacemos a continuación:

sudo add-apt-repository -y ppa:ondrej/php
sudo apt-get update

En este caso he incluido la opción -y porque al intentar agregar el repositorio me mostraba un warning relacionado con la codificación de caracteres de los repositorios.

Acto seguido instalar la versión de php que necesitemos, en mi caso voy a instalar la versión 7.3:

sudo apt-get install php7.3

Tras reiniciar Apache ya habremos acabado:

sudo service apache2 restart

Para comprobar que php está correctamente instalado crearemos el archivo  /var/www/html/phpinfo.php con el siguiente contenido:

<?php php phpinfo(); ?>

Si todo es correcto al acceder a http://192.168.1.10/phpinfo.php veremos algo así:

Instalamos y configuramos MariaDB

Una vez que php está instalado, continuamos con la base de datos:

sudo apt-get install mariadb-server

Durante el proceso de instalación deberemos responder responder a algunas preguntas que sin complicación alguna.

El primer paso tras la instalación será configurar MariaDB para que podamos acceder remotamente, pues por defecto solo acepta conexiones desde el propio host:

sudo vim /etc/mysql/mariadb.conf.d/50-server.cnf

Esfe archivo puede cambiar en función de tu distribución y de la versión de MariaDB. En ocasiones puedes encontrarlo en /etc/mysql/my.cnf, en /etc/mysql/mysql.conf.d/mysqld.cnf, etc.

Localizamos la siguiente línea:

bind-address  = 127.0.0.1

La sustituimos por:

bind-address  = 0.0.0.0

Y reiniciamos la base de datos:

sudo service mysql restart

Con esto hemos habilitado el acceso remoto a MariaDB. Ahora crearemos un nuevo usuario para evitar trabajar con root. Para ello accedemos a la consola de MariaDB:

sudo mysql -u root -p

Una vez en la consola de MariaDB creamos nuestro usuario:

CREATE USER 'usuario' IDENTIFIED BY 'contraseña';

Y concedemos acceso remoto y a todas las bases de datos al usuario que acabamos de crear:

GRANT USAGE ON *.* TO 'usuario'@'%' IDENTIFIED BY 'contraseña';

En este punto es buena idea comprobar que todo ha salido bien. Podemos hacerlo abriendo una conexión al servidor de bases desde nuestro equipo de trabajo con alguna herramienta como MySQL Workbench.

Instalamos phpMyAdmin

Esta es una herramienta que siempre me gusta instalar a pesar de que en la mayoría de situaciones trabajo con MySql Workbenck. Para instalar basta con:

sudo apt-get install phpmyadmin

Y una vez instalado podremos acceder a ella mediante http://192.168.1.10/phpmyadmin.

Conclusión

Ya tenemos un servidor web completamente funcional corriendo sobre nuestra Rasperri PI, sencillo, económico y funcional. Ahora solo hay que usarlo.

¿Y tú?, ¿Crees que necesitamos aplicar alguna otra configuración? ¿Haces algo distinto? ¿Echas en falta algún paso? o simplemente ¿te ha servido de ayuda? Comparte tu experiencia y aprendamos todos.