Git est un système de gestion de versions. Voir sa [http://fr.wikipedia.org/wiki/Git_(logiciel) page wikipédia]

Note : testé sur Gutsy... en cours de test sur Etch

Suivre la config d'une machine avec git

On veut pouvoir documenter les modifications faites dans /etc et dans /usr/local.

Installation

1. On installe git :

   # aptitude install git-core

2. On créée un dépôt général pour toute la machine. Attention à bien régler les droits : seul root doit pouvoir accéder au dépôt, sinon les fichiers du genre shadow seraient accessibles à tous.

   # cd /
   # git init   (ou "git init-db" sur une Debian Etch, git version 1.4)
   # chmod u=rwx,go= /.git

3. Pour éviter d'avoir des "saletés" directement à la racine (/), on déplace le dépôt. Le répertoire /.git à la racine ne sera en fait qu'un lien symbolique vers le véritable emplacement du dépôt :

   # mkdir /var/lib/git
   # mv /.git /var/lib/git/root
   # ln -s /var/lib/git/root /.git

4. On veut suivre /etc et /usr/local seulement, pour cela on modifie les exclusions au niveau du dépôt, dans le fichier /var/lib/git/root/info/exclude :

   # Le fichier /var/lib/git/root/info/exclude :
   # Par défaut, on exclut tout, sauf /etc
   /*
   !/etc
   # ... mais dans /etc on interdit certains fichiers :
   # cf "find /etc -not -perm /004 -ls"
   /etc/*shadow*
   /etc/ssh/ssh_host_*_key
   /etc/mtab
   /etc/adjtime
   /etc/sudoers
   /etc/sasldb*
   /etc/krb5.keytab
   /etc/ldap.secret
   /etc/ssl/private/*
   /etc/nut/upsd.users
   /etc/bind/rndc.key
   /etc/pipsecd/pipsecd.conf
   /etc/postfix/ssl/smtpd.pem
   /etc/samba/smbpasswd
   /etc/samba/*.tdb
   # On n'interdit pas non plus le parcours de /usr. Mais dans ce parcours,
   # on interdit tout sauf /usr/local. C'est la technique pour inclure /usr/local...
   !/usr
   /usr/*
   !/usr/local
   # quelques type fichiers à ne pas jamais considérer, globalement :
   *.dpkg-old
   *.dpkg-new
   .*.swp
   *~
   *#

5. On fait les premiers ajouts et le premier commit :

   # cd /
   # git add etc usr/local
   # git commit -m "mise en route du suivi : /etc et /usr/local" --author "moi <email@auf.org>"

Utilisation

Après chaque modification d'un fichier, enregistrer les modifications :

• # git commit -a

Si on veut suivre un nouveau fichier, ou ne committer les modifications que de ce fichier :

• # git add fichier
  # git commit

et pour un répertoire (modifier exclude si c'est en dehors de /etc ou /usr/local):

• # cd / ; git add un/reper/toire
  # git commit

Pour voir les modifications, plusieurs techniques en ligne de commande :

• # tig    <-- à installer avec aptitude install tig
  # git whatchanged
  # git log -10
  # git show ...(le code du commit)...

Quelques scripts d'automatisation (wrapper)

A ajouter dans son ~/.bashrc :

• export GIT_COMMITTER_NAME="Prenom NOM"
  export GIT_COMMITTER_EMAIL="prenom.nom@auf.org"

confcommit

attachment:confcommit

Permet une utilisation plus simple via sudo :

• trouve le nom de l'auteur/committer par les variables d'environnement GIT_ et/ou SUDO_USER

• confcommit -a : effectue un git commit -a pour committer toutes les modifications et suppression de fichiers

• confcommit -n : effectue un git add etc usr/local pour ajouter tous les nouveaux fichiers

TODO : accepter "confcommit fichier1 fichier2 ..." permettant de ne committer que tel et tel fichier, comme git commit. Mais si possible en simplifiant la syntaxe, c-a-d en acceptant des noms de fichiers absolus, p.ex. "confcommit /etc/network/interfaces".

TODO2 : par défaut, sudo flingue les variables d'environnement. Voir comment configurer sudo pour qu'il laisse les GIT_* tranquilles, si possible...

• man sudoers puis /env_keep donne à ajouter dans /etc/sudoers :

  Defaults env_keep += "GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL"

confcommit-status

attachment:confcommit-status

A lancer via un cron au moins quotidien, il donne la liste des modifications non encore enregistrées : fichiers modifiés, fichiers supprimés, nouveaux fichiers.

Un serveur gitweb central

brouillon (manip testées, ça marche, mais j'ai peut-être oublié quelques détails)

1. Installation de gitweb sur un serveur du RPV. Attention, puisqu'il permettra d'accéder à des fichiers du type shadow : accès restreint par mot de passe, éventuellement à certaines IP, voir certificat ssl si on passe en mode parano.

2. Dans /var/lib/git on créée des dépôts (un par serveur à suivre). Ces dépots appartiennent à un utilisateur "gitweb" (pas à root) qui n'a aucun autre droit.

   gitweb@serveur-git$ GIT_DIR=/var/lib/git/apollon git init-db
   gitweb@serveur-git$ ln -s /var/lib/git/apollon /var/cache/git/apollon     # prise en compte par gitweb

3. On met les clés publiques des comptes root des serveurs dans /home/gitweb/.ssh/authorized_keys

4. Pour synchroniser le dépôt local d'un serveur avec le dépôt sur le serveur gitweb :

   # git push --all ssh://gitweb@serveur-gitweb/var/lib/git/apollon

5. C'est tout.

Idée pour simplifier : procéder comme pour les backups, c-à-d par git-pull depuis le serveur. Si on installe ça sur la même machine que backuppc (ce n'est pas illogique) c'est simple, vu que backuppc a déjà un accès root aux machines. Question pour Tini : backuppc accepte-t-il les "hooks" dans son système de backup ? Ca serait sympa de pouvoir lancer le git-pull en même temps que la sauvegarde par backuppc.

Améliorations à prévoir

• interfaçage avec apt : voir http://bryan-murdock.blogspot.com/2007/07/put-etc-under-revision-control-with-git.html

• hooks à comprendre : envoyer un mail à chaque commit, synchroniser avec le gitweb à chaque commit, etc...