Contexte
Lorsque plus d'un appareil fonctionnel apparaît entre vos mains, alors% username% vient à vous pour avoir la même configuration ici et là, au travail et à la maison. Quand je viens de commencer à essayer de synchroniser des fichiers, Dropbox et Yandex.disk me suffisaient. Ils étaient particulièrement bons pour synchroniser les documents et l'historique du jabber, mais dès que j'ai essayé de les adapter au .bashrc, .vimrc et autres, divers effets secondaires sont apparus. Par exemple, avec des liens symboliques dans les deux systèmes, c'est un désastre complet, ± il n'y a une sorte d'histoire que dans la boîte de dépôt, eh bien, je devrais écrire des scripts pour gérer le zoo moi-même. Certes, quelque chose a déjà été écrit, non?
L'histoire
Sur la page https://dotfiles.imtqy.com/, vous pouvez voir un peu moins d'une centaine d'utilitaires, plug-ins et approches différents pour gérer les configurations - des programmes personnalisés aux programmes individuels aux programmes universels. Je vous conseille fortement de vous familiariser, il est fort possible que vous arrêtiez la lecture et que vous choisissiez quelque chose de plus acceptable.
Le sens général de la philosophie se résume au fait que les configurations sont dans le dépôt% your_favorit_vcs% sous une certaine forme et de là se glissent dans $HOME . Puisque% default_vcs% est maintenant git, je vais l'utiliser plus loin.
J'ai commencé ma connaissance de dotfiles-in-git avec un utilitaire appelé dotgit . Cela a commencé comme «simple et direct en pure bash». Mais au moment où l'auteur y a ajouté un cryptage avec la possibilité de créer des liens symboliques directement vers le répertoire, et j'ai essayé de tout comprendre (vers le début de 2017), un concombre de mon cerveau s'est produit dans mon dossier personnel avec des liens brisés et une récupération manuelle des fichiers de la gita. En général, une journée a été allouée pour rechercher des alternatives avec la possibilité de régler le comportement et une configuration simple.
rcm
Ainsi, comme déjà mentionné, il existe de nombreuses options pour les utilitaires. rcm a été choisi pour les raisons suivantes:
- Pure sh, pas même bash. Il ne tire ni python ni rubis, rien d'autre
- Vous permet de configurer le comportement de livraison de la configuration
- La présence de pages de manuel
- Personnalisation du déploiement à l'aide des dossiers
tag-* et host-* - Long soutien, projet en développement vivant
- Au moment de l'utilisation, à ce jour, cela n'est pas pertinent, mais les crochets
{pre,post}-{up,down} pour la mise à jour et l'effacement des fichiers de configuration sont pris en charge
Le point le plus important est, bien sûr, la documentation, car sans elle, je ne serais pas allé jusqu'à personnaliser entièrement le comportement de déploiement.
Après l'installation du gestionnaire, 4 commandes seront disponibles:
- lsrc - Liste à quoi ressemblera la configuration après
rcup - mkrc - ajoute le fichier à
~/.dotfiles (par défaut, vous pouvez le changer en ~/.rcrc ), puis réinstallez-le. Si vous avez besoin d'un comportement non standard, il est préférable de d'abord corriger ~/.rcrc , sinon il peut y avoir des effets spéciaux inattendus. - rcdn - supprime tous les fichiers de configuration gérés par rcm.
- rcup - installe tous les fichiers. Si vous utilisez l'option
-g , un script shell séparé sera généré, qui peut également être placé dans le référentiel pour une utilisation sur les hôtes où le gestionnaire n'est pas installé.
En tant que tel, le ~/.rcrc fait simplement partie du script shell inclus avec la commande source chaque appel des utilitaires rcm. Sur cette base, il peut être rendu modulaire, avec une logique intégrée. Selon la documentation, son contenu vous permet de contrôler finement les paramètres des fichiers dot à l'aide de rcup , par exemple:
- comportement par défaut: pour chaque fichier à l'intérieur de
~/.dotfiles , un lien symbolique est créé dans le dossier de départ sans point de départ (par exemple, '/home/felixoid/.dotfiles/bashrc' -> '/home/felixoid/.bashrc' , '/home/felixoid/.dotfiles/README.md' -> '/home/felixoid/.README.md' ) - daddy
~/.vim : est un lien symbolique vers le dossier /home/felixoid/.dotfiles/vim (option SYMLINK_DIRS) - papa
~/.some_secret_files : copié depuis /home/felixoid/.dotfiles/tag-dmz/some_secret_files (option COPY_ALWAYS) - le fichier
~/.README.md est en fait ignoré (option EXCLUDES) - le fichier
'/home/felixoid/.zshenv' est un lien symbolique vers '/home/felixoid/.dotfiles/tag-zsh/zshenv' (paramètre TAGS) - le
~/bin également géré avec rcm, son contenu provient de /home/felixoid/.dotfiles/bin/ (paramètre UNDOTTED)
Parfois, il peut être nécessaire de mentionner le même fichier dans plusieurs options. Par exemple, l'extrait .rcrc doit ressembler à ceci si tout le contenu de ~/bin doit être dans ~/.dotfiles/tag-bins/bin et copié tel ~/.dotfiles/tag-bins/bin :
COPY_ALWAYS="bin/*" TAGS="bins" UNDOTTED="bin"
En fait, un exemple de la façon d'organiser le contenu du dossier ~/.dotfiles trouve dans le référentiel avec dotfiles. Des informations complètes sont contenues dans la documentation, n'hésitez pas à lire les pages de manuel suivantes: lsrc (1), mkrc (1), rcrc (5) rcdn (1), rcm (7), rcup (1).
Untold and Untold
Pendant que je tapais ce texte, de bonnes idées me sont venues sur la façon d'organiser le stockage des données sensibles dans un référentiel public. Par exemple, j'ai toujours été préoccupé par la question: est-ce que cela a du sens et est-il possible de sauvegarder des clés gpg et ssh? Juste pour cela, les crochets pourraient être utiles: emballez-les dans du goudron, puis chiffrez avec le même gpg symétrique, puis déballez. J'y consacrerai peut-être la note suivante après la mise en œuvre. Ou peut-être que c'est un autre vélo? Et tout a déjà été inventé? Ajoutez les commentaires si c'est réellement le cas.
J'espère vraiment que ce matériel suscitera l'intérêt et le désir d'essayer d'organiser la gestion des configs en mode semi-automatique!
Et une petite enquête: