Comment résoudre les problèmes courants d’un site sur un serveur Linux

Introduction

Tout le monde rencontre des problèmes avec son serveur web ou son site de temps à autre. Apprendre où chercher lorsqu'on rencontre un problème et quels composants sont probablement responsables vous aidera à résoudre ces problèmes aussi rapidement et efficacement que possible.

Dans ce guide, vous apprendrez à comprendre comment résoudre ces problèmes afin de pouvoir remettre votre site en marche.

Quels types de problèmes sont typiques ?

La majorité des problèmes que vous rencontrerez en essayant de mettre votre site en ligne relèvent d'un spectre prévisible.

Nous examinerons ces points plus en détail dans les sections ci-dessous, mais pour l'instant, voici une liste de contrôle des éléments à examiner :

• Votre serveur web est-il installé ?
• Le serveur web fonctionne-t-il ?
• La syntaxe de vos fichiers de configuration de serveur web est-elle correcte ?
• Les ports que vous avez configurés sont-ils ouverts (non bloqués par un pare-feu) ?
• Vos paramètres DNS vous dirigent-ils vers le bon endroit ?
• La racine du document pointe-t-elle vers l'emplacement de vos fichiers ?
• Votre serveur web sert-il les fichiers index corrects ?
• Les autorisations et la propriété des fichiers et des structures de répertoires sont-elles correctes ?
• Restreignez-vous l'accès via vos fichiers de configuration ?
• Si vous avez un backend de base de données, est-il en fonctionnement ?
• Votre site peut-il se connecter à la base de données avec succès ?

Voici quelques-uns des problèmes courants auxquels les administrateurs sont confrontés lorsqu'un site ne fonctionne pas correctement. Le problème exact peut généralement être identifié en examinant les fichiers journaux des différents composants et en consultant les pages d'erreur affichées dans votre navigateur.

Ci-dessous, nous passerons en revue chacun de ces scénarios afin que vous puissiez vous assurer que vos services sont configurés correctement.

Vérifiez les journaux

Avant de chercher aveuglément à résoudre un problème, essayez de vérifier les journaux de votre serveur web et de tous les composants associés. Ceux-ci se trouvent généralement dans /var/log dans un sous-répertoire spécifique au service.

Par exemple, si vous avez un serveur Apache fonctionnant sur un serveur Ubuntu, par défaut les journaux seront conservés dans /var/log/apache2. Vérifiez les fichiers dans ce répertoire pour voir quel type de messages d'erreur est généré. Si vous avez un backend de base de données qui vous pose problème, il conservera probablement ses journaux dans /var/log également.

D'autres choses à vérifier sont si les processus eux-mêmes vous laissent des messages d'erreur lorsque les services sont démarrés. Si vous essayez de visiter une page web et obtenez une erreur, la page d'erreur peut aussi contenir des indices (bien que pas aussi spécifiques que les lignes dans les fichiers journaux).

Utilisez un moteur de recherche pour essayer de trouver des informations pertinentes qui peuvent vous orienter dans la bonne direction. Dans de nombreux cas, il peut être utile de coller un extrait de vos journaux directement dans un moteur de recherche pour trouver d'autres exemples du même problème. Les étapes ci-dessous peuvent vous aider à poursuivre le dépannage.

Votre serveur Web est-il installé ?

La première chose dont vous aurez probablement besoin pour diffuser correctement vos sites est un serveur web. Dans certains cas, vos pages web peuvent être servies directement par un conteneur Docker ou une autre application, et vous n’aurez en réalité pas besoin d’installer un serveur web dédié, mais la plupart des déploiements incluront toujours au moins un.

La plupart des gens auront installé un serveur avant d'en arriver à ce point, mais il existe certaines situations où vous avez peut-être en fait désinstallé le serveur par accident en effectuant d'autres opérations sur les packages.

Si vous utilisez un système Ubuntu ou Debian et que vous devez installer le serveur web Apache, vous pouvez taper :

sudo apt-get update

sudo apt-get install apache2

Sur ces systèmes, le processus Apache s'appelle apache2.

Si vous utilisez Ubuntu ou Debian et souhaitez le serveur web Nginx, vous pouvez plutôt taper :

sudo apt-get update

