Modifications entre les versions 51 et 64 (s'étendant sur 13 versions)
Version 51 à la date du 2008-02-14 16:32:46
Taille: 10420
Commentaire: le fichier correct pour les variables d'environnement est .bash_profile et il est plus correct de laisser GIT_COMMITTER_* au compte local réel, qui est celui qui fait effectivement le commit
Version 64 à la date du 2008-11-17 12:46:59
Taille: 5738
Éditeur: ThomasNoël
Commentaire: là, c'est ok ?
Texte supprimé. Texte ajouté.
Ligne 1: Ligne 1:
Git est un système de gestion de versions. Voir sa [http://fr.wikipedia.org/wiki/Git_(logiciel) page wikipédia]   ||<#FFFF50> '''APPEL A PARTICIPATION AUX TESTS DE DÉPLOIEMENT''' :<<BR>> Mettez ce système en place en suivant les sections « Installation automatisée » et « Utilisation ».<<BR>> En cas de problème, signalez-le immédiatement via la liste de discussion technique de l'AUF. ||
Ligne 3: Ligne 3:
= Suivre la config' d'une machine avec git = = Introduction =
Ligne 5: Ligne 5:
On veut pouvoir documenter les modifications faites dans `/etc` et dans `/usr/local`, qui sont grosso modo les deux répertoires permettant de décrire comment fonctionne un serveur. Cette documentation est indispensable en cas d'administration à plusieurs, mais elle est également très utile quand on est seul à gérer : c'est un aide-mémoire indispensable vu la vitesse à laquelle évoluent les technologies et donc les configurations. On veut pouvoir documenter les modifications faites dans `/etc` et dans `/usr/local`, qui sont ''grosso modo'' les deux répertoires permettant de décrire comment fonctionne un serveur. Cette documentation est indispensable en cas d'administration à plusieurs, mais elle est également très utile quand on est seul à gérer : c'est un aide-mémoire indispensable vu la vitesse à laquelle évoluent les technologies et donc les configurations.
Ligne 9: Ligne 9:
Il existe différents logiciels de ce type, parmis lesquels on peut citer l'ancètre CVS, son fils Subversion (`svn`), et dans une famille différente `git`. C'est ce dernier logiciel que nous avons choisi car il est moins bavard, moins intrusif dans le code à surveiller, et surtout très bien documenté. Il existe différents logiciels de ce type, parmis lesquels on peut citer l'ancètre RCS, son fils CVS, son petit-fils Subversion (`svn`) et dans la génération qui vient d'arriver : `git`. C'est ce dernier logiciel que nous avons choisi car il est moins bavard, moins intrusif dans le code à surveiller, et surtout très bien documenté.
Ligne 12: Ligne 12:
''A écrire : petites explications sur la notion de dépôt, orientée git et surveillance de /etc'' '''Notre objectif est d'installer et de configurer `git` pour que s'administrateur d'un serveur puisse aisément faire le suivi de sa configuration.'''
Ligne 14: Ligne 14:
Notre objectif ici est d'installer `git` sur un serveur pour que son ou ses administrateurs, et uniquement eux, puissent aisément faire le suivi de sa configuration. = Installation automatisée (paquet auf-git-etc) =
Ligne 16: Ligne 16:
== Installation == Vous avez maintenant à votre disposition un paquet Debian [[http://git.auf.org/?p=auf-git-etc.git|réalisé en interne à l'AuF]].
Ligne 18: Ligne 18:
 1. On installe `git` : Pour profiter de ce paquet il vous suffit de créer un fichier `/etc/apt/sources.list.d/auf.list` avec le contenu suivant :
Ligne 20: Ligne 20:
# aptitude install git-core deb http://apt.auf.org/ etch auf
Ligne 23: Ligne 23:
 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. Puis de lancer les commandes suivantes :
Ligne 25: Ligne 25:
# cd /
# git init (ou "git init-db" sur une Debian Etch, git version 1.4)
# chmod u=rwx,go= /.git
# aptitude update # ignorer le message d'avertissement
# aptitude install auf-keyring # accepter l'installation "non signée"
# aptitude update # aucun message d'avertissement ne doit s'afficher
# aptitude install auf-git-etc
Ligne 30: Ligne 31:
 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 : = Utilisation =

== Configuration préliminaire ==

Ajouter les lignes suivantes dans son `~/.bash_profile`, puis se reloguer pour activation :
Ligne 32: Ligne 37:
# mkdir /var/lib/git
# mv /.git /var/lib/git/root
# ln -s /var/lib/git/root /.git
# lignes à ajouter à la fin de son fichier ~/.bash_profile (puis se reloguer pour activation) :
export GIT_AUTHOR_NAME="Prenom NOM"
export GIT_AUTHOR_EMAIL="prenom.nom@auf.org"
Ligne 37: Ligne 42:
 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/ld.so.cache
# 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
*~
*#
}}}
== Utilisation au quotidien ==
Ligne 63: Ligne 44:
 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 GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL"
}}}

