Gérard Milhaud, Frédéric Bloise aka La F.I.R.M.E JeDDLaJ : le teaser Gérard Milhaud, Frédéric Bloise aka La F.I.R.M.E

La problématique Très grand nombre de postes de travail Forte diversité des architectures Configurations logicielles très changeantes dans le temps (formations, intervenants divers, etc.) Plusieurs OS différents, des doubles boot et... indigence des ressources humaines => gestion/supervision du parc = 90% de l'activité...

Un début de solution : Rembo Toolkit (1) PXE ! Exit disquettes et CD... Images disques stockées AUSSI en cache sur le disque local du client => réinstallation très rapide Répertoire partagé pour les images disques sur le serveur : pour un même OS, un fichier présent dans N images disque n'est stocké qu'une fois => grand nombre d'images facilement stockables

Un début de solution : Rembo Toolkit (2) Langage Rembo-C aux multiples primitives et API pour scripter le comportement d'une machine en mode PXE : tout devient possible (partitionnement, intervention sur le système de fichiers (FAT, NTFS, EXT2/3), accès au réseau pour récupérer des informations, envoi de mails, etc.) Possibilité d'images incrémentales... et donc de paquetages logiciels Multicast : déploiement d'une salle =~ déploiement d'une machine 23€/machine...

Mais, en vrai, c'est pas encore ça... (1) Visibilité du parc matériel (et surtout logiciel) limitée (Rembo-console...) Toute l'information sur le parc est sur le serveur Rembo sans moyen d'interrogation puissant/scriptable Manipulation des variables Rembo assez lourde (Rembo-console et clicofolies)

Mais, en vrai, c'est pas encore ça... (2) Création de paquetages logiciels contraignante (machine dédiée, nécessité de partir d'une image disque non modifiée) Pilotage du parc laborieux : pour ajouter/supprimer un logiciel d'un poste ou d'une salle, manipulations fastidieuses sous Rembo-console Finalement : 2 problèmes principaux Fonctionnalités présentes mais pénibles à mettre en oeuvre pour un usage quotidien Information insuffisamment accessible Pénibles à mettre en oeuvre car - la Rembo-console est lourdingue - il faut l'accès administrateur au serveur REMBO - on doit être sur le serveur Rembo, ou diffuser en remote la Rembo-console - l'utilisation de variables Rembo associées aux différentes machines ou groupes est pénible - on ne voit pas trop comment faire intervenir quelqu'un d'autre qu'un informaticien pour configurer quoi que ce soit sur le comportement des machines : intervention sur la valeur des variables !!! On est trop proche du programme Rembo-C...

02/2003 : We have a dream... Dis, tu trouves pas que ça serait terrible si on pouvait : piloter complètement le parc au travers d'une interface web (IW), et ce sans connaissance informatique ajouter/supprimer des logiciels d'une machine ou d'un groupe de machines d'un simple clic dans l'IW avoir une vue synoptique et configurable d'un simple clic de l'ensemble du parc via l'IW, des composants des machines aux logiciels installés en passant par les @ MAC et IP, etc. Se servir de tout ça pour avoir un inventaire matériel et logiciel complet et à jour

02/2003 : We have a dream (2) Dis, tu trouves pas que ça serait terrible si on pouvait AUSSI : Voir les choses de manière totalement modulaire : 1. on créerait une image disque de base seulement avec l'OS et les réglages voulus qui conviendrait pour toutes les machines d'architecture compatible 2. on créerait, par OS, des paquetages pour chaque logiciel voulu qui conviendrait pour toutes les machines sous cet OS 3. on piocherait par clic via l'IW dans ce réservoir d'images de base et de paquetages logiciels pour configurer toutes les machines du parc Ainsi, la sainte-quête-du-travail-minimum serait achevée : UNE SEULE installation de l'OS par architecture matérielle UNE SEULE installation d'un logiciel par OS UNE SEULE installation de l'OS par architecture matérielle : c'est bien sûr un plus pour windows (> 2000) seulement, car on n'a pas ce type de problème sous Linux. L'attachement au matériel n'est pas si fort sous Linux et n'empêche en aucun cas de booter une image disque si quelques drivers non adaptés sont installés en lieu et place des bons...

