Blog de Geoffrey Frogeye

Un problème tout con

Sat, 10 Aug 2019 15:00:00 +0000

Tout à l’heure, en voulant paramètrer un add-on Firefox, je me suis retrouvé avec un PC qui ne bootait plus (relevant xkcd). Je vous passe les détails de comment je suis arrivé là, mais comment j’ai essayé de le résoudre c’était plutôt intéressant.

En fait, pour ma configuration BTRFS + dm-crypt, j’ai besoin de trois options dans GRUB: cryptdevice pour lui dire qu’il doit déchiffrer tel disque, root pour lui dire sur quoi il doit booter (le disque déchiffré) et rootflags pour lui dire de booter sur un certain sous-volume BTRFS.

Ces trois paramètres sont définis dans ma config GRUB, sauf que depuis une mise à jour root et rootflags se génèrent automatiquement, faisant en sorte que ces deux machins soient dupliqués, ce que GRUB aime pas du tout, d’où le système non-bootable ¹.

Pour corriger le problème, c’est très simple, il suffit d’enlever les paramètres en double du fichier de config, et si le système est déjà plus bootable, le faire dans l’éditeur de config integré de GRUB. Hyper simple.

Sauf que ça, je l’ai appris bien plus tard, et entre temps j’ai énormément perdu de temps. Voyez plutôt :