== Utilisation ==

 * A ajouter dans son `~/.bashrc` (puis se reloger pour activation) :
 {{{
# à ajouter à la fin de son fichier ~/.bash_profile :
export GIT_AUTHOR_NAME="Prenom NOM"
export GIT_AUTHOR_EMAIL="prenom.nom@auf.org"}}}

 * Pour voir les modifications :
Pour voir les modifications avant de les envoyer dans le dépôt :
Ligne 90: Ligne 50:
 * Pour enregistrer les modifications : Pour envoyer les modifications dans le dépôt, on lance un ''commit''. Il y a plusieurs façons de faire, parmis lesquelles :
Ligne 92: Ligne 52:
$ sudo git commit un/seul/fichier/modifié # pour un fichier : toujours en notation relative
$ sudo git commit -a # on enregistre *toutes* les modifications}}}
$ sudo git commit un/seul/fichier/modifié # on enregistre les modification d'un seul fichier (attention : toujours en notation relative)
$ sudo git commit -a # on enregistre *toutes* les modifications
}}}
Ligne 95: Ligne 56:
 * Pour suivre un nouveau fichier : Pour revoir les modifications, plusieurs techniques en ligne de commande :
Ligne 97: Ligne 58:
$ sudo git add le/chemin/relatif/vers/le/fichier/ou/repertoire $ sudo git log -10 # rappel succinct des 10 dernières modifications
$ sudo git show # affiche les détails de la dernière modification
$ sudo git show 4961aef5e675fd148 # 4961aef5e675fd148 = le début du code de la modification à afficher en détail
$ sudo git whatchanged # liste des modifications
$ sudo tig # petit logiciel très sympa, à installer avec aptitude install tig
}}}

== Exemple d'utilisation ==

 {{{
$ cd /etc | ici on travaille, dans cet exemple
$ sudo vi profile <-----| on modifie la configuration du
$ sudo vi postfix/main.cf | logiciel Postfix
$ cd /
$ sudo git status -a | une fois le travail fait, on va sur /
$ sudo git diff <-----| puis on documente ce qu'on a fait
$ sudo git commit -a | (pourquoi, comment...)
}}}

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

== Suivre de nouveaux fichiers / Ne plus suivre des fichiers ==

