La page de GnunuX

Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - gaspacho

Fil des billets - Fil des commentaires

lundi, octobre 17 2011

Edenwall est mort ... vive Cadoles

Comme je disais il y a un peu plus de 3 ans, je ne parle pas facilement de mon activité professionnelle (1) sur ce site. A l'époque je rejoignais l'entreprise INL (devenu ensuite EdenWall) (2).

Durant ces 3 ans 1/2 j'ai travaillé sur le projet libre EOLE de l'Éducation Nationale (3). EOLE est un ensemble de modules répondant à différent besoins, au départ, de l'Éducation Nationale. En voici quelques-un :

  • Amon : module de contrôle des accès Internet (firewall, Proxy filtrant, ...) ;
  • Scribe : serveur pédagogique (partage de fichier, courriel, ...) ;
  • Eclair : serveur de client léger diffusant des bureaux libres.

L'ensemble du projet est libre et ouvert.

J'ai beaucoup apprécié de travailler sur ce projet. Il est nécessaire d'avoir une variété de compétences et l'ambiance de travail est agréable.

Edenwall vient d'être liquidé et à ce titre ... j'ai été licencié.

Dijon n'est pas forcement le meilleur endroit pour trouver un travail intéressant. Nous avons donc décider de monter une boîte pour proposer notre expertise EOLE. J'espère également pouvoir faire des offres autour de la solution libre Gaspacho (4).

Cette boîte est une SCOP à responsabilité limité dont je suis le gérant.

Donc si vous voulez une prestation EOLE, une formation, du Gaspacho ou du logiciels libres à Dijon ou ailleurs ... il y a Cadoles !

  1. http://www.gnunux.info/dotclear2/index.php?post/2008/01/31/249
  2. http://www.gnunux.info/dotclear2/index.php?post/2008/02/10/250
  3. http://eole.orion.education.fr
  4. http://www.gaspacho-project.net

lundi, juillet 18 2011

Présentation de Gaspacho au RMLL 2011

J'ai présenté Gaspacho au RMLL 2011.

Je mets à disposition le support de présentation. Le support est au format SVG. Il faut l'ouvrir avec un lecteur SVG capable d'interpréter le javascript (comme Firefox par exemple). Attention, il faut attendre un peu le chargement du document.

http://gnunux.info/dotclear2/public/gaspacho/gaspacho.svg

samedi, juillet 2 2011

Mécanisme de "clef obligatoire" par utilisateur avec dconf (GNOME 3)

Contrairement à GNOME 2, GNOME 3 n'utilise plus GConf pour gérer les éléments de configuration.

Maintenant c'est Gsettings. Gsettings est en réalité une API de configuration. Le stockage des configurations se fait par un backend.

Sous GNU/Linux, le backend est dconf.

Avec GConf il était facile d'avoir des clefs obligatoires avec le mécanisme des mandatories. Avec dconf c'est un peu plus compliqué.

La configuration de dconf est séparée en deux parties :

  • les profiles ;
  • les bases de données.

Les profiles

Les profiles servent a mettre en relation des configurations et les bases de données. Le profile par défaut est user.

Par défaut, les profiles sont dans le répertoire /etc/dconf/profile/. Ce sont des fichiers de la forme :

database1
database2

La valeur database1 correspond au nom de la base de données utilisateur (généralement dans ~/.config/dconf/). La valeur database2 correspond au nom de la base de données système (généralement dans /etc/dconf/db/). La base de données utilisateur sera prioritaire.

La base de données utilisateur

Pour modifier la base de données utilisateur, le plus simple est d'utiliser la commande dconf :

# dconf write path value

Pour lire la valeur :

# dconf read path

Pour lister les valeurs :

# dconf list path

Par exemple :

# dconf write /org/gnome/gnome-screenshot/delay 16
# dconf read /org/gnome/gnome-screenshot/delay
# dconf list /org/gnome/gnome-screenshot/

La base de données système

Pour modifier la base de données système, le plus simple est de faire des fichiers plats (type INI).

Pour cela, il faut faire une fichier du nom de la base de données dans le répertoire /etc/dconf/db/ avec l'extension .d.

Dans notre cas, nous ferons le répertoire /etc/dconf/db/database2.d/. À l'intérieur nous ferons des fichiers avec l'ensemble des paramètres :

[path]
key=value

Les clefs obligatoires

Dans le répertoire de la base de données système, il faut faire un répertoire locks avec une série de fichiers contenant le chemin des clefs obligatoires de la forme :

path

Clefs obligatoires par utilisateur

