Modifications entre les versions 32 et 65 (s'étendant sur 33 versions)
Version 32 à la date du 2007-11-21 20:44:24
Taille: 6482
Éditeur: ThomasNoël
Commentaire: typozzz
Version 65 à la date du 2013-09-02 03:48:11
Taille: 5359
Commentaire: projet déjà en phase de déploiement + mise à jour
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] = Introduction =
Ligne 3: Ligne 3:
'''Note : testé sur Gutsy... en cours de test sur Etch''' 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 5: Ligne 5:
= Suivre la config d'une machine avec git = 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.'''
Ligne 7: Ligne 7:
On veut pouvoir documenter les modifications faites dans /etc et dans /usr/local. Il existe différents logiciels de ce type, parmi 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 9: Ligne 9:
== Installation == '''Notre objectif est d'installer et de configurer `git` pour que l'administrateur d'un serveur puisse aisément faire le suivi de sa configuration.'''
Ligne 11: Ligne 11:
 1. On installe `git` :
 {{{
# aptitude install git-core
= Installation automatisée (paquet auf-git-etc) =

Vous avez maintenant à votre disposition un paquet Debian [[http://git.auf.org/?p=auf-git-etc.git|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/ wheezy auf
Ligne 16: Ligne 19:
 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
Puis de lancer les commandes suivantes : {{{#!shell
sudo aptitude update # ignorer le message d'avertissement
sudo aptitude install auf-keyring # accepter l'installation « non signée »
sudo aptitude update # aucun message d'avertissement ne doit s'afficher
sudo aptitude install auf-git-etc
Ligne 23: Ligne 26:
 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
= Utilisation =

== Configuration préliminaire ==

Ajouter les lignes suivantes dans son `~/.bash_profile` (puis se reconnecter pour activation) : {{{#!shell
export GIT_AUTHOR_NAME="Prénom NOM"
export GIT_AUTHOR_EMAIL="prenom.nom@auf.org"
Ligne 30: Ligne 35:
 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 ==

Pour voir les modifications avant de les envoyer dans le dépôt : {{{#!shell
sudo git status # affiche la liste des fichiers modifiés, supprimés, nouveaux…
sudo git diff # affiche les différences entre ce qui est stocké dans git et l'état actuel
Ligne 56: Ligne 42:
 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>"
Pour envoyer les modifications dans le dépôt, on lance un `commit`.
Il y a plusieurs façons de faire, parmi lesquelles : {{{#!shell
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 63: Ligne 48:
 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"
Pour revoir les modifications, plusieurs techniques en ligne de commande : {{{#!shell
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
Ligne 69: Ligne 56:
== Utilisation == == Exemple d'utilisation ==
Ligne 71: Ligne 58:
 * A ajouter dans son `~/.bashrc` (puis se reloger pour activation) :
Ligne 73: Ligne 59:
# à 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
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 | 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...)
Ligne 83: Ligne 68:
 * 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}}}
Note : la plupart du temps, il est plus simple de prendre l'habitude de se placer à la racine pour faire les manipulations `git`.
Ligne 88: Ligne 70:
 * 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`
== Suivre de nouveaux fichiers / Ne plus suivre des fichiers ==
Ligne 95: Ligne 72:
 * Pour ne plus suivre un fichier :
 {{{
$ 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
}}}

 * 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)...
Pour suivre un nouveau fichier ou tous les nouveaux fichiers d'un répertoire,
par exemple suite à l'installation de nouveaux fichiers de configuration : {{{#!shell
cd /
sudo git add le/chemin/du/fichier/ou/repertoire # il faut indiquer un chemin relatif (sans / au début)
sudo git commit
Ligne 109: Ligne 79:
 * 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 ...
Attention : il faut éventuellement modifier le fichier `/etc/auf-git-etc/info/exclude`

Pour arrêter de suivre un fichier ou un répertoire : {{{#!shell
sudo vi /etc/auf-git-etc/info/exclude # on ajoute le nom du fichier dans les exclusions (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 120: Ligne 87:
== Quelques automatisations == = Ca ressemble à quoi ? =
Ligne 122: Ligne 89:
 * Pour lancer un "status" à chaque connexion sur le serveur (très très utile) : Juste pour donner une idée, voici ce que donne le petit programme `tig` lorsqu'on le lance sur une machine bien suivie :
Ligne 124: Ligne 91:
  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
}}}
 {{attachment:ce-que-montre-tig.png}}
Ligne 130: Ligne 93:
  1. 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.
= Annexes =
Ligne 166: Ligne 97:
 . hooks à comprendre : envoyer un mail à chaque commit, synchroniser avec le gitweb à chaque commit, etc... Pour plus tard (post Etch) :
 * 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

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, parmi 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 l'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/ wheezy auf

Puis de lancer les commandes suivantes :

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

Utilisation

Configuration préliminaire

Ajouter les lignes suivantes dans son ~/.bash_profile (puis se reconnecter pour activation) :

export GIT_AUTHOR_NAME="Prénom 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         # affiche la liste des fichiers modifiés, supprimés, nouveaux…
sudo git diff           # affiche les différences entre ce qui est stocké dans git et l'état actuel

Pour envoyer les modifications dans le dépôt, on lance un commit. Il y a plusieurs façons de faire, parmi 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                      | 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 un chemin relatif (sans / au début)
sudo git commit

Attention : il faut éventuellement modifier le fichier /etc/auf-git-etc/info/exclude

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

sudo vi /etc/auf-git-etc/info/exclude                    # on ajoute le nom du fichier dans les exclusions (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 (post Etch) :

  • 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é)