Modifications entre les versions 35 et 36
Version 35 à la date du 2007-12-05 15:01:57
Taille: 8058
Éditeur: JérômeSantini
Commentaire: $Conf{DumpPreUserCmd}
Version 36 à la date du 2007-12-05 15:39:02
Taille: 8866
Éditeur: ThomasNoël
Commentaire: à quoi ça sert ?
Texte supprimé. Texte ajouté.
Ligne 5: Ligne 5:
On veut pouvoir documenter les modifications faites dans /etc et dans /usr/local. 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.

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 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é.


''A écrire : petites explications sur la notion de dépôt, orientée git et surveillance de /etc''

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

Suivre la config d'une machine avec git

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.

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 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é.

A écrire : petites explications sur la notion de dépôt, orientée git et surveillance de /etc

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/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
    *~
    *#
  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 ~/.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 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)...
  • 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 quasi indispensables

  • 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
      if $(id -Gn | grep -q admin); 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 :

    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}" | 
      /usr/lib/sendmail ${recipients}
    exit 0
    1. Activer le script :
    # chmod +x /.git/hooks/post-commit
    1. Faire un commit et vérifier 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.

Améliorations à trouver

Pour plus tard (Lenny) :

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