Pourquoi ne pas tout laisser dans un seul dossier
Décompresser GLPI dans le répertoire web et s'arrêter là fonctionne. C'est ainsi que la plupart des installations de test vivent, et c'est ce qui les rend pénibles à exploiter.
Une installation de production éclate les fichiers selon leur nature, comme n'importe quel paquet système :
| Chemin | Contenu | Pourquoi séparé |
|---|---|---|
/var/www/glpi | le code | remplacé entièrement à chaque montée de version |
/etc/glpi | la configuration | ne doit jamais être écrasé par une mise à jour |
/var/lib/glpi/files | documents, cache, plugins | volumineux, à sauvegarder à part |
/var/log/glpi | les journaux | rotation, et pas d'accès depuis le web |
Le bénéfice se voit le jour de la montée de version : vous remplacez le code sans toucher à la configuration ni aux documents. Avec tout dans un seul dossier, la même opération demande des précautions et finit un jour par effacer quelque chose.
Déclarer ces chemins à l'application
GLPI ne devine pas ce découpage. Deux fichiers le lui disent.
/var/www/glpi/inc/downstream.php annonce où se trouve la configuration :
<?php
define('GLPI_CONFIG_DIR', '/etc/glpi/');
if (file_exists(GLPI_CONFIG_DIR . '/local_define.php')) {
require_once GLPI_CONFIG_DIR . '/local_define.php';
}
/etc/glpi/local_define.php annonce le reste :
<?php
define('GLPI_VAR_DIR', '/var/lib/glpi/files');
define('GLPI_LOG_DIR', '/var/log/glpi');
Chaque répertoire appartient à l'utilisateur du serveur web, www-data sur Debian. Une erreur de propriétaire produit un symptôme déroutant : l'application s'affiche, et le téléversement d'un document échoue sans message clair.
Le serveur web
Un hôte virtuel dédié, dont la racine pointe sur /var/www/glpi, avec les journaux d'erreur séparés. Le module de réécriture est activé, et le site par défaut désactivé, sinon l'adresse du serveur sert la page d'accueil d'Apache.
PHP passe par php-fpm plutôt que par le module intégré : le processus PHP est isolé du serveur web, il se redémarre seul, et il se règle indépendamment.
Un réglage compte plus que les autres dans php.ini :
session.cookie_httponly = on
Il interdit à un script de page de lire le cookie de session. Sans lui, une faille d'injection de script dans un ticket suffit à voler la session d'un administrateur. C'est le seul réglage de cette leçon qui soit une mesure de sécurité et non de confort.
Les trois gestes d'après installation
Ils prennent cinq minutes et ils sont régulièrement omis.
Supprimer install/install.php. Tant qu'il existe, n'importe qui atteignant le serveur peut relancer l'assistant. GLPI affiche d'ailleurs un avertissement permanent tant que ce n'est pas fait.
Changer les mots de passe des quatre comptes livrés : glpi, tech, normal et post-only, tous avec un mot de passe identique à leur nom. Le premier est administrateur. Ce sont les premiers essayés par tout scanner.
Passer en HTTPS. GLPI transporte des identifiants d'annuaire et des données de parc. Un certificat interne ou publiquement reconnu, selon l'exposition, mais pas de HTTP en clair.
À retenir
Quatre chemins séparés, déclarés par downstream.php et local_define.php, pour qu'une montée de version ne touche que le code. session.cookie_httponly activé. Et le jour de la mise en service : supprimer l'installeur, changer les quatre mots de passe par défaut, activer HTTPS.