07 Nov 2018, 00:00

Réinitialiser le mot de passe BIOS sur certains portables HP

HPBR

Un outil nommé HP Bios Reset permet, sur certains modèles, notamment des Probook et des Elitebook, de réinitialiser le mot de passe du bios. Lien vers le thread mydigitallife.
Et un exemplaire de HPBR mirroré chez moi

Il faut déjà créer la clé bootable.
Depuis Windows, il suffit de lancer l’exécutable, de brancher la clé (qui sera effacée), la sélectionner, cliquer sur Restore, choisir le fichier image fourni dans l’archive.
Sous Linux, je n’ai pas testé, mais je présume que l’image se dumpe simplement sur la clé avec dd.

On boote l’ordinateur sur la clé. Au lancement, il faut en trer les commandes suivantes :

cd ..
HPBR

Dans “reprogram” on peut sauvegarder les informations actuelles (fichiers .sav dans le répertoire HPBR).
Dans “first run” on peut lancer la réinit du mot de passe du bios en choisissant le bon modèle.

Forcer l’upgrade du bios

Dans mon cas, le bios était trop vieux, et n’était pas supporté par HPBR. J’ai donc du faire la mise à jour, mais la procédure standard me demandait le mot de passe, que je n’avais toujours pas.

Pour ceci, des indications données sur ce post peuvent être utiles. Les images et signatures de BIOS sont stockées dans le dossier Hewlett-Packard/BIOS/Current. L’image HPBR en contient certains, mais pas tous. On peut donc rajouter celui d’un autre modèle.
J’ai donc récupéré le bios le plus récent sur le site de support de HP.
J’ai extrait le fichier exe, puis le fichier rom.cab.
Dedans, il y’a un fichier “ver.txt”, on trouve dedans le numéro de la ROM, par exemple _ROM_ 68PDD v0F.20 12/07/2011 ROLL_BACK_WARNING
Dans ce cas, c’est “68PDD”. On renomme rom.bin par 68PDD.bin et efibios.sig par 68PDD.sig, on copie ces 2 fichiers dans “Current” (à noter que sur un clé usb vierge en fat32, l’arborescence et ces 2 fichiers suffisent pour la MAJ du BIOS, pas besoin de HPBR).
On éjecte la clé proprement.

Ensuite, il faut faire booter l’ordi sur la clé, mais pas par le boot habituel. Il faut, ordi éteint, brancher la clé, maintenir Super+B, allumer le pc en maintenant les touches enfoncées, normalement la LED de VerrMaj clignote, puis le voyant de la clé usb (s’il y’en a un…) va commencer à clignoter. C’est le moment de relacher les touches.

Normalement l’écran reste noir, pendant au maximum 2 minutes (selon le readme), puis devrait redémarrer tout seul et informer du succès de la mise à jour. Il est alors possible de reset le mot de passe via HPBR
Si rien ne se passe au bout de 10 minutes (soyons précautionneux…) ,c’est que la MAJ n’a pas réussi, et il faut redémarrer le poste.

29 Oct 2018, 00:00

Utilisation de ddrutility pour identifier les secteurs contenant de la données NTFS pour une utilisation optimale de ddrescue

Cet article se penche sur l’utilisation de ddrutility pour créer un fichier de carte de domaine à utiliser avec ddrescue, afin de focaliser ce dernier sur les secteurs qui contiennent effectivement des données. Dans cet exemple, je ne parle que du ntfs.

L’ensemble d’utilitaires ddrutility peut être installé depuis les dépôts Debian à partir de Buster, ou bien compilé depuis la source disponible ici.

L’utilitaire qui nous intéresse : ddru_ntfsbitmap qui va créer un fichier “domain_mapfile”, c’est-à-dire une liste des secteurs à lire sur la partition ntfs (secteurs effectivement utilisés).
Ceci ne fonctionnera que si ddrescuelog est présent dans la release de ddrescue (à partir de la version 1.15, normalement)

Création du fichier de délimitation du domaine

Voici la syntaxe pour une partition seule :

sudo ddru_ntfsbitmap /dev/sdX1 ./domain_ntfs.log

