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

Personalmente lo utilzo con relativa frecuencia, generalmente con el cliente FileZilla, un cliente FTP multiplataforma de código abierto muy recomendable. Y siendo honestos, hasta la escritura de esta entrada, mi desconocimiento sobre los modos de conexión activo o pasivo era absoluto, algo que intuyo que le sucede a mucha gente, y ya se sabe que mal de muchos consuelo de tontos entrada en el blog.

FTP, FTPS y SFTP.

Recordemos que existen tres protocolos distintos a los que solemos referirnos cuando hablamos de FTP: FTP, FTPS y SFTP. Si tienes dudas sobre alguno de ellos puedes echarle un vistazo a la entrada FTP, FTPS y SFTP: diferencias, ventajas e inconvenientes.

Pues bien, los modos activo o pasivo solo aplican sobre los protocolos FTP y FTPS, en ningún caso sobre SFTP, pues es un protocolo que dista bastante de los dos anteriores.

Puerto de datos y puerto de control

Otro aspecto clave que debemos conoce para entender el funcionamiento del FTP es que trabaja sobre dos puertos distintos: el puerto de datos y el puerto de comandos o puerto de control.

Los nombres son bastante auto-explicativos, el puerto de datos se encarga de la transmisión de los ficheros y el puerto de control de las instrucciones entre ambos host. Se diseñó así para poder enviar comandos sin la necesidad de detener la transmisión de datos ni de encolarlos tras estos.

Si nos centramos en el servidor, tradicionalmente el puerto de control ha sido el 21 y el puerto de datos varía en función del modo, siendo el 20 para el modo activo, y un puerto aleatorio para el modo pasivo.

En el lado del cliente, en cambio, el puerto de control será un puerto aleatorio P superior a 1023, y el puerto de datos será P+1. Esto es así tanto en el modo activo, como en el pasivo.

Pero veamos cada uno de los modos en detalle para entenderlo mejor.

FTP activo

Es el modo predeterminado para las conexiones FTP, de hecho fue el primero en desarrollarse. En este modo el servidor utilizará el puerto 20 para la transferencia de datos, mientras que transmitirá los comandos utilizando el puerto 21. El cliente en cambio utilizará un puerto aleatorio P superior al 1023 para la transferencia de comandos, y un puerto P+1 para la transferencia de datos.

Secuencia de conexión del modo activo

La secuencia de conexión del modo activo es la siguiente:

1. El cliente FTP comienza la conexión dese un puerto de control aleatorio P con destino al puerto 21 del servidor. Como hemos mencionado el puerto P será superior a 1023.
2. El servidor responde desde el puerto de control.
3. El servidor inicia entonces la conexión del canal de datos: puerto 20 para el servidor y puerto P+1 para el cliente.
4. El cliente responde desde el puerto de datos estableciendo así la conexión.

Inconvenientes del modo activo

Históricamente el principal inconveniente de este modo ha radicado en que si no hay una directiva específica en los firewalls del lado del cliente, la conexión es propensa a ser bloqueada. Esto se debe a que, como hemos visto, existen dos conexiones independientes: una de salida en la que el cliente establece la conexión del canal de control y otra de entrada en la que el servidor hace lo propio con el de datos. Esta última conexión es iniciada por el servidor en el puerto previamente negociado, y en ocasiones es bloqueada por el firewall del cliente al ser identificada como un intento de conexión externa no autorizada.

Recordemos que este sistema se diseñó en los años 70, cuando la democratización de los sistemas informáticos y los problemas de seguridad eran completamente distintos a los que podemos encontrar hoy en día.

Sea como sea, en todos los años que llevo utilizando el protocolo FTP desde el rol de cliente, no recuerdo haber experimentado nunca problemas de este tipo, y habré conectado con varias decenas de servidores de muchos proveedores distintos. Entiendo que esto se deba a la sofisticación de los sistemas de red y de seguridad más modernos.

FTP pasivo

El modo de FTP pasivo surge como consecuencia de los problemas de conexión del modo activo. Este modo mantiene los dos canales (control y datos) pero en este caso es el cliente el encargado de establecer las dos conexiones.

El servidor sigue manteniendo el puerto 21 como puerto de comandos, el puerto de datos en cambio difiere del modo activo y pasa a ser un rango de puertos Q superior a 1023. Del lado del cliente seguimos manteniendo el puerto P superior a 1023 para control, y el puerto P+1 para datos.

Secuencia de conexión del modo pasivo

La secuencia de conexión del modo pasivo es la que sigue a continuación:

1. El cliente FTP comienza la conexión dese un puerto de control aleatorio P con destino al puerto 21 del servidor.
2. El servidor responde desde el puerto de control.
3. El cliente inicia la conexión del canal de datos dese el puerto P+1 hacia el puerto Q del servidor.
4. El servidor responde desde el puerto de datos estableciendo así la conexión.

Como ves, los pasos uno y dos son iguales que en el modo activo, y es en los pasos tres y cuatro dónde vemos como se invierten los roles y es el cliente el que inicia la conexión de datos.

Inconvenientes del modo pasivo del FTP

El principal inconveniente de habilitar el modo pasivo en un servidor FTP está asociado con el riesgo extra en materia de seguridad que conlleva la apertura de un rango de puertos extra con respecto al modo activo. Notemos que para que el modo pasivo funcione adecuadamente estos puertos deben ser abiertos tanto en el servidor como en el firewall.

Para minimizar este riesgo la estrategia pasa por definir un rango de puertos lo más pequeño posible en función del número de conexiones concurrentes que esperemos tener, pero ojo, porque un cliente no se corresponde con una única conexión, es muy probable que cada cliente abra múltiples conexiones concurrentes.

Resumen

Para cerrar esta entrada os dejo una tabla con el resumen de lo que hemos visto.

Créditos, referencias y artículos relacionados

• Imagen de portada por Michal Jarmoluk en Pixabay
• FTP, FTPS y SFTP: diferencias, ventajas e inconvenientes
• VSFTP instalar y configurar un servidor FTP en una Raspberry Pi con Ubuntu
• FTPS o cómo habilitar SSL en vsftp
• Usuarios virtuales en vsftp

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.

Mi experiencia con los triggers proviene principalmente de SQL Server, plataforma en la que he hecho un uso bastante extenso de ellos, y me atrevería a asegurar que para algunos programadores, en según que condiciones, los triggers pueden abrir un mundo nuevo de posibilidades, facilitando enormemente la realización de algunas tareas que de no ser por éstos tendrían una resolución bastante más aparatosa.

Qué son los triggers en MySQL

Los triggers (o desencadenadores) son pequeños programas creados por el usuario que se invocan de forma automática por el propio motor de bases de datos al producirse ciertos eventos, lo que nos permite capturarlos, controlarlos e intervenir en ellos.

En MySQL los eventos que podemos capturar son los relacionados con las sentencias INSERT, UPDATE y DELETE.

Precauciones en el uso de triggers

Antes de entrar de lleno con ellos, es importante conocer cuales son los inconvenientes más comunes derivados de su uso para así evitarlos o cuanto menos minimizarlos.

El primero de ellos es el rendimiento. Ejecutar el código programado en el trigger conlleva un consumo de recursos que por norma general suele ser muy superior al de la sentencia que lo origina. Por lo tanto deberemos tener en cuenta esa carga y optimizarla para evitar posibles problemas como ralentización del sistema o interbloqueos.

El segundo inconveniente a tratar es la visibilidad. Hablamos de una porción de código que se encuentra completamente separada del resto, lo que en ocasiones puede provocar que nos olvidemos que está ahí, o que lo desconozcamos por completo si nos enrolamos en un nuevo proyecto.

Y una recomendación derivada del punto anterior, es poner un extra de atención para asegurar su correcto funcionamiento, o de lo contrario podemos encontrarnos con resultado indeseados mucho tiempo después de su activación.

Por último debemos destacar el efecto global de los triggers, que actuarán siempre que ocurra el evento para el que han sido definidos, independientemente de la aplicación, usuario o cualquier otra variable de sistema que se nos ocurra. Esta condición es intrínseca los triggers y es básicamente lo que buscamos, pero debemos recordarlo si en algún momento actuamos sobre la base de datos desde un lugar diferente al habitual.

Cuándo utilizar triggers