sudo apt-get install nginx

Sur ces systèmes, le processus Nginx s'appelle nginx.

Si vous utilisez RHEL, Rocky Linux ou Fedora et devez utiliser le serveur web Apache, vous pouvez taper :

sudo dnf install httpd

Sur ces systèmes, le processus Apache est appelé httpd.

Si vous utilisez RHEL, Rocky Linux ou Fedora et que vous voulez utiliser Nginx, vous pouvez taper ceci. Encore une fois, retirez le « sudo » si vous êtes connecté en tant que root :

sudo dnf install nginx

Sur ces systèmes, le processus Nginx s'appelle nginx. Contrairement à Ubuntu, Nginx n'est pas démarré automatiquement après son installation sur ces distributions basées sur RPM. Lisez la suite pour apprendre comment le démarrer.

Votre serveur Web fonctionne-t-il ?

Maintenant que vous êtes sûr que votre serveur est installé, fonctionne-t-il ?

Il existe de nombreuses façons de savoir si le service fonctionne ou non. Une méthode qui est assez multiplateforme consiste à utiliser la commande netstat.

Exécuter netstat avec les options -plunt vous indiquera tous les processus qui utilisent des ports sur le serveur. Pour en savoir plus sur l'exécution de netstat, vous pouvez vous référer à Comment Utiliser Top, Netstat, Du et d'Autres Outils pour Surveiller les Ressources du Serveur. Vous pouvez ensuite grep la sortie de netstat pour le nom du processus que vous recherchez :

sudo netstat -plunt | grep nginx

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      15686/nginx: master
tcp6       0      0 :::80                   :::*                    LISTEN      15686/nginx: master

Vous pouvez changer nginx par le nom du processus du serveur web sur votre serveur. Si vous voyez une ligne comme celle ci-dessus, cela signifie que votre processus est en cours d'exécution. Si vous n'obtenez aucune sortie, cela signifie que vous avez interrogé le mauvais processus ou que votre serveur web n'est pas en cours d'exécution.

Si votre serveur web ne fonctionne pas, vous pouvez le démarrer en utilisant le système init de votre distribution Linux. La plupart des logiciels conçus pour s'exécuter en arrière-plan s'enregistreront auprès du système init après avoir été installés, afin que vous puissiez les démarrer et les arrêter de manière programmée. La plupart des distributions utilisent également maintenant le même système init, systemd, qui fournit la commande systemctl.

Par exemple, vous pourriez démarrer le service nginx en tapant :

sudo systemctl start nginx

Si votre serveur web démarre, vous pouvez vérifier à nouveau avec netstat pour confirmer que tout est correct.

La syntaxe de votre fichier de configuration de serveur Web est-elle correcte ?

Si votre serveur web n'a pas pu démarrer, cela indique généralement que vos fichiers de configuration nécessitent une attention particulière. Apache et Nginx exigent tous deux un respect strict de leur syntaxe afin que leur configuration soit analysée correctement.

Les fichiers de configuration des services système se trouvent généralement dans un sous-répertoire du répertoire /etc/ portant le nom du processus lui-même.

Par exemple, vous pouvez accéder au répertoire principal de configuration d'Apache sur Ubuntu en tapant :

cd /etc/apache2

Le répertoire de configuration d'Apache sur RHEL, Rocky et Fedora reflète également le nom RHEL pour ce processus :

cd /etc/httpd

La configuration sera répartie entre de nombreux fichiers différents. Lorsqu'on tente en vain de démarrer un service, cela produira généralement des erreurs indiquant le fichier de configuration et la ligne où le problème a été trouvé pour la première fois. Vous pouvez commencer à examiner ce fichier.

Chacun de ces serveurs web fournit également un moyen de valider la syntaxe de configuration de vos fichiers.

Si vous utilisez Apache, vous pouvez utiliser la commande apache2ctl ou apachectl pour vérifier vos fichiers de configuration pour des erreurs de syntaxe :

apache2ctl configtest

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK

Syntax OK signifie essentiellement qu'il n'y a pas d'erreurs majeures empêchant le serveur de fonctionner, et que chaque message affiché avant cela est une erreur mineure ou un avertissement. Dans ce cas, Impossible de déterminer de manière fiable le nom de domaine complet du serveur reflète une configuration Apache standard sur un serveur qui n'a pas encore été configuré avec un nom de domaine, mais qui devrait tout de même être accessible via son adresse IP.

