YaKa une distribution orientée parc informatique et services

Posté par . Modéré par Nÿco.
Tags :
1
22
nov.
2006
Linux
YaKa est à la fois une distribution de type GNU/Linux source et un langage permettant la description d'un parc informatique. Son but principal est de fournir une méthode simple et efficace de déploiement d'un parc informatique hétérogène aussi bien sur le plan matériel, logiciel ou d'infrastructure.

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
Les principaux avantages de la distribution/langage sont :
  • 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)
  • # IACA

    Posté par (page perso) . Évalué à 1.

    Le nom a-t-il quelque chose à voir avec un autre système largement utilisé dans nos collèges et lycées (dans les bouches du rhône en tout cas) répondant au nom de IACA ?
    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 . Évalué à 3.

      Non, aucun lien, mais il est possible de faire la même chose avec Yaka (en utilisant le service LDAP/SAMBA/NFS).
  • # Quelques explications s'il vous plait ?

    Posté par . Évalué à 3.

    «La mise à jour de l'ensemble du parc aisée»

    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 . Évalué à 3.

      Hum... il ne faut pas confondre le gros bousin qui génère les images du système, et le système lui-même qui sera installé sur les postes de travail.

      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 . Évalué à 6.

        Oui effectivement il faut bien dissocier ce que l'on va appeler le serveur YaKa (la machine qui va générer l'ensemble des packages, créer les serveurs (PXE/DHCP/etc) et les machines clients (postes desktop ou serveurs d'application).

        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 . Évalué à 2.

          Merci bien en effet, ça répond à mes questions.

          (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 . Évalué à 1.

            Ahah :) la fameuse question : Pourquoi ne pas s'être basé sur une distribution existante ...

            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 . Évalué à 2.

              Des élèves d'une école a les ressources pour mettre à jour les paquets d'une distribution ?

              Cela me parait un sacré boulot.

              "La première sécurité est la liberté"

              • [^] # Re: Quelques explications s'il vous plait ?

                Posté par . Évalué à 1.

                > Des élèves d'une école a les ressources pour mettre à jour les paquets d'une distribution ?

                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 . Évalué à 3.

                  On parle souvent des 3 axes d'une distrib :
                  - 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 . Évalué à 2.

                    Oui c'est ca, et pour le nombre de personnes l'utilisant et pouvoir faire les tests de non-regression je trouve qu'on est plutot à jour (Xorg 7.1, gcc 4.1, etc). Bien sur avec une équipe restreinte pour le moment c'est pas évident de rajouter 2 fois par jours les patchs gentoo qui font bien pour l'architecture exotique (d'ailleurs pour le moment la seule architecture supportée est la x86 par faute d'autre plateforme a tester). Ensuite on essaye au maximum d'utiliser les version vanilla des projets (plus facil pour faire du bugreport quand un paquet ne marche pas).
                    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 . Évalué à 1.

        Perso, je vois difficilement justifiable l'absence de la fonctionnalité de mise à jour.

        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 . Évalué à 2.

          "Quel est l'intéret de YaKa si on veut utiliser RedHat/Fadora/SuSE/Debian/... ?"

          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 . Évalué à 3.

            Merci pour cette explication.

            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 . Évalué à 1.

              Je viens de lire ce qu'étais Stateless. En fait nous faisons presque la même chose (si j'ai bien compris Stateless) avec notre système de monitoring. Il permet de sauvegarder une partie d'une machine (homes, datas, etc) par NFS ou SSH sur le serveur d'installation (avec RSYNC). Le serveur d'installation a alors toujours un tar.gz récent et ainsi à la prochaine réinstallation il peut réinstaller les datas (si on le désire, la réinstallation peut se faire partition par partition).
              Ai-je répondu à la question ?

              Vincent
              • [^] # Re: Quelques explications s'il vous plait ?

                Posté par . Évalué à 2.

                Je me demandais si techniquement, il était possible d'intégrer stateless dans YaKa... combiner les points forts des deux solutions dans YaKa afin de pouvoir gérer plus ou moins de la même manière un Fedora... ça ferait tout de même une distribution de plus dans le système YaKa, ce qui le rendrait plus attrayant pour certaines entreprises.
                • [^] # Re: Quelques explications s'il vous plait ?

                  Posté par . Évalué à 2.

                  Je pense que techniquement, contrairement à utiliser un système de paquetage externe à la YaKa, c'est possible et envetuellement pertinent. Ensuite ne connaissant pas StateLess je ne pourrait l'affirmer avec certitude. A voir donc
      • [^] # Re: Quelques explications s'il vous plait ?

        Posté par (page perso) . Évalué à 2.

        Connais tu la solution qui etait utilisée par cette FAC pour l'installation des Windows et Linux ? (un peu HS mais ça m'interresses :) )
        • [^] # Re: Quelques explications s'il vous plait ?

          Posté par . Évalué à 2.

          Pas la moindre idée.

          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 (page perso) . Évalué à 2.

            J'ai commencé a mettre en place une solution dans ce genre la, avec un linux minimaliste (a base de busybox et partage nfs), et pour la restauration d'image, j'utilise Partimage. Mais si il y a une solution toute prete, j'aurai été prenneur :)
  • # à promouvoir

    Posté par . Évalué à 3.

    Salut,
    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 . Évalué à 2.

      Bonjour,

      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 (page perso) . Évalué à 2.

    Dans des petits réseaux de petites structures (5 à 10 postes) on a aussi besoin de ce genre de choses pour éviter à l'informaticien du coin de se pointer tous les 15 jours.
    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 . Évalué à 2.

      Alors concernant les machines serveurs ... Une puissance de calcul est souhaitable si l'on ne veut pas passer trop de temps lors de la première compilation et pour régénérer les packages lors du chagement de configuration. Il faut également prévoir une bonne quantité de RAM (car afin d'augmenter la rapidité de la machine de nombreuses données sont stockées en RAM).

      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 (page perso) . Évalué à 1.

        merci pour cette super réponse!

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Quelle capacité pour le serveur ?

        Posté par . Évalué à 3.

        ça ouvre des perspectives en tout cas...

        Pour déployer un système grid, par exemple...
        • [^] # Re: Quelle capacité pour le serveur ?

          Posté par . Évalué à 2.

          Quelqu'un a parlé d'installation sur Internet à partir d'une mini image et maintenue à distance ? (ou comment faire passer le commun des mortels à Linux en ayant un support supérieur à celui de Windows)
          • [^] # Re: Quelle capacité pour le serveur ?

            Posté par . Évalué à 3.

            Ca, ça peut être super bien...
            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 . Évalué à 1.

              Pour le YaKa-fs oui et non :) car une fois qu'un fichier est utilisé il est placé en local, donc l'on obtient très rapidement un système avec le maximum de choses en local.
              • [^] # Re: Quelle capacité pour le serveur ?

                Posté par . Évalué à 3.

                Hmm, ça dépend de la fiabilité de la connexion alors.

                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 . Évalué à 1.

                  Le cas d'installation par internet est potentiellement possible (on peut generer des CD/DVD de boot contenant les adresses ou telecharger les paquets). En revanche l'identification se fait par MAC/IP il faudrait changer ca pour avoir une cle par CD et identifier la machine (ou quelquechose de ce genre).
                  Donc la base existe il suffirait de rajouter quelques fonctionnalités dans l'installeur je pense.
  • # yaka

    Posté par . Évalué à 1.

    yaka fonkon !
    • [^] # Re: yaka

      Posté par . Évalué à 2.

      Fokon existe également est un système de notation automatique de TP http://yaka.ensiie.fr/fokon/
      • [^] # Re: yaka

        Posté par . Évalué à 2.

        et y'a pas la même chose pour faire les TP ?
        • [^] # Re: yaka

          Posté par . Évalué à 1.

          Heuuu, si la question est est-ce que le programme peut générer les exercices c'est ce qu'il fait. Si c'est plutôt est-ce qu'il peut faire le TP a ma place pôv petit élève ..... non ;)
  • # moi j'aime

    Posté par (page perso) . Évalué à 3.

    J'ai pas essayé, mais à la lecture de l'article je trouve l'idée très interressante.
    Je poste juste pour vous souhaiter bon courrage et bonne chance.
  • # Package "office"

    Posté par . Évalué à 1.

    salut,

    pour ceux qui se demandent à quoi peut ressembler les package "office" :
    http://yaka.leligeour.net:8080/yaka.jpg
    • [^] # Re: Package "office"

      Posté par . Évalué à 1.

      Je veux pas faire de Troll mais pourquoi un skin qui ressemble à windows ?? C'est dommage quand on voit le fond d'écran !!

      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 . Évalué à 1.

        Pour le paquetage office je le pensais plutôt destiné à des utilisateurs en migration. Le but est donc de ne pas trop les depayser (skins) tout en marquant une différence (fond d'écran).

        Merci
  • # FAI, kickstart, cfengine

    Posté par (page perso) . Évalué à 3.

    J'ai pas tout lu mais en ctrl+fant sur les commentaires je ne vois personne parler de FAI, Kickstart ou cfengine donc je le fais.

    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 . Évalué à 2.

      L'équipe est en cours de rédaction d'un "papier blanc" (donc il existe une ébauche sur la branche développement sur le CVS) qui marque très nettement les différences par rapport à des technologies telles que cfengine+FAI ou Kickstart.. Pour plus d'info, consultez le début de papier :)
  • # Autres Systèmes

    Posté par (page perso) . Évalué à 4.

    Dans la série 36.15 ma vie, on vient précisemment de réinstaller un cluster de 40 noeuds (c'était le cluster de tests, on deploie sur 136 noeuds la semaine prochaine). On a regardé ce qui pouvait mieux le faire pour nos besoins. Pour définir cela clairement :

    - 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 à ceux qui les ont postés. Nous n'en sommes pas responsables.