1925
Commentaire: bon voilà quoi
|
6736
|
Texte supprimé. | Texte ajouté. |
Ligne 2: | Ligne 2: |
'''Note : testé sur Gutsy... en cours de test sur Etch''' |
|
Ligne 10: | Ligne 12: |
{{{ | {{{ |
Ligne 14: | Ligne 16: |
2. On créée un dépôt général pour toute la machine : {{{ |
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. {{{ |
Ligne 17: | Ligne 19: |
# git init | # git init (ou "git init-db" sur une Debian Etch, git version 1.4) # chmod u=rwx,go= /.git |
Ligne 20: | Ligne 23: |
3. Pour éviter d'avoir des "saletés" directement à la racine (`/`), on déplace le dépôt autre part : {{{ |
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 : {{{ |
Ligne 25: | Ligne 28: |
# chmod u=rwx /var/lib/git/root | |
Ligne 29: | Ligne 31: |
{{{ # # 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/sudoers /etc/sasldb* /etc/krb5.keytab /etc/ld.so.cache /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 # 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/* |
Ligne 35: | Ligne 59: |
!/etc | # quelques type fichiers à ne pas jamais considérer, globalement : |
Ligne 38: | Ligne 62: |
.*.swp | |
Ligne 39: | Ligne 64: |
*# | |
Ligne 42: | Ligne 68: |
{{{ # cd /etc ; git add . # cd /usr/local ; git add . # git commit -m "mise en route du suivi : /etc et /usr/local" |
{{{ # cd / # git add etc usr/local # git commit -m "mise en route du suivi : /etc et /usr/local" --author "moi <email@auf.org>" |
Ligne 54: | Ligne 80: |
Si on veut suivre un nouveau fichier : | Si on veut suivre un nouveau fichier, ou ne committer les modifications que de ce fichier : |
Ligne 56: | Ligne 82: |
# git add fichier}}} ou un nouveau répertoire (modifier `exclude` si c'est en dehors de /etc ou /usr/local): |
# git add fichier # git commit}}} et pour un répertoire (modifier `exclude` si c'est en dehors de /etc ou /usr/local): |
Ligne 59: | Ligne 86: |
# cd /repertoire ; git add .}}} | # cd / ; git add un/reper/toire # git commit}}} |
Ligne 61: | Ligne 89: |
Pour voir les modifications : | Pour voir les modifications, plusieurs techniques en ligne de commande : |
Ligne 63: | Ligne 91: |
# tig <-- à installer avec aptitude install tig # git whatchanged |
|
Ligne 64: | Ligne 94: |
# git show ...(le code du commit)...}}} | # git show ...(le code du commit)... }}} |
Ligne 66: | Ligne 97: |
== Améliorations == | == Quelques scripts d'automatisation (wrapper) == |
Ligne 68: | Ligne 99: |
. interfaçage avec apt : http://bryan-murdock.blogspot.com/2007/07/put-etc-under-revision-control-with-git.html . cron nocture qui balance un courriel d'insulte quand on a pas fait le commit alors qu'il y a des modifs . faire un serveur central gitweb (avec les commandes git-ssh-* ou autre pour envoyer vers le dépot) |
A ajouter dans son `~/.bashrc` : {{{ export GIT_COMMITTER_NAME="Prenom NOM" export GIT_COMMITTER_EMAIL="prenom.nom@auf.org"}}} === 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" }}} === confcommit-status === attachment:confcommit-status Il donne la liste des fichiers modifiés, supprimés ou créés depuis le dernier ''commit''. 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";}; }}} == Un serveur gitweb central == ''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 : 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 à prévoir == . 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. . hooks à comprendre : envoyer un mail à chaque commit, synchroniser avec le gitweb à chaque commit, etc... |
Git est un système de gestion de versions. Voir sa [http://fr.wikipedia.org/wiki/Git_(logiciel) page wikipédia]
Note : testé sur Gutsy... en cours de test sur Etch
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/sudoers /etc/sasldb* /etc/krb5.keytab /etc/ld.so.cache /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 # 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>"
Utilisation
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 :
export GIT_COMMITTER_NAME="Prenom NOM" export GIT_COMMITTER_EMAIL="prenom.nom@auf.org"
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"
confcommit-status
attachment:confcommit-status
Il donne la liste des fichiers modifiés, supprimés ou créés depuis le dernier commit.
A lancer via un cron au moins quotidien (toutes les 6 heures ?), il donne la liste des modifications non encore enregistrées.
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";}; }}}
Un serveur gitweb central
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 : 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 à prévoir
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.
- hooks à comprendre : envoyer un mail à chaque commit, synchroniser avec le gitweb à chaque commit, etc...