On Mon, Oct 05, 2009 at 04:57:50PM +0200, Vincent Caron wrote: > On Mon, 2009-10-05 at 16:09 +0200, Sylvain Beucler wrote: > > On Mon, Oct 05, 2009 at 03:50:59PM +0200, Vincent Caron wrote: > > > OK, donc si ça n'est pas sous contrôle d'un package, je fais "svn > > > commit". J'ai toujours eu du mal à suivre Yeupou entre les contrôles > > > RCS, SVN et le packaging... > > > > ;) > > > > D'ailleurs j'ai dû désactiver un ou deux dépôt RCS, ce serait des > > choses à passer dans les paquets gnapgnap-* éventuellement. > > > > > > J'ai un avis encore mitigé sur ces paquets. J'aime bien: > > > > - la gestion des dépendances (qui m'empêche, par exemple, de supprimer > > 'libgd-graph-perl' en pensant qu'il n'est pas utilisé) > > > > - partager les fichiers de configuration (et s'assurer qu'il s'agit de > > la version courante, pas d'une vieille copie) > > > > - fournir du réutilisable > > > > - utiliser dpkg car il permet à d'autres personnes de faire des > > modifications facilement pour leur installation dans les fichiers de > > configuration > > > > Je n'aime pas: > > > > - utiliser dpkg ;) car il ne supprime pas automatiquement les vieux > > fichiers de configuration (en cas de renommage notamment), ce qui > > oblige à un nettoyage manuel après une mise à jour > > > > - le côté fastidieux (installer un paquet pour modifier une ligne de > > configuration) > > > > - les risques d'écrasement des modifications locales (bin/gnapak.pl > > par exemple) > > > > - avoir un seul paquet source: la moindre modification (source) dans > > un système implique une mise à jour (binaire) de tous les systèmes > > C'est bien détaillé, je "plusse". > > De manière générale pour déployer (aka installer+mettre à jour) du > "programme", dpkg/apt vaut vraiment l'effort dès que le nombre de > machines/chroots est supérierur à 2. > > Par contre pour gérer des configurations, je préfère largement des > copies de travail SVN. Ca permet de modifier "sur place" et très > facilement répliquer sur les autres machines.
Toute la question est d'avoir un dépôt entremélé dans /etc :) Il y a des gens qui mettent tout /etc dans un VCS, mais là on parle de maintainer _quelques_ fichiers seulement. > > On m'a parlé de Puppets récemment, mais je n'ai pas bien compris la > > portée de ce projet - si vous avez un avis sur la question ça > > m'intéresse :) (http://reductivelabs.com/products/puppet). > > J'ai vu une présentation aux RMLL et j'ai un peu regardé (je lorgne > aussi sur CFengine depuis longtemps) > > Je n'aime pas trop la façon dont ça réinvente des roues, notamment > avec son propre DSL qui ne semble pas justifié, et des solutions qui ne > correspondent pas à mes problèmes (je gère actuellement ~150 Debian). > > C'est aussi un système "pull" où les serveurs vont de temps en temps > chercher des infos et se "reconfigurer". Ca écrase en permanence les > fichiers de conf. Je trouve ça pas très élégant et incompatible avec les > humains, et franchement je n'ai pas encore trouvé comment me passer d'un > coup de ssh r...@xxx pour diagnostiquer/réparer. Et avec un truc qui te > marche sur les pieds > > Pour le moment je travaille sur un outil qui me permet d'assez > facilement exécuter un script sur N machines, 100 < N < 1000. Ca me > permet de continuer à travailler à peu près de la même façon, mais > passer à l'échelle supérieure et traiter les serveurs en lots > efficacement. Je trouve ça assez satisfaisant, ça me permet de passer > 90% de mon temps à réfléchir un problème et implémenter une solution, > l'appliquer redevient un détail, et j'ai rien de nouveau à apprendre - > et surtout faire apprendre à mes 7 acolytes. AMHA c'est tout ce qui > compte :) Je suis plutôt du même avis :) Ça a plutôt l'air adapté à des configurations "clusters" avec beaucoup de machines identiques, donc pas très adapté. -- Sylvain _______________________________________________ Project mailing list [email protected] https://mail.gna.org/listinfo/project
