freem a écrit 5059 commentaires

il est même administrable en Web ce qui peut sembler bien, mais moi je trouve que ça fait une interface en trop à surveiller.

Tiens, je n'avais jamais fait attention à son existence, merci, ça pourrait être utile. Et pour commencer, ça va se rendre utile par un touch /etc/apt-cacher-ng/userinfo.html pour désactiver ça… en tout cas, ça à l'air de désactiver le frontal web de conf, je vais creuser un peu plus le sujet quand j'aurais le temps.

j'ai déjà eu des problèmes de cache corrompu pour une raison inconnue (plusieurs fois),

Raison inconnue, ça veut bien dire que tu n'es pas sûr que le problème ne viens pas du système de fichiers ou d'un autre processus?

Je pensais que inetd était un vieux truc

Dans mon cas, je me serais arrêté la, en gros, mais je n'y connais rien.
Si je ne me trompe pas (peu probable, mais les trucs que j'en ai lu jusqu'ici se résument à peu près à dire "superserveur", rien que ça), inetd est un outil pour économiser les ressources: il lance et éteins des daemons selon la demande.
Du coup, autant j'en vois l'intérêt dans un environnement ou il faut pouvoir redémarrer très vite le système (exposé à des milliers d'utilisateurs énervés d'attendre 10s de plus), mais est-ce maintenant vraiment le plus long de nos jours, de charger le daemon depuis le disque dur (voire le cache de l'OS)? Est-ce si coûteux de garder le processus en mémoire (en supposant qu'il soit capable de se nettoyer de lui-même lors de la fermeture d'une connexion, bien sûr) ou en swap?
Même en imaginant un environnement ou il y a un grand besoin de performances, je trouve que l'idée fait double emploi avec le cache de l'OS, au fond?

Du coup, il sert a quoi, inetd?

On voit bien que les terminaux graphiques ont des valeurs sensiblement autour de 2.0secs, mais le tty est vraiment à la ramasse sous linux.
Est ce qu'il y a des raisons à ça ?

J'étais intrigué, donc j'ai fait un test, plus simple, en bash: time for i in $(seq 1 10000); do printf "%d" $i;done.
Le résultat est environ de 1.84s sur un TTY, sur 5 essais.
Sur urxvt, je suis à environ 0.19s, l'écart est d'un ordre de grandeur de x10.
Sur TTY via ssh, les résultats changent pas mal, mais en moyenne et à vue de nez, dans les 0.25s.
Sur urxvt, via ssh, dans les 0.35s.

À vue de nez, le TTY est en moyenne et à la louche 10x plus lents que les autres solutions.
Le temps mis par les sessions ssh fluctue énormément, ce que j'aurai envie d'associer au réseau et autres usages CPU ponctuels (le chiffrement, ça doit se sentir, il aurait fallu tester telnet, screen ou tmux pour enlever des causes d'interférences), mais sont proches, tout en étant légèrement plus lents que le test sous urxvt seul.

À vue de nez, pour moi, la constante ici c'est: /dev/ttyXX vs /dev/pts/XX. Je m'avance, mais je suppose que /dev/ttyXX accède à l'écran de manière brute, sans cache, en mode caractère, tandis que /dev/pts/XX doit ajouter un cache, qui doit augmenter les performances drastiquement (parce qu'envoyer 10 blocs de 5 octets est plus lents qu'envoyer un seul bloc de 50 octets, moins d'appels systèmes, notamment).

Bon, théorie à confirmer, hein, je n'ai pas fait de vrais bench, y'a pleins d'applications qui tournent sur cette machine et qui parasitent, je n'ai pas non plus fait assez d'essais loggués pour extraire des résultats vraiment précis et surtout, je n'ai pas cherché à caler un petit gperftools derrière tout ça :)

Pour le fun, le même truc codé en C:
* tty, sans SSH: ~0.95s
* tty, via SSH: ~0.005s
* urxvt, sans SSH: ~0.004s
* urxvt, via SSH: ~0.005s

Le ratio change radicalement de catégorie ici (x200?) et l'impact de SSH est négligeable (en fait, je pense que la commande time n'est pas assez précise, il faudrait que j'augmente le nombre d'itérations…).
J'ai envie de dire que ça conforte mon idée: dans le cas des terminaux virtuels, il est probable que les données ne soient envoyées à l'écran qu'avec une certaine fréquence, contrairement au TTY qui doit envoyer dès que la donnée est disponible.

Mais c'est amusant de voir l'écart de performances entre PTS et TTY du coup… je pense que je vais me bricoler un petit bout de code pour coller direct mes shells TTY dans des PTS du coup.

PS: désolé de pas pouvoir aider plus sur la question…

