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.
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 freem . En réponse au journal Debian, installations automatiques et ARM. Évalué à 4.
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.
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.
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.
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.