Forcer le reboot après avoir lancé des programmes qui abusaient un peu sur l’I/O.
Voir que ça démarre pas. Soupçonner la corruption disque à cause du reboot forcé.
Tooter sur le fait.
Survoler la config GRUB délibérément ignorer le fait qu’il y a deux root: « Bah, ça devrait pas gêner c’est deux fois la même chose » (spoiler: non).
Préparer à manger en guise de procrastination en croyant connaître les étapes qui arrivent.
Télécharger la dernière ISO d’Arch via DriveDroid² sur mon téléphone, et attendre (oui ça aurait été moins con une étape plus tôt).
Tenter de booter dessus via DriveDroid, voir que ça marche pas.
Trifouiller les paramètres de DriveDroid.
Trifouiller les paramètres de boot du PC.
Lancer l’assistant de configuration de DriveDroid au cas où.
Abandonner et aller chercher une clef USB et un adaptateur USB-OTG pour graver l’image dessus.
Retrouver la bonne commande pour passer en root sur Termux.
Vérifier si il n’y a pas d’arguments nécessaire pour graver l’image avec dd sur le wiki Arch.
Se perdre sur le Arch Wiki à l’idée d’avoir une clef bootable Arch avec tous les drivers dont j’ai besoin dessus afin d’éviter 14 étapes.
Tooter sur la reflexion.
Lancer dd, et attendre (oui ça aurait été moins con deux étapes plus tôt).
Booter sur la clef, voir que ça marche pas.
Défaire les paramètres trifouillés en 9.
Booter sur la clef, voir que ça marche.
Entrer en mode : « Va falloir installer des trucs, il me faut une connexion internet ».
Vouloir installer les pilotes Wi-Fi. Je vous passe les détails, c’est chiant.
Se rendre compte que c’était pas nécessaire parce qu’ils sont déjà inclus pour ce PC là.
Vouloir configurer wpa_supplicant en récupérant tant bien que mal de la conf un peu partout.
Se rendre compte que j’ai foutu ma conf /etc sur un git privé et que j’ai qu’à recopier la config.
Probablement quelques instants avant, se rendre compte qu’on utilie pas DriveDroid et qu’on peut faire un partage de connexion par le téléphone, c’est quand même beaucoup plus simple.
Faire un pacman -Syu parce que va falloir installer des trucs.
Essayer d’installer yay parce qu’on va avoir besoin de trus de AUR.
Raté, il faut un compte non-root pour créer des paquets. En créer un.
Lancer la création, partir manger (ça a refroidi en attendant) le temps que go se télécharge (oui j’ai pas été con cette fois. Sauf que…).
Revenir, voir que ça a foiré au bout de 60 secondes parce que go est super lourd et que le disque d’installation a un espace limité d’écriture (sur la RAM).
Taper la commande pour augmenter l’espace en écriture, voir que ça marche pas.
Chercher sur internet la bonne commande, pas comprendre parce que c’est ce qu’on a tapé.
Taper la commande pour augmenter l’espace en écriture SANS FAUTE DE FRAPPE, voir que ça marche.
Attendre que go se re-télécharge.
Juste quand c’est fini, se rendre compte que ça fait deux mois qu’on utilise plus ZFS mais BTRFS donc que les drivers sont déjà installés.
Tant qu’on y est, ptet que dm-crypt est déjà installé. Semblerait que oui. Oh cool !
Tester si bcache serait pas déjà là lui aussi. Non, modprobe bcache renvoie une erreur.
Se rendre compte qu’on a qu’un seul paquet à installer depuis AUR, bcache-tools. Annuler l’installation de yay et installation manuelle de bcache-tools.
Pardon, installation manuelle SANS FAUTE DE FRAPPE (oui ça m’a pris une putain de minute pour m’en rendre compte).
modprobe bcache. Module pas trouvé. What?.
Se rendre compte qu’en ayant fait un pacman -Syu à l’étape 26., on a installé Linux et ses headers version 5.2.8 alors que le LiveUSB a démarré en 5.2.5. Du coup on a compilé bcache pour une version qu’on lance pas.
Essayer de forcer le chargement du module même si c’est pas la bonne version. Le système remarque le subterfuge, et refuse. Tsss…
Vouloir redémarrer. Taper reboo et se rendre compte que vu que c’est un LiveUSB, on perdra tous les changements et on redémarrera en 5.2.5.
Essayer de trouver un moyen de faire persister les changements sur la clef.
Abandonner au bout de 5 minutes au regard de la complexité du truc.
Redémarrer le LiveUSB en pensant au moyen d’installer tout ce qui est nécessaire pour compiler bcache-tools sans mettre à jour Linux.
Taper modprobe bcache pour le voir pas trouver le module.
Ça marche. QUOI !? MAIS D’OÙ ???? DSAJ3R3QIJAKLDLKAJDKLSANLKDA .
Se rendre compte que bcache-tools inclus pas le module. Il est déjà inclus dans le LiveUSB, c’est juste en faisant un pacman -Syu j’ai remplacé le module du 5.2.5 par celui du 5.2.8, incompatbile.
Voir que c’est marqué dans le premier paragraphe sur bcache du wiki Arch, que j’avais ouvert sur mon téléphone depuis longtemps.
Aller faire un tour 10 minutes dehors, profiter du soleil pour se reconcentrer après.
Suivre minutieusement les étapes de /dev/bcache device does not exist on bootup.
Se planter quand même.
Réussir à déchiffrer le disque, le monter.
Chrooter dessus.
Pardon, chrooter sur le bon sous-volume.
Tenter un pacman -Syu (mer il é fou).
Foutre un dahua pas possible parce que j’ai pas monter les sous-volumes des sous-volumes. Les monter.
Re-tenter le pacman -Syu. Voir qu’il me demande d’accepter de nouvelles clefs PGP, les accepter.
Y a beaucoup de clefs PGP à accepter. Bon, admettons, ça vient ptet du dahua.
Attendre qu’il télécharge les paquets.
Y a un problème avec les clefs PGP, truc corrompus ou je sais pas quoi. Supprimer ? Oui.
Supprimer ? Oui. Supprimer ? Oui. Supprimer ? Oui. Supprimer ? Oui. Supprimer ? Oui.
Relancer la commande. Se rendre compte que ce que j’ai supprimé tous les paquets que je venais de télécharger.
Attendre que ça se re-télécharge.
Pester pourquoi j’ai pas fait un pacman -Syu plus récemment.
Supprimer ? NON VA TE FAIRE FOUTRE.
Trifouiller avec pacman-key pour récupérer les clefs GPG. Erreur. Erreur.
Supprimer TOUTES les clefs PGP, relancer un pacman-key --init et un pacman-key --populate. Aucune erreur.
Relancer pacman -Syu. « J’ai pas de clef PGP ! ». Ah, je suis ptet allé un peu loin.
Réinstaller archlinux-keyring comme un sale à coup de tar xzvf.
Relancer un pacman-key --init et un pacman-key --populate. Erreur. Erreur. ERREUR.
Chercher sur internet les messages d’erreur. Tomber sur deux bugs de 2014 et 2017 avec les mêmes symptômes mais marqué comme corrigé depuis.
Ça me casse les coilles de chercher comment corriger ce problème sur mon téléphone, du coup je désactive temporairment la vérification de clefs PGP pour pacman et on verra plus tard.
pacman -Syu. « Pas trouvé / ». « Pas assez d’espace disque ». « Refuse d’installer ».
Ah oui, avec le chroot, / est pas réellement monté. Le monter.
pacman -Syu. « Pas pu trouvé / dans /etc/mtab ». « Pas assez d’espace disque ». « Refuse d’installer ».
Mais /etc/mtab c’est celui du système hôte, pas celui du chroot. Rooh, et puis va te faire foutre, je re-nique mon /etc/pacman.conf pour passer la vérification d’espace libre.
pacman -Syu. J’appréhende la prochaine emmerde. Roulements de tambours… Oh ça a marché. Ben ça alors.
Avec tous les hooks qu’il a lancé, je me dit qu’il a ptet corrigé le problème, un petit reboot pour tester ça peut pas faire de mal.
Avant ça, je re-regarde quand même /boot/grub/grub.cfg pour voir si tout va bien, tu sais, la même chose que l’étape 4., juste pas depuis Grub directement.
ENFIN, se redre compte du vrai problème. Corriger /etc/default/grub, et lancer grub-mkconfig. Rebooter.
Ça reboote pas. Évidemment, j’ai lancé un chroot comme un pécore du coup moon /boot/grub/grub.cfg utilise des préfixes du genre /boot/archlinux/ au liu de /…
Changer les 2 occurences du préfixe dans l’éditeur de config de GRUB, rebooter.
Pardon, changer les 3 préfixes. Rebooter.
Pardon, changer les 4 préfixes. Rebooter.
Welcome to ~~Mario Kart~~ Arch Linux!
Voir que tout fonctionne à partir de là. Respirer.

