Je continue sur ma lancée des trucs qui enlarge my productivity. Aujourd'hui, voyons comment gérer efficacement ses fichiers de config directement avec git.
Comment gérez-vous les fichiers de configs répartis sur vos différentes machines ? Les synchronisez-vous de temps en temps à coup de scp, rsync ou unison ? Peut-être utilisez-vous un outil évolué comme vcsh ? Mais savez-vous que si ce dernier est une surcouche à git dédiée à la gestion des fichiers de configuration, git seul peut faire l'affaire ?
Bien sûr, tout serait simple si tous les logiciels enregistraient leurs fichiers de configuration dans ~/.config, mais ce n'est pas le cas : beaucoup l'enregistrent directement dans le dossier home. Il va donc falloir versionner tout le dossier home. Oui, c'est sale, j'en vois déjà s'agiter derrière leur clavier ! Mais pas de panique, on va commencer par tout ignorer par défaut :
echo '*' > ~/.gitignore
Il faudra donc par la suite ajouter les fichiers avec git add -f. Mais pour commencer, créons notre dépôt, comme un dépôt git normal :
git init --bare <répertoire_dédié>
Une fois le dépôt créé, on va pouvoir le cloner sur chaque machine concernée.
cd # pour revenir dans son home
git init
git remote add origin/master <adresse du dépôt>
# Supprimer/sauvegarder les fichiers potentiellement écrasés avant de pull (.bashrc notamment)
git pull origin/master master
Avant de pouvoir commencer à envoyer des commits au serveur, il faudra encore exécuter la commande suivante, pour indiquer qu'on veut push sur la branche master du dépôt distant :
git push --set-upstream origin/master master
Et, si ce n'est pas déjà défini dans votre .gitconfig, pensez à définir votre nom ainsi que votre adresse mail :
git config --global user.email "toto@perdu.com"
git config --global user.name "Erika Mustermann"
Et voilà, c'est tout ! Vous pouvez à présent gérer vos fichiers de config comme n'importe quel dépôt git, à l'exception près qu'il faut ajouter les fichiers avec git add -f. Très pratique pour effectuer fréquemment des changements et les diffuser sur ses différentes machines ! Et le versionnage vous permettra de retrouver rapidement une modification effectuée, annuler une config qui-casse-tout…
Faites bien attention de n'ajouter que les fichiers de configuration modifiés uniquement par l'utilisateur, et non pas les différents fichiers de cache (n'ajoutez pas votre .emacs.d/ en entier, par exemple). On regrettera d'ailleurs que certains logiciels tels thunderbird/icedove placent les configs utilisateurs et différentes options modifiées en permanence (dernier dossier ouvert, etc.) dans le même fichier, ce qui empêche un versionnage pratique.
Voilà, bonne gestion de vos dizaines de machines !
# Versionner tout ${HOME}: moyen...
Posté par ymorin . Évalué à 10.
B'soir !
Au début, je versionnais tout mon
${HOME}
. Et puis j'ai fait une bêtise… Le problème de versionner tout~/
, c'est lorsque l'on fait aussi du dévelopement dans un sous-dossier. Par exemple chez moi, tous mes dévs sont dans~/dev/
.Et du coup, il devient facile d'exécuter une commande git et que le dépôt
~/
soit utilisé alors qu'on croyait être dans un répertoire de dev ; ou l'inverse. Ou encore utiliser git au lieu de hg ; ou l'inverse.Maintenant, mon
~/
n'est plus un dépôt git, mais~/.home/
l'est. Et tout ce que je veux versionner dans~/
je le déplace dans~/.home/
et crée un lien symbolique (il y a un script pour ça).Enfin, le dépôt est pushé vers mon serveur. Quand je veux déployer sur une autre machine, je clone le dépôt depuis mon serveur, lance le script qui crée les liens symboliques.
Il reste un peu de config locale (e.g. les proxys à utiliser si différents, générer les clés ssh, etc…).
Voilà. C'est pas parfait, ni absolument propre, mais ça fait l'affaire.
Hop,
Moi.
[^] # Re: Versionner tout ${HOME}: moyen...
Posté par Perdu (site web personnel) . Évalué à 1.
Hum, je n'avais jamais vu le risque sous cet angle…
Pourtant, je fais comme cela depuis plusieurs années, et je n'ai jamais fait d'erreur malheureuse. Suis-je prudent, ou chanceux ?
Enfin, avec des sauvegardes régulières, rien n'est dramatique :o)
[^] # Re: Versionner tout ${HOME}: moyen...
Posté par robin . Évalué à 7.
Dans mon prompt, j'ai fait en sorte qu'il m'affiche « ✔ » si le dossier courant est directement versioné (ie contient un .git). Sinon, il m'affiche le dossier racine du dépôt git avec la commande suivante :
Si ça peut aider qqun.(git rev-parse --show-toplevel | sed -e "s-$(pwd)-✔-g" | rev | cut -d / -f 1 | rev) 2>/dev/null
bépo powered
[^] # Re: Versionner tout ${HOME}: moyen...
Posté par dixDel (site web personnel) . Évalué à 2.
Merci pour l'astuce.
Voici un exemple d'intégration dans une variable PS1 :
J'ai laissé de côté le bout de code qui enlève tout ce qui précède le dernier slash ( je préfère voir le chemin complet ). J'ai aussi enlevé les couleurs et passages à la ligne pour simplifier.
[^] # Re: Versionner tout ${HOME}: moyen...
Posté par dixDel (site web personnel) . Évalué à 2.
Pour aller plus loin, voici un exemple pour afficher aussi la branche sur laquelle on travaille :
Cela rend la PS1 plus lisible:
Résultat :
Il y a sûrement moyen de faire plus beau mais je ne code pas beaucoup en shell script.
[^] # Re: Versionner tout ${HOME}: moyen...
Posté par ymorin . Évalué à 3.
Bon, puisqu'on s'est mis à parler prompt, voici le mien.
Au final, ça ressemble à ça (sur un terminal qui n'affiche pas l'unicode, puis sur un terminal qui affiche l'unicode) sur la largeur complète de la ligne du terminal :
Les infos VCS sont affichées pour git, Mercurial et Subversion ; on y trouve: la branche, le
changeset
, le statut (fichiers modifiés, non-trackés, dans l'index, stash en cours, en fonction du VCS).Les diverses infos incluent par exemple le statut de la batterie, le load average, la date courante, le user et le hostname, le tty (ainsi que la session tmux/screen courante), le code de retour de la dernière commande si non nul, etc…
Il y a différentes couleurs pour chaque partie, avec les infos importantes en rouge (VCS statut, batterie faible, dernier $? non nul … ), en bleu pour
CWD
, vert foncé pour la branche VCS, orange pour lechangeset
courant, vert clair pour leusername@host
, etc … Il y a trois thèmes de couleurs dispos :green
,red
etmono
.Notes : le code est pas très beau et la doc pas complètement à jour, désolé, mais ça a évolué pas mal en presque 9 ans …
Ceci dit, si quelqu'un sait comment connaître la largeur d'un glyphe, je suis preneur…
Hop,
Moi.
[^] # Re: Versionner tout ${HOME}: moyen...
Posté par lolop (site web personnel) . Évalué à 2.
Ça me rappelle le liquidprompt de nohan (qui poste de temps en temps sur le sujet).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Versionner tout ${HOME}: moyen...
Posté par deuzene (site web personnel) . Évalué à 2.
-> chance
-> prudence
Là où tu serais malchanceux, c'est si tes sauvegardes sont foireuses.
« Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
# Attention, risque sympatique.
Posté par Guillaum (site web personnel) . Évalué à 5.
Attention au git clean dans le mauvais répertoire, cela fait désordre…
Histoire vécue. Je fais souvent des git clean (enfin moi c'est du hg purge, mais c'est pareil) pour nettoyer un dépôt de tous les trucs inutiles qui sont arrivés et pan… plus de home…
Personnellement j'ai une solution avec un sous répertoire de mon home pour les fichiers de config versionnés et je crée automatiquement les liens symboliques qui vont bien.
[^] # Re: Attention, risque sympatique.
Posté par ymorin . Évalué à 2.
Marrant ça…
Ça me rappelle vaguement quelque chose… ;-)
[^] # Re: Attention, risque sympatique.
Posté par navaati . Évalué à 2.
Bizarre, je viens de lire le man de git clean (connaissais pas, merci) et ça dit :
Du coup si tu a fais un .gitignore avec * dedans et que tu
add -f
juste ce qu'il faut, comme le monsieur a dit, faire un git clean ne supprime rien puisque tu ne peux pas avoir de fichiers untracked (seulement des fichiers ignored).À moins que tu ne fasses régulièrement des
git clean -x
?[^] # Re: Attention, risque sympatique.
Posté par Guillaum (site web personnel) . Évalué à 3.
Ba oui… Globalement c'est surtout les fichiers ignoré que je supprime avec git clean. Les autres j'ai tendance à supprimer à la main car c'est soit des fichier à ajouter, soit des fichiers qui doivent sans doute avoir une raison d'être là ou d'être bougé ailleurs.
[^] # Re: Attention, risque sympatique.
Posté par ymorin . Évalué à 1.
Oui, quand on développe sur des packages pas encore très propres, par exemple. Je fait même assez souvent des
git clean -dx
pour vraiment tout virer (sous-répertoires compris).Hop,
Moi.
# Sous modules
Posté par chimrod (site web personnel) . Évalué à 3.
Plutôt que d'utiliser une configuration unique, pourquoi ne pas éclater la configuration en différents sous-modules ?
Ça permet d'avoir un repo git pour chaque configuration (par exemple vim, i3, bashrc) que l'on peut cloner sur une autre machine de manière indépendante. Je pense qu'il peut être intéressant de ne cloner la configuration que d'une seule application (entre le pc du bureau et le pc à la main par exemple), sans pour autant rapatrier l'ensemble de son home.
La repo général ne fait que référencer l'ensemble des différentes configuration.
[^] # Re: Sous modules
Posté par Perdu (site web personnel) . Évalué à 1.
Je préfère avoir un repo général, personnellement. Plus facile à gérer, et ça ne me dérange pas de rapatrier les confs d'applications que je n'utilise pas sur certaines machines.
# vcsh myrepos
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
http://blog.tfnico.com/2014/03/managing-dot-files-with-vcsh-and-myrepos.html
Cela ma rappelle l'usage de mr et de vcsh pour gérer ses config, mais je n'ai jamais testé.
"La première sécurité est la liberté"
# Pour quoi pas Git pour /etc, mais solution au niveau filesystem pour /home
Posté par gUI (Mastodon) . Évalué à 2.
Ça fait un moment que je réfléchis à mettre mon /etc sous Git. Je pense que c'est une bonne idée, mais quelqu'un a-t-il déjà tenté et peut-il témoigner ?
Par contre pour mon /home, je suis un fan absolu de rsnapshot. Pour ceux qui ne connaissent pas, ça implémente (en mieux) cette page qui a été une illumination pour moi : http://www.mikerubel.org/computers/rsync_snapshots/
(C'est plus ou moins ce que Apple a appelé la Timemachine).
On crée autant de snapshot qu'on veut, en les faisant tourner (toutes les 3h, je garde les 4 derniers, ainsi que tous les jours, je garde les 7 derniers, ainsi que toutes les semaines etc…), mais ça ne 'coûte' que une fois la totale (car ça sert d'archive), ainsi que une fois chaque différence (seuls les fichiers qui diffèrent entre les différents snapshots sont dupliqués).
C'est pas tout à fait le même but que de versionner par git (on perd le concept d'historique, de traçabilité), mais ça suffit à revenir en arrière sur n'importe quel incident.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Pour quoi pas Git pour /etc, mais solution au niveau filesystem pour /home
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 2.
Faut au moins prendre la méthode au-dessus de tout exclure par défaut pour pas prendre hostname/passwd/shadow… En plus ça oblige d'utiliser git avec les droits root. Enfin bref, autant avoir les configs utile dans son home plutôt que de mettre tout /etc
[^] # Re: Pour quoi pas Git pour /etc, mais solution au niveau filesystem pour /home
Posté par jame_s . Évalué à 9.
Si tu veux versionner ton /etc, tu peux utiliser le programme etckeeper qui va faire ça de façon transparente.
[^] # Re: Pour quoi pas Git pour /etc, mais solution au niveau filesystem pour /home
Posté par Kioob (site web personnel) . Évalué à 1.
Pour ma part j'utilise bcfg2 pour gérer le déploiement de mes configurations sur les serveurs, y compris une partie de mon /home/. Et du coup, c'est l'arborescence de bcfg2 coté serveur qui est versionnée sous Git.
alf.life
[^] # Re: Pour quoi pas Git pour /etc, mais solution au niveau filesystem pour /home
Posté par claudex . Évalué à 10.
Je te conseille
etckeeper
qui, en plus de mettre ton/etc
sousgit
, va s'occuper des permissions de fichier (qui ne sont pas conservés avecgit
). Par contre, il faut faire attention à ne pas pousser le dépôt n'importe où, il contient des données sensibles (mots de passe, clef privée RSA…).« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Ma solution
Posté par Aissen . Évalué à 5.
J’ai jamais prit le temps de la publier, mais ma solution est un poil plus complexe, elle évite le fait de versionner tout le home (donc les sous dossiers ne se croient pas dans un répertoire git). En fait le dépôt git est dans ~/.sync/ ; et on utilise un alias pour gérer ce dépôt :
L'installation se passe comme suit :
Pour initialiser le tout, le fichier .init-sync va paramétrer l’environnement:
Pour ajouter des fichiers dans le dépot:
Et ça permet de tracker et synchroniser à peu près tout ce qui compte (config bash, git, vim, less). Certains paquets supplémentaires sont installés comme submodules (z/autojump, icdiff, vimpager,…).
Le fichier ~/.init-sync peut être relancé sur quand des nouveaux paquets vundle ou submodules sont ajoutés.
# BSD Owl Scripts
Posté par Michaël (site web personnel) . Évalué à 9. Dernière modification le 17 avril 2015 à 11:09.
Sommaire
Je fais ça avec BSD Owl Scripts¹ qui propose un module dédié pour les systèmes FreeBSD.
Organisation
Dans mon parc, j'ai quelques ordinateurs personnels sous FreeBSD ou Mac OS X et quelques systèmes virtualisés dans des jails. Chaque machine, possède un dossier contenant ses fichoers de configuration et il existe un dossier
common
contenant les fichiers communs à toutes les machines:Tous ces dossiers sont dans un dépôt git qui est cloné sur chaque machine réelle – les machines virtualisées dans des jails n'ont pas besoin du clone, cf. ci-dessous.
Fichiers communs
Dans le fichier
common
on trouve par exemple un fichierhost
mais aussi plein de petits trucs du style configuration du dæmon npd qui met à jour l'horloge du réseau, ou bien un fichierXresource
.Fichiers par machine réelle
Pour la machine réelle
llea
on a les fichiers spécifiques suivants: on y trouve la configuration de SSH, de NFS, de poudrière, de musicpd, etc.:La partie importante est le
Makefile
:Les listes BOOT, BASE, XORG, PORT et PKLA énumèrent respectivement les fichiers de configuration pour le démarrage de la machine, pour le système de base, Xorg, les ports et les règles pour le Policy Kit de FreeDektop.org.
L'incantation magique
.PATH: ../common
indique à bmake que les fichiers non trouvés dans le dossier courant peuvent être cherchés dans../common
. Après ceci un petitmake install
donneOn voit une authentification avec
su -
mais on pourrait utilisersudo
aussi. La dernière ligne montre un petit détail sympa puisque la base de donnée des logins est automatiquement reconstruite.Fichiers par machine virtualisée dans une jail
C'est la même chose que pour une machine réelle, mais il faut ajouter une déclaration
JAILDIR
qui indique la racine du système de fichiers du système virtualisé:Ainsi dans le système hôte, on peut installer les fichiers dans le système virtualisé:
Et voilà!
Prolongations
Si vous êtes tentés pour avoir la même chose sur votre sytème Linux préféré n'hésitez pas à me faire part de vos besoin sur le issue tracker du projet! Même en français ou en allemand! :)
¹ Disponible sous Debian, Ubuntu, et bientôt MacPorts et FreeBSD. Une installation à la mano est possible et facile. Marche aussi sous Cygwin.
# seafile
Posté par barmic . Évalué à 4.
J'avais suivi une méthode proche de la tienne, mais il faut penser à pousser et récupérer les versions c'est assez lourd et j'y pense jamais.
À la place j'utilise une bibliothèque seafile, qui me synchronise un dossier automatiquement et je fais les liens symbolique qui vont bien (ce que je faisais déjà avec git).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# ~/.config
Posté par woprandi . Évalué à 1.
C'est vrai que ça serait bien mieux ! Pourquoi ce n'est que peu respecté ?
[^] # Re: ~/.config
Posté par Sufflope (site web personnel) . Évalué à 2. Dernière modification le 18 avril 2015 à 17:27.
Le poids de l'historique.
[^] # Re: ~/.config
Posté par lolop (site web personnel) . Évalué à 2.
Et… malheureusement certains ne mettent pas que de la config là-dedans… mais aussi des données de cache…
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# git + run-part
Posté par Gauthier Monserand (site web personnel) . Évalué à 1.
Je ne m'y suis mis que récemment, avant je ne copiais que mon .vimrc .
Depuis peut j'ai formalisé ça dans un git qui installe des liens, run-part et des scripts s'occupe de l'installation.
Du coup cela gère aussi l'installation des packages et des outils de dev.
pub : https://github.com/simkim/dotfiles
# Ma solution à base de GIT_DIR/GIT_WORK_TREE
Posté par benoar . Évalué à 3.
Ma solution c'est une commande séparée qui passe tout à git avec le bon GIT_DIR/GIT_WORK_TREE, car c'est très facile de faire travailler git en dehors d'un dépôt, plutôt que de se prendre la tête à faire des liens symboliques…
Le dépôt est stocké dans
~/.dotfiles.git
, et on appelle la commandedotg
pour effectuer ses opérations dessus (les arguments sont comme pour git). Il y a juste deux petites commandes en plus pour initier/cloner son dépôt de configuration.C'est vraiment un wrapper léger autour de git, mais avec juste le sucre qu'il faut pour que ça marche de manière robuste et sympatique.
C'est ici : http://dolka.fr/code/gitweb/?p=dotfiles.git;a=shortlog;h=refs/heads/master
voire http://dolka.fr/code/gitweb/?p=dotfiles.git;a=blob;f=bin/dotg;h=a651ce2804a64b8e2ef41b883c2c15d0d71b40ee;hb=378c0f6e1c0c0d8d760cc586a700a991a12854f3 pour le code du script en version actuelle directement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.