NexTool Solutions

Installare GLPI 11 su Linux fila liscio fino alla riga in cui sposti config/ e files/ fuori dal webroot e l'installatore non "trova" più il database. Questo è il passo dopo passo che usiamo quando provisioniamo GLPI per i clienti: i comandi reali, i due php.ini che contano davvero, il file che evita l'errore più comune dell'installazione manuale e la checklist post-installazione che mette in sicurezza l'ambiente.

Prima di iniziare: dimensiona il server

GLPI 11 gira sullo stack classico LAMP: Apache (o Nginx) + PHP 8.1 o superiore + MariaDB 10.5+ (o MySQL 8). Su Debian 12 il PHP predefinito è l'8.2; su Ubuntu 24.04 LTS, l'8.3 - vanno bene entrambi. Ciò che cambia davvero tra un pilota e un ambiente da centinaia di tecnici è la RAM e il modello di esecuzione di PHP (mod_php contro PHP-FPM). Questa è la matrice che usiamo per dimensionare:

1. Sistema, server web, PHP ed estensioni

Aggiorna il sistema e installa tutto in una volta. Le estensioni non sono opzionali: GLPI verifica ognuna nella schermata dei requisiti.

apt update && apt upgrade -y
apt install -y apache2 mariadb-server \
  php php-{mysql,curl,gd,intl,xml,mbstring,zip,bz2,ldap,imap,apcu} \
  libapache2-mod-php certbot python3-certbot-apache

L'errore comune qui è dimenticare php-intl: l'installazione del pacchetto va comunque a buon fine, ma GLPI si blocca alla verifica dei requisiti e la formattazione delle date e l'internazionalizzazione si rompono. php-ldap e php-imap servono solo se integri Active Directory e il ricevitore di posta, ma installarli subito evita una reinstallazione più avanti.

2. I due php.ini che contano

Questo è ciò che separa un'installazione che "funziona" da una che funziona anche alle 3 di notte. PHP tiene impostazioni separate per SAPI: Apache legge /etc/php/8.2/apache2/php.ini, ma il cron di GLPI gira da riga di comando e legge /etc/php/8.2/cli/php.ini. Imposta entrambi con gli stessi valori:

memory_limit = 256M
upload_max_filesize = 20M
post_max_size = 20M
max_execution_time = 300
max_input_vars = 5000
session.cookie_httponly = On
date.timezone = Europe/Rome
; ricorda: questo stesso file esiste anche in .../cli/php.ini

Nella gestione operativa, la causa numero uno di "le azioni automatiche si sono fermate" quasi mai è il cron di sistema: è il memory_limit a 128M nel php.ini del CLI che soffoca la sincronizzazione dell'inventario o l'invio di notifiche in blocco, mentre quello di Apache era già a 256M e nessuno lo sospettava. Modifica entrambi i file.

3. MariaDB, il database e il fuso orario

Esegui mysql_secure_installation e crea il database in utf8mb4 (accenti ed emoji dipendono da questo):

mysql -u root -p

CREATE DATABASE glpi CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'glpi'@'localhost' IDENTIFIED BY 'PasswordForte';
GRANT ALL PRIVILEGES ON glpi.* TO 'glpi'@'localhost';
FLUSH PRIVILEGES;

Un dettaglio che salta fuori solo dopo: il selettore del fuso orario di GLPI resta vuoto finché non importi le tabelle dei fusi di MariaDB e non concedi la lettura all'utente GLPI. Fallo adesso:

# Carica le tabelle dei fusi; senza questo il selettore resta vuoto
mariadb-tzinfo-to-sql /usr/share/zoneinfo | mysql -u root mysql
mysql -u root -e "GRANT SELECT ON mysql.time_zone_name TO 'glpi'@'localhost'; FLUSH PRIVILEGES;"

4. Sposta config, files e log fuori dal webroot - e di' a GLPI dove sono finiti

Scarica GLPI 11 ed estrailo:

cd /tmp
wget https://github.com/glpi-project/glpi/releases/download/11.0.0/glpi-11.0.0.tgz
tar -xzf glpi-11.0.0.tgz -C /var/www/
chown -R www-data:www-data /var/www/glpi

Per sicurezza, i dati sensibili non possono stare sotto il webroot. Spostali:

