Installer LAMP sur Ubuntu 24.04 avec PHP-FPM

Ce que vous allez construire

Une stack LAMP regroupe quatre éléments sur un même serveur Ubuntu 24.04 : Linux en dessous, Apache qui traite les requêtes HTTP, MariaDB qui stocke les données et PHP 8.3 qui exécute le code. À la fin, vous disposerez d’un virtual host basé sur le nom, qui servira un véritable répertoire d’application, d’une base de données avec un utilisateur dédié doté des privilèges minimaux, de PHP relié à Apache via PHP-FPM et d’un certificat gratuit Let’s Encrypt.

L’installation elle-même tient en quatre commandes apt. La majeure partie de ce guide explique le raccordement entre ces composants et les quelques erreurs qui peuvent faire afficher une page blanche à une stack fraîchement installée, faire transmettre votre code source au navigateur sous forme de téléchargement ou vous empêcher d’accéder à la base de données que vous venez d’installer. Chacun de ces problèmes possède une signature reconnaissable. Ils sont décrits ci-dessous avec le texte exact que vous verrez.

Prérequis et points à connaître

Partez d’un VPS KVM Ubuntu 24.04 fraîchement installé, avec un utilisateur sudo ou root, et une adresse IPv4 publique. Une pile minimale fonctionne avec 1 GB de RAM. Prévoyez 2 GB avant d’y installer une véritable application utilisant une base de données, car les buffers par défaut de MariaDB et quelques workers PHP-FPM consomment rapidement le premier gigaoctet.

Deux conditions doivent être réunies pour que Certbot fonctionne à la fin. Préparez-les dès maintenant. Vous avez besoin d’un nom de domaine avec un enregistrement A pointant vers l’adresse IP publique du VPS. Let’s Encrypt effectue la validation en HTTP sur ce nom. Une simple adresse IP ne peut jamais obtenir de certificat. Les ports 80 et 443 doivent également être accessibles depuis Internet. Chez de nombreux fournisseurs, cela signifie les ouvrir dans le pare-feu réseau du panneau de contrôle et dans ufw sur la machine. La propagation des changements DNS peut prendre jusqu’à une heure. Créez donc l’enregistrement A en premier pour qu’il soit actif au moment voulu.

Étape 1 - Installer Apache et vérifier la page par défaut

sudo apt update
sudo apt install -y apache2

apt démarre et active le service pour vous. Vérifiez son état :

systemctl status apache2

Vous devez obtenir une ligne contenant active (running). Ouvrez ensuite http://YOUR_SERVER_IP/ dans un navigateur. La page par défaut Apache2 Ubuntu, avec la grande bannière « It works! », est le résultat attendu. Elle confirme qu’Apache sert bien des pages ; ce n’est pas une erreur. Cette page se trouve dans /var/www/html/index.html et est servie par le virtual host par défaut fourni dans 000-default.conf. Vous désactiverez les deux plus tard. Pour l’instant, leur présence est exactement ce que vous devez vérifier.

Si la page ne se charge pas du tout alors que systemctl indique que le processus fonctionne, un pare-feu bloque l’accès. C’est l’étape suivante.

Étape 2 - Ouvrir le pare-feu pour HTTP et HTTPS

Le paquet apache2 enregistre trois profils d’application ufw. Affichez-les :

sudo ufw app list

Vous verrez Apache, Apache Full et Apache Secure. Apache concerne uniquement le port 80, Apache Secure uniquement le port 443 et Apache Full les deux. C’est celui qu’il vous faut, car vous ajoutez TLS à la fin.

sudo ufw allow OpenSSH
sudo ufw allow "Apache Full"
sudo ufw enable

Autorisez OpenSSH avant d’exécuter ufw enable. Par défaut, ufw refuse tout le trafic entrant. Si vous l’activez sans règle SSH, votre connexion est coupée dès son activation. Vous conservez la session actuelle, mais vous ne pouvez plus vous reconnecter. Vérifiez avec sudo ufw status. Les entrées OpenSSH, Apache Full et leurs équivalents v6 doivent toutes afficher ALLOW.

Étape 3 - Installer MariaDB et le sécuriser