Si vous avez un serveur web Nginx, vous pouvez exécuter un test similaire en tapant :

sudo nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Si vous supprimez un point-virgule à la fin d'une ligne de configuration dans /etc/nginx/nginx.conf (une erreur courante pour les configurations Nginx), vous obtiendrez un message comme celui-ci :

sudo nginx -t 

nginx: [emerg] invalid number of arguments in "tcp_nopush" directive in /etc/nginx/nginx.conf:18
nginx: configuration file /etc/nginx/nginx.conf test failed

Il y a un nombre invalide d'arguments parce que Nginx cherche un point-virgule pour terminer les instructions. S'il n'en trouve pas, il passe à la ligne suivante et l'interprète comme des arguments supplémentaires pour la dernière ligne.

Vous pouvez exécuter ces tests afin de trouver des problèmes de syntaxe dans vos fichiers. Corrigez les problèmes auxquels il fait référence jusqu'à ce que vous puissiez faire passer les fichiers au test.

Les ports que vous avez configurés sont-ils ouverts ?

En général, les serveurs web fonctionnent sur le port 80 pour le trafic web HTTP et utilisent le port 443 pour le trafic HTTPS chiffré avec TLS/SSL. Pour que les utilisateurs puissent accéder à votre site, ces ports doivent être accessibles.

Vous pouvez tester si votre serveur a son port ouvert en exécutant netcat depuis votre machine locale.

Vous devrez utiliser l'adresse IP de votre serveur distant et lui indiquer quel port vérifier, comme ceci :

nc -z 111.111.111.111 80

Cela vérifiera si le port 80 est ouvert sur le serveur à 111.111.111.111. S'il est ouvert, la commande renverra immédiatement. S'il n'est pas ouvert, la commande tentera continuellement d'établir une connexion, sans succès. Vous pouvez arrêter ce processus en appuyant sur CTRL+C dans la fenêtre du terminal.

Si vos ports web ne sont pas accessibles, vous devriez examiner la configuration de votre pare-feu. Il se peut que vous deviez ouvrir le port 80 ou le port 443.

Vos paramètres DNS vous dirigent-ils vers le bon endroit ?

Si vous pouvez accéder à votre site via son adresse IP, mais pas par un nom de domaine que vous avez configuré, vous devrez peut-être examiner vos paramètres DNS.

Afin que les visiteurs puissent accéder à votre site via son nom de domaine, vous devez avoir un enregistrement « A » ou « AAAA » pointant vers l'adresse IP de votre serveur dans les paramètres DNS. Vous pouvez interroger l'enregistrement « A » de votre domaine en utilisant la commande host sur un ordinateur local ou :

host -t A example.com

example.com has address 93.184.216.119

La ligne qui vous est renvoyée doit correspondre à l'adresse IP de votre serveur. Si vous devez vérifier un enregistrement « AAAA » (pour les connexions IPv6), vous pouvez taper :

host -t AAAA example.com

example.com has IPv6 address 2606:2800:220:6d:26bf:1447:1097:aa7

Gardez à l'esprit que toute modification apportée à vos enregistrements DNS peut prendre un certain temps pour se propager, selon votre registraire de nom de domaine. Il peut parfois être utile d'utiliser un site comme https://www.whatsmydns.net/ pour vérifier quand vos changements DNS sont effectifs dans le monde entier (généralement une demi-heure environ). Vous pouvez recevoir des résultats incohérents à ces requêtes après une modification, car votre demande atteindra souvent différents serveurs qui ne sont pas encore tous à jour.

Si vous utilisez Linux-Console.net, vous pouvez apprendre comment configurer les paramètres DNS de votre domaine ici.

Assurez-vous que vos fichiers de configuration gèrent également correctement votre domaine

Si vos paramètres DNS sont corrects, vous pouvez également vérifier vos fichiers d'hôtes virtuels Apache ou les fichiers de blocs serveur Nginx pour vous assurer qu'ils sont configurés pour répondre aux requêtes pour votre domaine.

