6736
Commentaire:
|
6420
ça marche parfaitement sur Etch
|
Texte supprimé. | Texte ajouté. |
Ligne 2: | Ligne 2: |
'''Note : testé sur Gutsy... en cours de test sur Etch''' |
|
Ligne 42: | Ligne 40: |
/etc/sudoers /etc/sasldb* /etc/krb5.keytab |
|
Ligne 46: | Ligne 41: |
/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 |
|
Ligne 74: | Ligne 61: |
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" }}} |
|
Ligne 76: | Ligne 69: |
Après '''chaque''' modification d'un fichier, enregistrer les modifications : {{{ # git commit -a}}} Si on veut suivre un nouveau fichier, ou ne committer les modifications que de ce fichier : {{{ # git add fichier # git commit}}} et pour un répertoire (modifier `exclude` si c'est en dehors de /etc ou /usr/local): {{{ # cd / ; git add un/reper/toire # git commit}}} Pour voir les modifications, plusieurs techniques en ligne de commande : {{{ # tig <-- à installer avec aptitude install tig # git whatchanged # git log -10 # git show ...(le code du commit)... }}} == Quelques scripts d'automatisation (wrapper) == A ajouter dans son `~/.bashrc` : {{{ |
* A ajouter dans son `~/.bashrc` (puis se reloger pour activation) : {{{ # à ajouter à la fin de son fichier ~/.bashrc : |
Ligne 104: | Ligne 75: |
=== confcommit === attachment:confcommit Permet une utilisation plus simple via `sudo` : * trouve le nom de l'auteur/committer par les variables d'environnement GIT_ et/ou SUDO_USER * `confcommit -a` : effectue un `git commit -a` pour committer toutes les modifications et suppression de fichiers * `confcommit -n` : effectue un `git add etc usr/local` pour ajouter tous les nouveaux fichiers ''TODO'' : accepter "confcommit fichier1 fichier2 ..." permettant de ne committer que tel et tel fichier, comme git commit. Mais si possible en simplifiant la syntaxe, c-a-d en acceptant des noms de fichiers absolus, p.ex. "confcommit /etc/network/interfaces". ''TODO2'' : par défaut, sudo flingue les variables d'environnement. Voir comment configurer sudo pour qu'il laisse les GIT_* tranquilles, si possible... . `man sudoers` puis `/env_keep` donne à ajouter dans `/etc/sudoers` : {{{ Defaults env_keep += "GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL" |
* 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 |
Ligne 120: | Ligne 81: |
=== confcommit-status === | * 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}}} |
Ligne 122: | Ligne 86: |
attachment:confcommit-status | * 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` |
Ligne 124: | Ligne 93: |
Il donne la liste des fichiers modifiés, supprimés ou créés depuis le dernier ''commit''. | * 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 }}} |
Ligne 126: | Ligne 99: |
1. A lancer via un `cron` au moins quotidien (toutes les 6 heures ?), il donne la liste des modifications non encore enregistrées. 1. Peut aussi être installé pour signaler des modifications à la fin de l'utilisation de `apt-get` ou `aptitude`. Pour cela, créer un fichier `/etc/apt/apt.conf.d/99confcommit-status` tel que : {{{# /etc/apt/apt.conf.d/99confcommit-status DPkg::Post-Invoke {"if [ -x /usr/local/bin/confcommit-status ]; then /usr/local/bin/confcommit-status post || true; fi";}; |
* 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)... |
Ligne 132: | Ligne 107: |
== Un serveur gitweb central == | * 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 }}} 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...) == |
Ligne 149: | Ligne 160: |
''Idée'' pour simplifier : 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. | ''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. |
Ligne 151: | Ligne 162: |
== Améliorations à prévoir == | == Améliorations à trouver == |
Ligne 153: | Ligne 164: |
. interfaçage avec apt : voir http://bryan-murdock.blogspot.com/2007/07/put-etc-under-revision-control-with-git.html et https://wiki.ubuntu.com/VersionControlledEtc et http://www.bononia.it/~zack/blog/posts/versioning_etc_w_bzr/discussion.html : '''tout ça est bof bof''' (et surtout sur Etch on n'a pas le "git stash"), alors on préfèrera pour l'instant un simple message à la fin d'utilisation de apt-get ou aptitude. Voir ci-dessus, appel à confcommit-status. |
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...