Putain. Tout ça pour ça.

Morale de l’histoire ? Vous avez beau connaître votre domaine sur le bout des doigts, vous vous passerez toujours trois heures sur des trucs à la con.

J’ai ai dépanné des systèmes qui bootaient pas. J’en ai fait des chroots. J’ai ai parametré des systèmes avec des configurations alambiquées pour pouvoir bien comprendre comment ça fonctionne. Mais ça m’a pas enpêché de me foutre des bâtons dans les roues à une étape sur deux de la résolution de ce problème :D.

Petit message à tous les nouveaux administrateurs systèmes en herbe. Si vous passez trois heure sur un truc tout con, c’est normal, Ça arrive même aux meilleurs ³. En fait, vous avez même l’avantage de bien analyser le problème et de ne pas sauter sur des conclusions hâtives qui vous feront perdre du temps. Courage :)

Bon, sur ce je vous laisse, je dois

Corriger mon grub.cfg
Rectifier le bordel que j’ai mis dans mon pacman.conf
Corriger le bordel des clefs de pacman
Tooter pour se marrer du fait que je suis allé loin pour un souci de ce genre
Écrire le toot sur un fichier parce qu’il commence à devenir long et si le navigateur crashe j’aimerais pas le réécrire
Tant qu’à faire, autant publier un article de blog
Oh wait

J’en suis pas totalement sûr, peut-être qu’un truc que j’ai fais durant ce debug a corrigé le problème sans que je m’en rende compte. ↩
C’est une application qui permet de faire croire à votre PC que votre téléphone est une clef USB. Vous pouvez vous en servir (entre autres) pour installer une distro avec son image d’installation, ça vous évite de la graver. ↩
Je parle pas de moi là, hein :D ↩

Configurer eduroam pour une connexion WPA-EAP TLS avec un certificat au format .p12

Tue, 23 Oct 2018 13:00:00 +0000

Si vous étudiez / travaillez dans une université il y a de grandes chances pour que celle-ci propose une connexion via le réseau Wi-Fi eduroam. Une fois connecté, à ce réseau avec les identifiants de votre université, vous pouvrez vous y connecter dans n’importe quelle université proposant aussi eduroam, ce qui est plutôt chouette.

Certaines universités vous proposent de vous connecter via un identifiant et un mot de passe d’autres vous proposent de vous connecter avec un certificat et une clef privée. C’est plus complexe à mettre en place, mais c’est plus safe et si vous changez de mot de passe (ce qu’il faut faire régulièrement) ça reste configuré sur tous vos appareils. Pour simplifier la configuration du système pour les utilisateurs, eduroam propose un outil appelé eduroamCAT qui configure la connexion pour vous.

Sauf que pour moi, que ce soit sur mon Arch avec wpa_supplicant ou sur mon téléphone Android, j’ai eu quelques difficultés à installer le certificat fourni par mon université, dans mon cas au format .p12. Voici ce que j’ai fais pour y remédier, si d’autres personnes sont dans le même cas.