Il est envisageable d'avoir des clefs obligatoires par utilisateur si nous créons un profile et une base par utilisateur. Ce profile sera associé à l'utilisateur au démarrage de la session.

Pour cela, il faut ajouter dans le fichier de configuration de bash quelque chose comme cela :

readonly DCONF_PROFILE=nomprofile
export DCONF_PROFILE

Par contre, utiliser le nom d'utilisateur comme nom de profile n'est pas forcement une bonne idée, en effet il y a des restrictions importantes dans le nom du profile : il doit être de type alphanumérique ou "_".

Exemple d'utilisation

Dans /etc/bashrc :

if [ -e /etc/dconf/profile/$UID ]; then
    readonly DCONF_PROFILE=$UID
    export DCONF_PROFILE
fi

Création du fichier : /etc/dconf/profile/500 (pour l'utilisateur avec l'uid 500) :

user
500

Le fichier /etc/dconf/db/500.d/delay contient :

[org/gnome/gnome-screenshot]
delay=16

Le fichier /etc/dconf/db/500.d/locks/delay contient le chemin :

/org/gnome/gnome-screenshot/delay

samedi, novembre 13 2010

Dernière version RC de Gaspacho avant la version 0.1

Je viens de mettre en ligne la dernière version RC de Gaspacho 0.1.

Gaspacho est une application libre (GNU/GPL v3) 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é.

J'encourage tout le monde à tester cette version pour permettre la meilleure version stable possible.

Tester veux dire :

  • installer le projet et faire de retour sur le sujet ;
  • tester l'interface web ;
  • lire la documentation en ligne.

C'est aussi l'occasion de préparer l'avenir en faisant des suggestions d'améliorations, de nouvelles fonctionnalités, ...

Plus d'informations sur Gaspacho sur le site du projet : http://www.gaspacho-project.net/.

N'hésitez pas à laisser des commentaires pour poser des questions, remarques, ...

Je cherche également une forge de développement supportant git. Si vous avez des idées ...

vendredi, septembre 24 2010

Les choix Gaspacho

Le choix est l'élément central de Gaspacho. Sans choix ... il n'y a aucun intérêt de l'utiliser.

Le choix est le lien entre la règle (1 et 2) et le groupe (3).

Le choix

Le choix est donc la configuration particulière d'une règle pour un groupe ou un template (et éventuellement le groupe d'utilisateur).

Pour un groupe ou un template il est possible de définir des choix pour les règles machines et les règles utilisateurs. Par contre, pour un groupe d'utilisateur, seul les règles utilisateurs sont paramétrables.

Si le règle n'est pas de type booléen, une valeur devra être définit en plus du choix.

Les choix

En réalité, il n'y pas un choix possible par règle mais trois :

  1. choix libre : c'est l'utilisateur qui choisit le paramétrage de cette option (c'est la valeur par défaut) ;
  2. choix imposé désactivé : c'est l'administrateur qui choisit le paramétrage en la désactivant ;
  3. choix imposé activé : c'est l'administrateur qui choisit le paramétrage en l'activant ;

La valeur de la règle ne sera utile que lorsque le choix est imposé et activé.

Exemple avec l'activation du proxy :

  1. choix libre : l'utilisateur active ou désactive le proxy à sa convenance ;
  2. choix imposé désactivé : l'administrateur impose la désactivation du proxy ;
  3. choix imposé activé : l'administrateur impose l'activation du proxy et le configure suivant le paramétrage prédéfini.

Le choix et l'héritage

Lorsqu'on parle d'héritage, cela concerne bien évidement uniquement les choix. Le premier choix détecté dans l'héritage sera appliqué à l'utilisateur.

Donc pour un groupe il y deux états pour la règle :

  1. l'administrateur a spécifié un choix : il s'applique ;
  2. l'administrateur n'a pas spécifié de choix : c'est le choix hérité qui s'applique ;

Si l'administrateur n'a pas spécifié de choix pour les groupes hérités ou les templates hérités, c'est le choix par défaut, choix libre, qui s'applique.

Liens :

  1. http://gnunux.info/dotclear2/index.php?post/2010/09/17/Les-regles-dans-Gaspacho
  2. http://gnunux.info/dotclear2/index.php?post/2010/09/18/Proprietes-des-regles-Gaspacho
  3. http://gnunux.info/dotclear2/index.php?post/2010/09/18/Les-groupes-Gaspacho

samedi, septembre 18 2010

Les groupes Gaspacho

Après avoir présenté les règles Gaspacho (1 et 2), il faut s'attarder sur la notion de groupe.

Si l'administrateur ne devrait pas avoir besoin de gérer lui même les règles (sauf si la règle dont il a besoin n'existe pas encore), il devra créer les groupes.

