[Nas 3/x] Et un disque défectueux ! Un !

Dans l’article précédent, j’évoquais quelques étapes de préparation du NAS et l’installation d’OpenMediaVault. Une fois ces étapes effectuées, je me suis donc tourné vers la mise en place des disques durs de données.

J’ai décidé de commencer doucement et j’ai choisi deux disques Western Digital Red 1 To. Afin d’éviter d’avoir deux disques provenant d’un même lot et ainsi réduire les risques de défaillance simultanée, je me suis procuré les disques auprès de deux enseignes différentes. L’un en Allemagne chez MediaMarkt, l’autre chez Amazon.

Une fois les disques en ma possession, quelques coups de tournevis pour monter le support et je charge les disques dans le NAS éteint. Démarrage. Authentification. Arrivé sur l’interface du NAS, je vérifie les disques détectés par le système : j’en vois bien trois, mes deux disques de 1 To et le SSD. Pas de problème à priori. Je clique donc sur le menu gestion du RAID pour configurer un raid miroir sur les deux disques. Bouton créer; je complète la configuration du périphérique RAID, clique sur enregistrer, et là, c’est le drame.

Rien ne se produit… Je devrais avoir un état d’avancement de la construction du RAID, rien. Pourtant, après investigation, le RAID semble avoir été initialisé. Dans le doute, je redémarre le NAS… Le système boot, puis affiche des lignes d’erreurs, avant de continuer à démarrer. L’un des disques semble avoir des problèmes.

Lignes d'erreur au démarrage
Lignes d’erreur au démarrage

Je tente alors de diagnostiquer le problème. La question que je me pose est la suivante : « Mon disque est-il défectueux depuis son acquisition ou, une erreur lors de la création du RAID peut-elle avoir entraînée une corruption d’un secteur ? Bref, le problème est-il corrigeable ou non ? ». Pour essayer de répondre à ces interrogations, je vais exécuter des tests SMART pour tenter de déterminer précisément l’état du disque. Pour cela, je me tourne sous GNU/Linux vers Smartmontools avec la commande :

smartctl -i /dev/sdX

Je n’ai pas sauvegardé les résultats des différentes commandes. Globalement, ce que j’apprends et comprends dans les informations retenues, c’est que mon disque fonctionne (tourne), mais que le taux d’erreur est impressionnant et qu’il ne semble pas être en mesure de lire un seul secteur. Je tente donc de lancer des tests plus poussés, un long puis un cours en arrière plan :

smartctl -t short /dev/sdX
smartctl -t long /dev/sdX

Puis une heure plus tard, je regarde les résultats :

smartctl -a /dev/sdX

Pas de chance, les deux tests sont en erreur et n’ont pas réussi à finir. Pas beaucoup plus avancé, sinon que ça ne marche vraiment pas. En faisant des recherches sur le web pour essayer de comprendre, je tombe sur la question ATA drive is failing self-tests, but SMART health status is ‘PASSED’. What’s going on? soit en français, les tests sont en erreur, le status de santé du disque est « ok », que ce passe-t-il ? D’après ce qui est écrit en réponse, j’en déduis qu’écrire une donnée sur le disque pourrait forcer une réallocation de secteur endommagé s’il y en a un présent ou permettre d’écrire une donnée « cohérente ».

Mon disque ne contient pas de système de fichier, un certain nombre de solutions proposées tombent à l’eau. En dernier recours, je tente de réécrire des données aléatoires sur l’ensemble du disque avec :

dd if=/dev/urandom > /dev/sdX

Cela semble fonctionner, ça mouline, c’est long. Les tests ayant incriminé un secteur proche du début du disque, je coupe la commande à la moitié pour gagner du temps. Redémarrage, mais pas d’amélioration. À ce stade, j’en conclue que le disque est défectueux et qu’il va donc falloir tenter de le faire remplacer. Le disque concerné est celui en provenance d’Amazon. J’étudie leur politique de retour, ça semble plutôt facile et ils n’ont pas l’air de chipoter.