mkdir -p /etc/glpi /var/lib/glpi/files /var/log/glpi
mv /var/www/glpi/config/* /etc/glpi/
mv /var/www/glpi/files/*  /var/lib/glpi/files/
chown -R www-data:www-data /etc/glpi /var/lib/glpi /var/log/glpi

Ecco l'errore più comune dell'installazione manuale: spostare le cartelle e non dire a GLPI dove sono andate. Il risultato è l'installatore che ricrea config/ e files/ dentro il webroot, tu che chiudi i permessi nel posto sbagliato e l'ambiente che resta esposto. Il modo corretto è creare inc/downstream.php - è letto sia da Apache sia dal CLI, quindi sistema web e cron in un colpo solo:

<?php // /var/www/glpi/inc/downstream.php
define('GLPI_CONFIG_DIR', '/etc/glpi');
define('GLPI_VAR_DIR',    '/var/lib/glpi/files');
define('GLPI_LOG_DIR',    '/var/log/glpi');

5. Virtual host, HTTPS e il DocumentRoot su public/

Il DocumentRoot punta a /var/www/glpi/public, mai alla radice dell'installazione - è obbligatorio da GLPI 10 ed è ciò che impedisce a config e files di essere serviti dal web.

<VirtualHost *:80>
    ServerName glpi.cliente.com.br
    DocumentRoot /var/www/glpi/public   # mai /var/www/glpi

    <Directory /var/www/glpi/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

a2ensite glpi.conf && a2enmod rewrite
a2dissite 000-default.conf
systemctl reload apache2
certbot --apache -d glpi.cliente.com.br

6. Installa da riga di comando e configura il cron

Con downstream.php al suo posto, db:install scrive già config_db.php in /etc/glpi - non serve esportare alcuna variabile:

php /var/www/glpi/bin/console db:install \
  --db-host=localhost --db-name=glpi \
  --db-user=glpi --db-password='PasswordForte' \
  --default-language=it_IT --no-interaction

GLPI elabora notifiche, inventario e azioni automatiche tramite un cron esterno. Pianificalo ogni minuto - è GLPI stesso a decidere cosa girare a ogni scatto, in base alla frequenza di ciascun task:

echo "* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php &>/dev/null" > /etc/cron.d/glpi

Poi, in Configurazione > Azioni automatiche, cambia la modalità di esecuzione in CLI. Se resta in modalità interna (scatto all'accesso degli utenti), i task spariscono di notte e nei fine settimana - proprio quando vuoi inventario e backup in esecuzione.

7. Post-installazione: la checklist che mette in sicurezza

1. Rimuovi l'installatore: rm /var/www/glpi/install/install.php. Attenzione: ogni upgrade ricrea questo file - rimuovilo di nuovo dopo ogni aggiornamento.
2. Cambia le password dei quattro utenti predefiniti: glpi, tech, normal e post-only.
3. Configura l'SMTP in Configurazione > Notifiche e invia un'email di prova.
4. Verifica che l'installatore sia sparito e che il cron abbia girato:

# L'installatore è ancora raggiungibile? (atteso: 404)
curl -s -o /dev/null -w "%{http_code}\n" https://glpi.cliente.com.br/install/install.php

-- Il cron esterno sta girando? (lastrun deve essere recente)
SELECT name, state, lastrun FROM glpi_crontasks ORDER BY lastrun DESC LIMIT 5;

Cosa verifichiamo quando ereditiamo un GLPI di terzi

Quando prendiamo in gestione un ambiente installato da un altro team, la diagnosi è sempre lo stesso trio: esiste inc/downstream.php o ci sono due cartelle config che convivono (una viva, una fantasma che qualcuno modifica senza effetto)? Il memory_limit del CLI segue quello di Apache? E la modalità delle azioni automatiche è in CLI o legata all'accesso degli utenti? Questi tre punti spiegano la maggior parte dei "GLPI è lento" e "le notifiche non arrivano" che riceviamo - e nessuno compare in un'installazione provata solo cliccando nell'interfaccia in orario d'ufficio.

Ti serve un GLPI 11 provisionato e mantenuto con questo rigore, senza ereditare debito di installazione? Scopri la gestione e il supporto GLPI di NexTool.

Revisionato dal team NexTool Solutions.