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

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

Nahuel ANGELINETTI nahuel at altnetvision.info
Lun 7 Mai 18:04:41 CEST 2007


Yop,

On ne pourrait pas avoir tout stocké dans une BDD, et à chaque modif on
regénère le fichier qui va bien ?
Cela permettrait de ne pas avoir à parser les fichiers et avoir tout
bien organiser comme on veut.
Bien évidement ce sera chaque module qui gérerait sa config dans des
tables qu'il garderait à jour.



Le Mon, 07 May 2007 09:18:49 +0200,
Benjamin Sonntag <benjamin at alternc.org> a écrit :

> Salut,
> 
> The Anarcat a écrit :
> > J'ai aussi commité une config plus simple, avec tout sur le même
> > serveur. Du coup, j'ai complexifié au maximum la config "cluster",
> > pour vous donner une idée.
> >
> > https://alternc.org/svn/alternd/trunk/doc/dev/simple_configuration.png
> > https://alternc.org/svn/alternd/trunk/doc/dev/simple_configuration.dia
> >
> >   
> Excellent, je ne m'attendais pas à ce que cela ressemble autant à mon
> braindump d'hier ;)
> > Ce qui est chouette avec l'utilisation de puppet, c'est qu'entre les
> > deux configurations, il n'y a pas une grosse différence d'efforts
> > pour le déploiement, c'est parfaitement "scalable", pour vu qu'on
> > tient les choses bien en ordre...
> >   
> oui
> > Si les choses ne sont pas bien comprises dans mes dessins affreux
> > et ne respectant aucune forme de standard, faites-moi signe, car je
> > crois que c'est une voie extrêmement intéressante à prendre.
> >   
> compris, et très intéressant.
> > Notez bien que dans les deux configurations, le gros du travail va
> > comme suit, pour ce qui est du codage d'AlternD:
> >
> >  1. codage d'un paquet de recettes pour puppet, afin qu'il sache
> > comment configurer postfix, bind, courier, vhosts apache, etc
> >  2. codage d'une interface web pour la création de vhosts, qui va
> > écrire et gérer des recettes puppet (qui peuvent être stockées en
> > LDAP, en passant)
> >   
> je suis heureux de voir que tu n'as pas mis LDAP dans ton schéma ;) (à
> mon avis trop compliqué à gérer pour le peu que cela apporte ...)
> Notamment parce que puppet ne gère ldap que pour y stocker quelques
> rares informations sur ses nodes, que l'on pourra tout aussi bien
> coller dans quelques recettes de quelques lignes, et qui ne changent
> pas tout les jours, y compris sur un cluster AlternC de 10 machines
> comme celui de Lautre Net ...
> http://reductivelabs.com/trac/puppet/wiki/LdapNodes
> 
> 
> >  3. codage d'une interface web pour gérer les comptes usagers
> > (comptes pop, redirections, FTP, permissions, etc)
> >
> > Selon moi, chaque utilisateur créé devrait avoir un ACL lui donnant
> > droit (ou non) à gérer certains domaines, à avoir un certain nombre
> > de mails (quotas bonjour), FTP, etc, etc, mais tout centralisé dans
> > le même usager au lieu d'avoir tout ça déconnecté.
> >
> > Ces comptes usagers ne sont pas stockés dans Puppet, mais dans une
> > base de données externe, dont Puppet n'a pas grand chose à faire
> > anyways.
> >
> > Pour les domaines, par contre, je ne suis pas certains. Selon moi,
> > initialement, ils pourraient se tenir dans les recettes puppet. Ça
> > serait plus facile à gérer, et ça serait plus transparent que
> > d'avoir une copie dans une BD mysql. Anyways, à terme ces recettes
> > peuvent se retrouver dans LDAP si on a besoin d'une config plus
> > complexe (e.g. 1000+ domaines).
> >   
> Le problème de mettre cela dans des recettes puppet, c'est que ce sont
> des fichiers texte. puppet étant destiné à être utilisé directement
> par des admins-sys, on retrouve des fichiers texte visibles par un
> admin-sys, et peu facilement décodables par un programme. Ce que l'on
> peut faire tenir dans puppet, à mon avis, se sont les templates qui
> génèreront les recettes à partir de la base de données. Sinon il faut
> écrire un writer/parser de recettes ...
> Par ailleurs, cela rend le code entre le bureau web et la base de
> données des domaines beaucoup plus léger.
> 
> L'avantage de puppet est vraiment de disposer d'un outil qui va
> modifier les config, s'assurer de la stabilité de ce point, et
> reloader les services pour nous.
> 
> Après, pour la gestion des 1000+ domaines hébergés sur LautreNet, je
> ne sais pas trop si les auteurs de puppet ont quelque chose en tête
> sur la manière de procéder. Je pense que l'on devrait prendre le
> temps de les contacter (irc leur semble habituel, je viens d'arriver
> sur leur chan pour lurker un peu). En fait, je pensais à bind et à
> ses fichiers zones, et me rend compte qu'avec myDNS, on a pas ce
> problème (il tape direct en base les zones). J'en viens à me dire que
> ce type de problème sera du ressort de chaque module d'altrnc
> pilotant un logiciel donné.
> 
> Par ailleurs, tous les cas que l'on évoque pour l'instant parlent soit
> d'un AlternC monoserveur, soit de config multiserveurs typiquement en
> HA/HP. Or, de mon côté, j'ai un cas plus retors : j'ai en fait une
> vingtaine de serveurs sous AlternC, chacun avec sa base système, bref,
> 20 serveurs indépendants. Comment pourrais-je centraliser un peu la
> config ? voir "gagner du temps d'admin sys grace a puppet" ?
> 
> 
> Ensuite un détail : je ne vois pas puppetmaster piloter le DNS
> secondaire, tout simplement parce que, par exemple,
> secondary.heberge.info est secondaire pour une vingtaine de serveurs
> AlternC, et qu'il me parait difficile de donner à 20 puppetmasters :)
> l'accès à cette machine (... en fait ca n'est pas possible et pas fait
> pour) d'autant qu'elle n'est pas gérée par les mêmes admins, ce qui me
> parait assez habituel comme façon de procéder dans le monde du DNS. Je
> vois plutot garder le système actuel (autoriser un serveur distant à
> accéder à la liste des domaines hébergés, qu'il synchronise
> régulièrement, et autoriser sur le serveur dns les axfr depuis des ips
> habilités)
> (c'est un détail, mais autant en tenir compte)
> 
> Enfin :
> 
> - que veux tu dire par : "(mails, FTP, etc, etc,) mais tout centralisé
> dans le même usager au lieu d'avoir tout ça déconnecté."
> parles-tu d'usager unix ? que veux-tu dire par "déconnecté" ?
> 
> - Si j'ai bien compris ton schéma, on n'a plus de démon AlternD, c'est
> le httpd qui pilote les fichiers de puppetmaster, le même httpd qui
> sert les pages web aux internautes ?
> Je pensais que l'on voulait avoir un endroit déconnecté du httpd
> habituel, qui serait par exemple un demon en python qui fournirait du
> rest/xml-rpc, et serait chargé de tout cela ?
> En gros, il serait le lien entre un bureau web tout léger sans droit
> particulier, et les recettes puppet et las base de données système que
> l'on ne voulait pas trop exposer.
> Cela dit, dans ton schéma multiserveurs, le httpd de config (utilisé
> par l'admin) n'est pas non plus le webnode. Je pense donc qu'il
> serait bon d'expliciter cela.
> 
> 
> > Voilà... Je crois que c'est très important de réfléchir comme il
> > faut avant de d'asseoir et écrire du code (je considère des APIs
> > comme du code). On est encore beaucoup à l'étape du design et de la
> > réflexion, et si on saute cette étape, on est aussi bien de joindre
> > une autre équipe de développement, car repartir à neuf, sans plan,
> > ça nous amène nulle part.
> >   
> oui, réfléchissons.
> 
> 
> @+
> 
> Benjamin Sonntag
> 
> Menu v2 : https://alternc.org/wiki/Version2.0
> Logiciels : https://alternc.org/wiki/AlternCSpecsV2
> Api : https://alternc.org/wiki/ApiV2
> WebGui : https://alternc.org/wiki/InterfaceUtilisateur
> 
> _______________________________________________
> Dev mailing list
> Dev at alternc.org
> http://alternc.org/cgi-bin/mailman/listinfo/dev


-- 
Nahuel ANGELINETTI
Association ~altNetVision
Jabber/XMPP : nahuel at ahtna.org



Plus d'informations sur la liste de diffusion Dev