NexTool Solutions

Actualizamos dos veces una copia de un GLPI 11.0.11 a la 12.0.0: en Docker con la imagen oficial y en Debian 13 con el paquete .tgz. La migración de la base de datos tardó unos 5 segundos en ambos casos. El trabajo vino antes y después: el MariaDB 10.6 fue rechazado, los plugins quedaron suspendidos, las categorías de la base de conocimiento se convirtieron en artículos que técnicos y usuarios no pueden abrir y el webhook dejó de enviar, por dos motivos distintos. Esta guía trae el paso a paso de los dos caminos y la solución de cada problema, en el orden en que aparecieron.

¿Todavía decidiendo si es momento de actualizar? Lea antes Salió GLPI 12: qué cambia, requisitos y cuándo actualizar.

Qué probamos

Montamos un GLPI 11.0.11 desechable con datos ficticios de Acme: 120 tickets con seguimientos y 40 tareas, un SLA, 9 artículos de la base de conocimiento en 4 categorías con permisos diferentes, un webhook hacia un servidor interno y tres plugins de la comunidad (Fields, Tag y Data Injection), con datos. Hicimos el respaldo y actualizamos a la 12.0.0. Después restauramos el mismo respaldo en un Debian 13 y repetimos la actualización con el paquete .tgz.

Antes de empezar: requisitos

Dos detalles que mostró la prueba:

• PHP 8.2 no da un aviso, da un error de sintaxis. La consola de GLPI 12 ni siquiera llega a verificar los requisitos: se detiene con un "Parse error" en un archivo del propio GLPI. Debian 12 y Ubuntu 22.04 traen PHP 8.2 o anterior. Debian 13 (PHP 8.4) y Ubuntu 24.04 (PHP 8.3) cumplen con los paquetes estándar. La imagen Docker oficial ya trae PHP 8.5.
• Revise la base de datos antes que nada. Ejecute php bin/console system:check_requirements con el código nuevo apuntando a su base. En nuestro MariaDB 10.6 la respuesta fue directa: versión no soportada, mínimo 10.11.

Paso 0: respaldo (base de datos, archivos y la clave)

Haga tres copias antes de tocar nada: la base de datos, la carpeta de archivos y la carpeta de configuración. La carpeta de configuración contiene glpicrypt.key. Sin ella, las contraseñas que guarda GLPI (recolector de correo, LDAP, proxy, secretos de webhook) ya no se pueden descifrar.

mariadb-dump --single-transaction --routines -u root -p glpi | gzip > glpi11-$(date +%F).sql.gz
tar czf glpi11-arquivos-$(date +%F).tgz /etc/glpi /var/lib/glpi/files /var/www/glpi/marketplace

En Docker con la imagen oficial, todo está en el volumen montado en /var/glpi (config, files, marketplace y logs): copie el volumen completo. En nuestra prueba, el volcado tardó 5 segundos y la copia del volumen, 8,5.

Camino 1: Docker con la imagen oficial

La imagen oficial (glpi/glpi) actualiza la base de datos por sí sola cuando arranca con una versión nueva. Basta con cambiar la etiqueta y levantar el contenedor: no pide confirmación. Por eso el respaldo va antes del cambio de etiqueta, nunca después. Si prefiere ejecutar la actualización a mano, levántelo con GLPI_SKIP_AUTOUPDATE=true y use el comando del camino 2.

1. Actualice MariaDB, si hace falta. Con MariaDB 10.6, el contenedor de GLPI 12 terminó con código 128. El log avisó que faltaban requisitos y, justo después, escribió una frase que asusta: "GLPI is not installed... Starting installation". No instaló nada. La base de datos siguió intacta, en la versión 11.0.11, con los 120 tickets. Simplemente no pasó la verificación de requisitos. El cambio de MariaDB 10.6 a 10.11 tardó 22 segundos con la variable de actualización automática de la imagen de MariaDB. Levante primero solo la base de datos (docker compose up -d db) y revise el log antes de seguir:

services:
  db:
    image: mariadb:10.11          # antes 10.6
    environment:
      MARIADB_AUTO_UPGRADE: "1"   # ejecuta mariadb-upgrade al arrancar
  glpi:
    image: glpi/glpi:12.0.0       # antes 11.0.11 (paso 2)
    volumes:
      - glpi-data:/var/glpi

2. Cambie la etiqueta y levante. docker compose up -d. El log muestra "GLPI is installed, and auto-update is enabled. Starting update..." y, a continuación, el mensaje de bienvenida. En la prueba pasaron 17 segundos desde el up hasta el mensaje de bienvenida en el log.

3. Verifique. docker compose exec glpi bin/console db:check debe responder "Database schema is OK".

Camino 2: Linux con el paquete .tgz

Los comandos siguientes usan la estructura de nuestra guía de instalación de GLPI 11 en Debian y Ubuntu: código en /var/www/glpi, configuración en /etc/glpi y archivos en /var/lib/glpi/files.