Avant de me résigner à renvoyer le disque, je décide de le tester une dernière fois avec les outils de tests du constructeur. Celui de Western Digital n’est disponible que sous Windows et le disque doit être monté en SATA; pas possible d’utiliser un connecteur USB, le disque n’est pas reconnu. Les résultats sont les suivants :

Western Digital Logo

Test Option: QUICK TEST
 Model Number: WDC WD10EFRX-68FYTN0
 Unit Serial Number: WD-WCC4J4VZKS2H
 Firmware Number: 82.00A82
 Capacity: 1000.20 GB
 SMART Status: PASS
 Test Result: FAIL
 Test Error Code: 06-Quick Test on drive 4 did not complete! Status code = 07 (Failed read test element), Failure Checkpoint = 97 (Unknown Test) SMART self-test did not complete on drive 4!
 Test Time: 17:54:31, August 01, 2016

Ce n’est pas mieux. Le contrôleur RAID du NAS, les outils de diagnostic Western Digital, Smartmontools, tous indiquent que le disque n’a jamais fonctionné correctement. Je renvoie donc le disque et demande son remboursement. Quitte à devoir en obtenir un nouveau, je préfère qu’il n’arrive pas par transporteur et lui éviter les chocs. Je me tourne donc vers materiel.net et leur boutique proche de Strasbourg qui indique que le disque est en stock pour quelques euros de moins.

Bref, achat direct d’un nouveau disque dur le lendemain et montage dans le NAS, et cette fois ça y est, la construction du RAID démarre. Je retiendrai qu’acheter un disque dur par correspondance n’est pas une bonne idée, on peut avoir de la chance ou pas, mais il est probable que le disque aura subi de nombreux chocs durant le transport. J’ai voulu essayer, je suis fixé.

 

Les sources d’informations utilisées durant mes recherches :
https://www.thomas-krenn.com/en/wiki/SMART_tests_with_smartctl
http://www.linuxtechi.com/smartctl-monitoring-analysis-tool-hard-drive/
https://wiki.archlinux.org/index.php/Securely_wipe_disk#Non-random_data
https://www.smartmontools.org/wiki/FAQ#ATAdriveisfailingself-testsbutSMARThealthstatusisPASSED.Whatsgoingon
https://www.smartmontools.org/browser/trunk/www/badblockhowto.xml
https://wiki.archlinux.org/index.php/RAID
https://wiki.archlinux.org/index.php/S.M.A.R.T.
https://unix.stackexchange.com/questions/113737/does-my-hard-drive-have-bad-sectors-or-not

[NAS 2/x] Installation

Dans le premier article de cette série, je vous annoncais que j’avais choisi le HP Proliant MicroServer Gen8 pour en faire un NAS. Une fois la machine reçue, il convient de faire quelques adaptations pour rendre son utilisation, et son administration, plus agréable. Pour ces quelques opérations, je me suis à nouveau basé sur l’article très complet de L’Atelier du Geek traitant de l’installation d’OpenMediaVault sur cette machine.

En partant des informations de l’article, je me suis moi aussi doté d’un câble SATA, d’un câble adaptateur d’alimentation floppy vers SATA et d’un disque SSD sur lequel sera installé le système.

nas_1
Le disque SSD placé sur le haut du NAS

On connecte le câble d’alimentation sur une broche d’alimentation libre et au SSD. Pour le câble SATA, rien de bien compliqué, la machine dispose d’un port libre sur l’un de ses côtés. En mettant en place les différents éléments, j’ai constaté que la machine semble également disposer d’un emplacement pour carte SD. Il pourrait donc être intéressant d’effectuer l’installation du système sur une carte SD, plutôt que sur le disque SSD. Ainsi, le pourcentage d’utilisation de l’espace disque serait bien plus optimisé qu’avec le SSD où plusieurs dizaines de gigaoctets sont inutilisés.