Un groupe est un ensemble de machines disposant des mêmes configurations. Il est possible d'associer des utilisateurs pour différencier les configurations suivant le profile de la personne qui se connecte à la machine.

Les groupes

Un groupe est d'abord un libellé. Il est directement visible dans l'interface de configuration.

Pour limiter le nombre de règles disponible, ce groupe peut être lié à un ou plusieurs systèmes ou un ou plusieurs logiciels. Dans ce cas, seuls les règles concernant ces logiciels ou systèmes seront proposées.

Enfin, pour classer les groupes, un niveau est associé à ce groupe. En effet, le première groupe qui comprends aux critères de la machine se connectant sera le groupe de la machine. Il est alors important de pouvoir les classer.

Les groupes de machine

Une fois défini, le groupe est lié à un ensemble de machines. Un machine est décrite soit par son adresse IP, soit par son nom DNS. Dans le nom DNS ou l'IP il est possible d'utiliser les motifs inspirés du shell Unix :

*        remplace tout
?        remplace un seul caractère
[seq]    remplace tous caractères dans "seq"
[!seq]   remplace tous caractères en dehors de "seq"

Les utilisateurs ou groupes d'utilisateurs

Le groupe peut également être lié à un ensemble d'utilisateurs. Il est possible de définir des utilisateurs ou des groupes d'utilisateurs. Le nom de l'utilisateur primant sur son groupe primaire.

Si l'utilisateur n'est pas définit ou n'appartient pas aux groupes, il récupèrera les paramétrages du groupe directement

Les templates

En plus des groupes, il existe les templates. Les templates ont les mêmes propriétés qu'un groupe sauf qu'il n'est pas possible de lui associer des groupes de machine. Les templates sont utiles dans le cadre de l'héritage. Les templates peuvent être associés à des groupes différents.

L'héritage des groupes

Le mécanisme d'héritage permet mettre en commun des réglages pour différents groupes.

Exemple d'héritage :

default (None, user1, user2)
   |
   '--group1 (None, user1, user2)
         |
         |--group2 (None, user1, user2)
         |
         template1 (None, user1, user2)

Si l'utilisateur user1 se connecte à group2, le parcours de l'héritage se fera de la manière suivante :

  1. user1 sur group2 ;
  2. group2
  3. user1 sur group1 ;
  4. group1
  5. user1 sur template1 ;
  6. template1 ;
  7. user1 sur default ;
  8. default

Si l'utilisateur n'est pas user1 ni user2 :

  1. group2
  2. group1
  3. template1
  4. default

Le concept de template prend tout son sens. Les groupes ne peuvent hériter que de ses parents alors qu'un template peut concerner plusieurs groupes avec des parents complètement différents.

Liens :

  1. http://gnunux.info/dotclear2/index.php?post/2010/09/17/Les-regles-dans-Gaspacho
  2. http://gnunux.info/dotclear2/index.php?post/2010/09/18/Proprietes-des-regles-Gaspacho

Propriétés des règles Gaspacho

Comme indiqué dans un précédent poste (1), une règle Gaspacho est d'abord un intitulé.

Mais évidement, ce n'est pas que cela.

Les niveaux de règles

Il existe déjà deux niveaux de règles différentes :

  • les règles dites "machines", appliquées au démarrage de la machine quelque soit l'utilisateur s'y connectant ;
  • les règles dites "utilisateurs" qui concernent un utilisateur particulier ou un groupe d'utilisateurs. Elles sont appliquées au démarrage de la session.

Par exemple :

  1. "Autoriser l'arrêt de la machine depuis la fenêtre d'ouverture de session" est une règle machine ;
  2. "Configuration du proxy" est une règle utilisateur.

Les types

Les types de règle

Une fois que le niveau de règle est défini (machine ou utilisateur), il faut choisir son type.

Les types possible sont composés de deux catégories :

  • sans valeur : "boolean"
  • avec valeur : "unicode" (un texte libre), "integer" (un chiffre), "enum" (une liste de choix prédéfinies) et "list" (une liste de choix libres).

Les types sans valeurs sont les plus simple. Par exemple cette règle n'attend aucune valeur particulière :

"Vérifier que Firefox est le navigateur par défaut"

Alors que celle-ci attend une adresse IP :

"Configuration du serveur proxy manuelle"

Il existe un autre type ("multi") qui permet de mêler plusieurs types. Je n'entrerais pas dans les détails dans ce billet.

Il s'agit bien de définir ici le type de la règle (et uniquement de la règle).

Les types de variables

Le type de la règle n'agit en rien sur les types des variables associées à la règle.