sudo apt install -y mariadb-server
systemctl status mariadb

Ubuntu 24.04 fournit MariaDB 10.11, une version bénéficiant d’un support à long terme. Vous n’avez donc pas besoin d’un dépôt externe. Une fois le service démarré, renforcez sa configuration :

sudo mysql_secure_installation

Lisez les invites au lieu d’appuyer machinalement sur Entrée. Lorsqu’il demande le mot de passe root actuel, appuyez sur Entrée : il n’y en a pas encore. Lorsqu’il demande « Switch to unix_socket authentication? », la réponse ne change rien, car cette authentification est déjà activée dans ce paquet ; appuyez donc sur n. Répondez n à « Change the root password? » pour la raison indiquée au paragraphe suivant, puis répondez Y aux autres questions : supprimer les utilisateurs anonymes, interdire la connexion distante de root, supprimer la base de données de test et recharger les tables de privilèges.

Voici le point qui prête à confusion. Dans MariaDB sur Ubuntu, le compte de base de données root utilise l’authentification unix_socket, et non un mot de passe. La base de données fait donc confiance à l’utilisateur du système d’exploitation avec lequel vous vous êtes déjà authentifié. Cette commande fonctionne depuis un shell root :

sudo mysql

… et vous amène à une invite MariaDB [(none)]> sans demander de mot de passe. La même commande exécutée par un utilisateur non privilégié est refusée. C’est précisément le but recherché : l’accès au compte root de la base de données dépend de sudo sur le serveur, et aucun mot de passe ne peut être volé, hameçonné ou deviné par force brute. Cette méthode est plus sûre qu’un mot de passe ; laissez-la donc telle quelle. La règle qui en découle est la suivante : ne pointez jamais une application vers le compte root. Créez un utilisateur dédié pour chaque application (étape 7), car une application qui se connecte via TCP avec un nom d’utilisateur et un mot de passe ne peut de toute façon pas utiliser l’authentification par socket, et vous voulez limiter chaque application à sa propre base de données.

Étape 4 - Installer PHP 8.3 avec PHP-FPM

La version PHP par défaut d’Ubuntu 24.04 est la 8.3. Installez le gestionnaire de processus FPM et les extensions nécessaires à une application courante :

sudo apt install -y php8.3-fpm php8.3-mysql php8.3-cli \
  php8.3-curl php8.3-xml php8.3-mbstring php8.3-zip

Notez ce qui ne figure pas dans cette liste : libapache2-mod-php. Cet ancien paquet intègre un interpréteur PHP dans chaque processus Apache. Cette solution est simple, mais chaque worker contient une copie de PHP, qu’il serve un script ou une image statique. Les deux composants partagent leur cycle de vie. Cette solution ne fonctionne en outre qu’avec le MPM prefork d’Apache, le moins efficace. PHP-FPM exécute au contraire PHP dans son propre pool de processus, auquel Apache accède via un socket. Apache peut alors utiliser le MPM event, basé sur les threads, pour les fichiers statiques et ne transmettre que les requêtes PHP. Le pool se règle indépendamment du serveur web. La même configuration FPM fonctionne ensuite si vous placez nginx devant. C’est la configuration par défaut actuelle, à juste titre.

Apache accède à FPM via le module proxy_fcgi. Activez-le, activez la configuration installée par le paquet FPM, puis redémarrez :

sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.3-fpm
sudo systemctl restart apache2

a2enconf php8.3-fpm active /etc/apache2/conf-available/php8.3-fpm.conf, qui contient la règle d’acheminement des fichiers PHP vers le socket FPM. Cette règle recherche tout fichier .php et le transmet au socket situé à /run/php/php8.3-fpm.sock :

<FilesMatch ".+\.ph(ar|p|tml)$">
    SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"
</FilesMatch>

Vous ne devez pas modifier ce fichier : le paquet l’installe avec la bonne configuration. Cependant, connaître le chemin du socket permet de diagnostiquer les erreurs « PHP est téléchargé au lieu d’être exécuté » et « Primary script unknown ». Dans les deux cas, Apache et FPM n’utilisent pas le même socket ou ne pointent pas vers le même fichier.