Android

J’ai d’abord téléchargé sur le site de mon université le certificat avec l’extension .p12 donné avec un mot de passe pour le déchiffrer. En l’ouvrant simplement depuis mon gestionnaire de fichiers j’ai eu le droit à pleins de comportements indésirables de l’application censée l’installer : crashs, freezes, messages d’erreur…

C’est probablement lié à ma ROM, mais dans mon cas il faut simplement l’installer depuis les paramètres de sécurité du téléphone (Installer un certificat depuis la carte SD). Tapez le mot de passe pour le déchiffrer, donnez-lui un nom bidon et c’est bon.

Tant que vous êtes dans les paramètres, oubliez le réseau eduroam pour éviter les conflits.

Ensuite, je suis allé sur le site https://cat.eduroam.org pour télécharger le profil de mon université. Encore une fois, ouvrir le fichier directement ça fonctionne pas, donc j’ai dû l’ouvrir depuis l’application.

Après c’est assez buttersmooth, entrez votre identifiant (du type monidentifiant@monuniv.tld) et la config se fait automatiquement, il vous faut juste retourner dans les paramètres Wi-Fi pour choisir le bon certificat utilisateur puisque l’application ne peut pas le faire elle-même.

Si votre université propose un deuxième réseau Wi-Fi protegé aussi basé sur eduroam (dans mon cas monuniv-protected) il vous suffit de copier/coller les paramètres depuis le réseau eduroam puisque l’application ne le fait pas pour vous.

wpa_supplicant

Encore une fois téléchargez sur le site de votre université le certificat avec l’extension .p12 donné avec un mot de passe pour le déchiffrer.

Vous pouvez aller sur https://cat.eduroam.org pour télécharger un script Python avec la configuration integrée mais le script crashe si Network Manager n’est pas installé donc il faut le forcer à faire une config wpa_supplicant.

Voilà le messsage d’erreur si NetworkManager n’est pas installé (oui c’est principalement pour le référencement):

$ python ./eduroam-linux-PdM-UNIV.py
eduroam-linux-PdM-UNIV.py:149: DeprecationWarning: dist() and linux_distribution() functions are deprecated in Python 3.5
  system = platform.linux_distribution()
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/dbus/bus.py", line 175, in activate_name_owner
    return self.get_name_owner(bus_name)
  File "/usr/lib/python3.7/site-packages/dbus/bus.py", line 361, in get_name_owner
    's', (bus_name,), **keywords)
  File "/usr/lib/python3.7/site-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'org.freedesktop.NetworkManager': no such name

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "eduroam-linux-PdM-UNIV.py", line 995, in <module>
    run_installer()
  File "eduroam-linux-PdM-UNIV.py", line 197, in run_installer
    if config_tool.connect_to_nm() is None:
  File "eduroam-linux-PdM-UNIV.py", line 779, in connect_to_nm
    "/org/freedesktop/NetworkManagerSettings")
  File "/usr/lib/python3.7/site-packages/dbus/bus.py", line 241, in get_object
    follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python3.7/site-packages/dbus/proxies.py", line 248, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python3.7/site-packages/dbus/bus.py", line 180, in activate_name_owner
    self.start_service_by_name(bus_name)
  File "/usr/lib/python3.7/site-packages/dbus/bus.py", line 278, in start_service_by_name
    'su', (bus_name, flags)))
  File "/usr/lib/python3.7/site-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.NetworkManager was not provided by any .service files

Du coup voilà la modif à faire:

diff --git a/eduroam-linux-PdM-UNIV.py b/eduroam-linux-PdM-UNIV.corrected.py
index 576126b..3ad59f0 100644
--- a/eduroam-linux-PdM-UNIV.py
+++ b/eduroam-linux-PdM-UNIV.corrected.py
@@ -194,7 +194,7 @@ def run_installer():
     # test dbus connection
     if NM_AVAILABLE:
         config_tool = CatNMConfigTool()
-        if config_tool.connect_to_nm() is None:
+        if None is None:
             NM_AVAILABLE = False
     if not NM_AVAILABLE:
         # no dbus so ask if the user will want wpa_supplicant config

Lancez-le (python eduroam-linux-PdM-UNIV.py), entrez (dans le désordre) votre identifiant (du type monidentifiant@monuniv.tld), le chemin du certificat et son mot de passe de déchiffrement.

