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 freem . En réponse au journal Debian, installations automatiques et ARM. É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):
apt-get update(pour générer la liste des paquets à installer);