cd /var/www/glpi && sudo -u www-data php bin/console maintenance:enable
cd /var/www && mv glpi glpi-11-antigo
wget https://github.com/glpi-project/glpi/releases/download/12.0.0/glpi-12.0.0.tgz
tar xzf glpi-12.0.0.tgz
cp glpi-11-antigo/inc/downstream.php glpi/inc/                  # si existe
cp glpi-11-antigo/config/local_define.php glpi/config/ 2>/dev/null  # si existe
cp -a glpi-11-antigo/marketplace/. glpi/marketplace/
chown -R www-data:www-data glpi
cd glpi
sudo -u www-data php bin/console system:check_requirements
sudo -u www-data php bin/console database:update
sudo -u www-data php bin/console maintenance:disable

El archivo que nadie recuerda: inc/downstream.php. Es el que le dice a GLPI que la configuración está en /etc/glpi. Vive dentro de la carpeta del código, así que desaparece cuando usted cambia la carpeta. En la prueba, sin él, database:update respondió "Unable to connect to database". El mensaje no dice el motivo real: GLPI buscó la configuración en el lugar equivocado. Con el archivo copiado de vuelta, la actualización se ejecutó de inmediato. Lo mismo vale para config/local_define.php, si lo usa.

Si su GLPI guarda config y files dentro de /var/www/glpi, copie también config/ y files/ de la carpeta antigua. Así fue en Debian 13 (PHP 8.4): la migración tardó 5 segundos y db:check salió limpio.

Si la actualización de la base de datos falla

En el foro de GLPI apareció, el 3 de noviembre, una actualización de 11.0.8 a 12.0.1 en Debian 13 que se trabó: se copiaron los archivos, se ajustaron dueño y permisos, y maintenance:disable dio error y la actualización de la base falló. No reprodujimos este caso. Una respuesta en el hilo señaló una causa probable, y el código de la migración confirma que es posible: en la 11, la tabla que vincula artículos con categorías de la base de conocimiento acepta el mismo par artículo/categoría repetido; la tabla que la reemplaza en la 12 no lo acepta. Un vínculo duplicado basta para detener la migración. Restaure el respaldo de la 11 (la migración puede haberse detenido a la mitad) y busque duplicados:

SELECT knowbaseitems_id, knowbaseitemcategories_id, COUNT(*) AS n
FROM glpi_knowbaseitems_knowbaseitemcategories
GROUP BY knowbaseitems_id, knowbaseitemcategories_id
HAVING n > 1;

Si aparece alguna fila, borre las copias y mantenga un vínculo por par. El artículo sigue en la categoría:

DELETE l1 FROM glpi_knowbaseitems_knowbaseitemcategories l1
JOIN glpi_knowbaseitems_knowbaseitemcategories l2
  ON l1.knowbaseitems_id = l2.knowbaseitems_id
 AND l1.knowbaseitemcategories_id = l2.knowbaseitemcategories_id
 AND l1.id > l2.id;

Si la consulta sale vacía, la causa es otra. Verifique que la carpeta de archivos y la de configuración (en nuestro esquema, /var/lib/glpi/files y /etc/glpi) pertenezcan a www-data, ejecute system:check_requirements y lea php-errors.log en la carpeta _log de los archivos y el log de errores del servidor web. Ejecute database:update por línea de comandos, que muestra el error en pantalla, y solo después maintenance:disable.

Después de la migración: qué se rompió y cómo resolverlo

1. Los plugins quedan suspendidos (y el comando para listarlos no lo dice)

Después de la actualización, GLPI 12 suspende la ejecución de todos los plugins. plugin:list siguió mostrando los tres como "Enabled". Pero la configuración plugins_execution_mode estaba en "suspended_by_update", y ningún plugin se ejecutaba. Para liberarlos:

php bin/console plugin:resume_execution

Al liberarlos, GLPI verificó las versiones y desactivó los tres ("Installed / not activated"). Las versiones para la 11 aceptan como máximo GLPI 11.0.99, y las versiones para la 12 exigen como mínimo la 12.0.0. Es decir: no se pueden actualizar estos plugins antes que GLPI. Primero GLPI, después los plugins:

Para cada uno: reemplace la carpeta en marketplace/ por la versión nueva y ejecute plugin:install y plugin:activate. Los datos se mantuvieron: los 5 valores del campo "Centro de costo" de Fields y las 10 etiquetas de Tag siguieron ahí. Antes de fijar la fecha, confirme que todos sus plugins ya tienen versión para la 12 (cómo elegir plugins sin trabar la actualización).

2. Las categorías de la base de conocimiento se convierten en artículos sin visibilidad

GLPI 12 ya no tiene categorías en la base de conocimiento: las 4 categorías se convirtieron en 4 artículos "padre", y se creó un artículo raíz ("Home") por encima de ellos. Los 9 artículos mantuvieron los permisos que tenían. Pero los 4 artículos que eran categorías quedaron sin ninguna regla de visibilidad. Probamos por la API con un técnico y un usuario de Self-Service: los dos recibieron error 403 al abrir "Procedimientos", "Red", "Wi-Fi" y "FAQ del usuario". Cada uno siguió abriendo solo los artículos que ya veía antes.

Solución: abra cada excategoría y asígnele el público que tenía la carpeta (entidad, perfil o grupo). En la 12, un artículo hereda la visibilidad de los artículos que están por encima. En la prueba, abrir la excategoría "FAQ del usuario" a la entidad Acme hizo que el técnico pudiera abrir la carpeta y los dos artículos que contiene, que antes daban 403. Para el usuario de Self-Service hay un paso más: solo ve artículos marcados como Preguntas frecuentes (FAQ), y las excategorías llegan sin esa marca. Con visibilidad y la marca de FAQ, la carpeta apareció también para él. Haga esto antes de abrir el sistema a los usuarios.

3. El webhook se detuvo: método "post" en minúsculas

El webhook creado en GLPI 11 entró en la cola y falló. El log webhook.log mostró la causa: Invalid HTTP method "post", only uppercase letters are accepted. GLPI guarda el método en minúsculas, y el cliente HTTP de la 12 solo acepta mayúsculas. Esto afecta a todos los webhooks, incluidos los creados en la 12. El problema está registrado en el GitHub de GLPI (issue 25883), con una corrección propuesta. Cuando probamos, el 16 de octubre, la corrección todavía no estaba en la 12.0.0 ni en la versión de desarrollo de la 12.0.1.

Hasta que salga la corrección, la solución temporal es pasar el método a mayúsculas directamente en la base de datos (con respaldo):

UPDATE glpi_webhooks SET http_method = UPPER(http_method);
UPDATE glpi_queuedwebhooks SET http_method = UPPER(http_method);

Si alguien vuelve a guardar el webhook desde la interfaz, el campo regresa a minúsculas. En ese caso repita el comando, y revise las notas de las versiones 12.0.x: cuando entre la corrección, la solución temporal dejará de ser necesaria.

4. Después, el bloqueo de la red interna

Con el método corregido, el error cambió: Host "glpiup-hook" is blocked. GLPI 12 bloquea por defecto las llamadas del servidor hacia redes privadas (10.x, 172.16-31.x, 192.168.x). Esto vale para webhooks, calendarios externos, feeds RSS y la conexión con GLPI Network. Por defecto, solo quedan permitidas las llamadas al agente de inventario y a la autenticación externa. Si su webhook apunta a un n8n, un ERP o una API en la red interna, va a dejar de funcionar.

Para permitir solo lo necesario, cree el archivo config/local_define.php en la carpeta del código de GLPI:

<?php
define('GLPI_SERVERSIDE_URL_ALLOWED_PRIVATE_NETWORKS_CONTEXTS', [
    \Agent::class,    // por defecto
    \Auth::class,     // por defecto
    \Webhook::class,  // permite webhooks hacia la red interna
]);

Trampa de Docker: GLPI lee ese archivo en /var/www/glpi/config/, que está dentro de la imagen, y no en el volumen /var/glpi/config. Colocado en el volumen, el archivo no tuvo efecto. Montado como archivo, funcionó:

    volumes:
      - glpi-data:/var/glpi
      - ./local_define.php:/var/www/glpi/config/local_define.php:ro

Después de eso, los dos webhooks de la cola se entregaron con estado 200. Para configurar un webhook desde cero, vea webhooks nativos de GLPI 11.

5. El aviso sobre documentos

La migración dejó un único aviso en el log warning_during_migration_to_12.0.0.log: "Rights have been given for document, you should review ACLs after update". GLPI otorgó permisos nuevos sobre documentos. Revíselos en Administración > Perfiles, pestaña Gestión > Documentos, sobre todo en los perfiles de usuario final.

Checklist de la actualización

¿Y los módulos de NexTool?

El plugin NexTool y sus 37 módulos funcionan en GLPI 11 y en la 12 con la misma versión. Por eso, a diferencia de los plugins anteriores, se pueden actualizar antes, todavía en la 11, en NexTool > Módulos > Actualizar todos. Después de la migración quedan suspendidos como los demás plugins: ejecute plugin:resume_execution y revise la lista en NexTool > Módulos. La tabla módulo por módulo está en NexTool en GLPI 12: compatibilidad. Si quiere apoyo para planificar o ejecutar la actualización, hable con nosotros.

Prueba de NexTool el 16 de octubre de 2026, en una copia desechable con datos ficticios: imagen oficial glpi/glpi 11.0.11 a 12.0.0 (PHP 8.5), MariaDB 10.6 a 10.11, y paquete .tgz en Debian 13 (PHP 8.4). El entorno se eliminó al final. GLPI es marca registrada de Teclib'. NexTool no está afiliada a Teclib'.