NEXT GENERATION DOTFILES CONTINUOUS CONFIGURATION

Увидел CapsLock в заглавии и дальше не читал.

В наши дни каждая домохозяйка хранит свои дотфаелсы на гитхабе. Тысячи репозиториев, одни и те же конфиги

...и частные ключи SSH.

приватные ключи встречаются только у людей, которые гитхаб используют в виде невосстанавливаемого бэкапа

У меня как-то всё работает через git, симлинки и скрипт на баше. Для дотфайлов два репозитория – один в качестве паблика доступен через гитхаб (назовём его dotfiles), второй с персональным хламом, который удобно переносить вместе, но выкладывать в паблик – только засорять и плагиатить чужие работы, в этом же репозитории находятся ssh-ключи (назовём его general). Эти два репозитория немного отличаются в строении каталогов – dotfiles представляет из себя файлы в хомяке, а general имитирует корень ФС, т. е. там есть папка home, в ней fargred, а там уже файлы. Сделано так для удобства деплоя, о чём будет ниже, пока скажу только, что на месте файлов из dotfiles в general находятся симлинки, указывающие на эти файлы (туда, где они на самом деле лежат, в dotfiles). Фактически деплоится из этих двух только general.

Скрипт (пусть будет deploy.sh) ожидает в environment переменную REPOS_DIR, содержащую путь до репозиториев, которые можно деплоить, этот скрипт принимает единственный параметр – имя репозитория из REPOS_DIR и дальше работа происходит уже с ним. Скрипт ищет в этом репозитории каталоги, повторяющие каталоги корневой файловой системы, и, если таковые есть, мержит их. Под «мержит» подразумевается, что он проверяет дерево каталогов в корне на соответствие тому, что в репозитории, и создаёт недостающие. После этого он создаёт в ФС симлинки на файлы из репозитория, а если файл существует – удаляет его. Каждый каталог предварительно очищается от поломанных ссылок. Скрипт также читает .gitignore в корне репозитория, предназначенного на деплой, и строит по паттернам правила исключения для файлов, которые не надо деплоить, даже если они там есть (т. е. всякие бекапы и прочая, не тащим мусор в натуральную ФС). Проверка на каталогов-близнецов в корне репозитория и корне ФС позволяет держать наверху служебные файлы и прочие каталоги, как тот же .gitignore, например.

После проведённых операций, получится, что за два вызова git clone и один deploy.sh (не считая копирования папки ~/.ssh ручками) хомяк будет полностью восстановлен. Дерево каталогов будет полностью соответствовать тому, что в general, симлинки будут вести или на конфиги в самом general, или на другие симлинки, которые тоже находятся в general, но ведут в distfiles. Вообще, можно обойтись и одним репозиторием, если вы не собираетесь делать часть конфигов публичной. А ещё таким же образом у меня деплоятся и системные конфиги, ня.

у меня всегда есть «одно место», которое можно всегда склонировать с гитхаба, а скрипт настроит симлинки системных и пользовательских настроек в это место, но не наоборот.

- как называется процесс менеджирования домашних конфигов?

Красноглазие.

И как этой схемой пользоваться для нескольких окружений?

Ну, это обычный install.sh

5.5

«Окружений»?

Конфигурирование ≠ деплой, кстати.

Деплоем в данном случае является установка определённых версий пакетов, или сборка сервисов из исходников. Подсовывание пускай даже нагенерированных конфигов не является деплоем как таковым.

Окружение - рабочая станция с дотфаелсами. Репозиторий один, конфиги сервисов представлены в единственном числе, окружения почти одинаковые, но есть небольшие отличия. Шрифты в ~/.Xdefaults на одном ноуте 14, а на другом 10. На одном ноуте гента, на другом дебиан, поэтому в одном случае в конфиге firefox, а в другом - iceweasel. Виму на одном ноуте нужна определённая функциональность, включаемая в vimrc, на другом - нет. На одном ноуте нужен конфиг для идеи, на другом не нужен.

Продолжать можно до бесконечности.

Мне тут безумная идея пришла. Конфиги с условными директивами на m4 + модуль fuse который на лету отображает результаты обработки файлов макропроцессором.

А чем это лучше шефа?

Я хз, что делает шеф, ибо не сталкивался. Но подозреваю, что там в явном виде присутствует фаза компиляции итоговых конфигов из сорцов. Здесь же её не будет.

