Comment installer WordPress en ligne de commande sur un VPS ?

Installer WordPress depuis une interface d'hébergement mutualisé prend trois clics et convient parfaitement à la plupart des projets. Sur un serveur privé virtuel, il n'y a pas d'interface, et c'est précisément l'intérêt : on choisit chaque composant, on connaît l'état exact du système, et l'installation devient reproductible parce qu'elle tient dans un script. L'installation de WordPress en ligne de commande sur une machine Debian neuve demande une heure la première fois et quinze minutes ensuite. Elle suppose surtout de faire les choses dans le bon ordre, car certaines décisions prises au début coûtent cher à revenir dessus une fois le site en production.

Préparer le serveur

Un serveur fraîchement livré est une machine nue qu'il faut mettre en état avant d'y déposer quoi que ce soit. Ces étapes sont les mêmes quel que soit le site que l'on installera ensuite, et elles méritent d'être scriptées dès la première fois.

Mettre le système à jour

La première commande à lancer met à jour la liste des paquets et applique les correctifs disponibles. Une image de distribution, même récente, accuse toujours plusieurs semaines de retard sur les correctifs de sécurité. Cette étape prend quelques minutes et doit être faite avant toute exposition de la machine au réseau. Il est également prudent de vérifier la version de la distribution installée, certains fournisseurs proposant encore des images de versions proches de leur fin de support. Repartir d'une image récente coûte quelques minutes et évite une migration de version dans six mois.

Créer un utilisateur non privilégié

Travailler avec le compte administrateur du système est une mauvaise habitude qui se paie tôt ou tard. Un utilisateur dédié, disposant du droit d'élever ses privilèges lorsque c'est nécessaire, suffit pour tout ce qui suit. La connexion directe du compte administrateur doit ensuite être désactivée dans la configuration du service d'accès distant, ce qui supprime d'un coup l'essentiel des tentatives automatisées observées sur n'importe quelle machine exposée. L'authentification par clé plutôt que par mot de passe complète utilement ce réglage et se met en place en deux commandes.

Installer les composants nécessaires

Il faut un serveur web, un interpréteur PHP avec ses modules, et un serveur de base de données. Les modules PHP indispensables couvrent la manipulation d'images, les chaînes multioctets, les archives, les échanges réseau et l'accès à la base. Installer le paquet correspondant à chacun explicitement, plutôt que de compter sur les dépendances, évite les fonctions manquantes découvertes plusieurs semaines après la mise en ligne, symptôme classique des installations menées trop vite. La liste des modules attendus est courte et mérite d'être consignée dans le script d'installation, où elle sert de documentation.

Régler l'horloge et la langue

Le fuseau horaire du système détermine l'horodatage des journaux et des tâches planifiées. Le régler correctement dès le départ évite des heures de confusion lors du premier incident. La configuration régionale, souvent négligée, influence le tri des données et l'affichage des dates dans certains contextes. Ces deux réglages prennent une minute et sont pénibles à corriger sur une machine en production, notamment parce qu'ils faussent rétroactivement la lecture des journaux existants. Le fuseau du site, réglé dans WordPress, est un paramètre distinct de celui du système, et les deux doivent être cohérents.

Configurer le pare feu

Seuls les ports réellement nécessaires doivent être ouverts : accès distant, service web en clair et sécurisé. Tout le reste doit être fermé, y compris le port de la base de données, qui n'a aucune raison d'être joignable depuis l'extérieur sur une installation où tout tourne sur la même machine. Cette configuration tient en quelques commandes et constitue la protection la plus élémentaire, celle dont l'absence explique la majorité des incidents sur les serveurs personnels. Le port d'accès distant peut en outre être restreint à quelques adresses connues lorsque l'usage le permet, ce qui réduit encore la surface exposée.

Installer WordPress en ligne de commande

L'outil en ligne de commande officiel rend toute l'opération scriptable, ce qui change complètement la nature du travail. Ses possibilités dépassent largement l'installation, comme nous le montrons dans notre article sur les commandes WP-CLI.

Créer la base de données

Une base dédiée et un utilisateur ne disposant de droits que sur celle ci constituent le point de départ. L'utilisateur ne doit surtout pas être celui du système ni celui d'administration de la base. Ce cloisonnement limite les conséquences d'une compromission du site, et il ne coûte rien à mettre en place. La démarche est la même que sur un hébergement mutualisé, décrite dans notre article sur la manière de créer une base de données WordPress. Le jeu de caractères de la base doit être choisi dès la création, une modification ultérieure sur des données existantes étant nettement moins simple.

Télécharger le cœur

La commande de téléchargement récupère la dernière version dans la langue choisie et la décompresse dans le répertoire courant. Elle vérifie l'intégrité de l'archive, ce qui vaut mieux qu'un téléchargement manuel. Le choix de la langue à ce stade évite d'avoir à installer un paquet de traduction ensuite, détail mineur qui fait gagner quelques minutes et surtout qui donne une installation cohérente dès le départ. La commande accepte également une version précise, ce qui sert lors d'une reprise de site où l'on veut reproduire un environnement existant.

Générer le fichier de configuration

La commande dédiée écrit le fichier de configuration avec les paramètres de connexion et génère automatiquement les clés de sécurité, qui sont trop souvent laissées à leur valeur par défaut sur les installations manuelles. Elle permet également de définir un préfixe de table personnalisé, mesure de sécurité modeste mais gratuite. C'est le moment de choisir ces valeurs, leur modification ultérieure demandant une intervention en base. Le fichier ainsi produit reste parfaitement modifiable ensuite pour y ajouter les constantes propres au projet.

Lancer l'installation

Une seule commande crée les tables, le compte administrateur et les réglages de base, en prenant le titre du site, l'adresse, l'identifiant et le courriel en paramètres. Le mot de passe doit être fourni explicitement plutôt que laissé à la génération automatique si l'on veut le maîtriser, et il ne doit évidemment pas figurer dans un script versionné. Cette étape remplace intégralement l'assistant d'installation par navigateur, en quelques secondes. Un identifiant autre que le classique nom générique d'administrateur est également préférable, ne serait ce que pour réduire le bruit des tentatives automatisées.

Configurer le serveur web

Un hôte virtuel pointant vers le répertoire du site, avec la prise en charge de l'interpréteur, suffit pour un site simple. Les réglages de performance de l'interpréteur méritent une attention particulière sur un serveur peu doté, sujet que nous traitons dans notre article sur la manière de configurer PHP-FPM pour un trafic modéré. Les valeurs par défaut conviennent rarement à la mémoire réellement disponible sur une petite machine.

Poser le certificat

L'obtention d'un certificat gratuit et sa configuration automatique tiennent en une commande avec l'outil approprié. Cette opération doit intervenir avant la première visite publique, car changer l'adresse du site de la version en clair vers la version sécurisée une fois du contenu publié demande de reprendre les adresses enregistrées en base. Prendre cette précaution au bon moment économise une heure de manipulations désagréables. Le renouvellement automatique doit être vérifié dans la foulée, en forçant un renouvellement de test.

Sécuriser et configurer

Ces réglages se font juste après l'installation et avant toute publication. Les repousser signifie qu'ils ne seront jamais faits, constat vérifiable sur la quasi totalité des serveurs que nous reprenons.

Régler les droits sur les fichiers

Les fichiers doivent appartenir à l'utilisateur du site et être lisibles par le serveur web, sans être modifiables par lui à l'exception du répertoire de téléversement. Des droits trop larges permettent à un script compromis d'écrire n'importe où, des droits trop stricts empêchent les mises à jour automatiques. L'équilibre habituel consiste à donner la propriété à l'utilisateur du serveur web sur les seuls répertoires qui doivent être écrits, et à laisser le reste en lecture seule. Sur une installation où les mises à jour se font en ligne de commande, le serveur web n'a besoin d'écrire que dans le répertoire de téléversement.

Protéger les fichiers sensibles

Le fichier de configuration ne doit être lisible que par son propriétaire. Les fichiers de sauvegarde, les archives et les exports de base ne doivent jamais séjourner dans un répertoire servi publiquement. Ce dernier point est la cause d'un nombre étonnant de fuites de données, généralement une archive laissée à la racine après une migration et découverte par un robot des mois plus tard, quand tout le monde l'avait oubliée. Un répertoire de travail placé en dehors de l'arborescence servie règle définitivement la question.

Désactiver l'édition de fichiers

WordPress permet par défaut de modifier le code des thèmes et extensions depuis l'administration. Cette fonction transforme un compte administrateur compromis en accès complet au serveur. Une constante dans le fichier de configuration la désactive, et personne n'utilise sérieusement cet éditeur pour travailler. C'est la mesure de sécurité au meilleur rapport entre effort et bénéfice de toute la liste. Une seconde constante, interdisant l'installation d'extensions depuis l'administration, complète utilement le dispositif sur les sites gérés par déploiement.

Mettre en place les tâches planifiées

Le mécanisme interne de WordPress se déclenche au passage d'un visiteur, ce qui est imprévisible sur un site peu fréquenté. Sur un serveur dont on dispose, il vaut mieux le désactiver et le déclencher par une tâche système à intervalle régulier. Cette configuration rend l'exécution fiable et évite qu'un article programmé ne reste en attente faute de visite, situation particulièrement gênante sur un site publiant à heure fixe. Un intervalle de cinq minutes convient à la plupart des usages et reste sans effet notable sur la charge.