Étape 5 - Un virtual host basé sur le nom pour votre application

L’hébergement virtuel basé sur le nom permet à une seule adresse IP de servir plusieurs sites. Apache sélectionne le site à partir de l’en-tête Host: de la requête. Créez un répertoire pour l’application, distinct du répertoire /var/www/html par défaut :

sudo mkdir -p /var/www/testapp
sudo chown -R www-data:www-data /var/www/testapp
sudo chmod -R 755 /var/www/testapp

Le propriétaire des fichiers est important. Sur Ubuntu, Apache et PHP-FPM s’exécutent tous deux avec l’utilisateur www-data. Les fichiers que le serveur web doit lire et les répertoires dans lesquels l’application doit écrire, comme un dossier d’uploads, doivent donc appartenir à www-data. Si vous devez également modifier des fichiers avec votre utilisateur de connexion, une configuration courante consiste à être propriétaire des fichiers et à ajouter votre utilisateur au groupe www-data. Pour un déploiement simple, www-data:www-data est le choix le plus prévisible.

Créez le virtual host dans /etc/apache2/sites-available/testapp.conf :

<VirtualHost *:80>
    ServerName app.example.com
    DocumentRoot /var/www/testapp

    <Directory /var/www/testapp>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/testapp-error.log
    CustomLog ${APACHE_LOG_DIR}/testapp-access.log combined
</VirtualHost>

Définissez ServerName avec votre véritable domaine. Options -Indexes empêche Apache d’afficher le contenu du répertoire lorsqu’aucun fichier d’index n’est présent. Sans cette directive, les visiteurs peuvent parcourir votre arborescence de fichiers. AllowOverride All permet à un fichier .htaccess de fonctionner, ce que la plupart des applications PHP attendent pour les URL lisibles. Remplacez cette valeur par None pour gagner un peu en performances si votre application n’en a pas besoin. Activez ce site, désactivez le site par défaut, vérifiez la configuration, puis rechargez Apache :

sudo a2ensite testapp
sudo a2dissite 000-default
sudo apache2ctl configtest
sudo systemctl reload apache2

apache2ctl configtest doit afficher Syntax OK. La ligne a2dissite 000-default est celle que l’on oublie le plus souvent. C’est pourquoi la page par défaut semble ensuite rester affichée, comme expliqué dans la section consacrée aux échecs.

Étape 6 - Vérifier que PHP fonctionne, puis supprimer le fichier de test

Déposez un fichier PHP d’une seule ligne à la racine de l’application :

echo "<?php phpinfo();" | sudo tee /var/www/testapp/info.php

Accédez à http://app.example.com/info.php. Le résultat attendu est le long tableau PHP Version 8.3.x violet et gris qui répertorie les modules chargés, avec la ligne Server API indiquant FPM/FastCGI. Cette dernière ligne confirme que les requêtes passent par PHP-FPM et non par mod_php.

Supprimez-le immédiatement :

sudo rm /var/www/testapp/info.php

phpinfo() expose votre version exacte de PHP, toutes les extensions chargées, les chemins des fichiers et les détails de l’environnement. Ces informations peuvent aider toute personne qui recherche sur le serveur une version présentant une vulnérabilité connue. Il s’agit d’un test, pas d’une fonctionnalité. Supprimez le fichier dès que vous avez vu la page. Si votre navigateur propose de télécharger info.php au lieu d’afficher le tableau, PHP n’est pas correctement connecté à Apache. Passez à la section consacrée aux échecs avant toute autre action.

Étape 7 - Créer la base de données de l’application et un utilisateur aux privilèges minimaux

Ouvrez la base de données avec le compte root authentifié par socket :

sudo mysql

Créez ensuite une base de données et un utilisateur limités exactement à cette base :

CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'a-long-random-password';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Trois choix sont délibérés ici. utf8mb4 utilise réellement l’UTF-8 sur 4 octets ; l’ancien alias utf8 tronque silencieusement les emoji et certains caractères CJK. Utilisez donc toujours utf8mb4. L’autorisation porte sur appdb.*, et non sur *.* : cet utilisateur peut accéder à sa propre base, mais à rien d’autre. Ainsi, une faille d’injection SQL dans l’application ne permet pas de lire les tables des autres sites. Enfin, 'appuser'@'localhost' limite le compte aux connexions provenant du serveur lui-même.

Testez la connexion avec cet utilisateur :

mysql -u appuser -p appdb

Le client demande le mot de passe, puis vous place sur une invite MariaDB [appdb]>. Notez l’absence de l’option -h : laissez-la désactivée. Le client se connecte alors via la socket Unix locale, ce que MariaDB considère exactement comme localhost. Un point important : pour MySQL et MariaDB, localhost désigne la socket Unix et 127.0.0.1 désigne une connexion TCP. Sur une installation standard de MariaDB sous Ubuntu 24.04, le serveur ramène encore une connexion TCP provenant de 127.0.0.1 à localhost. Les deux correspondent donc au compte. En revanche, lorsque skip-name-resolve est activé — un réglage d’optimisation courant, et la configuration habituelle de nombreuses images de conteneur — ces deux valeurs sont considérées comme des hôtes différents. Une application qui se connecte à 127.0.0.1 est alors refusée avec ERROR 1045 (28000): Access denied for user 'appuser'@'127.0.0.1' (using password: YES), même si le mot de passe est correct.

Configurez donc l’application avec l’hôte localhost, l’utilisateur appuser et la base de données appdb, jamais avec root. mysqli de PHP et PDO utilisent tous deux la socket Unix lorsque l’hôte est la chaîne littérale localhost, ce qui correspond au compte que vous venez de créer. Si un framework exige une adresse TCP numérique, créez l’utilisateur en fonction de son mode de connexion réel : 'appuser'@'127.0.0.1' ou @'%', avec une règle de pare-feu, uniquement s’il doit accéder à la base depuis une autre machine.

Étape 8 - Ajouter HTTPS avec Certbot

Servir un formulaire de connexion en HTTP simple transmet les mots de passe en clair, et les navigateurs modernes signalent la page comme « Non sécurisée ». Certbot corrige ce problème avec une seule commande. Installez-le avec le plugin Apache :

sudo apt install -y certbot python3-certbot-apache
sudo certbot --apache

Certbot utilise ici deux plugins. L’authenticator apache prouve que vous contrôlez le domaine en servant brièvement un fichier de challenge via votre instance Apache en fonctionnement. L’installer apache réécrit ensuite votre virtual host pour ajouter le bloc 443, le faire pointer vers le nouveau certificat et rediriger par défaut tout le trafic HTTP vers HTTPS. Depuis Certbot 2.0, aucune question de redirection n’est posée ; transmettez --no-redirect si vous devez continuer à servir du HTTP simple. Comme vous avez défini un véritable ServerName à l’étape 5, Certbot détecte automatiquement le domaine. Les certificats sont valables 90 jours et le paquet installe un timer systemd qui les renouvelle. Vérifiez ce timer avec sudo certbot renew --dry-run ; la sortie doit se terminer par Congratulations, all simulated renewals succeeded.

Pour consulter la procédure complète du challenge, du timer de renouvellement et des exigences liées au DNS et au pare-feu, consultez le guide associé Émettre gratuitement des certificats TLS Let’s Encrypt avec Certbot sur Apache.

Sauvegardes, mises à niveau et durcissement

Sauvegardez les deux éléments qui contiennent votre état : les bases de données et la racine web. Un dump logique nocturne est l’approche fiable la plus simple, sudo sh -c 'mysqldump --all-databases --single-transaction | gzip > /root/db-$(date +%F).sql.gz', puis copiez-le hors du serveur. Il est important d’encapsuler tout le pipeline dans sudo sh -c : sans cela, le shell exécute la redirection > /root/... avec votre propre utilisateur et échoue avec Permission denied, car seul mysqldump a hérité de sudo. --single-transaction fournit un instantané cohérent des tables InnoDB sans les verrouiller. Associez-le à un tar de /var/www et de /etc/apache2/sites-available, et vous pourrez reconstruire toute la stack sur un VPS neuf à partir de ces fichiers.

