diff --git a/docs/live-build/live-build-apprentissage.md b/docs/live-build/live-build-apprentissage.md new file mode 100644 index 0000000..06c739b --- /dev/null +++ b/docs/live-build/live-build-apprentissage.md @@ -0,0 +1,779 @@ +# formation live-build + + * 19/05/2017 + +``` + attention au flood :P +[---------------------- +Bienvenue @tou-te-s sur ce chan pour la première session de formation empirique live-build Debian :) +le but de cette formation est de vous guider dans le processus de configuration, de construction et +de diffusion d'un live Debian. +la session commence maintenant et se poursuit tout le week-end afin de vous permettre de construire, +tester, puis revenir ici pour résoudre d'éventuels soucis ou ajouter des options de configuration. +il y aura quelques pauses, en fonction de l'heure mais aussi de l'activité de chacun et/ou de mes 5 enfants :D +pour me présenter rapidement : arpinux aka arnault, dev autodidacte qui ne sait pas coder en C, maintainer/builder +de https://arpinux.org/livarp , https://handylinux.org , https://lescahiersdudebutant.fr/dflinux.html et +https://kissballad.arpinux.org/kiss0s.html . rédacteur principal de https://lescahiersdudebutant.fr +et anarchiste assumé. +je bidouille live-build depuis 2011 et non, la documentation officielle et les mans ne sont pas à jour car ça +bouge trop vite et ils ne sont pas des tonnes à assurer la documentation. donc je me propose de vous aider +à y voir plus clair dans les options et les possibilités de live-build. +si vous avez déposé vos sources de build sur git ou cloud quelque part, n'hésitez à filer le lien pour que je +puisse cloner, jeter un œil aux fichiers et tester avec vous :) +si vous êtes là, c'est que vous avez construit au moins 1 live et que vous avez des questions, alors je vous +en prie, c'est le but, soyez pas timide :) +-----------------------] +``` + +## principe live-build +``` + +l'installeur étant buggé pour l'instant le processus par défaut initialisé par le udeb +live-build et le processus en ligne appelé sont en conflit. en fait, l'installation fait +cohabiter deux programmes en très gros. +le premier programme, live-build, construit le live, il fonctionne en local. on peut configurer +les dépôts en local, ça ne le gêne pas + +le second programme, l'installeur fait appel aux dépôts en ligne, donc si il y a la moindre +différence dans les processus initiés par ces deux programmes, on se retrouve avec un bug de +l'installeur au final +c'est rare car les tâches sont normalement bien séparées mais lors de l'installation d'un +liveCD de type 'live' c'est le système du squaqhfs qui est copié sur le système donc à ce +moment, les versions se "croisent" si je puis dire + +la configuration intégrée dans le live (modifiée par nos soins) et la configuration appelée +par l'installeur, en UEFI, j'ai remarqué que le preseed n'était pas pris en compte au même +moment par l'installeur effectivement, alors qu'en démarrage BIOS, oui. +donc ça confirme que la différence vient du traitement efi +``` + +## conseil +``` + +le principe de synchronisation des configuration : +un dossier de build contenant les sources + un dossier en ligne sur cloud ou serveur + le /home +d'une machine de test 3 dossiers à synchroniser pour être certain que le dossier de build soit à jour +comme l'indiquait coyotus, il arrive parfois que des applications changent l'adresse de leur fichier +de conf le cas ~/.blah.cfg -> ~/.config/blah.cfg est le pus courant effectivement +pourquoi ? +car la normalisation veut que les programmes placent leur configuration par défaut dans /etc/xdg +qui est le dossier système qui correspond à ~/.config pour l'utilisateur +un peu comme le /usr/share/icons/ correspond à votre ~/.icons +un changement d'adresse provoque immanquablement une mauvaise lecture de la configuration +sauf chez conky, merci les devs, qui sait même traduire tes anciennes conf !!! je voulais le préciser +quand même :D +et donc, une machine test/dédié permet de ne pas se soucier de ce genre de détails tant que votre +machine test tourne comme vous voulez, c'est que les conf sont lues un bug qui apparaît dans votre +machine test vous renseigne sur le bug à venir de votre build de la même façon :) +donc prenez soin de tester le plus possible. il vaut mieux tester sur la machine dédiée, plutôt +que de refaire des builds à l'aveugle car on est sûr que "ça va passer" :) +je me suis fait avoir assez souvent par arrogance :/ +pour les dossiers systèmes et les paquets c'est la même chose mais pas de synchronisation +les tests et vérifications se situent au niveau du terminal, +donc pour les paquets, le plus important est de s'assurer de ne pas installer de truc superflus +c'est pourquoi il faut régulièrement faire les mises à jour, bien sûr, mais surtout, envoyer un +apt autoremove --purge si des paquets ne sont plus nécessaires dans le système test, +ils seront potentiellement en conflit dans le futur build si vous ne lez retirez pas +``` + +## live-wrapper +``` + alors pour rassurer, effectivement, ce sera le nouvel outil pour faire des live debian + mais live-build est maintenu + et fabrique des live similaires + hormis cette compatibilité uefi après personnalisation sur une install sans réseau ... + en fait, live-wrapper n'accepte pas de conf locale pour l'instant + pas sur le modèle du chroot.includes de live-build + il est conçu pour choper du paquet + alors d'où tu veux + mais du paquet + donc c'est un outil de fork plus que personnalisation + il impose l'utilisation de dépôts externe pour modifier le comportement des applications + par exemple + avec live-build + pour modifier le menu fluxbox, + il faut modifier le ficher /config/includes.chroot/etc/skel/.fluxbox/menu et voilà + rien de plus + donc en gros, un copier coller de ton menu et hop + simplissime si tu sais où le coller + avec live-wrapper + la modification doit s'effectuer au niveau du menu par défaut de fluxbox + donc fork du paquet fluxbox dans un dépôt externe + utilisation de ce dépôt pour faire ton live + c'est une autre façon de travailler + plus professionnel je dirais :) + dans le cas de live-wrapper, les compétences de maintainer de dépôts sont obligatoire + avec live-build + faut savoir lire et faire des copier coller + Donc avec live-wrapper tu ne peux rien personnaliser tant que tu n'as pas une infrastructure réseau + tu peux toujours utiliser un dépôt en local starsheep , mais il faudra de toute façon un dépôt en ligne à un moment pour les users + ou alors tes mods risquent d'être écrasées par une mise à jour debian + oui ... bien lire le chapitre "ce qui ne fonctionne pas" ! :D + sinon, c'est la haine + genre tu te modifies tout plein de .desktop dans /usr/share/applications ..... + ah non, mais c'est excellent comme outil + mais comme le reste ça devient une "affaire de spécialistes" + par principe, tout fichier appartenant à un paquet est potentiellement écrasable + donc modifier un .desktop ou un menu dans /etc/xdg ne sert à rien + il sera écrasé + donc il faut passer par les dossier de personnalisation prévus + pour l'utilisateur, c'est le /etc/skel + les paquets ne déposent rien là-dedans + c'est le dossier qui forme le /home/$USER lors de l'installation + et aussi le /home/$USER du live + donc c'est l'endroit idéal. + mais ça ne suffit pas toujours + d'ac et live-wrapper ne permet pas d'exploiter /etc/skel ? + genre pour modifier le grub, le fstab ou ce genre d chose + alors si, avec un paquet externe qui irait peupler le /etc/skel + voilà, toute la conf user dans un paquet + pareil pour la conf système + la plupart des programmes acceptent les configuration de type /etc/apt/sources.list.d + le ".d" + Donc plus de copier-coller dans live-wrapper + non starsheep + mais modifier le $HOME via des paquets c'est dégueulasse + donc faut quand même une autre méthode + mais en ajoutant de la conf système dans les ".d" des dossiers système,n on peut aussi modififer le comportement sans forker les paquets + et oui starsheep , c'est pourri + donc pour faire propre faut forker les paquets + donc avec live-wrapper faut créer des paquets avec des fichiers de conf dans /etc + donc faut maintenir un dépôt + par le biais d'un paquet, oui starsheep + Mais si le logiciel n'accepte pas de conf dans etc mais juste dans le $HOME, ben faut reprogrammer + ou je me trompe ? + d'où les deux paquets, pour le user et pour le sys + la modification user d'un côté et les mods système de l'autre + sinon, pour finir avec live-wrapper, ils vont peut-être ajouter une fonction de personnalisation en local, mais rien pour l'instant + donc je continue d travailler avec live-build + qui est en plus maintenant maintenu par Raphael Hertzog + cool d'avoir un français qui dev dessus :) + il a d’ailleurs déjà filé un coup de main à Patrick D'Emmabuntüs Debian Edition pour rendre l'EmmaDE compatible UEFI sur Jessie :) + devant ce silence, je me dois d'indiquer que la seconde raison qui m'a poussé à faire cette session + c'est le cassage de mythe du dev + les gars comme Raphael sont accessibles, il faut le savoir + donc même si vous débutez et que vous voulez un coup de main, n'hésitez pas à contacter les dev + un peu comme en politique ... faudrait pas hésiter à harceler nos députés ;) + ce sont des humains :) +``` +## synchronisation +``` + comment tu fais pour exporter tes modif sur git pour avoir tes sources à jours en temps réel ? + git push ? ^^ + depuis le dossier de build ou l'env de test ? + même pas git perso ... je fonctionne avec un cloud openmailbox. + mais pour la synchro + je fonctionne au cloud à la main + entre la machine test et la machine de build + oui + c'est automatisable + genre git push depuis ta machine de test et git pull depuis ton dossier de build + mais ça impose l'installation de git sur la machine test + alors que justement + la machine test doit rester la plus fidèle possible à l'installation par défaut du user + pour ça que j'utilise un cloud + par exemple + juste avant le build + j'archive sur la machine test mon ~/.mozilla , ~/.config ... + j'upload sur cloud + je récupère sur la machine de build + je mets à jour les dossiers dans le build et hop + ça laisse le système de teste vierge + car c'est ça le piège + Tu fonctionnes en 3 temps alors ? + quand on geek souvent, on se dit que modifier la bonne ligne suffit, mais comme tu l'as dit tout à l'heure, une modification de syntaxe peut aussi intervenir sans ton "consentement" et donc, tu ne le reportera pas dans le build, sauf à synchroniser les dossiers + Tu build un premier coup, tu balances sur la machine de test, tu fais ta config et tu balance le $HOME pour créer le skel et tu rebuild ? + en gros starsheep oui :) + heeeeeeeein + ah ben je viens de comprendre un truc + et avec une VM et un partage de fichier ça ne peut pas être plus simple ? + mais im ne faut pas non plus tout prendre dans le home de ton test + genre la résolution de l'écran + les icpnes du bureau + ah oui oui + le cache ... + c'était pour résumer + bref .. il y a un gros tri à faire ... + oui :) + mais c'est le principe +``` +## aparté +``` + alors pour le skel je comprends. Mais /usr/share il n'est pas modifié par les paquets lui ? + si on peut + mais sans ajouter de programmes qui seront appelés plus tard + par exemple + si tu veux coller ta version de conky dans le build + tu peux + - forker le paquet et l'appeler depuis la liste des paquets + - forker ton paquet et l'ajouter en dur dans le build + - forker le binaire et l'ajouter à la main + Mais + dans le cas 1, il faudra configurer apt pour lui indiquer par pinning de préférer ton conky à celui d debian lors de la prochaine mise à jour + dans le cas 2, idem, mais en plus, tu ne pourras pas mettre ton conky à jour + dans le cas 3, ton conky sera écrasé dès le build par l'installation du 'vrai' conky + donc tu dois forker + renommer + ou alors + forker + placer ailleurs + ok + genre .usr/local/bin + aaaaah ok + dans le cas de DFLinux ou nos autres projets, le soucis ne se pose pas + c'est pour ça que dans kissos tu as un /usr/local/share + carnos programmes sont des ajouts et non des forks + pour dwm-kissed + oui starsheep, et aussi pour respecter l'architecture de base : ajout externe > local + ajout externe ? + En dehors des paquets ? + oui +``` +## séparation binary/chroot +``` + et donc un autre aspect pratique que je souhaitais souligner à propos de live-build,c'est la séparation binary/chroot visible dans plusieurs dossiers/fichiers. + live-build permet de séparer les applications installées dans le live de celles effectivement intégrées dans la distribution finale + binary c'est pour le live et chroot pour l'installation ? + donc le live 2 en 1 :) + le principe est d'intégrer des programmes qui seront présent dans le live, mais pas dans la session installée et inversement :) + ainsi, vous pouvez avoir sur un même cd, gparted disponible en live pour vérifier vos disques, mais pas dans la version installée + plusieurs avantages : la disponibilité dans le live de nombreux programmes sans pour autant alourdir le système installé + l'installation de nombreux programmes dans le système installé sans alourdir lechargement ni les menus du live + l'équilibre est à trouver selon l'objectif du live + mais vous voyez de suite le panel des possibilités :) + yep + l’extrême étant de faire un live qui n'a rien à voir avec le système installé au final + et c'est possible de façon "transparente" + cad sans que le user du live puisse le voir + Il n'y a pas moyen de faire un truc commun aux deux sans faire doublon dans les sources ? + un système live jessie stable pour tourner tranquille, mais qui renvoi à l'installation d'un sid + car les binary/chroot + sont des options disponibles aussi pour les miroirs consultés lors du build + donc live-build peut appeler des paquets de différents branches de debian pour le live indépendamment des paquets du système final + genre tu appâtes le chaland et crac! sid :o) + yes ! :D + sans aller jusque là, ça a le mérite de pouvoir éviter la surcharge du live en en supprimant toutes les applications non-essentielles par exemple + un live-ultra-light installant un système complet :) + l'inverse est possible aussi. un live ultra-complet pour montrer de quoi est capable debian, mais plusieurs formats d'installation + car oui + on peut aussi installer plusieurs système différents depuis le même live + en dehors de la distinction binary/chroot + oui + ça en fait des possibilités :) + alors pour ceux que ça branche, voilà le principe + vous trouverez dans les sources de DFLinux https://git.framasoft.org/dflinux/DFiso le dossier /config/includes.binary/isolinux + c'est la config du menu syslinux au boot du live + le fichier install.cfg liste les entrées de menu pour l'installation. il indique lefichier preseed de préconfiguration à utiliser, on en a parlé au début. + il suffit de coller plusieurs entrées, avec un appel à des preseed différents :) + on peut coller une liste de paquets dans le preseed, donc.... + potentiellement une autre distro + et autant de sitro que d'entrées de menu syslinux + multi-possibilités ce live-build :) +``` +### installer depuis live +``` + Tu n'as toujours pas trouvé pour appeler les preseed depuis le live ? + Pour ne pas retourner sur syslinux pour installer le système + pour installer sans retourner sur syslinus, il y a le lanceur d'installation de bureau + mais je ne l'intègre jamais + j'explique + le lanceur de bureau existe et permet effectivement de lancer l'installation sur le disque depuis une session live + le soucis + si pendant l'installation, le user ouvre son navigateur ou toute autre application rameuse + il peut freezer son interface graphique + oui c'est un reproche récurrent qui est fait à DFLinux (et avant HandyLinux) + l'installation continuera en background + mais il n'aura aucun retour ni interaction possible + ah ouai pas con + dangereux ce machin + donc le dernier 'installation termniée, cliquez ok" ... bah tant pis ... + et c'est pas trop grave si c'est ça + en revanche, dans le cas d'un dual boot + alors là + bah dommage .... + répare ton MBR + :/ + t'as pété ton grub ^^ + nooon pas le MBR !!!! + :D + et c'est vraiment le truc tellement con pour un tout petit confort que je ne le fais jamais :) + Trop de mauvais souvenirs :p + c'était rigolo sur ubuntu de frimer en navigant et installant ... jusqu'au moment ou ça freeze ... + et tu frimes moins + non, vraiment, c'est une feature à éviter + comme le "--interractive" + l'option qui permet d'ouvrir une console pendant le build .... + l'arme absolue ... + alors oui + on peut virer oute les autres options, ne laisser que celle-là + et lors du passage en 'interractive', + bah tu construis ton livesystème directementdans le chrrot + tu fais ton live en temps réel à la main + c'est une possibilité +``` +## les hooks +``` + donc les hooks sont des scripts qui s'exécutent dans le chroot juste avant de le quitter et de le compresser en squashfs + même moment que interractive + mais en automatique + c'est pour le fignolage + :) + ok ! + on peut potentiellement faire tout ce qu'on veut + pas de limite + Je les oublie toujours ceux là + openbar dans le chroot + pourquoi ils ont des chiffres les hooks ? Si on ajoute celui que tu proposes dans le tutto on le nomme avec une valeur particulière ? + l'ordre d'exécution + ils s'exécutent dans l'ordre, tout simplement + donc pratique si une action en demande un autre :) + celui pour prendre en compte les ‘proposed-updates’ tu le nomme comment ? + sans numéro particulier dans les sources car il peut se lancer n'importe quand + proposed-update.chroot + un autre fichier à tout faire + c'est une option du fichier preseed dont on a déjà parlé + -late-command + c'est une option passée à l'installeur debian + et qui permet de lancer des commandes sur le système fraîchement installé avant le reboot + c'est la dernière chance de modifier le système avant que l'utilisateur prenne la main dessus + dans les sources et le tuto support, il ne fait pas grand chose hormis fixer la date d'installation et virer 3 paquets inutiles au cas ou l'installeur ne l'ai pas fait + après on ne peut même plus balancer de virus + pas drôle + depuis les dépôts externe, si, mais c'est mal + :) + :) + faut voir le process de build en 3 temps + installation du système de base dans un chroot + copie du chroot modifié (le includes.chroot) dans le chrrot de build + compression du chroot et build du live + le système de base c'est donc Debian dans ce cas + le hook se fait juste avant la fin du 2 + oui starsheep , plus les paquet listés dans le build + ensuite viennent les modifs du includes + ensuite les hooks système + ensuite les hooks perso + puis la compression en squasjfs + squashfs + et enfin les -late-command + non starsheep + les late-command, c'est à l'installation + les hooks ,c'est lors du build + oui, il y a vraiment énormément de façon de modifier son live, même après le build +``` + +## simulation de build + + * avec suivi git + * irc 20/05/2017 + +``` +[20:04:44] attention au flood .... +``` +``` +[----------------------------------------------------------------------- +Bonsoir et bienvenue dans la session de simulation de construction d'une ISO personnalisée Debian :D + - but de la session de travail : décomposer la personnalisation et suivre les modifications apportées + aux sources du build au fur et à mesure + - outils utilisés : + - je travaille sur dépôt git, donc l'outil approprié serait ... git, mais vous pouvez aussi télécharger les sources en + archives zip https://git.framasoft.org/arpinux/dfl-apprentissage/repository/archive.zip?ref=master puis suivre les + différentes modification en ligne directement depuis la page des commits du projet + https://git.framasoft.org/arpinux/dfl-apprentissage/commits/master + - si vous utilisez git, vous pouvez cloner les sources depuis un 'git clone https://arpinux@framagit.org/arpinux/dfl-apprentissage.git' + puis suivre la progression avec 'git pull' à chaque étape. + +je vais partir d'un live vide puis ajouter par section les différents éléments. + pour l'exemple, je ne construirai pas de live compatible efi, car l'option est encore en travaux, et le but principal est de bien + suivre une construction, pas de tester la compatibilité UEFI :) +vous pourrez personnaliser plus finement votre environnement après la session, je ne rajouterais que peu d'éléments, ceux qui me + semblent les plus pertinents pour commencer avec live-build. +le contenu de cette session sera ensuite disponible sous forme de wiki+archives pour consultation hors ligne. + + notez que le processus simulé ce soir n'est pas fixé et que ce n'est qu'un exemple ... vous êtes libre ! :D +-----------------------------------------------------------------------] +``` +``` +git clone https://arpinux@framagit.org/arpinux/dfl-apprentissage.git + +``` +``` + donc cd ./dfl-apprentissage + puis git pull + quand j'ai fait les modifs :) + je vais tout expliquer au fur et à mesure :) + donc la première chose à ajouter dans les sources d'un build, ce sont les premiers scripts de config et de construction + situés dans le dossier /auto des sources + il n'est pas encire là :) + donc le premier ajout + quand le réseau voudra bien me l'uploader .. + vous pouvez git pull ou visitez les commits https://git.framasoft.org/arpinux/dfl-apprentissage/commits/master + le fichier 'build" est celui livré par défaut dans live-build + le fichier 'build" est celui livré par défaut dans live-build + le "clean" est modifié pour nettoyer plus + pour y voir plus clair sur les modifications des sources + on aurait pu faire lb config? + dans config il y a --architectures "i386" \ normal ? que pas autres + alors le lb config sans arguments, c'est pour faire une debian netinstall + et pour voir toutes les possibilités en bloc + le sujet de ce soir, c'est partir de rien et ajouter le strict nécessaire à la personnalisation + dans ce cas, un lb config à vide ne sert à rien + donc 3 nouveaux fichiers et le plus important étant le auto/config + script qui va définir les arguments lancés à lb build + donc les options de ce script que vous pouvez parcourir +``` +``` + pour la liste complète des options acceptés, un man lb config renseignera + mais le but de ce soir est vraiment d'en faire le minimum pour un résultat optimal + donc dans les options indiquées dans auto/config, on remarque la ligne "architecture" qui permet de construire un live avec une arch différente de celle du système hôte + notez qu'il n'es pas possible de build une amd64 depuis un i386 mais l'inverse, oui + on va déjà se concentrer sur le processus global pas à pas et ne pas détailler chaque option de suite sinon ce sera sans fin et surtout illisible pour quelqu'un qui aimerait suivre le tuto + comme je disais, la liste complète des options est dispo dans le man, mais il n'est pas totalement à jour + donc pour vérifier celles que vous voudriez modifier dans les sources de ce soir, + on peut se reporter aux fameux "test à vide" effectué hier ou simplement se contenter de celui que je fournis et qui vous permettra de build sereinement sans trop vous poser de question au début :) + le plus important reste la personnalisation + les paquets à installer + et le final + la custo du bureau de base :) + pour se faire Son ISO + :) +``` +``` + donc la suite de la personnalisation réside dans les applications à installer + ce soir, on va faire simple, on va coller les mêmes apps dans le live et dans le système final + mais il est possible de séparer les paquets pour avoir des applications en plus/moins dans le live et le système installé, on y reviendra au final + donc la liste des paquets se trouve dans le dossier config/package-lists/ + qui arrive :) + alors effectivement, dans la liste que je vais poster, on pourrait encore simplifier + et vous pourrez d'ailleurs le faire + je push ... j'arrive :) + vous pouvez pull depuis les sources + ou visitez les commits https://git.framasoft.org/arpinux/dfl-apprentissage/commits/master +``` +``` +git pull +``` +``` + il y a deux listes + la liste live* a été ajoutée automatiquement par live-build + elle contient des paquets présents dans le live et qui ne seront pas installés + vous comprenez que vous pouvez éditer cette liste + et y ajouter tout les applications que vous voudriez voir dans le live et pas dans le système + attention + donc cette liste live* est ajoutée par live-build + mais vous pouvez en coller une autre + en fait tout fichier placé ici /config/package-lists/live* avec l'extension .live + sera prit en compte par live-build + donc vous pouvez faire des listes à thème si vous voulez + genre multimedia.live .... + et là vous auriez du me stopper car ne n'est pas l'extension live, mais le nom .... +* arpinux le boulet + :D + mais si vous avez les sources devant les yeux, vous avez capté le truc :) + bref +``` +``` + l'autre liste, la *.chroot, est destinée aux paquets installés dans le live + dans le système installé + donc la seconde liste avec les applications + elle est détaillée car je n'ai pas mis de gros méta-paquets + le système des dépendances debian permet de réduire la liste à 5 ou 6 paquets grace aus "taskel" + mais ça fait des live assez gros + comme les live officiel en fait + donc pour éviter ça, on ne colle pas des trucs genre gnome-desktop :) + mais plutôt les composants séparés + donc je vous invite à ouvrir cette liste madebian.list.chroot + vous pouvez supprimer ou ajouter des applications en prenant soin de vérifier qu'elles se trouvent bien dans les dépôts stretch :) + la liste d'origine fournie donne un temps de build de 2h en gros, avec un système final fonctionnel + bureau xfce/firefox/transmission/cups ... le nécessaire :) + mais je vous laisse quelques minutes pour bien mater le fichier, et le modifier à votre guise + vous pouvez yu aller, ça ne gênera pas la suite des ajouts ,quoique vous modifiez :) + voilà, j'espère que vous avez eu le temps de modifier votre liste, vous pourrez y revenir tout à l'heure :) +``` +``` + passons à une truc débile et rigolo + la bannière de l'installeur graphique :) + et donc, avant de taper dans les trucs longs et embêtant + un petit plaisir de sucto + la bannière + le truc qui va s'afficher en haut pendant l'installation + et qui dire + dira + "tu installe ma distro" :D + un peu d'ego ne fait pas de mal si il ne fait pas d'ombre à l'autre :) + c'est dans le dossier config/includes.installer/usr/share/grahics/ + qui n'est pas encore là :) + vous pouvez git pull ou visiter les commits :) + oui, je sais, c'est futile + mais ça rassure aussi l'utilisateur de savoir que le builder s'est un peu fait chier à personnaliser son truc et n'a pas juste balancé 2 walls et 3 applis :) + c'est pas anodin :) +``` +``` + passons à plus sérieux + le menu de boot du live + il est contrôlé par syslinux + pour le personnaliser, vous pouvez changer les labels des entrées , le fond et même en rajouter + par exemple + lister plusieurs entrées avec différentes langues activées par défaut + car les options passées à syslinux sont comme les options de grub + on va voir de suite un custo simple + ça se passe dans /config/includes.binary/isolinux/ + qui arrive :) + vous pouvez git pull ou visitez les commits https://git.framasoft.org/arpinux/dfl-apprentissage/commits/master + le nouveau dossier intègre un menu pour le live et un fond d'écran + mais vous pouvez aussi personnaliser le label d'installation, le titre principal etc + vous aurez des exemples plus complet sur DFLinux + donc le fichier live.cfg + vous pouvez voir que ce fichier contient le label "tester debian" en premier + avec un ^ + c'est pour indiquer la touche d'accès rapide au clavier + le raccourcis quoi .. + la dernière ligne de chaque section indique les options passées au kernel + append boot = .... + c'est là que vous pouvez spécifier la langue du live + le fichier install.cfg n'est pas dans ces sources car on ne le personnalise pas, il sera ajouté par live-build et donc, on aura bien une entrée 'install' dans le menu final :) + ligne e: option, c: console + c'est qui qui fait? + un fichier qui se nomme stdmenu.cfg + qui n'est pas présent dans ces sources mais dans celles de DFLinux + on n'y touche pas ce soir, donc il n'est pas dans ces sources + donc je termine sur la custo du menu + pour les couleurs, la disposition etc, franchement, c'est la galère car c'est tout en code de taré + (terme technique assumé) + donc faites simple, ce sera mieux :) + et puis, ce n'est pas non plus l plus important, le tout étant d'avoir la bonne langue au démarrage :) +``` +``` + on va attaquer maintenant le plus cool + la custo directe du système et du user + ça se passe dans /config/includes.chroot/ + ce dossier représente la racine du système installé :) + donc c'est le moment de se faire plaisir et d'y ajouter tout ce qu'on veut :) + avec quelques restrictions cependant + badadd n1 + les trucs écrasés .... + si vous ajoutez dans ce dossier, un élément qui appartient déjà à un paquet + il sera écrasé par le paquet lors du build + par exemple + vous voulez coller votre version de "ffmpeg" + mais si vous ajoutez + config/includes.chroot/usr/bin/ffmpeg + il sera écrasé par le vrai lors de l'install + vous pouvez coller le votre dans /usr/local/bin :) + il ne sera pas écrasé + et vous pourrez vous en servir sans soucis depuis un alias approprié :) + badadd n2 + le paquets perso + live-build gère ses paquets avec apt + donc dépendances, sécurité, mise à jour et tout ce qui va bien + live-build vous permet d'ajouter des paquets perso dans le dossier /config/packages + c'est super :) + mais attention + c'est dpkg qui installe les paquet de /packages + donc avec tout ce que ça implique :) + pas de suivi des mises à jour et pas de gestion des dep + donc faire attention + en fait apt télécharge les paquets, puis dpkg installe les paquets, dont ceux que tu as ajouté à la main + badadd n3 + les copyrights + gaffe si vous voulez diffuser votre live + ce que vous y ajoutez est de votre responsabilité + donc respectez les licences, créditez les auteurs, palcez des liens dans un README + bref + soyez responsables de ce que vous diffusez + je sais que ça fait un peu vieux con de dire ça + mais les débutants ou les curieux de linus méritent de recevoir un truc propre :) + linux* + ce n'est pas parce que c'est free et gratuit que ça doit être "passable" ;) + donc pour illustrer la custo + un exemple tout bête + les wallpapers perso :) + bah oui ... c'est quand même super cool d'avoir ses walls dans sa distro :) + vous pouvez git pull, et profitez de quelques walls de Péhä :) + un dernier stade avant de build :) + je vous laisserais ajouter ce que vous voulez dans le includes.chroot mais avant + un point sur les paquets selon ceux que vous avez ajoutés/retirés + si comme dans les sources, vous installé libdvdcss2 + vous devez ajouter des dépôts externes + c'est geekland à expliquer alors que c'est simple en voyant ... alors je montre :) + les paquets listés doivent être sur un dépôt + logique + si ils ne sont pas chez debian, il faut indiquer les dépôt + la clé d'authentification + soit en un commit pour faire simple + vous pouvez git pull et voir apparaître le dossier config/archives :) + 2 fichiers pour les dépôts videolan : un pour le liven et un pour le système installé + 2 fichiers pour la clé videolan : idem que pour l'autre :) + donc si vous voulez par exemple, le dépôt TOR + bah pareil, vous ajoutez les dépôts sous forme d'adresse + le fichier avec la clé dans le même dossier + avec les mêmes extensions *.binary pour le live et *.chroot pour le système installé + donc c'est fini pour la custo de base ... +``` +``` + pour un premier build fonctionnel , pas de custo du user en phase 1 + pourquoi + car il faut d'abord choper les valeurs par défaut avant de les modifier + les valeurs distribuées par le système que vous venez de créer + donc le meilleur moyen + c'est de build + lancer le live + personnaliser en live + puis faire une archive des mods + donc généralement + archiver le ~/.config + le ~/.mozilla sivous voulez mais attention à bien vider le cache et les pass !!! + puis récupérer ces archives pour les placer des includes.chroot/etc/skel afin de personnaliser votre utilisateur :) + et vous retrouverez vos préférences en live + autre solution + ... + pour la custo user + si vous utilisez le même environnement que celui qui sera dans le live + vous pouvez récupérer certaines de vos préférences directement + attention + pensez que le live , s'il est public, comportera vos préférences + donc pas de .ssh + PAS DE .SHH !!! + :D + bref + je ne peux pas lister Vos fichiers sensibles mais vous avez compris le principe :) + et c'est aussi pour ça que pour ce soir, je ne vous conseille pas de custo le user + autant vous concentrer sur les applications à installer +``` +``` + donc si vous êtes partant, on peut lb build :D + depuis les sources, vous pouvez envoyer la commande + sudo lb build + plus sûr + donc voilà, avec ces sources https://git.framasoft.org/arpinux/dfl-apprentissage , vous avez une armature pour un live simple sur xfce, que vous pouvez agrémenter avec le tuto live-build et faire votre distro + j'espère avoir été clair et simple + et que vous avez vu le processus en global + :) +``` +``` + pour ajouter des dépôts debian supplémentaires, comme les dépôts externes, tu places un fichier avec l'adresse dans /config/archives + tu n'as pas besoin de coller la clé :) + pour les préférences apt/pinning + tu ajoute ton preferences dans config/includes.chroot/etc/apt/preferences.d/preferences + et voilà :) + la ligne "experimentale" sera prise en compte lors du build et à l'installation et sera ajouté à /etc/apt/sources.list.d/experimental.list +``` +``` + donc si je je veux mettre un .mozilla + c'est dans config/includes.chroot/etc/skel/.mozilla + et il vient de ton système ? + ok, j'ai compris ça. de la clé live que j'ai testé tout à l'heure... + :) +``` +``` + donc quand tu veux ajouter une config dans le skeleton, tu recréer l’arborescence des fichiers si je comprends bien... + oui, comme si includes.chroot/ était la racine du système + sauf pour /home qui reste vide + c'est pour ça qu'on colle dans /etc/skel pour le user + ok... surtout que c'est un user live qui ne conservera rien... + enfin si la config reste pour les deux en live et après install + on peut activer la persistances des données, non? + oui, on peut aussi pré-configurer un 'vrai' user avec un login/pass etc, mais c'est un peu plus hard en config :) + et j'avoue que je suis pas fan de la persistance + rien de plus facile à perdre qu'une clé usb ... + donc je préfère le live 'pure' +``` +``` + Aïe et si l'écran se met en veille utilisateur: humain ? mot de passe? + live +``` + +## un essai de bidouille live sid +``` +#!/bin/sh +set -e +lb config noauto \ + --apt-indices "true" \ + --apt-recommends "true" \ + --apt-secure "true" \ + --apt-source-archives "false" \ + --architectures "amd64" \ + --archive-areas "main contrib non-free" \ + --backports "false" \ + --binary-images "iso-hybrid" \ + --bootloader "syslinux" \ + --clean \ + --debian-installer "netinst" \ + --debian-installer-gui "true" \ + --distribution "sid" \ + --system "live" \ + --iso-application "PengouinSid" \ + --iso-volume "PengouinSid" \ + --linux-package "linux-image" \ + --firmware-binary "true" \ + --firmware-chroot "true" \ + --source "false" \ + --security "false" \ + --updates "false" \ + --verbose \ + --win32-loader "false" \ + "${@}" +``` +``` + le live fonctionne + l'install aussi :D + erreur au chargement des noyaux + je continue quand même + ah .. il trouve pas de disque dur ... + ahhh, très bien :p + :/ + enfin, non, mais bon, t'as compris :D + oui :) + alors pour construire un live sid ... peut être passer par un live ç vide stretch, mais avec un hook, un seul, pour exécuter une dist-upgrade du chroot vers sid avant la fin du chroot :) + donc un installeur stretch, mais qui copie un système sid + parce que normalement, pour installer une sid, on prend la netinstall testing, on passe en mode expert install et on demande à choper la version unstable dans les options + mais il n'y a pas de live sid proprement dit + sid seul n est pas utilisable en tant que tel + y à pas asser de paquet + mais c'est marrant que live-build accepte de build en sid quand même + enfin "marrant" .... + une autre idée + choper ta config, mais en collant "stretch" + et en plus + dans config/archives + on rajoute la ligne des dépôts sid + :) + donc juste remplace "sid" par "stretch" dans auto/config + et ajouter dans config/archives + sid.list.chroot et sid.list.binary + avec deb http://ftp.fr.debian.org/debian/ unstable main contrib non-free + PengouinBSD: c est ça qui est drole + ah si + j'ai changé "netinst" par "live" pour l'installeur + arpinux, si je ne me trompe, ça va faire quand même une install qui dure 2 * + de temps, non ? + cad ? 2*+ de temps ? + beh, oui, y'a la phase d'install stretch puis sid + non + pas comme j'ai fait + pas de hook + en ajoutant la ligne sid dans archives + je dis à live-build de le prendre en compte directement dans le build + pourtant il récupère bien tous les packages en interrogeant les dépôts Sid ! + mais tout en précisant d'utiliser le système de base stretch (donc tous les paquets dispo) + l'option --distribution "stretch" indique à live-build de tout mettre en place avec les outils stretch + la ligne dans archives indique qu'il peut choper aussi des paquets de sid + ce n'est pas pareil que de dire directement à l'installeur de bosser sur sid + là il taf que stretch + et si il peut + il chope du sid + théoriquement, ça devrait marcher :SD + :D + il build là + il va bien chercher l'installeur chez stretch + build stretch/sid terminé + live fonctionnel + je tente l'install ?? + install lancée .... + pas de module noyau .... + ça commence mal.... + aucuen carte ethernet trouvée .... + bon bah non .... abort install + haha + à jouer avec stretch/sid alors que debian est prévu comme 'stable' ... jte jure ... + hihihihihihi + * PengouinBSD "love exciting way :p!" + ça t'amuse de me faire build nawak hein ???!!! + :D + YESSS! + XD + alors pourquoi ça ne fonctionne pas + si on utilise distribution "sid", il manque des paquets +``` diff --git a/mkdocs.yml b/mkdocs.yml index 824ba0a..0cc46ee 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -22,6 +22,7 @@ pages: - config: "live-build/config.md" - live-build/preseed-stretch.md - live-build/liens.md + - apprentissage: live-build/live-build-apprentissage.md - trucs: - trucs/iso-sur-usb.md - trucs/rmadison.md