Dans Apache, votre fichier d’hôte virtuel pourrait ressembler à ceci :

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    ServerAdmin admin@example.com
    DocumentRoot /var/www/html
. . .

Cet hôte virtuel est configuré pour répondre à toutes les requêtes sur le port 80 pour le domaine example.com.

Un bloc similaire dans Nginx pourrait ressembler à quelque chose comme ceci :

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name example.com www.example.com;
. . .

Ces deux blocs sont configurés pour répondre aux mêmes types de demandes par défaut.

La racine du document pointe-t-elle vers l'emplacement de vos fichiers ?

Une autre considération est de savoir si votre serveur web est pointé vers le bon emplacement de fichier.

Chaque serveur virtuel dans Apache ou bloc serveur dans Nginx est configuré pour pointer vers un port spécifique ou un répertoire local. Si cela est mal configuré, le serveur affichera un message d'erreur lorsque vous essayerez d'accéder à la page.

Dans Apache, la racine des documents est configurée via la directive DocumentRoot :

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    ServerAdmin admin@example.com
    DocumentRoot /var/www/html
. . .

Cette ligne indique à Apache qu'il doit chercher les fichiers pour ce domaine dans le répertoire /var/www/html. Si vos fichiers sont conservés ailleurs, vous devrez modifier cette ligne pour indiquer l'emplacement correct.

Dans Nginx, la directive root configure la même chose :

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name example.com www.example.com;
. . .

Dans cette configuration, Nginx recherche les fichiers pour ce domaine dans le répertoire /usr/share/nginx/html.

Votre serveur Web sert-il les fichiers d'index corrects ?

Si la racine de votre document est correcte et que vos pages d'index ne sont pas servies correctement lorsque vous accédez à votre site ou à un emplacement de répertoire sur votre site, il se peut que vos index soient configurés incorrectement.

Selon la complexité de vos applications web, de nombreux serveurs web continueront de servir par défaut des fichiers index. Il s'agit généralement d'un fichier index.html ou d'un fichier index.php en fonction de votre configuration.

Dans Apache, vous pouvez trouver une ligne dans votre fichier de virtual host qui configure explicitement l'ordre des index qui sera utilisé pour des répertoires spécifiques, comme ceci :

<Directory /var/www/html>
    DirectoryIndex index.html index.php
</Directory>

Cela signifie que lorsque le répertoire est servi, Apache cherchera d'abord un fichier appelé index.html, et essaiera de servir index.php en tant que secours si le premier fichier n'est pas trouvé.

Vous pouvez définir l'ordre qui sera utilisé pour servir les fichiers index pour l'ensemble du serveur en éditant le fichier mods-enabled/dir.conf, ce qui définira les valeurs par défaut pour le serveur. Si votre serveur ne sert pas de fichier index, assurez-vous d'avoir un fichier index dans votre répertoire qui correspond à l'une des options de votre fichier.

Dans Nginx, la directive qui fait cela s'appelle index et elle est utilisée ainsi :

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name example.com www.example.com;
. . .

Les autorisations et la propriété sont-elles correctement définies ?

Pour que le serveur web puisse correctement servir les fichiers, il doit pouvoir lire les fichiers et avoir accès aux répertoires où ils sont conservés. Cela peut être contrôlé par les permissions et la propriété des fichiers et répertoires.

Pour lire des fichiers, les répertoires contenant le contenu doivent être lisibles et exécutables par le compte utilisateur associé au serveur web. Sur Ubuntu et Debian, Apache et Nginx s'exécutent en tant qu'utilisateur www-data qui est membre du groupe www-data.

Sur RHEL, Rocky et Fedora, Apache fonctionne sous un utilisateur appelé apache qui appartient au groupe apache. Nginx fonctionne sous un utilisateur appelé nginx qui fait partie du groupe nginx.

Dans cet esprit, vous pouvez regarder les fichiers et dossiers que vous hébergez :

ls -l /path/to/web/root

Les répertoires doivent être lisibles et exécutables par l'utilisateur ou le groupe web, et les fichiers doivent être lisibles afin de lire le contenu. Pour pouvoir télécharger, écrire ou modifier le contenu, les répertoires doivent également être inscriptibles et les fichiers doivent aussi être inscriptibles.