Pour suivre un nouveau fichier ou tous les nouveaux fichiers d'un répertoire, par exemple suite à l'installation de nouveaux fichiers de configuration :
 {{{
$ cd /
$ sudo git add le/chemin/du/fichier/ou/repertoire # il faut indiquer le chemin en "relatif" (sans / au début)
Ligne 100: Ligne 87:
  Attention : il faut éventuellement modifier le fichier `/.git/info/exclude` Attention : il faut éventuellement modifier le fichier `/.git/info/exclude`
Ligne 102: Ligne 89:
 * Pour ne plus suivre un fichier : Pour arrêter de suivre un fichier ou un répertoire :
Ligne 104: Ligne 91:
$ sudo vi /.git/info/exclude <--- on ajoute dans les excludes (exemple : /etc/ldap.secret)
$ sudo git rm le/chemin/relatif/du/fichier/a/ne/plus/suivre
$ sudo vi /.git/info/exclude                              # on ajoute le nom du fichier dans les excludes (exemple : /etc/ldap.secret)
$ cd /
$
sudo git rm le/chemin/du/fichier/a/ne/plus/suivre        # on le retire du dépôt (note : le chemin est relatif, sans / au début)
Ligne 108: Ligne 96:
 * 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)...
}}}
= Ca ressemble à quoi ? =
Ligne 116: Ligne 98:
 * 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 ...
}}}
Juste pour donner une idée, voici ce que donne le petit programme `tig` lorsqu'on le lance sur une machine bien suivie :
Ligne 127: Ligne 100:
== Quelques automatisations quasi indispensables ==  {{attachment:ce-que-montre-tig.png}}
Ligne 129: Ligne 102:
 * 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 :
 {{{
# et à ajouter vers la fin de /etc/sudoers :
%admin ALL=(ALL) /usr/bin/git status -a
}}}

  1. Lancer le `git status` (via `sudo`) dans le `/etc/profile`, et configurer un peu les variables GIT :
 {{{
# A ajouter à la fin de /etc/profile :
if [ "$PS1" ]; then
  # on lance un git status sur l'utilisateur est dans le groupe
  # admin ou bien si c'est root
  if $(id -Gn | grep -qw admin) || [ $(id -u) -eq 0 ]; then
    (test -x /usr/bin/git && test -e /.git && cd / && sudo /usr/bin/git status -a)
  fi
  # les lignes suivantes tentent de configurer les variables GIT_*
  # si les résultats ne sont pas bien "devinés", définir les bonnes valeurs dans .bashrc
  GIT_AUTHOR_NAME=${GIT_AUTHOR_NAME:=$(getent passwd $(id -un)|cut -d: -f5|cut -d, -f1)}
  GIT_AUTHOR_EMAIL=${GIT_AUTHOR_EMAIL:=$(id -un)@$(hostname -f)}
  GIT_COMMITTER_NAME=${GIT_COMMITTER_NAME:=$GIT_AUTHOR_NAME}
  GIT_COMMITTER_EMAIL=${GIT_COMMITTER_EMAIL:=$GIT_AUTHOR_EMAIL}
  export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL
fi
}}}


 * Pour envoyer un mail à chaque commit :

  1. Créer un script `/.git/hooks/post-commit` :
 {{{
#!/bin/bash
recipients="admins@XX.auf.org" # adresse pour l'envoi du mail
# On modifie un peu la sortie de git show :
# 1) on ajoute "From git hostname" devant le nom en From
# 2) on retire le [PATCH] dans le sujet, replacé par git-commit:
# 3) on ajoute un champ To:
# et on maile le tout via sendmail
PATH=/usr/sbin:/usr/bin:/sbin:/bin
git show --pretty=email |
  sed '1,6s/^From: /From: git '`hostname -f`' - /;1,6s/^Subject: \[PATCH\]/Subject: git-commit:/;2iTo: '"${recipients}" |
  head -c 16k | /usr/lib/sendmail ${recipients}
exit 0
}}}

  1. Activer le script :
 {{{
# chmod +x /.git/hooks/post-commit
}}}

  1. Eventuellement faire un commit de test afin de vérifier ça marche, notamment que `sendmail` (Postfix, Exim, ...) envoie bien le message.


== 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.
 * ouiiiiiiiii : {{{$Conf{DumpPreUserCmd}}}}. Sur le principe, ouip, ça serait beaucoup beaucoup plus simple à mettre en oeuvre ainsi. mais, heu... pas sûr d'être trés chaud (pas d'autre argument pour le moment que "j'ai le nez qui coule", toutefois) -- J.
 * c'est juste comme ça pour le fun... il faut protéger derrière (protéger comme l'est bppc, avec un bon gros login/passwd sur une machine tout au fond du réseau...?). Enfin bref, pas très très important/nécessaire pour l'instant, on va déjà essayer de se discipliner sur les commit, on verra ensuite ! -- Thomas
= Annexes =
Ligne 206: Ligne 106:
Pour plus tard (Lenny) :
 * [http://kerneltrap.org/mailarchive/git/2007/10/11/335112 RCS keyword expansion] pour les $Id$ et compagnies
 * `git-stash` pour relier apt et git correctement
 * [:Tini:] n'ose pas le dire, mais il a fait un paquet Debian `git-etc-auf` qui fait tout le boulot d'installation. Un jour il osera.
 * RHHHAAAAAA !!!! Ça urge la mise en place du dépôt APT AuF... On fait de plus en plus de paquets Debian et personne n'en profite car on a pas de lieu commun pour les déposer, grmph... Bon, Moussa, tu le fais quand le serveur virtual apt.auf.org (je ferai la suite) ? Ou sinon je peux le faire où ?? -- ProgFou
   "Je vous ai compris" :-), le serveur apt.auf.org vient d'être mise en place sur vz-www.ca.auf avec l'IP 199.84.140.13. La balle est dans ton camp JC ;-)