Desde mi punto de vista los triggers tienen dos escenarios principales de uso:

El primero es cuando no podemos intervenir en el código fuente de la aplicación que trabaja sobre la base de datos sobre la que queremos actuar o reaccionar a sus eventos.

El segundo es cuando a pesar de disponer del código, éste pertenece a un software desarrollado por terceros y existe una probabilidad relativamente alta de aplicar actualizaciones o instalar pluggins, y hemos decidido modificar el código fuente lo menos posible para facilitar este tipo de tareas.

Un ejemplo muy habitual son integraciones de software en las que al menos uno de los programas que intervienen es de código cerrado. En este tipo de situaciones los triggers nos permiten capturar los eventos que modifican la base de datos y actuar en consecuencia, evitando crear tareas programadas y e incluso tablas de integración.

Cuándo no utilizar trigger

Cuando tenemos acceso al código fuente de la aplicación que trabaja sobre la base de datos que nos interesa y no tenemos que mantener ningún tipo de compatibilidad con cambios como nuevas versiones, no existe razón alguna para utilizar triggers. En estos casos será mejor trabajar sobre el código de la aplicación y así evitaremos los inconvenientes de uso de los triggers.

Bien sea para registrar logs de acciones, generar registros de integración, realizar validaciones pre o post inserción o cualquier otra tarea que se nos ocurra, siempre será más eficiente, más visible y por lo tanto sencillo para el programador delegar esa responsabilidad en la propia aplicación.

Usando los triggers

Muy bien, ya hemos tomado las consideraciones necesarias y hemos decidido utilizar triggers, veamos ahora cómo crearlos.

Sentencias sobre las que podemos crear triggers

Ya lo adelantábamos al comienzo del artículo, podemos crear triggers que actúen sobre las sentencias:

• INSERT
• UPDATE
• DELETE

De esta forma podremos intervenir cada vez que se inserte, modifique o elimine un registro.

Cada trigger se define para un tipo de evento, de forma que si queremos controlar los tres eventos para una determinada tabla deberemos crear tres triggers.

También es importante mencionar que los triggers actúan registro a registro, es decir, supongamos que tenemos una sentencia UPDATE que modifica 100 registros, el trigger se ejecutará 100 veces, una por cada registro modificado

BEFORE y AFTER

Y como complemento al tipo de sentencia, podemos decidir si intervenir antes o después de que ésta realice los cambios. Así un trigger AFTER INSERT nos permitirá actuar una vez que el nuevo registro este insertado, y un trigger BEFORE DELETE lo hará antes de eliminar un registro.

La combinación del tipo de sentencia con BEFORE o AFTER nos ofrecen mucha versatilidad a la hora de diseñar nuestros triggers.

NEW y OLD

NEW y OLD son las palabras reservadas de MySQL para acceder a los valores de los registros sobre los que estamos trabajando.

• OLD nos permite acceder a los datos previos a la modificación realizada por la sentencia.
• NEW nos permite acceder a los nuevos datos que propone la sentencia.

La sintaxis es muy sencilla, OLD.campo o NEW.campo, dónde campo es el nombre del campo de la tabla al que queremos acceder.

Cómo crear un trigger en MySQL

Y una buena forma de aprender a crear un triggers es mediante un ejemplo, así que veamos uno. Supongamos que tenemos la tabla brands que forma parte de la base de datos de un software propietario:

+----+----------+---------+
| ID | Name     | Segment |
+----+----------+---------+
|  1 | Opel     | Mass    |
|  2 | Renault  | Mass    |
|  3 | Ford     | Mass    |
|  4 | Audi     | Premium |
|  5 | Mercedes | Premium |
|  6 | Porche   | Luxury  |
|  7 | Ferrari  | Luxury  |
+----+----------+---------+

Y queremos registrar los cambios que se producen para integrarlos con otro sistema, para lo que hemos creado una tabla en la que registraremos cualquier cambio que se produzca en la tabla brands. La nueva tabla la hemos llamado integration, y tiene los siguientes campos:

+----+--------+----------+--------+---------------------+-----------+---------------+------------+
| ID | Object | ObjectID | Action | DateCreated         | Processed | DateProcessed | ErrorCount |
+----+--------+----------+--------+---------------------+-----------+---------------+------------+

Para registrar todos los cambios que se produzcan en la tabla brands deberemos generar tres triggers:

• Uno para registrar los nuevos registros: AFTER INSERT.
• Uno para registrar los cambios: AFTER UPDATE.
• Uno para registrar las eliminaciones: BEFORE DELETE.

En esta entrada crearemos únicamente el trigger para la sentencia INSERT. Crear el resto de triggers se hace de forma muy similar, y en caso de que estés interesado en aprender será una buena práctica.

Así que veamos como crear el trigger, que será el encargado de registrar las nuevas marcas:

delimiter //
CREATE TRIGGER brandsInsertLog AFTER INSERT ON brands
FOR EACH ROW
BEGIN

	INSERT INTO integration (`Object`, `ObjectID`, `Action`, `DateCreated`, `Processed`, `DateProcessed`, `ErrorCount`) 
	VALUES ('brands', NEW.ID, 'insert', now(), 0, null, 0);

END;//
delimiter;

De forma que si ejecutásemos una sentencia de de inserción sobre la tabla brands:

INSERT INTO `osticket`.`brands` (`ID`, `Name`, `Segment`)
VALUES (8, 'Citroen', 'Mass');

Se registraría automáticamente la entrada correspondiente en la tabla integration:

+----+--------+----------+--------+---------------------+-----------+---------------+------------+
| ID | Object | ObjectID | Action | DateCreated         | Processed | DateProcessed | ErrorCount |
+----+--------+----------+--------+---------------------+-----------+---------------+------------+
|  1 | brands |        8 | insert | 2019-09-21 08:20:07 |         0 | NULL          |          0 |
+----+--------+----------+--------+---------------------+-----------+---------------+------------+

Así de sencillo. Espero que esta entrada te haya servido de ayuda y si es así un comentario siempre es de agradecer.

Créditos, referencias y artículos relacionados

• Imagen Peggy und Marco Lachmann-Anke en pixabay.
• Documentación sobre triggers de María DB
• Documentación sobre triggers de MySQL
• Backup de base de datos MySQL con PHP
• Servidor Web en Raspberry PI y Ubuntu Mate

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

El error es muy similar a este otro «E: No se pudo bloquear /var/lib/apt/lists/lock – open (11 Recurso no disponible temporalmente)«, y es fácil confundirlos si no prestamos la atención suficiente. Ambos ocurren cuando realizamos tareas de instalación o des-instalación de software, la diferencia radica en que mientras uno está relacionado con Apt, el otro está relacionado con Dpkg.

El error

El error se produce al intentar instalar o des-instalar alguna aplicación. Cuando el sistema hace uso del gestor de paquetes Dpkg, y éste intenta bloquear los recursos necesarios para realizar sus tareas, se encuentra que estos ya están bloqueados y lanza el siguiente error:

E: No se pudo bloquear /var/lib/dpkg/lock - open (11 Recurso no disponible temporalmente)
E: Unable to acquire the dpkg No se pudo bloquear el directorio (/var/lib/dpkg/), ¿quizás haya algún otro proceso utilizándolo?

Es bastante habitual que ese bloqueo esté producido por algún problema en operaciones anteriores, y que en el momento de encontrarnos con el error no exista ningún proceso activo utilizando esos recursos. No obstante debemos asegurarnos de ello.

La solución

La solución es rápida y sencilla. Como hemos dicho, comenzamos comprobando si existe algún proceso activo utilizando el archivo que genera el bloqueo:

sudo fuser -v /var/lib/dpkg/lock

En caso de que haya algún proceso activo provocando el bloqueo deberemos decidir si lo dejamos terminar o si por el contrario lo matamos, mi recomendación es ser razonablemente pacientes. Si optamos por matarlo, volveremos a hacer uso del comando fuser, añadiendo dos modificadores más:

sudo fuser -vki /var/lib/dpkg/lock 

Si era un proceso el causante del y este ha concluido su tarea, lo más probable es que el error ya no persista.

Si por el contrario no había proceso activo, o lo había pero decidimos matarlo, deberemos eliminar el archivo que sigue generando el bloqueo:

