Le déploiement d'un site peut s'effectuer de la manière suivante :
- Description des postes (clients et/ou serveurs) dans le langage de description YaKa.
- Ajout des fonctionnalités spécifiques à chaque poste (.config du noyau, images Windows, QNX, etc)
- Lancement de la commande YaKa qui va générer les paquets depuis les sources si ces derniers ne sont pas déjà générés et configurer automatiquement les serveurs PXE/DHCP/TFTP pour l'installation réseau (ou alors fournir des ISO pour une installation par CD/DVD)
- Lancer les serveurs grâce au script start-daemon.sh
- Redémarrer l'ensemble des postes décrits et attendre que YaKa les installe
- La garantie d'avoir des postes identiques si telle est la demande (en terme logiciel)
- La réinstallation quasi immédiate d'un poste à son état initial
- La mise à jour de l'ensemble du parc aisée
- L'aspect orienté service de la distribution qui permet de très rapidement déployer des fonctionnalités (service de jonction NIS/SAMBA, LDAP/SAMBA, MAILHUB, etc) avec un nombre réduit de configurations à donner (bien que le langage permette à un utilisateur de redéfinir tous les fichiers de configuration).
- Le support du multi-boot (lilo) dans le langage.
La question qui se pose dorénavant est de savoir si YaKa est stable pour des mises en production. La réponse est OUI. La distribution est, en effet, en production à l'ENSIIE depuis avril 2004 (un parc d'environ 120 postes clients et 10 serveurs).
La distribution est testée avec différentes configurations :
- Une version standard pour les cours
- Une version avec une réduction des accès réseaux pour les contrôles
- Une version légère pour les cours système
Il existe également un packaging dit "office" intégrant le minimum mais l'utile pour une utilisation office de Linux (Firefox, Thunderbird, gestion d'archive, IceWM avec un thème simple et intuitif, gmplayer, etc).
Le projet compte actuellement se développer et cherche pour cela des personnes intéressées pour contribuer :
- Développement
- Correction de la documentation en anglais
- Utilisateurs (la distribution peut être utile à partir d'un très petit nombre de postes)
Pour plus d'informations rendez vous sur la canal #yaka sur le serveur IRC irc.iiens.net (port 6667 ou port 7000 en ssl)
Aller plus loin
- Le site de la distribution (379 clics)
- Ecole Nationale Supérieure d'Informatique pour l'Industrie et l'Entreprise (210 clics)
# IACA
Posté par Adrien BUSTANY (site web personnel) . Évalué à 1.
Note, ce système est extrêmement facile à berner, il suffit de renommer n'importe quel programme en winword ou mspaint, et hop roule ma poule :)
[^] # Re: IACA
Posté par Vincent LE LIGEOUR . Évalué à 3.
# Quelques explications s'il vous plait ?
Posté par freeze . Évalué à 3.
En allant me balader sur le site officiel, j'ai lu ça :
«no package update, no incremental addons : In YaKa environment, systems are generate as a whole, updates can only be done by regenerating a new system and dowloading it.»[1]
Euh c'est une réinvention de windows ? quel est l'intérêt (sérieusement) ?
De même j'ai lu que certaines choses sont liées statiquement:
«YaKa links statically some of its commands, so in the below list of required tools, the static libraries are needed. The main of those are: libc.a, libm.a, libcrypt.a, libpthread.a libfl.a, .... »
Donc même question, quel intérêt de se lier statiquement partout ? Dans le système unix, ce que j'aime bien, c'est justement que les libs soient partagées ... Qu'apporte une compilation statique ?
Et finalement:
«15 giga bytes are required to compile the YaKa tools, to make the binaries of the YaKa distribution and to generate the Target System of the examples presented in the section "Making LAN descriptions". You must add add 10 giga bytes if you intend to compile the openoffice package instead of using its YaKa binaries.»[2]
C'est plus une distribution orienté réseau la ... c'est un énorme fourre-tout ... j'espère que je me trompe, merci de me corriger (gentiment, quand même ;) )
[1]: http://yaka.ensiie.fr/yaka-dist.html
[2]: http://yaka.ensiie.fr/tutorial.html#tut-inst-requirement
[^] # Re: Quelques explications s'il vous plait ?
Posté par Aldoo . Évalué à 3.
Ensuite pour les autres choix je ne sais pas... si ce n'est que ne pas installer de système de paquetage sur les postes de travail, c'est toujours ça de moins à gérer. Et ça permet d'avoir des postes de travail ou seul les logiciels de productivité sont installés, et non les outils d'administration du poste. La mise à jour suppose de tout réinstaller, mais bon, j'ai vu faire dans mon ancienne fac, où le choix de l'OS (Red Hat ou Win 2K) sur les postes de travail se faisait lors du boot par la carte réseau, qui téléchargeait alors l'image du système : 5 minutes montre en main pour DL+install (gigabit ethernet). Donc franchement ce n'est pas un drame de tout réinstaller. En plus ça permet de repartir sur une base saine.
Attention, on parle bien de postes de travail, qu'on peut se permettre de rebooter pendant la nuit, et non de serveurs avec des exigences de disponibilité.
[^] # Re: Quelques explications s'il vous plait ?
Posté par Vincent LE LIGEOUR . Évalué à 6.
Une fois cette distinction faite plusieurs points sont à aborder :
1. Ne pas se préoccuper d'un système de paquetage : Ceci est motivé par le fait que lorque l'on fait une mise à jour, il faut la faire sur l'ensemble des postes et que de toutes facon à la prochaine installation le serveur tftp doit être à jour : donc autant faire la mise à jour directement sur le serveur (de plus gérer des updates/dependances/fichiers de configuration à la volée est un travail fastidieux et non automatisable (je parle en tant qu'utilisateur chevronné de Gentoo ou un "-5" est toujours une mauvaise idée). Il faut noter que bien entendu les paquets compilés une première fois ne le seront pas par la suite.
L'avantage par rapport à Windows est bien sur que les paquets sont installés un à un et avec des configurations dépendantes de la machine cliente.
2. Concernant les librairies statiques il me semble que ce n'est plus d'actualité (mais je devrais vérifier). A la base il me semble que c'était pour s'assurer que rien dans le système de bootstraping de l'environement dans lequel on va tout compiler (ouf c'est long comme phrase) sur le serveur n'ai de lien en dehors de sa prison chroot. De plus sur les installations des clients les librairies dynamiques sont installées uniquement quand ceci est necessaire (grâce aux fonctions de la libelf).
3. Concernant la place necessaire évaluée à 15Go c'est la place pour compiler/deposer l'ensemble des paquets supportés par la distribution (3 version de GCC, kde, openoffice, firefox, thunderbird, ennemy territory, etc.). Ensuite il n'est pas obligatoire d'utiliser tous ces paquets (et il ne seront donc ni installés ni compilés). Pour ce qui est de openoffice il existe un flag dans les paquets qui nous permet de dire si tel ou tel paquet doit générer un tar.gz de ses binaires, c'est la raison pour laquelle on peut utiliser openoffice sans forcement le compiler (et si l'on veur le compiler il faut rajouter 10Go ... je sais mais c'est pas ma faute :) ). Les paquets binaires sont fournis pour la glibc 2.2, 2.3 et 2.4 (et j'espère bientôt la 2.5).
Concernant les installations nous avons fait un test récemment d'une réinstallation complête d'une machine d'enseignement (avec openoffice, thunderbird, firefox, et, etc.) Il faut 5 minutes montre en main sans utiliser le yaka-fs (voir plus bas) et l'installation d'un serveur est quasi instantanée (280 Mo décompressés sur le disque dur).
A propos du yaka-fs il s'agit d'un pseudo-système de fichier. En fait dans chaque paquet il est possible d'indiquer, fichier par fichier, si ce dernier est installé sur la machine ou distant. Pour le procédé distant, le fichier en local est un lien vers un disque NFS monté, en cas d'utilisation, le NFS le télécharge et le mets en cache. Un démon tournant sur la machine s'occupe de scruter ces fichiers et de remplacer ces derniers par le fichier s'il a été utilisé. Bien entendu ce système de fichier est totalement transparent pour l'utilisateur la distribution prenant tout en charge pour la configuration.
J'espère avoir répondu aux questions posées.
Vincent
[^] # Re: Quelques explications s'il vous plait ?
Posté par freeze . Évalué à 2.
(Merci au moinsseur initial...)
Mais en quoi est-ce différent d'une Gentoo avec un petit outil de type rsync (avec surement des fonctions supplémentaires) ?
En fait, j'ai du mal à comprendre pourquoi faire une distribution spécifique pour ça ... un outil de synchro n'est vraiment pas suffisant ?
[^] # Re: Quelques explications s'il vous plait ?
Posté par Vincent LE LIGEOUR . Évalué à 1.
Le premier point est que nos paquets sont différents de ceux d'une distribution standard (car configurant automatiquement, en fonction de chaque poste, les fichiers de configuration, en fonction de variables globales au système ou spécifique à l'hote). Nous aurions donc dans tous les cas du redéfinir une partie du paquet.
Or il est hors de question de gérer au sein de la distribution même, une telle quantité de paquets (en gros ne pas passer son temps a faire de la compatibilité entre paquets etc). De plus le fait d'être dépendant d'une tierce partie est plutôt embetant pour les tests de regression (actuellement il faut un peu moins de 24h pour recompiler l'ensemble de la distribution).
Il existe des softs permettant de faire la syncronisation de différentes machines avec des configurations, mais ceci est systematiquement des rustines sur d'autres systèmes de paquetage ou alors non disponible en GPL.
Enfin pour plus d'informations un "papier blanc ?" est en cours de rédaction afin de résumer l'état de l'Art dans le domaine et bien décrire le positionnement de la distribution/langage YaKa.
[^] # Re: Quelques explications s'il vous plait ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Cela me parait un sacré boulot.
"La première sécurité est la liberté"
[^] # Re: Quelques explications s'il vous plait ?
Posté par Vincent LE LIGEOUR . Évalué à 1.
Il suffit de prendre ses amis aimant une distribution particulière ... disons Gentoo, ensuite on élimine ceux qui ne font pas d'ebuild et/ou qui ne postent pas de bugreport ..... et on arrive très vite à un chiffre qui n'est presque plus strictement positif ...
Et même si on en trouve un qui le fait, cela reste un éleve, et il peut très bien arreter du jour au landemain. Donc la meilleure solution est de se concentrer sur le maintient des 90% des paquets qui servent pour 99% des utilisations :)
[^] # Re: Quelques explications s'il vous plait ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
- le fait d'être à jour
- la qualité
- la quantité
En général, une distrib n'est bonne que dans 2 points sur 3.
Si j'ai bien compris vous avez sacrifier la quantité.
"La première sécurité est la liberté"
[^] # Re: Quelques explications s'il vous plait ?
Posté par Vincent LE LIGEOUR . Évalué à 2.
Pour la qualité c'est vraiment l'axe principal, avec l'aspect service (par exemple pour monter un service NIS/SAMBA ou LDAP/SAMBA les configurations sont totalement paralelles, ce qui permet de migrer facilement de l'un à l'autre).
[^] # Re: Quelques explications s'il vous plait ?
Posté par ragoutoutou . Évalué à 1.
Le choix de mettre à jour les postes de travail ou de les réinstaller systématiquement est un choix qui revient aux gestionnaires du parc, et chacune de ces optiques peut être motivée par des éléments comme la politique de sécurité, la capacité du réseau et des serveurs, la politique de gestion d'énergie, ...
Je ne vois pas en quoi ne pas avoir ce choix est un point positif.
Ce sont les outils qui doivent s'adapter aux besoins, pas l'inverse.
Sinon, il semble que le processus de génération d'image soit tout de même intimement lié à la distribution YaKa, donc cet avantage semble tomber dès qu'on utilise une autre distro que YaKa...
D'où une grande question: quel est l'intéret de YaKa si on veut utiliser RedHat/Fadora/SuSE/Debian/... comme distribution au lieu de la distribution intégrée à YaKa?
[^] # Re: Quelques explications s'il vous plait ?
Posté par Vincent LE LIGEOUR . Évalué à 2.
Je dirais relativement faible, l'avantage de la YaKa intervient surtout dans le fait que la configuration de chaque poste est intégré aux langage et que le même langage décrive à la fois les aspects matériels et logiciels. Ceci permet que chaque package puisse avoir une configuration spécifique à chaque poste client sans pour autant devoir le dupliquer (cf l'exemple plus bas).
Ensuite la distribution peut installer des images/tar.gz de distribution (Windows, QNX, debian, etc) mais il est évident que l'on perd une partie de l'intéret de la distribution (même si cela reste possible).
Pour l'exemple prenons le cas de firefox, en effet sur un réseau, tous les postes n'ont pas forcément le même proxy http, ou ftp etc. La distribution permet de fournir un fichier de configuration firefox en fonction de la valeur d'une variable du langage (qui sera la même utilisée pour wget, opéra, etc). Ceci n'est pas possible avec une distribution classique. Il est de même possible de rentrer l'ensemble des postes dans /etc/hosts et ceci de façon dynamique (car la distribution à connaissance de l'ensemble des hôtes possibles).
[^] # Re: Quelques explications s'il vous plait ?
Posté par ragoutoutou . Évalué à 3.
Sinon, une intégration avec le système Stateless de Fedora/RedHat est-elle envisageable/possible?
[^] # Re: Quelques explications s'il vous plait ?
Posté par Vincent LE LIGEOUR . Évalué à 1.
Ai-je répondu à la question ?
Vincent
[^] # Re: Quelques explications s'il vous plait ?
Posté par ragoutoutou . Évalué à 2.
[^] # Re: Quelques explications s'il vous plait ?
Posté par Vincent LE LIGEOUR . Évalué à 2.
[^] # Re: Quelques explications s'il vous plait ?
Posté par Fabien Engels . Évalué à 2.
[^] # Re: Quelques explications s'il vous plait ?
Posté par Aldoo . Évalué à 2.
Si tu veux te renseigner un peu plus, il s'agissait des postes de l'IFSIC de l'université de Rennes I.
Mais bon je ne pense pas que cette solution ait quoi que ce soit d'exceptionnel : boot PXE, téléchargement et installation d'image disque. Simple et efficace (si le réseau est rapide), ou comment passer une salle de TP de windows à linux en un clin d'½il et vice-versa sans dual boot, et avec une config toujours propre.
[^] # Re: Quelques explications s'il vous plait ?
Posté par Fabien Engels . Évalué à 2.
# à promouvoir
Posté par Alex G. . Évalué à 3.
Avez vous pensé à faire la promotion de votre système auprès de SS2L et auprès de l'Adullact. Je pense que ce genre d'outils est vraiment ce que rechercherait beaucoup de grosses administrations (je parle en connaissance de cause) Bien sur ceci supposerai une migration à Linux mais justement, ce peut être un argument à faveur.
[^] # Re: à promouvoir
Posté par Vincent LE LIGEOUR . Évalué à 2.
En fait c'est un peu le but de cet article. Nous avons déjà des idées de projets se basant sur cette distribution et des idées de plans de financement sur différents points. Même si le système est et restera GPL, je pense pour ma part (avis personnel) qu'il y a la place pour gérer/vendre des services basés sur cette distribution (même si l'administration ne veut pas migrer il reste la possibilité de réinstaller des Windows tout en mettant déja toutes les briques pour installer des Linux, voire installer les Linux en multi-boot).
En fait nous cherchons des personnes avec la volonté et les capacités de promouvoir la distribution/langage.
Merci pour l'Adullact je n'y avais plus pensé et je vais voir ce que je peux faire.
Vincent
# Quelle capacité pour le serveur ?
Posté par ZeroHeure (site web personnel) . Évalué à 2.
Mais les petites structures n'ont pas de gros matériel. Donc à partir de quelle "taille" (processeur, mémoire) un serveur convient-il ? et avez-vous fait des tests d'installation sur un réseau 100 mégabit ? et sur 10 ?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Quelle capacité pour le serveur ?
Posté par Vincent LE LIGEOUR . Évalué à 2.
Pour l'ENSIIE (~150 machine soit environ 1000 hôtes différents (de mémoire)) la machine est un bi-P4 avec 2Go de RAM (le process en prenant 1Go à la toute fin de la génération).
Un simple P4 avec 1Go de RAM est AMPLEMENT suffisant pour une petite structure.
Pour le réseau l'ENSIIE à été un temps en 10Mb et ca passait (même si les installations pouvaient prendre du temps, d'ou le developpement du YaKa-FS). Mais ils est clair que le 100Mb c'est mieux (5 minutes pour l'installation complete d'une machine avec pleins de choses, quelques secondes pour une serveur).
Dans la documentation il y a une présentation en français qui repend cela :
réinstallation d'une salle en 10Mbits (16 machines) : 25 minutes
réinstallation d'une salle en 10Mbits (16 machines) en YakaFS : 5 minutes
On va sans doute essayer de travailler sur du téléchargement distribué (bittorrent, etc) mais c'est juste au stade d"étude.
[^] # Re: Quelle capacité pour le serveur ?
Posté par ZeroHeure (site web personnel) . Évalué à 1.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Quelle capacité pour le serveur ?
Posté par ragoutoutou . Évalué à 3.
Pour déployer un système grid, par exemple...
[^] # Re: Quelle capacité pour le serveur ?
Posté par Vincent LE LIGEOUR . Évalué à 2.
[^] # Re: Quelle capacité pour le serveur ?
Posté par Yth (Mastodon) . Évalué à 3.
Par contre faut éviter le yaka-fs là, sinon sans connexion internet c'est foutu :p
Et même sur des connexions assez classiques ça risque d'être moins long que de faire une vraie install...
Tu m'intéresses Yoda :)
Yth.
[^] # Re: Quelle capacité pour le serveur ?
Posté par Vincent LE LIGEOUR . Évalué à 1.
[^] # Re: Quelle capacité pour le serveur ?
Posté par Yth (Mastodon) . Évalué à 3.
Cette histoire d'installation par internet, c'est un cas prévu dans Yaka ? Parce qu'on ne peut plus se reposer sur du PXE et du tftp, il faut avoir une base en local sur la machine cliente, qui va chercher les infos de mise à jour (ou de yaka-fs) à distance.
La base existe, ou c'est une excellente idée qui n'attend que des contributions ? ^^
El Yth.
[^] # Re: Quelle capacité pour le serveur ?
Posté par Vincent LE LIGEOUR . Évalué à 1.
Donc la base existe il suffirait de rajouter quelques fonctionnalités dans l'installeur je pense.
# yaka
Posté par farib . Évalué à 1.
[^] # Re: yaka
Posté par Vincent LE LIGEOUR . Évalué à 2.
[^] # Re: yaka
Posté par farib . Évalué à 2.
[^] # Re: yaka
Posté par Vincent LE LIGEOUR . Évalué à 1.
# moi j'aime
Posté par mornik . Évalué à 3.
Je poste juste pour vous souhaiter bon courrage et bonne chance.
# Package "office"
Posté par Vincent LE LIGEOUR . Évalué à 1.
pour ceux qui se demandent à quoi peut ressembler les package "office" :
http://yaka.leligeour.net:8080/yaka.jpg
[^] # Re: Package "office"
Posté par alpharom . Évalué à 1.
Sinon perso l'idée me parait vraiment sympa... ça fait un moment que je me renseigne un peu sur ce type de solution et c'est une idée original qui peux servire à beaucoup !
Bon courage à tous!
[^] # Re: Package "office"
Posté par Vincent LE LIGEOUR . Évalué à 1.
Merci
# FAI, kickstart, cfengine
Posté par Krunch (site web personnel) . Évalué à 3.
http://www.informatik.uni-koeln.de/fai/
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/cust(...)
http://www.cfengine.org/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: FAI, kickstart, cfengine
Posté par Vincent LE LIGEOUR . Évalué à 2.
# Autres Systèmes
Posté par FRLinux (site web personnel) . Évalué à 4.
- Distribution : nous sommes obligés d'avoir une distribution basée sur le système RPM. Sinon, exit le support Intel (on fourni les compilateurs GNU C et Fortran, mais aussi leur équivalent Intel). Donc le choix a été fait pour CentOS, qui représente une RHEL bien stable avec le plein de patches.
- Automatisation : même problème, on ne se prends pas la tête à) patcher chaque station, nous avons un "master node" et prenons ensuite une image (on utilise systemimager pour cela) que nous balancons aux clients par redémarrage par PXE/TFTP.
- Programmes : nos scientifiques étant spéciaux, leurs besoins le sont aussi. Le cluster admin nous a trouvé un superbe projet pour cela : modules (http://modules.sourceforge.net/) qui permet de définir des environnements pour les personnes voulant compiler leur code ou faire des simulations.
Ceci note la fin du 36.15 ma vie, mais c'était pour donner un autre retour d'expérience vu que perso, j'aime bien lire sur ce que les autres font.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.