|
Taille: 3027
Commentaire: relancer la discussion ?
|
← Version 15 à la date du 2008-02-21 22:10:05 ⇥
Taille: 3150
Commentaire: converted to 1.6 markup
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| ||<#ffa000> Cette étude a finalement débouché sur l'utilisation de [[Git]]. On laisse cette page uniquement pour mémoire... || |
|
| Ligne 5: | Ligne 7: |
| But : garder un historique des modificatios des fichiers de configuration de chaque serveur. Pour * pouvoir revenir en arrière |
But : garder un historique des modifications des fichiers de configuration de chaque serveur. Pour * documenter sans peine l'évolution de son réseau :-) |
| Ligne 8: | Ligne 10: |
| * documenter sans peine l'évolution de son réseau :-) | = Proposition de méthodologie pour la gestion des /etc en svn = == Proposition de schéma global, suite à une 'tite discussion avec Thomas == * svn local à chaque serveur * un serveur svn/trac central, sur un réseau protégé, qui se synchronise (pull) et consolide les données, en excluant éventuellement les fichiers "sensibles" via une liste centralisée, plus faicle à maintenir (/etc/passwd, /etc/shadow, fichiers avec mot de passe). Voir comment faire le merge des différents repository ? ou les garder côte à côté ? bof * à côté de cela, un [[Aide]] ultra minimal, pour éviter l'avalanche de mails, pour le suivi des chgt de permissions == fonctionnement général == * on ne touche pas aux repertoire de référence ({{{/etc}}} ou autre) : rsync vers un répertoire "de travail" : éviter les accidents, et de poluer les répertoires de travail avec des {{{.svn}}} * un paquet debian qui fera l'initialisation du déport, mise en place des fichiers de conf, hooks mail, etc * configuration dans {/etc/svnconf/} : * {{{ignore}}} : fichiers à ne pas rsyncer : seront ignorés complétement, avec même l'étape svn (passé tel quel à {{{rsync --exclude-from=}}} * {{{config}}} : Répertoires à surveiller. Espace intermédiaire. Emplacement du dépôt svn. quoi d'autre ? = Package debian "svnconf" = * init : ok * purge : virer les fichiers svn ou non ? question debconf ? * mail-hook : question debconf * création du /etc/svnconf/config : via debconf == description "svnconf" === ''ce que ça fait déjà'' |
| Ligne 13: | Ligne 44: |
| * ProgFou : [[http://svn.haxx.se/users/archive-2004-06/1064.shtml un début de solution]] mais c'est surtout la [[http://svn.haxx.se/users/archive-2004-06/1065.shtml la réponse]] qui me paraît intéressante | |
| Ligne 16: | Ligne 45: |
| * Autre voie qui me semble interressante : [[http://svn.collab.net/repos/svn/trunk/contrib/client-side/asvn asvn]] et [[http://subversion.tigris.org/faq.html#in-place-import in-place-import]] : relativement simple (à mon avis) et ça '''semble''' marcher. à creuser. asvn pourrait être un bon candidat pour inclusion dans PackageDebianServeurAuf En fait le //in-place-import// est l'usage normal de [[svn]], ou tout de moins celui que j'ai toujours fait : ça vient naturellement à l'idée quand on utilise [[svn]]. -- ProgFou * Pour asvn je sais pas... En fait je me demande si on veut vraiment que SVN remplace un backup ou serve simplement au suivi. Il faut voir aussi si le "svn diff" montrera bien les changements de propriétés, vu qu'elles ne sont apparement enregistrées que lors du //commit//... À tester donc. -- ProgFou * Si SVN pouvait faire backup en même temps, ça serait pas mal, quand même. -- TN bof... notre système de backup actuel fait déjà bien ce boulot là -- J. * autre idée, plus simple (ou plutôt, que je préfere :-D) : svn de base pour le suivi du *contenu* des fichiers, et traiter la question des permissions / droits à part (avec Aide/Tripwire, par exemple) ou ne pas la traiter du tout. Je crois que je vais partir là-dessus dans un premier temps -- J. * C'est surtout le point à propos de la traçabilité de l'orginie des modifications qui me parait important. Voir si on peut avoir la même chose en utilisant tout simplement le contenu de $USERNAME ? |
(problème mis de côté pour le moment) |
| Ligne 35: | Ligne 55: |
| = Proposition de méthodologie pour la gestion des /etc en svn = création : import commande aprés modif' : ci revenir en arriere : revert, co vérifier les dernieres modif's : diff vérifier qu'il n'y a pas de modif' non enregistrée : diff diff avec la version de telle date |
|
| Ligne 46: | Ligne 57: |
| * le faire en vrai, et voir ce que ça donne vraiment ? | * le faire en vrai, et voir ce que ça donne vraiment ? en cours de test "usage quotidien" sur mail-dakar.refer.sn et backup.sn.auf, voir si c'est trop pénible, ou gérable, ou si, pourquoi pas, ça peut servir à quelquechose ? * un peu d'enrobage, un 'tit paquet debian ? cf http://trac.sn.auf.org/svnconf (début de début de début de début pour le moment) * Voir comment faire le merge des différents repository * synchro des svn : via commandes svn, ou rsync ? |
Cette étude a finalement débouché sur l'utilisation de Git. On laisse cette page uniquement pour mémoire...
Suivi via SVN des configurations serveurs
histoire de relancer la discussion
But : garder un historique des modifications des fichiers de configuration de chaque serveur. Pour
documenter sans peine l'évolution de son réseau
- comprendre la source d'un problème
Proposition de méthodologie pour la gestion des /etc en svn
Proposition de schéma global, suite à une 'tite discussion avec Thomas
- svn local à chaque serveur
- un serveur svn/trac central, sur un réseau protégé, qui se synchronise (pull) et consolide les données, en excluant éventuellement les fichiers "sensibles" via une liste centralisée, plus faicle à maintenir (/etc/passwd, /etc/shadow, fichiers avec mot de passe). Voir comment faire le merge des différents repository ? ou les garder côte à côté ? bof
à côté de cela, un Aide ultra minimal, pour éviter l'avalanche de mails, pour le suivi des chgt de permissions
fonctionnement général
on ne touche pas aux repertoire de référence (/etc ou autre) : rsync vers un répertoire "de travail" : éviter les accidents, et de poluer les répertoires de travail avec des .svn
- un paquet debian qui fera l'initialisation du déport, mise en place des fichiers de conf, hooks mail, etc
- configuration dans {/etc/svnconf/} :
ignore : fichiers à ne pas rsyncer : seront ignorés complétement, avec même l'étape svn (passé tel quel à rsync --exclude-from=
config : Répertoires à surveiller. Espace intermédiaire. Emplacement du dépôt svn. quoi d'autre ?
Package debian "svnconf"
- init : ok
- purge : virer les fichiers svn ou non ? question debconf ?
- mail-hook : question debconf
- création du /etc/svnconf/config : via debconf
== description "svnconf" ===
ce que ça fait déjà
Questions et problèmes à résoudre
Préservation des uid.gid de chaque fichier
- (problème mis de côté pour le moment)
Repository central ou propre à chaque machine ?
- argument pour le local à chaque machine : évite d'avoir un svn centrale accessible en lecture/écriture depuis chaque serveur. (même soucis que l'accés à un serveur de backup central, en fait)
- argument pour le central :
- tout en un seul point, plus facile pour faire des comparaisons entre plusieurs bécanes (vraiment ?)
- permettrait d'installer un serveur trac pour faciliter le suivi d'un réseau
Actions suivantes
- le faire en vrai, et voir ce que ça donne vraiment ? en cours de test "usage quotidien" sur mail-dakar.refer.sn et backup.sn.auf, voir si c'est trop pénible, ou gérable, ou si, pourquoi pas, ça peut servir à quelquechose ?
un peu d'enrobage, un 'tit paquet debian ? cf http://trac.sn.auf.org/svnconf (début de début de début de début pour le moment)
- Voir comment faire le merge des différents repository
- synchro des svn : via commandes svn, ou rsync ?