Admettons que tu ne t'aperçoive du problème qu'après avoir distribué ton binaire à 1000 machines au travers de, disons, juste 3 pays de la taille de la France.
Tu as alors fait chauffer la totalité de l'infrastructure, et tu dois de toute façon faire tes tests à postériori, sans parler de réémettre. Donc, à mon humble avis, le gain est à la fois au niveau de la réputation (système plus fiable), du temps humain (moins de tests manuels), et de l'énergie (moins de transfert de données).

C'est vrai, et surtout, les softs pour leur système ont une compatibilité ascendante qui peut dépasser les 20 ans, sans recompilation. Ça n'empêche, winfile, c'est une application finale, pas une lib, donc la nécessité d'être carré est «moins importante».
Et ça date de leurs débuts dans le monde des OS graphiques, ils auraient pu avoir du code plus cavalier.

Est-il vraiment souhaitable de faire la même chose qu'Electron.JS (j'ai toujours envie de virer la moitié de ce mot quand je pense à cette «techno»… traumatisme des galères liées à une appli du taf j'imagine)?

Je veux dire, embarquer Chromium, ne pas avoir d'API stable qui permette de s'interfacer avec le système, bouffer une mégachiée de mémoire vive et poncer le disque dur au lancement à chaud, sans parler d'une intégration déplorable au système (ben oui, obligé d'avoir N instances de chromium sur le disque, puisque l'API n'est pas stable…). Ah, et je sais que l'espace disque c'est «pas cher» (même si perso je préfère avoir de la place pour mes VMs, qui elles ont une raison valide d'être lourdes), mais la bande passante à chaque MàJ par contre si: tout le monde n'a pas la fibre hein, mes parents sont encore à moins de 250 Kio/s de download par exemple.

Du coup, ça fait vraiment la même chose? Ça embarque vraiment chromium en mode sale? Est-ce une bonne chose si c'est le cas?

J'ai pris 2 fichiers, comme ça, au hasard, et… j'ai trouvé le code limpide, ça m'a surpris.

Les fonctions documentent leurs pré-requis, les "if() d'une ligne" utilisent des accolades (donc pas de goto fail probable), le code est aéré…
Vraiment surpris!

Parce que "Oh, tu te rends compte, ils allouent sur la stack! Comment osent-ils!!!", moi, ça me fait ni chaud ni froid.

Je faisait référence à ceci. Oui, on passe notre temps à alouer sur la stack, à chaque appel de fonction même.
Par contre, ça se fait très rarement avec des données en provenance directe de l'utilisateur, et la fonction utilisée pour ça ne permets pas de savoir si l'appel à échoué. Les problèmes mémoire sont assez communs comme ça, pourquoi prendre un risque aussi important? La performance de journald est-elle vraiment critique au point de ne pas pouvoir appeller malloc?

a ne remet pas l'intérêt de SystemD en cause. Il répond à des besoins où nous n'avions pas de solution simple avant.

Comme je l'ai dis, je remercie systemd, du fait qu'il m'a forcé à me pencher sur le fonctionnement du PID 1, et j'ai beaucoup appris ainsi.
Et puis, le côté configuration déclarative, franchement, je trouve l'idée super. Ce que je regrette, c'est que le projet ne semble avoir aucune limite dans le NIH, et vue la criticité de tout ça, je tique.

Je dirais que customiser la totalité du démarrage d'une distribution est un bon moyen d'apprendre:

• comprendre ce qui se passe quand le firmware passe la main au bootloader (grub2, habituellement, quelques-uns préfèrent utiliser syslinux, pour diverses raisons);
• comprendre ce que fait le "PID 1", comprendre ce qu'est l'utilisateur "root" (UID 1, de mémoire, on peut très bien imaginer le renommer en "admin", tant que l'UID reste 1), par exemple en refaisant tous les services, ou en essayant d'autres logiciels que systemd (ce qui force à porter les units);
• se faire (en fait, utiliser une combinaison de logiciels isolés, et non un méta-paquet type gnome) son propre environnement de bureau, ce qui part du gestionnaire de connexion jusqu'à l'explorateur de fichier;
• se faire violence (au début au moins) et cesser d'utiliser un explorateur de fichiers ou un menu graphiques;

Sinon, il reste la possibilité d'installer une distribution de 0, sans passer par l'installateur: ça s'appelle du bootstrap, Debian à même des logiciels faits pour: debootstrap et cdebootstrap.
Déployer un serveur PXE pour utiliser des machines sans disque dur est également formateur (et pratique, ça permets de faire des systèmes jetables rapidement, pour les expérimentations).
Utiliser des gestionnaires de configuration, type Rex, cfengine, puppet, salt, …

Mais bon, comme les autres l'ont dit, ça viens surtout au fur et à mesure, quand on cherche à optimiser son PC pour son usage perso, plutôt que garder des trucs génériques.

Titre «raccoleur» (qui ne marchera ici que sur ceux qui s'ennuyent).
Liens sans informations sur leur contenu.
Conclusion qui sort du vide si on lit juste le «journal».

Tu penses juste être moinssé pour l'anglais?

Et donc? Y'en a un qu'ils ont trouvé à propos, ils l'on choisit, et alors?

Je dirais même que, Ascii, pour un satellite, c'est débile, bordel c'est un standard sur 7 bits quoi, comment peut-on nommer un satellite comme ça?

Faudrait p'tet penser à arrêter de se concentrer sur les apparrences un jour… la plupart d'entre nous est probablement adulte, et pourtant on passe plus de temps a critiquer des apparences, noms, libellés,etc qu'a agir…
En plus, ici, on a un public plutôt orienté technique, alors vraiment, si vous voulez enfoncer devuan, faites-le avec un peu d'arguments, de véritables statistiques que vous pouvez détourner proprement…

Devuan c'est tout de même pas terrible.

Je te rejoins, la parenté est trop présente. D'un autre côté, je pense que c'est le but, malgré l'évidente polémique. Cela dit, à la base, c'était debian-fork, je crois. C'est moins pire de nos jours donc.

J'aurais préfèré un truc plus fonctionnel, évocateur.

Hum… cites moi un seul nom de distro qui soit «fonctionnel, évocateur» s'il te plaît? Chapeau rouge? Deborah Ian? Linux du vide? Super-linux (Arch)?

Rah, si seulement on avait un OS complet appelé Linux.

Y'a moyen, si tu parviens a faire intégrer busybox dans le sourcetree de linux…

On peut lister une série de problème sur à peu près tout, y compris des supers logiciels dont on est "fanatique", ça s'appelle garder son sens critique, c'est pas pour ça que ce sont de mauvais logiciels.

Bien entendu.

une simplification de la situation précédente

Qui était quoi, dans ton cas?

Je comprends les sceptiques, SysV (et consort) est satisfaisant pour les administrateurs, qui connaissent bien leur système (contrairement aux développeurs). Et à partir du moment où ça juste marche, pourquoi vouloir changer ..

Je pense que le problème n'est pas juste lié à "if it works, don't fix it".
C'est quoi, d'ailleurs, les consorts de sysV? C'est quoi, selon toi, le rôle de sysV? Et c'est quoi, selon toi, le rôle de systemd? Tu es programmeur, donc tu devrais être capable de définir le rôle d'un logiciel de façon précise, pour pouvoir l'implémenter correctement.
Et c'est justement ce que moi je n'aime pas avec systemd: ce projet a démarré comme simple init+watchdog, et ça faisait sens. En plus, il promettait de remplacer ces immondes scripts de rc.d par des fichier de déclaration? Génial. Seul inconvénient: pas portable. Bon, ça, ok, pourquoi.

Ensuite, je me suis aperçu au fil du temps que non, je n'était pas capable de voir ou ce projet compte s'arrêter, et qu'il compte remlacer tout un ensemble logiciel éprouvé par de nouvelles implémentations inter-dépendantes.
C'est ça qui m'a fait chercher des alternatives, et je dois à systemd le fait de connaîtres des alternatives à rc.d.

Pour en revenir à la question: pourquoi ne pas l'utiliser s'il marche bien? Parce que, il suffit de lire un tant soit peu pour s'apercevoir qu'à plusieurs reprises des composants de systemd qui n'ont pas à tourner en tant que root ont permis l'escalade de privilège, bugs qui sont liés à l'usage de fonctions dont la simple lecture du rôle me fait froid dans le dos (allouer sur la stack?)!

C'est la même chose pour D-Bus aussi

Marrant que tu en parles. Récemment, sur mon poste perso sous debian, j'ai du recompiler SDL pour virer le support de DBus parce que ça pourrissait les performances (afficher un message d'erreur à chaque fois qu'on ne trouve pas DBus, même si on ne s'en sert pas… mais… sérieux?). Je pense que le problème vient en pratique de la SDL, hein, mais, je trouve ça cocasse.

Tu l'as mal compris.

J'ai noté ça.

C'est pas faux. Sauf:

en pratique, les critiqueurs de systemd veulent juste garder leur vieux truc pire sans proposer mieux

Si on remets le contexte, il y a deux catégories de gens qui critiquent systemd:

• ceux qui veulent rester à rc.d (parce que les cascade d'inclusion de dash, bash, et autres c'est tellement lisible, et devoir se fader 150 lignes de code par service c'est logique);
• ceux qui considèrent qu'il y a d'autres solutions moins "tout-en-un", qui font la même chose que ce que j'ai perçu comme le but initial de systemd (à savoir, être un watchdog logiciel, oui, ça remonte, et à l'époque j'aimai systemd) sans avoir à supporter tout le reste, journald inclu, sur lequel j'ai vu passer plusieurs failles exploitables à distance, et les dernières en date sont liées à l'utilisation de code pour allouer dynamiquement sur la stack, qui n'est pas faite pour ça.

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 :)

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.

C'est assez curieux comme choix de nom

Ça va, ils auraient pu faire pire, ils auraient pu l'appeller BSOD, bricolage en revanche eu été faire de la pub au logiciel qu'ils ne veulent justement pas utiliser… Je trouve ça amusant de reprocher un nom qui certes fait référence à un ancien standard (mais, standard, au moins) et de plébisciter derrière un logiciel qui lui évoque la bidouille pour gérer les parties clé d'un système.
Pour ce qui est du nom, je ne sais pas quand tu as regardé, ça a peut-être changé, mais là, sur la page d'accueil c'est écrit:

Now Devuan ASCII offers an upgrade from Devuan Jessie as well as a transition from Debian 9 (Stretch) that avoids unnecessary entanglements and ensures Init Freedom.

Devuan aliases its releases using minor planet names as codenames. Devuan file names follow this release naming scheme.

En gros, il suffit de lire 3 lignes de plus pour savoir d'où le nom vient.
Et puis, je le trouve amusant moi: il colle à leur taxonomie tout en faisant référence a l'informatique. Accessoirement, contrairement à bien des encodages, ASCII est compatible UTF-8.

Je pense qu'il y a plus a reprocher à Devuan que leur choix de noms et de ne pas utiliser systemd, mais pour ça, il faut l'essayer.

Je n'ai pas dis que c'était le mal et qu'il fallait en partir, j'ai même dit que c'est préférable à rc.d.

Je pense qu'il adresse bien une grande classe de problèmes, mais comme toutes les solutions il n'est pas parfait, alors il faut arrêter de le mettre sur un piédestal.

Quand j'ai lu "rien ne nous fera revenir en arrière" dans le contexte, j'ai compris "systemd forever", c'est du fanatisme, surtout quand celui qui me fait comprendre ça liste une série de problèmes qu'il a eus, factuellement.

Par contre, je trouve l'idée d'utiliser des outils pour allouer sur la pile une super mauvaise idée en général, et en particulier pour un logiciel qui tourne en tant que root, accessible via le réseau.

Ok, le seul vrai problème que j'ai eu c'est quand Coreos a décidé sur une release mineur de changer la config du format de stockage des logs, qui était incompatible avec ma version courante de journalbeat. De là à incriminer systemd…

Ça, c'est clairement pas imputable à systemd, je manque de mauvaise foi sur ce coup :)
On pourrait à la rigueur leur repprocher un versionning qui ne parle pas (juste un nombre entier qui s'incrémente, si je ne m'abuse), mais bon, avant de mettre à jour un élément clé, on lit les release note pour moi, donc c'est clairement pas systemd le problème ici.

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;

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.

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.

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).

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.

rien ne nous fera revenir en arrière.

Pas même un watchdog qui fasse son job efficacement? Parce que de ce que tu dis, systemd est une vraie merde. Je cite:

j'ai eu des services recalcitrants, systemd ne m'a jamais aidé et m'a même posé problème

Pourtant systemd prétend pouvoir tout gérer.

GDM - dont le service ne porte pas le nom et ne se désactivant pas via systemctl

GDM… c'est le gestionnaire de session de gnome, non? L'un des DE qui dépendent le plus de systemd je crois?

qui timeout sans fin

Tu n'avais, j'imagine, pas accès aux TTY classiques? Il est ou le chargement à la demande? Voire en parallèle?

zero entrée dans les logs ou stdout, ni audit. C'est en repassant dans tous les fichiers de config que j'ai trouvé le problème.

Tu sembles dire que les fichiers de conf de systemd sont compliqués à comprendre, pourrais-tu détailler?

Mais journald, la gestion de dépendances tout ça ne m'a aucunement aidé. :/

C'est tout de même dommage, journald à pour seul et unique rôle de journaliser les évènements. L'échec du démarrage d'un binaire est la première chose que je loggue quand j'écrit un logiciel… un truc du style

if( -1 == foobar( ... ) )
{
//si fonction systeme
  fprintf( stderr, __FILE__ "[%d]:\t%s\n", __LINE__, strerror( errno ) );
//sinon expliciter le pre-requis qui a foire
  return false;
}

Si les types qui s'amusent à faire des allocations dynamiques en boucle sur la stack (c'est pas vraiment la 1ère faille de sécurité avec journald…) sont pas foutus d'utiliser ce genre de trucs, ça fait quand même peur, non? Je veux dire, je suis loin d'être un dev exceptionnel après tout…

Désolé pour le troll, mais je trouve ta position très amusante. Oui, systemd a de bonne idées. Surtout une: la configuration déclarative. Le reste est trop bordélique, essaie trop de faire le café, et c'est bien le reste qui fait que compte rester le plus loins possible de ce machin.