6482
Commentaire: typozzz
|
6420
ça marche parfaitement sur Etch
|
Texte supprimé. | Texte ajouté. |
Ligne 2: | Ligne 2: |
'''Note : testé sur Gutsy... en cours de test sur Etch''' |
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.
Installation
On installe git :
# aptitude install git-core
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
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
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 *~ *#
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>"
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 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
- Pour lancer un "status" à chaque connexion sur le serveur (très très utile) :
- 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
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 (...)
- Permettre aux gens du groupe "admin" de lancer git status sans mot de passe :
Un serveur gitweb central (idée pour plus tard...)
brouillon (manip testées, ça marche, mais j'ai peut-être oublié quelques détails)
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.
- 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
On met les clés publiques des comptes root des serveurs dans /home/gitweb/.ssh/authorized_keys
- 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
- 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...