Предыстория
Когда на руках появляется более одного рабочего устройства, то к тебе, %username%, приходит желание иметь одинаковую конфигурацию и тут, и там, и на работе, и дома. Когда я только-только начинал попытки синхронизировать файлы, мне было достаточно Dropbox и Yandex.disk. Особенно хорошо они помогали синхронизировать документы и историю джаббера, но как только я попытался приспособить их к .bashrc, .vimrc и им подобным, тут же повылезали различные сайд-эффекты. Например, с symlink'ами в обоих системах полнейшая беда, ± какая-то история есть только в дропбоксе, ну и писать скрипты управления зоопарком пришлось бы самому. Наверняка ведь что-то уже написано, правда?
История
На страничке https://dotfiles.github.io/ представлены чуть меньше сотни различных утилит, плагинов и подходов к управлению конфигурациями — от заточенных под отдельные программы до универсальных. Очень советую ознакомиться, вполне возможно, что Вы прекратите дальнейшее чтение и пойдёте выбирать себе что-нибудь более приемлемое.
Общий смысл философии сводится к тому, что конфиги лежат в репозитории %your_favorit_vcs% в определённом виде и оттуда расползаются по $HOME
. Так как %default_vcs% сейчас это git, то его я и буду использовать далее.
Начинал я своё знакомство с dotfiles-in-git с утилитки под названием dotgit. Она начиналась как "простенькая и понятная на чистом bash". Но в момент, когда автор добавил туда шифрование с возможностью делать симлинки непосредственно на директории, и я попытался во всём этом разобраться (примерно начало 2017 года), у моей домашней папки случился огурец
rcm
Итак, как уже было сказано, вариантов утилит существует, действительно, много. rcm был выбран по следующим причинам:
- Чистый sh, даже не bash. Он не тянет за собой ни python, ни ruby, ничего другого
- Позволяет настраивать поведение доставки конфигов
- Наличие man-страниц
- Кастомизация деплоя с помощью папок
tag-*
иhost-*
- Долгая поддержка, живой развивающийся проект
- На момент использования и по сей день это не актуально, но поддерживаются
{pre,post}-{up,down}
хуки для обновления и очистки файлов конфигурации
Наиболее важным пунктом является, разумеется, документация, ибо без неё я бы не дошёл того, чтобы полностью настроить поведение деплоя под себя.
После установки менеджера будут доступны 4 команды:
- lsrc — выводит список того, как будет выглядеть конфигурация после выполнения
rcup
- mkrc — добавляет файл в
~/.dotfiles
(по умолчанию, можно изменить в~/.rcrc
) и затем устанавливает их обратно. Если необходимо нестандартное поведение, лучше сперва поправить~/.rcrc
, в противном случае могут быть неожиданные спецэффекты - rcdn — удаляет все файлы конфигурации, управляемые посредством rcm
- rcup — устанавливает все файлы
Как таковой, файл ~/.rcrc
— просто часть shell-скрипта, который подключается командой source
при каждом вызове утилит rcm. Исходя из этого, его можно сделать модульным, со встроенной логикой. Согласно документации, его содержимое позволяет тонко управлять параметрами установки дотфайлов при помощи rcup
, например:
- поведение по умолчанию: на каждый файл внутри
~/.dotfiles
создаётся симлинк в домашней папке без начальной точки (например,'/home/felixoid/.dotfiles/bashrc' -> '/home/felixoid/.bashrc'
,'/home/felixoid/.dotfiles/README.md' -> '/home/felixoid/.README.md'
) - папочка
~/.vim
: является симлинком на папку/home/felixoid/.dotfiles/vim
(опция SYMLINK_DIRS) - папочка
~/.some_secret_files
: скопированная из/home/felixoid/.dotfiles/tag-dmz/some_secret_files
(опция COPY_ALWAYS) - файл
~/.README.md
на самом деле игнорируется (опция EXCLUDES) - файл
'/home/felixoid/.zshenv'
является симлинком на'/home/felixoid/.dotfiles/tag-zsh/zshenv'
(параметр TAGS) - папка
~/bin
также управляется при помощи rcm, её содержимое приезжает из/home/felixoid/.dotfiles/bin/
(параметр UNDOTTED)
Иногда может потребоваться упоминание одного и того же файла в нескольких опциях. Например, так должен выглядеть сниппет .rcrc, если всё содержимое ~/bin
должно находиться в ~/.dotfiles/tag-bins/bin
и копироваться as is:
COPY_ALWAYS="bin/*"
TAGS="bins"
UNDOTTED="bin"
Собственно, пример того, как можно организовать содержимое папки ~/.dotfiles
, есть в репозитории с дотфайлами. Исчерпывающая информация содержится в документации, не стесняйтесь прочитать следующие man-страницы: lsrc(1), mkrc(1), rcrc(5) rcdn(1), rcm(7), rcup(1).
Несказанное и несделанное
Пока я набирал данный текст, ко мне пришли неплохие идеи о том, как можно организовать хранение чувствительных данных внутри публичного репозитория. Например, меня всегда волновал вопрос, имеет ли смысл и возможно ли делать бекапы ключей gpg и ssh? Как раз для этого могли бы пригодиться хуки: упаковывать их в tar, затем шифровать тем же симметричным gpg с последующей распаковкой. Возможно, этому я посвящу следующую заметку после реализации. Или, может быть, это очередной велосипед? И всё уже придумано? Добавьте в комментариях, если это на самом деле так.
Очень надеюсь, что данный материал вызовет заинтересованность и желание попробовать организовать управление конфигами в полуавтоматическом режиме!
И небольшой опросик:
Автор: felix0id