Archives du mot-clé Linux

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 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 !

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 !

Utiliser son système local, même lorsqu’il ne semble plus démarrer ? C’est possible avec Chrootme.sh !

1 réponse

Chrootme.sh - Script de Chroot automatisé

Chrootme.sh – Script de Chroot automatisé

Pour de raisons multiples, il est possible que le démarrage d’un serveur soit impossible. Selon les possibilités de l’offre, il peut être très compliqué de trouver quelle en est la cause. Malgré que le système ne veuille plus démarrer, il peut être encore possible d’accéder non seulement aux données, mais aussi à certains services depuis un système de restauration (encore appelé système de sauvetage, ou rescue).

La fonction « chroot » de Linux permet de changer le dossier racine d’un processus ; la commande « chroot » permet donc de démarrer un processus avec une nouvelle racine (en ne précisant pas la commande, par défaut c’est le shell par défaut qui est lancé).

Pour pouvoir accéder aux données du système du serveur, il est alors nécessaire de monter l’ensemble des disques dans un dossier, et de se « chrooter » dans ce dossier, par exemple /mnt/ ou encore /media/. L’exercice est assez facile lorsque le partitionnement du disque est connu mais devient plus acrobatique et complexe lorsque c’est un serveur qu’on vient de découvrir. Heureusement, le fichier /etc/fstab du système local contient l’organisation des partitions utilisées par le système local et va nous permettre de monter facilement les partitions.

Pour gagner du temps, j’ai développé un script qui permet d’automatiser la recherche du fichier fstab, permet de choisir quel est le fichier fstab à utiliser, et de monter l’ensemble des partitions du fichier fstab choisi, et de faire un « chroot » sur le système nouvellement monté.

Ce script s’appelle Chrootme.sh et est disponible sur Github. Le script a été développé en essayant de dépendre du minimum d’outils possibles, pour pouvoir être utilisé depuis le plus grand nombre de systèmes « rescue » possible.

Si jamais un problème survenait lors de l’utilisation de ce script, vous pouvez reporter les bugs (en anglais si possible) sur GitHub.

Pour utiliser ce script, il vous suffit de lancer la commande suivante :

$ wget --no-check-certificate "https://raw.githubusercontent.com/sysadminstory/chrootme/master/chrootme.sh" -O "chrootme.sh" && sh chrootme.sh

Si la commande wget n’est pas disponible, il est possible d’utiliser la commande curl en remplaçement :

$ curl -k -o "chrootme.sh" "https://raw.githubusercontent.com/sysadminstory/chrootme/master/chrootme.sh" && sh chrootme.sh

Une fois le script démarré, il ne vous reste plus qu’à suivre les instructions à l’écran.

Un certain nombre d’articles de ce blog font appel au chroot. La méthode pour récupérer ou modifier le mot de passe root sous Linux y fait appel, tout comme les articles sur la restauration d’un RAID1 logiciel et la méthode pour migrer un système complet en minimisant l’indisponibilité y font référence quant à la réinstallation du chargeur d’amorçage.

Monitorer l’état des disques sous Debian

Laisser une réponse

Défaillance d'un disque dur - Tête de lecture ayant abimé un plateau

Défaillance d’un disque dur – Tête de lecture ayant abimé un plateau

Sous Debian, superviser l’état des disques et être informé de toute défaillance détectée par SMART sur l’un des disques attachées au contrôleur non RAID (le cas des controleurs RAID est assez spécifique) est assez simple.

Le premier pré-requis pour surveiller l’état des disques est de disposer du package smartmontools. Si celui ci n’est pas encore installé, il suffit de lancer la commande suivante en root :

# apt-get install smartmontools

Par défaut, sous Debian, le service de surveillance de l’état SMART des disques n’est pas actif, il va donc falloir l’activer. Pour ce faire, il faut éditer le fichier /etc/default/smartmontools et décommenter la ligne suivante :

#start_smartd=yes

La ligne est à présent la suivante :

start_smartd=yes

Il faut à présent modifier la configuration de smartd afin de recevoir les alertes sur l’email de son choix. Le fichier à modifier est /etc/smartd.conf. Il faudra remplacer la ligne suivante :

DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

Le remplacement devra s’effectuer avec cette ligne, en prenant soin de remplacer [email protected] par l’adresse email de votre choix :

DEVICESCAN -m [email protected] -M exec /usr/share/smartmontools/smartd-runner

Après avoir modifié la configuration, il ne reste plus qu’à redémarrer le service smartmontools avec la commande suivante :

/etc/init.d/smartmontools restart

❗ Pour que le mail puisse être envoyé, il faut qu’un serveur de mail soit correctement configuré, comme exim4, sendmail, ou encore postfix.

Vous serez à présent averti par mail dès qu’un problème sera détecté par le système SMART, et vous pourrez donc agir avant de rencontrer une indisponibilité, voire de perdre des données.

Malgré tout, il reste important de disposer de sauvegardes, car une panne électrique ou un contrôleur de disque peuvent rendre inexploitable un disque sans prévenir !

Monitorer un RAID logiciel sous Debian

Laisser une réponse

Linux RAID1 Soft - Défaillance totale

Linux RAID1 Soft – Défaillance totale


Afin que le RAID remplisse sa fonction de tolérance aux pannes, il est nécessaire non seulement de le mettre en place, mais aussi de surveiller son état.
Dans le cadre d’un RAID logiciel Linux, l’utilitaire mdadm utilisé pour configurer et gérer le RAID, permet également d’être informé de tout changement d’état du RAID. Dans le cas contraire, il est bien possible que des données se retrouvent perdues à jamais un jour où l’autre !

Sous Debian, par défaut, mdadm est lancé en tant que service, mais il reporte les changements d’états du RAID uniquement dans syslog : il faudrait donc surveiller les logs du serveur en permanence pour être informé en temps réels des éventuels problèmes rencontrés sur le RAID. Il est tout à fait possible de remplacer l’écriture dans les logs par l’envoi d’un email.

Pour ce faire, il vous faudra modifier deux fichiers. En premier lieu, ce sera le fichier /etc/default/mdadm qu’il faudra modifier, celui-ci correspond aux paramètres du service « mdadm ». Il faudra remplacer dans ce fichier la ligne suivante :

DAEMON_OPTIONS="--syslog"

par la ligne suivante :

DAEMON_OPTIONS=""

Le deuxième fichier corresponds aux paramètres de mdadm dans sa globalité. Le fichier /etc/mdadm/mdadm.conf doit être modifié et peut-être complété.

La ligne suivante doit être remplacée par l’adresse qui doit recevoir les alertes de changement d’état (par défaut, c’est l’utilisateur root qui recevra les alertes par mail) :

MAILADDR root

Elle devra être de la forme suivante

MAILADDR [email protected]

Si l’adresse de l’expéditeur par défaut ne convient pas il est également possible de définir l’adresse de l’expéditeur (par défaut : root@<hostname>), il suffit d’ajouter la ligne suivante :

MAILFROM [email protected]

❗ Pour que le mail puisse être envoyé, il faut qu’un serveur de mail soit correctement configuré, comme exim4, sendmail, ou encore postfix.

Une fois la configuration modifiée, il restera à relancer le service mdadm avec la commande suivante :

# /etc/init.d/mdadm restart

A présent, un email sera envoyé dès qu’un volume RAID sera dégradé.