Les mises à niveau font partie de la maintenance courante : sudo apt update && sudo apt upgrade. Le cas problématique est celui d’une mise à niveau de la version de PHP. Lorsqu’une future version d’Ubuntu définit PHP 8.4 par défaut, apt peut installer php8.4-fpm en parallèle de 8.3, le socket devient /run/php/php8.4-fpm.sock et votre configuration Apache pointe toujours vers le socket de 8.3. Activez la nouvelle configuration (sudo a2enconf php8.4-fpm) et désactivez l’ancienne. Sinon, votre site commence à renvoyer Primary script unknown après une mise à niveau pourtant standard. Les versions de PHP évoluent plus vite que celles d’une distribution LTS. Consultez donc les notes de version actuelles de PHP au lieu de figer une version de correctif.

Deux mesures de durcissement sont utiles dès le premier jour. Premièrement, installez Fail2Ban pour surveiller SSH sur le serveur. Un VPS public reçoit des tentatives de connexion automatisées en quelques minutes. Une petite jail réduit des milliers de tentatives à quelques-unes avant le bannissement. Deuxièmement, si vous préférez gérer les virtual hosts Apache, les bases de données MariaDB et les utilisateurs depuis un navigateur plutôt que de modifier les fichiers manuellement, le panneau de contrôle Webmin accessible depuis le Web s’appuie sur cette même stack et modifie les mêmes fichiers de configuration que ceux que vous venez d’écrire. Aucun de ces outils ne remplace la compréhension des différents composants, mais tous deux réduisent les tâches répétitives quotidiennes.

Modes d’échec et messages affichés

La page par défaut ne disparaît pas. Vous avez modifié votre virtual host, rechargé la configuration, mais le navigateur affiche toujours « Apache2 Ubuntu Default Page » avec sa bannière « It works! ». Apache sert le premier virtual host correspondant. Lorsqu’aucun ServerName ne correspond à la requête, la configuration qui arrive en premier dans l’ordre alphabétique est utilisée ; 000-default.conf est classé avant testapp.conf. Le nom d’hôte de la requête ne correspond peut-être pas à votre ServerName, ou vous n’avez jamais exécuté sudo a2dissite 000-default. Désactivez la configuration par défaut avec sudo systemctl reload apache2, puis vérifiez avec apache2ctl -S. Cette commande affiche la correspondance des virtual hosts et indique quelle configuration possède le virtual host par défaut. Videz également le cache du navigateur : une réponse 200 mise en cache pour l’ancienne page peut rester affichée.

Un fichier .php est téléchargé au lieu d’être exécuté. Vous ouvrez info.php et le navigateur télécharge un fichier contenant le code source <?php brut, ou l’affiche comme du texte brut, au lieu de l’exécuter. Apache sert le fichier comme une ressource statique, car le gestionnaire PHP n’est pas associé, vous avez ignoré sudo a2enmod proxy_fcgi ou sudo a2enconf php8.3-fpm, ou vous n’avez pas redémarré Apache ensuite. Exécutez les trois commandes (étape 4), puis rechargez la page. Vérifiez que le module est chargé avec apache2ctl -M | grep fcgi ; la commande doit afficher proxy_fcgi_module. Il s’agit d’une fuite de code source, pas d’un simple problème d’affichage. Corrigez-la avant de mettre quoi que ce soit d’important sur le serveur.

ERROR 1698 (28000): Access denied for user 'root'@'localhost'. Vous avez exécuté mysql -u root ou mariadb -u root sans sudo. Le compte root utilise l’authentification unix_socket. Il n’accepte donc la connexion que lorsque votre utilisateur du système d’exploitation est réellement root. La correction consiste à utiliser sudo mysql, sans -u root et sans mot de passe. Ce message est le comportement attendu d’une authentification par socket qui fonctionne correctement. Il n’indique pas une installation défectueuse.

ERROR 1045 (28000): Access denied for user 'appuser'@'127.0.0.1' depuis l’application, avec le bon mot de passe. Le compte existe sous le nom 'appuser'@'localhost', mais votre application se connecte via TCP à 127.0.0.1 sur un serveur où la résolution des noms d’hôte est désactivée (skip-name-resolve). MariaDB considère donc ces deux connexions comme provenant d’hôtes différents : localhost est la socket Unix et 127.0.0.1 utilise TCP. Configurez l’application pour utiliser l’hôte localhost afin qu’elle passe par la socket et corresponde au compte, ou créez un deuxième compte 'appuser'@'127.0.0.1' si le framework ne peut utiliser que TCP.

