Journal Debian, installations automatiques et ARM

Posté par freem le 16 janvier 2019 à 23:27. Licence CC By‑SA.

Étiquettes :

jan.

2019

Sommaire

Installation réseau automatisée pour x86
- mauvais sujet, changer sujet
on cause d'ARM?
- ARM, boot standard
- ARM, boot réseau
Conclusion et purge du cerveau, à grands coups de traSH

Salut.

À la base, je ne suis qu'un développeur, mais comme «malheureusement» dans ma boîte je suis celui qui connaît le mieux le système (en tout cas ceux que l'on déploie: Debian avec kernel linux), je suis celui qui s'occupe en pratique de configurer et déployer les machines (je ne me considère pas comme un admin sys, par manque de compétences).

Installation réseau automatisée pour x86

Les premiers systèmes sur lesquels j'ai «officié» étaient basés sur des architectures x86, je me suis donc orienté vers un démarrage «diskless» PXE qui log automatiquement l'utilisateur root, qui a lui-même un .profile qui lance le formatage du «disque dur» et y installe un chroot via (c)debootstrap (en mode minimal, histoire que je puisse avoir la plus grosse maîtrise possible sur ce qui est effectivement installé: non, wamerican n'a aucun intérêt, par exemple…), chroot qui est ensuite utilisé pour installer la base de données et les divers logiciel nécessaire à mon taf (je laisserai cet aspect de côté, parce que ce que j'ai fait est sale. J'y gagnerais à nettoyer et surtout finir, mais pour ça, il me faudrait du temps… sigh).
Plutôt simple, dans le fond (enfin, quand on sait, y'a des trucs qui s'inventent pas), mais je vais rappeller ici ce qu'il est nécessaire de faire ou, en tout cas, comment moi j'ai fait:

installer et configurer un DHCPd (isc-dhcp-server pour moi, c'est le mieux documenté de ceux sous Debian) pour servir les requêtes DHCP/BOOTP (réseau physique différent du lan, parce que je n'ai pas encore trouvé le temps d'avoir le lan sous contrôle). Pas forcément le meilleur outil, mais au moins, trouver de la doc voire des exemples est relativement simple. À noter tout de même, selon les implémentations du client PXE, la machine qui doit servir le fichier à exécuter est déterminée de façon différente, mais je pense que c'est lié au fait que je n'avais pas spécifié à l'époque de routeur dans le DHCPd: en tout cas, les machines physiques utilisaient l'IP du DHCPd, alors que virtualbox nécessitait une URI complète. Je tiens aussi à mentionner l'option 'dynamic-bootp', ou un truc du genre;
installer et configurer un TFTPd (tftp-hpa pour moi), pour permettre le téléchargement par la cible d'un exécutable, ici un binaire de pxelinux. Outil super simple à utiliser, vraiment.
installer et configurer un bootloader (pxelinux… blabla), qui s'occupe de télécharger le noyau et l'initrd. La doc est un peu obtuse, notamment sur comment passer au noyau l'interface à utiliser si par malheur le système cible à plusieurs ports ethernet (et tant qu'à faire un PXE pour la 1ère fois, autant que ça ne soit pas dans la configuration la plus simple, pas vrai?) sans quoi ce dernier… freeze. Je remercie stack overflow sur ce coup, quelqu'un m'a filé une piste qui m'a permis de comprendre ce que je lisais dans la doc, plus spécificiquement, il est possible d'ajouter «BOOTIF=[MAC-ADDRESS]» afin que syslinux file la bonne interface au noyau (honnêtement, j'ai mis du temps avant de comprendre qu'il s'agit d'une option de syslinux et non du noyau… quoique, j'ai une doute? Je regarderai au taf demain au pire);
installer (c)debootstrap(-static) et l'utiliser pour créer un système complet;
configurer initramfs-tools dans le bootstrap afin de générer une image qui inclue les pilotes NFS, et probablement d'autres détails que j'ignore;
installer et configurer nfs-kernel-server afin de permettre l'accès par le réseau au bootstrap. Dans mon cas, j'ai mis l'accès en rw, j'aurai préféré ro, voire utiliser autre chose que NFS, peut-être TFTP ou SFTP ou SCP… surtout que je ne comprend pas quel daemon fait quoi dans NFS… mais bon, ça juste marche, et vu que c'est pour le taf, j'ai pas le choix de laisser des trucs moyennement maîtrisés tant qu'il n'y a pas une vraie raison de maîtriser (oui, ça me fait chier cette façon de faire)…
et bien sûr, créer un script qui partitionne automatiquement (sfdisk est bien pratique de ce point de vue), formate les partitions, crée les points de montages, les monte, invoque (c)debootstrap(-static), crée le fstab, initialise les mots de passe (merci à chpasswd sur ce coup) et mets en place les divers éléments nécessaires.

mauvais sujet, changer sujet

Bon, tout ça, c'est bien (ou pas, d'ailleurs, pour être franc c'est aussi une sorte de mea culpa pour mon manque de maîtrise), mais c'est pour des archis de type intel. Ça aidera peut-être quelques mollusques ici (j'en doute, mais, sait-on jamais?) mais ce n'était pas le sujet. J'ai bien précisé ARM dans le titre, après tout.
Hors, il s'avère que les machines ARM, ça ne boote pas comme nos bons (enfin, tant que le spectre de la sécurité ne nous hante pas quoi) vieux CPU intel, équipés de leurs bons vieux firmwares majoritairement fermés, quelques peu buggués (surtout depuis l'avènement de l'UEFI, d'ailleurs!).
De ce que j'ai compris (pour info, j'écris ceci le jour même ou j'ai finallement réussi à booter une beaglebone black via le réseau, je suis loin de maîtriser tout) le contenu d'une mémoire est chargé et exécuté. Comment et pourquoi, je n'en sais encore rien (mais j'ai l'intention d'apprendre pour un projet perso).
Ce qui est sûr, c'est que dans le cas des beaglebone black que j'ai au boulot, ça charge une version de «Das U-boot» vieille de 3 ans (au pifomètre), et que la «documentation» est franchement triste. Bien sûr, mes prédécesseurs ne maîtrisaient pas non plus le sujet, et ils ne sont de toute façon plus là… sinon s'pas drôle, pas vrai?
Trouver des articles de gens qui en parle est également difficile, et le peu que j'ai trouvé datent d'il y a plusieurs années. Le problème, c'est que le support d'ARM à été, comme tout bon bivalve le sait, considérablement remanié, et ces remaniements ont manifestement pas mal affecté le beaglebone black. Notamment, la configuration matérielle est à priori modifiable à l'exécution, peut-être est-ce lié à une sombre histoire de fermiers, je ne sais pas.

on cause d'ARM?

ARM, boot standard

Ce que je sais, c'est que j'ai dû dumper le contenu des variables, qui servent également de scripts, passer ce dump dans un script (fait maison, je n'ai pas connaissance d'outil fait pour) histoire de tranformer des one-liners de plusieurs dizaines d'instructions en un script lisible (30 lignes de shell, certes, mais c'est pénible quand même) qui ne liste que le code potentiellement appellé.
Par défaut, le contenu de la variable «bootcmd» est exécuté.
En pratique, on pourrait résumer ce script en ces quelques étapes (sur une BBB, hein):