09/2003 : We make le dream vrai : JeDDLaJ is born (1) Pilotage complet du parc par l'IW : plus aucune connaissance Rembo nécessaire Oubliées, les variables Rembo et la Rembo-console : tout est inclus dans une base de données relationnelle MySQL qui décrit entièrement le parc Définition déclarative complète du parc matériel et logiciel via l'IW (les caractéristiques matérielles des machines sont auto-insérées dans la base à leur premier boot PXE) On adresse tous les problèmes liés à l'interface Rembo-console, la difficulté de vision/interrogation du parc. Dans la base on a, outre les config. Matérielles qui s'auto-insérent (du n° de série au nombre de ports USB ou de processeurs en passant par le type de RAM), les config. Logicielles, les appartenances des machines au groupes, l'état des machines, des logiciels, les logiciels, OS, disponibles, etc.

JeDDLaJ is born (2) La base est consultée/renseignée à la fois par l'IW et les scripts REMBO-C qui composent JeDDLaJ Création de paquetages logiciels depuis n'importe quelle machine du parc, sans réinstallation Création d'images de base depuis n'importe quelle machine du parc Les scripts REMBO-C vont interroger la base pour savoir quels logiciels il faut installer en fonction de la machine, du groupe de la machine, etc. Ils vont renseigner aussi la base en faisant évoluer l'état de la machine (de a_installer à installé par exemple) L'IW va permettre de consulter la base pour extraire toute information utile : « quels logiciels sont installés sur les PC linux de la salle 08 », ou « combien a-t-on de PC ayant moins de 128 Mo de RAM », etc. L'IW va renseigner la base en demandant l'installation de logiciels sur des machines, ou leur suppression, en partitionnant des disques durs, en ajoutant un OS sur un groupe de machines, en créant des groupes, en passant une machine en état création d'iamges de base, de packagesetc. Depuis la version chouia avant la 1.0, on s'affranchit de la machine dédiée pour créer les packages. On dispose d'une interface REMBO-C dédiée : il suffit via la base de mettre cette machine en état « Création de packages ». C'est un progrès colossal. Le package créé est ensuite immédiatement inséré dans la base et disponible pour toutes les autres machines sous le même OS... Pareil pour les images de base (état « Création images de base ») qui sont pareillement immédiatement insérées dans le serveur REMBO ET dans la base et disponibles immédiatement pour les machines dont l'architecture est adaptée.

JeDDLaJ is born (3) La saine quête est achevée... Après avoir créé une fois pour toutes ses images de base et ses paquetages logiciels, on va, via l'IW, et donc depuis n'importe où : 1. choisir une machine ou un groupe de machines 2. choisir une image de base parmi les proposées 3. choisir les logiciels voulus parmi la liste 4. rebooter la/les machine(s) 5. Et voilà. On a déployé dans la joie et du coup... On part à l'apéro une heure plus tôt !!! Les paquetages logiciels peuvent être par exemple l'ensemble de hotfixes depuis le jour de l'image de base, ou depuis le dernier package de hotfixes. Ainsi on fait le paquetages de hotfixes et on l'applique sur tout le parc d'un clic...

Donc finalement, JeDDLaJ, c'est quoi ? Pas facile à définir en quelques mots... On peut tenter : Un outil de pilotage/supervision de parc via le web ? Une base de données MySQL décrivant un parc informatique ? renseignée/consultée via une interface web dynamique exploitée/renseignée par un ensemble de programmes Rembo- C lancés par les machines du parc au boot PXE Un logiciel libre universitaire ? Un front-end web à Rembo Toolkit ? Un moyen puissant d'administrer un parc hétérogène, avec des configurations logicielles fluctuantes ? 9500 lignes de PHP, 3200 de Rembo-C ? Tout ça à la fois ???

Et qu'est-ce qu'il me faut, à moi admin Et qu'est-ce qu'il me faut, à moi admin. réseau, pour installer et utiliser JeDDLaJ ??? Des cartes réseaux PXE (ou des disquettes...) sur toutes les machines à gérer par JeDDLaJ Déclarer toutes ces machines dans le DNS Déclarer toutes ces machines en attribution d'@IP statique dans le serveur DHCP Un espace WEB avec PHP4 disponible (et EXPECT pour le module non fondamental mais bien pratique de connexion au serveur REMBO depuis l'IW) Un serveur MySQL accessible depuis cet espace web

