Мне часто приходится разворачивать свою рабочую среду (в частности, Kali Linux) на новых машинах: то на железе, то на виртуалках, то снова на железе... В какой-то момент мне надоели рутинные действия, и я решил извлечь из этой ситуации максимальную пользу для себя и окружающих. В этой статье поговорим о том, как можно организовать хранение своих дотфайлов, чтобы более-менее автоматизировать настройку и персонализацию различных ОС для дома и работы.
 

.файлы

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

Эта концепция стара как мир и носит название «дотфайлы» — файлы, названия которых начинаются с точки, а так как большинство конфигов в никсах и правда начинаются с точки (чтобы стать скрытыми и не мозолить глаза юзеру в выводе ls), то все вполне логично.

Удобнее всего, на мой взгляд, организовать хранение дотфайлов в системе управления версиями (CVS), чтобы можно было клонировать репозиторий одним действием при настройке новой системы. Однако это накладывает определенные условия на то, что́ смогут содержать твои конфиги, так как нельзя забывать, что CVS — штука публичная.

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

Итак, у меня есть два репозитория.

Первый — dotfiles-linux — конфигурационные файлы для приложений на Linux.

Ветки master и wsl репозитория dotfiles-linux
Ветки master и wsl репозитория dotfiles-linux

Второй — dotfiles-windows — конфигурационные файлы для приложений на Windows.

Ветка master репозитория dotfiles-windows
Ветка master репозитория dotfiles-windows

В первом репозитории две ветки: master и wsl. Ветка wsl отвечает за версии дотфайлов, которые я использую во втором репозитории для персонализации Windows Subsystem for Linux. Когда при настройке винды я заметил, что никсовые конфиги не получается юзать для WSL «в чистом виде», то решил вести отдельную ветку, которую позже включил в dotfiles-windows в качестве подмодуля.

Результат такой: когда я разворачиваю дотфайлы на новой системе с Windows, я должен выполнить изнутри WSL следующие команды.

~$ WIN_DOTFILES_DIR="$(wslpathcmd.exe /C "echo %USERPROFILE%" | tr -d "\r")/.dotfiles"

Первым действием с помощью wslpath, который резолвит пути между хостовой ОС и WSL, я создаю переменную с именем директории, куда я клонирую репозиторий с моими дотфайлами для Windows. В моем случае директория будет называться /mnt/c/Users/snovvcrash/.dotfiles.

~$ git clone https://github.com/snovvcrash/dotfiles-windows "${WIN_DOTFILES_DIR}"

Далее я выкачиваю dotfiles-windows по этому пути.

~$ ln -sv "${WIN_DOTFILES_DIR}/wsl" ~/.dotfiles

Последним действием я создаю символическую ссылку в файловой системе WSL. Она будет указывать на подмодуль /mnt/c/Users/snovvcrash/.dotfiles/wsl, который мы заберем с гита, как показано ниже.

/mnt/c/Users/snovvcrash/.dotfiles$ git submodule update --init --remote
/mnt/c/Users/snovvcrash/.dotfiles$ git submodule foreach "git checkout $(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)"

Здесь я инициализирую git-подмодуль для данного репозитория на основании настроек .gitmodules, а потом восстанавливаю стейт detached HEAD для всех подгрузившихся подмодулей, так как по дефолту они выкачиваются с отваленными головами.

Если интересно настроить такую же схему, как у меня, это можно сделать с помощью одной команды, которая добавит подмодуль wsl в твой репозиторий дотфайлов из существующего ремоута.

/mnt/c/Users/snovvcrash/.dotfiles$ git submodule add https://github.com/snovvcrash/dotfiles-linux wsl

Результат такой же, как если бы я вручную изменил конфиг .gitmodules с помощью git config.

/mnt/c/Users/snovvcrash/.dotfiles$ git config -f .gitmodules submodule.wsl.branch wsl

Про концепцию хранения дотфайлов поговорили, а что же, собственно, можно в них хранить? Я остановлюсь только на нескольких тулзах, которыми постоянно пользуюсь в Linux: описание всего, что там лежит, может растянуться на долгие часы.

 

Zsh

С какого-то момента я перестал воспринимать Bash как шелл, в котором можно комфортно работать. Да, разумеется, если жизнь заставит (особенно если это реверс-коннект с машины-жертвы), можно юзать и обычный /bin/sh без автодополнения, истории и управляющих символов. Но даже реверс-шелл можно довести до ума, проапгрейдив его до PTY, чего уж говорить о дефолтной оболочке на своей машине. Поэтому я использую Zsh. Не писал о нем только ленивый, так что сразу перейдем к минимальному набору приятностей, нужных, чтобы удобно с ним существовать.

 

Oh My Zsh

В первую очередь это, конечно же, фреймворк Oh My Zsh, позволяющий играючи управлять дополнениями и плагинами Zsh. Маст-хэвом я считаю zsh-syntax-highlighting для подсветки синтаксиса команд в терминале и zsh-autosuggestions для предложения автозавершения команд на основе твоей истории. Установка сводится к выполнению трех простых действий, после которых нужно перелогиниться, чтобы изменения возымели эффект.

$ apt install zsh -y && sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
$ git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting
$ git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
$ sed -i 's/plugins=(git)/plugins=(git zsh-syntax-highlighting zsh-autosuggestions)/g' ~/.zshrc

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

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.


3 комментария

  1. Аватар

    akimdi

    13.04.2020 в 17:29

    ммм… да.. после такого даже подписку на хакер не хочется продлевать. При всём уважении, тема не раскрыта. Не написано не про системы управления дотфайлами, типо chezmoi или yadm, ни про безопасность, типо токены или ключи, ни про то как подружить системы конфигураций с дотфайлами, типо примеров с ansible.
    А лишь пару каких-то скриптов написанных на коленке.

    • snovvcrash

      snovvcrash

      13.04.2020 в 19:48

      Как и в любом другом предмете обсуждения, здесь есть разные углы обзора, откуда можно смотреть на тему. Менеджеры управления дотфайлами, это здорово, безусловно, однако в этой статье освещается более нативный слой работы с конфигами — своими силами, без установки стороннего софта. С ansible та же история: если бы мы погружались в сторону деплоя десятков виртуалок на vSphere, которые бы работали в бэкграунде по заранее спланированному сценарию — то да, плейбуки ansible самое оно. Но когда ты ставишь систему для себя (для непосредственной там работы на долгой основе), комфортнее принимать более интерактивное участие в настройке, чтобы иметь возможность что-то отладить здесь и сейчас, если очередная установка пойдет не по плану (что бывает довольно часто). По крайне мере, мне всегда так было комфортнее 🙂

    • Аватар

      WellFedCat

      25.04.2020 в 17:14

Оставить мнение