Première version publique de Gaspacho (version 0.1)

Posté par (page perso) . Modéré par patrick_g.
Tags :
12
15
nov.
2010
Bureautique
Configurer l'ensemble des postes d'un parc est une activité rébarbative et difficile, surtout dans un environnement hétérogène avec des utilisateurs nomades. Gaspacho permet de pallier ces difficultés, en offrant à l'administrateur la possibilité de gérer, de façon centralisée, la configuration de l'environnement de travail des utilisateurs d'une entité.

Le projet a été initié par l'association de promotion du logiciel libre en Côte d'Or COAGUL dans le cadre des journées de développement de l'année 2009-2010.

Cette version 0.1 est la première version publique du serveur de configuration sous licence GNU/GPL version 3.

Seule la partie serveur est aujourd'hui disponible. Les agents Gaspacho, à installer sur les postes clients, ne sont pas finalisés. Le logiciel n'est donc pas utilisable en l'état dans un environnement de production. Prémices du projet

L'idée de Gaspacho est née d'un besoin dans un cadre professionnel. Il a été conçu durant les premiers ateliers de développement de l'association COAGUL. Le projet est maintenant développé de manière autonome, même si le projet est suivi par certains membres de COAGUL.

Les bonnes volontés sont les bienvenues, ne serait-ce que pour traduire le site du projet en anglais ou écrire de la documentation technique ou utilisateur. Bref, la première version du projet et aussi l'occasion d'un appel à contributions.

Présentation

Le but du projet Gaspacho est de proposer une interface de configuration avec des choix déterminés par l’administrateur pour des groupes de machines et d'utilisateurs.

Pour cela, les configurations des applications sont divisées en différentes règles regroupées par catégories et étiquettes. Une unique règle peut être appliquée à différents logiciels (Mozilla Firefox et Konqueror) et à différents types de système (GNU/Linux et Microsoft Windows).

Par exemple, pour configurer correctement le proxy sur un système, il faut le faire dans différentes applications (configuration du système et des application (Firefox, OpenOffice.org, ...)). Avec Gaspacho, il est possible de définir une seule fois la configuration du proxy pour que l’ensemble des logiciels compatibles soient correctement paramétrés.

Les choix de l’administrateur sont regroupés dans des groupes de machine auxquels on associe des utilisateurs ou des groupes d’utilisateurs. Ainsi, le bureau de l’utilisateur sera systématiquement construit en fonction du lieu de connexion, du système et des besoins exprimés. Sur un poste de travail, ce bureau peut être configuré différemment suivant l'utilisateur.

Il existe trois types de choix pour chaque règle : le choix de l'utilisateur (l'administrateur ne précise pas de configuration), le choix imposé activé et le choix imposé désactivé.

Si nécessaire, une valeur sera demandée à l'administrateur en cas de choix imposé activé.

Enfin, l’administration pourra être déléguée à un ou plusieurs managers pour des groupes donnés.

Pour faciliter la configuration de l’ensemble du parc, un système d’héritage de choix et de template de choix permet de centraliser la configuration de différents groupes.

Logiciels Gaspacho

Gaspacho est composé de deux parties logicielles :
  • Un serveur de configuration : une application web de configuration ;
  • Un agent à installer sur les postes clients (non finalisé pour le moment).

Projets proches

Des projets proches, sur le principe, existent. S’ils sont utiles dans leur domaine de compétence, ils ne peuvent pas remplacer Gaspacho.
  • Privateur : GPO de Microsoft. Ce projet ne s’intéresse qu’à la base de registre et ne permet pas de configurer plusieurs logiciels avec une seule règle ;
  • Libres : Puppet, CfEngine, ... : pas de notion d’utilisateur, centré sur la notion de fichier (donc pas de possibilité de personnalisation de l’utilisateur) et l’administrateur doit connaître la structure des fichiers de configuration.

Futur
  • Utilisation d'une forge pour le projet ;
  • Création, harmonisation et internationalisation des règles ;
  • Sortie d'agents Gaspacho ;
  • Possibilité de différencier le choix sur une règle suivant le logiciel ;
  • ...
  • # Mauvaise architecture

    Posté par . Évalué à 2.

    Perso je trouves l'architecture de la chose absolument horrible.

    Plutot que creer un systeme central sur lequel les applications peuvent se reposer pour recevoir les parametres dont elles ont besoin, on cree un systeme qui doit de lui-meme supporter toutes les applications passees, presentes et futures avec leur differents formats, etc...

    Bref, plutot que distribuer le travail et permettre une integration, on centralise tout ce boulot sur un gros soft qui fait tout et affecte le comportement d'autres softs qui ne sont pas au courant.

    Resultat, tu changes un parametre dans le soft ? T'as interet a ce que ce dernier sache de lui-meme reconnaitre le changement quand il se produit pour le prendre en compte, sinon t'es bon pour devoir soit redemarrer le soft, soit attendre le prochain lancement pour qu'il soit pris en compte.

    Gerer plusieurs versions d'un meme softs qui pourraient stocker ou interpreter le meme parametre de maniere differente ? Deja le framework ne semble rien prevoir pour ce cas, et si c'etait prevu, ca serait du bordel centralise en plus plutot que laisser soin au soft d'aller chercher le parametre et s'en occuper (systeme d'eventing pour quand l'info change, ...)

    Bref, je suggeres perso de revoir totalement l'architecture de la chose, c'est pas scalable du tout comme approche.
    • [^] # Re: Mauvaise architecture

      Posté par . Évalué à 4.

      Patcher des dizaines d'applications dont certaines ne sont pas libre c'est scalable ?

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: Mauvaise architecture

        Posté par . Évalué à -1.

        Parce que tu comptes faire comment pour que le soft en question prenne le changement en compte si il n'est pas capable de detecter le changement ? Tu kill le soft et le redemarre ? Pas top...
        • [^] # Re: Mauvaise architecture

          Posté par . Évalué à 5.

          Les seuls fois où j'ai vu ce genre de solutions c'est pour administrer un parc de serveur et la mise à jour des configuration se fait en automatique la nuit (en même temps que les mises à jour logicielles), les machines sont éteintes automatiquement après application de celles-ci.

          Je pense que c'est l'un des cas d'utilisation privilégié de Gaspacho.

          De toute manière la solution que tu propose est juste pas envisageable, je doute que les éditeurs de logiciels propriétaires acceptent d'inclurent les patchs binaires sur leur exécutables. D'un autre coté je vois mal des fondations Mozilla (c'est pareil pour les entreprises et les communautés) accepter des patchs « juste » pour être compatible avec une solution en devenir qui est loin d'être massivement utilisé.

          Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

          • [^] # Re: Mauvaise architecture

            Posté par . Évalué à 3.

            La solution est parfaitement envisageable, c'est comme ca que fonctionne GPO sous Windows.

            Les editeurs de softs, si ils font le soft pour la plateforme, ils ont tout interet a les faire de maniere a etre facilement gerable sur un parc. Il s'agit pas de faire des patchs binaires un soft proprio, mais bien de modifier le logiciel pour qu'il supporte la solution. Les editeurs le font sous Windows, aucune raison qu'ils ne fassent pas de meme sous Linux si un systeme stable, propre et repandu existe.

            Quand au probleme d'etre compatible avec une solution en devenir, tout a fait, personne a dit que ca serait simple. Mais a choisir entre un systeme lourd et impossible a gerer, et un bon systeme qui va avoir du mal au debut, perso je prefere le 2eme.
            • [^] # Re: Mauvaise architecture

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

              C'est vrai que Gaspacho a le même poids que MS pour discuter avec tout le monde.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Mauvaise architecture

                Posté par . Évalué à 3.

                C'est pas le probleme. Une solution bien pensee et bien faite, petit a petit elle sera adoptee.

                C'est pas discuter qu'il faut, c'est avoir un systeme efficace qui donne envie aux editeurs de l'utiliser car il leur simplifie la vie.
                • [^] # Re: Mauvaise architecture

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

                  Autant je suis d'accord avec toi dans le principe d'architecture unifiée, bien pensée et tout, autant pour le fait qu'elle sera de fait adoptée, là je pense qu'il faut que tu quittes le monde des Bisounours et que tu reviennes à la réalité de la vie, car c'est loin d'être aussi simple (malheureusement).

                  There is no spoon...

            • [^] # Re: Mauvaise architecture

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

              Euh y'a vraiment beaucoup d'éditeur qui gère les GPO en dehors de MS ?

              Sous windows tout n'est pas automatique, gpupdate, logoff/logon ou restart de la machine pour prise en compte de la gpo.
              • [^] # Re: Mauvaise architecture

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

                Euh y'a vraiment beaucoup d'éditeur qui gère les GPO en dehors de MS ?
                C'est la réflexion que je me suis faite également. Et pour avoir un 2003 server et du XP en client, je confirme que non, en dehors de Microsoft, je n'ai aucune application de mon parc qui gère les GPO. (Déjà que MS les gère tellement bien... :/)

                Sous windows tout n'est pas automatique, gpupdate, logoff/logon ou restart de la machine pour prise en compte de la gpo.
                En théorie, la propagation des GPO est automatique (et les délais sont réglables)... En pratique (chez moi en tout cas), elles ne s'appliquent qu'avec un gpupdate (et encore...).

                There is no spoon...

        • [^] # Re: Mauvaise architecture

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

          > Parce que tu comptes faire comment pour que le soft en question prenne le changement
          > en compte si il n'est pas capable de detecter le changement ? Tu kill le soft et le
          > redemarre ? Pas top...

          L'application des paramétrages se fait soit au démarrage de la machine, soit au démarrage de la session. Pas après.

          C'est marrant que tu dises ca, parce que le plus gros problème que nous ayons c'est ... explorer.exe (c'est le seul soft que nous killons au démarrage d'une session Windows / GNU/linux).

          Effectivement il y un temps de latence entre moment où on paramètre un logiciel et le moment où il est appliqué effectivement. Mais nous ne considérons pas ca comme un problème pour le moment.
    • [^] # Re: Mauvaise architecture

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

      La critique que tu fais est également valable pour tous les autres logiciels de configuration/gestion de parc ? Cfengine ou Chef par exemple. Ou alors j'ai mal compris.
      • [^] # Re: Mauvaise architecture

        Posté par . Évalué à 2.

        Sous Linux c'est bien possible, je les connais pas assez pour affirmer qu'ils n'ont pas ce probleme.
      • [^] # Re: Mauvaise architecture

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

        Cfengine 3 est précisément une solution des plus scalables ajd car ils n'ont pas choisi cette architecture : un serveur central sert de repository à plusieurs dizaines de milliers de noeuds, mais les noeuds viennent chercher les règles de configuration dans un méta-langage (DSL) qu'elles doivent respecter, et s'assurent ensuite de les respecter

        Lorsque le serveur central tombe ou est en maintenance, toute l'architecture continue à fonctionner. De plus les traitements de gestion de conf ne sont pas faits par le serveur mais par les noeuds eux-mêmes.
        • [^] # Re: Mauvaise architecture

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

          J'avoue que j'aime bien cfengine qui fonctionne en deux étapes :

          - 1 - synchronise une base de fichier (ensemble de règles, fichiers...)

          - 2 - on applique en fonction de classe un ensemble de règle sur la version locale de la base

          C'est très robuste aux pannes réseaux et tout peut être découpé en morceaux plus petits. Vraiment très très efficace.
        • [^] # Re: Mauvaise architecture

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

          Il devrait y avoir la possibilité, à terme, d'avoir un Gaspacho centrale qui se synchronisera avec des Gaspachos dans les entités (une partie des groupes seront gérés par ceux-ci).

          Il est très facile de faire un mécanisme de noeud. Les "choix" sont enregistrés (pour l'instant) dans des fichiers au format JSON. Le client doit récupérer le fichier JSON spécifique à son groupe. Rien empêche de distribuer les fichiers JSON.
  • # OCS, OPSI, Pulse2

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

    Il y a aussi pour gérer un parc

    - OCS Inventory : marche mais est un peu limité je trouve

    - OPSI : a l'air de tout faire

    - Pulse2 : un peu trop Mandriva mais je n'en sais pas plus

    - WPKG : basique comme OCS

    Ces systèmes me semblent basés sur des clients agents assez basique et ne reprennent pas malheureusement la stratégie de cfengine. Du coup, ça fait des gros serveurs compliqué...
    • [^] # Re: OCS, OPSI, Pulse2

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

      Tu veux dire que la philosophie UNIX que veut qu'un logiciel fait une chose est une mauvaise philosophie ? ;)

      En réalité, il est possible que nous utilisions l'agent de fusioninventory plutot que de développer complètement un nouvel agent (pas encore décidé).
      • [^] # Re: OCS, OPSI, Pulse2

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

        L'agent OCS fait deux choses : remonté de l'inventaire et déployer un logiciel. Il fait donc deux choses.

        Ce qui n'est pas bien. Si l'installation plante, le code retour n'est pas toujours bon. Donc parfois OCS dis que le logiciel est déployé mais en fait non. Si on veut de nouveau l'installer, il faut aller effacer la ligne avec le timestamp du logiciel dans le fichier history... Un peu nul. On devrait avoir une option pour forcer une ré-installation sans avoir à refaire un nouveau paquet identique !

        Autre chose pas terrible, pas possible d'installer un logiciel toutes les x fois, chose que fait très bien cfengine. Par exemple, un logiciel est en pratique un bête script qui bidouille trois clefs de registre pour forcer des sécurités. On veut les ré-appliqué toutes les deux heures par sécurité. Impossible avec OCS puisqu'il n'installe le logiciel qu'une fois. Faut passer ensuite pas la commande AT mais la gestion de celle-ci est un peu pourris.

        Dans le même esprit, on pourrait lancé un nettoyage via CCleaner ou une défragmentation régulière...

        En fait, il y a presque tout dans l'agent pour faire cela.

        Autre chose avec OCS, la commande que tu lances ouvres une invite de commande... J'ai pas trouvé de solution pour avoir un truc 100% silencieux qui marche sur tous les postes sauf à mettre en tout début de script .bat la commande cmdow.exe (et penser à rajouter cette commande dans les exceptions des anti-virus).

        J'ai regardé du coté d'OPSI mais tu deviens très dépendant de lui...

        Comment on fonctionne avec OCS, on fait des zip qui ont tout dedans et surtout un script install.bat. L'idée est que l'installation via OCS ou à la main est la plus proche possible. OCS lance install.bat qui fait toute la suite. Les choses sont donc bien distinctes et simple à maintenir. Et puis, on peux diffuser les paquets zip même aux personnes qui ne sont pas gérer par OCS, ou on peut remplacer OCS par un autre système à terme.
    • [^] # Re: OCS, OPSI, Pulse2

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

      - OCS Inventory : marche mais est un peu limité je trouve
      L'agent Ocs n'a pas pour fonction première de faire de l'installation mais de récupérer des informations qui peuvent être traités par d'autres applications (le serveur OCSi-ng, GLPI via OCSi-ng, Pulse 2)
      à noter le projet Fusion Inventory qui complète, j'oserais même dire remplace et surpasse OCS inventory (pas encore tout à fait, mais ça s'approche)
      L'avantage d'OCS est de gérer le découpage des fichiers à installer par petits morceaux, et d'installer de manière aléatoire. Par contre l'interface de création de paquet de déploiement est proche du zéro.

      - OPSI : a l'air de tout faire
      Je n'ai pas eu l'occasion de tester, j'ai trouvé l'installation assez... inhabituelle.

      - Pulse2 : un peu trop Mandriva mais je n'en sais pas plus
      J'ai pas testé, je suis intéressé, néanmoins je n'ai pas compris le commentaire

      - WPKG : basique comme OCS
      Basique, mmm, je dirais petit mais costaud, il y a un grand nombre de script, et une interface graphique simple, mais performante.
      L'avantage de wpkg sur OCS c'est de pouvoir gérer les mises à jour, les désinstallations, etc.
      • [^] # Re: OCS, OPSI, Pulse2

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

        Chez nous, la fonction première de l'agent OCS est de déploiement ;-) Le projet FusionInventory est très bien mais c'est surtout la partie agent d'installation qui m'intéresse le plus...

        La manière qu'à OCS pour déployer un paquet est génial, découper en petit morceau de manière automatique, le client récupère tout cela via http en prenant son temps, tout simplement génial et bien mieux que tout le reste ou malheureusement, cela passe trop souvent par un partage samba ;-(

        Pour Pulse2, ma remarque est que je ne connais personne l'ayant utilisé et je ne sais pas s'il est utilisé ailleurs que sur un serveur Mandriva. C'est tout.
        • [^] # Re: OCS, OPSI, Pulse2

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

          > La manière qu'à OCS pour déployer un paquet est génial, découper en petit morceau de
          > manière automatique, le client récupère tout cela via http en prenant son temps, tout
          > simplement génial et bien mieux que tout le reste ou malheureusement, cela passe trop
          > souvent par un partage samba ;-(

          Peut être sous Windows, mais je ne trouve pas que ca soit une bonne manière d'installer des applications GNU/Linux sur les postes.
          • [^] # Re: OCS, OPSI, Pulse2

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

            Sous Linux, je déploie avec cfengine qui est bien plus souple ;-)
            • [^] # Re: OCS, OPSI, Pulse2

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

              Je ne connais pas le mécanisme de déploiement de cfengine. Ca se base sur les systèmes de paquets des distributions ?
              • [^] # Re: OCS, OPSI, Pulse2

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

                Tu peux mais personnellement, je lance un script avec les classes de cfengine en option via cfengine. C'est un script que j'ai bidouillé à partir d'un script développé par Steve Kemp pour debian.

                Le problème que j'ai eu la version intégré dans cfengine, c'était trop verbeux et surtout, dès qu'il y avait trop de paquet à installer, ça plantait pour un histoire de longueur de ligne si je me souviens bien...
        • [^] # Re: OCS, OPSI, Pulse2

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

          Pour Pulse2, ma remarque est que je ne connais personne l'ayant utilisé et je ne sais pas s'il est utilisé ailleurs que sur un serveur Mandriva. C'est tout.

          Si ça t'intéresse, c'est disponible pour Debian : http://pulse2.mandriva.org/wiki/DocumentationFr#Installingan(...)

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Faute de français

    Posté par . Évalué à -1.

    La phrase : "Le projet a été initié par l'association" est incorrecte. On ne peut pas initier quelque chose (par contre on peut initier quelqu'un à une science ou à un art).
    Il vaudrait mieux dire, par exemple : "Le projet a été lancé par l'association".
    • [^] # Re: Faute de français

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

      Nous avons pourtant passé l'article dans différentes mains pour relecture.
      En tout cas merci de la précision, par contre j'ai pu constater que nous n'étions pas seul à faire cette faute de français :
      http://www.seeks.fr/search?q=%22Le+projet+a+%C3%A9t%C3%A9+in(...)
    • [^] # Re: Faute de français

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

      Pourtant dans la définition http://fr.wiktionary.org/wiki/initier j'ai :

      > (Par analogie) Faire les procédures initiales, commencer à mettre en place une action, une organisation.

      Cela me semble plutôt correct comme tournure de phrase.
    • [^] # Re: Faute de français

      Posté par . Évalué à 2.

      L'Académie Française dit:

      (2)INITIER (ti se prononce ci) v. tr. (se conjugue comme Crier). XIVe siècle. Emprunté du latin initiare, « initier, instruire ; commencer ».
      (...)
      4. SC. Amorcer, engager, mettre en œuvre la phase initiale d'un processus. Initier une réaction chimique.
      Les dictionnaires d'ancien français attestent l'existence du mot inition, inicion, du latin initium, au sens de « commencement », employé par Jean de Meung, Froissart, etc. Le verbe initier, du latin initiare, est de même attesté au XVIe siècle, notamment chez Rabelais : « Quartiers [de lune]... croissans, initians... » On en retrouve un exemple isolé chez Chateaubriand : « Pierre, évêque de Rome, initia la papauté ». Cet emploi se retrouve dans toutes les langues latines, et n'est pas en soi condamnable. Toutefois il se répand abusivement dans les textes politiques, administratifs, journalistiques, alors que le français dispose de verbes ou de locutions tels que commencer, inaugurer, engager, entreprendre, lancer, être à l'origine de, mieux adaptés à traduire les diverses nuances de la même idée.


      C'est donc limite comme emploi puisque l'on est pas strictement dans le cadre des sciences, mais cet emploi a tendance à se généraliser. Peut être ce verbe prendra-t-il véritablement ce sens dans les années à venir. Enfin, tant que ce n'est pas au détriment des autres verbes…

      cd /pub && more beer

  • # doc

    Posté par . Évalué à 5.

    Personnellement, je tiens à souligner les efforts réalisés pour faire la documentation.

    Une doc est dispo avant d'avoir un produit finalisé, c'est pas mal, ca change des outils libres ou on doit allé chercher des infos au fond d'une mailing list..
    • [^] # Re: doc

      Posté par . Évalué à 3.

      > ca change des outils libres ou on doit allé chercher des infos au fond d'une mailing list..
      Ou dans le code source :)
    • [^] # Re: doc

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

      Merci pour ce commentaire positif ça valorise le travail accompli.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.