И вот спустя 11 лет офигенный совет: Предусмотреть автоматичский откат к предыдущей версии, если вдруг новый конфиг кривой (да, да. Ничего не сломается мы только конфиг катим.)
Ему бы она не подошла (ИМХО), так как для бекапа конфигов требуется гарантированно работающий механизм. А вот поменяли вы конфиги в single-user mode, когда следящий демон не работает — и конфиги не забекапились.
Сейчас в LKML обсуждают новый механизм — fanotify, в который, может быть, будет добавлено «гарантированное» получение уведомлений про изменение файлов (если уведомление не получено сейчас, то оно будет получено при следующем старте демона, возможно даже после перезагрузки).
Демон не работает, когда:
* система в single-user mode;
* демон кто-то выключил вручную и ещё не включил обратно (или вообще забыл включить);
* демон упал;
*…
Выполняет роль безопачного режима венды. В юниксах в этом ражиме возможен только один пользователь — рут. И как правило не чтартуют никакие службы — ака демоны. Используется при устрвнении аварий, воссьановлении рут пароля и нпример в фрибсд этот режим используют при обноылении системы.
В юниксах в этом ражиме возможен только один пользователь — рут.
Неправда. su sername и вперёд. Можно даже «рассвет вручную» сделать и иксы запустить (сначала hald стартовать, ещё несколько сервисов и startx от юзера).
Скажем, inotifywait я могу дать команду — «следи за /etc, КРОМЕ /etc/udev.d» потому, что бекапить /etc/udev.d (с динамически создаваемыми правилами) мне не нужно.
Вообще, в список «целей» попадает gentoo-переменная CONFIG_PROTECT, а в список «исключений» — переменная CONFIG_PROTECT_MASK
Кроме того, есть ещё одно неудобство. Мне-то надо действия выполнять не сразу, а через некоторую задержку. Редактирую я пачку конфигов, закончил — вот тут-то и настало время бекапа. Для этого, видимо, incron не очень подходит, либо с ним нужно искать другое решение задачи.
А вот inotifywait как раз позволяет написать такой shell-скрипт, с ним я задачу решил ;)
Ага, клевая штука, используем inotifywait для сбора множества мелких js и css файлов в 2 больших и последующего сжатия. Очень удобно — сохраняешь изменения в любом из мелких файлов, inotifywait отслеживает изменение в указанной директории и поддиректориях, и запускает команду сборки.
Вот, нашёл у себя в исходниках:
man 2 kqueue (для FreeBSD и Darwin)
У меня была идея, написать на python кроссплатформенного демона, реагирующего на такого-рода события, но дальше «ядра» для Windows и Linux дело не продвинулось — времени нет.
ИМХО, перезапуск сервиса по любому изменению конфига для «боевых» серверов всё-таки не есть хорошо, ведь после редактирования конфигурация сервиса может быть просто нерабочей (зависимые сервисы, конфигурация в несколькоих файлах, сервис долго перезапускается и т.д.). А это непроизводительные простои и тоска пользователям.
Лично у меня, например, есть привычка говорить ":w" несколько раз в процессе редактирования (а изменения бывают объёмными) конфига — IM_MODIFY будет выстреливать при каждой записи?
Штука интересная, но не стоит её использовать для конфигов, стоит подыскать примеры получше.
Кстати очень интересный вопрос как эта подсистема выдаёт MODIFY, ведь операции записи могут идти кусками. Варианты — по закрытию файла или после записи каждого куска…
> У меня маленькие конфиги. Они сразу пишутся =).
Не стоит на это рассчитывать.
Из примеров — наш админ планирует использовать данную штуку для оповещения изменений конфигов. Т.е. конфиг поменялся -> сообщение на jabber о том кто его его поменял, когда и т.д.
Вообще-то, была другая задумка — автоматический бекап новой версии конфигов в svn. «Нулевая» версия (до запуска сервиса) бекапится руками, а все последующие — автоматом; при желании, в таком архиве можно будет найти любые версии любых конфигов.
Как я делал:
1. Запускается subshell отдельным потоком в фоне (потом объясню, зачем)
2. При получении события действие только планируется, т.е. subshellу через какой-то механизм типа файла в /dev/shm сообщается, что через минуту нужно будет выполнить svn update. А сразу делается только svn add при создании файла, или svn delete при удалении (модификацию svn update заметит само). Если в течение минуты другой файл отредактировать, то время выполнения svn update «отодвинется».
3. Subshell устроен так: он ждёт изменений в файле в /dev/shm (сейчас я сделал банальный polling, но ничто не мешает реализовать там при помощи того же самого inotifywait). Через минуту, после того как последнее редактирование было произведено, выполнить svn update.
Собственно, вот и вся логика. С учётом инициализации (разбора переменных Gentoo и построения параметров inotifywait), весь скрипт уместится в строк 50 кода.
P.S. Предлагаю доделать это (наконец) и написать сюда статью.
Кстати это было бы супер — на все свои сервера ставить такую штуку, единый svn/git/hg/bzr реп и мы сразу же видим изменение конфигурации на сервере. Пойду поразбираюсь как бы это на питоне сваять.
Спасибо, написал скрипт, который каждый раз при вставке flash`ки делает резервную копию на жёсткий диск через rsync, теперь не так страшно потерять её :)
Inotify или автоматизация рутинных операций с помощью incron