Journal kyrbeis: un outil basique de gestion de dotfiles

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
16
18
août
2017

Mon bien cher Nal,

Voulant synchroniser simplement des fichiers de configuration utilisateur, j'ai tout d'abord testé quelques-uns des outils énumérés ici.

Je voulais un outil:

  • simple d'utilisation
  • fondé sur les liens symboliques, comme dotfiles

Je voulais aussi utiliser git (et git-crypt pour chiffrer les fichiers sensibles).
Trouvant les outils testés trop compliqués (voir risqués), j'ai décidé d'écrire une gem ruby de quelques lignes, kyrbeis pour faire cela.

Je me suis dit que cela pourrait aussi éventuellement vous intéresser, voilà donc comment vous pourrez l'utiliser.

installation

$ gem install kyrbeis

utilisation

Créez un répertoire ~/dotfiles, dans lequel vos configurations seront stockées.
Pour ajouter un nouveau fichier de configuration, par exemple ~/.vimrc,
créez ~/dotfiles/__vimrc dans lequel vous écrirez votre configuration vim comme d'habitude.
Puis, en prenant soin que ~/.vimrc n'existe pas déjà (auquel cas kyrbeis ne fera rien) faites un:

$ kyrbeis apply

ce qui est équivalent à faire un ln -s ~/dotfiles/__vimrc ~/.vimrc.

Kyrbeis supporte aussi les sous répertoires, comme ~/.config/.
Par exemple, pour ajouter un fichier ~/.config/git/ignore, vous créerez ~/dotfiles/__config/git/ignore.

Conclusion

Évidemment, cet outil prend son sens combiné a git, (ainsi que git-crypt, et à un gestionnaire de mot de passe).

