SphynxGenerateurDeConf » Historique » Version 3
Version 2 (Gwenael Remond, 02/02/2010 10:22) → Version 3/14 (Gwenael Remond, 02/02/2010 10:30)
h1. SphynxGenerateurDeConf
h2. Modélisation
_tunnel_
mise en relation de deux _extrémités_ (sphynx-amon, amon-amon, amon-autre...)
de type 1-1
_réseau sécurisé_
un _réseau sécurisé_ est composé de _n_ tunnels
Entre les deux extrémités d'un tunnel, il y a forcément un _maître_ et un _esclave_
car la configuration générée doit dépendre d'une responsabilité donnée d'un côté (et pas des deux).
h2. La génération des _configurations_
_configuration_
base de données, templatisée ou pas, à mettre sur une machine EOLE ou non (fichier cible identique à une base de données strongswan)
Les configurations doivent pouvoir être **aggrégées** (puisque sur un Amon par exemple il peut y avoir plusieurs tunnels)
Les configurations doivent pouvoir être **templatisées** de manière à être "instanciables", par exemple sur un EOLE, elles doivent pouvoir être générées directement sous un format compatible strongswan. (comme une configuration Era par exemple)
La sortie doit ressembler à une base tagguée de manière à connaître à tout moment le responsable du tunnel (le _maître_).
h3. outils de génération des configurations générations
L'outil de génération doit pouvoir être lancé en local (pas d'appli web), en ligne de commande ou bien une interface graphique lancée uniquement en framebuffer.
L'éditeur doit pouvoir manipuler des séries de paramètres-valeurs dynamiquement (comme dans ltsconfeditor par exemple)
h3. conhérence des configurations
Sur une machine cible, la seule vérification de cohérence est de type "ACID":http://fr.wikipedia.org/wiki/Transaction_informatique
et pas de type de cohérence d'intégrité fonctionnelle. En clair, cela veut dire que la seule vérification à faire _in fine_ c'est que les tunnels ne soient pas identiques.
*Donc le tunnel est indexé sur l'extrémité*
h2. Modélisation
_tunnel_
mise en relation de deux _extrémités_ (sphynx-amon, amon-amon, amon-autre...)
de type 1-1
_réseau sécurisé_
un _réseau sécurisé_ est composé de _n_ tunnels
Entre les deux extrémités d'un tunnel, il y a forcément un _maître_ et un _esclave_
car la configuration générée doit dépendre d'une responsabilité donnée d'un côté (et pas des deux).
h2. La génération des _configurations_
_configuration_
base de données, templatisée ou pas, à mettre sur une machine EOLE ou non (fichier cible identique à une base de données strongswan)
Les configurations doivent pouvoir être **aggrégées** (puisque sur un Amon par exemple il peut y avoir plusieurs tunnels)
Les configurations doivent pouvoir être **templatisées** de manière à être "instanciables", par exemple sur un EOLE, elles doivent pouvoir être générées directement sous un format compatible strongswan. (comme une configuration Era par exemple)
La sortie doit ressembler à une base tagguée de manière à connaître à tout moment le responsable du tunnel (le _maître_).
h3. outils de génération des configurations générations
L'outil de génération doit pouvoir être lancé en local (pas d'appli web), en ligne de commande ou bien une interface graphique lancée uniquement en framebuffer.
L'éditeur doit pouvoir manipuler des séries de paramètres-valeurs dynamiquement (comme dans ltsconfeditor par exemple)
h3. conhérence des configurations
Sur une machine cible, la seule vérification de cohérence est de type "ACID":http://fr.wikipedia.org/wiki/Transaction_informatique
et pas de type de cohérence d'intégrité fonctionnelle. En clair, cela veut dire que la seule vérification à faire _in fine_ c'est que les tunnels ne soient pas identiques.
*Donc le tunnel est indexé sur l'extrémité*