Pour plus tard (Lenny) :
 * correction du bogue quand on joue avec un "/.git" (y a-t-il un bogue, d'ailleurs ? )
 * `git-stash` pour relier apt et git

== Annexes ==
 * historique : /InstallationManuelle
  • APPEL A PARTICIPATION AUX TESTS DE DÉPLOIEMENT :
    Mettez ce système en place en suivant les sections « Installation automatisée » et « Utilisation ».
    En cas de problème, signalez-le immédiatement via la liste de discussion technique de l'AUF.

Introduction

On veut pouvoir documenter les modifications faites dans /etc et dans /usr/local, qui sont grosso modo les deux répertoires permettant de décrire comment fonctionne un serveur. Cette documentation est indispensable en cas d'administration à plusieurs, mais elle est également très utile quand on est seul à gérer : c'est un aide-mémoire indispensable vu la vitesse à laquelle évoluent les technologies et donc les configurations.

Pour cela, on utilise un logiciel de gestion de version. Ce logiciel va nous permettre de documenter chaque modification effectuée sur un fichier ou un ensemble de fichier. On pourra ensuite retrouver à quel moment à été faite une modification, par qui et pour quelle raison.

Il existe différents logiciels de ce type, parmis lesquels on peut citer l'ancètre RCS, son fils CVS, son petit-fils Subversion (svn) et dans la génération qui vient d'arriver : git. C'est ce dernier logiciel que nous avons choisi car il est moins bavard, moins intrusif dans le code à surveiller, et surtout très bien documenté.

Notre objectif est d'installer et de configurer git pour que s'administrateur d'un serveur puisse aisément faire le suivi de sa configuration.

Installation automatisée (paquet auf-git-etc)

Vous avez maintenant à votre disposition un paquet Debian réalisé en interne à l'AuF.

Pour profiter de ce paquet il vous suffit de créer un fichier /etc/apt/sources.list.d/auf.list avec le contenu suivant :

  • deb http://apt.auf.org/ etch auf

Puis de lancer les commandes suivantes :

  • # aptitude update                 # ignorer le message d'avertissement
    # aptitude install auf-keyring    # accepter l'installation "non signée"
    # aptitude update                 # aucun message d'avertissement ne doit s'afficher
    # aptitude install auf-git-etc

Utilisation

Configuration préliminaire

Ajouter les lignes suivantes dans son ~/.bash_profile, puis se reloguer pour activation :

  • # lignes à ajouter à la fin de son fichier ~/.bash_profile (puis se reloguer pour activation) :
    export GIT_AUTHOR_NAME="Prenom NOM"
    export GIT_AUTHOR_EMAIL="prenom.nom@auf.org"

Utilisation au quotidien

Pour voir les modifications avant de les envoyer dans le dépôt :

  • $ 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 envoyer les modifications dans le dépôt, on lance un commit. Il y a plusieurs façons de faire, parmis lesquelles :

  • $ sudo git commit un/seul/fichier/modifié   # on enregistre les modification d'un seul fichier (attention : toujours en notation relative)
    $ sudo git commit -a                        # on enregistre *toutes* les modifications

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

  • $ sudo git log -10                       # rappel succinct des 10 dernières modifications
    $ sudo git show                          # affiche les détails de la dernière modification
    $ sudo git show 4961aef5e675fd148        # 4961aef5e675fd148 = le début du code de la modification à afficher en détail
    $ sudo git whatchanged                   # liste des modifications
    $ sudo tig                               # petit logiciel très sympa, à installer avec aptitude install tig

Exemple d'utilisation

  • $ cd /etc                              | ici on travaille, dans cet exemple
    $ sudo vi profile                <-----| on modifie la configuration du
    $ sudo vi postfix/main.cf              | logiciel Postfix
    $ cd /     
    $ sudo git status -a                   | une fois le travail fait, on va sur /
    $ sudo git diff                  <-----| puis on documente ce qu'on a fait
    $ sudo git commit -a                   | (pourquoi, comment...)

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

Suivre de nouveaux fichiers / Ne plus suivre des fichiers

Pour suivre un nouveau fichier ou tous les nouveaux fichiers d'un répertoire, par exemple suite à l'installation de nouveaux fichiers de configuration :

  • $ cd /
    $ sudo git add le/chemin/du/fichier/ou/repertoire          # il faut indiquer le chemin en "relatif" (sans / au début)
    $ sudo git commit

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

Pour arrêter de suivre un fichier ou un répertoire :

  • $ sudo vi /.git/info/exclude                               # on ajoute le nom du fichier dans les excludes (exemple : /etc/ldap.secret) 
    $ cd /
    $ sudo git rm le/chemin/du/fichier/a/ne/plus/suivre        # on le retire du dépôt (note : le chemin est relatif, sans / au début)

Ca ressemble à quoi ?

Juste pour donner une idée, voici ce que donne le petit programme tig lorsqu'on le lance sur une machine bien suivie :

  • ce-que-montre-tig.png

Annexes

Améliorations à trouver

Pour plus tard (Lenny) :

  • correction du bogue quand on joue avec un "/.git" (y a-t-il un bogue, d'ailleurs ? )
  • git-stash pour relier apt et git

Annexes

Git/SuiviDeConfiguration (dernière édition le 2013-09-02 03:50:32 par JeanChristopheAndré)