nas_2
Câble SATA connecté sur le port libre de la carte mère

Au niveau matériel, notre NAS est donc prêt à fonctionner. Il reste une petite subtilité à effectuer afin de s’assurer que le NAS démarrera sur le SSD. Pour cela, il convient de créer un Array RAID contenant notre disque et de demander au BIOS de booter dessus. Voir l’étape 2 de l’article de L’Atelier du Geek pour tous les détails.

nas_3
Préparation du boot sur le SSD

Une fois ces opérations effectuées, on peut se tourner vers l’installation du système d’exploitation du NAS. J’ai moi aussi choisi OpenMediaVault. On récupère l’ISO, un coup de dd pour créer une clé USB d’installation et le tour est joué, l’installation peut commencer.

Pas de difficultés particulières de ce côté là, des questions classiques pour qui aura déjà installé un système GNU/Linux. Une fois l’installation terminée et le NAS éteint, on peut se tourner vers la mise en place des disques de données.

Unity3D : gestion des bords de l’écran

Définition du problème

J’ai passé quelques temps à comprendre comment gérer la détection des bords de l’écran pour ne pas que mon gameobject en sorte.

Dans mon cas le gameobject dirigé par le joueur est un cube auquel on ajoute un BoxCollider, la caméra est fixe.

Dans Unity on gère la position d’un objet par son attribut position (un Vector3 donnant le positionnement du centre de l’objet).

Malheureusement pour moi le composant camera de Unity permet seulement de trouver la taille en pixels de l’écran (maCamera.pixelHeight et maCamera.pixelWidth) et donc je me suis mis à chercher un moyen de déterminer en pixel l’endroit où se trouve mon cube afin de savoir si celui-ci est en dehors ou en dedans de l’écran. En gros si mon cube est entièrement visible ou non !

De l’intérêt d’utiliser un BoxCollider

Pour déterminer le centre de mon cube ainsi que sa taille j’utilise les valeurs récupérables dans l’attribut bounds du composant :

//dans start()
joueurX = this.GetComponent<Collider>().bounds.size.x/2;
joueurY = this.GetComponent<Collider>().bounds.size.y/2;

//dans update()  centreJoueurX = this.GetComponent<Collider> ().bounds.center.x; centreJoueurY = this.GetComponent<Collider> ().bounds.center.y; 

Aux tests à effectuer

if (maCamera.WorldToScreenPoint(new Vector3(0,(centreJoueurY+joueurY),0)).y > pixelHeight) {
//on stop le déplacement
directionJoueur = 0;
this.gameObject.transform.localPosition += (-mouvementY * speed * Time.deltaTime);
} 
else if (maCamera.WorldToScreenPoint(new Vector3(0,(centreJoueurY-joueurY),0)).y  < 0) {
directionJoueur = 0;            this.gameObject.transform.localPosition += (mouvementY * speed * Time.deltaTime);
} 
else if (maCamera.WorldToScreenPoint(new Vector3((centreJoueurX+joueurX),0,0)).x > pixelWidth) {
directionJoueur = 0;             this.gameObject.transform.localPosition += (-mouvementX * speed * Time.deltaTime);
}
else if (maCamera.WorldToScreenPoint(new Vector3((centreJoueurX-joueurX),0,0)).x < 0) {
directionJoueur = 0;                                           this.gameObject.transform.localPosition += (mouvementX * speed  * Time.deltaTime);
}


Voilà pour le système utilisé actuellement, on peut bien entendu imaginer un système pour ne pas refaire les tests à chaque update() mais uniquement au moment voulu.

WordPress, xmlrpc et déni de service