Par exemple, la configuration du proxy (type unicode) sous GNOME configure trois variables de types différents :

  1. /system/http_proxy/use_http_proxy de type boolean ;
  2. /system/http_proxy/host de type unicode ;
  3. /system/http_proxy/port de type integer.

Les valeurs

Valeurs par défaut des règles

Chaque règle avec valeur peut contenir une valeur par défaut. Celle-ci sera proposée à l'activation de la règle. Si cette valeur ne lui convient pas, il aura bien évidement le loisir de la modifier.

Les valeurs "activées" et "désactivées" des variables

Je présenterais en temps voulu la notion de "activé" et "désactivé" d'une variable. Il faut juste savoir que l'on peut associer une valeur fixe à une variable.

Par exemple, lors de l'activation du proxy sous GNOME, la variable "/system/http_proxy/use_http_proxy" aura comme valeur "True". L'utilisateur n'interagit pas directement sur cette valeur.

En cas de règle avec valeur, il est possible qu'une variable ne récupère par la valeur défini par l'utilisateur (comme le montre l'exemple juste avant). Si la variable doit récupérer la valeur, il suffit de ne pas spécifier de valeur pour la variable en question.

  1. http://gnunux.info/dotclear2/index.php?post/2010/09/17/Les-regles-dans-Gaspacho

vendredi, septembre 17 2010

Les règles dans Gaspacho ?

Une règle, dans Gaspacho, est simplement (pour schématiser) un libellé.

Par exemple "Configuration du serveur proxy manuelle" est une règle.

Évidement, la règle en elle même ne sert a rien. Il faut lui associer des éléments de configuration.

Avant d'expliquer comment cela fonctionne, voici des exemples de configuration du proxy. On peut voir qu'il existe une variété de formats de fichiers de configuration.

  • Configuration du proxy sous Windows avec des clefs de registre :
  1. activation du proxy : HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable : 1 ;
  2. configuration du proxy : HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer : 192.168.1.1:3128 :
  3. mise en place d'une restriction sur la modification du paramétrage du proxy : HKEY_CURRENT_USER\Software\Policies\Microsoft\Internet Explorer\Control Panel\Proxy : 1.
  • Configuration du proxy sous Mozilla Firefox avec un fichier javascript utilisateur.js (1) :
  1. activation du proxy : lockPerf("network.proxy.type", "1"); ;
  2. configuration de l'IP du proxy : lockPerf("network.proxy.http", "192.168.1.1"); ;
  3. configuration du port du proxy : lockPerf("network.proxy.http_port", "3128");.
  • Configuration du proxy sous GNOME avec des clefs gconf :
  1. activation du proxy : /system/http_proxy/use_http_proxy True ;
  2. configuration de l'IP du proxy : /system/http_proxy/host "192.168.1.1" ;
  3. configuration du port du proxy : /system/http_proxy/port 3128.
  • Configuration du proxy sous OpenOffice.org avec le fichier XML ~/.ooo3/user/registry/data/org/openoffice/Inet.xcu :
<?xml version="1.0" encoding="UTF-8"?>
<oor:component-data xmlns:oor="http://openoffice.org/2001/registry" xmlns:xs="http://www.w3.org/2001/XMLSchema" oor:name="Inet" oor:package="org.openoffice">
 <node oor:name="Settings">
  <prop oor:name="ooInetProxyType" oor:type="xs:int">
   <value>2</value>
  </prop>
  <prop oor:name="ooInetHTTPProxyName" oor:type="xs:string">
   <value>192.168.10.1</value>
  </prop>
  <prop oor:name="ooInetHTTPProxyPort" oor:type="xs:int">
   <value>8080</value>
  </prop>
 </node>
</oor:component-data>

Gaspacho devra supporter l'ensemble des formats de fichiers de configuration. De plus, il devra gérer les versions des logiciels et les distributions/systèmes d'exploitation.

Pour cela, chaque élément de configuration sera divisé en deux : la variable et la plateforme. La plateforme comprendra le chemin et le système.

Par exemple, nous aurons :

  • variable : ProxyEnable avec la valeur 1 ;
  • plateforme : chemin : HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ et système : Windows XP.

Autre exemple pour OpenOffice.org :

  • variable : ooInetProxyType dans la section Inet/Settings avec la valeur 2 ;
  • plateforme : chemin : ~/.ooo3/user/registry/data/org/openoffice/Inet.xcu et système : Mandriva 2010 + OpenOffice.org 3.2.

Enfin, ces règles sont classés dans des "tags" eux-mêmes classés dans des "catégories".

Ici, cette règle sera dans la catégorie "Réseau" et dans le tag "Configuration du proxy".

  1. http://gnunux.info/dotclear2/index.php?post/2010/08/30/Mecanisme-de-clef-obligatoire-par-utilisateur-sous-Mozilla-Firefox

Présentation de Gaspacho

Gaspacho est un projet libre (GNU GPL v3) destiné à configurer les postes clients d'une entité.

Le but du projet est de configurer indifféremment un ensemble de logiciels et systèmes différents avec des choix déterminés par l'administrateur.

Un exemple simple de configuration : le proxy.

Si l'on veut configurer le proxy sur un ensemble de logiciels et systèmes, cela peut devenir assez rapidement rébarbatif. Il faut le faire souvent dans plusieurs applications (même si la plupart savent utiliser les variables globales du système).

Dans Gaspacho, il sera possible de définir une fois la configuration du proxy pour que l'ensemble des logiciels compatibles soient correctement configuré.

Gaspacho est composé de 2 parties :

  • un serveur de configuration ;
  • un agent sur le poste client.

La configuration se fait via une interface web. L'agent, installer sur le poste client, sera chargé de convertir les choix en fichiers de configuration, clef gconf, entrée dans la base de registre, ...

Plan :

Les concepts

  1. les règles et leurs propriétés
  2. les groupes
  3. les choix

Je présenterais Gaspacho au JDLL 2010 : http://www.jdll.org/content/configuration-centralis%C3%A9e-des-postes-clients-avec-gaspacho

Plus d'informations sur le site du projet : http://www.gaspacho-project.net/

lundi, août 30 2010

Mécanisme de "clef obligatoire" par utilisateur sous Mozilla Firefox

Je cherche depuis deux jours comment avoir un mécanisme de "clef obligatoire" (mandatory key) par utilisateur avec Mozilla Firefox.

Mon but est de pré-configurer des postes clients Firefox suivant l'utilisateur qui s'y connecte.

Le plus simple est de modifier le fichier "prefs.js" dans le profile utilisateur se trouvant dans le répertoire personnel de l'utilisateur. Le problème c'est que l'utilisateur aura la possibilité de modifier les paramètres. A chaque connexion il verra son paramétrage disparaître sans forcement comprendre.

Il existe un second fichier "user.js" qui prévaut sur le fichier "prefs.js". Cela signifie que l'utilisateur peut modifier les paramétrages, mais ceux-ci ne s'appliquent ni maintenant, ni après redémarrage. C'est assez perturbant.

La troisième solution est d'utiliser le mécanisme de verrou. Mais le fichier de verrou est global pour tous les utilisateurs. Impossible alors de personnaliser quoi que ce soit.

Après recherche, je suis parvenu a réalisé ce que je souhaite.

Voici la méthodologie :

Commençons par ajouter le support des "clefs obligatoires" :

Dans le fichier, /usr/lib/xulrunner-x.x.x.x/greprefs/all.js (sous Mandriva en tout cas, il est possible que ce répertoire soit directement dans le répertoire de firefox), ajouter :

pref("general.config.filename", "mozilla.cfg");
pref("general.config.obscure_value", 0); 

Cela permet d'ajouter le support du fichier "mozilla.cfg". C'est ce fichier qui est censé contenir les "clefs obligatoires" global pour tous les utilisateurs. L'option "obscure_value" est à "0" pour éviter l'avoir à le convertir en ROT13 (sécurité par obscurantisme inutile).

Pour avoir un support multi-utilisateur, j'ajoute dans le fichier /usr/lib/firefox-x.x.x/mozilla.cfg :

//
var env_user = getenv("USER');
lockPref("autoadmin.global_config_url", "file///etc/firefox/"+env_user+".js");

(attention, le "//" au début du fichier semble obligatoire).

EDIT : sous Windows, il faut visiblement : var env_user = getenv("USERNAME"); (non testé). Pour un support multi-platforme il est alors possible de faire :

if(getenv("USER") != "") {
  // *NIX settings
  var env_user = getenv("USER");
} else {
  // Windows settings
  var env_user = getenv("USERNAME");
}

Il est alors possible d'avoir un fichier de configuration par utilisateur. Dans le fichier /etc/firefox/nom_de_l'utilisateur.js, mettre des clefs commençant par lockPerf (penser à la première ligne "//").

Pour les clefs, vous pouvez utiliser les informations de cette page : http://www.pcc-services.com/kixtart/firefox-lockdown.html.

Reste un soucis de taille ... à la prochaine mise à jour de Firefox ... il faudra reconfigurer le fichier all.js ...

Si quelqu'un à une solution pour cette limitation, je suis intéressé.