Et qu'est-ce qu'il me faut, à moi admin Et qu'est-ce qu'il me faut, à moi admin. réseau, pour installer et utiliser JeDDLaJ ??? (2) Un serveur REMBO Toolkit (RT) Un pont ODBC entre le serveur RT et le serveur MySQL Lire la doc. à http://www.esil.univ-mrs.fr/~lafirme/website/rubrique.php3?id_rubrique=7 Télécharger la dernière version à cette même adresse ½ journée à 1 journée tranquille pour mettre tout ça en place Un hamac pour la sieste pendant que JeDDLaJ travaille...

JeDDLaJ : Résumé des features qui vont vous convaincre... (1) Auto-détection matérielle des machines Création de paquetages logiciels/d'images de base sur toute machine du parc Postinstall scripts associables aux OS et/ou aux paquetages logiciels Gestion du multi-boot Gestion des erreurs pendant l'installation Cadeau Linux : postinstall script (pour Debian, mais adaptable) d'ajout à la volée des bons modules kernel en fonction des composants détectés Auto détection avec insertion dans la base Multi-boot sans autre limite que la place disque pour les OS Gestion d'erreur : récupération des erreurs Rembo et mode Dépannage

JeDDLaJ : Résumé des features qui vont vous convaincre... (2) Gestion fine des groupes de machines Action possible sur une machine ou sur un groupe Examen graphique d'une machine, d'un groupe Copie de machine Calcul de l'image de base « la plus adaptée » Échange simple de paquetage ou d'images de base avec d'autres JeDDLaJeurs Cadeau Windows : images génériques Groupes peuvent inclure d'autres groupes avec héritage des propriétés entre groupes inclus et incluant Action sur un groupe : par exemple ajouter supprimer des softs Copie de machine : utile lors de l'arrivée d'une vingtaine de machines identiques : on n'en boote qu'une, puis on copie (les champs identifiant de manière unique la machine ne sont pas copiés : @Mac,@ ip, n°série, etc.) Pour une nouvelle machine : par rapport à la signature REMBO, on propose les images de base qui s'approchent le plus de l'architecture de la nouvelle machine (X composants identiques sur Y...) Facile d'exporter des paquetages, des OS vers d'autres JeDDLaJeurs : à terme plus besoin d'installer aucun logiciel, si la communauté de JeDDLaJeurs grossit suffisamment Images génériques = images débarrassées de toute spécificité matérielle mais embarquant toutes les préférences systèmes logicielles désirées (droits, fichiers présents, SP, etc.). Elles permettent lors d'une install sur une nouvelle architecture de limiter l'effort à l'install des drivers...

Ce que JeDDLaJ ne fait pas... encore Délégation d'administration par authentification de sous-ensembles du parc Interface web d'import/export de packages d'autres JeDDLaJeurs Véritable « versionning » des logiciels (en tant que relation dans la BD) Gestion des dépendances entre paquetages logiciels Versionning : actuellement, c'est la valeur du champ nom de la table logiciel qui est utilisé pour savoir si deux entrées correspondent au même logiciel et la valeur du champ version pour savoir quelle est la version la plus récente (or entre 2000 et XP par exemple, il est difficile d'ordonner correctement a priori.... Il faudrait qu'existe au niveau relationnel un « ordre » des versions. Ca permettrait par exemple de faire des choses comme « Upgrade à la dernière version tous les logiciels installés sur la machine X, ou le groupe G » A vos claviers : vous pouvez contribuer, c'est libre...

Ce que JeDDLaJ ne fera peut-être jamais... JeDDLaj hérite des limitations de REMBO... Pas de connaissances des systèmes de fichiers autres que FAT, FAT32, EXT[23]FS => images monolithiques pour tout autre OS que Windows et Linux Pas de possibilité de packager des logiciels Linux .deb ou .rpm (problème plus général des fichiers modifiés par plusieurs packages...) Images RAW pour les OS « autres » Le problème des .deb, .rpm : si on package sur une machine mozilla.deb, le fichier de database gérant les .deb installés sera incrémenté de mozilla et tout irait bien si REMBO savait gérer ce type de modifications de fichiers binaires... mais il ne sait pas : il va juste embarquer dans le package le fichier de databases des .deb correspondant à la machine sur laquelle on a fait le package. Donc l'injection du package sur une autre machine va mettre Mozilla, certes, mais corrompre à jamais le fichier de database. Ce problème est en fait plus général : si un fichier est commun à plusieurs packages, la version de ce fichier finalement présente sur la machine installée est celle embarqué dans le dernier package chronologiquement installé. Rembo ne sait pas faire de la différence AU SEIN des fichiers, mais seulement au niveau systèmes de fichiers : fichiers en plus, fichiers en moins