Certains d’entre vous l’ont peut-être constaté, il était plutôt compliqué d’accéder à unicoda.com durant les dernières 48h. En effet, il se trouve que le site a été la cible d’une attaque de type brute force qui l’a mis à mal. Résultat, un processus apache qui décolle et accapare toutes les ressources de la machine jusqu’au déni de service. Retour sur la folle vie d’un serveur attaqué.

Tout commence le 25 août 2016 aux alentours de 19h, la première requête de la série apparaît à 18 heures 46 minutes et 25 secondes pour être précis.

191.96.249.54 - - [25/Aug/2016:18:46:25 +0200] "POST /xmlrpc.php HTTP/1.0" 200 579 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
191.96.249.54 - - [25/Aug/2016:18:46:25 +0200] "POST /xmlrpc.php HTTP/1.0" 200 579 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
191.96.249.54 - - [25/Aug/2016:18:46:25 +0200] "POST /xmlrpc.php HTTP/1.0" 200 579 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"

À cette heure-là, pas de problème, le serveur fonctionne correctement. La première alerte sera levée par le système de monitoring d’OVH à 22h54 ce même jour. Le serveur a déclaré forfait et ne répond plus au ping. Quelques minutes plus tard, le support intervient et redémarre le serveur. Une nouvelle alerte sera levée vers 4h du matin, avec intervention du support. En découvrant les mails le matin, je ne flaire pas immédiatement l’attaque. Le support est intervenu, il n’y a pas de précision indiquant si le problème vient du logiciel ou du matériel côté hébergeur, le site ne s’affichant pas, j’effectue à mon tour un redémarrage du serveur et m’assure que les différents services sont bien repartis. Tout semble fonctionner… Pourtant, même scénario dans la nuit de vendredi à samedi avec deux interventions du support. Quelque chose cloche, je continue de vaquer à mes occupations lorsque le serveur devient une nouvelle fois inaccessible samedi vers midi. Pas doute il y a un problème, je vais devoir effectuer des vérifications dès que possible.

Continuer la lecture de « WordPress, xmlrpc et déni de service »

dd ? Et pourquoi pas, dcfldd ?

Si vous avez un peu joué avec le Raspberry Pi, vous êtes certainement familier avec la commande dd, en particulier si vous avez installé l’OS sur carte SD depuis GNU/Linux. Peut-être avez-vous même effleuré sa consœur, j’ai nommé: dcfldd.

J’ai découvert cette version du programme dd lors de ma dernière installation de Raspbian. Bien que celle-ci soit un peu ancienne et peu mise à jour, nous pouvons tout de même parler de version améliorée du programme d’origine. L’outil est développé par le « laboratoire des investigations informatiques » américain (Defense Computer Forensics Lab), aussi abrévié DCFL, d’où le nom de l’outil: dcfldd.

Du côté des fonctionnalités, on notera la possibilité d’effacer un disque en utilisant des motifs connus, ou encore celle de vérifier qu’une image est identique à l’originale bit à bit. dcfldd propose également un suivi de la quantité de donnée traitée au fur et à mesure de son avancement.

La dernière version stable date du 19 décembre 2006. Les dernières modifications sont à peine plus récentes et datent quant à elle du 4 décembre 2007. En comparaison, les dernières modifications du programme original ont eu lieu en janvier 2016, dcfldd ne dispose donc pas de toutes les améliorations qui ont pu être apportées à dd depuis 2008. Une mise à jour du code serait donc appréciable, mais l’opération ne serait pas forcément aisée.

Ces derniers temps, j’ai principalement utilisé dcfldd plutôt que dd afin de profiter de l’information d’avancement du travail en cours donnée par défaut par la commande. Néanmoins, à l’avenir, dd devrait faire l’affaire, puisqu’il existe une option status=progress permettant de suivre l’avancement de l’opération. Le comportement par défaut de dd étant de ne rien afficher avant que la tâche soit terminée. Ce sera donc un retour probable à dd pour les prochaines opérations.

 

Voir aussi : http://forensicswiki.org/wiki/Dcfldd