Et vous, cher Nal, quelle méthode utilisez-vous pour résoudre ce problème ?

  • # Git + ansible + liens symboliques

    Posté par  . Évalué à 6. Dernière modification le 18 août 2017 à 21:41.

    Je synchronise mes dotfiles sur mes petits VPS et les deux postes client (boulot et perso), pour ça j’utilise Ansible qui va me faire des liens symboliques vers un dépôt git. Les rôles, playbooks et inventaires sont aussi dans un dépôt Ansible, qui lui est privé et auto-hébergé.

    Ensuite un dépôt git pour les dotfiles, dans lequel il n’y a rien de privé de stocké, ce qui m’évite de devoir utiliser du chiffrement, tout en me permettant d’exposer mes fichiers de conf publiquement sur github. Je n’ai pas besoin de chiffrer des données et je m’arrange toujours pour pouvoir continuer ainsi. Ça ne me pose pas de problèmes. J’y songerai quand ça sera le cas :p

    Certains diront que c’est bourrin d’utiliser Ansible, et si c’est pour ce seul but, ça l’est sans doute. Personnellement je connais bien l’outil du coup ça ne me pose pas de problème. Et puis ça répond aussi à d’autres besoin, comme l’installation de certains paquets qui me sont essentiels, sur toutes les machines. Comme par exemple tmux, tcpdump, bind-utils, strace, htop, vim et j’en passe…

    • [^] # Re: Git + ansible + liens symboliques

      Posté par  . Évalué à 4.

      Pareil, mon rôle ansible :
      - créé l'user
      - lui génère une clé SSH
      - récupère la clé générée, la dépose dans le authorized_keys du serveur git
      - clone le repository dotfiles
      - créé les liens symboliques

      mais aussi :
      - installe les paquets essentiels
      - pousse le .bashrc de root, et d'autres confs dans /etc (vimrc, screenrc)
      - génère un motd avec figlet
      - pousse mon lesspipe
      - installe un firewall (iptables + fail2ban)
      - installe ntpd

    • [^] # Re: Git + ansible + liens symboliques

      Posté par  (site web personnel) . Évalué à 2.

      J'avais du Ansible y'a quelques temps, je suis repassé à un gros script sh qui me fait mes symlinks.
      C'est plus rapide à maintenir et j'utilisais pas vraiment la puissance d'Ansible pour ça…

      • [^] # Re: Git + ansible + liens symboliques

        Posté par  . Évalué à 3.

        Pareil, j'ai regardé qqs trucs et j'ai finir par coder mon script shell, et comme je passais un temps fou à chercher comment faire des choses simples en shell, j'ai fini par le faire en python.

        J'utilise la notion de submodule de git pour introduire des modules plugins vim eux aussi disponible via git.

  • # "standard" xdg + git + sh + workarounds

    Posté par  . Évalué à 3. Dernière modification le 18 août 2017 à 21:51.

    C'est dans le titre:

    • je gitifie mon $XDG_HOME_TRUC
    • si un outil (genre vim, parce que je n'ai pas encore cherche serieusement comment utiliser de la coloration syntaxique avec kakoune) ne supporte pas cette convention, soit je le change (bash deviens donc zsh, meme si c'est pas la seule raison valable), soit je trouve un workaround.
    • des scripts/variables/alias sh pour generer ou "dynamiser" les variantes selon le systeme
    • une branche par type de systeme pour les config non generables

    Mais je reconnais ne pas avoir totalement chiade mes trucs.
    Franchement, je voudrai un DE base sur i3 (ou tmux je suppose, pour avoir un de tty-based, mais j'ai jamais teste ce dernier ou son concurrent) et des outils pour sync les config des outils interactifs, mais pour ca faut que je me sorte les doigts, parce que je suis sur que c'est faisable.

    Le plus gros probleme que j'ai actuellement, c'est que dans Debian il n'existe rien a ma connaissance pour definir un squelette de variables XDG_* controllable par les utilisateurs. J'avais commence a bosser la dessus via une combinaison de runit et ngetty, mais le fait d'empecher l'utilisateur de redefinir ses dossiers ainsi que le fait de n'avoir pas trouve de solution propre pour nettoyer xdg_runtime_dir quand l'utilisateur ferme sa derniere session me genait.
    Peut-etre que le cote config oar un user pourrait etre gere de la meme facon que passwd fait, mais il reste l'utmp qui a l'air, selon le man debian,gere de facon assez aleatoire…
    J'ai dit Debian? Oups, je devrai dire void, parce que les custo que j'ai bricolees sont basees sur runit (usage de /dev/shm pour que les users aient un /run perso p.ex., tellement trivial sous runit+ngetty) et que je reconnais ne pas avoir cherche pour systemd (enfin… j'ai cherche a changer le getty et rien que ca, ca a l'air bien penible a faire proprement), et que mes scripts runit sous debian ne sont pas parfaits (trop bases sur inittab a mon gout, donc sysv toujours necessaire).

    PS: t'abuses, je me suis emmerde toute la journee au taf et je suis sur que ton journal m'aurait bien occupe via les commentaires, mais il a fallu que tu postes le soir! :D

  • # Gnu stow

    Posté par  (site web personnel) . Évalué à 6.

    Je connaissais stow qui fait la même chose à force d'avoir traîné un peu sur unixporn, mais c'est le genre d'outil très pratique qui ne sont pas si connu que ça…

  • # Pas de configuration ou bien BSD Owl

    Posté par  (site web personnel) . Évalué à 5.

    La solution que je privilégie est de ne pas configurer les outils que j'utilise, tant que c'est une solution acceptable. Si j'ai vraiment besoin de configurer quelque chose, alors j'utilise les makefiles BSD Owl qui ont un module spécial pour ça.

    En pratique je n'ai qu'un fichier dot.emacs qui précharge les modules que j'utilise et et un fichier dot.zshrc qui définit trois variables d'environnement, parceque j'essaie de me conformer au maximum de non configuration.

  • # Nommage

    Posté par  (site web personnel) . Évalué à 7.

    Je me suis demandé si c'était un nom choisi au hasard ou non. La réponse est probablement non, vu que le terme désignait d'anciennes tables de loi grecque (sources 1 et2). Fin de la minute culturelle.

  • # Commentaire supprimé

    Posté par  . Évalué à 6.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # confman

    Posté par  (site web personnel) . Évalué à 2.

    Et vous, cher Nal, quelle méthode utilisez-vous pour résoudre ce problème ?

    J'ai écrit https://pypi.python.org/pypi/confman qui se base sur le même principe (prend tous les fichiers d'un dossier pour en faire des liens symboliques) mais qui gère aussi plein de cas spécifiques. Le principe reste le même, la simplicité prime et il doit y avoir peu à configurer.

    Il me manque le support des déplacements/suppressions de fichiers, cependant. J'ai aussi eu la flemme de faire une interface en ligne de commande, il faut donc écrire un fichier .py pour le lancer…

  • # Sans liens symboliques

    Posté par  . Évalué à 4.

    Quand on y pense, git gère des « liens » placés dans un work-tree vers une version spécifique d'un fichier dans sa « base de données ». En pratique, ce sont des fichiers, mais l'opération de check-out correspond à une sort de « mise à jour des liens ». Bon, l'analogie est moyenne, mais chez moi ça a donné ça :

    http://dolka.fr/code/gitweb/?p=dotfiles.git;a=summary

    Bref, des dotfiles gérés réellement comme des fichiers (puisque j'ai juste déplacé le work-tree dans $HOME), et une utilisation à la git juste en changeant le nom de la commande, « dotg » (à part pour les commandes spécifiques de création initiale). Pour le code directement à lire, c'est ici :
    http://dolka.fr/code/gitweb/?p=dotfiles.git;a=blob;f=bin/dotg;hb=HEAD

    C'est sous GPLv3+.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.