Configurer l'envoi de courriels

Un serveur neuf n'envoie pas de courriels dans de bonnes conditions : ses messages partent sans authentification et finissent en indésirables ou sont rejetés. Le passage par un service d'envoi tiers, configuré dès l'installation, évite de découvrir le problème le jour où un client ne reçoit pas sa confirmation de commande. Ce point est systématiquement découvert trop tard sur les installations faites dans l'urgence. Un test d'envoi immédiatement après la configuration, vers une adresse externe, suffit à s'assurer que tout fonctionne.

Mettre en place les sauvegardes

Une sauvegarde comprend la base de données et le répertoire de téléversement, les fichiers du cœur et des extensions étant reconstructibles. Elle doit être déposée ailleurs que sur la machine sauvegardée, faute de quoi elle disparaît avec elle. Un script quotidien et une conservation sur trente jours constituent un minimum raisonnable. La sauvegarde doit surtout être testée par une restauration réelle, seul moyen de savoir si elle vaut quelque chose. Un test de restauration par trimestre, sur une machine jetable, transforme une sauvegarde théorique en sauvegarde réelle.

Exploiter au quotidien

Le vrai coût d'un serveur géré en propre n'est pas son installation mais son entretien, qui doit être organisé dès le premier jour.

Mettre à jour régulièrement

Les mises à jour du système, du cœur et des extensions doivent suivre un rythme défini plutôt que dépendre de la disponibilité de quelqu'un. L'outil en ligne de commande permet de les lancer, de les vérifier et de les rejouer sur plusieurs sites en une seule opération. Une session hebdomadaire d'un quart d'heure suffit sur un site unique et évite l'accumulation qui rend chaque mise à jour risquée. Une sauvegarde immédiatement avant la session de mise à jour rend l'opération réversible en quelques minutes.

Surveiller la machine

L'espace disque, la charge, la mémoire disponible et la validité du certificat sont les quatre grandeurs à surveiller. Une saturation du disque, souvent causée par les journaux ou par des sauvegardes qui s'accumulent, provoque des pannes difficiles à diagnostiquer quand on n'y pense pas. Une alerte simple sur ces quatre points, envoyée par courriel, coûte quelques minutes de configuration et évite la majorité des incidents. Un contrôle externe de disponibilité complète ce dispositif en signalant ce que la machine elle même ne peut pas rapporter.

Lire les journaux

Les journaux du serveur web et ceux de l'interpréteur contiennent la trace de tout ce qui se passe mal. Les consulter une fois par semaine, ne serait ce que pour compter les erreurs, permet de repérer une régression avant qu'un visiteur ne la signale. Une rotation correcte de ces fichiers est indispensable, faute de quoi ils finissent par remplir le disque, cause de panne fréquente et parfaitement évitable. Activer l'écriture des erreurs PHP dans un fichier dédié, sans les afficher aux visiteurs, est le réglage de départ à retenir.

Automatiser ce qui se répète

Toutes les commandes utilisées pour l'installation gagnent à être rassemblées dans un script, testé sur une machine jetable. Ce script transforme une réinstallation en opération de quinze minutes et sert de documentation exécutable de la configuration. C'est le meilleur investissement du projet, et il se rentabilise dès la deuxième installation ou dès le premier incident sérieux. Il doit être conservé avec le projet et mis à jour à chaque modification de la configuration du serveur.

Prévoir un environnement de test

Une copie du site sur laquelle essayer les mises à jour et les modifications évite d'apprendre en production. Sur un serveur privé, elle peut vivre sur la même machine dans un répertoire séparé avec une base distincte, à condition qu'elle ne soit pas indexable et qu'elle soit protégée par un mot de passe. Ce dispositif coûte une demi heure et change complètement la sérénité des interventions. Une commande de recopie de la production vers la préproduction, écrite une fois, rend cette copie utilisable en permanence.

Savoir quand ce n'est pas le bon choix

Un serveur géré en propre suppose de consacrer du temps à son entretien, tous les mois, indéfiniment. Pour un site vitrine sans contrainte particulière, un hébergement mutualisé de qualité rend le même service sans cette charge. Le serveur privé se justifie par un besoin réel : configuration particulière, volumétrie, plusieurs sites à mutualiser, contraintes de confidentialité. Choisir cette voie par goût technique sans mesurer la charge d'entretien est une décision que l'on regrette généralement au bout d'un an. La bonne question à se poser avant de commencer est de savoir qui s'occupera de la machine dans dix huit mois, et si cette personne aura le temps de le faire. Cette question se pose au commanditaire et non au prestataire technique, car elle relève d'un arbitrage de coût plutôt que d'une préférence d'outil.