merci beaucoup pour ces journaux et votre travail sur le boot.
En ces temps où il est déjà difficile d'expliquer et responsabiliser des dev(ops) qui piochent n'importe quelle image cloud ou Docker et ne se posent aucune question de sécurité et de chaîne de confiance, aller jusqu'au boot et expliquer qu'il faudrait aussi s'inquiéter du firmware n°1 est une tâche super ardue... Ca me semble pourtant en effet essentiel.
Je vois aussi d'autres avantages : par ex. concernant Meltdown, les maj de microcodes restent étroitement liées aux constructeurs et à leurs BIOS (je peux les faire moi-même depuis Linux, mais le vendeur peut me garantir la couverture de test pour un hard particulier). Avec un LinuxBios je pourrais court-circuiter le vendeur et faire mes tests beaucoup plus facilement...
Et oui, le temps de boot des serveurs c'est un sujet, chez Dell on en arrive à des POSTs délirant de 2 à 3min pour le moindre serveur. Quand on debug un automate ou une panne ça rend le processus extrêmement inefficace. Quand on veut minimiser un downtime sur un service non redondé ou cloudé (et il en reste des tonnes dans la nature), c'est souvent ce qui plombe le SLA. Et objectivement on sait que c'est un indécent par rapport aux réels besoins que la physique impose (stabilisation des alims, allumage en cascade des éléments, etc). Tout POST > 10s devrait pouvoir être considéré comme un défaut de construction :(.
Note historique : j'ai bossé au début des années 2000 sur des Cobalt/Raq (projet Sun) qui utilisaient Linux comme firmware, et c'était tellement bien conçu et ouvert que je pouvais moi-même recompiler des Linux/firmwares sans soucis (sans être dév kernel). Le support Cobalt/Raq était d'ailleurs mainstream dans Linux (au moins pour les 2.2 et 2.4). J'ai ainsi maintenu des firmwares de ces Raq pendant plus de 5 ans après la fin de vie de ces produits. Ces machines étaient triviales à administrer à distance, provisionner, debugger. Elles postaient en 1 à 2s (!). Tous les autres équipements (serveurs, routeurs) me semblent d'une hostilité incroyable depuis cette expérience.
Sur vos questions sur le contexte de boot idéal, je ne sais pas trop ce qu'il pourrait être mais j'ai une bonne idée sur ce qu'il ne pourrait pas être :
oublier tout ce qui est vidéo/VGA; ou plus exactement le laisser hors-scope, ceux qui veulent aller de ce côté le feront s'ils le souhaitent
oublier les interfaces pseudo-vidéo à la ncurses : souvent inutilisables via des consoles séries, n'ont en général pas la moindre notion de termcap, sont inscriptables, etc; pareil, devrait être hors-scope, si des gens veulent faire ça, qu'ils n'embêtent pas les autres avec ça
oublier les firmwares pluggables avec chacun leur propre vision du monde (et interface, et idiomes, etc), mais ça je crois que c'est déjà fait vu que c'est dans le design de NERF :)
oublier IPMI dont l'intention est bonne mais dont le protocole est ridicule (personne ne l'implémente correctement, du moins de façon interopérable, et je parie qu'il est truffé de trous de sécu)
Dans le cahier des charges, il me vient à l'esprit :
être trivial à prendre en main par un opérateur; le fait que ce soit une forme de shell autodocumenté semble assez attendue
faciliter l'automatisation; sans aller jusqu'à vouloir définir une API, ce qui serait trop rigide et trop de travail. Ca peut très bien marcher en laissant les acteurs se synchroniser sur des formats 'machine readable' des commandes usuelles, le pragmatisme faisant souvent des merveilles; en tout cas les admins sont rompus à assurer la glue avec ce genre d'outils et n'auraient aucune objection a maintenir un jeu d'automate par vendeur (rien que pouvoir le faire serait une avancée énorme, regardez la complexité et la fragilité de FAI)
avoir des opinions fortes pour limiter la configurabilité et faire disparaître plein de problèmes de déploiement et de développement; par ex. les Cobalt/Raq avaient un port série en 115200n8, c'était comme ça et pas autrement (et, malins, un second port série pour un usage libre, rendant tout le monde content). Evacuation de moults questions et inconnues, s'il n'y a pas de raison que ça soit configurable, alors ça ne doit pas l'être.
s'il doit y avoir de l'auth, utiliser/imposer SSH; la hostkey pourrait être générée pour chaque build et signée par le builder (sur un site public), ce qui permettrait de vérifier trivialement qu'on s'adresse bien à la première connection au firmware fourni par le tiers prévu
d'un autre côté je dois dire que j'utilise des LAN dédiés pour l'ILO et si je pouvais juste avoir des telnets triviaux, ce serait aussi simple; mais SSH est tellement universel, trivial, et surtout beaucoup plus utilisable que telnet (notion de canal, pty oui/non, keepalive, tunnel, etc) que je ne vois aucune excuse de s'en passer
Et c'est peut être hors sujet, mais si on pouvait obliger la présence d'un support Flash librement utilisable d'environ 512 MB, ça ne coûterait quasiment rien à l'intégrateur, et ça pourrait révolutionner le déploiement de pas mal de serveurs où l'OS est très simple (hyperviseur, filers, routeurs soft, loadbalancers soft, etc.) quand on veut être plus résilient qu'une infra de netboot (qui de plus est pénible à maintenir et scaler).
# Suggestions/expérience sur le boot de serveur
Posté par zerodeux (site web personnel) . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). Évalué à 3.
Bonjour,
merci beaucoup pour ces journaux et votre travail sur le boot.
En ces temps où il est déjà difficile d'expliquer et responsabiliser des dev(ops) qui piochent n'importe quelle image cloud ou Docker et ne se posent aucune question de sécurité et de chaîne de confiance, aller jusqu'au boot et expliquer qu'il faudrait aussi s'inquiéter du firmware n°1 est une tâche super ardue... Ca me semble pourtant en effet essentiel.
Je vois aussi d'autres avantages : par ex. concernant Meltdown, les maj de microcodes restent étroitement liées aux constructeurs et à leurs BIOS (je peux les faire moi-même depuis Linux, mais le vendeur peut me garantir la couverture de test pour un hard particulier). Avec un LinuxBios je pourrais court-circuiter le vendeur et faire mes tests beaucoup plus facilement...
Et oui, le temps de boot des serveurs c'est un sujet, chez Dell on en arrive à des POSTs délirant de 2 à 3min pour le moindre serveur. Quand on debug un automate ou une panne ça rend le processus extrêmement inefficace. Quand on veut minimiser un downtime sur un service non redondé ou cloudé (et il en reste des tonnes dans la nature), c'est souvent ce qui plombe le SLA. Et objectivement on sait que c'est un indécent par rapport aux réels besoins que la physique impose (stabilisation des alims, allumage en cascade des éléments, etc). Tout POST > 10s devrait pouvoir être considéré comme un défaut de construction :(.
Note historique : j'ai bossé au début des années 2000 sur des Cobalt/Raq (projet Sun) qui utilisaient Linux comme firmware, et c'était tellement bien conçu et ouvert que je pouvais moi-même recompiler des Linux/firmwares sans soucis (sans être dév kernel). Le support Cobalt/Raq était d'ailleurs mainstream dans Linux (au moins pour les 2.2 et 2.4). J'ai ainsi maintenu des firmwares de ces Raq pendant plus de 5 ans après la fin de vie de ces produits. Ces machines étaient triviales à administrer à distance, provisionner, debugger. Elles postaient en 1 à 2s (!). Tous les autres équipements (serveurs, routeurs) me semblent d'une hostilité incroyable depuis cette expérience.
Sur vos questions sur le contexte de boot idéal, je ne sais pas trop ce qu'il pourrait être mais j'ai une bonne idée sur ce qu'il ne pourrait pas être :
Dans le cahier des charges, il me vient à l'esprit :
Et c'est peut être hors sujet, mais si on pouvait obliger la présence d'un support Flash librement utilisable d'environ 512 MB, ça ne coûterait quasiment rien à l'intégrateur, et ça pourrait révolutionner le déploiement de pas mal de serveurs où l'OS est très simple (hyperviseur, filers, routeurs soft, loadbalancers soft, etc.) quand on veut être plus résilient qu'une infra de netboot (qui de plus est pénible à maintenir et scaler).