====== Présentation de Ndkm ====== **Ndkm** est un acronyme pour **N**asgaïa **D**evelopment **K**it **M**aker (créateur de kit de développement de Nasgaïa). Il s'agit d'un générateur automatisé de ce qui est appelé le //devkit//. ==== Qu'est-ce que le devkit ? ==== Historiquement, Nasgaïa a été fondée à partir d'une LFS ([[http://linuxfromscratch.org|Linux From Scratch]]), générant un système minimal mais utilisable pour ajouter de nouveaux logiciels. A partir de ce système minimal, la génération des premiers paquets via Ncooker peut-être effectuée. Le //devkit// est un ensemble de **nba**s constituant un système Nasgaïa ne contenant que ce qui est nécessaire pour créer d'autres **nba**s. Il s'agit donc de la première pierre d'une release de Nasgaïa. Comme une release normale constituée de **nba**s, le //devkit// peut être installé depuis un autre système si Ncooker est lui-même disponible ; cette propriété permet à quelques personnes de créer cette base, et une fois fait, d'en faire profiter au maximum de personnes pour qu'ils puissent créer des nbuilds/nbas depuis un système Nasgaïa minimal. Jusqu'alors, le devkit était fabriqué //à la main//, en suivant plus ou moins la procédure LFS. Ce travail étant fastidieux, et la méthode peu propice au travail collaboratif, l'idée était d'automatiser tout ça : **Ndkm est né**. ==== Comment ça fonctionne ? ==== **Ndkm** est un ensemble de scripts shell fonctionnant de manière automatisée, grâce à un fichier de configuration lu au démarrage. Il automatise non seulement le lancement des procédures de compilation, mais aussi toute la mise en place de l'environnement nécessaire à la bonne marche de cette procédure. Cela inclut les variables d'environnement qui doivent être ou ne doivent pas être définies, le téléchargement et la décompression des sources ou l'entrée dans le ''chroot'' de manière sécurisée. Le but étant de réduire au maximum les chances de mauvaises manipulations de la part de l'utilisateur. L'utilisateur qui a bien paramétré **Ndkm** n'a qu'à lancer l'outil et le laisser travailler ; la seule question posée est la demande du mot de passe root au démarrage (car **Ndkm** automatise également la nécessité de passer root lorsque c'est nécessaire). Lorsqu'il est lancé, le script tentera d'aller jusqu'à la fin, c'est à dire le lancement séquentiel de Ncooker pour générer les **nba**s. En cas d'erreur à n'importe quel moment, il s'arrête, indiquant la raison de l'échec. De toute manière, tout est tracé dans des fichiers de log, aucune information concernant l'erreur ne peut donc être perdue. L'intérêt majeur est qu'en cas d'erreur, le processus reprendra là où il s'est arrêté, et non au début - un gain de temps non négligeable, surtout lorsque la création du système temporaire a déjà été effectuée. **Ndkm** suit dans les grandes lignes la procédure du [[http://www.linuxfromscratch.org/lfs/view/development/index.html|LFS Book, version développement]]. Suivre la version développement plutôt que la version stable apporte un plus, car cela permet de toujours être au fait des dernières évolutions. Ce principe a été utilisé au tout début de **Ndkm** (alors appelé **ngalfs**) pour intégrer de base les noyaux de la série 2.6 et remplacer //devfs// par le couple //hotplug/udev//. Comme cela ne s'invente pas (ou il faut y passer du temps), autant utiliser ce qui a déjà été fait, et les développeurs de LFS nous ont montré à plusieurs reprises qu'ils étaient digne de confiance. ==== Pourquoi un outil complet ? ==== Plutôt qu'une simple procédure ou le lancement direct de Ncooker ? ... Eh bien, il faut comprendre un peu comment fonctionne le principe LFS et les avantages que cela apporte, au prix d'une certaine complication (qui a induit la création de **Ndkm**). Il existe également d'autres avantages qui ne sont pas forcément évident de premier abord. === Isoler pour faire propre === Etant donné que le **devkit** est la base d'un système Nasgaïa GNU/Linux, il se doit d'être aussi clean que possible (ça vient aussi du fait que j'aime avoir des choses carrées). Pour contruire un **devkit**, il faut compiler des paquets, via ce qu'on appelle communement une ''toolchain'', et l'un de ces paquets, très important, est la **libc** (la glibc en fait, puisqu'on tourne autour de GNU). Si on compile directement les paquets depuis le système hôte (celui sur lequel les commandes de construction sont lancées), il y aura dans les logiciels résultants des références à cette **toolchain**, qui je le rappelle, se trouve sur le système hôte. Lorsqu'on passera dans le devkit par un **chroot**, il y a un risque assez fort d'incompatibilités entre les deux système, et le devkit ne sera pas utilisable. La première solution était de construire un système temporaire compilé statiquement (donc sans référence à la toolchain de hôte). Le problème, c'était d'une part que les binaires statiques sont énormes, et d'autre part cela polluait le système cible (car des fichiers se trouvent dans le devkit avant qu'on ne le crée réellement). Pour y remédier, quelques auteurs du projet LFS ont eu une idée de génie qui certe demande plus de temps, mais permet de contrer les deux problèmes liés à la compilation statique, tout en fournissant une isolation du système cible vis à vis de la toolchain hôte. Le principe est simple (mais la réalisation plus complexe) : on ne crée pas le système temporaire directement dans le répertoire cible, mais dans un sous-répertoire (baptisé ''tools''), et on crée sur le système hôte un lien à la racine vers ce ''tools''. Ce cette manière, le système hôte et la cible ont tous deux un répertoire ''tools'' représentant la même chose. On commence à créer une toolchain basique (binutils + gcc) dans ''/tools'', puis on ''ajuste'' cette toolchain pour préprer l'isolation (pour que tout pointe vers /tools), ce qui demande une recompilation de binutils et gcc. On compile ensuite les paquets norlamenent dans /tools. A la fin, depuis le chroot qui contient le mini-système tools, on réajuste cette toolchain pour cette fois tout faire repointer sur la racine, et on recompile enfin binutils et gcc, puis glibc à la racine. De ce fait, le chroot (futur devkit) est autonome, indépendant binairement du système hôte, et les fichiers qui ont été placés à la racine (binutils, gcc et glibc) seront écrasés par les mêmes fichiers installés par Ncooker. On recompile binutils, gcc et la glibc à la racine afin que les futurs autres logiciels n'aient pas de référence au répertoire /tools (même principe que l'isolation depuis le système hôte, mais dans l'autres sens). On peut enfin lancer Ncooker pour créer les nbas. Ce jeu de nbas sera ensuite regroupé pour être installé sur d'autres machines : on a notre devkit. === Arrière-plan et traces === Comme déjà expliqué, **Ndkm** commence par regrouper des informations depuis un fichier de configuration, puis se lance de manière non-interactive (sauf pour demander le mot de passe root au début), du début jusqu'à la fin. Ce processus peu être très (très très) long suivant la configuration de l'hôte. Il est donc essentiel de pouvoir lancer **Ndkm** et de ne plus s'en soucier jusqu'à la fin, où jusqu'à ce qu'une erreur survienne. Dans ce dernier cas, il faut pouvoir identifier l'erreur facilement, et si cette erreur est due à autre chose effectué en amont, de pouvoir remonter la chaine. C'est un des autres grands principes de **Ndkm**. Il génère un fichier central de traces plus un fichier de log par paquet construit (évitant ainsi un seul fichier de plusieurs dixaines de mégas). Par ailleurs, **Ndkm** ne fait pas que lancer des commandes préenregistrées. Il effectue bien d'autres opérations toutes plus rébarbatives les unes que les autres : * téléchargement et vérification par somme md5 des fichiers d'archives sources nécessaires * création de fichiers prédéfinis (comme /etc/passwd, /etc/nsswitch.conf) * récupération et mise à jour de Ncooker sur son dépot subversion * lancement séquentiel et automatisé de Ncooker pour chacun des nbuilds * création d'un tarball du chroot ''clean'' (sans nbas) et à la fin d'un tarball contenant le jeu de nbas. === Futures releases === Il existe un autre intérêt à un outil tels que **Ndkm** pour les futures releases de Nasgaïa. En effet, l'outil étant assez générique, il pourra être adapté lorsqu'on aura besoin de refaire un devkit : * les définitions de paquets sont centralisées dans des fichiers de configuration * les modifications de fonctionnement de Ncooker seront faciles à transposer, dans la mesure où c'est également centralisé. Il est d'ailleurs fort probable que **Ndkm** soit lancé depuis une Nasgaïa pour la prochaine release ;-)

 
ndkm_presentation.txt · Dernière modification: 11/09/2007 16:14 par riri
 
Recent changes RSS feed Creative Commons License Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki