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.

Y uno de esos valores que a veces se quedan cortos es la cantidad de memoria máxima que un script desarrollado en PHP puede consumir, así que hoy veremos como aumentar ese límite.

Fatal error: Allowed memory size of 134217728 bytes exhausted

Alcanzar el límite máximo de memoria de nuestro servidor no es algo demasiado habitual. La configuración por defecto tiene un valor lo suficientemente amplio como para que podamos ejecutar la mayoría de las aplicaciones sin problema alguno. Pero en caso de alcanzarlo,el sistema devuelve el siguiente error:

Fatal error: Allowed memory size of 134217728 bytes exhausted

Con la salvedad de que el número de bytes puede variar en función de la configuración del servidor.

Medida de protección

Que PHP disponga de un límite máximo de consumo de memoria en la ejecución de cada script es una medida de protección, no olvidemos que la memoria en una máquina es un recurso finito. Así que antes de ampliar este parámetro, mi consejo es que nos aseguremos de que:

1. No es un bug en nuestro script el que crea la necesidad de ampliar la memoria.
2. Nuestro script está razonablemente optimizado.

Es decir, nada que no debamos hacer con cualquier otro script que no supere el límite máximo de memoria definido. Porque si recordáis una de las primeras lecciones que aprendemos (o al menos que deberíamos aprender) al comenzar a programar es que nuestro código debe cumplir tres requisitos fundamentales:

1. Estar libre de errores
2. Ser eficiente
3. Ser comprensible

Cómo aumentar el límite máximo de memoria para un script PHP

Por defecto, el límite máximo de memoria que un script PHP puede consumir es de 128Mb, algo más que razonable. Si ya tenemos claro que queremos aumentar este límite podemos hacerlo de dos formas.

Con la función init_set()

Con la función init_set() pasando el string memory_limit como primer parámetro y la cantidad de memoria deseada como segundo. Con este método, el nuevo limite afectará única y exclusivamente al script dónde lo estemos utilizando, es decir, sin afectar a la configuración general del servidor.

<?php

ini_set('memory_limit', '256M');

...

?>

En el archivo php.ini

En este caso, la principal diferencia con respecto al método anterior es que el nuevo límite afectará a todos los scripts PHP que se ejecuten en el servidor dónde apliquemos esta configuración. Para definir el nuevo límite, buscamos la directriz memory_limit, dentro de la sección Resources Limits, en el archivo php.ini y modificamos su valor.

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;

...

; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit=256M

Y acto seguido reiniciamos el servidor Apache 2 para que los cambios surtan efecto.:

sudo service apache2 restart

La ubicación del archivo php.ini variará en función del sistema que estemos utilizando. En los sistemas Linux basados en Debian como Ubuntu la ubicación será /etc/php/X.X/apache2, donde X.X será la versión de PHP.

Comprobar límite máximo de memoria de un script PHP

Podemos comprobar el valor máximo de memoria que utiliza un script configurado en nuestro servidor en la sección Core de la salida de la función phpinfo():

O como acabamos de ver, accediendo al archivo de configuración php.ini:

Créditos, referencias y artículos relacionados

• Imagen de portada: Public Domain Pictures
• Aumentar el limite de tiempo máximo de ejecución de un script en PHP.
• Documentación de la función php init_set()
• 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

Algunos de ellos pueden ser: la memoria consumida en la ejecución del script, el tamaño de los archivos subidos al servidor, el número de variables pasadas por get o por post, etc.

En esta estrada hablamos sobre el límite de tiempo de ejecución de un script.

Fatal error: Maximum execution time of 30 seconds exceeded

Este es el error que nos encontraremos si nuestro script sobrepasa el tiempo máximo de ejecución definido.

Encontrarnos con este error no es una situación excesivamente habitual y en muchos casos puede ser el resultado de un error de programación, como por ejemplo una rutina que nos haga entrar en un bucle infinito.