Pour modifier la propriété d'un fichier, vous pouvez utiliser chown :

sudo chown user_owner:group_owner /path/to/file

Cela peut également être fait sur un répertoire. Vous pouvez changer la propriété d'un répertoire et de tous les fichiers qu'il contient en utilisant l'option -R :

sudo chown -R user_owner:group_owner /path/to/file

Pour en savoir plus sur les permissions, consultez Une introduction aux permissions Linux.

Restreignez-vous l'accès via vos fichiers de configuration ?

Les paramètres de votre serveur web peuvent également être configurés pour refuser l'accès aux fichiers que vous essayez de servir.

Dans Apache, cela serait configuré dans le fichier d'hôte virtuel pour ce site, ou via un fichier .htaccess situé dans le répertoire lui-même.

Dans ces fichiers, il est possible de restreindre l'accès de plusieurs manières différentes. Les répertoires peuvent être restreints ainsi dans Apache 2.4+):

<Directory /usr/share>
    AllowOverride None
    Require all denied
</Directory>

Dans Nginx, ces restrictions prendront la forme de directives deny et seront situées dans vos blocs de serveur ou vos fichiers de configuration principaux :

location /usr/share {
    deny all;
}

Si vous avez un backend de base de données, est-il en fonctionnement ?

Si votre site dépend d'une base de données comme MySQL, PostgreSQL, MongoDB, etc., vous devez vous assurer qu'elle est opérationnelle et disponible.

Vous pouvez faire cela de la même manière que vous avez vérifié que le serveur web fonctionnait. Encore une fois, vous pouvez rechercher parmi les processus en cours d'exécution avec netstat et grep :

sudo netstat -plunt | grep mysql

tcp        0      0 127.0.0.1:3306        0.0.0.0:*         LISTEN      3356/mysqld

Comme vous pouvez le voir, le service fonctionne sur cette machine. Assurez-vous de connaître le nom sous lequel votre service s'exécute lors de sa recherche.

Une alternative consiste à rechercher le port sur lequel votre service fonctionne. Consultez la documentation de votre base de données pour trouver le port par défaut sur lequel elle fonctionne (MySQL utilise par défaut le 3356), ou vérifiez vos fichiers de configuration.

Si vous avez un backend de base de données, votre site peut-il se connecter avec succès ?

L'étape suivante à suivre si vous dépannez un problème avec un backend de base de données est de voir si vous pouvez vous connecter correctement. Cela signifie généralement vérifier les fichiers que votre site lit pour trouver les informations de la base de données.

Par exemple, pour un site WordPress, les paramètres de connexion à la base de données sont stockés dans un fichier appelé wp-config.php. Vous devez vérifier que DB_NAME, DB_USER et DB_PASSWORD sont corrects afin que votre site puisse se connecter à la base de données.

Vous pouvez vérifier si le fichier contient les informations correctes en essayant de vous connecter à la base de données manuellement depuis la ligne de commande. La plupart des bases de données prendront en charge une syntaxe similaire à MySQL :

mysql -u DB_USER_value -pDB_PASSWORD_value DB_NAME_value

Si vous ne pouvez pas vous connecter en utilisant les valeurs que vous avez trouvées dans le fichier, vous devrez peut-être modifier les autorisations d'accès de vos bases de données.

Si tout échoue, vérifiez à nouveau les journaux

Vérifier les journaux devrait en fait être votre première étape, mais c'est aussi une bonne dernière étape avant de demander plus d'aide.

Si vous avez atteint la limite de votre capacité à résoudre les problèmes par vous-même et que vous avez besoin d'aide, vous obtiendrez une aide plus pertinente et plus rapide en fournissant des fichiers journaux et des messages d'erreur. Les administrateurs expérimentés auront probablement une bonne idée de ce qui se passe si vous leur donnez les informations dont ils ont besoin.

Conclusion

Espérons que ces conseils de dépannage vous auront aidé à localiser et à résoudre certains des problèmes les plus courants auxquels les administrateurs sont confrontés lorsqu'ils essaient de mettre leurs sites en ligne.

Si vous avez des conseils supplémentaires sur des points à vérifier et des méthodes de résolution de problèmes, veuillez les partager avec les autres utilisateurs dans les commentaires.