Suivi via SVN des configurations serveurs

histoire de relancer la discussion

But : garder un historique des modificatios des fichiers de configuration de chaque serveur. Pour

• pouvoir revenir en arrière
• comprendre la source d'un problème

• documenter sans peine l'évolution de son réseau

Questions et problèmes à résoudre

Préservation des uid.gid de chaque fichier

• 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

• 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 ?

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

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

mini doc svn à faire

ATTENTION SI VOUS VOULEZ TESTER, NE LE FAITES PAS SUR UN VRAI SERVEUR :BR COMME TOUTE EXPERIMENTATION SUR UN SERVEUR EN PRODUCTION, UNE MAUVAISE MANIPULATION PEUT DETRUIRE VOTRE /etc !!

Création du dépôt svn (à faire sur chaque serveur)

Standardiser avec le même répertoire sur chaque serveur (dans un repertoire /srv/svn/, par exemple)

Plutôt travailler sur une copie de etc, pour limiter les accidents, et ne pas polluer ce repertoire avec les .svn/

# création du dépôt
% svnadmin create /srv/svn 
# racine du dépôt
% svn mkdir file:///tmp/svn/base -m "création" 
# pour ajouter la racine au système svn
% svn co file:///tmp/svn/base . 
# faire une première copie
% rsync -av /etc/ /var/backups/etc/
# ajouter le répertoire /etc au système svn
% cd /var/backups
% svn -N add etc
% svn propedit svn:ignore etc
<lister les fichiers à ne pas faire gérer par svn, pour diverses raisons (par exemple : mtab, ou passwd, passwd-, shadow, shadow- sur certains serveurs où ce suivi n'est pas voulu)>
# ajouter à svn le contenu du /var/backups/etc
% svn --force add etc/ 
# premier commit : les fichiers sont effectivement enregistrés dans svn
% svn commit -m "version initiale"

Les des fichiers à ignorer, et pourquoi

Vérification nocturne qu'aucun commit n'a été oublié

% cat >/etc/cron.daily/verification-svn
#!/bin/sh
rsync -a --delete --exclude .svn /etc/ /var/backups/etc/
cd /var/backups/etc
svn status
% chmod 755 /etc/cron.daily/verification-svn

Aprés une série de modification dans /etc

% cat >/usr/local/bin/commmit-conf
#!/bin/bash

if [ -n "$SUDO_USER" ] ; then
  USER="$SUDO_USER"
fi

if [ -z "$USER" -o "$USER" = "root" ] ; then
  echo 'tu es qui, toi ?'
  exit
fi

rsync -a --delete --exclude .svn /etc/ /var/backups/etc/

cd /var/backups/etc

svn commit --username "$USER" $*

Revenir en arrière

attention aux permissions

Vérifier les dernières modifications

• diff

Actions suivantes

• le faire en vrai, et voir ce que ça donne vraiment ?
• Voir comment faire le merge des différents repository
• synchro des svn : via commandes svn, ou rsync ?