AH01071: Got error 'Primary script unknown' dans /var/log/apache2/testapp-error.log, tandis que le navigateur affiche File not found.. Apache a transmis la requête à PHP-FPM, mais FPM n’a pas trouvé le script à l’emplacement indiqué par Apache. Deux causes sont fréquentes : la socket FPM de votre configuration pointe vers une version de PHP qui n’est pas installée — une socket php8.4 après une mise à niveau alors que seule la version 8.3 fonctionne —, ou le fichier n’existe réellement pas parce que DocumentRoot et le répertoire réel ne correspondent pas. Vérifiez que la socket existe avec ls -l /run/php/, confirmez que DocumentRoot correspond à l’emplacement du fichier, puis redémarrez php8.3-fpm et apache2.

AH00558: apache2: Could not reliably determine the server's fully qualified domain name à chaque redémarrage. Il s’agit d’un avertissement sans conséquence, pas d’une erreur. Apache indique qu’aucun ServerName global n’est défini. Supprimez cet avertissement en écrivant ServerName your.domain dans /etc/apache2/conf-available/servername.conf, puis en exécutant sudo a2enconf servername.

(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80 au démarrage d’Apache. Un autre serveur web utilise déjà le port 80, souvent un nginx resté actif après une précédente expérimentation. Identifiez-le avec sudo ss -ltnp | grep :80, puis arrêtez et désactivez l’autre service avant de démarrer Apache.

FAQ

mod_php ou PHP-FPM : lequel choisir ?

Utilisez PHP-FPM. mod_php intègre un interpréteur dans chaque processus Apache et impose le MPM lent prefork. Apache conserve donc la surcharge de PHP même lorsqu’il sert une image statique. PHP-FPM exécute PHP dans un pool séparé, réglable indépendamment, qu’Apache contacte via un socket. Il fonctionne avec le MPM threadé plus rapide event et pourra être repris sans modification lors d’une migration ultérieure vers nginx. C’est le choix moderne par défaut. mod_php ne se justifie que pour une application ancienne qui dépend d’un comportement au sein du processus.

Pourquoi mon navigateur télécharge-t-il le fichier PHP au lieu de l’exécuter ?

Apache traite le fichier .php comme un téléchargement statique, car aucun gestionnaire PHP ne lui est associé. Sur Ubuntu 24.04 avec FPM, cela signifie que vous avez oublié l’une des étapes sudo a2enmod proxy_fcgi, sudo a2enconf php8.3-fpm ou le redémarrage d’Apache qui suit. Exécutez les trois étapes, rechargez ensuite la configuration, puis vérifiez avec apache2ctl -M | grep fcgi que proxy_fcgi_module est bien listé. Tant que le problème n’est pas corrigé, le serveur divulgue le code source. Traitez donc ce problème comme urgent.

Pourquoi l’accès root est-il refusé dans MariaDB, même avec le bon mot de passe ?

Parce qu’il n’y a pas de mot de passe. Sur Ubuntu, MariaDB authentifie le compte root via unix_socket et le lie à l’utilisateur root du système d’exploitation. mysql -u root depuis un shell standard renvoie ERROR 1698 (28000): Access denied for user 'root'@'localhost' par conception. Connectez-vous plutôt avec sudo mysql et créez un utilisateur distinct, authentifié par mot de passe, pour chaque application au lieu de réutiliser root.

Comment ajouter HTTPS à mon site LAMP ?

Installez certbot et python3-certbot-apache, faites pointer l’enregistrement A du domaine vers le serveur, puis exécutez sudo certbot --apache. L’authenticator Apache prouve que vous contrôlez le domaine au moyen de votre serveur Apache en fonctionnement. L’installateur modifie ensuite le virtual host pour le port 443 et configure le renouvellement automatique. Le guide complet Certbot et Apache décrit le challenge, le timer de renouvellement et les causes courantes d’échec.