Pero también es posible alcanzar ese límite por las propias exigencias de nuestro software. En mi caso, me he encontrado con esta situación al desarrollar aplicaciones empresariales que procesan una gran cantidad de datos.

Medida de protección

Que PHP disponga de un límite máximo de tiempo de ejecución para los scripts es una medida de protección que puede librarnos de largas esperas e incluso de algún reinicio. La experiencia me dice que en algunas ocasiones un bucle infinito puede dejar un equipo completamente bloqueado.

Así que antes de ampliar el tiempo máximo de ejecución mi consejo es que nos aseguremos de que:

1. No es un bug en nuestro script el que crea la necesidad de ampliar este tiempo.
2. Nuestro script está razonablemente optimizado.

Es decir, nada que no debamos hacer con cualquier otro script que no supere el tiempo de ejecución máximo.

Cómo aumentar el límite el tiempo de ejecución de un script PHP

Por defecto, el tiempo máximo de ejecución de un script es de 30 segundos. Si ya tenemos claro que queremos aumentar este tiempo podemos hacerlo de varias formas.

Con la función set_time_limit()

Utilizaremos esta función al comienzo de nuestro script definiendo el tiempo máximo de ejecución en segundos. Por lo tanto, con este método el nuevo limite afectará única y exclusivamente al script dónde lo utilicemos.

<?php

set_time_limit(60);

...

?>

Debemos puntualizar que en caso de que estemos utilizando php en modo seguro esta función no tendrá ningún efecto.

Con la función init_set()

Este sistema funciona exactamente igual que set_time_limit(), con la única diferencia que utilizaremos la función init_set() pasando el string max_execution_time como primer parámetro.

<?php

ini_set('max_execution_time', 60);

...

?>

En el archivo php.ini

En este caso, la principal diferencia entre este método y los dos anteriores es que el nuevo límite afectará a todos los scripts PHP que se ejecuten en el servidor dónde apliquemos esta configuración. Para aplicarlo, buscamos la directriz max_execution_time, dentro de la sección Resources Limits, en el archivo php.ini y modificamos su valor.

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;

; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time = 60

Y acto seguido reiniciamos el servidor Apache 2 para que los cambios surtan efecto.:

sudo service apache2 restart

La ubicación del archivo php.ini variará en función del sistema que estemos utilizando. En los sistemas Linux basados en Debian como Ubuntu la ubicación será /etc/php/X.X/apache2, donde X.X será la versión de PHP.

En el archivo .htaccess

Esta es quizás la opción menos conocida de las que mostramos en esta entrada, pero es una de las más interesante en cuanto a que podemos conseguir que la nueva directriz aplique a todos los scripts cuando no tenemos acceso al archivo php.ini.

Para aplicar este sistema editaremos el archivo .htaccess que nos interese incluyendo las siguientes líneas:

<IfModule mod_php7.c>
php_value max_execution_time 60
</IfModule>

Si nuestro servidor utiliza una versión 5.X de PHP en lugar de una versión 7.X, solo habría que cambiar mod_php7.c por mod_php5.c.

Cómo comprobar el valor de tiempo máximo de ejecución

Podemos comprobar el valor de tiempo máximo de ejecución configurado en nuestro servidor en la sección Core de la salida de la función phpinfo():

O como acabamos de ver, accediendo al archivo de configuración php.ini:

Créditos, referencias y artículos relacionados

• Imagen de portada: Michael Jarmoluk
• Documentación de la función php set_time_limit()
• Documentación de la función php init_set()
• 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

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.

Otra de esas posibilidades de las que hablamos es realizar el respaldo con PHP, lo que nos permitirá hacerlo con casi todos los hostings, además de que es fácilmente automatizable. La principal desventaja, por contra, es que es una opción algo más laboriosa, pues tendremos que programar el script. Pero como la rueda casi siempre está inventada, en internet tienes muchas soluciones que te facilitarán la labor.

