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. > 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 :) _______________________________________________ Project mailing list [email protected] https://mail.gna.org/listinfo/project