в чистом поле васильки - цветут, цветут, цветут (с)

Годно, попробую
!

Шрифты в ~/.Xdefaults на одном ноуте 14, а на другом 10

Поэтому у меня везде стоит одно и то же dpi и терминус, который от этого не страдает. Но я понимаю, о чём ты, в таких случаях у меня либо в самих конфигах профайлы по $HOSTNAME, либо конфиг компонуется во время запуска WM из ~/.someconf.common и ~/.someconf.$HOSTNAME. Компоновка прописана в ~/.xinitrc, точнее, в файле, который сорсится оттуда (он ещё может сорситься и из ~/.xsession, поэтому, чтоб два раза не писать, один файл и source).

На одном ноуте гента, на другом дебиан

Эмм. Мне это кажется кучей потенциальных несовместимостей. У меня везде гента, файерфокс и емакс. FF синкается с mozilla-облаком, поэтому жирнопапки фокса в репах нет.

Деплоем в данном случае является установка определённых версий пакетов, или сборка сервисов из исходников.

Вот как не стыдно,а? Да понимаю я, что в хорошем смысле деплой это развёртывание вообще всего, что надо, но плохо представляю, чем это может быть и закончиться в генте. А так для домашних машин держится по два репозитория – один общий system, где хоум-папка рута, пачка дефолтных конфигов в /etc, глобальные настройки портежа, и второй персональный для машинки, там локальный /etc, локальные настройки портежей, world и layman.conf. При развёртывании после конфигов останется разве что локали сгенерировать, граб установить в MBR да ядро с миром пересобрать через -e. Кстати надо ещё конфиг ведра в локальный репо загнать, что-то я сразу не додумался.

Расскажи про впечатления - что неудобно, чего не хватает. Не хватает ишьюсов и понимания юзабельности с точки зрения абстрактного пользователя.

Поэтому у меня везде стоит одно и то же dpi и терминус, который от этого не страдает. Но я понимаю, о чём ты, в таких случаях у меня либо в самих конфигах профайлы по $HOSTNAME, либо конфиг компонуется во время запуска WM из ~/.someconf.common и ~/.someconf.$HOSTNAME. Компоновка прописана в ~/.xinitrc, точнее, в файле, который сорсится оттуда (он ещё может сорситься и из ~/.xsession, поэтому, чтоб два раза не писать, один файл и source).

Это звучит как насильно упрощение модели для невозникновения интересных проблем. В реальной жизни часто разные машины используются для разных нужд. Часто даже размеры мониторов разные и дпи. Поэтому конфигурация систем тоже получается разная. Хранить копипасту конфигов и поддерживать их все параллельно - это ад, г-но и палки.

Эмм. Мне это кажется кучей потенциальных несовместимостей.

Именно в этом и заключается основной интерес.

Вот как не стыдно,а?

А что стыдного? По ссылке пример сельского деплоя в куче - без фазы сбора артефактов и так далее. Да, это пещерный век, то так или иначе это деплой. Накатывание конфигов - это конфигурация, совсем иная куча проблем и задач.

Есть erb-компиляция конфигов из темлейтов. Пхп-вей.

Хранить копипасту конфигов и поддерживать их все параллельно - это ад, г-но и палки.

Согласен. Поэтому и не храню, лол.

Именно в этом и заключается основной интерес.

Не знаю, как тебя, а меня тошнит от гетерогенных зоопарков.

По ссылке пример сельского деплоя

Я что-то не заметил там «установку определённых версий пакетов» или «сборку из исходников».

А посмотри повнимательнее. Сборкой из исходников обычно воняет возле упоминаний использования гита на машинах, предназначенных для деплоя.

Там дебиан.

Ожидал увидеть там Python, .. ну может Perl. О мой б-г, хацкель! Пошто используете «3rd party», когда на машинах по дефолту его почти нет?

// И как там с поддержкой оффтопиков (обеих)? Тоже ведь хранить конфиги нужно.

речь идёт не о промышленном конфигурировании, а о домашем дотфаелсожонглировании от избытка свободного времени

Не благодари https://github.com/RichiH/vcsh

// zubb

Оно одномашинное?

A man's home is his castle. Never leave your dotfiles behind.

https://github.com/technicalpickles/homesick