Как вы, наверное, знаете, в *nix, в отличие от Windows¹, можно удалить открытый кем-то файл; при этом имя из файловой системы пропадает сразу, а место, занятое данными, освободится лишь после закрытия файла всеми процессами.

При обновлении системы ситуацию с уже удалёнными, но всё ещё кем-то используемыми файлами можно встретить сплошь и рядом: при обновлении библиотеки старый .so может быть удалён, а на его место под тем же именем помещена новая сборка. При этом процессы, использующие старую версию, будут продолжать ею пользоваться, а новые будут запускаться уже с обновлённой. Это может привести к проблемам: к примеру, в случае с Heartbleed одного только обновления libssl мало, нужно ещё и перезапустить sshd, Nginx, Apache и вообще всё-всё-всё, что работало с SSL.

В Debian есть готовое решение, работающее с любым демоном — checkrestart (пакет debian-goodies). Он показывает, какие из демонов пользуются устаревшими файлами, и объясняет, как их перезапустить.

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

$ sudo lsof / | grep DEL | cut -f1 -d' ' | sort -u

Что он делает:

1. lsof показывает все-все-все открытые файлы и сокеты. lsof / показывает только файлы. При запущенном торрент-клиенте, постоянно плодящем соединения, вывод сокетов занимает кучу времени, поэтому я отсеиваю их на этом этапе;

2. в выводе lsof присутствует колонка TYPE, показывающая тип открытого ресурса: файл (REG), директория (DIR), сокет (IPv4 или IPv6) и, наконец, файлы, которые были удалены (DEL). Есть ещё целая куча других типов, читайте lsof(8). В общем, grep DEL выдирает строки с удалёнными файлами;

3. в получившемся списке меня интересуют только имена процессов (первая колонка), поэтому я вырезаю её (cut) и сортирую, удаляя повторяющиеся строки (sort -u);

4. voilà: теперь у нас есть список процессов, которые нужно перезапустить. Эту часть я всё никак не соберусь автоматизировать.

Некоторые процессы могут перезапускаться не самостоятельно, а вместе с другими, например:

• для перезапуска udisksd, polkitd и console-kit нужно перезапустить dbus;
• для перезапуска dhclient и wicd-monitor нужно убить dhclient (sudo pkill dhclient), перезапустить wicd и, кажется, переподключиться к сети.

Некоторые другие процессы перезапустить вообще нельзя (например, systemd — там хоть и есть daemon-reexec, но у меня он почему-то никогда не работает).

И, конечно же, не следует забывать про ядро — в списке процессов его не видно, но обновления придти могут. Тут уже только ребут поможет (или ksplice, но ребутнуться проще :)

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

В результате появился репозиторий, представляющий из себя кучку дотфайлов и скрипт, который создавал в $HOME симлинки. Это было не слишком удобно, потому что в случае добавления в репозиторий нового дотфайла я должен был не забыть на всех остальных машинах этот скрипт запустить. Кроме того, мне не нравилось отсутствие тотальности: репозиторий знал только о тех конфигах, о которых я позаботился ему сообщить. Если я ставил новую программу, конфиг которой мне хотелось бы хранить в Git, я должен был не забыть его туда добавить — сам по себе git status мне о нём не сообщал. В общем, пользоваться этим способом можно, но удобств никаких.

vcsh же даёт гораздо менее костыльное и при этом более мощное решение. Он хранит репозиторий (историю Git) в .config/vcsh/repo.d, а сами конфиги оставляет лежать в домашней директории. Это гораздо лучше смотрится в выводе ls, чем былое обилие симлинков. Это также даёт возможность разбивать ваши дотфайлы на несколько наборов, каждый из которых хранится в отдельном репозитории и клонируется независимо от других². Выделив свой .vimrc в отдельный репозиторий, вы наконец-то сможете везде иметь одинаковую среду редактирования текста, не таская при этом всякую мишуру вроде настроек MPlayer и XScreenSaver (она теперь будет в отдельном репозитории).

Кроме того, vcsh рассматривает мой $HOME как свою рабочую директорию, так что я получаю желанную «тотальность»: теперь git status будет сразу сообщать мне обо всех незнакомых файлах (с учётом .gitignore, конечно). Ура, ура, ура!

Сейчас мы будем делать что-то, что может повредить ваши данные. Советую закрыть все приложения и сделать бекап дотфайлов, например, вот так: tar cvjf dotfiles.tbz2 ~/.*

От слов — к делу. Предварительно вернув $HOME к первозданному виду (чтобы дотфайлы были файлами, а не симлинками на них), установим vcsh (в Squeeze придётся подключить backports, в более новых релизах всё уже в main) и инициализируем репозиторий:

$ cd    # вся работа происходит непосредственно в $HOME
$ sudo aptitude install vcsh
$ vcsh init dotfiles