configurer quelques connecteurs;
chercher comment accéder à la mémoire de masse;
reconfigurer les connecteurs;
chercher comment accéder à une autre mémoire de masse;
si pas de mémoire de masse trouvée, faire la gueule;
autrement charger un fichier de config (uEnv.txt) qui peut se trouver à divers endroits (sinon s'pas drôle, quoi);
éventuellement l'exécuter;
charger le noyal, l'initrd ET un fichier de config dtd qui, de ce que j'ai compris, permets de configurer les connecteurs (oui, ça fait potentiellement 3 fois qu'on les config, et si ça se trouve le système lui-même va les re-bidouiller…) en mémoire;
lancer le noyal avec en paramètres (passés par les registres du CPU à vue de nez) l'adresse de l'initrd et celle de la config hardware à utiliser;

ARM, boot réseau

Tout ça, c'est ce qui se fait en démarrage normal. Les docs (leS, parce que je parle a la fois de celle sur le site officielle, de celle à laquelle on peut accéder via help bla dans le prompt u-boot, et de celle dans le code-source) mentionnent une commande DHCP, qui, selon elles, permet de télécharger et d'exécuter un fichier.
Ne les croyez surtout pas!!! En pratique, la commande DHCP se contente de récupérer la configuration réseau et de charger en mémoire le fichier éventuellement indiqué par le serveur DHCP. Charger. Pas exécuter. Et non, il n'est pas possible de spécifier l'URI du fichier à télécharger depuis la carte ARM (ou, du moins, pas de cette façon).
Une fois la commande DHCP faite, nous avons donc récupéré une configuration IP, et chargé un fichier en mémoire. Il faut donc l'exécuter, et non, cela ne se fait pas forcément avec une commande nommée "bootmachinchose", on peut aussi utiliser la commande «source». Pourquoi pas, après tout, un binaire et un script sont 2 choses différentes, pas de souci ici.
Du coup, le but est de créer un fichier source. Un simple fichier texte qui contiendrait les instructions? Ah non, ça le fait pas: il faut créer un binaire via la commande mkimage. Ce binaire contiendra l'information de format, de compression, d'architecture probablement, et j'imagine d'autres trucs, mais pas trop, vue la taille du header…
Ce fichier pourrait, par exemple, utiliser la commande tftp (non, elle n'est pas dans la doc, je l'ai trouvée en lisant le code des scripts par défaut, et, oui, c'est built-in) afin de télécharger un fichier arbitraire à un emplacement mémoire arbitraire.
J'ai commencé par suivre plus ou moins bêtement un article de blog qui indiquait de ne télécharger que le fichier de config matérielle et le noyau. Grâce au fait d'avoir monté un PXE classique, j'ai été intrigué de l'absence explicite de l'initrd… à raison. Non, ça ne boote pas sans initrd ou, en tout cas, pas une Debian standard.
Il faut donc télécharger 3 fichiers: le noyau, l'initrd, et le dtb (config matérielle). Sauf que, ça ne boote toujours pas…
Pour une raison qui m'échappe, il faut, pour que ça démarre, passer l'initrd par la commande mkimage, sans quoi U-boot se mêle de ce qui ne le regarde pas (le format de l'initrd) et refuse de démarrer.

Tout ce bazard ne remplace que la configuration de pxelinux….

Conclusion et purge du cerveau, à grands coups de traSH

U-boot, je trouve ça sale.
La doc est à la fois incomplète et erronée, centrée sur un produit bien précis et donc tout sauf générique, les scripts exécutables sont dans des variables indiscernables des vraies variables, et j'ai du mal a avaler le fait d'avoir passé plus d'une semaine à comprendre comment ça marche en surface! Parce que non, je ne comprend toujours pas comment ça marche vraiment (alors que quand j'avais 15 ans, j'ai été capable de comprendre comment un BIOS bootait un kernel en quelques jours hein).
Comme je veux mettre à jour U-boot, par exemple pour qu'il soit capable de comprendre que non, je n'ai pas l'intention de n'avoir qu'un seul système viable sur la mémoire (double banque pour les MàJ) je sais que je vais encore en chier, et pas qu'un peu. Je vais sûrement finir par juste chainer les bootloaders…
Je peux aussi ajouter le fait que le chemin d'exécution originel, qui est la faute de Texas Instruments, pèse plus de 400 lignes alors que moins de 10 sont vraiment nécessaires (bon, je peux comprendre ça, et puis, ça reste super rapide) mais surtout le fait de faire des one-liners! Je ne sais pas si c'est à cause de Das U-boot ou de TI, mais c'est vraiment super moche. Le langage lui-même semble encourager le «code d'aviateurs» avec de looooooooongues ailes constituée de cascades de IFs.
Bref, c'est libre donc c'est génial, mais ça reste moche techniquement, selon moi. Mais je n'ai probablement pas tout compris…

PS: désolé pour le formatage

# Installation automatisée

Posté par Dafyd le 17 janvier 2019 à 07:49. Évalué à 8.

Salut,

Pour des installations PXE automatisées je te conseille kickstart. C'est une techno RedHat, mais c'était supporté par Debian et Ubuntu, la dernière fois que j'ai regardé. Ça marche relativement bien (bien qu'un peu rigide). J'utilise ça au taf pour déployer des postes clients, c'est rapide et efficace, et les postes sont tous les mêmes, sans doute possible.
- [^] # Re: Installation automatisée
  
  Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 17 janvier 2019 à 08:40. Évalué à 5. Dernière modification le 17 janvier 2019 à 08:40.
  
  Dans le même genre pour ceux que ça intéresserait je ne maitrise pas le 10ème des connaissances explicités dans l'article. Mais en quelques minutes avec ltsp et un collègue on a pu déployer des salles mixtes x86 et arm. Bon la config réseau était visiblement beaucoup plus simple.
  
  « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
  - [^] # Re: Installation automatisée
    
    Posté par freem le 18 janvier 2019 à 02:25. Évalué à 3.
    
    Bon la config réseau était visiblement beaucoup plus simple.
    
    Je ne pense pas… elle n'est pas super complexe de mon côté (il y a juste le problème que le but soit de déployer sans connaître l'adresse MAC d'une part, et d'autre part que certaines aient plusieurs interfaces réseau), par contre, les machines sont installées pour être déployées ailleurs, parfois en connexion directe, donc j'ai vraiment besoin d'installer sur un disque. Et si possible, sans intervention manuelle autre que préciser quelques identifiants que je ne peux pas récupérer directement depuis le hardware.
    
    Je fais juste un retour de mon (manque) d'expérience, il y a sûrement des solutions qui m'auraient fait gagner un temps important (je regarderais d'ailleurs).
- [^] # Re: Installation automatisée
  
  Posté par ted (site web personnel) le 17 janvier 2019 à 09:54. Évalué à 4.
  
  Je me suis aussi demandé pourquoi il fait comme ça. Pour Debian, il y a preseed qui devrait pouvoir faire ça: c'est un fichier à fournir à l'installeur pour automatiser l'installation. Enfin, j'ai jamais testé moi-même, donc il y a peut être des fonctions qui lui manquent, comme pour l'installation de certains logiciels hors dépôts.
  Merci pour ce journal
  
  Un LUG en Lorraine : https://enunclic-cappel.fr
  - [^] # Re: Installation automatisée
    
    Posté par claudex le 17 janvier 2019 à 10:07. Évalué à 6.
    
    On peut inclure un script bash dans le preseed (ou lui faire télécharger, c'est quand même plus pratique). Donc, on n'est assez peu limité.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Installation automatisée
    
    Posté par freem le 18 janvier 2019 à 02:20. Évalué à 2.
    Pour ce qui est de preseed, il y a 2 problèmes:
    - déjà, je me souviens du nombre de questions posées à ce sujet sur la m.l. debian, quand j'y étais abonné, et des réponses: ça à l'air super compliqué, pour pas grand chose;
    - c'est conçu pour fonctionner avec le CD d'installation. Il faut donc plus d'interventions manuelles que la solution que j'ai utilisée. Sans parler du fait que l'installateur Debian outre un tas de bloat inutile se base sur debconf pour preseed, et de ce que j'ai vu, c'est vraiment pénible pour pas grand chose.
# Il faut l'apprivoiser

Posté par a-wai (site web personnel) le 17 janvier 2019 à 11:07. Évalué à 10. Dernière modification le 17 janvier 2019 à 11:08.

Comme pour tous les outils, il y a de l'apprentissage…

Déjà, il faut bien comprendre que U-boot vient du monde de l'embarqué, avec toutes les casseroles que ça implique, et du coup, pas le choix, il faut "s'y mettre".
Concernant le process de boot par exemple, on est sur des processeurs qui n'accèdent qu'à une toute petite RAM directement intégrée au SoC, la SRAM (quelques dizaines de ko tout au plus), bien trop petite pour faire plus qu'une initialisation basique. Donc une version minimale d'U-boot y est chargée pour initialiser la RAM et pouvoir y mettre le U-boot complet (SPL), qui va ensuite initialiser les périphériques internes (notamment réseau et stockage) pour pouvoir charger (commandes tftp, mmc read, fatload etc…) et booter le noyau (bootm ou booti).
Et encore, sur ARM64 par exemple, c'est pire, il y a ARM Trusted Firmware au milieu de tout ça…

Ceci dit, je suppose que tu utilises une version ancienne et/ou sans en personnaliser la configuration. U-boot, c'est comme le kernel : si tu as un besoin spécifique, make menuconfig est ton meilleur ami.

En l'occurrence, tu n'as sans doute pas vu qu'une commande pxe existait, ce qui t'aurait surement fait gagner du temps.
De même, packager ton kernel dans un format uImage contenant kernel + initrd (ou kenel + dtb, je ne me rappelle plus) est une bonne idée, voire même, avec une version raisonnablement récente, une fitImage contenant kernel + initrd + dtb. Moins de fichiers à gérer, des scripts plus digestes, etc…

surtout le fait de faire des one-liners

C'est une question de formatage : les scripts sont stockés dans des variables d'environnement, et une variable ne peut contenir qu'une ligne de texte. Quand on fait les choses bien, on découpe son script en plusieurs variables (des "fonctions" en quelques sortes) qu'on va appeler via run, mais je te l'accorde, ça demande un peu de pratique pour être à l'aise avec ça.

Concernant la documentation, tu as un répertoire doc dans les sources qui, a l'instar du kernel, contient énormément d'infos utiles. Et s'il te manque une info, tu la trouveras dans le code lui-même, qui est raisonnablement bien rangé (le répertoire cmd en particulier est d'une aide précieuse, puisqu'il contient le code de toutes les commandes du shell).

PS: Pour la suite, tu peux aller regarder cet article qui parle de la problématique des MàJ avec système de fallback sous U-boot
# Déraisonnable

Posté par lfr2m le 17 janvier 2019 à 11:20. Évalué à -4.

J'ai du mal à comprendre ton problème… Je le crois bien, comme tu le dis que tu ne maîtrises pas le sujet, ça en devient de la mauvaise foi!

Y'a pas plus simple et configurable que Das U-boot pour faire un simple boot réseau en TFTP/SMB de pleins de façons différentes: utilisation d'un script, embarqué en dur, configurable via le server DHCP, etc. C'est sûr que si tu t'attaques directement à pxelinux direct sans maitriser le plus simple, tu vas galérer. Mais ça se fait bien une fois que tu maîtrises le plus simple.
Une adaptation d'U-boot ne me prend pas plus de 8heures validation complète sur un nouveau produit avec boot réseau (eth, usb) ou stockage embarqué (selon le mode ou l'état du produit), flash en sortie de prod, multiboot, intégration dans yocto : passer plus de temps que ça ne montre qu'un manque de maîtrise du bootloader.

Sur une BeagleBone Black, U-boot d'il y a 3 ans fonctionne aussi bien que celui d'aujourd'hui: il y a eu des évolutions du driver model et de l'intégration (et validation totale) d'autres fonctionnalités (falcon, dtb). Ils ont une démarche d'amélioration continue et celà s'interface de mieux en mieux avec Linux.
Il y a le multiboot, le DFU, le falcon mode, le secure boot…

Il y a une directory 'doc' dans le code source d'U-boot!
De plus, tu trouves de la doc en pagaille sur le net sur le sujet: wiki de TI, forum de TI, forums de NXP, Linaro, blogs en anglais, excellentes formations en France par pléthore de boîtes (pas de billes dans la société, mais tu as Bootlin par exemple), des présentations comme celle de konsulko, des présentations de conférences (linuxcon, etc.) sans oublier la lecture des docs de DHCP, samba et de TFTP, pxelinux…
C'est sûr que les docs en langue française ne valent pas le détour bien au contraire(sic)

L'environnement offert par TI est fait pour l'ensemble de leurs cartes d'éval alors c'est sûr que c'est très cryptique au début mais souvent dans les formations, on simplifie la commande de boot et l'autoconfiguration des scripts pour régler les variables d'environment: ils ont même fait l'effort d'intégrer le DFU, le pxelinux… Et comme ça gère plein de manières de booter, on peut essayer de comprendre comment ils ont fait justement pour récupérer des images différentes selon la plateforme, le produit, la configuration du produit, etc.

mender.io, NXP, utilisent Das U-boot…
=> T'as passé un temps colossal pour troller un des meilleurs bootloaders du marché pour l'ARM juste parce que, comme tu le dis, tu ne maîtrises pas le sujet: ça en devient tellement pathétique que j'ai pas envie de donner du temps qui ne me sera pas payé…
- [^] # Re: Déraisonnable
  
  Posté par freem le 18 janvier 2019 à 02:41. Évalué à 6. Dernière modification le 18 janvier 2019 à 02:41.
  tu le dis que tu ne maîtrises pas le sujet, ça en devient de la mauvaise foi!
  
  On m'aurait menti, quand on m'a dis que la mauvaise foi consiste à ne pas admettre ses erreurs et faiblesses?
  
  excellentes formations
  
  Je me demande: le temps de chercher, puis de prendre une formation, et enfin d'accomplir la tâche, ça m'aurait pris combien de temps? Ah, j'ai oublié le temps de convaincre le patron…
  
  Quant à la doc, on va faire court, j'ai pris celle qui semble être celle du site officiel. Si on prend par exemple la section sur bootp on à ceci:
```
=> help bootp
bootp - boot image via network using BOOTP/TFTP protocol

Usage:
bootp [loadAddress] [[hostIPaddr:]bootfilename]
=>
```
  Superbe doc en effet.
  Même sans le site officiel, taper help permets de trouver cette commande, puis help bootp d'accéder au même texte.
  Problème: spécifier l'IP hôte ou le nom de fichier dans le cas que j'ai eu n'avait strictement aucun effet. J'ai aussi été lire le source, et non, je n'ai pas pris assez de temps pour tirer toute la pelote, j'ai préféré zapper et mettre en forme un dump de l'environnement, réduire le boot au strict minimum qui marche, regarder le code fournit puis l'adapter.
  Ce code utilise une commande qui n'est nulle part dans la doc.
  
  Je ne sais pas ce que valent les autres, et c'est possible que U-boot soit le meilleure. De toute façon, je n'ai pas le choix de l'utiliser, je ne suis pas assez idiot pour essayer de remplacer un élément critique d'un matériel que je ne maîtrise pas, et cela implique de ne pas non plus le remplacer par une version compilée moi-même: ce serait la meilleure façon de briquer les systèmes.
  
  Pour le reste, tu peux me qualifier de troll si tu veux. Je me suis contenté de dire ce que j'ai fait, parce qu'il fallait que le boulot soit fait d'une manière ou d'une autre, et que c'est celle qui m'a permis d'avoir des résultats, la ou la méthode "lire la doc" ne me menait nulle part.
# Beaucoup de NIH ici

Posté par benoar le 17 janvier 2019 à 16:40. Évalué à 5. Dernière modification le 17 janvier 2019 à 16:40.
comment moi j'ai fait:
- installer et configurer un bootloader
- installer (c)debootstrap(-static)
- configurer initramfs-tools
- et bien sûr, créer un script qui partitionne automatiquement […]

Heu… tu viens de réinventer le debian installer https://www.debian.org/devel/debian-installer/.
- installer et configurer un DHCPd
- installer et configurer un TFTPd
Moi je fais ça avec dnsmasq, tout en un, beaucoup moins prise de tête : cf. https://openwrt.org/inbox/howto/netboot par exemple.

U-boot, je trouve ça sale.

Oui, ça a été fait par des gens qui ont en gros la même mentalité que ceux qui ont fait l'UEFI, je trouve. C'est surtout des hardeux à la base, et je pense que vu que leur objectif est de se différencier des concurrents, ils ne peuvent pas intégrer dans leur cerveau le principe d'universalité du logiciel. Bon, UEFI uniformise, mais le côté « fait le café » est similaire.

Je te raconte même pas le jour où j'ai testé le netboot UEFI en IPv6 : je devrais écrire un journal, tiens.
- [^] # Re: Beaucoup de NIH ici
  
  Posté par benoar le 17 janvier 2019 à 16:54. Évalué à 5.
  
  Heu… tu viens de réinventer le debian installer https://www.debian.org/devel/debian-installer/.
  
  Et pour avoir un setup prêt à utiliser avec du netboot, il y a même des paquets tout prêts :
  https://packages.debian.org/search?keywords=debian-installer-9-netboot
  - [^] # Re: Beaucoup de NIH ici
    
    Posté par freem le 18 janvier 2019 à 04:12. Évalué à 7.
    Juste par curiosité: comment installer un paquet qui n'a pour seule dépendance une suggestion (pas même un recommend qui eusse été installé automatiquement…) sur le serveur TFTP à employer pourrait-il déployer la totalité de la pile nécessaire à une installation réseau?
    
    Réponse: impossible. Du coup, ça n'adresse potentiellement que la partie installation générique d'un système composé uniquement de paquets Debian.
    En bref, ça addresse la partie triviale du problème, en la rendant potentiellement plus complexe, et en impliquant qu'il faille apprendre à utiliser un outil qui ne peut servir que dans le cas d'une installation, d'un système dérivé de Debian.
    C'est sûrement très bien pour les gens qui installent des postes utilisateurs de cette façon… mes systèmes n'ont pas vocation à avoir un clavier branché (sauf situation d'urgence).
    
    Mes scripts (237 lignes de moins de 80 caractères, espacées et commentées) sont compréhensibles, débogables et correctibles sans apprentissage par n'importe qui capable de lire du bourne shell, prévus pour générer une installation de fallback (au cas ou une MàJ future pète le système, pas encore implémenté, mais ça devrait prendre moins de 10 lignes, ainsi que le temps pour vérifier que tout marche comme prévu), configurent la liaison GPRS et autres paramètres (des applications métiers notament), et choisissent runit plutôt que systemd (ce qui est peut-être un défaut, admettons), privilégient syslinux à grub2 (plus prévisible, réutilise l'outil utilisé pour le PXE de toute façon, et pas besoin d'une partition d'1M réservée pour un bootloader, sachant que syslinux n'est pas une option de D-I à ma connaissance).
    Les adapter à un hypothétique autre système nécessiterait de changer à peu près 4 passages qui sont spécifiques à Debian et ses filles (en plus des listes de paquets à installer bien entendu):
    - la ligne qui (de)bootstrap;
    - les 8 lignes qui préconfigurent la console et le clavier (via debconf-set-selections, ça a un intérêt limité, j'aurai pu faire plus simple en faisant autrement, et avec le D-I j'aurai du les laisser de toute façon);
    - la ligne qui fait dans le chroot apt-get update (pour générer la liste des paquets à installer);
    - la ligne qui dans le chroot installe les paquets «utiles», que je pourrais fusionner avec deboostrap, mais j'ai séparé ça pour justement rendre le rôle de chaque script clair (il sont numérotés par ordre d'exécution, avec un nom qui indique l'étape;
- [^] # Re: Beaucoup de NIH ici
  
  Posté par bubar🦥 (Mastodon) le 17 janvier 2019 à 18:13. Évalué à 7. Dernière modification le 17 janvier 2019 à 18:35.
  
  Heu… tu viens de réinventer le debian installer
  
  Et c'est remarquable.
  Si l'aspect 'sale' décrit est la réaction bien normale, avoir trouvé un chemin pour arriver au résultat voulu (et en plus en détournant pe certains usages ou outils) n'est ce pas beau ? Si, non ?
- [^] # Re: Beaucoup de NIH ici
  
  Posté par freem le 18 janvier 2019 à 03:44. Évalué à 4.
  
  Heu… tu viens de réinventer le debian installer https://www.debian.org/devel/debian-installer/.
  
  Un collègue avait essayé plusieurs jours de faire fonctionner D-I pour ça, sans succès (pour la partie x86, faite il y a 8 mois). J'ai aussi énormément de souvenirs de lectures sur la mailing list de debian, au sujet de la comlexité de la chose.
  
  Dans mon cas, générer une installation à partir d'un script ne m'a posé aucun problème technique: le seul truc qui m'ai posé des problèmes, c'est comprendre comment U-boot fonctionne (pour l'ARM). Trouver le point d'entrée de U-boot n'est pas simple, et l'information (présente dans la doc, pour le coup. Celle-ci y est.) ne saute pas au yeux.
  Pour l'x86, si ma mémoire ne me trompe pas, j'avais réussi aisément à booter une machine virtualbox via PXE (pxelinux a une doc correcte), par contre, le fait est que la majorité des informations trouvables ne concernent que des machines avec un seul port ethernet m'a fait tomber sur le fait qu'il faut spécifier au kernel lequelle utiliser quand il y en a plusieurs. Non, la doc à ce sujet ne saute pas aux yeux (surtout quand on ne connaît pas le sujet, et que l'on n'imagine pas que ça puisse être le problème). Je mets de côté le fait d'avoir des comportements différents entre machines virtuelles, machines physiques, BIOS et UEFIs (etttt je n'ai pas touché IPv6 :)).
  Et des informations qui ne sautent pas aux yeux à tête reposée sautent encore moins aux yeux quand il faut aller vite.
  
  Moi je fais ça avec dnsmasq, tout en un, beaucoup moins prise de tête : cf. https://openwrt.org/inbox/howto/netboot par exemple.
  
  Je regarderais.
  Pour être honnête, le choix s'est fait plus ou moins par défaut: isc-dhcp est l'outil pour lequel j'ai trouvé la doc en premier, tout simplement. Il fait le boulot, la doc est exhaustive, le nom indique ce qu'il fait et il ne fait à priori qu'une seule chose (moins de risque qu'un truc que je maîtrise pas me pète au nez), je suis parti avec. Mais en effet, ce n'est peut-être pas le plus simple.
  
  Beaucoup de NIH ici
  
  Ne maîtrisant pas le sujet, je ne connais pas les outils habituellement utilisés. Enfin, je connaissais les termes «PXE», «DHCP», «diskless», «preseed» depuis quelques années, mais sans plus.
  Dans ce genre de cas, il arrive que trouver les outils les plus simples avec une doc claire (fr ou en, peu importe) et pas obsolète soit plus long que partir sur une solution plus bas niveau mais que l'on sait comment faire (ayant déjà joué avec debootstrap et dpkg bien avant, pour installer ou réparer (à partir d')un système de secours sur une partition d'un disque booté, sans périphérique externe pour simplifier… et puis, sérieux, la tétrachiées de questions posées par le D-I pour avoir un shell de secours, c'est ridicule. Quant on veul un shell pour réparer, est-ce vraiment vital de spécifier le pays ou l'on est?).
  
  Donc, je dirais que oui, il y a NIH pour l'installation, parce que j'ai fait un script qui en moins de 200 lignes de shell facile à déboguer installe un système propre sur une partition cible sans forcer les gens à lire un pavé de doc pour un installateur qui ne semble pas franchement conçu pour être automatisé (je suis sûr qu'en fouillant un peu, je pourrais même trouver une citation à ce sujet, sur le preseed…).
  Accessoirement, intégrer les soft qu'on fait selon la rache est plus simple avec un script qu'avec un installateur qui attendra forcément des paquets, donc un reprepro et un serveur http/ftp déployé quelque part, et de préférence sécurisé (je parle ici d'un serveur créé et déployé par des étudiants non encadrés, dans l'urgence, ainsi que d'un système «embarqué» implémenté et déployé de la même manière, le tout pendant 3 ans. Le serveur est lancé manuellement, via screen, pour info.), ce qui implique l'usage de signatures électroniques (oui, j'ai regardé, c'est un truc que j'ai bien l'intention de faire, mais j'ai d'autres choses à faire avant).
  
  Pour le boot réseau, c'est juste de la démerde, faite avec les connaissances du bord, et, oui, en l'occurrence elles étaient limitées, tout comme le temps que j'ai à disposition pour avoir un truc qui marche. C'est pour le boulot, pas un projet de stage ou de fin d'études, ni même un trip perso. Et il y a encore 20 000 trucs à automatiser.
  
  D'un autre côté, le fait que j'aie certainement fait de mauvais choix, et le dire ici, ça permets à ceux qui connaissent les bons choix de les indiquer, ce qui m'aidera pour la prochaine fois, et peut-être d'autres. Informations qui arriveront donc parce que j'ai parlé de mon "NIH".
  
  Je me demande d'ailleurs comment j'aurai pu faire pour avoir rapidement un truc qui marche et qui installe les applications maison (qui ne sont pas empaquetées proprement, parce que l'année 2018 à été sous le signe de l'urgence, dans une boîte qui a 0 infra, dont les seuls informaticiens avant moi étaient stagiaires ou alternants, partis depuis).
  Sachant que l'installation elle-même fut la partie la plus simple.
  
  Je te raconte même pas le jour où j'ai testé le netboot UEFI en IPv6 : je devrais écrire un journal, tiens.
  
  Excellente idée, ça serait informatif, et ça changerait des journaux sur la politique ou pour savoir quelles blagues sont acceptables sur des projets internationaux.
  - [^] # Re: Beaucoup de NIH ici
    
    Posté par Samuel (site web personnel) le 18 janvier 2019 à 11:08. Évalué à 1.
    
    Moi je fais ça avec dnsmasq, tout en un, beaucoup moins prise de tête : cf. https://openwrt.org/inbox/howto/netboot par exemple.
    
    Je regarderais.
    
    Un des avantages de dnsmasq c'est qu'il peut se contenter de faire la partie "PXE" de DHCP : sur un réseau existant (avec un DHCP déjà en place responsable de la configuration du réseau), il envoie les options PxE dès qu'un client demande une configuration IP (le client reçoit donc la configuration IP depuis le serveur DHCP principal + la configuration PxE depuis dnsmasq).
    
    Cette solution règle donc une partie de un problème que tu listais : "(réseau physique différent du lan, parce que je n'ai pas encore trouvé le temps d'avoir le lan sous contrôle)".
    
    Après, tu n'as peut-être pas envie de "polluer" ton réseau lan avec des options PXE pour des postes clients qui seraient configurés par défaut pour démarrer sur le réseau alors qu'ils ne devraient pas.
    - [^] # Re: Beaucoup de NIH ici
      
      Posté par benoar le 18 janvier 2019 à 11:45. Évalué à 2. Dernière modification le 18 janvier 2019 à 11:45.
      
      Dans le lien indiqué il y a même mieux (c'est moi qui l'ait écrite, il y a un bail maintenant) : tu ne répond en BOOTP/DHCP que aux clients qui sont des firmware PXE ; ils ajoutent une info que tu peux détecter dans la requête. Ainsi, avoir les deux DHCP en parallèle est « invisible ». Et pour peaufiner le tout, il n'envoit pas l'option qui indique de mettre le DHCP en route par défaut : ainsi, pas de « risque » de se retrouver avec un réseau qui ne répond pas, tu aurais tout de suite une erreur car il n'y a pas de route par défaut. Et pour le debian-installer qui est si bien fait, il ne le sélectionnera même pas car (de mémoire) il vérifie si le DHCP offre bien une route par défaut et passe au suivant si ça n'est pas le cas.
      - [^] # Re: Beaucoup de NIH ici
        
        Posté par freem le 19 janvier 2019 à 16:36. Évalué à 2.
        
        tu ne répond en BOOTP/DHCP que aux clients qui sont des firmware PXE
        
        En somme, c'est un DHCP secondaire. Personnellement, j'ai un problème majeur: le routeur que l'on utilise, quand on change la config DHCP, il faut le rebooter. Il n'a pas non plus de telnetd/sshd/whatever. En gros, c'est un routeur pour particuliers, et j'ai aucune maîtrise dessus (enfin, j'ai accès à l'IHM web… mouarf).
        
        Mon idée à long terme, c'est de séparer le LAN en plusieurs VLAN, selon les services, affecter à tout ça un routeur que je puisse configurer à ma guise (ou celle de quelqu'un qui s'y connaît mieux, ça m'arrangerait), qui routerait les requêtes vers l'une de nos deux *box en fonction de divers paramètres. À partir de là, je pourrais être confiant de pas tout casser à la mondre modif DHCP, mais il me reste une longue route à parcourir, et pas mal de connaissances à amasser… la seule chose certaine, c'est qu'ici vu que tout est à faire, je peux choisir de n'utiliser que des soft libres :)
    - [^] # Re: Beaucoup de NIH ici
      
      Posté par freem le 19 janvier 2019 à 16:25. Évalué à 2.
      
      Un des avantages de dnsmasq c'est qu'il peut se contenter de faire la partie "PXE" de DHCP : sur un réseau existant (avec un DHCP déjà en place responsable de la configuration du réseau), il envoie les options PxE dès qu'un client demande une configuration IP (le client reçoit donc la configuration IP depuis le serveur DHCP principal + la configuration PxE depuis dnsmasq).
      
      isc-dhcp-server peut étagalement le faire, mais il faut pour ça que le DHCPd principal soit configuré pour ça (next-server). Par contre, je ne sais pas s'il est possible d'identifier une requête DHCP/BOOTP pour PXE d'une requête DHCP classique?
      Ceci dit, dans ma boîte, le DHCPd principal, c'est un routeur pour particulier… J'ai beau avoir retravaillé un peu le bordel ambiant, ce n'est pas simple de migrer d'un environnement sale à un propre sans interrompre le service (je suis pas le seul à bosser et le réseau est un élément important) surtout que mes connaissances sont juste celles d'un dev un peu système, pas celles d'un admin réseau.
      
      Après, tu n'as peut-être pas envie de "polluer" ton réseau lan avec des options PXE pour des postes clients qui seraient configurés par défaut pour démarrer sur le réseau alors qu'ils ne devraient pas.
      
      Je suis surtout méfiant envers mes capacités… je sais par expérience qu'il en faut peu pour faire basculer un truc qui marche sans qu'on sache pourquoi à un truc qui ne marche plus du tout. Je pense que je vais finir par vraiment couper le réseau en 2 réseaux physiques, et migrer progressivement les postes sur un sous réseau mieux maîtrisé…
      Ceci dit, avec un DHCPd proprement configuré, j'ai cru comprendre que les requêtes PXE peuvent être transmises automatiquement à un DHCP secondaire spécialisé. On peut affecter (et c'est ce que j'ai fait, même alors qu'il est isolé) des classes d'adresses MAC (dont une partie est un identifiant de constructeur, et il y a même une partie réservée aux machines virtuelles apparemment!) à une zone dynamique (pardon pour le manque de vocabulaire technique), zones qui peuvent avoir des options différentes, notamment celle d'indiquer un fichier à télécharger.
      D'un autre côté, je suppose que tant que les machines de bureau ne sont pas configurées pour démarrer en PXE, ça ne poserais même pas de problème en pratique. Jusqu'au jour ou… bien sûr.
      Ce qui implique donc qu'il faille que les machines connectables (cartes réseau et PC) passent dans les mains d'un admin pour vérifier qu'il n'y a pas de problème.
# le logiciel est ton ami

Posté par bubar🦥 (Mastodon) le 17 janvier 2019 à 17:50. Évalué à 6. Dernière modification le 17 janvier 2019 à 17:51.

il y a bien longtemps dans une galaxie lointaine, très lointaine, la guerre civile fait rage entre l'Empire galactique et l'Alliance Rebelle. Au péril de leurs vies les Rebelles écrivirent iPXE et Etherboot afin de s'affranchir des ~~bugs~~ features de mauvaises implémentations de pxe sur les simples ordinateurs du peuple. L'Empire contre-attaqua et détruisis rom-o-matic.net. La Rébellion se réfugiât ipxe.org et repris les travaux dont l'ancien maître bootp la voie avait tracé.

Rejoins la force jeune padawan.

(il semble bien que arm soit de la partie, mais jamais testé personnellement, par contre ai utilisé souvent cette solution pour outrepasser les bugs divers et variés de différents constructeurs et modèles de matériels dans leur implémentation de la complète pxe, ai même vu des cartes rzo intel avoir *juste* le tftp buggé, mais c'était il y a bien longtemps.)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.