[AlternC-dev] Alternc 2.0 & Puppets : Howto ?

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Benjamin Sonntag benjamin at alternc.org
Dim 6 Mai 20:24:00 CEST 2007


Alternc 2.0 & Puppets : Howto ?

Ayant testé puppet (puppetd et puppetmaster) sous divers angles, je suis
en train de réfléchir à l'utilisation de ce logiciel (fabuleux) pour
AlternC v2.0
Puppet est très pratique pour administrer de manière centrale un ou
plusieurs serveurs, pour s'assurer que leurs fichiers de configurations
et les services réseau sont correctement configurés etc.

Puppet fonctionne avec
    - des recettes (posées dans un dépot de recette, nommé manifeste)
applicables par hote ou groupe d'hote, qui peuvent faire tout et
n'importe quoi (droits, fichiers, patchs divers, dossiers, commandes etc.)
    - des fichiers ou archives servies par le puppetmaster via un
protocole ssl home-made puppet://
    - des modèles interprétés avec des balises dedans.

Très pratique pour déployer des fichiers de conf ou pour les patcher et
vérifier que ces patchs restent, puppet me parait aussi un peu adapté
aux cas simples comme Bind (création / modif / effacement de fichiers
zones) mais pas du tout adapté à des trucs comme gérer la liste des
emails pops dans des fichiers plats ou bases de données.

Donc, puppet permettra de gérer la configuration des services, mais
surement pas la liste des hébergements ...

Reste donc à définir :

- Les logiciels que l'on souhaite utiliser pour la V2 (postfix, certes,
mais named ou mydns ?, courier ou cyrus ? etc.)
- Quelle partie de chaque logiciel est gérée par Puppuet, et quelle
partie par une base de donnée par exemple
- Comment intéragit-on entre les services, le Puppet, la base MySQL, le
serveur AlternD, le bureau virtuel (situé au dessus de tout cela)

Un petit dessin en prime de ce que je pense :

https://alternc.org/chrome/site/alterncv2_1.jpg

J'imagine donc un zoli AlternD écrit en python, modulaire, qui contient
le minimum, la gestion des users & des droits, qui sert en xml rpc des
fonctions d'API commune (domaines, mails & co) et pilote en dessous les
modules par service (bind, cyrus, apache etc.)

Je propose que l'on commence par une liste des softs que l'on souhaite
intégrer nativement dans la v2, et que l'on découpe cela en modules,
avec une API précise, pour que l'on puisse se découper les devs ...

Une branche neuve, des packages neufs (on pourra copier/coller depuis la
v1 si besoin hein ...)

Un bureau PHP neuf, utilisant xml-rpc et ce que vous voulez comme
template ou autre.

Je commence sur la liste des softs et les specs de la v2 sur le wiki  ...

@+

Benjamin Sonntag





Plus d'informations sur la liste de diffusion Dev