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/ld.so.cache
   /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>"

6. On configure sudo pour qu'il ne supprime pas les variables d'environnement de git :

   # une ligne à ajouter au début de /etc/sudoers :
   Defaults env_keep += "GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL"

Utilisation

• A ajouter dans son ~/.bashrc (puis se reloger pour activation) :

  # à ajouter à la fin de son fichier ~/.bashrc :
  export GIT_COMMITTER_NAME="Prenom NOM"
  export GIT_COMMITTER_EMAIL="prenom.nom@auf.org"

• Pour voir les modifications :

  $ sudo git status -a      # affiche la ligne des fichiers modifiés, supprimés, nouveaux...
  $ sudo git diff           # affiche les différences entre la version stockée dans git et la version actuelle

• Pour enregistrer les modifications :

  $ sudo git commit un/seul/fichier/modifié   # pour un fichier : toujours en notation relative
  $ sudo git commit -a                        # on enregistre *toutes* les modifications

• Pour suivre un nouveau fichier :

  $ sudo git add le/chemin/relatif/vers/le/fichier/ou/repertoire
  $ sudo git commit

  • Attention : il faut éventuellement modifier le fichier /.git/info/exclude

• Pour revoir les modifications, plusieurs techniques en ligne de commande :

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

• Note : la plupart du temps, il est plus simple de prendre l'habitude de se placer à la racine pour faire les manipulations git. Un exemple typique :

  $ cd /etc                              |
  $ sudo vi profile                <-----| ici on travaille
  $ sudo vi postfix/main.cf              |
  $ cd /     
  $ sudo git status -a                   | on fait un cd /
  $ sudo git diff | less           <-----| puis on documente
  $ sudo git commit -a                   | son travail ...

Quelques automatisations

• Pour lancer un "status" à chaque connexion sur le serveur (très très utile) :
  1. Permettre aux gens du groupe "admin" de lancer git status sans mot de passe :

     # à ajouter à la fin de /etc/sudoers :
     %admin ALL=(ALL) /usr/bin/git status -a

  2. Lancer le git status dans le /etc/profile, via sudo :

     (... extrait de /etc/profile ...)
     if [ "$PS1" ]; then
       (...)
     # les lignes a ajouter -------------------------------------
     # lancement de git commit si l'utilisateur est dans le groupe admin
       if $(id -Gn | grep -q admin); then
         (cd / && sudo /usr/bin/git status -a) 
       fi
     # fin des lignes a ajouter ---------------------------------
     fi
     (...)

Un serveur gitweb central (idée pour plus tard...)

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 et un peu sécuriser : 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 à trouver

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