geoffrey/blog.frogeye.fr
geoffrey/blog.frogeye.fr
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

_posts/2018-10-22-acceder-a-un-peripherique-bloc-a-distance.markdown

Browse source
This commit is contained in:
Geoffrey Frogeye 2018-10-22 14:04:08 +02:00
parent b1c3960181
commit f1ced5e9fc
2 changed files with 57 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
_config.yml
View file

@ -5,7 +5,7 @@ description: > # this means to ignore newlines until "baseurl:"
Ceci est le blog de Geoffrey "Frogeye" Preud'homme. Vous y trouverez
de tout et de rien, vous êtes prévenus !
baseurl: "" # the subpath of your site, e.g. /blog/
url: "http://blog.frogeye.fr" # the base hostname & protocol for your site
url: "https://blog.frogeye.fr" # the base hostname & protocol for your site
twitter_username: GeoffreyFrogeye
github_username: GeoffreyFrogeye

56
_posts/2018-10-22-acceder-a-un-peripherique-bloc-a-distance.markdown Normal file
View file

@ -0,0 +1,56 @@
---
layout: post
title: "Accèder à un périphérique bloc à distance"
date: 2018-10-21 14:00:00
categories: linux rescue disk network
---
<!-- L'article a été rédigé le 2018-10-22 mais Jekyll n'aime pas cette date, allez savoir -->
# Contexte
J'aime beaucoup tester des trucs sur mon serveur, notamment avec le système de fichiers BTRFS.
Sauf que j'ai fait l'erreur de [compresser `/boot` avec une méthode que Grub ne supporte pas](https://askubuntu.com/q/1056396/342879), et après un [reboot malencontreux](https://oc.todon.fr/@GeoffreyFrogeye/100938592425275062) mon système ne peux plus booter.
Qu'à cela ne tienne, je me pointe vers mon panel OVH et démarre en rescue avec une image d'Arch.
Sauf que le mode rescue utilise la clef SSH que j'ai utilisé pour créer le serveur et que j'ai détruite depuis le temps, et [impossible de la changer](https://twitter.com/GeoffreyFrogeye/status/1054315898566250496).
Ma seule option est donc de démarrer sur l'image de rescue « Made in OVH », dont le noyau n'est pas suffisament récent pour monter ma partition BTRFS (à jouer avec le feu...).
Plutôt que de recompiler un noyaux linux avec les bonnes options, je préfère plutôt monter le disque à distance depuis mon laptop et réparer mes dégâts d'ici (ça implique une bonne connexion).
# Réalisation
> **Avertissement :** Je vous donne ma méthode quick'n'dirty à défaut d'avoir trouvé quelque chose qui expliquait ce que je voulais faire simplement, mais je vous renvoie à la documentation si vous souhaitez utiliser ça de manière propre.
> Je ne sais d'ailleurs aucunement si il y a une méthode de correction d'erreur, donc à vos risques et périls (et évitez le Wi-Fi).
Sur la machine avec le périphérique bloc à monter (dans mon cas `/dev/sdb1`), installez le paquet `nbd-server` (ou `ndb` selon la distribution).
Modifiez ensuite le fichier `/etc/nbd-server/config` comme suit:
```ini
[generic]
# Mettez en root ou changez les permissions de l'utilisateur `ndb` pour
# qu'il puisse ouvrir le périphérique voulu.
user = root
group = root
[export1]
exportname = /dev/sdb1
```
Ensuite, lancez `nbd-server 4567`, 4567 étant un numéro de port choisi aléatoirement.
À noter que le processus se fork en arrière plan donc pas de sortie et il vous rend l'accès au terminal tout de suite.
Pour vérifier que ça a fonctionné, `netcat localhost 4567` devrait vous afficher quelque chose commencant par `NDB`.
> **Attention :** En lançant cette commande vous exposez n'importe qui pouvant accéder à la machine peut lire/écrire dans votre périphérique.
> Personnellement j'ai joué la carte du « Qui va trouver et exploiter la vulnérabilité en 10 minutes sérieux ? » mais je vous renvoie au manuel de `ndb-server` pour ajouter au moins un filtrage IP.
Sur la machine qui va monter le périphérique, installez le paquet `nbd-client` (ou `ndb` selon la distribution).
Lancez ensuite `nbd-client -no-optgo 10.0.0.42 7894 -N export1` avec 10.0.0.42 l'ip de la machine avec le périphérique à monter.
L'option `-no-optgo` n'était nécessaire que dans mon cas, la version de `nbd-client` étant superieure à celle de `ndb-server`
Vous devriez obtenir un message vous informant que vous avez créé le périphérique `/dev/ndb0`, que vous pouvez désormais monter comme si vous étiez sur la machine distante.
Sur une connexion à 100 Mbps rien ne m'a semblé plus lent que si j'étais en local, mais je n'ai pas non plus testé énormément de choses.
# Références
- [Readme du projet NBD](https://github.com/NetworkBlockDevice/nbd/blob/master/README.md)
- Le manuel de NBD
- [La seule occurence de NBD sur le wiki Arch](https://wiki.archlinux.org/index.php/Diskless_system#NBD_2)