Une fois terminé, vous allez avoir des fichiers dans ~/.cat_installer. cat_installer.conf contient la configuration de votre réseau Wi-Fi que vous pouvez rajouter à votre fichier /etc/wpa_supplicant/wpa_supplicant.conf (ou autre, selon votre configuration). Cependant il va falloir remplacer un bon nombre de choses :

L’indentation est pétée
Il faut mettre le SSID entre guillemets
Il faut indiquer le chemin du certificat et la clef privée de l’utilisateur (et non, ils ne sont pas mis par le script), par exemple client_cert="/home/geoffrey/.cat_installer/cert.pem" et private_key="/home/geoffrey/.cat_installer/key.pem".
password= n’a rien à faire dans une connexion par certificat, il vous faut mettre private_key_passwd= à la place (vous pouvez utiliser un autre mot de passe, à partir de l’étape suivante on pourra se débarasser du mot de passe donné à la prochaine étape)
Dans mon cas pairwise=CCMP était pas suffiant, j’ai dû utiliser pairwise=CCMP TKIP
Dans mon cas j’ai dû corriger phase2= avec phase2="auth="

Il faut désormais créer les fichiers .pem referencés précédemment, à partir du fichier .p12. Un fichier user.p12 a été créé dans ~/.cat_installer mais il n’avait pas le même hash que fichier .p12 téléchargé donc j’ai préféré ne pas l’utiliser. Du coup :

openssl pkcs12 -in fichier.p12 -nokeys -out cert.pem
openssl pkcs12 -in fichier.p12 -nocerts -out key.pem

Pour les deux commandes, on vous demandera dans un premier temps le mot de passe fourni avec le fichier .p12 et pour la deuxième commande on vous demandera une clef PEM, utilisez ce que vous avez mis dans private_key_passwd= dans la conf.

Il vous faudra peut-être enlever ce qui n’est pas dans les -----BEGIN ...----- → -----END ...----- dans les fichiers générés.

Voilà, redémarrez wpa_supplicant et ça devrait fonctionner.

Accéder à un périphérique bloc à distance

Sun, 21 Oct 2018 14:00:00 +0000

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, et après un reboot malencontreux 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.

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 nbd selon la distribution). Modifiez ensuite le fichier /etc/nbd-server/config comme suit:

[generic]
    # Mettez en root ou changez les permissions de l'utilisateur `nbd` 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 NBD.

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 nbd-server pour ajouter au moins un filtrage IP.

Sur la machine qui va monter le périphérique, installez le paquet nbd-client (ou nbd 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 nbd-server

Vous devriez obtenir un message vous informant que vous avez créé le périphérique /dev/nbd0, 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
Le manuel de NBD
La seule occurence de NBD sur le wiki Arch

Un blog ? Pourquoi faire ?

Fri, 17 Jul 2015 17:54:00 +0000

Par où commencer ? Si vous ne me connaissez pas (ou peu), je vous propose de faire un tour sur la page “À propos”.

Donc voilà, j’ouvre un blog. Pourquoi ? Comme ça, j’ai envie. Qu’est-ce qu’il contiendra ? J’ai ma petite idée pour les deux ou trois premiers articles, mais en général ça parlera de tout et de rien. Majoritairement de mes centres d’interêt, à savoir la programmation. De toute manière, je ne compte pas simplement relayer les informations qui me paraissent intéressante. Pour cela, il y a mon compte Twitter, 140 caractères sont largement suffisants pour ce genre de choses. J’ai plus l’intention de créer du contenu original, ou semi-original, surtout si ce que je dit n’a pas ou peu été dit.

Je n’ai aucune envie de me forcer à mettre ce blog continuellement à jour, j’y posterais quand j’en aurais envie et parce que j’en ai eu l’envie. Donc un truc est sûr, je ne vous spammerais pas de posts. Vous pouvez dès maintenant vous inscrire à mon flux RSS, et l’oublier jusqu’à ce qu’à un post arrive ;-).

Je ne garantis pas non plus la véritabilité de ce que je dit, et vous suivez mes conseils à vos risque et perils. Ça m’arrivera sûrement de dire des bêtises, ou de faire des fautes, ou de vous dire que les touches Alt+F4 vous configure votre système automatiquement ; je n’ai pas envie de m’embêter avec ça.

Voilà ! On peut résumer tout simplement :

TL;DR Ceci est un blog écrit par un feignant qui a juste envie de l’ouvrir :-)