sudo rm /var/lib/dpkg/lock

Y con esto ya habremos terminado y podremos realizar la tarea que no pudimos inicialmente.

El caso es que en los últimos meses me he encontrado en varias ocasiones con el error del título, y con este otro «No se pudo obtener el bloqueo /var/lib/dpkg/lock – open (recurso temporalmente no disponible)«, que es tan parecido que si no leemos atentamente puede llevarnos a errar en el diagnóstico del problema. Y si bien las soluciones son prácticamente iguales, los detalles distan mucho, y podríamos estar intentando curar un catarro con las medicinas para curar una gastroenteritis. Pero no me enrollo mas y vayamos al lío.

El error

El error se produce al intentar actualizar los repositorios o realizar otras tareas relacionadas con el gestor de paquetes Apt, y la salida en pantalla completa es la siguiente:

E: No se pudo bloquear /var/lib/apt/lists/lock - open (11 Recurso no disponible temporalmente)
E: No se pudo bloquear el directorio (/var/lib/apt/lists/)

El origen del problema radica en que intentamos acceder a un recurso que está bloqueado por otro proceso. Lo más habitual es que ese otro proceso ya no exista, y que el recurso que necesitamos haya quedado bloqueado por algún problema en una operación anterior. No obstante, es mejor ser cautos y verificar si ese bloqueo esté motivado por una algún proceso activo.

La Solución

La solución al problema es rápida y sencilla. En primer lugar comprobamos si existe algún proceso utilizando el archivo que genera el bloqueo:

sudo fuser -v /var/lib/apt/lists/lock 

En caso de que haya algún proceso, deberemos decidir si lo dejamos terminar o si lo matamos. Si optamos por matarlo, podemos hacerlo con el mismo comando fuser, tan solo añadiendo algunos modificadores más:

sudo fuser -vki /var/lib/apt/lists/lock 

Y acto seguido, e independientemente de si había o no un proceso activo, eliminamos el archivo que provoca el bloqueo:

sudo rm /var/lib/apt/lists/lock

Y con esto ya podríamos volver a actualizar nuestros repositorios o realizar la tarea que no pudimos completar al encontrarnos con este inconveniente.

El caso es que tengo un pc (o tablet) Microsoft Surface Pro 1 en el que tenía instalado Windows 10. La verdad es que esa combinación funciona muy bien para el uso que hago de este dispositivo: consultas varias en internet, escribir este blog, sincronizar algún gadget, etc., en fin, un uso lúdico y poco intensivo. Pero desde hace ya algún tiempo rondaba por mi cabeza la idea de probar cómo iría con alguna distribución de Linux.

Microsoft Surface Pro 1

Para aquellos que no conozcan este dispositivo os dejo una pequeña presentación. El equipo tiene ya algunos añitos, concretamente 6, salio a la venta en 2012 pero yo lo adquirí en 2013. Tiene un procesador Intel Core I5-3317U con dos cores a 1.70GHz, 4GB de memoria RAM, 128GB de disco duro SSD y una pantalla de 10,6 pulgadas con una resolución de 1920×1080.

En la practica es un equipo pesado en relación a su tamaño, se calienta demasiado y su batería difícilmente duraba dos horas con Windows 8 o con Windows 10.

Elección de distribución

En mi ordenador personal utilizo Xubuntu, y estoy muy contento con esta distribución, de hecho me siento mucho más cómodo con su escritorio Xfce que con GNOME o KDE, así que fue mi primera opción. Pero tras probarlo desde un live usb lo descarté sobre la marcha, el teclado en pantalla no aparecía por defecto, y aunque sé que podría encontrar alguno en los repositorios, digamos que lo tomé como un presagio y no tenía ganas de buscarme complicaciones.

La segunda opción fue Ubuntu 19.04, también desde live usb. En este caso el teclado en pantalla apareció desde que situé el foco en un cuadro de texto. Y aunque en ese momento existían algunos detalles que no me convencían, la existencia de apartados dedicados a la configuración de accesibilidad para ratón y teclado, unido al teclado en pantalla me convencieron. Así que me despedí de Windows e instalé Ubuntu, un HD de 128GB no es territorio para que convivan dos sistemas operativos.

Experiencia con Ubuntu en dispositivos táctiles

Y ahora que ya os he soltado la chapa, vamos a revisar los aspectos que considero más relevantes de mi experiencia con Ubuntu en la tablet Microsoft Surface.

Teclado en pantalla

Ubuntu Desktop tiene el teclado en pantalla instalado por defecto, así que podremos utilizarlo tanto ejecutando la distro desde el live usb como en el proceso de instalación, y por supuesto una vez instalado en nuestro equipo.

El teclado en pantalla está estéticamente bien logrado y no me resulta nada intrusivo en el despliegue, es más estos dos puntos me parecen sensacionales. Su funcionamiento es bueno, salvo al escribir en la barra de direcciones de Firefox que tiene un comportamiento errático. Este problema no lo he notado en ningún otro programa.

El principal inconveniente con este teclado es que es excesivamente sencillo, no dispone de teclas de dirección, ni de teclas de función (F1, F2…), ni de teclas de control (Alt, Ctrl, Esc…). Parece pensado para utilizarse en una tablet tipo Android más que en un pc.

Esto me ha obligado a instalar un segundo teclado en palla para solventar las situaciones en las que necesito hacer uso de alguna de las teclas de las que no dispongo, algo que me resulta muy engorroso.

Este teclado auxiliar se llama Florence Virtual Keyboard, y está muy bien para salir del paso, pero personalmente no me convence como teclado principal. Si quieres instalarlo:

sudo apt-get update
sudo apt-get install florence

Afortunadamente este tipo de teclas, por el uso que hago del dispositivo, las utilizo poco. Pero si tú haces uso intensivo de ellas, el teclado en pantalla de Ubuntu se te quedará corto.

Stylus

La tablet Microsoft surface 1 viene con un lápiz o stylus con cuatro funciones principales: puntero, click izquierdo, click derecho y borrar. Mi stylus ha perdido esta última funcionalidad así que os hablaré de las otras tres.

El puntero funciona perfectamente, al igual que la simulación del click del botón izquierdo del ratón. La simulación del click derecho en cambio no funciona desde un principio, pero tras una sencilla búsqueda en internet pude solucionarlo. Tan solo tenemos que hacer que Ubuntu ejecute el siguiente comando tras el arranque:

xmodmap -e "pointer = 1 3 2 4 5 6 7 8 9 10"

Acciones táctiles

El manejo de la tablet sin el lápiz está conseguido a medias. Si bien la respuesta a las acciones táctiles es buena, no he conseguido simular el click derecho del ratón de una forma satisfactoria. A pesar de que en el apartado «Acceso Universal», dentro de la configuración de Ubuntu, existe un apartado para este propósito, el resultado no me ha convencido en absoluto.

Rotación de pantalla

La rotación de la pantalla es otra de las funcionalidades que vienen por defecto. Su funcionamiento es muy bueno, la respuesta al giro es adecuada y el escritorio y los programas se adaptan perfectamente a visualizaciones tanto horizontales como verticales. Además en las herramientas situadas en la esquina superior derecha podemos bloquear la rotación, algo muy de agradecer en un dispositivo de estas características.

Duración de la batería

Un aspecto que me ha sorprendido gratamente y que no me esperaba es la duración de la batería. Si con Windows 10 rara vez conseguía tener dos horas reales de uso de la tablet, con Ubuntu he conseguido duplicar esta autonomía. Evidentemente esto dependerá del uso que hagamos del dispositivo, y es posible que en usos más intensivos la diferencia entre los dos sistemas se reduzca.

Además, algo con un origen muy en relación a la duración de la batería, es que la tablet ahora se calienta menos que cuando tenía instalado Windows.

Conclusión

El uso de Ubuntu en dispositivos táctiles tiene sus luces y sus sombras. La experiencia de usuario está lejos de ser perfecta, pero aun así, para mi ha sido más que suficiente para decidirme a cambiar.

Créditos, referencia y artículos relacionados

• Averiguar que versión de Linux tengo instalada.
• Cómo instalar Linux dentro de Windows 10 utilizando WSL 1
• Actualización de Windows 10 machaca el gestor de arranque de Linux

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

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.