MySQL BackUp Lite

Yo os propongo esta sencilla solución que he desarrollado, de la que os dejo el código a continuación. En cualquier momento puedes acceder a la versión más actualizada de MySQL Backup Lite en Github.

/**
*
* MySql Backup Lite Class
*
* @author     Andres Hierro
* @copyright  2019 Andres Hierro
* @license    http://www.apache.org/licenses/LICENSE-2.0  Apache License, Version 2.0
* @version    0.0.1
* @link       http://ahierro.es/
*
*
*
* Copyright 2019 Andrés Hierro
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*     http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/

class MySqlBackupLite {

  private $host;
  private $user;
  private $pass;
  private $name;

  private $fileName = "mySqlBackup.sql";
  private $fileDir = "./";
  private $fileCompression = false;

  private $timeZone = '+00:00';

  private $mySqli;
  private $sqlString = "";
  private $arrayTables;

  private $tableFieldCount = 0;
  private $tableNumberOfRows = 0;
  private $queryResult;



  public function __construct(array $arrayConnConfig) {

      if (
        (!isset($arrayConnConfig['host'])) ||
        (!isset($arrayConnConfig['user'])) ||
        (!isset($arrayConnConfig['pass'])) ||
        (!isset($arrayConnConfig['name']))
      ) {
          throw new Exception('Missing connection data.');

      }
      $this->setHost($arrayConnConfig['host']);
      $this->setUser($arrayConnConfig['user']);
      $this->setPass($arrayConnConfig['pass']);
      $this->setName($arrayConnConfig['name']);

  }



  public function backUp() {

    $this->connectMySql();
    $this->getTables();
    $this->generateSqlHeader();
    $this->createTableStaments();
    $this->insertStaments();
    $this->generateSqlFooter();

  }



  private function setHost($host) {
    $this->host = $host;
  }



  private function setUser($user) {
    $this->user = $user;
  }



  private function setPass($password) {
    $this->pass = $password;
  }



  private function setName($name) {
    $this->name = $name;
  }



  public function setFileName($name) {
    $this->fileName = $name;
  }



  public function setFileDir($dir) {
    $this->fileDir = $dir;
  }



  public function setFileCompression($compression) {
    $this->fileCompression = $compression;
  }



  private function connectMySql() {

    $this->mySqli = new mysqli($this->host, $this->user, $this->pass, $this->name);
    $this->mySqli->select_db($this->name);
    $this->mySqli->query("SET NAMES 'utf8'");

  }



  private function getTables() {

    $queryTables = $this->mySqli->query('SHOW TABLES');
    while($row = $queryTables->fetch_row()) {
      $this->arrayTables[] = $row[0];
    }

  }



  private function generateSqlHeader() {

    $this->sqlString  = 'SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";' . "\r\n";
    $this->sqlString .= 'SET time_zone = "' . $this->timeZone . '";' . "\r\n\r\n\r\n";
    $this->sqlString .= '/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;' . "\r\n";
    $this->sqlString .= '/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;' . "\r\n";
    $this->sqlString .= '/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;' . "\r\n";
    $this->sqlString .= '/*!40101 SET NAMES utf8 */;' . "\r\n";
    $this->sqlString .= '--' . "\r\n";
    $this->sqlString .= '-- Database: `' . $this->name . '`' . "\r\n";
    $this->sqlString .= '--' . "\r\n\r\n\r\n";

    return;

  }



  private function createTableStaments() {

    foreach($this->arrayTables as $table){
      $this->sqlCreateTableStament($table);
    }

  }



  private function sqlCreateTableStament($table) {

    $res = $this->mySqli->query('SHOW CREATE TABLE '.$table);
    $temp = $res->fetch_row();
		$this->sqlString .= "\n\n" . str_ireplace('CREATE TABLE `','CREATE TABLE IF NOT EXISTS `', $temp[1]) . ";\n\n";

  }



  private function insertStaments() {

    foreach($this->arrayTables as $table){
      $this->sqlInsertStaments($table);
    }

  }



  private function sqlInsertStaments($table) {

		$this->getTableData($table);

    if($this->tableFieldCount == 0) {
      return;
    }


    $i = 0;
		while($row = $this->queryResult->fetch_row())	{

      $this->insertResultHeader($table, $i);
      $this->insertSingleResult($row);

      $i++;
      $this->sqlString .= (($i != 0) && ($i % 100 == 0) || ($i == $this->tableNumberOfRows)) ? ";" : ",";

		}

    $this->sqlString .= "\n\n\n";

  }



  private function getTableData($table) {

  	$this->queryResult	= $this->mySqli->query('SELECT * FROM `' . $table . '`');
    $this->tableFieldCount = $this->queryResult->field_count;
    $this->tableNumberOfRows = $this->mySqli->affected_rows;

  }



  private function insertResultHeader($table, $currentRowNumber) {

  	if ($currentRowNumber % 100 == 0 || $currentRowNumber == 0 )	{
      $this->sqlString .= "\nINSERT INTO " . $table . " VALUES";
    }

  }



  private function insertSingleResult($row) {

    $this->sqlString .= "\n(";

    for($i = 0; $i < $this->tableFieldCount; $i++){

      $row[$i] = str_replace("\n","\\n", addslashes($row[$i]));

      $this->sqlString .= (isset($row[$i])) ? '"'.$row[$i].'"' : '""';
      if($i < ($this->tableFieldCount-1)){
        $this->sqlString.= ',';
      }

    }

    $this->sqlString .=")";

  }



  private function generateSqlFooter() {

    $this->sqlString .=  "\r\n\r\n";
    $this->sqlString .=  '/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;';
    $this->sqlString .=  "\r\n";
    $this->sqlString .=  '/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;';
    $this->sqlString .=  "\r\n";
    $this->sqlString .=  '/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;';

  }



  public function downloadFile() {

      ob_get_clean();
      header('Content-Type: application/octet-stream');
      header("Content-Transfer-Encoding: Binary");
      header('Content-Length: '. (function_exists('mb_strlen') ? mb_strlen($this->sqlString, '8bit'): strlen($this->sqlString)) );
      header("Content-disposition: attachment; filename=\"".$this->fileName."\"");
    	echo $this->sqlString; exit;

  }



  public function saveToFile() {

    if (!$backupFile = fopen($this->fileDir . $this->fileName, "w+")) {
        throw new Exception('Imposible to create file.');
    }
    fwrite($backupFile, $this->sqlString);
    fclose($backupFile);

  }


}

Realizar la copia de seguridad

La solución propuesta nos proporciona dos opciones que podemos utilizar según nuestras necesidades:

1. Realizar el backup y descargarlo.
2. Realizar el backup y guardarlo en un archivo.

En ambos casos incluimos la clase y le pasaremos al método constructor los datos de la conexión a la base de datos en un array como el que ves a continuación:

include('MySqlBackup.php');

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

Respaldar y descargar

Para realizar el backup y descargarlo serán suficientes unas pocas líneas:

try {

  $bck = new MySqlBackupLite($arrayDbConf);
  $bck->backUp();
  $bck->downloadFile();

}
catch(Exception $e) {

  echo $e;

}

Respaldar y guardar en un archivo

Para guardar el resultado en un archivo además deberemos de indicarle el nombre del archivo y el directorio dónde guardarlo.

try {

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

}
catch(Exception $e) {

  echo $e;

}

Solo una parte del proceso

Pero en muchas situaciones, este respaldo sera solo una parte del proceso. Nosotros hemos propuesto un escenario mayor en el que clonamos nuestra web en un servidor local, en breve publicaremos el artículo.

Créditos y rerefencias

• Imagen principal: Tumisu en Pixabay.
• Solución Mysql Backup Lite: Andrés Hierro, github.

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.