Теперь перейдём в специальный режим, где все вызовы git будут относиться к свежесозданному репозиторию, и добавим в него несколько конфигов:

$ vcsh enter dotfiles
$ git add .vimrc .tmux.conf
$ git commit -m'Initial commit'

Чтобы в выводе git status вам не мешали обычные файлы, советую добавить в начало .gitignore вот такие строки:

*       # ignore everything...
!.*     # ...but dotfiles
!.*/**  # ...and "dotdirs"

Думаю, из комментариев понятно, что именно они делают.

При желании ваш репозиторий можно опубликовать на GitHub (не забудьте предварительно создать его через веб-интерфейс и поменять в команде ниже адрес на тот, который вам сообщит сайт):

$ git remote add origin 'git@github.com:Minoru/dotfiles.git'
$ git push origin master:master
$ git branch --track master origin/master

Выйти из режима, в который мы попали после vcsh enter, можно с помощью Ctrl-D, exit или просто закрыв окно терминала.

Чтобы не забывать коммитить сделанные изменения, можно добавить в свой crontab напоминалку, которая будет писать вам на локальное мыло (читается с помощью mail):

$ crontab -e
# каждое утро рапортовать о локальных изменениях в репозитории dotfiles
13 7 * * * vcsh dotfiles status --short

Точно так же можно организовать автоматические push и pull, но это останется вам в качестве домашнего задания ☺

На этом обзор базовых возможностей можно считать завершённым. Обязательно пролистайте /usr/share/doc/vcsh/README.md.gz — файл хоть и длинный, но содержит хорошие описания команд и даст вам представление о том, что же умеет vcsh. До новых встреч!

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

Итак, предлог следующий. У многих из нас есть коллекции фотографий, музыки, научных статей, видео с конференций — кучи немаленьких файлов, которые хотелось бы использовать на нескольких машинах сразу, или же удобно архивировать на DVD (или что вы там используете). Эти (как и некоторые другие) задачи и призван решать git-annex.

Технически говоря, git-annex — это надстройка над системой контроля версий Git, но пусть вас это не пугает — с собственно Git’ом вам общаться не придётся, если только вы сами этого не захотите. Git-annex добавляет Git’у новые команды, с помощью которых вы можете инициализировать и управлять своим annex’ом.

Кстати говоря, annex может быть добавлен к любому git-репозиторию, но об этом я здесь говорить не буду — если интересно, почитайте сайт проекта.

Мощь и красоту этой утилиты лучше показывать, а не описывать, так что перейдём к делу. Joey — разработчик Debian, так что не странно, что в нашем с вами любимом дистрибутиве для git-annex есть готовенький пакет:

$ sudo aptitude install git-annex

Я доверяю git-annex все свои мультимедийные данные, и пока что он меня не подводил. Тем не менее, я не советую вам вот так сразу помещать под его управление единственную копию ваших фотографий, публикаций или что вы там собрались в нём хранить — сделайте копию, поэкспериментируйте на ней, а как свыкнитесь с командами, пробуйте уже на «живых» данных.

Перейдём-ка в какую-нибудь директорию с файлами и попробуем создать в ней annex:

$ cd my-first-annex
$ ls -R
.:
avatar.jpg  avatar-myopenid.png  summer_camp_2012  wallpaper.png

./summer_camp_2012:
DSC05599.jpg  DSC05602.jpg  DSC05604.jpg  DSC05605.jpg
$ git init .
Initialized empty Git repository in /tmp/my-first-annex/.git/
$ git annex init 'notebook'
init notebook ok
(Recording state in git...)

Как видите, сперва мы создали git-репозиторий, а затем уже инициализировали в нём annex. Обязательным параметром git annex init является название annex — зачем он нужен, вы узнаете чуть позже.

Добавим и закоммитим файлы:

$ git annex add .
add avatar-myopenid.png (checksum...) ok
add avatar.jpg (checksum...) ok
add summer_camp_2012/DSC05599.jpg (checksum...) ok
add summer_camp_2012/DSC05602.jpg (checksum...) ok
add summer_camp_2012/DSC05604.jpg (checksum...) ok
add summer_camp_2012/DSC05605.jpg (checksum...) ok
add wallpaper.png (checksum...) ok
(Recording state in git...)
$ git commit -m"Добавил аватарки и пару летних фоток"
[master (root-commit) d312aca] Добавил аватарки и пару летних фоток
 7 files changed, 7 insertions(+)
 create mode 120000 avatar-myopenid.png
 create mode 120000 avatar.jpg
 create mode 120000 summer_camp_2012/DSC05599.jpg
 create mode 120000 summer_camp_2012/DSC05602.jpg
 create mode 120000 summer_camp_2012/DSC05604.jpg
 create mode 120000 summer_camp_2012/DSC05605.jpg
 create mode 120000 wallpaper.png
$ ls -l avatar.jpg
lrwxrwxrwx 1 minoru minoru 192 Dec 14 06:38 avatar.jpg ->
.git/annex/objects/7v/Q7/SHA256E-s7164--b442aaed464409198c19f37614dd6e7fd82ee658b897deaddf9a51b08c1aa19f.jpg/SHA256E-s7164--b442aaed464409198c19f37614dd6e7fd82ee658b897deaddf9a51b08c1aa19f.jpg

Ой, что случилось? Не переживайте, всё именно так, как должно быть. В отличие от git, который не трогает ваши файлы, а только запоминает их состояние, git-annex переместил все наши фотографии в глубины .git/annex/objects, а в рабочей директории расставил симлинки на них. Должен предупредить, что симлинки могут негативно сказаться на скорости работы ls -l, ls --color и прочих штук, которые читают содержимое симлинка с целью выяснить, куда он ведёт — на моём ноутбуке с 5400rpm HDD ls -l --color в директории с почти тремя сотнями файлов отрабатывает около секунды. Впрочем, при последующих вызовах кеширование сглаживает это время до нуля, так что ничего страшного я в этой ситуации не вижу.

Ну ладно, комиттить файлы можно было и в простом Git — какие же именно преимущества даёт нам git-annex? Давайте-ка попробуем клонировать наш git-репозиторий куда-нибудь ещё, например, на внешний винчестер:

$ cd /media/storejet
$ git clone /tmp/my-first-annex my-first-annex

Инициализируем здесь annex под названием “storejet” и сообщим первому репозиторию о втором:

$ cd /media/storejet/my-first-annex
$ git annex init 'storejet'
$ git annex sync
(merging origin/git-annex into git-annex...)
(Recording state in git...)
commit  
ok
pull origin 
ok
push origin 
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (8/8), 722 bytes | 0 bytes/s, done.
Total 8 (delta 3), reused 0 (delta 0)
To /tmp/my-first-annex
 * [new branch]      git-annex -> synced/git-annex
 * [new branch]      master -> synced/master
ok
$ # идём обратно в первый репозиторий
$ cd /tmp/my-first-annex 
$ git remote add storejet /media/storejet/my-first-annex
$ git annex sync
commit  
ok
pull storejet 
From /media/storejet/my-first-annex
 * [new branch]      git-annex  -> storejet/git-annex
 * [new branch]      master     -> storejet/master
 * [new branch]      synced/git-annex -> storejet/synced/git-annex
 * [new branch]      synced/master -> storejet/synced/master
ok
pull origin 
From /media/storejet/my-first-annex
   b10e6d9..6706944  git-annex  -> origin/git-annex
ok

Вот эта магия с git remote add — это такой способ объяснить репозиториям, как они могут достучаться до остальных (второй уже знает о первом, потому что был с него клонирован). Возможно, в будущем git-annex начнёт предоставлять какие-то команды, которые эту магию от пользователя спрячут, но пока что работаем так.

Посмотрим на наш свежесозданный клон:

$ ls -l avatar.jpg
lrwxrwxrwx 1 minoru minoru 192 Dec 14 06:59 avatar.jpg ->
.git/annex/objects/7v/Q7/SHA256E-s7164--b442aaed464409198c19f37614dd6e7fd82ee658b897deaddf9a51b08c1aa19f.jpg/SHA256E-s7164--b442aaed464409198c19f37614dd6e7fd82ee658b897deaddf9a51b08c1aa19f.jpg
$ test -e avatar.jpg && echo "Link is ok" || echo "Broken link"
Broken link

Упс, а линк-то битый! (Как и все остальные в репозитории, кстати говоря). Это, господа, вовсе не баг, это фича. Напомню, что файлы хранятся не в в самом git-репозитории, а в .git/annex/objects, поэтому git clone их не копирует. Это даёт вам возможность создавать так называемые partial checkouts — клоны репозитория, в которых присутствуют не все файлы. В то же время, в каждом клоне есть полный список симлинков на все существующие файлы, и их можно легко получить, что мы сейчас и сделаем:

$ git annex get avatar.jpg
get avatar.jpg (from origin...) ok
SHA256E-s7164--b442aaed464409198c19f37614dd6e7fd82ee658b897deaddf9a51b08c1aa19f.jpg
     7,164 100%    1.01MB/s    0:00:00 (xfr#1, to-chk=0/1)
ok
(Recording state in git...)
$ test -e avatar.jpg && echo "Link is ok" || echo "Broken link"
Link is ok

Что сейчас произошло? git-annex сообразил, что файла в текущем клоне нет, но он есть в origin (это тот репозиторий, с которого был клонирован данный, то есть наш “notebook”), после чего файл был скопирован в текущий клон. Как видно из вывода, для копирования был использован rsync, что как бы намекает, что передача файлов неплохо оптимизирована (передаётся только разница, есть докачка).

Вы всегда можете выяснить, где именно находится тот или иной файл:

$ git annex whereis avatar.jpg
whereis avatar.jpg (2 copies) 
    31ef94bc-12d5-4af4-96a2-fb73bac12039 -- here (storejet)
    8644f457-86ec-4b15-bdc5-022ded68d4fa -- origin (notebook)
ok

“storejet” и “notebook” взяты не с потолка — это те самые имена, которые мы передавали параметром в git annex init. Как видите, они нужны для того, чтобы вы могли легко понять, какой именно репозиторий скрывается за непонятным численно-буквенным именем.

С помощью команд get, copy и move можно удобно рулить файлами (вывод опущен):

# получить все файлы в этот репозиторий
$ git annex get .
# скопировать директорию с фотографиями обратно на notebook
$ git annex copy --to=notebook summer_camp_2012
# переместить всё со старого ноутбука сюда
$ git annex move --from=old_notebook .

Уже существующие файлы не передаются, то есть вторая команда не передаст ничего — фотографии с “notebook” никуда не девались, так что и копировать ничего не нужно.

Последняя команда git-annex, без которой вам не удастся жить — это git annex sync. Я уже запускал её, когда говорил о клонировании репозитория, но не объяснял, что она делает. А выполняет она очень важную операцию — синхронизирует текущий annex со всеми остальными, подтягивая из них данные о новых файлах и отправляя информацию о том, что поменялось в текущем. Для полной синхронизации, насколько я понимаю, нужно два круга (то есть по очереди выполнить git annex sync во всех репозиториях, а потом сделать то же самое ещё раз), но на деле вам вряд ли понадобится быть насколько строгим и последовательным. Лично мне с с ноутбуком, внешним винчестером и нетбуком хватает синхронизации между ноутом и винтом по крону, плюс ручная синхронизация нетбука, выполняемая время от времени по настроению. Git гарантирует, что ничего не потеряется, просто если добавить или удалить какой-то файл, информация об этом может не сразу добраться до всех репозиториев.

Ну всё, базовые функции я показал, свой первый annex мы создали — думаю, вы готовы читать git-annex walkthrough и идти внедрять git-annex в свою повседневную жизнь. Впереди вас ждёт куча интересных фич, таких как special remotes (возможность использовать Amazon Glassier, Flickr и прочие в качестве удалённых репозиториев), unused content (удаление или перемещение в архив старых версий файлов) и многое другое. Удачи!

• подумать, какие именно опции могут влиять на автодополнение (учитывая, что Vim — не самый простой редактор, и я всё ещё далёк от постижения всех его возможностей и особенностей, здесь я вполне мог бы додуматься до чего-то неправильного);
• вспомнить, что я менял в последнее время (прошла всего пара дней, но я за это время столько раз читал :help и столько смотрел на чужие конфиги, что вспомнить сделанные мной правки было уже не так-то просто);
• наконец, методом проб и ошибок выяснить, верны ли мои догадки, и всё починить.

Но мой .vimrc таки лежит под Git, поэтому я сделал следующее:

cd docs/git/dotfiles
git log
git bisect start
git bisect good 53273d7a0d6ab7f61a00ad1a43b1008eb189640f
git bisect bad
git bisect good
git bisect reset
git show acdc994b492bf5933e9c0374bf70e0ada69a2231
vim .vimrc
git add .vimrc
git ci -m'vim: fix directory completion for :e'
git push

То есть вместо того, чтобы думать и вспоминать, я запустил git bisect и уже через пару минут знал, какой именно коммит поломал мне автодополнение.

Когда я коммитил правки, мне было лень разбивать их на атомарные коммиты, поэтому после bisect пришлось ещё немного поэкспериментировать, чтобы выяснить, что всё ломается из-за опции wildignore, но это уже мелочи.

Между cd в репозитой и финальным git push прошло меньше десяти минут. Если бы не Git, я бы потратил не меньше получаса. В общем, если у вас есть большие и ценные конфиги, очень советую положить их под СКВ — морока минимальна, а польза хоть и редка, но огромна.

Пользуясь случаем, рекламирую etckeeper — программу, которая будет хранить правки вашего /etc в Git, Mercurial, Darcs или Bazaar. Более того, благодаря хукам для aptitude (а также yum и pacman-g2) всё автоматизировано по самое не хочу: при любом install, remove или purge программа сначала закоммитит любые незакоммиченные правки (если вы ленитесь и сами этого не делаете), потом поставит/удалит пакеты и снова всё закоммитит (на случай, если пакеты что-то поменяли). То есть вам делать ничего не нужно, а возможность всё откатить и починить появляется. Приятно же!