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 ;
- ...
Aller plus loin
- Gaspacho (105 clics)
- COAGUL (17 clics)
- Présentation aux JDLL (16 clics)
# Mauvaise architecture
Posté par pasBill pasGates . Évalué à 2.
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 barmic . Évalué à 4.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mauvaise architecture
Posté par pasBill pasGates . Évalué à -1.
[^] # Re: Mauvaise architecture
Posté par barmic . Évalué à 5.
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é.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mauvaise architecture
Posté par pasBill pasGates . Évalué à 3.
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 claudex . Évalué à 7.
« 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 pasBill pasGates . Évalué à 3.
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 madhatter (site web personnel) . Évalué à 5.
There is no spoon...
[^] # Re: Mauvaise architecture
Posté par Dup (site web personnel) . Évalué à 4.
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 madhatter (site web personnel) . Évalué à 5.
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 GnunuX (site web personnel) . Évalué à 2.
> 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 Kerro . Évalué à 2.
[^] # Re: Mauvaise architecture
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Mauvaise architecture
Posté par Nico G (site web personnel) . Évalué à 1.
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 Sytoka Modon (site web personnel) . Évalué à 2.
- 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 GnunuX (site web personnel) . Évalué à 1.
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 Sytoka Modon (site web personnel) . Évalué à 2.
- 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 GnunuX (site web personnel) . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 Bruce Le Nain (site web personnel) . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 GnunuX (site web personnel) . Évalué à 1.
> 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 Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: OCS, OPSI, Pulse2
Posté par GnunuX (site web personnel) . Évalué à 1.
[^] # Re: OCS, OPSI, Pulse2
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
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 claudex . Évalué à 2.
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 jcr83 . Évalué à -1.
Il vaudrait mieux dire, par exemple : "Le projet a été lancé par l'association".
[^] # Re: Faute de français
Posté par Dlareg (site web personnel) . Évalué à 0.
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 Toutankharton . Évalué à 0.
[^] # Re: Faute de français
Posté par GnunuX (site web personnel) . Évalué à 1.
[^] # Re: Faute de français
Posté par Dlareg (site web personnel) . Évalué à 1.
On va finir par demander aux personnes de nous rejoindre et de modérer toutes nos news.
[^] # Re: Faute de français
Posté par GnunuX (site web personnel) . Évalué à 1.
> (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 Fopossum . Évalué à 2.
(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 slockstone . Évalué à 5.
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 contre_maitre . Évalué à 3.
Ou dans le code source :)
[^] # Re: doc
Posté par Dlareg (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.