Mon nouveau disque se transforme en Spare pendant la reconstruction du RAID

Laisser une réponse

Tête et plateau d'un disque dur ayant subi un « Head crash »

Tête et plateau d’un disque dur ayant subi un « Head crash »

Après avoir démarré la reconstruction du RAID d’un client, suite au remplacement d’un disque, le résultat escompté n’est pas arrivé : l’ensemble des deux disques ne sont pas synchronisés. Pire encore, le disque remplacé est passé en statut « spare » au lieu de « active » ! Mais que c’est-il passé ?

Pour analyser ce qu’il est passé, j’ai eu recours à la commande « mdadm --detail » :

# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Sun May 27 11:26:05 2012
     Raid Level : raid1
     Array Size : 1953511288 (1863.01 GiB 2000.40 GB)
  Used Dev Size : 1953511288 (1863.01 GiB 2000.40 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Mon May 28 11:16:49 2012
          State : clean, degraded 
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 1

           Name : swraid  (local to host Debian)
           UUID : 81c1d8e5:27f6f8b9:9cdc99e6:9d92a1cf
         Events : 32365

    Number   Major   Minor   RaidDevice State
       1       8       33        0      faulty sync   /dev/sda1
       1       0        0        1      removed

       2       8       17        -      spare   /dev/sdb1

On constate ici deux choses :

  • sda1 fait encore partie du RAID, il fait encore partie des disques synchronisés mais est marqué comme défectueux
  • sdb1 est bien présent sur la grappe raid, mais en tant que disque de réserve

Après avoir exécuté la commande « dmesg » il est apparu que lors de la synchronisation des partitions de la grappe RAID se sont produit des erreurs de lecture. Ces erreurs de lecture ont eu lieu sur le disque sda1, qui est actuellement le seul disque contenant les données du volume RAID. Ce scénario est l’un des plus mauvais lorsqu’on tente de restaurer une grappe RAID. En effet, il n’est plus possible de compter sur le seul disque contenant les données, puisque pendant la lecture de ce disque des erreurs se produisent.

Il reste deux solutions à envisager : si on dispose de sauvegardes récentes du contenu de la grappe RAID, il est plus judicieux de récupérer les données à partir de celles-ci : on est certain de retrouver des données dans un état homogène en un minimum de temps. Dans le cas encore trop fréquent où aucune sauvegarde n’est disponible, il va falloir récupérer « les données à la petite cuillère », puisque les données se trouvent sur un disque en train de mourir à petit feu.

Pour restaurer les données, il existe deux optiques possibles : restaurer le maximum de fichiers complets en ignorant les fichiers illisibles, ou récupérer le maximum de données, y compris des fichiers incomplets.

Récupérer le maximum de données par une copie bit à bit de partition

Restaurer une partition complète est globalement plus long que la copie de fichiers mais reste la seule manière de copier un système de fichier endommagé.

GNU ddrescue

L’outil « ddrescue » est un outil qui va s’occuper de récupérer dans un premier temps l’ensemble des données lisibles, pour revenir plus tard sur les zones illisibles et tenter de récupérer les derniers octets qui peuvent encore être lus. Le but est de créer une copie bit à bit du disque défaillant sur le disque neuf qui vient de passer en spare. Voici un exemple de commande :

# ddrescue -f -n /dev/sda1 /dev/sdb1 mapfile

dd_rescue associé à dd_rhelp

La commande « dd_rescue » permet de maximiser la récupération des données en lisant à l’infini les secteurs défectueux du premier au dernier secteur et inversement. Associé au script « dd_rhelp », il devient un outil puissant et automatisé de copie bit à bit de données, tout en essayant des stratégies de lectures originales pour récupérer des données. Voici un exemple de commande :

# dd_rhelp /dev/sda /dev/sdb

Récupérer les fichiers encore complètement lisible

Récupérer uniquement les fichiers présents sur un volume RAID en mauvais état est plus rapide car le volume de données est plus faible, et permet de récupérer en général un grand nombre de fichiers. Le bonus serait qu’aucun des fichiers présent sur la partition n’utilise la partie endommagée du disque, mais il vaut mieux ne pas compter là-dessus.

rsync

S’il est encore possible de monter le volume RAID, il est très certainement possible de récupérer une bonne partie des fichiers de la partition. Pour cela, il faut utiliser un utilitaire de copie qui ignorer les erreurs comme la commande « rsync ». Voici un exemple de commande :

# rsync --archive --hard-links --acls --xattrs --ignore-errors /mnt/broken-partition /mnt/new-partition

Je ne peux pas avoir perdu de données, j’utilise du RAID matériel !

Laisser une réponse

Carte RAID matérielle

Carte RAID matérielle

Dernièrement, après avoir eu la mission d’analyser un serveur qui ne démarrait plus, j’ai dû annoncer à un client une perte de données. Le client était totalement abasourdi et furieux, car on lui avait vendu le RAID matériel comme étant « la solution » pour ne jamais perdre de données.

Beaucoup de commerciaux vont vanter les bénéfices du RAID matériel avec comme argument une plus grande fiabilité que le RAID logiciel, pour pouvoir placer une carte RAID dans un serveur ou un serveur avec du RAID matériel. Cet argument est possiblement correct. Si le client n’est pas totalement convaincu, le commercial va asséner son argument massue : « Avec du RAID matériel, tout est géré par la carte RAID, c’est beaucoup plus facile et simple parce que c’est automatique ». Et cet argument massue va convaincre le client, et l’induire en erreur.

Quand une carte RAID va détecter des soucis sur un disque (valeurs SMART limite, erreurs de lecture/écriture, …), celle-ci va faire son travail automatiquement : éjecter le disque défectueux du RAID, et marquer le RAID comme dégradé. L’effet pervers du RAID matériel est qu’il est effectivement automatisé, et surtout très silencieux : lorsque le RAID passe en mode dégradé, dans de très nombreux cas, cela s’effectue de manière transparente pour le serveur, qui au mieux constatera quelques lenteurs, et puis plus rien du tout une fois le disque éjecté du RAID. Aucune information ne sera renvoyé à l’administrateur du serveur. A partir de ce moment-là, pour peu que le RAID soit du RAID1, la prochaine défaillance du seul disque restant fonctionnel sera fatale aux données.

La prochaine défaillance sera la seule qui se fera remarquer : des lenteurs voire des erreurs de lecture / écriture récurrente vont apparaitre. Et malheureusement, à ce stade-là, il est fort probable d’avoir déjà perdu des données, car le dernier disque en fonction commence à ne plus fonctionner correctement.

Pour éviter d’arriver à une perte de données, il est indispensable de mettre ne place un monitoring du RAID matériel : le constructeur de la carte fournit dans la majorité des cas un utilitaire qui va au moins permettre de consulter l’état du RAID. Dans de rare cas, il est possible de se faire envoyer un email lorsqu’un événement nécessitant une intervention humaine se présente.

Il existe un site web qui regroupe des informations sur comment surveiller l’était d’un RAID avec les principales carte RAID matérielle du marché :
http://hwraid.le-vert.net/

Que le RAID soit matériel ou logiciel, mettre en place une surveillance du RAID va permettre de s’assurer une continuité de service (ou tout du moins, des coupures les plus courtes possibles), et surtout d’éviter la perte de données !

Je viens de patcher la dernière faille à la mode, mais je suis toujours vulnérable ?

Laisser une réponse

Test de vulnérabilité à la faille Heartbleed

Test de vulnérabilité à la faille Heartbleed

Vous venez de mettre à jour votre distribution pour vous protéger de la dernière faille de sécurité de la librairie OpenSSL, OpenSSH, etc., … Comme vous êtes consciencieux, vous avez vérifié que vous étiez vulnérable avant d’effectuer la mise à jour, et vous vérifiez aussi que vous n’êtes plus vulnérable après la mise à jour.
Quelle n’est pas votre surprise quand, après avoir mis à jour, vous êtes toujours vulnérable ?

Pourquoi la mise à jour n’est pas suffisante ?

Lorsque votre distribution mets à jour une librairie, ou tout autre package, le processus se déroule en 4 étapes :

  1. Chargement du nouveau package
  2. Suppression des fichiers de la version actuelle du package
  3. Extraction des fichiers de la nouvelle version du package
  4. Configuration éventuelle de la nouvelle version

Lors de la suppression d’un fichier sous Linux, seule la référence entre le contenu du fichier et le nom de fichier dans le dossier est réellement supprimée : toute autre référence à ce fichier (ou plutôt son contenu) reste valide. Un service ou un processus qui a été démarré avant la mise à jour fera toujours usage de la version précédente de la librairie, car les références à celle-ci se feront toujours vers le contenu de l’ancien fichier. Le contenu de l’ancienne version disparaîtra (ou plutôt ne sera plus référencé) qu’une fois tous les processus l’utilisant stoppés.

Comment être sûr de ne plus utiliser une ancienne version des librairies ?

Afin de s’assurer que tout les processus utilisent bien les versions à jours des librairies, il faut déterminer si aucun ne fait encore appel à une version supprimée d’une librairie. La commande « lsof » (LiSt Open Files) permet d’effectuer cette vérification. Vous trouverez ci-dessous la commande destinée à cet effet :

lsof +L1 | grep -E "(/usr/bin|/usr/sbin|/bin/|/sbin|/lib|/usr/lib|/usr/local/lib|/usr/local/bin|/usr/local/sbin|^COMMAND)"

La commande « lsof +L1 » affiche quels sont les processus qui font référence à un fichier ne comportant plus aucun lien dans un système de fichier qui est donc un fichier supprimé. La commande « grep -E "(/usr/bin|/usr/sbin|/bin/|/sbin|/lib|/usr/lib|/usr/local/lib|/usr/local/bin|/usr/local/sbin|^COMMAND)" » permet de limiter le listing des fichiers à un certain nombre de dossiers prévus pour contenir les librairies :

  • /usr/bin
  • /usr/sbin
  • /bin
  • /sbin
  • /lib
  • /usr/lib
  • /usr/local/lib
  • /usr/local/bin
  • /usr/local/sbin

Si votre distribution stocke des librairies dans d’autres dossiers, il suffit d’ajouter ces dossiers à la commande. Comme c’est plus simple de savoir à quoi correspondent les colonnes du listing, la première ligne de la commande « lsof » est conservée.

Si un processus apparait, il va falloir le redémarrer si c’est un service, ou fermer l’application et la rouvrir pour une application. Vous ne serez donc plus vulnérable, ouf !

Je viens de supprimer un fichier, mais je n’ai pas récupéré d’espace libre

Laisser une réponse

Linux - Suppression de fichier sans effet sur l'espace libre

Linux – Suppression de fichier sans effet sur l’espace libre

Il peut arriver que le partitionnement choisi sur un serveur Linux ne soit pas optimal, et qu’une partition se retrouve saturée. Lorsque c’est la partition «  /var  », c’est souvent les journaux dont la taille a explosé. Naturellement, pour résoudre ce problème de place, il suffit de supprimer des fichiers.

Mais parfois, cela ne suffit pas car même après avoir supprimé le fichier, l’espace libre n’augmente pas.

Qu’est-ce qu’un fichier sous Linux ?

Un fichier sous Linux, ou plutôt un nom de fichier est une référence à un inode sur le système de fichier. Cet inode rassemble les méta données (droits d’accès, propriétaire, groupe, date de dernière modification, …) et la liste des blocs contenant les données du fichier. Tant qu’il existe une référence active à un inode sous Linux, les blocs occupés par le fichier sont considérés comme utilisés. Les références possibles à un fichier peuvent être tous les noms de fichiers faisant référence à cet inode (le nom de fichier initial, et tous les « hard links » créés avec la commande « ln ») et tous les processus ayant actuellement ce fichier ouvert.

Donc, tant qu’un fichier restera ouvert par un processus en cours, il existera une référence vers son inode, et l’espace sera toujours utilisé sur le système de fichier. Pour résoudre ce problème, il suffit de retrouver quel est le processus qui utilise ce fichier, et l’arrêter (ou le redémarrer si c’est un service). Soit on se doute de l’application qui utilise ce fichier, soit on peut utiliser l’outil « lsof » comme suit ( « /chemin/vers/le/fichier.log » étant le fichier que l’on vient de supprimer) :

$ lsof /chemin/vers/le/fichier.log

Si le fichier a été supprimé depuis son ouverture, il apparaitre la mention (deleted) derrière le nom de fichier, c’est donc le processus correspondant qu’il faudra arrêter pour récupérer de la place. Après que la dernière référence au fichier aura été supprimé, l’espace utilisé par celui-ci sera libéré.

Rencontrer l’erreur « No space left on device » alors que le périphérique n’est pas plein ?

Laisser une réponse

No space left on device

No space left on device

Il arrive parfois qu’une mauvaise estimation de l’espace nécessaire à une partition aboutisse au célèbre message «  No space left on device  » ou en français «  Aucun espace disponible sur le périphérique  ». C’est un problème qui se résout assez facilement en général, soit en redimensionnant des partitions ou en ajoutant de l’espace à un volume LVM par exemple.

En revanche le problème se corse quand la totalité de l’espace n’est pas utilisé : comment résoudre un problème inexistant ?

Un message d’erreur n’arrive pas sans une cause. La commande «  df  » n’indique pas de souci d’espace. Mais en revanche, la commande «  df -i  » permet de découvrir qu’il existe un nombre limité d’inodes possibles.

df -i : la commande qui permet d'afficher l'utilisation des inodes

df -i : la commande qui permet d’afficher l’utilisation des inodes


En effet, même si la principale limite d’une partition ou d’un périphérique est sa taille, il existe une autre limitation qui peut être atteinte : une partition est limitée en taille, mais aussi en nombre de fichiers ou d’inodes pour être plus exact. En général, augmenter la taille de la partition va également permettre d’augmenter le nombre d’inodes possibles, mais ce comportement est spécifique à chaque système de fichiers.

Selon le système de fichiers, il faudra soit agrandir le périphérique ou recréer le système de fichiers en spécifiant le nombre d’inodes souhaités. Toutes ces opérations ne seront effectuées qu’après avoir sauvegardé les données bien évidemment !

5 légendes sur Mail, un média encore mal connu

Laisser une réponse

Email - 5 légendes sur un média encore mal connu

Email – 5 légendes sur un média encore mal connu

Le mail a été pour beaucoup de personne une nouvelle façon de communiquer. Toute nouvelle technologie apporte également son lot de croyances approximatives, voire totalement fausses. Voici un petit florilège des idées reçus sur le mail.

Envoyer un email c’est instantané

Le protocole mail ne définit pas de contrainte sur la durée de livraison d’un message. Même si un serveur de mail va tenter de livrer un message le plus rapidement possible, il est tout à fait possible de rencontrer le cas d’un message qui mettra plusieurs dizaines de minutes voire plusieurs heures pour arriver, selon les aléas des deux serveurs de mails impliqués.

SPF et DKIM permettent de ne pas arriver dans le dossier Spam

SPF et DKIM sont deux normes qui permettent de vérifier que le serveur émetteur d’un email est bien autorisé à émettre un email pour ce domaine. Rien n’empêchera un spammeur d’émettre un message non sollicité depuis un serveur autorisé à émettre pour le domaine qu’il utilise. Dès lors, considérer un message respectant la norme SPF ou DKIM comme légitime risque de laisser passer des messages indésirables. L’idée derrière SPF et DKIM est de lutter contre l’usurpation d’identité, mais absolument pas de lutter contre les messages indésirables : tout au plus, ces normes permettent d’écarter les messages provenant de serveurs non autorisés à émettre pour le domaine utilisé en tant qu’expéditeur. Seule la manière d’opérer des spammeurs permet d’accorder un peu plus de crédit aux messages validant les normes SPF et DKIM : la plupart des spammeurs changent très souvent d’IP et n’investissent pas de temps dans la configuration de DKIM et SPF.

Personne ne peut utiliser mon adresse email

Lors de la création du service mail, le fonctionnent du courrier postal a été utilisé comme base. De ce fait, on retrouve des limitations identiques entre le courrier postal et le mail. Une grande partie des utilisateurs des emails se basant uniquement sur leurs expériences sur les webmails pensent à tord que l’expéditeur d’un email ne peut être usurpé : tout comme le courrier postal sur lequel vous pouvez apposer un expéditeur de votre choix, l’email permet exactement la même chose. Rien n’empêche techniquement d’envoyer un email avec l’expéditeur de son choix ; seuls SPF et DKIM peuvent bloquer la réception du message ou le classer en message indésirable, si le domaine est usurpé ; dans le cadre d’un utilisateur usurpé, il n’existe pas de solution hormis la signature électronique d’un email (actuellement encore trop peu répandue).

Depuis que je suis passé en SSL partout, plus personne ne peut lire mes emails

Depuis qu’Edward Snowden a révélé que la NSA disposait de programme d’écoute sur Internet, bon nombre de prestataires de mails sont passés au SSL sur leur Webmail, leurs serveurs IMAP, POP et SMTP. De ce fait, il devient beaucoup plus difficile d’intercepter le contenu d’un email quand un utilisateur consulte ou envoie un email. Si les communications avec l’utilisateur final sont chiffrées, rien n’assure à l’utilisateur que son email va transiter de manière chiffrée vers son destinataire. En effet pendant la distribution de l’email au destinataire, il est nécessaire que les serveurs de mails de l’expéditeur et du destinataire aient SSL (ou plutôt STARTTLS) d’activé. Dans le cas contraire, l’ensemble des informations du mail transiteront en clair, et pourront donc être écoutées.

Je reçois des emails d’erreurs, je n’y comprends rien, c’est tellement compliqué

Lors de l’envoi de mail, il arrive de recevoir une notification de mails parce que l’email n’a pas pu être envoyé. Alors que les messages, certes en anglais, sont en règle générale explicite et clair, bon nombre de personne s’obstinent à dire que c’est très compliqué. Pourtant une traduction automatique devrait permettre de comprendre l’erreur et au pire, une recherche du message d’erreur sur un moteur de recherche devrait permettre d’en connaitre la signification précise.

Restaurer l’espace InnoDB MySQL

Laisser une réponse

MySQL - Contenu des logs lorsque l'espace InnoDB est corrompu

MySQL – Contenu des logs lorsque l’espace InnoDB est corrompu

« MySQL server has gone away » et « Lost connection to MySQL server during query » sont les messages que le gestionnaire d’un serveur MySQL appréhende de rencontrer, surtout lorsque l’essentiel des tables utilisent le moteur de stockage InnoDB. InnoDB est un moteur de stockage intéressant en ce qui concerne ses fonctionnalités, mais qui rends inutilisable l’ensemble du serveur MySQL dès lors que l’espace de stockage est corrompu. Le service s’arrêtera de fonctionner dès lors qu’une corruption sera détectée.

En temps normal, MySQL devrai détecter la corruption de l’espace InnoDB lors du démarrage du serveur, et tenter de réparer l’erreur en « rejouant » le contenu présent dans les logs, mais il est courant que cela ne corrige pas totalement la corruption. Avant d’essayer quoique ce soit, il est prudent de faire une copie de sauvegarde de l’état initial. Pour ce faire, il suffit de sauvegarder le contenu du dossier des données de MySQL, dont l’emplacement par défaut est « /var/lib/mysql/ ». Il faut dans un premier temps s’assurer que le serveur MySQL soit arrêté, puis utiliser par exemple la commande « tar » comme ci-dessous :

# tar zcvf mysql-backup.tar.gz /var/lib/mysql/

Une fois l’état initial du serveur sauvegardé, il est temps de démarrer la phase de récupération des données. Pour forcer MySQL à rester actif malgré la corruption de l’espace InnoDB, il est nécessaire de modifier le fichier de configuration du serveur MySQL « /etc/my.cnf », en rajoutant la variable « innodb_force_recovery » dans la section « [mysqld] » :

[mysqld]
innodb_force_recovery = 1

La variable « innodb_force_recovery » peut prendre les valeurs de 0 à 6 (0 étant la valeur par défaut indiquant un fonctionnement normal de MySQL). Les valeurs supérieures à 0 sont différents modes de récupérations proposés par MySQL : plus la valeur est faible, moins le risque de corrompre les données est grand (d’où la sauvegarde préalable).

Après avoir défini la valeur de la variable « innodb_force_recovery » sur 1, il faut démarrer le service MySQL. Le serveur MySQL devrait démarrer, et ne pas s’arrêter. Si le service s’arrête, il faudra augmenter successivement la valeur jusqu’à 6. Si avec la valeur 6 le MySQL ne fonctionne pas, il y a de grandes chances qu’il ne soit pas possible de récupérer les données, c’est pourquoi les sauvegardes régulières sont indispensables.

Si MySQL démarre, il va falloir utiliser la méthode de l’exportation / importation pour pouvoir récupérer les données. Cette méthode permettra de récupérer l’ensemble des enregistrements valides présent dans les tables du serveur. Pour optimiser la création de l’export des données, l’utilisation de l’option « --opt » de la commande « mysqldump » est fortement recommandée. Voici un exemple de la commande à utiliser :

# mysqldump --user=<utilisateur> --password --opt --all-databases --result-file=dump.sql

Une fois l’export des données terminé, il est nécessaire de désactiver le mode de récupération en supprimant la variable « innodb_force_recovery » dans la section « [mysqld] » du fichier « /var/lib/mysql/ ».

Il faut à présent arrêter MySQL, supprimer l’espace InnoDB et enfin le recréer en démarrant MySQL :

# service mysql stop
# rm /var/lib/mysql/ib*
# service mysql start

Supprimer l’ensemble de l’espace InnoDB peut paraître radical, mais elle permet de repartir sur un espace de stockage InnoDB sain.

Il ne reste plus qu’à réimporter les données récupérée précédemment :

# mysql --user=<utilisateur> --password < dump.sql

L’import des données InnoDB est assez long en raison des fonctionnalités de ce moteur, il est possible que vous ayez à vous armer de patience pendant l’import des données selon le nombre de lignes et la taille des données. Si tout se passe bien, un maximum de données aura été récupéré.

Mon système ne démarre plus ! Au secours je suis perdu !

Laisser une réponse

Ecran noir - la hantise de tout Sysadmin !

Ecran noir – la hantise de tout Sysadmin !

Lorsqu’une machine est administrée à distance, et donc sans accès physique, il arrive que cette machine ne veuille plus démarrer : il est difficile mais pas impossible d’essayer d’en déterminer la cause, même à distance.

Les problèmes matériels

La première chose à faire est d’essayer de déterminer si un problème matériel n’est pas à l’origine du problème. Il est courant qu’un hébergeur de serveurs dédiés propose un système de « rescue » ou système de sauvetage. Ce système étant chargé par le réseau, il n’utilisera aucun élément du système de votre serveur pour démarrer, afin d’écarter tout problème provenant de celui-ci. Pour effectuer les vérifications de bases, il vous faudra donc démarrer votre serveur dans ce mode. Il faudra en général s’armer de patience (quelques minutes) pour que le démarrage du système « rescue » soit terminé. Si au bout d’un quart d’heure, vous n’avez aucune réaction du serveur, il est temps de contacter l’hébergeur de celui-ci pour lui demander une vérification du matériel.

Si le serveur est accessible sur le système « rescue » il est alors possible d’avancer dans le diagnostic. Il faut dans un premier temps vérifier que le ou les disques sont bien présent, en utilisant la commande « fdisk -l », « lsblk » ou « ls -l /dev/disk/by-id ». Si aucun disque n’apparait ou un disque est manquant, il va falloir contacter l’hébergeur pour demander une intervention sur le serveur.

Il peut également être utile de vérifier l’état de santé des disques du serveur : l’impossibilité de lire un fichier peut empêcher le démarrage du serveur. Pour vérifier l’état de santé d’un disque, il suffit d’utiliser la commande « smartctl » :

smartctl -a /dev/sda

L’interprétation des valeurs affichées est expliquée sur la page suivante, sous la rubrique -A, –attributes de la documentation de la commande smartctl

Si le journal des erreurs comporte des entrées ou que certaines valeurs d’attributs SMART sont sous la plus mauvaise valeur admissible, il est grand temps d’effectuer une sauvegarde, et de demander le remplacement du disque auprès de l’hébergeur.

Les problèmes logiciels

Maintenant qu’on a déterminé que le problème n’était (très probablement) pas matériel, il faut déterminer quels sont les moyens à notre disposition pour effectuer le diagnostic. Si le serveur ne démarre pas, il faudrait pouvoir observer ce qu’il se passe au démarrage du serveur, mais sans écran, c’est impossible. Impossible ? Non !

Il existe deux principaux moyens pour voir ce qu’il se passe au démarrage d’un serveur sans écran. La première méthode consiste à utiliser la « console série » qui transmets l’affichage de l’écran par l’intermédiaire d’un câble série : c’est l’hébergeur qui fourni ce genre de solution, renseignez-vous si celui-ci la propose.

La seconde méthode est l’utilisation du « KVM sur IP » qui permet de voir et agir sur le serveur à distance comme si un écran, clavier et souris était connecté au serveur. Soit votre hébergeur vous propose ce type d’outil (matériel à brancher sur le serveur) à la demande ou il peut s’agir d’une fonctionnalité proposée par le constructeur de votre serveur (iLO pour les serveurs HP, iDrac sur les serveurs Dell, IPMI chez Supermicro, …) qui sera donc accessible de manière permanente.

L’avantage du KVM sur IP sur la console série est qu’il permet de voir tout ce qui se passe à l’écran, et notamment le BIOS et le chargement du boot loader, contrairement à la console série qui ne sera active qu’une fois le boot loader chargé (si celui-ci est configuré).

Il ne reste plus qu’à observer sur quoi bloque le démarrage du serveur. Si vous disposez d’une console série, mais que rien ne s’affiche, il sera alors nécessaire de vérifier si la console série est bien configurée dans le boot loader et sur le kernel que vous démarrez ; si tout est bien configuré, il est très probable que le souci provienne du boot loader. Dans les autres cas, vous devriez pouvoir observer ce qu’il se passe au démarrage du serveur.

Si vous ne disposez pas de console série ou de KVM sur IP, il est peut être possible tout de même de déterminer quel est le souci. Pour cela, il va falloir consulter les logs du système local dans le dossier /var/log depuis le rescue : il faudra agir en conséquence du contenu des fichiers de logs. Si les logs ne contiennent pas d’information sur le boot, le serveur n’est très certainement pas arrivé jusqu’au montage des partitions, il va donc falloir essayer d’en déterminer la cause.

Il existe deux problèmes courants empêchant le démarrage d’un serveur : une erreur dans la configuration du boot loader et une erreur sur un système de fichier qui ne peut être corrigée sans confirmation.

Pour pouvoir vérifier, et éventuellement corriger les systèmes de fichiers du serveurs, il suffit de lancer la commande « fsck » sur l’ensemble des systèmes de fichiers comme par exemple :

$ fsck /dev/sda1 /dev/sda3

Si « fsck » vous demande d’accepter une correction de manière explicite, il y a de grandes chances que vous ayez trouvé et résolu le problème.

Afin de s’assurer que le boot loader est bien installé et configuré, il suffit en général de le réinstaller. Le boot loader le plus courant à l’heure actuelle est « grub », et il suffit d’exécuter la commande « grub-install » pour l’installer sur le périphérique de stockage permettant de démarrer.

$ grub-install /dev/sda

Une nouvelle tentative de démarrage sur le système local vous indiquera si le boot loader était à l’origine de l’impossibilité de démarrer.

Si malgré toutes ces tentatives, votre serveur ne démarre toujours pas, il va falloir s’armer de patience et de réflexion pour en trouver la cause. Voici quelques pistes de réflexions :

  • Quelles sont les modifications apportées depuis le dernier démarrage fonctionnel ?
  • Manque-t-il un module nécessaire au démarrage du serveur (carte RAID, Contrôleur de disque, …) dans le fichier initramfs ?
  • Le boot loader est-il configuré pour charger par défaut le bon kernel, et est-ce que le chemin vers ce kernel est valide ?
  • Les paramètres passés au kernel sont-ils correctement configurés, notamment en ce qui concerne le système de fichier «  root  » ?

Bonne chance !

On vient de remplacer mon serveur, mais je n’ai plus de réseau !

Laisser une réponse

Règles udev - La nouvelle carte réseau se nomme eth1

Règles udev – La nouvelle carte réseau se nomme eth1

Lorsqu’un prestataire loue des serveurs dédiés, il est courant qu’il privilégie des solutions de maintenance minimisant la durée d’indisponibilité du serveur pour le client final. Il est donc parfois amené à remplacer un serveur complet en récupérant les disques pour les replacer dans un nouveau serveur. Il parait logique qu’un matériel identique utilisant les disques de l’ancien serveur (donc les mêmes données) fonctionne sans modification. C’est sans compter la petite modification qui a toute son importance durant cette opération : le changement d’adresse MAC de la carte réseau, qui se doit d’être unique.

Après le changement de serveur, il est courant que tout fonctionne, sauf le réseau : aucune connexion réseau n’est active alors que seul le matériel a été changé.

Depuis que « udev » a été mis en place pour gérer et nommer les périphériques dans le dossier « /dev/ » afin de disposer d’un nom unique et persistant, ce n’est plus l’ordre de détection des périphériques qui donne leur noms aux périphériques (sauf exceptions). De ce fait, lors de la détection de la nouvelle carte réseau du nouveau matériel, celle-ci n’est plus nommée « eth0 », mais « eth1 ». Quelle que soit la distribution, la configuration réseau, qu’elle soit statique ou en DHCP, se base sur le nom de l’interface, et la « nouvelle carte réseau » ne dispose donc d’aucune configuration définie.

Deux solutions sont envisageables : supprimer le fichier contenant les règles de nommage des cartes réseaux, ou modifier ce fichier. Dans le cadre où il n’y a qu’une seule carte réseau sur le serveur, la première solution est la plus simple. Pour ce faire, il suffit d’exécuter la commande suivante :

rm /etc/udev/rules.d/70-persistent-net.rules

Ce fichier sera généré automatiquement et la première et unique carte réseau sera alors nommée « eth0 ».

Dans le cadre où il y a plusieurs interfaces, il va falloir modifier le fichier « /etc/udev/rules.d/70-persistent-net.rules » en mettant les bonnes adresses MAC au bon endroit. C’est l’attribut « ATTR{address} » qu’il faudra mettre à jour avec la bonne adresse MAC (récupérée avec la commande « ip addr ») :

# PCI device 0x8086:/sys/devices/pci0000:00/0000:00:03.0 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:70:9b:d7", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Règles udev - Définition du nom eth0 pour la carte réseau

Règles udev – Définition du nom eth0 pour la carte réseau

Une fois ce fichier pris en compte, toutes les interfaces réseaux reprendront le nom que vous aurez choisi.

Les modifications seront bien évidemment à apporter sur le système local du serveur : vous pouvez utiliser Chrootme.sh si vous utilisez un système rescue pour faire ces modifications.

Dans les deux solutions, pour que les nouvelles règles de nommage soient créées ou utilisées, le plus simple sera de lancer un redémarrage du serveur.

Une fois le serveur démarré sur le système local, vous devriez retrouver une connectivité réseau à l’identique, puisque la nouvelle interface du serveur aura repris le même nom qu’avec le précédent serveur, et par conséquence, la même configuration réseau :

Règles udev - La carte réseau est bien eth0 à nouveau

Règles udev – La carte réseau est bien eth0 à nouveau


Et voilà un serveur prêt à continuer de fonctionner sans réinstallation !

Trouver la solution à un problème : quelques conseils !

Laisser une réponse

Strace - Analyse des appels système de ls

Strace – Analyse des appels système de ls

Étant confronté à de nombreux problèmes sur des systèmes parfois totalement inconnus, parfois partiellement connus, il est nécessaire de procéder de manière logique et consciencieuse pour trouver une solution.
La première étape est de chercher comment reproduire le problème : pouvoir reproduire l’erreur à la demande permet de déterminer les conditions de déclenchement de l’erreur et d’analyser en détail les conditions qui mènent au problème. Enfin cela permettra également de déterminer si la solution mise en œuvre résout le problème ou non.

Pour trouver une solution à un problème, il est nécessaire de rassembler le maximum d’informations pour déterminer quels sont les axes de recherche et actions les plus pertinents. La première source d’information, même si elle paraît évident est l’éventuel message d’erreur qui apparait soit à l’écran directement, ou dans un journal (encore appelé « log »). Il peut être intéressant d’augmenter le niveau de verbosité concernant les messages d’erreur ou les logs dans l’application, afin d’avoir plus d’information ou des informations plus précises. Si la source de l’application est disponible et que le message d’erreur fait référence aux sources, les consulter vous permettra de déterminer plus précisément le contexte de l’erreur, notamment quelle est l’opération en cours pendant l’erreur.

Une fois ces informations récupérées, il est essentiel d’exploiter au mieux les ressources d’information à notre disposition.

La documentation ainsi que la foire aux questions de l’application permettent de se familiariser avec l’application et notamment avec l’éventuelle partie identifiée de l’application qui pose actuellement problème. Il est souvent utile de survoler la documentation, et approfondir les points s’approchant du contenu du message d’erreur.

Les « Howto » permettent souvent de déterminer la signification et une valeur « correcte » d’une directive de configuration, lorsque la configuration est en cause, et d’essayer de modifier cette valeur.

Dès lors qu’on dispose d’un message d’erreur explicite, il y a de grandes chances de pouvoir trouver une solution sur un moteur de recherche, mais encore faut-il savoir correctement chercher. En effet, pour rechercher un message d’erreur sur un moteur de recherche, il convient de ne conserver dans la requête que les éléments significatifs :

  • un nom de fichier et le numéro de ligne dans ce fichier tout en supprimant le chemin vers ce fichier qui peut être totalement différent selon les installations
  • le nom d’une fonction, en supprimant les paramètres qui sont souvent unique,
  • les codes d’erreurs par opposition à un message d’erreur traduit qui limiteraient les résultats de recherches à la langue sélectionnée pour l’application.

De manière générale, rechercher du plus général au plus précis permet d’affiner les résultats de recherche pour trouver une solution sur un forum, un blog ou une liste de discussion.

Dans l’éventualité où la solution n’a pas encore pu être trouvée, il y a encore quelques pistes à explorer. Dans un premier temps, il peut être utile de démarrer le programme en mode « debug » et pousser la verbosité au maximum. Cette solution, aussi applicable aux services et démons permet de connaitre un détail des actions effectuées avant l’apparition du problème, et peut être avoir plus d’éléments permettant d’identifier une solution.

La dernière option à utiliser est celle de tracer l’exécution du service ou programme. Cette solution utilise des outils très verbeux, il est donc nécessaire de pouvoir faire le tri dans une masse d’information importante. Il est généralement nécessaire d’avoir quelques connaissances en développement pour pouvoir juger de la pertinence d’une information. L’outil le plus utilisé pour ce type d’analyse est « strace » sous Linux : cet outil permet de tracer tous les appels systèmes d’une application, de voir les paramètres utilisés et surtout la valeur de retour de ces appels systèmes. Il existe un équivalent sous Windows, appelé Process Monitor développé par Sysinternals. Une fois l’appel système posant problème identifié, en consultant la documentation de cet appel système avec le code de retour sous les yeux il sera possible d’identifier concrètement quelle est l’erreur rencontrée. Il restera ensuite à déterminer pourquoi l’appel système échoue, ce qui sera bien plus facile quand le code d’erreur est connu, car il est souvent plus clair qu’un message d’erreur.

Dans toutes les étapes de la résolution d’un problème, il convient d’essayer de comprendre comment fonctionne le service ou l’application posant problème : de cette manière, la résolution du problème n’en sera que plus évidente, puisqu’elle découlera d’un raisonnement logique.

Il arrive parfois de buter sur un problème. Si la durée de résolution du problème n’est pas une contrainte (c’est malheureusement rarement le cas), il est très souvent utile de revenir à cette tâche plus tard, afin d’avoir un point de vue différent qui facilitera peut-être le déclic pour trouver la solution.

Bonne chance !