NAME

edix_developpeur - Pratique de développement du système edix.

INTRODUCTION

Chaque développeur de edix travaille sur une machine dont le système d'exploitation est un unix. Il doit avoir accès au serveur nastar. Il clone le projet git edix sur sa machine unix (la machine hôte) et télécharge le fichier image edix-57G.img. Le développement passe ensuite pour l'essentiel par

*
l'enrichissement du projet git (notamment des pages de manuel et des scripts de mise à jour) ;
*
le test des mises à jours par chroot sur le fichier image~;
*
la création et la publication de nouvelles versions du fichier image (qui sert de base à tous les types d'installation).

Dans ce qui suit, on admet que sur la machine hôte, le développeur à le nom d'utilisateur lamenaire.

CLONAGE DU PROJET edix

Admettons que le développeur souhaite installer cloner edix à la racine de son compte sur la machine hôte : 

lamenaire:~ $ git clone nastar:/nastar/git/edix.git
A l'échelle du système unix de la machine hôte, il doit ensuite déclarer une variable d'environnement EDIX_DEVELOPPEUR qui contient l'adresse de ce répertoire. Sur gentoo par exemple : 
lamenaire:~ $ doas echo "EDIX_DEVELOPPEUR="/home/lamenaire/edix" > /etc/env.d/999edix_developpeur
lamenaire:~ $ doas env-update && source /etc/profile
En tout cas, dans tous les shells la commande 
lamenaire:~ $ echo ${EDIX_DEVELOPPEUR}
doit renvoyer (dans notre exemple) 
/home/lamenaire/edix
Cette variable d'environnement sera utilisée par les scripts de soutien au développement.

TELECHARGEMENT ET UTILISATION DU FICHIER IMAGE edix-57G.img

Voir la page de manuel edix_chroot(8f)

MISE A JOUR GENTOO COMPLETE ET DEPLOIEMENT D'UN NOUVEAU FICHIER IMAGE

Voir la page de manuel edix_developpeur_mise_a_jour(8f)

VOIR AUSSI

edix(8f), cle-usb-bootable-gentoo(7f), systeme(7f), unix(7f), gentoo(7f)

POUR MEMOIRE

LA MACHINE DE REFERENCE

Il y a une machine de référence. C'est sur cette machine qu'est développé le système edix. On peut donc retenir qu'à tout instant edix est défini comme le système d'exploitation présent sur cette machine de référence. La définition de cette machine se résume à un ensemble de fichiers de configuration. Il est donc possible pour plusieurs administrateurs de disposer de la même machine de référence (en tant qu'iso sur leur machine de travail) et de faire évoluer cette référence en parallèle. Pour cela, les fichiers de référence sont partagés sur un dépot git. Ce dépot git edix est accessible, en lecture seule, à l'adresse suivante : 

  https://nastar.laplace.enseeiht.fr/git/edstar/edix.git
Pour le faire évoluer, les développeurs devront avoir un accès sur le nastar et accéder au dépot via ssh : 
  nastar:/nastar/git/edix.git

LES MACHINES CLONES

Il y a ensuite des machines clones. Ces machines sont typiquement celles que nous utilisons dans la salle de permanence (voir edstar_permanence(7f)), ou celles que nous déploirons dans les salles de travaux pratiques. A tout moment elles doivent être prêtes pour une séance de travail collectif. Toute machine clone doit avoir un numero IP fixe. Lors de son installation, son serveur ssh est activé et configuré pour n'accorder l'accès qu'à un ensemble de machines (à IP fixe) depuis lesquelles les gestionnaires du parc feront les mises à jour.

LES MACHINES FILLES

Les autres machines sont des machines filles. A partir de la machine de référence, ce sont des machines qui sont chacune gérées par un gestionnaire indépendant, sans objectif collectif. Reste collectif le partage de la base de référence. Donc à tout moment ces machines doivent également pouvoir être mises à jour au sens d'edix, c'est à dire être prêtes pour une séance de travail collectif. Par contre, le gestionnaire fait évoluer sa machine en fonction de ses besoins spécifiques en rajoutant des logiciels et des fichiers de configuration qui n'existent pas sur la machine de référence.

Pour qu'il soit possible de maintenir la connexion rigoureuse avec la machine de référence, le mode de gestion de ces machines filles doit être précisé de façon très étroite : tout doit être possible, mais en archivant chaque étape de gestion de la même façon que sont archivées les étapes de gestion de la machine de référence de façon à permettre d'identifier et de préserver les différences lors des mises à jour de la référence. Il faut donc un projet par machine fille déposé sur un dépot git. Ces dépots git seront edix_fille_prenom_nom sur le git de edstar ou sur le git de edstaretudiant. Ces projets sont publics de façon à ce que d'autres gestionnaires puissent s'inspirer des solutions spécifiques adoptées sur chacune des machines filles existantes. La partie privée de la définition d'une machine fille est à écrire dans un projet spéparé nommé edix_fille_prive_prenom_nom.