Dans mon cas, j’ai l’habitude de dumper le disque en entier, y compris la table de partitions. Pour ceci, il faut calculer l’offset de la partition (en octets) avec des maths assez simples : multiplier le secteur de démarrage de la partition par la taile d’un secteur en octets. Pour ceci : sudo fdisk -lu /dev/sdX qui nous donne par exemple :

Disk /dev/sdX: 465,7 GiB, 500074283008 bytes, 976707584 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0004a183

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdX1        2048 976707583 976705536 465,7G  7 HPFS/NTFS/exFAT

On voit que la partition démarre au secteur 2048, et que chaque secteur pèse 512 bytes (octets). On multiplie donc : 2048*512 = 1048576, puis on passe l’argument -i à ddrutility, ce qui donne la commande

sudo ddru_ntfsbitmap /dev/sdX ./domain_ntfs.log -i 1048576

Ceci va aller lire le secteur de boot de la partition ntfs, puis la section bitmap afin de déterminer quels sont les clusters sur lesquels des données sont stockées. Selon la doc de ddrutility, si des secteurs du bitmap sont illisibles, alors ddrutility va les remplir avec le motif 0xFF (soit uniquement des 1), ce qui signifie que les secteurs en question sont utlisés pour stocker des données. Ainsi, en l’absence de certitude (grâce à la lecture correcte du bitmap) qu’un secteur est inutilisé, alors il sera extrait par ddrescue. On a ainsi le “risque” de lire des secteurs inutilisés, mais beaucoup moins de risque de sauter des secteurs sur lesquels des données sont effectivement stockées !

On obtient plusieurs fichiers en résultat :

  • __bootsec qui est un dump du secteur de boot de la partition (et est utilisé pour trouver l’emplacement de la MFT
  • __bootsec.log : la mapfile ddrescue utilisée pour l’extraction du secteur de boot

  • __mftshort : dump de la MFT

  • __mftshort.log : mapfile utilisée par ddrescue pour dumper la MFT

  • __bitmapfile : dump du fichier $BitMap de la partition

  • _partX__bitmapfile.log : fichier mapfile utilisé par ddrescue pour dumper le fichier $BitMap. Il est possible qu’il y en ait plusieurs si le fichier $BitMap est fragmenté

  • ntfsbitmap_rescue_report.log : résumé des différentes passes de ddru

  • domain_ntfs.log : le fichier à donner à ddrescue lors de la réelle tentative de récupération de données. Le nom dépend de la ligne de commande invoquée.

Utilisation de ce fichier avec ddrescue

Il faut impérativement penser à accorder la ligne de commande ddrescue avec celle utilisée par ddrutility pour obtenir le fichier domaine. Notamment déterminer si on dumpe une partition ou bien un disque entier. Dans mon cas, c’est un disque entier.
Une fois le fichier obtenu, on peut lancer la récupération de données avec ddrescue avec l’option -m, comme ceci :

sudo ddrescue -m ./domain_ntfs.log /dev/sdX ./disk_image.img mapfile.img

Si on souhaite suivre l’avancement en graphique avec ddrescueview, il est possible dans le menu de ce dernier d’ouvrir une mapfile de domaine (et séléctionner domain_ntfs.log). Ainsi, le secteurs hors domaine seront coloriés en grisé.

À noter qu’il est possible de combiner cette méthode avec ddrescue sans carte de domaine, en utilisant le même fichier source (disque défectueux), la même destination et la même mapfile. Après avoir laissé tourner ddrescue séquentiellement sur le disque, et une récupération extremement lente (quelques ko/s), j’ai repris l’avancement en cours en rajoutant l’argument de la carte de domaine. Il est également possible de reprendre le dump du disque sans carte de domaine une fois que tous les secteurs sur la carte de domaine ont été correctement récupérés (même si cevrait théoriquement être inutile).

28 Jul 2018, 00:00

Divers - Office 365

Création d’une boite aux lettres partagées avec déploiement automatique

Dans le centre d’administration Exchange (EAC), on peut aller dans Recipients -> Shared, et créer une boite aux lettres partagées. Tous les utilisateurs qui sont entrés dans les propriétés de la boite partagée -> Mailbox delegation -> Full access verront la boite mail ainsi que son calendrier se déployer automatiquement sur leur client Outlook (avec toutefois un délai jusqu’à une heure).
Ceci correspond à une vraie boîte mail à part entière, avec son propre espace de stockage (quota de 99Go à l’heure de cet article).

Liste de distribution (alias)

Dans le EAC -> Recipients -> Groups, on peut créer des listes de distributions. Ceci ne correspond pas à une vraie boîte mail, mais plutôt à un alias. Les messages sont transférés à tous les utilisateurs définis dans les propriétés de la liste -> Membership.
Si on souhaite qu’un utilisateur puisse écrire depuis l’adresse de la liste de distribution, il faut ajouter l’utilisateur en question dans les propriétés de la liste -> Group delegation, et ajouter son nom sous Send As (envoi en tant qu’alias) ou bien Send on Behalf (envoi en tant que user au nom de alias).

Pour que l’utilisateur puisse envoyer des messages depuis sont Outlook (version de bureau), il faut ajouter le champ De qui est masqué par défaut. Sous 2016, ceci peut se faire dans la fenêtre de rédaction d’un message, sous l’onglet Options. Ensuite, on ajoute à la main le nom de l’alias qui doit servir à envoyer le message. Si les paramètres serveur sont corrects, l’envoi devrait fonctionner.

11 May 2018, 00:00

Installer une interface réseau virtuelle sous Debian et utilisation par Virtualbox

Création de l’interface virtuelle

Chargement du module

On peut créer très simplement une interface réseau virtuelle grâce au module dummy fourni par le noyau. Pour ceci, taper :

sudo modprobe dummy

et vérifier que cela ne renvoie pas d’erreur. Il faut ajouter ‘dummy’ au fichier /etc/modules pour un chargement automatique au démarrage.

Configuration réseau

[EDIT] J’ai finalement opté pour un pont br0 qui associe dummy0 et une carte réseau physique eth1. Dans ces conditions, aucune des 2 cartes n’a d’adresse IP directement, seul br0 en possède une, et dummy0 peut rester en NOARP, cela ne genera pas la circulation des paquets.
br0 est toujours en up (contrairement à eth1 qui ne l’est pas si pas de cable branché, ce qui empeche de bridger une VM VBox dessus sans cable) et l’ARP est activé par défaut (contrairement à dummy0, ce qui empêche de bridger la VM VBox sur dummy0 sans scripter l’activation de l’ARP…)

La suite reste ici à titre informatif [/EDIT]

On ajoute ensuite une entrée dans le /etc/network/interfaces

auto dummy0
iface dummy0 inet static
    address 192.168.2.1
    netmask 255.255.255.0
    network 192.168.2.0
    broadcast 192.168.2.255

pour une adresse statique. On redémarre le service :

sudo service networking restart

et on vérifie que la carte est bien détectée avec sudo ifconfig dummy0, qui doit donner quelque chose comme ça :

dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        inet 192.168.2.1  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 fe80::440f:8eff:fe69:4e35  prefixlen 64  scopeid 0x20<link>
        ether 46:0f:8e:69:4e:35  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 107  overruns 0  frame 0
        TX packets 606  bytes 43672 (42.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

On voit qu’elle porte le flag NOARP, alors que l’arp est nécessaire pour pouvoir communiquer en ethernet. On tape donc

sudo ip l set dummy0 up arp on

On peut aussi, si on le souhaite, activer le flag multicast

sudo ip l set dummy0 up multicast on

La route vers le nouveau réseau est normalement configurée automatiquement.

Lien avec VirtualBox

Mon LAN principal est en 192.168.1.x.
Je souhaite mettre en place un réseau distinct derrière cette carte, qui aie sa propre plage IP (192.168.2.x) et serveur DHCP, pour faire des tests de serveur. Je souhaite toutefois que les VM dans ce réseau puissent avoir accès à mon LAN principal (et vice-versa), et à Internet.

Config dans VBox

Il suffit de paramétrer la carte réseau de la VM en accès ponté avec la carte dummy0.
Plusieurs VM peuvent être bridgées à cette interface, elles pourront toutes communiquer ensemble (comme autour d’un switch) ainsi qu’avec Internet via l’hôte.

Forward ipv4

Pour que la machine (Debian) hébergeant la VM accepte de transmettre les paquets, il faut taper :

sudo sysctl -w net.ipv4.ip_forward=1

afin l’activer à la volée. Et rajouter

net.ipv4.ip_forward = 1

au fichier /etc/sysctl.conf pour que ce soit pris en compte à chaque démarrage.

Routage

Il faut activer le masquerading (NAT) sur les paquets sortant par l’interface eth0 (à adapter avec le nom de l’interface réseau principale, connectée à internet. Ainsi, les périphériques ne connaissant pas le réseau VBox auront l’impression que les requêtes viennent directement de l’hôte, connu.

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Cela suffit à donner au système invité un accès complet à routes les ressources LAN/Internet.

Sous Debian, les règles iptables sont défaut perdues au reboot. Le paquet iptables-persistent peut s’occuper de les sauvegarder et restaurer au démarrage.

Cependant, je souhaitais aussi que les machines de mon LAN principal puissent accéder à toutes les machines virtuelles de mon réseau VBox. Pour ceci, il faut utiliser une route qui va vers le réseau 192.168.2.0/24 et qui a pour passerelle l’ip de la machine hôte sur le réseau principal, par exemple en 192.168.1.x. Ainsi, n’importe quel machine du LAN physique pourra accéder à n’importe quelle machine du LAN virtuel.

Cette route doit être paramétrée en statique dans le routeur, et peut éventuellement être distribuée directement aux clients par DHCP. Tous les routeurs ne permettent hélas pas ces 2 possibilités.

10 May 2018, 00:00

Mise en place d'une réplication/failover AD/DNS/DHCP/DFS sur 2 Windows Server

Préambule

Je pars d’une situation où j’ai déjà un serveur Windows 2012R2 configuré en controleur de domaine, avec GPO et partage de fichiers. Je veux ajouter un 2e serveur sous Windows Server 2016, qui fasse office principalement de failover si un des 2 serveurs tombe en panne. Ceci pour les rôles de contrôleur de domaine, de serveur DHCP, serveur DNS, de serveur SMB et déploiement automatique de partages réseaux et d’imprimantes.

Le domaine est WINDOMAIN, le serveur actuel est WINDOMAIN\DC1.

Configurer le serveur secondaire

On commence par relier le serveur au réseau, on lui configure une adresse ip fixe, le hostname souhaité (ici DC2). on le connecte au domaine.

On peut ensuite installer le rôle AD DS, puis promouvoir le serveur en contrôleur de domaine.
La réplication de l’AD se fait automatiquement, avec toutes les GPO.

DNS

Intégration à l’AD

Normalement, le serveur DNS est installé et configuré en même temps que le serveur AD DS. Ceci permet aux enregistrements DNS d’être stockés dans l’AD directement, et donc d’être répliqués entre tous les controleurs de domaine. Cela se vérifie dans le gestionnaire DNS, avec un clic droit -> Propriétés sur une zone, on doit voir l’Etat “Intégré à AD”.
Ceci ne fonctionne que si les 2 serveurs DNS sont aussi des controleurs de domaine, ce qui est le cas ici. Si un serveur DNS n’est pas controleur, il faut passer par la création sur le second serveur d’une zone secondaire qui pointera vers le premier serveur).

Un peu plus d’infos chez Microsoft

Redirecteurs

Toujours dans le gestionnaire DNS, dans les propriétés de chaque serveur, il faut penser à aller vérifier les redirecteurs (serveur DNS utilisé si le serveur intégré ne sait pas résoudre, c’est-à-dire pour tout ce qui ne relève pas du domaine). Typiquement, on peut mettre l’IP de notre box, ou 8.8.8.8 par exemple. Il y’a aussi l’option de se rapatrier sur les serveurs DNS racines en cas d’indisponibilité des redirecteurs. On trouve la liste de ces serveurs dans l’onglet “Indications de racine”.

Distribution par DHCP

Enfin, il faut aller paramétrer les options du DHCP pour qu’il distribue les 2 serveurs DNS. Pour ceci, dans DC1 (actuellement le seul serveur DHCP), aller dans le gestionnaire DHCP, IPv4 -> Étendue -> Options d’étendue et ajouter l’IP du nouveau serveur dans les Serveurs DNS (006).

Note : si un des 2 serveurs venait à être en panne/hors-ligne durablement, penser à s’assurer que le serveur toujours en place est bien distribué en serveur primaire, ceci accélérera la résolution DNS.

DHCP

La première étape est d’avoir une étendue active sur un des 2 serveurs, dans cet exemple sur DC1. Si ce n’est pas le cas, on peut en créer une dans le gestionnaire DHCP -> Nouvelle étendue. L’installation est complètement guidée.
Penser à spécifier les options telles que serveurs DNS, passerelle par défaut.

Sur DC2, installer le rôle Serveur DHCP. Ne pas configurer d’étendue maintenant, elle va être automatiquement répliquée depuis DC1.
Aller sur DC1 dans le gestionnaire DHCP, IPv4 -> Clic-droit sur “Étendue” -> Configurer un basculement
Suivre les étapes en ajoutant l’IP du serveur secondaire (DC2).

Au cours de la création du basculement, les options du serveur DHCP de DC1 seront répliquées sur DC2 (étendue, route par défaut, serveur DNS etc°. Toutefois ces options ne seront par la suite plus synchronisées automatiquement. Pour les synchroniser, on peut lancer sur le serveur “source”, qui possède les informations à jour, la commande Powershell suivante :

Invoke-DhcpServerv4FailoverReplication

qui va répliquer l’ensemble de ses paramèters sur tous les serveurs partenaires.
Il y’a aussi un script planifié qui permet de faire ceci automatiquement, disponible sur cette page avec l’archive zip mirroré sur mon memo.

Si on souhaite supprimer la relation de basculement, il faut savoir que si on procède à la déconfiguration du basculement sur DC1, cela supprimera automatiquement l’étendue sur DC2 (et vice-versa).

Partage de fichiers

Afin d’assurer l’accès aux partages réseaux même si un des 2 serveurs (hébergeant directement les données) tombe, nous allons passer par la réplication DFS. Celle-ci va nous permettre une synchronisation instantanée et permanente de l’état des dossiers de travail, tout en y accédant de manière transparente par le réseau, via un espace de nom DFS.

Dans mon cas, je pars d’un dossier de travail déjà existant, sur DC1, avec le chemin D:\Travail\. Celui-ci est paramétré avec des droits d’accès spécifiques, et le partage réseau est déployé automatiquement via GPO avec le chemin \\DC1\Travail\.

Configuration de la réplication DFS (DFSR)

Il faut commencer par installer le rôle Services de fichiers et de stockage -> Services de fichiers et iSCSI -> Espaces de noms DFS et Réplication DFS sur DC1 ET sur DC2.

On lance le Gestionnaire de système de fichiers distribué DFS.
Réplication -> Nouveau groupe de réplication.... J’ai laissé le choix par défaut, groupe de réplication multi-usages.
On donne un nom au groupe de réplication, dans mon cas “Travail”.
On ajoute DC1 et DC2 dans la liste des serveurs.
Pour une réplication dans les 2 sens, quel que soit le serveur sur lequel les données sont modifiées, on choisit “Maille pleine”. J’ai laissé les options de bande passante par défaut, puisq’on est ici en réseau local.

On prend bien garde à choisir le serveur qui contient actuellement les données en tant que Membre principal. Il s’agit ici de DC1, car DC2 ne contient actuellement aucune donnée. Ainsi, au cours de la synchro initiale, toutes les données présentes actuellement sur DC1 seront répliquées sur le ou les autres serveurs. une fois la synchro initiale terminée, cela ira dans les 2 sens.

On choisit ensuite le dossier local où sont stockées les données sur DC1. C’est D:\Travail comme indiqué au-dessus.
Note : Microsoft eux-même déconseillent de répliquer directement une lettre de lecteur, bien que ce soit censé fonctionner. J’ai personnellement eu des soucis lorsque j’ai essayé. Il faut ensuite la réplication sur chaque serveur membre. On coche la case Activé, et on définit un chemin local sur le membre en question. Il n’est pas obligatoire que tous les membres aient le même chemin d’accès local.

On valide, et la réplication commencera sous peu. Les données seront ainsi sur les 2 serveurs. Toutefois, le partage réseau déployé chez les clients ne fait toujours appel qu’au serveur DC1.

Configuration de l’espace de nom DFS (DFSN)

Généralités

L’idée est de pouvoir centraliser les partages réseaux en y accédant via le nom de domaine. Par exemple, au lieu de déployer \\DC1\Travail, on va déployer le partage \\WINDOMAIN\Travail, et ce sera un des serveurs qui hébergent l’espace de nom Travail qui va répondre.

Cette techno est complètement dissociable de la réplication, bien qu’elles soient souvent utilisées ensemble. On peut décider de partager sous des chemins unifiés des ressources venant de serveurs différents (par exemple \\DC1\Travail et \\DC2\Direction, même si uniques sur leurs serveurs respectifs, peuvent être accessibles sous \\WINDOMAIN\Travail et \\WINDOMAIN\Direction). On peut aussi utiliser la réplication sans espace de noms, juste pour dupliquer les données d’un site à l’autre par exemple.

Si 2 serveurs hébergent le même espace de nom, mais sans réplication des dossiers, le contenu affiché sera alternativement le contenu de l’un ou l’autre. Par exemple, si \\DC1\Travail et \\DC2\Travail sont tous les 2 référencés par l’espace de nom \\WINDOMAIN\Travail mais que les 2 dossiers ne sont pas répliqués et ont des contenus différents, on ne sait jamais quel sera le contenu affiché par \\WINDOMAIN\Travail, ce sera celui qui répond le plus vite.

Mise en place

On ouvre le gestionnaire DFS.
Espace de noms (clic-droit) -> Nouvel espace de noms. On choisit DC1 comme premier serveur. On nomme notre espace de nom, ici Travail ; Dans Modifier les paramètres, on peut choisir l’emplacement des données locales. On choisit ici D:\Travail, comme défini précédemment, et on choisit les droits d’accès Admin : Full ; Users : RW (les vrais droits d’accès sont gérés par le NTFS).
On choisit l’option “Espace de noms de domaine”, puis on valide la création.

Le serveur DC1 est maintenant prêt à répondre lorsqu’on appelle \WINDOMAIN\Travail. On veut maintenant que DC2 puisse répondre aussi. Pour ceci, dans le gestionnaire DFS, sous Espaces de noms, clic-droit sur \WINDOMAIN\Travail -> Ajouter un serveur d’espaces de noms. Comme ci-dessus, on rentre le nom du serveur, on choit l’emplacement local des données, on met les droits sur le partage et on valide.

Et voilà : les 2 serveurs sont désormais capables de répondre lorsque l’on interroge le partage directement auprès du domaine, et grace à la combinaison avec la réplication, la continuité en cas de chute d’un serveur est quasi-transparente (à un caffouilage d’explorer près, sur les postes clients).

Note : il est possible, directement sous l’espace de noms DFS? de “Publier” des dossiers, qui seront créés puis partagés automatiquement, et référencés dans le gestionnaire. Il n’est pas du tout obligatoire de les utiliser si l’on souhaite créer des sous-dossiers et les partager, et le faire manuellement permet une plus grande souplesse (chemin du partage réseau notamment).

05 May 2018, 00:00

Chemin absolu dans un script bash

Pour lancer un script bash en se positionnant initialement dans le répertoire qui contient ce script bash (nécessaire dans certains cas, par exemple pour qu’un exécutable de jeu trouve le dossier data dont il a besoin pour se lancer, dans le cas des jeux Unity), ce de manière automatique quel que soit le répertoire en question, et même s’il a des caractères spéciaux du type espace ou accent, il suffit de faire commencer le script par cette ligne :

cd "`dirname "$0"`"

Cette commande va chercher le chemin complet du script lancé ($0) et y positionne le terminal.

05 May 2018, 00:00

Librairies pour les jeux sous Wine

Pour résoudre des erreurs de type

0009:err:d3dcompiler:compile_shader HLSL shader parsing failed

tester

winetricks d3dcompiler_43

28 Apr 2018, 00:00

Supprimer récursivement les fichiers corrompus suite à récupération de données peu concluante

Suite à une récupération de données via ddrescue qui n’a que peu fonctionné, le disque ne répondant rapidement plus du tout, j’ai essayé de tirer parti du peu que j’avais en ma possession.

L’image a été montée sous Windows via VirtualBox, les chkdsk nécéssaires ont été effectués, le système de fichier est redevenu lisible sous Linux comme sous Windows, mais malgré ça, une bonne partie des fichiers référencés par le NTFS n’étaient pas lisibles, car leur emplacement (qui n’a pas été dumpé depuis le disque) ne contenait rien d’autre que des 0.

Lorsque, sous Linux, on fait un file monfichier.jpg, on voit que dans le cas d’un fichier corrompu, comme il n’y a aucune donnée à analyser, le retour est un simple “data”.

J’ai donc utilisé cet indicateur pour supprimer tous les fichiers sans donnée, via le script suivant, rangé sous ~/del_empty.sh :

#!/bin/bash

cd "$1"
for i in *; do
    type=`file -b "./$i"`
    if [ "$type" = "data" ]
    then
        rm "./$i"
    fi
done

Ce script, qui fait référence à la variable de position $1, est voué à être utilisé en conjonction avec la commande find :

find /path/to/data/ -type d -exec ~/del_empty.sh {} \;

Puis on supprime automatiquement les dossiers vides

find /path/to/data/ -type d -empty -print -delete

Il ne reste plus qu’à découvrir ce qu’il reste des données initiales…

27 Apr 2018, 00:00

Monter une image de disque complet sous Linux (y compris Gparted, et VirtualBox)

Présentation et analyse

Si on a créé une image entière de disque (par exemple avec dd , dcfldd ou bien ddrescue), il est possible de la monter au sein du système, pour qu’elle soit détectée par le noyau, par Gparted, et même transférable (en tant que disque brut) à une machine virtuelle sous VirtualBox.

Dans mon exemple, on a le fichier /home/user/sdi.img, qui est une image complète d’un disque (avec le boot code et la table de partition, dans cet exemple au format MBR).

On vérifie la structure de l’image (qui doit être une copie du disque, donc avec une ou des partitions) : sudo fdisk -l ~/sdi.img. Chez moi, ça donne :

Disk sdi.img: 1,8 TiB, 2000399892480 bytes, 3907031040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x909b28dc

Device     Boot Start        End    Sectors  Size Id Type
sdi.img1   *     2048 3907031039 3907028992  1,8T  7 HPFS/NTFS/exFAT

J’ai bien la partition sdi.img1, formattée en NTFS.

Montage du disque complet

On utilise pour ça la commande losetup (en root).
Si on l’exécute toute seul, elle nous liste les périphériques actuellement montés. Par défaut, ce devrait être vide.
Si on l’exécute avec le paramètre -f, elle nous donne le premier périphérique disponible pour monter une image. Par défaut, ce devrait être /dev/loop0.

On monte l’image sur le périphérique loop : sudo losetup -r -P /dev/loop0 ~/sdi.img.
Note : l’option -r sert à monter le périphérique en lecture seule, pour éviter les corruptions de données, au cas où.
L’image est bien montée (vérifiable avec losetup sans argument), mais la partition n’est pour l’instant pas prise en compte par le noyau. (EDIT : plus vrai avec l’option -P)

Prise en compte de la table de partition par le noyau

EDIT : l’option losetup -P permet de faire cette étape automatiquement. Ceci dit c’est toujours bien d’avoir un peu les détails des rouages :)

Pour ceci : sudo partprobe /dev/loop0.

Ceci va dire au noyau d’aller réactualiser la table des partitions connues (en l’occurence en n’analysant que le périphérique loop0). Ceci a du créer les périphériques pour chacune des partitions de l’image (pour moi une seule). On vérifie : ls -l /dev/loop0* qui donne chez moi :

 20423171 brw-rw---- 1 root disk   7, 0 avril 27 13:56 /dev/loop0
213017956 brw-rw---- 1 root disk 259, 0 avril 27 13:56 /dev/loop0p1

J’ai bien le périphérique loop0p1 qui représente la première partition de mon image. On peut alors utiliser cette partition comme une partition physique : la monter (sudo mount /dev/loop0p1 /mnt), la fsck (sudo fsck /dev/loop0p1) etc.
On peut également manipuler l’image comme un vrai disque avec Gparted : sudo gparted /dev/loop0. Il faut spécifier manuellement l’emplacement, car Gparted sans argument ne liste que les disques physiques.

À noter, si la partition a été retrécie via GParted, l’image du disque ne le sera pas pour autant (car l’espace non-partitionné existe toujours). Pour ceci, suivant les conseils de ce billet, on peut lancer la commande sudo fdisk -l /home/user/sdi.img pour analyser la table de partition, puis utiliser la commande truncate pour couper l’image dès que la partition se finit. Pour ceci, on multiplie le numéro de secteur final de la dernière partition+1 par la taile des secteurs (logique, je suppose, en cas de différence entre physique et logique. A vérifier).

Par exemple, selon mon exemple en début d’article :

truncate --size=$[(3907031039+1)*512] /home/user/sdi.img

Accès à l’image depuis Virtualbox

VirtualBox permet l’accès depuis le système invité aux disques physiques de la machine hôte. Cela se fait via les disques virtuels VMDK.

Cette partie est grandement recopiée de ce billet.

On commence par s’assurer qu’on fait bien partie du groupe disk : sudo usermod -G disk -a user_name (et on pense à log out pour appliquer les modifs). Ceci permet de pouvoir accéder aux disques sans avoir besoin de lancer VB en root.

On crée le fichier vmdk avec la commande suivante : VBoxManage internalcommands createrawvmdk -filename image.vmdk -rawdisk /dev/loop0. Ceci va donner l’accès au disque complet.

Si on souhaite ne donner accès qu’à une partition, on peut utiliser l’option -partitions 2 (pour donner l’accès à la 2ème partition).
A noter que, selon ce Github, cet outil n’est capable de comprendre que les tables MBR. L’outil proposé par le github lui-même semble capable de lire le GPT aussi.

Une fois le fichier créé, il n’y a plus qu’à l’ajouter dans la configuration Stockage de la machine virtuelle.

Démontage

Une fois que l’on a fini, on peut démonter la partition de son point de montage (umount), puis démonter l’image du périphérique loop0 via la commande sudo losetup -d /dev/loop0.

[EDIT : avec l’option -P au montage, losetup supprimera les blocks partitions au démontage, l’étape suivant n’est donc pas nécessaire.]

Ceci ne supprime néanmoins pas le block /dev/loop0p1. Pour ceci : sudo delpart /dev/loop0 1.
C’est l’inverse de partprobe, cette commande dit au noyau d’oublier la partition 1 du périphérique loop0. A faire pour chaque partition.

08 Apr 2018, 00:00

Lancer server Xorg sans ecran connecté (Nvidia)

Sur une machine avec une GTX 1070, Xorg refusait de se lancer si un écran n’était pas physiquement connecté à la carte. Le fichier /etc/X11/xorg.conf suivant fait l’affaire (c’est probablement sur les sections Screen qu’on peut simuler la conection des écrans). L’option Coolbits sert à activer les possibilités d’overclocking.

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 375.26  (buildd@debian)  Fri Jan 13 02:38:29 UTC 2017

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0"
    Screen      1  "Screen1" RightOf "Screen0"
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       28.0 - 33.0
    VertRefresh     43.0 - 72.0
    Option         "DPMS"
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       28.0 - 33.0
    VertRefresh     43.0 - 72.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 1070"
    BusID          "PCI:1:0:0"
EndSection

Section "Device"
    Identifier     "Device1"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 1070"
    BusID          "PCI:2:0:0"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "AllowEmptyInitialConfiguration" "True"
    Option         "UseDisplayDevice" "DFP-0"
    Option         "Coolbits" "28"
    Option         "ConnectedMonitor" "DFP-0"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Section "Screen"
    Identifier     "Screen1"
    Device         "Device1"
    Monitor        "Monitor1"
    DefaultDepth    24
    Option         "AllowEmptyInitialConfiguration" "True"
    Option         "UseDisplayDevice" "DFP-0"
    Option         "Coolbits" "28"
    Option         "ConnectedMonitor" "DFP-0"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection